AWS SAA(Load Balancer, Auto Scaling, RDS, Aurora)

고가용성 및 확장성

수평적 확장

• 더 많은 수의 인스턴스를 띄우는 방식의 탄력적인 방식

수직적 확장

• 하드웨어 또는 인스턴의 티어를 올리고 더 많은 리소스를 사용하는 경우 사용
• 주로 한 개 애플리케이션이 처리하는 처리이 늘어나는 경우 진행

EC2에서 적용

• 수직적 확장(Vertical Scaling)
• t2micro - t2large
• 1vCPU / 10GiB RAM -> 2vCPU / 80GiB RAM
• 인스턴스 타입 변경을 통해 확장을 지원

수평적 확장

• Auto Scaling Group을 멀티 AZ로 적용
• 로드 밸런서를 Multi AZ로 적용

로드 밸런서를 사용하는 이유

• 여러 대의 서버에 트래픽을 분산하는 역할
• 여러 application / 서버에 대한 외부에 공개된 접근 포인트를 노출 주는 역할(DNS)
• 뒷단 인스턴스의 장애 또는 부하 처리를 용이하게 함
• 인스턴스에 대한 헬스 체크를 진행
• 가용 영역 간의 가용성을 지원
• 퍼블릭 트래픽과 프라이빗 트래픽을 분할

---

ELB, ALB, NLB, GWLB

ELB(Elastic Load Balancer) 란?

• AWS에서 제공하는 관리형 로드 밸런서
• 관리형 
  • AWS가 작동을 보증
  • AWS에서 업그레이드 / 유지 보수 / 고가용성을 관리
  • 적은 수의 설정 변경 권한을 제공
• 직접 생성에 비해 비용이 적음 → 가격적인 면과 관리 효율 면에서 더 나음
• 다른 AWS Service 들과 연동을 지원 Cloud watch를 통해 모니터링하고, AWS Certificate Manager를 통해 인증을 관리하고, EC2 Auto Scaling Group과 연계해 자동으로 부하를 분산하는 등 다양한 서비스 연동을 지원

※ 되도록이 무조건 사용하는 것이 좋음, 자체 로드 밸런서보다 비용이 적고 확장성은 좋음

 

헬스 체크 이해

• 로드 밸런서에서 가장 중요한 역할
• 뒷단 인스턴스가 들어오는 요청을 받을 수 있는 상태인지 확인하는 역할
• 포트 번호 + 라우트로 구성 (example.com:443/health-check)
• HTTP 상태 코드를 기준으로 판단(일반적으로 200을 사용)

---

Load balancer와 Security Groups

• Security Group을 기반으로 요청에 대한 허용 여부를 핸들링
• Type | Protocol | Port 범위 | 요청 소스를 기반으로 구성
• 요청 소스는 요청하는 Client를 식별
  • IP 0.0.0.0
  • IP Cidr 10.10.1.0/24
  • 다른 Security Group 의 Id
• 흐름: USER →  LOAD BALANCER → EC2
  • 로드 밸런서의 보안그룹과 EC2 보안그룹이 연결됨
  • USER의 요청을 로드 밸런서 보안그룹이 허용하고 EC2로 보냄, EC2 보안 그룹은 로드 밸런서의 요청만을 허용함

---

CLB(Classic Load Balancer) - 2009년 출시

• 지원 프로토콜
  • TCP(layer 4)
  • HTTP, HTTPS(layer 7)
  • HTTP 또는 TCP 기준으로 헬스 체크를 진행
• 고정된 호스트 네임을 가짐
• Client - CLB - Server

---

ALB(Application Load Balancer) - 2016년 출시

• HTTP (Layer 7 / 애플리케이션 계층)의 로드 밸런서
• 여러 대의 머신 / 여러 개의 HTTP 애플리케이션의 부하를 분산하는 데 사용(target group)
• 한 대 머신의 여러 인스턴스에 부하를 분산하는 데 사용(Container 환경 등)
• HTTP/2 와 웹소켓을 지원
• HTTP to HTTPS 리다이렉트 등 리다이렉트를 지원
• Client - ALB - Server1, Server2

