woongs dogfoot

AWS RDS

• RDS : 관계형 데이터베이스
• AWS RDS : AWS RDS 인스턴스에 DB를 생성할 수 있고, 올려진 DB는 AWS에 의해 관리됨
• RDS Type

1. Postgres
2. MySQL
3. MariaDB
4. Oracle
5. Microsoft SQL Server
6. Aurora
   
   
   

• EC2가 아닌 RDS에 DB서비스를 배포하는 이유

1. DB 프로비저닝과 기본 운영체제 패치가 자동화 되어 있음
2. 지속적으로 백업 생성 -> 특정 시점으로 복원 가능
3. 대시보드에서 성능 모니터링 가능
4. 읽기 전용 복제본을 활용하여 읽기 성능을 개선할 수 있음
5. 재해 복구 목적으로 다중 AZ 설정 가능
6. 수직 확장 및 읽기 전용 복제본 생성을 통한 수평 확장 가능
7. 파일 스토리지는 EBS에 구성 -> RDS와 연결될 Storage를 의미
8. EC2 인스턴스에 DB를 배포할 때 설정할 모든 것들을 AWS에서 제공
   
   
   

• SSH로 접근할 수 없다는 단점이 있음

• RDS는 EC2기반 -> RDS 생성 시, EC2 설정처럼 CPU, RAM 등 스펙을 설정할 수 있음

• RDS는 DB서버이고, 실제 데이터 저장은 EC2의 EBS에 저장됨 (RDS도 EC2 기반이기 때문)

• Connectivity 설정을 이용하면 Security Group 설정이나 VPC 등 세부적인 네트워크 설정을 자동으로 해주기 때문에 별도 설정 필요 없이 EC2와 연결할 수 있음 (EC2 외의 다른 컴퓨터에서 접근할 경우, 세부 네트워크 설정 필요)
  
  
  

• Storage Auto Scaling : DB에 데이터가 많이 쌓이면 공간이 부족해질 수 있는데, RDS가 이를 감지해서 자동으로 스토리지(EBS) 용량을 확장해줌

1. 스토리지(EBS) 용량 확장을 위해 DB 다운이 필요하지 않음
2. 최대 스토리지 임계값을 설정해야 함 (확장 최대값)
3. 남은 공간이 10% 미만이 되면 스토리지를 자동으로 수정
4. 스토리지 부족 상태가 5분 이상 지속되면 스토리지를 자동으로 수정
5. 지난 수정으로부터 6시간이 지났을 경우에 스토리지를 자동으로 수정
6. workload를 예측할 수 없는 application에 유용함
   
   
   

RDS Read Replicas for real scalability (RDS 읽기 전용 복제본)

• 특징

1. 최대 15개까지 생성
2. 동일 가용영역, 여러 가용영역, 여러 Region에 걸쳐 생성될 수 있음
3. Main RDS와 비동기식 복제가 진행됨 -> Main RDS에 write하고 읽기전용 RDS를 읽을 경우, 일관적인 데이터 수집 가능
4. DB로 승격 가능 -> 자체적인 생애 주기를 가짐
   
   
   

• Use Case : 특정 application의 DB에 대한 데이터 분석이 필요한 경우, Main RDS에 직접 접근하여 데이터를 추출하면 application이 느려질 수 있음 -> 읽기전용 Replica를 생성하여 데이터 분석용으로 제공하면 application에 대한 영향도를 없앨 수 있음
  
  
  

• Network Cost

1. 특정 가용영역에서 다른 가용영역으로 데이터가 이동할 때 비용 발생 -> 관리형 서비스는 예외 (RDS 읽기 전용 복제본은 관리형 서비스) -> 다른 가용영역이나 동일 region내에 읽기전용 복제본이 있을 경우, 비용이 발생하지 않음
2. RDS 읽기 전용 복제본이 다른 Region에 존재하는 경우, 네트워크에 대한 데이터 복제 비용 발생
   
   
   

• RDS Multi AZ (Disaster Recovery)

