woongs dogfoot

Load Balancer

• Load Balancer : 대량의 부하(Load)를 백엔드의 인스턴스에 고루 분산시켜주는 인스턴스

• 기능

1. 다수의 인스턴스로 부하 분산
2. 단일 엑세스 지점(DNS)만 노출
3. 인스턴스의 장애를 원활히 처리 (Load Balancer의 상태체크 기능 활용)
4. SSL기능도 있어 HTTPS 트래픽도 처리 가능
5. 가용영역에 걸친 고가용성 확보 가능
6. Cookies로 고정도(stickiness) 강화 가능
7. private 트래픽과 public 트래픽 분리 가능
   
   
   

Elastic Load Balancer (ELB)

• Elastic Load Balancer (ELB) : 관리형 로드밸런서
  
  
  

• 특징

1. AWS가 관리하고 어떤 경우에도 동작할 것을 보장
2. AWS가 업그레이드/유지관리/고가용성을 책임
3. 사용자가 동작방식을 설정할 수 있도록 AWS가 일부 configuration knobs를 제공
4. 자체 로드밸런서를 구성하는 것보다 비용이 저렴
5. 다양한 AWS 인스턴스와 통합 가능 (ex. EC2, ASG, ECS, Route53 등)
   
   
   

• Health Check 기능

1. ELB의 Health Check는 확인하고자 하는 인스턴스의 port와 route(ex. /health)로 진행됨
2. 인스턴스가 HTTP 응답으로 200을 주지 않는다면, 비정상으로 인식 -> 해당 인스턴스로 트래픽을 보내지 않음

• 관리형 Load Balancer(ELB)의 유형

1. Classic Load Balancer (CLB, 2009) -> 사용 안함
   • HTTP, HTTPS, TCP, SSL (Secure TCP) 지원
   • 현재 AWS Console에서는 사용 불가
2. Application Load Balancer (ALB, 2016)
   • HTTP, HTTPS, WebSocket 지원
3. Network Load Balancer (NLB, 2017)
   • TCP, TLS (Secure TCP), UDP
4. Gateway Load Balancer (GWLB, 2020)
   • 네트워크층에서 동작 -> 3계층, IP프로토콜 작동
     
     
     

• Internal : 내부에서만 동작하는 Load Balancer가 있음 -> 네트워크에 private 트래픽만 전달 가능 (ELB는 External)
  
  
  

• Load Balancer Security Group

1. Load Balancer의 Security Group 설정은 모든 클라이언트로부터 HTTP, HTTPS 트래픽을 허용해야 함
2. Back에 있는 EC2 인스턴스의 Security Group 설정은 ELB한테만 받아야하기 때문에 source를 ELB의 Security Group으로 설정함 (상세 설정은 아래 사진 참고)

Application Load Balancer (ALB)

• 특징

1. 7계층 HTTP전용 Load Balancer
2. 인스턴스 타겟간 다수 HTTP application의 라우팅이 활용 (타겟은 target groups으로 묶임)
3. 동일 인스턴스 상의 여러 application으로 부하 분산 (ex. containers)
4. HTTP/2와 WebSocket 지원
5. redirect 지원 (HTTP -> HTTPS 자동 redirect 가능)
6. target group별 라우팅 가능 (url path 기반 라우팅, ex. /users, /posts)
7. host name 기반 라우팅도 가능 (ex. one.example.com, other.example.com)
8. Query String, Headers 기반 라우팅도 가능 (ex. example.com/users?id=123&order=false)
9. micro service나 container기반 application에 가장 적합 (ex. Docker, Amazone ECS) -> port 매핑 기능이 있기 때문, port redirect 가능
10. Classic Load Balancer는 application별 Load Balancer가 필요했지만, ALB는 하나의 Load Balancer로 여러 개의 application에 활용 가능
11. url의 고정 host name이 부여됨
12. application 서버는 client의 ip를 직접 확인하지 못하고, HTTP요청의 X-Forwarded-For 헤더에 삽입 (X-Forwarded-Port : port, X-Forwarded-Proto : protocol)