ALB(Application Load Balancer) 사용 시기

• Container 기반 애플리케이션
• 마이크로 서비스
• ECS를 사용하는 경우 다이나믹 포트에 대응하기 위해 포트 매핑 지원
• 애플리케이션 별로 CLB를 붙일 필요가 없음
• 다양한 종류의 요청을 한곳에서 핸들링 할 수 있음

ALB(Application Load Balancer) 기억해야할 특징

• 고정된 호스트 명을 사용 (xxxx.region.elb.amAZonaws.com)
• 타겟그룹에 연결된 IP는 외부에 공개되지 않음
• IP 의존 대신 호스트를 기준으로 핸들링하기 때문에 유연
• 클라이언트의 정보는 HTTP 헤더에 담겨 들어감
  • X-Forwarded-For -> 클라이언트의 IP / 127.0.0.1이 클라이언트라면 전달된 IP는 로드 밸런서의 IP이고 x-forwarded-for 헤더에 127.0.0.1 이 담기게 됨
  • X-Forwarded-Port / X-Forwarded-Proto도 있음

ALB(Application Load Balancer) Routing

• 타겟 그룹은 라우팅 테이블(Routing Table)별로 구성

ALB Routing 기준

• url 기반 - example.com/something | example.com/products
• host 명 기반 - test.example.com | devops.example.com
• Query String 또는 헤더 기반 - example.com/product?id=1234

ALB(Application Load Balancer) - Target Group

• EC2 인스턴스 - HTTP 기반 타겟 그룹
• EC2 태스크 (ECS 기능) - HTTP
• Lambda 함수 - JSON event로 변환되는 HTTP
• IP 주소 - Private IP로 적용
• 한 개 ALB는 여러 개 타겟 그룹과 엮일 수 있음
• Health Check는 각 인스턴스가 아닌 타겟 그룹 단위로 이루어짐

---

NLB(Network Load Balancer)

• Layer 4(Transport Layer)에서 동작하며 TCP / UDP 요청을 전달
• 초당 백만 단위의 요청을 처리할 수 있음
• ALB에 비해서 더 빠른 지연 시간을 가지고 있음(ALB 400ms | NLB 최대 100ms)
• AZ당 하나의 고정 IP만 가짐
• 만약, NLB가 3개의 AZ에 걸쳐 설정되어 있다면, 이 NLB는 총 3개의 고정 IP 주소(AZ당 1개)를 가지게 됨
• 장애발생시 나머지 AZ의 고정 IP는 여전히 작동
• 극한의 성능, TCP, UDP = 네트워크 로드 밸런서 나야 
• 고성능 워크로드를 설계할 때 사용함
• 프리 티어에서는 사용할 수 없음
• TCP, TLS (보안형 TCP), UDP
• 타겟그룹과 TCP 또는 HTTP HTTPS로 통신할 수 있음
• 클라이언트 - NLB는 TCP 기반으로 통신함
• ALB 와 동일하게 여러 개의 대상그룹(Target Group) 을 가질 수 있음
• 타겟그룹의 속성
  
  • EC2 인스턴스
  • Private IP 주소
  • ALB

---

GWLB(Gateway Load Balancer)

• 가상 어플라이언스를 위한 로드 밸런서
• 배포, 확장, 관리 용이성을 위해 설계
• Layer 3 (네트워크 계층)에서 동작함
• 단일 인입 / 반환 지점이 있음
• 가상 어플라이언스에 대한 요청을 분할해서 전송함
• GENEVE 프로토콜을 사용함 (포트는 6081을 사용)
• EC2 인스턴스 또는 프라이빗 ip 주소를 대상 그룹으로 설정할 수 있음
• OSI 3계층 - IP 프로토콜

---

AWS 로드 밸런서 추가 기능

Sticky Session