1. Master DB의 모든 변화를 동기적으로 RDS standby 인스턴스에 복제 (RDS standby 인스턴스는 다른 가용영역에 생성)
2. Master DB에 문제가 발생할 때, standby RDS에 자동으로 장애 조치가 수행됨 (standby가 임시적으로 master가 됨) -> 하나의 RDS DNS를 갖고있기 때문에 가능 (RDS DNS는 DB의 엔드포인트가 됨)
3. standby RDS는 오직 장애에 대비한 대기 목적만 수행 (평시에는 사용 불가)
4. standby RDS로 읽기전용 복제본을 생성할 수도 있음

• Single-AZ to Multi-AZ

1. 다운타임이 없음 (DB 중지 필요x)
2. DB 설정에서 Multi-AZ 활성화 시, 다른 가용영역에 Standby DB가 자동으로 생성됨
3. 내부적으로 발생하는 일
   • RDS의 Snapshot 생성
   • 생성된 Snapshot은 새롭게 생성된 Standby DB에 복원됨
   • Main-Standby간 동기화가 설정됨
     
     
     

RDS Custom

• RDS에서는 운영체제 및 데이터베이스 관리자 권한 기능에 접근하지 못함 -> RDS Custom에서는 가능 (Oracle, Microsoft SQL Server)
• SSH 활용 접근
• Custom 기능
  1. Configure Settings
  2. Install Patches
  3. Enable Native Features
     
     
     

Amazon Aurora

• 특징

1. postgres 및 MySQL 호환 (해당 DB의 드라이버만 사용 가능) - Aurora MySQL, Aurora P ostgreSQL
2. AWS 고유 기능
3. 클라우도 최적화 (MySQL보다 5배 높은 성능, Postgres보다 3배 높은 성능)
4. Storage 자동 확장 (10GB, up to 120TB)
5. 기본적으로 클라우드 네이티브 환경이므로 빠른 장애 조치 (its HA native)
6. 비용은 RDS에 비해 20% 높음
7. BackTrack : 특정 시점으로 데이터 복원하는 기능 (백업에 의존하지 않고 다른 기능 활용)
   
   
   

• High Availability

1. 3개 가용영역에 걸쳐 6개의 데이터 사본 저장 (AZ하나가 비정상이어도 괜찮음)
2. 일부 데이터에 문제가 있을 경우, P2P 복제를 통한 자가복구 과정이 있음
3. 단일 볼륨이 아닌 수백 개의 볼륨을 활용 (AWS에서 관리)
4. RDS의 multi-AZ와 유사
5. master DB가 작동하지 않으면 30초 이내로 자동 장애복구 진행 (작은 블록 단위로 자가복구, master DB 변경 등)
6. master DB에 문제가 생기면 읽기 전용 DB중 하나가 master가 될 수 있음
7. region간 복제 지원
8. 읽기 전용 복제본은 15개까지 가능, 복제 속도도 상대적으로 빠름 (MySQL은 5개까지)

• Aurora DB Cluster

1. master가 바뀌거나 장애조치를 대비하여 writer Endpoint 제공 (DNS로 항상 master를 가리킴)
2. 읽기 전용 DB의 자동 Scaling이 진행됨 (적절한 인스턴스 수 유지, CPU사용량/인스턴스 평균 연결 수 기반)
3. Reader Endpoint (인스턴스 전용 Endpoint와 다른 개념)
   • connection load balancing : 모든 읽기전용 인스턴스와 자동 연결
   • client가 Reader Endpoint로 요청 시, 다중 읽기전용 인스턴스 중 하나로 자동 연결
   • load balancing은 connection 레벨에서 진행됨
4. 크기가 큰 global Aurora 인스턴스인 경우, Aurora Cluster내에 다른 region을 추가할 수 있음

• Aurora Auto Scaling

• Custom Endpoints
  : db.r3.large, db.r5.2xlarge 두 종류의 읽기전용 Aurora 존재 -> Aurora 인스턴스 일부를 Custom Endpoint로 정의 -> Custom Endpoint에는 성능이 더 좋은 db.r5.2xlarge 인스턴스를 연결하여 application 단에서 해당 Custom Endpoint에는 많은 연산이 필요한 쿼리를 날릴 수 있도록 할 수 있음 -> custom endpoint를 만들기 시작하면 reader endpoint를 사용할 것이 아닌 남은 인스턴스를 연결한 Custom Endpoint를 생성해줘야 함.