• Target Group for ALB

1. HTTP로 연결되는 EC2 인스턴스가 포함될 수 있음 (ASG으로도 관리됨)
2. ECS 작업 가능
3. Lambda Function으로 활용 (Lambda Function 앞에 Load Balancer가 있을 수 있다는 말, serverless 가능)
4. private IP주소로 활용 -> On-Premises 환경에도 라우팅 가능 -> On-Premises 서버의 private IP가 target group에 지정되어야 함
5. ALB는 여러 Target Group으로 라우팅할 수 있고 Health Check는 target group level로 진행됨

• Network Security (Security Group 설정)
  : EC2 인스턴스의 public IP로 접근하면 Load Balancer를 통하지 않고서도 접근 가능 -> 보안을 위해 인스턴스로의 직접 접근이 아닌 Load Balancer를 통한 접근을 지향해야 함 -> 인스턴스 Security Group의 in-bound rule 수정 -> source를 CIDR 모든 ip가 아닌 Load Balancer의 Security Group으로 설정
  
  
  

• ALB Listeners rule
  : 요청을 filtering하여 조건(ex. host header = *.example.com, path = /item, HTTP request method = get, source IP = 0.0.0.0, HTTP Header, Query String)에 맞는 요청이 들어올 경우, 특정 target group으로 라우팅될 수 있도록 설정할 수 있음 (Listeners -> add rule)
  
  
  

Network Load Balancer (NLB)

• 특징

1. Layer4 (전송계층) Load Balancer
2. TCP/UDP 트래픽을 다룸
3. 초당 수백만 건의 요청 처리
4. ALB보다 지연시간이 짧음 (ALB : 400mm, NLB : 100mm)
5. 가용영역(subnet)별로 하나의 고정 IP를 가짐 (Elastic IP (public 고정ip) 할당도 지원) -> 여러 개의 고정IP를 가진 application을 노출할 때 유용
   
   
   

• Target Group for NLB

1. EC2 인스턴스 -> TCP/UDP 트래픽을 EC2 인스턴스에 전달할 수 있음
2. private IP주소로 활용 -> 자체 데이터센터의 private IP를 지원하기 위함
3. Application Load Balancer -> NLB를 ALB 앞에 배치 -> ALB에 고정IP를 가질 수 있고, HTTP유형의 트래픽을 어떻게 처리할지 설정 가능
4. 타겟그룹에 대한 TCP/HTTP/HTTPS Health Check를 지원

Gateway Load Balancer (GWLB)

• 특징

1. AWS내에서 배포/확장/타사네트워크appliance에 활용
2. 모든 트래픽에 대한 방화벽 설정 진행
3. 모든 트래픽에 대한 침입 탐지 및 방지 시스템에 활용 -> IDPS나 심층패킷분석 시스템, 일부 페이로드 수정을 네트워크 수준에서 가능
   
   
   

• appliance : 운영체제나 응요 소프트웨어의 설치, 설정 등을 행하지 않고 전원만 연결하면 곧바로 사용할 수 있는 제품. 즉, 특정 목적에 최적의 성능을 낼 수 있도록 사전에 하드웨어 내 소프트웨어가 모두 설치되어 제공되기 때문에 전원만 연결하면 곧바로 사용할 수 있다.
  
  
  

• application으로의 사용자 트래픽을 모두 검사하기 위해 3rd-party appliance가 활용될 수 있음 -> 3rd-party appliance 연동을 위해 GWLB가 활용될 수 있음 -> GWLB가 생성되면, 사용자측 VPC의 라우팅 테이블이 update됨 -> 모든 사용자 트래픽은 GWLB를 통하게 되고, GWLB를 통하는 트래픽은 3rd-party appliance에 보내져 분석되고 처리됨 -> 이상이 없는 트래픽이면 다시 GWLB에 보내고, 이상이 있으면 GWLB에 보내지 않고 drop됨 (방화벽 기능) -> GWLB에서 트래픽을 다시 받으면 application으로 보내줌