• 동일한 클라이언트가 요청을 동일한 인스턴스에서 이어서 처리하도록 유도
• CLB / NLB / ALB에서 지원
• CLB 와 ALB에서는 쿠키를 기반으로 동일 클라이언트에 대한 요청을 확인함
  • 스티키 세션 유지 시간을 설정할 수 있음
• 사용할 때 인스턴스 간 트래픽 분할이 균등하지 않을 수 있음
• 예를 들면 로그인 정보를 세션에 저장하면, 저장된 로그인 세션 정보를 다른 인스턴스가 해당 세션을 이어서 활용할 수 있도록

---

스티키 세션 - 쿠키

• 애플리케이션 별 쿠키
• 애플리케이션 에서 커스텀 쿠키를 셋팅할 수 있음
• AWS ALB, AWS ALB APP, AWS ALB TG는 사용을 피해야함
• 타겟그룹당 독립적인 이름을 가져야 함
• AWS ALB APP 은 로드 밸런서에서 자동으로 생성해 주는 쿠키명

기간 단위 쿠키

• 로드 밸런서가 직접 생성함
• ALB는 AWS ALB
• CLB는 AWS ELB

---

Cross-Zone Load balancing

 

ALB

• 기본으로 사용설정이 켜져 있음
• 대상 그룹 단위로 껐다 킬 수 있음
• AZ 간 데이터 전달에 추가 비용이 발생하지 않음

NLB / GWLB

• 기본으로 사용이 꺼져있음
• AZ 간 데이터 전달에 비용이 발생함

CLB

• 기본으로 사용설정이 꺼져 있음
• AZ 간 데이터 전달에 추가 비용이 발생하지 않음

---

SSL 과 TLS

 

SSL

• SSL 인증은 클라이언트와 로드 밸런서 간의 통신을 암호화해주는 역할을 함
• SSL은 연결을 암호화하기 위한 용도 - Secure Socket Layer의 약자
• SSL 통신은 CA(Certified Agent)를 통해 발급됨
• 사용자가 지정한 만료 일자가 있고 주기적으로 업데이트해주어야 함

TLS

• Transport Layer Security의 약자
• SSL 이후 출시된 구간 암호화 방식

---

Load Balancer에서 SSL 인증 동작 방식

• 로드 밸런서는 X509 인증을 사용함
• AWS Certified Manager를 통해 인증을 관리할 수 있음
• 이미 가지고 있는 인증을 생성하거나 업로드할 수 있음
• HTTPS 리스너
  • 기본 인증서를 설정해야 함
  • 여러 개의 도메인을 지원하기 위해 추가적인 인증서를 등록할 수 있음
  • 클라이언트는 SNI를 통해 도착지의 호스트명을 식별할 수 있음
  • 레거시 인증서에 대한 서포트를 지원

---

SNI(server name indication)

• SNI는 여러 개의 SSL 인증서가 한 개 웹서버에서 동작할 때 적절한 인증서를 로딩하기 위해 사용함
• 클라이언트가 접근하고자 하는 목적지에 도달할 수 있도록 지원하는 프로토콜(SSL 핸드쉐이크 초기화 과정에서 진행)
• ALB & NLB & Cloudfront에서 사용할 수 있음
• CLB에서는 동작하지 않음
• 클라이언트의 최초 요청 도메인 정보를 서버까지 전달하여 식별하게 하는 역할이며 TLS 안에 해당 내용이 담겨있음

---

ELB 서비스별 SSL 인증

 

CLB

• SSL 인증만 지원
• 여러 개 호스트 네임을 사용하려면 여러 개 CLB를 사용해야 함 (인증서도 여러 개 필요)
• 레거시 서비스로 불편한 요소가 많아 사용을 지양하는 추세

ALB & NLB

• SNI를 통해 여러 개의 리스너와 인증서를 사용할 수 있음

---

Connection Draining