• Serverless (다시 봐야함)
  : 간헐적이고 예측 불가능한 업무량에 대응 -> capacity planning 불필요 -> 초당 비용을 지불하는 것이 효율적

• Global Aurora

1. 리전간 읽기전용 복제 가능 (읽기/쓰기 가능 primary region, 최대 5개 읽기 전용 secondary region, 보조 region당 최대 16개 읽기 전용 인스턴스) -> global한 읽기 요청에 대한 응답 지연 감소에 도움됨
2. 특정 region에 장애가 생겼을 경우, 다른 region으로 primary region전환 재해복구 (복구시간 1분 이내)
3. 특정 region에서 다른 region으로 데이터 복제 시, 1초 이하의 시간 소요

• Aurora Machine Learning
  : Aurora활용 Machine Learning 예측 기능을 application에 추가할 수 있음
  
  
  

1. Supported Service
   • SageMaker : 어떤 종류의 기계학습 모델이라도 사용할 수 있게 해줌
   • Comprehend : 감정 분석
2. Use case
   • 이상행위 탐지
   • 광고 타겟팅
   • 감정 분석
   • 상품 추천
   • etc...

RDS Backups

• 매일 자동으로 백업 수행 (during backup window)
• 5분마다 트랜잭션 로그 백업
• 백업 보존기간은 0~35일 사이로 설정 가능
• 수동 DB Snapshots => 원하는 기간동안 백업 유지 => 비용절감으로 사용할 수 있음 (ex. 한달에 두시간만 사용하는 DB를 Snapshot으로 백업해 둔 후, 원본 DB는 완전히 내려서 비용 절감)
  
  
  

Aurora Backups

• 자동화된 백업 (1~35일) => 비활성화 불가
• 해당 기간의 어느 시점으로든 백업 가능
• 수동 DB Snapshot은 RDS Backups과 동일
  
  
  

RDS/Aurora Restore Options

• 자동화된 백업이나 수동 snapshot으로 DB 복원 가능
• S3에서 MySQL로 복원 가능 (ex. 온프레미스의 DB를 S3에 백업 -> S3에서 RDS로 DB 복원 -> 온프레미스에서 RDS이동 가능)
• 온프레미스->Aurora로 복원을 위해서는 외부적으로 Percona XtraBackup 소프트웨어 사용 필요 -> 해당 소프트웨어로 온프레미스 DB의 백업파일을 S3로 보낼 수 있음
  
  
  

Aurora DB Cloning

• 기존 DB cluster -> 새로운 Aurora DB cluster 생성 가능
• Use case : 운영환경의 데이터로 테스트를 진행하고 싶을 때 활용 가능 (운영환경 데이터를 개발환경 DB에 이동) -> 운영환경 Aurora DB 복제 (Snapshot 생성 후, 복원하는 것보다 훨씬 빠름 -> copy-on-write 프로토콜 사용하기 때문)
• 일반 DB 복제는 원본과 복사본이 같은 스토리지를 공유 -> Aurora DB Cloning은 스토리지까지 복제하는데 RDS에 비해 빠르기까지 함
  
  
  

RDS Security

• DB가 처음 실행될 때, 원본과 복사본이 AWS KMS를 활용하여 모두 암호화됨
• 원본 DB가 암호화되지 않았다면, 복사본도 암호화할 수 없음
• 암호화 type
  1. in-flight encryption : TLS 인증서 필요, client와 DB간의 전송 중 데이터 암호화
  2. IAM Authentication : username/password 대신에 IAM Role을 활용하여 DB에 접근할 수 있음
  3. Security Groups : DB에 대한 네트워크 접근 통제 가능 (방화벽과 유사)
  4. RDS/Aurora에 SSH 접근 불가 (AWS에서 관리하기 때문, RDS 커스텀 서비스를 사용한다면 예외)
  5. 감사 log : 시간에 따라 어떤 쿼리가 생성되고 있는지 확인 가능 (로그의 장기간 보관을 위해서는 CloudWatch 서비스 활용 필요)
     
     
     

RDS Proxy