• 원리

1. 낮은 계층(L3)에서의 실행으로 인한 기능
   • 투명 네트워크 게이트웨이 : VCP의 모든 트래픽이 GWLB를 통하게 되는 단일 입구/출구
   • Load Balancer : 가상 appliance 집합에 트래픽을 분산
     
     
     

• 6081 포트의 GENEVE 프로토콜 사용 -> GWLB
  
  
  

• Target Group for GWLB

1. EC2 인스턴스 (타사 appliance가 될 수도 있음)
2. private IP주소로 활용
   
   
   

Sticky Sessions

• Sticky Sessions : client가 ELB를 통해 특정 EC2 인스턴스에 요청을 보내고, 다시 ELB에 요청을 보내면 이전과 동일한 EC2에 요청을 보낼 수 있도록 유지해주는 기능

• Target group - Actions - Edit Attributes - Stickiness 체크
  
  
  

• 원리 : HTTP 요청의 cookie를 활용하여 특정 client는 특정 인스턴스로 redirect해줌. 만료기간도 있을 수 있어 해당기간이 지나면 다른 인스턴스로도 요청이 보내질 수 있음 (요청으로 cookie를 만들 때에는 인스턴스나 LB가 생성한 cookie정보를 기반으로 브라우저에서 cookie를 생성함)
  
  
  

• cookie

1. application-based cookies
   • custom cookie
     • 타겟인 application 서버에서 생성됨
     • application에 필요한 사용자의 정보를 포함시킬 수 있음
     • cookie name은 target group별로 지정해야 함 (지양하는 name : AWSALB, AWSALBAPP와 같이 ELB에서 사용하는 cookie의 이름과 중복될 수 있음)
   • application cookie
     • Load Balancer에서 생성됨
     • cookie name은 AWSALBAPP
   • 만료기간은 application에서 지정할 수 있음
2. duration-based cookies
   • Load Balancer에서 생성됨
   • cookie name은 AWSALB, CLB에서는 AWSELB
   • 특정 기간을 기반으로 만료됨 (기간은 Load Balancer자체에서 설정됨)
     
     
     

• 취약점 : 인스턴스 부하의 불균형을 초래할 수 있음
  
  
  

• use case

1. 사용자가 로그인 정보와 같은 중요한 정보를 위한 세션 데이터를 잃지 않기 위해 동일 인스턴스에 요청을 보낼 수 있도록 함
   
   
   

Cross-Zone Load Balancing

• Cross-Zone Load Balancing : 서로다른 가용영역의 Load Balancer가 모든 가용영역에 등록된 모든 인스턴스에 부하를 고르게 분배하는 기능 -> 특정 가용영역의 Load Balancer가 다른 가용영역의 인스턴스까지 포함하여 트래픽을 고루 분배함
  
  
  

• 트래픽 불균형 (AS-IS)

• 영역교차 균형 분배 (TO-BE)

• 특징

1. application load balancer에는 기본적으로 활성화되어 있는 기능 (target group 설정에서 비활성화 가능) -> 데이터를 다른 가용영역으로 옮길 때 비용이 들지 않음
2. network/gateway load balancer에는 기본적으로 비활성화되어 있는 기능 (load balancer 설정에서 활성화 시, 비용 지불) -> 데이터를 다른 가용영역으로 옮길 때 비용이 청구됨
3. classic load balancer에는 기본적으로 비활성화되어 있는 기능 (target group 설정에서 활성화 가능, 비용 지불 없음)
   
   
   

SSL/TLS