• 인스턴스가 정지되거나 비정상(Unhealthy) 상태일 때 연결된 요청을 종료하는 방식을 의미함
• 중지되거나 비정상(Unhealthy) 인스턴스에 대해 요청을 중단(등록 해제, de-register)
• 1초에서 3600 초까지 요청이 완료되길 기다립니다(기본은 30초)
• 0초로 설정하면 사용하지 않는 상태
• 요청이 주로 몇 초 이내에 끝나는지 확인하고 적절한 값을 셋팅

---

Auto Scaling Group ELB 적용

Auto Scaling Group - 속성

• 런치 템플릿 (launch template)
  • AMI / 인스턴스 타입
  • EC2 user data
  • EBS Volume
  • 보안 그룹(Security Group)
  • SSH key pair
  • IAM Role네트워크 / 서브넷 정보
• 최소 / 최대 / 초기 사이즈
• 스케일링 정책

Auto Scaling Group - Cloud Watch 알람과 스케일링

• Cloud Watch의 알람을 기반으로 스케일링을 진행할 수 있음
• 알람은 메트릭 지표를 기반으로 설정됨
• 메트릭은 Auto Scaling group 내부의 인스턴스들 전체를 통틀어서 보게 됨
• Scale out / Scale in 모두 가능

Auto Scaling Group - 동적 조정 정책 (Dynamic Scaling)

• 목표 추적 조정
• AmAZon CloudWatch 지표와 목표 값을 기반으로 그룹의 현재 용량을 늘리거나 줄
• 단계별 조정(Step scaling) & 단순 조정(Simple scaling)
• 특정 지표 수준을 기반으로 인스턴스를 추가하거나 제거함
• Cloud Watch 알람이 CPU > 60%일 때 2개 인스턴스를 추가
• Cloud Watch 알람이 CPU < 30%일 때 1개 인스턴스를 제거

Auto Scaling Group - 동적 조정 정책 (Dynamic Scaling)

• 일정에 따른 조정
• 주기적으로 필요로 하는 리소스 양이 달라질 때 사용
• 매일 7시 ~ 11시에 요청이 많다면 6시에 2대를 추가하도록 설정
• 문제가 발생한 후 대응하는 것이 아닌 선제적인 대응이 가능
• 하지만 패턴을 알 수 없다면, 사용하기 쉽지 않음

Auto Scaling Group - 예측 조정 (Predictive Scaling)

• 기존 그래프 파형을 기반으로 인스턴스 수를 조정
• 요청이 적을 때는 적게 / 많은 때는 추가를 하는 방식으로 동작함

주요 메트릭

• CPUUtilization - Auto scaling group 내부의 평균적인 CPU 사용률
• RequestCountPerTarget - 대상 인스턴스 당 요청 수
• Average Nework IO - 네트워크 IO 평균
• Average Memory Usage - 메모리 사용률

---

RDS 와 Aws Aurora

RDS

• Relational Database Service의 약자
• SQL DB 관리형 서비스
• 다양한 DB 엔진 지원 Postgres, MySQL, MariaDB, Oracle, MS Sql
• Aurora (AWS 제공 완전 관리형 DB 서비스)

RDS 사용하는 이유

• OS 패치나 프로비저닝이 자동화 되어 있음
• 특정 시간 단위 백업 / 복구가 지원됨
• 모니터링 대시보드 지원
• 읽기 전용 복제본 을 지원
• 재해복구를 위한 멀티 AZ를 지원
• 관리 화면 제공
• 스케일링 용이성
• EBS를 통한 스토리지 백업 (gp2 또는 io1을 사용)
• 인스턴스에 직접 접근은 불가능 (OS 레벨 변경이 불가능)

RDS 스토리지 Auto Scaling

• RDS 스토리지를 동적으로 증가
• RDS가 용량이 부족함 감지하면 자동으로 용량을 증가
• Maximum Storage Threshold를 설정해야 함
• DB의 최대 스토리지 용량을 설정하는 액션
• 예측이 어려운 워크로드에 유용함
• 모든 종류의 RDS DB 엔진을 지원

RDS 읽기 복제본과 읽기 스케일링