• 완전 관리형 RDS DB Proxy 배포 가능
• Why proxy?
  1. application이 DB내에서 connection pool을 생성하고 타 app과 공유할 수 있음 (proxy가 하나의 pool에 연결을 모음) -> RDS로의 직접 연결을 줄일 수 있음 -> 연결이 많은 경우 CPU, RAM과 같은 컴퓨팅 리소스에 부담이 생길 수 있음
  2. DB로의 private 접근
  3. DB timeout 최소화
• RDS Proxy는 완전히 서버리스
• Auto Scaling이 가능하여 용량 관리가 불필요하고 가용성이 높음 (multi-AZ)
• 장애 조치 시간을 최대 66%까지 줄일 수 있음 (How?) -> main RDS 인스턴스에 app들 을 모두 연결하고 장애조치를 모두 처리하게 하는 것이 아닌, 장애 조치에 무관한 app들은 proxy에 연결 -> app코드를 모두 수정하지 않아도 되고, 장애조치가 끝난 후 proxy에 연결만 하면 되어서 장애조치 시간이 감소됨
• EC2 인스턴스간 connection pool을 공유하기 때문에 연결 시간을 아낄 수 있음
• MySQL, PostgreSQL, MariaDB용 RDS/MySQL, PostgreSQL용 Aurora 지원
• DB에 IAM 인증을 강제함 -> IAM인증을 통해서만 DB 인스턴스에 접근할 수 있음
• RDS Proxy는 public에서 접근할 수 없음 (VPC내에서만 접근 가능)
• Lambda Functions : RDS Proxy와 사용하기 좋음 (Lambda는 여러 개가 생성되고 사라지는 속도가 매우 빠름 -> RDS 인스턴스에 직접 접근하면 연결에 timeout 발생 가능성이 높아짐) -> Lambda Function이 RDS Proxy를 overload함 -> RDS 인스턴스로의 직접 연결이 줄어듦
  
  
  

ElasticCache

• RDS가 관계형 DB를 관리하는 방식과 동일

• 캐싱기술인 Redis나 Memcached를 관리

• 캐시를 이용하면 매번 DB에 접근하지 않아도 빠른 데이터 조회 가능

• application의 상태 또한 저장하여 관리할 수 있음

• AWS가 서비스를 관리 (OS패치, 최적화, 설정, 구성, 모니터링, 장애복구, 백업 등)

• 캐싱서비스 사용 = application 코드 변경 (DB가 아닌 캐시를 쿼리하도록)

• 캐시 무효화전략(=캐시삭제) 필요 (가장 최신 데이터만 사용되어야 하기 때문)
  
  
  

• Architecture

1. application -> cache에 사전 쿼리 이력이 있는지 확인 (있다면 cache hit라고 부름)
2. 쿼리 이력이 있다면(cache hit), 쿼리에 대한 응답을 캐시저장소로부터 받아옴
3. 쿼리 이력이 없다면(cache miss), DB에 쿼리를 날려 데이터를 가져옴
4. 해당 쿼리와 응답을 캐시저장소에 저장

• 사용자 세션(상태) 저장 Architecture

1. 사용자가 어떤 application에 로그인하면, application은 세션데이터를 캐시저장소에 write
2. 사용자가 app의 다른 인스턴스로 redirect되면, 해당 app은 요청 사용자에 맞는 세션데이터를 캐시저장소로부터 조회해 옴 (사용자 로그인 유지) => app이 직접 세션을 저장할 필요가 없기 때문에 상태 비저장 app 구현 가능
   
   
   

• Redis vs Memcached

1. Redis (장점, 데이터 내구성/가용성)
   • 자동 장애 조치 기능이 있는 Multi-AZ
   • 읽기 복제본 가능 (RDS와 매우 유사)
   • AOF(?)를 이용한 데이터 지속성
   • 백업 및 복원 기능
   • keyword : set, sorted set 지원(?)
2. Memcached (분산되어 있는 순수 캐시)
   • 데이터 분할(paritioning)을 위해 멀티 노드 활용 (sharding)
   • 고가용성x, 복제x, 영구 캐시x
   • 백업x, 복원x
   • 멀티스레드 아키텍처
     
     
     

Cache Security

1. Redis

• Redis만 IAM 인증 지원 (나머지는 username/password)
• Redis AUTH : Redis 인증을 위한 password와 token 생성 -> 캐시에 추가 보안 제공, Redis 보안그룹에 해당 pwd와 토큰을 인증해야 함
• SSL 전송중 암호화 지원
  
  
  