• SSL (Secure Sockets Layer) : client-Load Balancer간의 트래픽을 암호화 (in-flight 암호화)
• TLS : newer version SSL
• public SSL 인증서는 CA(인증기관)에서 발급 (ex. Comodo, Symantec, GoDaddy, GlobalSign etc...)
• public SSL 인증서를 Load Balancer에 추가하면 client-Load Balancer간의 연결이 암호화 됨
• 인증서는 만료기간이 있어 주기적으로 갱신해 주어야 함.
• Load Balancer는 X.509 인증서를 활용 (SSL/TLS Server certificate)
• ACM(AWS Certificate Manager)에서 해당 인증서들을 관리함 -> 발급받은 인증서를 ACM에 업로드할 수 있음
• Load Balancer에서 listener를 구성할 때, HTTPS로 구성해야 암호화가 진행됨
  • 기본 인증서 지정
  • 다중 도메인 지원을 위해서는 추가 인증서 지정 필요
  • client에서는 SNI(Server Name Indication)으로 접속할 hostname을 Load Balancer에 알릴 수 있음
  • SSL/TLS를 사용자가 지정할 수 있음

• 구조

1. client에서 Load Balancer로 HTTPS 요청을 보냄 (SSL 암호화)
2. HTTPS 요청을 받은 Load Balancer는 내부적으로 SSL 종료를 진행
3. Load Balancer-EC2간 통신은 HTTPS 통신 -> private 네트워크를 쓰기 때문에 별도 암호화 불필요
   
   
   

• SNI (Server Name Indication) : client가 대상 서버의 hostname을 지정하는 기능

1. SNI를 이용하면, 여러 개의 인증서를 하나의 웹서버에 업로드하여 하나의 웹 서버가 여러개의 웹 사이트를 지원할 수 있도록 할 수 있음
2. SNI는 SSL handshake 단계에서 진행됨 -> SNI를 통해 서버가 hostname을 전달받았을 때, 어떤 인증서를 불러와야 하는지 판단
3. 해당 기능은 확장된 protocol로 새로 추가된 기능이기 때문에 모든 client가 지원하는 기능은 아님 (ALB/NLB/CloudFront에서만 동작) -> CLB에서는 동작 안함
   
   
   

Connection Draining (Deregistration Delay)

• Connection Draining (Deregistration Delay) : 인스턴스가 중지나 비정상 상태일 때, 해당 인스턴스를 Draining mode로 설정하여 해당 인스턴스로의 요청이 완료될 수 있도록 하는 기능 -> 인스턴스가 drain mode에 있을 때, 해당 인스턴스에 새로운 요청을 보내지 않음
• 기요청된 트래픽이 완료될 수 있도록 drain mode 시간을 사용자가 설정할 수 있음 (1~3,600s, default : 300s)
• 요청 처리 시간이 짧을 수록 drain mode 시간을 낮게 설정하는 것이 유리 (빨리 중지시키고 빨리 교체)

• AWS 일반적인 아키텍처 : public IP를 할당받아 인터넷을 통한 통신이 가능하게 함
• 사설 네트워크에서 인터넷 통신이 필요할 때, NAT 장치와 인터넷 게이트웨이가 필요함

• Elastic IP : 고정적인 public IP
• 고정된 public IP가 필요할 때, 사용됨
• 계정당 5개 Elastic IP 허용
• Elastic IP 활용은 지양, random public IP를 할당하여 DNS로 인스턴스에 연결하는 방식 권장 (인스턴스 중지/시작 시, public IP 재할당됨)
  
  
  

Placement Group

• Placement Group : EC2 인스턴스가 AWS 인프라에 어떻게 배치할지 제어할 때 사용
  
  

• 배치전략

1. 클러스터배치그룹
   • 단일 가용영역 내에서 지연 시간이 짧도록 하드웨어를 배치하여 인스턴스 그룹화
   • 고성능 고위험
   • 빠른 빅데이터 처리 작업 등과 같은 초저지연의 고성능 application에 적합

2. 분산(spread)배치그룹
   • 인스턴스를 각 하드웨어에 배치
   • 인스턴스(하드웨어)간 오류로부터 격리 -> 안정성 보장
   • 가용영역별 Placement Group당 최대 7개의 인스턴스(7개의 하드웨어)만 배치할 수 있음 => application 규모에 제한 (ex. 모놀리식)