• 15대의 읽기 복제본을 생성할 수 있음
• 리젼 / AZ 간 생성하거나 동일 AZ에 생성할 수 있음
• 복제는 비동기 방식으로 일어나며, 궁극적 일관성을 가짐(Eventually Consistent)
• 복제본이 승격될 수 있음
• 애플리케이션이 복제본에 연결하려면 Connection String을 업데이트 해줘야 함

RDS 읽기 복제본 사용 시기

• 집계 / 통계 역할을 하는 애플리케이션
• CQRS 구현 시
• 분석용 DB 구현
• 읽기 복제본은 항상 읽기 만 가능
• RDS 읽기 복제본의 AZ 간 네트워크 비용은 따로 발생하지 않음 - 리전 간은 발생하니 주의가 필요

RDS 멀티 AZ 재해복구 (Disaster Recovery)

• 동기화된 복사를 진행함
• 한 개의 DNS를 사용함
• 가용성을 늘리기 위해 사용
• AZ에 문제가 생기거나, 네트워크 / 인스턴스 등에 문제가 생겼을 때를 대비함
• 스케일링을 사용하는 기능은 아님

RDS 하나의 AZ 에서 멀티 AZ로 적용

• 다운타임을 없앰
• 수정 버튼 클릭을 통해 적용할 수 있음
• 내부에서의 동작
  • 스냅샷이 생성
  • 새로운 DB가 새로운 AZ에 스냅샷을 기반으로 복구됨
  • 두 개의 DB 간에 동기화가 이루어짐

RDS 커스텀

• 관리형 Oracle 또는 MSSql을 사용하는 경우 OS와 DB에 대한 커스텀을 지원
• 일반적인 RDS에서 설정할 수 없는 내용을 셋팅할 수 있음
  • OS 또는 DB 설정을 변경할 수 있음
  • 신규 패치를 다운받을 수 있음
  • 관리형 DB에서 지원하는 자체 기능을 수행할 수 있음
  • SSH 또는 SSM 세션 매니저를 통해 인스턴스 접속이 가능
• 자동 모드는 꺼야하며, 스냅샷을 미리 생성하는 것을 권장함

RDS 백업

• 자동화된 백업
  • 매일 전체 DB 스냅샷을 남김
  • 트랜잭션 로그를 5분마다 백업함
  • 가장 오래된 백업부터 5분 전의 백업을 기반으로 복구할 수 있음
  • 1일에서 35일까지의 데이터를 저장함
  • 0으로 설정하면 자동 백업을 진행하지 않음
• 수동 DB 스냅샷
  • 사용자가 직접 실행함
  • 원하는 기간만큼 저장할 수 있음
• DB를 중지하는 대신 스냅샷을 생성하고 복구하는 걸 추천

AWS Aurora

• Aurora는 AWS에서 제공하는 서비스
• Postgres / Mysql 기반 엔진을 제공함
• AWS 클라우드 최적화되어 있음
  • rds mysql 대비 5배 성능 향상
  • rds postgresql 대비 3배 성능 향상
• 15개의 복제본을 생성할 수 있음
• 복제 생성 프로세스가 mysql 보다 빠름
• 고가용성을 위해 설계됨
• 20% 더 비쌈

AWS Aurora - 고가용성과 읽기 스케일링

• 한 개 Aurora 인스턴스가 쓰기 권한을 가짐(마스터 인스턴스)
• 리전 간 복제본 생성을 지원
• 마스터에 문제가 생기면 30초 이내로 복구됨
• 15개까지 읽기 복제본을 제공함
• 데이터를 3개 AZ 간에 복사해서 저장함

AWS Aurora 커스텀 엔드포인트

• 특정 읽기 복제본에 별도 엔드포인트를 할당할 수 있음
• 읽기 엔드포인트는 설정 이후에는 사용하지 않음
• 예를 들어 분석용 읽기 복제본을 사용하는 경우 적용함

AWS Aurora 서버리스