2. Memcached

• SASL 기반 인증 제공
  
  
  

ElasticCache 패턴

1. Lazy Loading : 모든 read 데이터 캐싱 -> 조회 지연 발생
2. Write Through : DB에 데이터가 기록될 때마다 캐시에 데이터를 추가하거나 업데이트
3. Session Store : 세션 유지시간을 사용하여 만료 시 캐시 데이터 삭제
   
   
   

• Redis Use Case : Gaming Leader Board (아래 기능 활용)
• Redis Sorted Sets : 고유성과 순서를 보장 (요소가 추가될 때마다 실시간으로 순위를 매김)

Auto Scaling Group (ASG)

• Auto Scaling Group (ASG) : 트래픽의 변동에 따라 자동으로 AWS API를 호출하여 EC2 인스턴스를 늘리거나 줄여주는 기능 (자동 Scale out/in)
  
  
  

• 특징

1. 매개변수를 통해 EC2 인스턴스의 최대/최소/희망 갯수를 조절할 수 있음
2. ASG를 Load Balancer와 연결할 경우, ASG내의 인스턴스가 추가될 때 자동으로 Load Balancer와 연결됨
3. ASG내 특정 인스턴스의 상태가 비정상일 경우, 해당 인스턴스를 종료하고 새로운 인스턴스를 생성함 (희망갯수 유지)
4. ASG is free
5. scale out/in 시, 희망갯수는 최대/최소 갯수 내에서 설정됨
6. ELB가 비정상이라고 판단하는 인스턴스가 ASG내에 있을 경우, ASG는 해당 인스턴스를 자동으로 종료하고 새로운 인스턴스를 생성
7. Launch Template : EC2 인스턴스를 시작하는 방법에 대한 정보가 포함되어 있음
   • AMI
   • Instance Type
   • EC2 User Data
   • EBS Volumes
   • Security Groups
   • SSH key pair
   • IAM Roles for your EC2 Instances
   • Network + Subnets Information
   • Load Balancer Information
   • etc...
8. Scaling 정책 정의 필요
   • CloudWatch : 모니터링 지표(metric, CPU사용량 등)을 기반으로 Alarm을 울리는 기능 -> CloudWatch Alarm 기반으로 scale out/in을 수행할 수 있음 -> Alarm기반 Scaling 정책
     
     
     

• Capacity

• Load Balancer + ASG is good

• Dynamic Scaling Policies

1. Target Tracking Scaling
   • CloudWatch를 생성할 수 있음
   • case : EC2 인스턴스의 CPU사용량을 추적하여 수치가 40%에 머무를 수 있도록 조정 (기준치 설정 필요)
2. Simple/Step Scaling
   • 기생성된 CloudWatch 활용
   • case 1 : CloudWatch Alarm을 설정하고 전체 ASG의 CPU사용량이 70%를 초과하는 경우, 인스턴스 두개 추가
   • case 2 : CloudWatch Alarm을 설정하고 전체 ASG의 CPU사용량이 30%를 미달하는 경우, 인스턴스 한개 삭제
   • CloudWatch 설정 시, 인스턴스를 몇개 추가하고 삭제할 것인지에 대한 설정 필요
   • Step Scaling : 다수의 경보 값을 기준으로 여러 Scaling Step을 진행하도록 할 수 있음
     
     
     

• Scheduled Actions

  • 사용자 트래픽 증감의 예측이 가능할 때
  • case : 금요일 오후 5시에 큰 이벤트가 예정되어 있으니 많은 사람들의 사용을 대비하여 ASG의 최소용량을 매주 금요일 오후 5시마다 자동으로 10으로 늘려줌 -> Scaling 작업을 예약
    
    
    

• Predictive Scaling

  • AWS내 Auto Scaling 서비스를 활용하여 지속적으로 트래픽 이력을 생성
  • 머신러닝 기반
  • 생성된 트래픽 이력을 보고 다음 트래픽을 예측하여 Scaling 진행 -> 자동 Scaling 작업 예약
    
    
    

• Scaling을 위한 Metics

