DevX

Load Balancer(이하 로드밸런서) 에 대한 내용은 이전에 간략하게 다루어 봤습니다.

이제는 AWS의 Elastic Load Balancer (이하 ELB) 에 대한 개념과 내부 동작을 간략히 설명하겠습니다.

글을 쓰기 앞서 아래 링크를 참조하였습니다.

• AWS ELB (Inpa.tistory)
• 패킷으로 확인하는 ALB & NLB (alden-kang.tistory)
• AWS NLB (gasida.notion)

ELB 구성

ELB는 Public (Internet) 과 Private (Internal) 영역에 생성이 가능합니다.

Public ELB는 공인IP와 사설 IP를 모두 가지며, 인터넷과 VPC 내부 리소스간 통신이 가능합니다.
즉, ELB 는 NAT Gateway 없이도 Private 과의 통신이 가능합니다.

Private ELB는 사설 IP만을 가지고 VPC 내부에 생성되어 내부 통신을 할 수 있습니다.

ELB 생성 시, EC2와 유사한 ELB 인스턴스(로드밸런서 노드)가 생성됩니다.

로드밸런서 노드는 Listener 와 Load Balancer 로 구성되어 있습니다.

• Listener 는 사용자가 지정한 프로토콜+포트와 일치하는 요청을 수신합니다.
• Load Balancer 는 수신한 요청을 적절한 대상으로 로드밸런싱합니다.

그리고 ELB 로부터 요청을 넘겨받을 Target Group 을 설정해주어야 합니다.

Target Group은 여러 개의 백엔드 서버들로 구성되며, 해당 서버에서 수신할 요청의 스펙을 정의할 수 있으며,

로드밸런서 노드가 Target Group의 정의된 스펙에 맞게 요청을 넘겨줍니다.

또한, Target Group은 로드밸런서로부터 서버들이 정상적으로 동작하는 주기적으로 검사하는 Health Check 기능을 수행하며, 자동으로 정상적인 서버에만 요청을 전달합니다.

( 구체적으로 말하자면, 로드밸런서는 Target Group 의 서버들을 서버풀(Pool) 로 관리합니다.
 Health Check 를 수행해 비정상적인 응답을 보내오는 서버들은 서버풀에서 제외시키며, 고가용성을 보장합니다. )

ELB는 Target Group의 모든 서버들이 비정상적인 응답을 하게되면 ELB 동작을 비활성화합니다.

만약, 알고리즘으로 세션이 갱신되는 상황을 방지하기 위해 Sticky Session 을 고려할 수 있습니다.

Sticky Session 은 처음 커넥션이 구성된 서버와 일정 시간동안 세션을 유지할 수 있도록 도와줍니다.

TCP 프로토콜은 350초이며, UDP 프로토콜은 120초로 세션이 유지됩니다.

그럼 이제 AWS ELB 서비스를 대표하는 NLB 와 ALB 에 대하여 간략히 알아보겠습니다.

NLB는 인스턴스로 생성이 되지만 AWS 측 LB 물리장비와 연결되어 동작합니다.

ALB는 인스턴스로 생성되어 Software Load Balancer 위에서 동작합니다.

두 LB의 차이가 보이시나요?   바로 Layer 의 수준이 다르다는것을 한 눈에 볼 수 있습니다.

NLB 는 L4 수준의 프로토콜(TCP, UDP)과 즉각적인 L4라우팅을 담당합니다.

ALB 는 L7 수준의 프로토콜(HTTP, HTTPS)을 다루며, 데이터를 직접 확인하기 때문에 정확한 전송이 가능합니다.

 결론적으로, L4 는 무지 빠릅니다,  그리고 L7은 다양하고 정밀한 라우팅이 가능합니다.

이대로는 아쉬우니 NLB, ALB 의 특징을 조금만 더 알아보겠습니다.

NLB 

ALB

위 내용은 AWS Docs 에서 가져왔습니다. 그 중 문서에서 찾아볼 수 없는 궁금한 내용들을 간략히 알아보겠습니다.

• NLB 만 고정 IP 를 지원합니다.

고정 IP 는 각 AZ 별 1개씩 생성이 가능하며 인스턴스(VM) 에  할당하여 사용가능한 리소스입니다.

NLB, ALB 둘 다 결국 인스턴스(로드밸런서 노드) 가 생성되어 할당이 가능해야하는데 왜 NLB만 지원할까요?

그 답은 ELB의 고가용성(HA) 에 있습니다. NLB는 매우 빠른 요청처리가 가능하며, 각 AZ 별로 생성 가능합니다.

또, 로드밸런서 자체적으로도 하는일이 거의 없습니다. 기껏해야 SNAT, DNAT , 포트포워딩이며, DSR을 활용 시 인바운드 트래픽만을 처리하기 때문에 변동이 거의 없는 안정적인 운용이 가능합니다. (이후에 부가적으로 설명하겠습니다.)

반면, ALB 는 패킷의 내부 데이터 헤더를 확인하여 정확한 경로(대상)로 전송해야할 의무가 있습니다.

따라서, ALB 내부적으로 처리해야하는 작업의 부담이 있으며, 요청 트래픽의 크기와 양에 따라 ALB 로드밸런서 노드를 추가로 생성/삭제하여 안정적으로 운용하려고 합니다.

ALB 로드밸런서 노드가 Scale In/Out 하는 과정에 있어 IP 가 수시로 바뀌기 때문에 고정 IP 를 할당하는데 있어 적합하지 않습니다.

( ALB에 고정 IP를 할당하고 싶다면 앞 단에 NLB를 생성한 후 타겟 그룹으로 ALB를 지정하는 방법이 있습니다. )

• NLB 는 보안 그룹을 사용할 수 없습니다.