3. 파티션배치그룹
   • 인스턴스를 각 파티션에 분산배치하고 해당 파티션들을 가용영역내에서 각각의 하드웨어 rack에 의존시키는 방식 (partition = rack)
   • 파티션 내의 인스턴스 갯수는 제한이 없지만, 가용영역당 파티션 갯수는 분산배치그룹과 동일하게 7개로 제한 (파티션 = 하드웨어 개념이기 때문)
   • 파티션(하드웨어)간 오류로부터 격리
   • 파티션간 오류로부터 격리되고 파티션 내의 인스턴스 갯수에 재한이 없음 -> 대규모 인스턴스 application 설계 가능 (ex. MSA)
   • Hadoop, Kafka 같은 분산환경 application을 실행시킬 수 있음
   • 메타데이터 서비스를 활용하여 각 인스턴스에 접근할 수 있게할수도 있음

Elastic Network Interfaces (ENI)

• ENI : VPC의 논리적 단위이며 가상 네트워크 카드를 가리킴, EC2 인스턴스가 private 네트워크에 접속할 수 있게함
  
  

• 특징

1. 인스턴스당 하나의 private IP와 여러 개의 보조 private IP를 가질 수 있음 (private IP 한개 당 ENI 한개)
2. private IP를 갖고 있는 ENI는 하나의 public IP나 Elastic IP를 가질 수 있음
3. ENI에 하나 이상의 Security Group을 연결할 수 있음
4. Mac 주소 등 기타 항목을 연결할 수 있음
5. 장애조치 등을 위해 다른 EC2 인스턴스로 이동시킬 수도 있음
6. 특정 가용영역에 바인딩됨 (특정 가용영역 내에서만 사용 가능)
   
   
   

EC2 Hibernate (절전모드)

• EC2 Stop/Start

1. Stop 시, EBS 데이터는 다시 시작할 때까지 유지
2. 종료 시, root volume이 삭제되게 설정했다면 데이터도 삭제 (root volume이 삭제되지 않는다면 유지)
3. 재시작 시, OS먼저 boot되고 사용자 스크립트가 실행됨 -> 애플리케이션 실행, 캐시 구성
4. EC2에는 Stop, Terminate, Start를 제외하고 Hibernate(절전)라는 기능이 제공됨.
   
   
   

• Hibernate 상태

1. In-Memory의 상태는 그대로 유지 -> 운영체제가 완전히 중지되지 않고 memory에 그대로 남아있기 때문에 인스턴스 부팅이 빨라짐
2. Im-Memory의 상태는 EBS root volume에 기록됨(dump) -> 용량이 커야하고 volume은 암호화되어야 함. (EBS likes 물리 디스크)
3. Hibernate 상태 진입 -> 인스턴스가 중지되면서 memory의 데이터는 EBS root volume에 dump됨 -> 인스턴스가 완전이 내려가면 ram 데이터는 모두 삭제 -> 인스턴스 재부팅 시, EBS root volume에 기록되었던 ram 데이터를 그대로 가져옴
   
   

• 참고사항

1. 인스턴스 ram 크기는 최대 150GB
2. Hibernate를 지원하는 제품군이 많음 (ex. C3, C4, C5, I3, M3, T2, T3 등)
3. 여러 운영체제에서 Hibernate 사용가능
4. 베어메탈 인스턴스는 지원하지 않음
5. In-Memory 데이터는 EBS Volume에만 저장 가능
6. On-Demand, Reserved 등과 같은 모든 인스턴스 요금제에서 사용가능
7. 최대 60일까지 사용가능
8. 운영체제로 하여금 인스턴스가 한번도 중지가 안된 것처럼 인식되게 함.
   
   

• Use Case

1. 오래 실행되는 프로세스
2. ram 데이터 저장 필요
3. 빠른 부팅 필요