1. CPU 사용량
2. 타겟당 요청 수 (Request Count per Target)
3. 평균 네트워크 입출력량 (Average Network In/Out) -> 네트워크에 연결되어 있는 상태에서 네트워크 병목을 방지를 위함
4. Any Custom Metrics (CloudWatch 활용)
   
   
   

• Request Count per Target

• Scaling Cooldown : 스케일링 작업이 끝날 때마다 기본적으로 5분 or 300초의 Cooldown 시간을 갖는 기능

1. 인스턴스의 안정적인 생성과 새롭게 기록되는 지표(metric)들의 양상을 정확하게 확인하기 위함
2. Cooldown 시간 동안에는 ASG가 인스턴스를 생성하거나 종료시킬 수 없음
3. 인스턴스 구성 시간을 단축시킬 수 있는 AMI를 활용하여 인스턴스를 보다 빠르게 생성하여 요청을 받을 수 있는 상태로 만드는 것이 좋음 -> 별도 cooldown 시간을 단축시킬 수 있음 -> ASG상의 더 많은 Scaling 작업을 진행할 수 있음
   
   
   

• stress amazone linux2 설치를 통해 임의로 인스턴스의 CPU사용량을 늘릴 수 있음

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 시간을 낮게 설정하는 것이 유리 (빨리 중지시키고 빨리 교체)

EBS (Elastic Block Store)

• EBS : 인스턴스가 실행중일 때 연결 가능한 네트워크 드라이브 (like network "USB", 실제 물리적인 연결은 없지만 네트워크를 통해 연결)
  
  
  

• 특징

1. 인스턴스가 종료되어도 데이터를 유지시킬 수 있다. (EC2 인스턴스 부팅 후, EBS Volume 마운트하면 재사용 가능)
2. CCP 레벨에서는 한 개 EBS에 하나의 인스턴스만 마운트할 수 있다. (한 개 인스턴스에는 여러개 EBS 마운트 가능, 어소시에이트 레벨에서는 EBS 다중연결 가능)
3. 동일 가용영역의 인스턴스만만 마운트 가능하다.
4. 네트워크가 필요하다. (EC2 인스턴스에서 다른 EC2 인스턴스로 옮겨 마운트될 수 있음. but, 네트워크 지연이 발생할 수 있음)
5. 스냅샷이라는 기능을 활용하면 다른 가용영역으로 EBS Volume을 옮길 수 있다.
6. 용량 및 성능을 미리 정해야 한다. (용량 및 성능에 따라 비용 청구)
7. EC2 인스턴스를 생성할 때 EBS도 동시에 생성하는 경우, EC2 인스턴스 종료 시에 EBS도 삭제될 수 있는 옵션이 있다. (default는 삭제)
   
   
   

• EBS Snapshots : EBS Volume의 특정 시점에 대한 백업 -> 다른 AZ나 Region에 복사할 수 있음 (Copy Snapshot)
• 기능

1. EBS Snapshot Archive : Standard teer에 비해 75% 저렴한 EBS 스냅샷 저장소 (Archive teer), 아카이브에서 복원 시 24시간에서 최대 72시간까지 소요됨
2. EBS Snapshot 휴지통 : EBS 스냅샷 휴지통, EBS 스냅샷을 삭제하는 경우에 영구 삭제되지 않고 휴지통으로 이동됨. (실수방지)
   • Regention Rule 생성을 통해 휴지통 보관 설정을 진행할 수 있음
3. Fast Snapshot Restore (FSR) : 빠른 스냅샷 복원, 스냅샷의 완전한 초기화를 통해 사용 시의 지연시간을 없앰 -> 고비용 수반

AMI (Amazone Machine Image)

• AMI : EC2 인스턴스를 통해 만든 image, 커스터마이징 가능 (like docker image)
  
  
  

• 특징

1. AMI를 이용하면 부팅을 위한 소프트웨어들이 모두 패키징(설치시간 단축)되어 있기 때문에 EC2 인스턴스의 부팅시간을 줄여줄 수 있음
2. 특정 지역에서 만든 AMI를 다른 지역에서 활용하여 EC2 인스턴스를 생성할 수 있음 (AMI를 복사해서 다른 region으로 옮겨야 함)
3. AWS 마켓플레이스에서 다른 커스터마이징 AMI를 구할 수 있음 (public AMI : AWS에서 제공)
   
   
   