• 사용량에 따라서 자동으로 스케일링 됨
• 간헐적이거나 예측이 어려운 워크로드에 적합함
• 용량에 대한 계획이 불필요
• 초 단위로 비용이 발생함 - 일부 케이스에는 오히려 더 효율적일 수 있음

AWS Aurora Global Aurora

• 리전 간 읽기 복제본을 지원 - 재해 복구 프로세스에 유용
• Aurora Global DB
  • 1개의 주요 리전을 가짐
  • 5개의 부속 리전을 가질 수 있음
  • 1초 이내의 지연시간을 가짐
  • 부속 리전당 16개의 읽기 복제본을 생성할 수 있음
  • 지연시간을 줄이는데 유용
  • 부속리전을 주요 리전으로 승격시키는 RTO(시스템 재가동 시간)는 1분 미만
  • 리전 간 복제본을 생성하는데 1초 미만이 걸림

AWS Aurora 머신러닝

• ML 기반 예측 데이터를 SQL을 통해 추가할 수 있도록 지원
• Aurora와 AWS ML 서비스 간의 안전하고 효율적이며 단순한 통합을 지원
• SageMaker / Comprehend를 지원
• ML 경험이 없더라도 사용할 수 있음

AWS Aurora 백업

• 자동화 백업
  • 1-35일간 데이터를 저장(중지 할 수 없음)
  • 해당 기간 내의 특정 시점을 기반으로 복구할 수 있음
• 수동 백업
  • 사용자가 직접 실행함
  • 원하는 기간만큼 저장할 수 있음

AWS Aurora/RDS 복구

• 스냅샷을 기반으로 새로운 DB를 생성할 수 있음
• S3를 통해 백업하기 - RDS
  • 다른 곳에 있는 DB를 백업함
  • s3에 백업파일을 저장함
  • 저장된 파일을 기반으로 신규 RDS 인스턴스를 시작함
• S3를 통해 백업하기 - Aurora
  • Percona XtraBackup을 통해 DB를 백업함
  • S3에 파일을 저장함
  • 저장한 파일을 기반으로 신규 Aurora 클러스터를 mysql로 시작함

AWS Aurora 클론

• 신규 클러스터를 기존 클러스터를 통해 복제함
• 스냅샷 | 복구 보다 빠릅니다
• Copy-on-Write 프로토콜을 사용함
  • 기존 클러스터와 동일한 볼륨을 사용함
  • 신규 클러스터에 쓰기가 발생하면 별도 스토리지가 할당되고 새로운 데이터를 신규 스토리지에 저장함
• 빠르고 비용 면에서 효율적
• 스테이징 환경을 구성할 때 사용하기 좋습니다

AWS Aurora/RDS 보안

• Database 마스터와 복사본은 AWS KMS를 통해 암호화 됨
• 마스터가 암호화되지 않은 경우 복사본도 암호화가 불가능 함
• 스냅샷 → 암호화를 진행해 복구를 통해 암호화 할 수 있음
• TLS가 기본으로 적용되어 있음 (AWS TLS 루트 인증서를 사용)
• DB 접근에 IAM Role을 사용함
• 보안 그룹을 통해 네트워크 보안을 유지함
• RDS Custom 을 제외하고는 ssh 접근이 불가함
• Audit 로그를 설정하고 Cloud watch 로그에 쌓을 수 있음

AWS RDS 프록시

• RDS를 위한 완전 관리형 프록시
• 애플리케이션들이 DB 커넥션을 공유할 수 있게 함
• 최소한의 커넥션을 유지하고 DB 리소스에 대한 부하를 감소시켜 성능 향상
• 서버리스 / 오토스케일링 / 멀티 AZ 등에서 사용함

AWS RDS 프록시

• RDS와 Aurora의 복구 시간을 66% 단축할 수 있음
• 애플리케이션에서 코드 변경은 불 필요함
• IAM 인증 사용을 강제함
• 자격 증명은 AWS Secrets Manager를 통해 관리함
• RDS Proxy는 퍼블릭으로 접근이 불가능
• 반드시 VPC를 통해 접근해야 함