보안그룹은 인스턴스 수준에서 인/아웃 바운드 트래픽을 제어하는 리소스로 ENI에 붙여 사용합니다.

인스턴스 당 5개의 보안그룹을 사용할 수 있고, 방화벽의 역할을 하지만 허용(Allow) 만 제어가 가능합니다.

그렇다면, 왜 NLB는 보안 그룹을 사용할 수 없을까요?

물론, AWS의 기술력이 부족한 이유는 절대 아니며, 사용할 수 있게 만들수는 있지만 본래 의도와 다르기 때문입니다.

NLB 특성 상 대량의 트래픽 처리가 가능하며 이에 따라 뒷 단에 요청을 받는 서버는 고가용성 보장이 가능해야 합니다.

즉, Scale 변동이 가능한 오토스케일링 그룹(ASG) , ALB 가 오는 경우가 많습니다.

이는 NLB와 인스턴스 타입으로 사용할 수 있고,  NLB + 인스턴스 타입의 조합은 소스 IP 를 그대로 전달합니다.  

소스 IP를 그대로 받는다는 것은 NLB가 요청받는 소스IP 와 백엔드 서버단에서 받는 소스 IP가 동일함을 의미합니다.

이렇게 되면 NLB에서 굳이 보안그룹을 사용해야 하는가? 에 대한 물음으로 이어질 수 있겠습니다. 

추후 Target Type (Instance mode, IP mode) 와 IP 보존에 대한 이야기를 덧붙이도록 하겠습니다.

또, 로드밸런서의 라우팅방법에 대해서도 간략히 이야기해보겠습니다.

로드 밸런서 라우팅 방법 : https://ssup2.github.io/theory_analysis/SLB/

글을 쓰기 앞서 이 책을 참조하였습니다.

쿠버네티스 인증에는 어떤 것들이 있나요?

• Service Account 오브젝트를 통한 인증
• Open ID Connect  (OAuth) 와 같은 third party 를 통한 인증
• Certificates (인증서)를 통한 인증  등이 있습니다.

쿠버네티스 사용 시 인증이 왜 필요한가요?

운영중인 서비스에 대한 보안 강화 및 기밀 정보 보호의 목적 뿐만 아니라,

사내 조직 간의 쿠버네티스 동시다발적 제어 및 접근에 있어서

RBAC (Role Based Access Control)  역할에 따른 최소 권한 할당에 있어서 중요한 역할을 합니다.

쿠버네티스의 인증과정은 어떻게 이루어지나요? 

일반적으로 위와 같은 과정으로 Kubernetes API Server 에서 인증이 진행됩니다.

1. Kubectl 명령어를 통해 Kube-API Server에 HTTP Handler 에 요청을 전송
2. API Server 는 해당 클라이언트가 쿠버네티스의 사용자가 맞는지 확인
3. API Server 는 해당 클라이언트가 요청한 기능을 실행할 권한이 있는지 확인 
4. 관리자의 정책에 따라 Admission Control 을 수행합니다.

API Server 가 인증을 어떻게 하나요?

앞서 설명했다시피  Service Account, third party , Certificates 와 같은 방법들이 있습니다.

우선 Service Account 오브젝트를 활용하여 인증하는 방법을 설명하겠습니다.

Service Account (SA) 는 체계적으로 권한을 관리하기 위한 쿠버네티스 오브젝트입니다.

k create sa [Service Account Name] -n [ namespace ]

 위와 같이 SA 생성이 가능하며, 다음과 같이 활용할 수 있습니다.

그러나, SA 오브젝트만 있어서는 인증이 불가능하며, SA 에 직접  접근 대상, 접근 권한, 권한 주체를 설정해주어야 합니다.

Role 이라는 오브젝트로 아래와 같이 rule 을 적용하여  SA에 RoleBinding 을 통해 Role 을 할당해 주어야 합니다.

또, Namespace 에 속한 리소스들을 대상으로 다루는 Role 과  Cluster 전체 리소스들을 다루는 Cluster Role 이 있습니다.

그러면, Kubectl 을 통해서만 SA 를 활용할 수 있나요?

Application 에서 또한 HTTP API 를 통해 API Server에 요청이 가능합니다.

우선, HTTP API 요청을 위한 API Server Endpoint 로  다음과 같습니다.

기본적으로 API Server 는 HTTPS 요청만을 처리하기 때문에, 인증에 대한 자격증명이 필요합니다.

SA 오브젝트를 생성ㅇ하면 해당 SA에 대응하는 Secret 이 자동으로 생성됩니다.

해당 Secret 에는 ca.crt , token , namespace 가 base64 로 인코딩되어 저장되어 있습니다.

이에 Application 에서는 Token 정보를 읽어 API Server 에 JWT 인증을 시도합니다.

이후, 기존 SA 정보를 바탕으로 인증 및 인가 과정을 처리하게 됩니다.

그리고, API Server 의 몇몇 특정 경로들은 접근 제한이 되어있으나, Cluster Role 을 통해 아래와 같이 설정하여 접근이 가능합니다.

마지막으로, 다음과 같이 SDK 를 통한 SA 인증이 가능합니다.

1. SA 를 생성 한 후 Role 과 Role Binding 을 적용해줍니다. 

2. 대상 Pod 에 SA 이름을 명시합니다.

3. 해당 Pod 의 Container 에 자동으로 Secret 정보가 마운트됩니다.

4. Token 정보를 읽어 기존 default namespace 의 kubernetes 서비스를 통해 API Server 에 인증을 시도합니다.

RBAC 이 왜 중요한건가요?

추후 작성 예정

Admission Controller 가 뭔가요?

추후 작성 예정

OIDC 나 Certificates 를 통한 인증은 어떻게 하나요??

새로운 글로 작성 예정