• AMI 생성순서

1. EC2 인스턴스 생성
2. EC2 인스턴스 중지
3. AMI 생성
   • EBS Snapshot 생성

EC2 Instance Store

• EC2 Instance Store : EC2 Instance와 연결될 Volume이 동일 하드웨어 서버에 위치한 Volume
• Network Driver를 통해 연결된 EBS Volume 보다 더 높은 network 성능을 요구할 수도 있음 -> EC2 Instance Store 활용 필요
• EC2 Instance Store가 중지되면 데이터 또한 손실됨 -> 장기적으로 저장할 용도의 저장소는 안됨
• Use Case : Buffer, Cache, Temporary Contents 등
• 필요에 따라 데이터를 백업하거나 복제해야 함.
  
  
  

EBS Volume Types

• IOPS : I/O Ops per Sec, 초당 I/O 작업 수, 높을 수록 파일을 읽고 쓰는게 빨라짐
  
  
  

1. gp2/gp3 (SSD) : 가격과 성능이 적절한 균형을 이룸

   • gp2/gp3 : 범용 SSD
   • 저지연/비용효율적
   • System boot volumes, 가상 데스크톱, 개발, 테스트 환경으로 활용
   • 1GiB ~ 16TiB
   • gp3 : gp2에 비해 최신 세대의 volume, 기본설정 3000IOPS/초당 125MB의 처리량
   • gp3 : 최대 IOPS16,000/초당 1,000MB의 처리량, volume size와 IOPS는 독립적
   • gp2 : gp3에 비해 small size, 최대 3,000 IOPS
   • gp2 : volume size와 IOPS는 서로 연결되어 있고 3 IOPS per GB
   • gp2 : 최대 IOPS는 16,000이고 3 IOPS per GB라서 volume size가 5,334GB일 경우 최대치인 16,000 IOPS를 넘게됨
     
     
     

2. io1/io2 (SSD) : 높은 성능의 SSD Volume, 지연 시간이 낮고 대용량의 workload에 쓰임

   • io1/io2 : Provisioned IOPS SSD
   • boot volume 활용 o
   • 4GiB ~ 16TiB
   • IOPS 성능 유지가 필요할 때 활용
   • 16,000 IOPS 이상을 요구하는 application에 활용
   • 스토리지 성능과 일관성에 민감한 Database workload에 적합
   • Nitro EC2에서는 최대 64,000IOPS까지 가능, 아닌 경우 최대 32,000IOPS까지 가능
   • gp3의 경우처럼 IOPS를 스토리지 크기와 독립적으로 증가시킬 수 있음
   • io2 : io1과 동일한 비용으로 내구성과 기기당 IOPS수가 더 높음 (io2 > io1 합리적)
   • io2 block express (4GiB ~ 64TiB) : 좀 더 고성능의 Volume, ms미만의 지연시간, IOPS : GB = 1000 : 1 일 때 최대 256,000 IOPS
     
     
     

3. st1 (HDD) : 저비용의 HDD Volume, 잦은 접근과 처리량이 많은 workload에 쓰임

   • boot volume 활용 x
   • 125MiB ~ 16TiB
   • 처리량 최적화 HDD, 최대처리량 500MiB/s, 최대 IOPS : 500
   • Big Data, Data Warehouse, Log처리 등에 적합
     
     
     

4. sc1 (HDD) : 가장 적은 비용의 HDD Volume, 접근 빈도가 낮은 workload에 쓰임

   • cold HDD
   • 아카이브 데이터 용도, 접근 빈도가 낮은 데이터에 적합
   • 최저비용으로 데이터를 저장할 떄 사용
   • 최대처리량 250MB, 최대 IOPS 250
     
     
     

• EBS Volume의 유형은 크기/처리량/IOPS(I/O Ops per Sec, 초당 I/O 작업 수)에 따라 결정됨
• EC2 인스턴스(root OS 실행)의 Boot Volume으로는 gp2/gp3 유형과 io1/io2 유형만 활용 가능
• EBS Volume Types 정리 : https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html
  
  
  

EBS Multi-Attach

• EBS Multi-Attach : 동일 가용영역 내에서 하나의 EBS에 여러 EC2 인스턴스를 연결하는 기능 (io1/io2 volume 한정)
• 모든 EC2 인스턴스는 읽기/쓰기 권한을 모두 가짐
• EC2 인스턴스 간에 동시쓰기 작업 등의 case에서 활용됨
• 최대 16개의 EC2 인스턴스 제한
• cluster-aware file system을 활용해야 함 (not XFS, EX4)
  
  
  

EBS Encyption

• EBS Volume 암호화 유형

1. volume 내부의 데이터 암호화
2. 인스턴스-volume간 데이터통신 암호화
3. volume의 snapshot 암호화
4. snapshot으로 생성한 volume 암호화
   
   
   

• 특징

1. 암호화는 EC2와 EBS의 백그라운드에서 알아서 처리됨
2. 지연시간에는 거의 영향이 없음
3. KMS에서 암호화 키를 생성
4. 암호화되지 않은 EBS에서 생성된 snapshot은 암호화되지 않음
   
   
   

• 암호화되지 않고 생성된 EBS 암호화 방법 - 1

1. EBS snapshot 생성
2. 복사 기능을 통해 EBS snapshot 암호화 (Actions - Copy snapshot)
3. EBS snapshot을 이용해 volume을 생성하면, 해당 volume도 암호화
4. 암호화된 volume을 원래의 EC2 인스턴스에 연결
   
   
   

• 암호화되지 않고 생성된 EBS 암호화 방법 - 2

1. EBS snapshot 생성
2. Create volume from snapshot
3. 암호화 체크 후 생성
   
   
   

EFS (Elastic File System)

• EFS : 관리형 NFS protocol, 네트워크 파일 시스템
  
  
  

• 특징

1. 많은 인스턴스에 마운트될 수 있음
2. 마운트된 인스턴스는 서로 다른 가용영역에 존재할 수 있음 (EFS의 강점)
3. 가용성 및 확장성이 좋으나 비용이 비쌈 (GP2 EBS의 약 3배)
4. 사용량에 따라 비용을 지불함 (미리 용량을 정하지 않음, 용량이 자동으로 확장됨, EFS의 강점)
5. 엑세스 제어를 위해 보안그룹을 활용함
6. linux기반 AMI만 호환됨
7. KMS를 활용하여 암호화를 활성화시킬 수 있음
8. linux 표준 파일시스템(POSIX) 활용
9. EC2에서 EFS설정 시, EFS와의 연결을 위해 자동으로 보안그룹(Security Group)을 생성하여 EFS에 연결함
   
   
   

• 성능

1. scale : 수천개의 클라이언트와 10GB이상의 처리량 확보, PetaByte 규모로 자동 확장
2. performance mode
   • general purpose(default) : 지연 시간에 민감한 case에서 활용됨 (ex. 웹서버, CMS 등)
   • Max I/O : 처리량 최대화 -> 처리량이 높고 병렬성이 좋음 (ex. 빅데이터 처리, 미디어 처리 등)
3. Throughput Mode
   • Bursting : 1TB, 초당 50MiB~100MiB 을 더한 것 (스토리지가 늘어날 수록 처리량 증가)
   • Provisioned : 스토리지 크기에 상관 없이 처리량 설정 (1TB 스토리지에서 초당 1GiB를 처리)
   • Elastic : workload에 따라 처리량을 자동 조절, workload를 예측하기 어려울 때 유용
     
     
     

• Storage classes

1. Storage Tiers : 며칠 후(수명주기) 파일을 다른계층으로 자동으로 옮김 (ex. 표준계층은 자주 사용하는 파일을 위한 계층이고, EFS-1A는 자주 사용하지 않는 파일을 위한 계층인데, EFS-1A 계층에서는 파일 검색이 오래걸림, 하지만 비용 감소)
2. 가용성과 내구성
   • 다중 가용영역으로 EFS를 설정할 수 있음 (가용성, prd환경에 적합)
   • One-Zone EFS (EFS One Zone-IA) : 하나의 가용영역, 백업 활성화, 엑세스 빈도가 낮은 Storage Tier와 호환 -> 비용할인이 많이 됨

• use case

1. 콘텐츠 관리
2. 웹 서버
3. 데이터 공유
4. wordpress
   
   
   

EBS vs EFS