[AWS] 서비스 개념 정리 (2)

✅ AWS RDS란 ?

• 아마존 관계형 데이터베이스 서비스(Amazon Relational Database Service)는 아마존 웹 서비스(AWS)가 서비스하는 분산 관계형 데이터베이스이다. 
• 애플리케이션 내에서 관계형 데이터베이스의 설정, 운영, 스케일링을 단순케 하도록 설계된 클라우드 내에서 동작하는 웹 서비스이다.
• 데이터베이스 소프트웨어를 패치하거나 데이터베이스를 백업하거나 시점 복구를 활성화하는 것과 같은 복잡한 관리 프로세스들은 자동으로 관리된다.
• 스토리지와 연산 자원들을 스케일링하는 것은 하나의 API 호출로 수행할 수 있다.

 

✅ RDS의 기능

• DB Back-ups
  • Automation Backups (자동 백업)
    줄여서 AB는 Retention Period(1~35일) 안의 어떤 시간으로 돌아가게 할 수 있다. AB는 그날 생성된 스냅샷과 Transaction logs(TL)을 참고하며, RDS에서 디폴트로 AB 기능이 설정되어 있다. 백업 정보는 S3에 저장되며 AB동안 약간의 I/O suspension이 존재할 수 있다. 하지만 AB가 끝나면 suspension은 사라진다.
  • DB Snapshots (데이터베이스 스냅샷)
    • 이 기능은 사용자에 의해 수동적으로 진행된다. 만약 원본 RDS를 삭제한다고 하더라도, 스냅샷은 S3 버킷에 존재합니다. 따라서 스냅샷만으로 RDS 인스턴스를 복원시킬 수 있다. 스냅샷 기능과는 반대로 AB 백업 기능은 인스턴스를 삭제할 때 스냅샷이 모두 없어진다는 특징이 있다.
• Read Replicas
  데이터베이스의 읽기, 쓰기 작업 중 쓰기 작업은 저장된 데이터가 변경되기 때문에 복제된 서버들 간에 동일한 형태를 유지하는 것이 어렵다. 그래서 보통 한대의 서버에만 쓰기 작업을 하고 그 서버의 데이터를 복제해서 여러 대의 슬레이브 서버를 만든 후에 슬레이브에서는 읽기 작업만을 수행한다. Read Replicas란 이런 작업을 RDS에서 하게 해주는 서비스이다.
  즉, Read Replica는 RDS DB 인스턴스의 읽기 전용 인스턴스이다.
  서비스에서 읽기 위주의 작업이 많은 경우 Read Replica를 여러 개 만들어서 부하를 분산할 수 있다. 즉, 쓰기 작업은 마스터 DB 인스턴스에 하고 읽기 작업은 Read Replica에 할당하면 마스터 DB 인스턴스의 부하를 줄일 수 있다. 만약 마스터 DB 인스턴스에 쓰기를 하면 자동으로 Read Replica DB 인스턴스로 데이터가 복제된다. 단, 즉시 복제되는 것은 아니며 약간의 시간차가 있다.
  
  
• 다중 AZ 배포
  다중 AZ 배포는 RDS 데이터베이스(DB) 인스턴스를 위해 향상된 가용성 및 내구성을 제공하므로, 프로덕션 데이터베이스 워크로드에 적합하다.
  다중 AZ DB 인스턴스를 프로비저닝하면 Amazon RDS는 자동으로 하나의 기본 DB 인스턴스를 생성하고 동시에 다른 가용 영역(AZ)의 예비 인스턴스에 데이터를 복제한다.
  각 AZ는 물리적으로 분리된 자체 독립 인프라에서 실행되며 높은 안정성을 제공하도록 설계되었다.
  인프라 장애가 발생하더라도 Amazon RDS가 예비 인스턴스(또는 Amazon Aurora의 경우 읽기 전용 복제본)로 자동 장애 조치를 수행하여 장애 조치 완료 후 데이터베이스 작업을 바로 재개할 수 있다.
  장애 조치 후에도 DB 인스턴스의 엔드포인트는 그대로 유지되므로 관리자가 직접 개입할 필요 없이 애플리케이션에서 데이터베이스 작업을 재개할 수 있다.
  장애 조치 시, Amazon RDS는 DB 인스턴스의 정식 이름 레코드(CNAME)가 예비 복제본을 가리키도록 변경한다.
  그러면 이 예비 복제본이 승격되어 새 기본 복제본이 된다.

---

✅ CloudFront란 ?

• .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹콘텐츠를 사용자게에 더 빨리 배포하도록 지원하는 웹서비스
• 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공한다. 
• CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능으로 콘텐츠가 제공된다.
  • 콘텐츠가 이미 지연 시간이 가장 낮은 엣지 로케이션에 있는 경우 CloudFront가 콘텐츠를 즉시 제공
     
  • 콘텐츠가 엣지 로케이션에 없는 경우 CloudFront는 콘텐츠의 최종 버전에 대한 소스로 지정된 오리진(Amazon S3 버킷, MediaPackage 채널, HTTP 서버(예: 웹 서버) 등)에서 콘텐츠를 검색합니다.

 

✅ CloudFront 용어

• Origin Server : 원본 데이터를 가지고 있는 서버이다. 보통 AWS에서의 Origin Server는 S3, EC2 인스턴스이다.
• Edge Server = Edge Location : AWS에서 실질적으로 제공하는 전 세계에 퍼져있는 서버이다. Edge Server에서는 요청받은 데이터에 대해서 같은 요청에 대해 빠르게 응답해주기 위해 Cache 기능을 제공

 

✅ Lambda@Edge

• CloudFront의 기능 중 하나로서 어플리케이션의 사용자에게 더 가까운 위치에서 코드를 실행시켜 성능을 개선하고 지연 시간을 단축할 수 있게 해준다. 
• Lambda@Edge를 사용하면 전 세계 여러 위치에 있는 인프라를 프로비저닝 하거나 관리하지 않아도 된다.
• CloudFront 콘텐츠 전송 네트워크 (CDN)에 의해 생성된 이벤트에 대한 응답으로 코드를 실행한다.
• 코드를 업로드하기만 하면 AWS Lambda가 최종 사용자와 가장 가까운 AWS 로케이션에서 작업을 처리한다.

---

✅ 엣지 로케이션(Edge Location)

• AWS의 CDN(Content Delivery Network) 제품인 CloudFront의 캐싱 컨텐츠가 위치하는 곳이다.
• CDN은 인터넷 상에 콘텐츠를 캐싱하여 좀 더 빠르게 사용자에게 전달할 수 있다.
  • CDN (Content Delivery Network)이란 ? 
    콘텐츠를 효율적으로 전달하기위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템
    인터넷 서비스 제공자(ISP)에 직접 연결되어 데이터를 전송하므로, 콘텐츠 병목을 피할 수 있는 장점이 있다.
• CDN 엣지가 사용자 근처에 있을수록 더욱 빠른 전달을 받을 수가 있기 때문에 리전과 별도로 엣지 로케이션은 더 많이 전세계 주요 도시 곳곳에 분포되어 있다.
• 엣지 로케이션의 경우 CloudFront만을 위한 공간이다. 그리고 서버리스 서비스 중 람다를 보다 사용자 근접에서 실행하여 성능을 개선하고 지연 시간을 단축하는 경우에도 엣지 로케이션이 이용된다.

---

✅ AWS Aurora란?

• Amazon Aurora(이하 Aurora)는 MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진
• 기존 애플리케이션을 거의 변경하지 않고도 MySQL의 처리량을 최대 5배, PostgreSQL의 처리량을 최대 3배 제공
• Aurora는 관리형 데이터베이스 서비스 Amazon Relational Database Service(Amazon RDS)의 일부

 

✅ Aurora DB cluster

Aurora DB cluster는 하나 이상의 DB 인스턴스와 데이터를 관리하는 클러스터 볼륨으로 구성된다.

DB 인스턴스 2가지 유형

• 기본 DB 인스턴스 
  • 읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨의 모든 데이터 수정을 실행
  • Aurora DB 클러스터마다 기본 DB 인스턴스가 하나씩 존재
• Aurora 복제본 
  • 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원 
  • 최대 15개까지 Aurora 복제본을 구성

 

✅ Aurora Serverless

• Amazon Aurora의 온디맨드 Auto Scaling 구성이다. 인스턴스 층이 수요에 맞게 자동으로 주율하고 미 사용시 종료 후 요금을 발생시키지 않는다. (스토리지 비용은 발생)
• 특정 시간대에만 사용하거나 테스트 환경의 데이터베이스의 수요를 전혀 예측할 수 없을 경우 이 기능을 사용하면 좋다.

 

✅ BackTrack 

Aurora에는 DB를 어느 시점으로든지 되돌릴 수 있는 Backtrack을 제공해주고 있다. 다만 Backtrack은 Mysql에서만 지원을 해주고 있다.

 

✅ Aurora DB 클러스터의 내결함성

클러스터 볼륨은 단일 AWS 리전에 속하는 다중 가용 영역을 모두 아우르며, 각 가용 영역에는 클러스터 볼륨 데이터의 사본이 복사됩니다. 이 기능은 가용 영역 한 곳에서 결함이 발생하더라도 DB 클러스터가 잠시 서비스가 중단될 뿐 전혀 데이터 손실 없이 결함을 견딜 수 있음을 의미한다. 

 

✅ 클러스터 기본 인스턴스에 결함 발생시 조치 방법

• 복제본이 있는 경우 
  • 동일하거나 다른 가용 영역에 Amazon Aurora 복제본이 있는 경우 장애 조치 시 Amazon Aurora는 DB 인스턴스의 표준 이름 레코드 (CNAME)를 정상 복제본을 가리 키도록 하여 새로운 복제본으로 승격시킨다.
• 복제본이 없는 경우
  • Amazon Aurora 복제본 (예 : 단일 인스턴스)이 없고 Aurora 서버리스를 실행하지 않는 경우 Aurora는 원래 인스턴스와 동일한 가용 영역에 새 DB 인스턴스를 생성하려고 시도합니다.
• DB 클러스터의 가용성을 높이려면 최소 하나 이상의 Aurora 복제본을 둘 이상의 다른 가용 영역에 생성하는 것이 바람직하다.

 

✅ AWS Aurora VS AWS RDS

• 가장 큰 차이점은 스토리지이다.
• Aurora는 Shared Storage를 사용하며 MySQL의 경우 Binlog 기반의 Replication이 아닌 Storage와 Page 기반의 Replication을 사용한다. 
  • Replication 이란 ?
    백업과 성능 향상을 위해 DB를 여러대의 서버에 복제하는 행위를 Replication이라 한다. 

 

---

✅ AWS EBS (Elastic Block Storage)란 ? 

• Elastic Block Storage로 EC2 instance에 직접 붙여 사용하는 볼륨형 스토리지이다.
• 하나의 인스턴스 도는 여러개의 인스턴스에 동시에 연결할 수 있는 AWS의 외장 하드디스크이다.

 

✅ EBS 용어

• Volume(볼륨) : EBS의 가장 기본적인 형태로 OS에서 바로 사용 가능한 형태
  • EBS (영구적 스토리지)
    
    • 인스턴스의 수명과 무관하게 유지 (인스턴스 stop, terminated 되면 데이터 유지/삭제 옵션이 존재)
    • 호스트 외부에 존재하는 스토리지
    • 하나의 인스턴스에 attach한 EBS 볼륨을 분리해서 다른 인스턴스에 연결 가능
  • 인스턴스 스토어 (휘발성 스토리지)
    
    • 인스턴스에 직접 연결돼 EBS보다 빠르다
    • 인스턴스가 활성화 되어있는 동안에만 유지(인스턴스 stop/terminate 되면 데이터 삭제)
    • 호스트 로컬 내부에 존재하는 스토리지
    • 하나의 인스턴스가 가진 인스턴스 스토어를 분리해서 다른 인스턴스에 연결 불가
• Image(이미지) : AMI(Amazon Machine Image)의 형태로 OS가 설치된 형태이며, 이를 통해 EC2 인스턴스를 생성함
• Snapshot(스냅삿): EBS 볼륨의 특정 시점을 그대로 복사해 저장한 파일
  snapshot을 통해서 EBS볼륨과 AMI를 생성할 수 있음
• IOPS (Input/Output Operation Per Second) : 저장 장치의 성능 측정 단위
  IOPS의 I/O 단위는 16KB

✅ EBS 특징

• 필요한 용량에 맞게 구입/생성/제거 가능 (필요한 만큼 가상의 볼륨을 잡고 과금)
• '스냅샷'  : EBS볼륨의 백업, AZ에 중복저장 가능 (증분식백업 : 마지막스냅샷 이후 변경된 볼륨의 블록만 저장)
• '암호화' : AWS KMS 마스터키를 사용해서 암호화된 볼륨생성 가능
• '지속성' : 인스턴스 수명에 관계없이 유지 (즉, 인스턴스 중지/종료해도 삭제해도 데이터유지가 기본)
• 종료시 삭제 옵션 
  활성화 : 인스턴스 종료시 연결된 볼륨도 같이 삭제
  비활성화 : 인스턴스 종료시 연결된 볼륨은 삭제되지 않고 분리됨(available상태)

 

✅ EBS는 언제 사용하는가 ?

• 데이터에 빠르게 액세스 해야하고, 장기간 지속하는 데이터를 저장해야할 경우
• 인터넷에 대한 액세스가 제공되지 않는다 
• USB처럼 EC2에 연결해서 사용가능
• 사용자가 지우기 전 까지 영구적으로 보존

 

✅ EBS 종류

• 프로비저닝된 IOPS SSD(io1) - 성능이 지속적으로 요구되는 중요한 비즈니스 어플리케이션에 주로 사용
• 처리량 최적화 HDD (st1) - 자주 액세스하는 처리량이 많은 워크로드에 주로 사용됨 (시스템 부팅 볼륨으로 사용 불가)
• Cold HDD (sc1) - 범용 SSD보다 저렴한 HDD 볼륨을 제공하나 시스템 부팅 볼륨으로 사용 불가  

 

---

✅ AWS ELB (Elastic Load Balancing) 이란 ?

• EC2 인스턴스에서 운영 중인 애플리케이션, 마이크로 서비스 또는 컨테이너로 트래픽을 분산 처리해주는 서비스
• 최소 2개 이상의 인스턴스가 각기 다른 AZ에 존재해야 한다.
• 하나의 리전에서만 실행되도록 설계되었으며 여러 리전에 걸쳐 실행되지 않는다.

 

✅ ELB 기본 구성

• AWS의 사용자 정의 네트워크인 VPN(Virtual Private Network)에 탑재되며 사용자의 요청을 받고 이를 VPN 내의 리소스 (EC2 등)에 적절히 부하 분산한다. 따라서 외부의 요청을 받아들이는 Listener와 요청을 분산/전달할 리소스의 집합인 대상 그룹(Target Group)으로 구성되며 ELB는 다수의 리스너와 대상 그룹을 거느릴 수 있다.
• 그리고 부하 분산 대상인 그룹 내 리소스들은 헬스 체크 (Health Check)를 활용해 끊임없이 상태를 확인받는다.

 

✅ ELB 종류 

1. External ELB
   인터넷에 요청을 받아 부하를 분산한다.
   따라서 Public IP가 부여되며 Public Subnet에 위치시켜 인터넷과 연결되도록 해야한다. 
   
   
2. Internal ELB
   Internal ELB는 VPC 서브넷 내부의 요청만을 받아 부하를 분산한다.
   따라서 Public IP가 부여되지 않는다. Public Subnet에 연결하더라도 인터넷 연결이 되지 않는다.

Application Load Balancers	OSI 7 Layer의 7계층에 해당하는 Application Layer의 특성을 이용하는 로드밸런서이다. 단순 부하 분산뿐아니라 HTTP의 헤더 정보를 이용해 부하분산은 실시하는 것이 중요한 특징이다. HTTP 헤더의 값들을 보고 각 요청을 어느 대상 그룹으로 보낼지를 판단할 수 있다는 것이다. 또한 SSL 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신해 SSL 암/복호화를 진행할 수 있다.
Network Load Balancer	OSI 7 Layer의 4계층에 해당하는 Transport Layer의 특성을 이용하는 로드밸런서이다. HTTP도 TCP 기반의 프로토콜이기 때문에 ALB를 사용하지 않고 NLB를 사용한다면 이를 받아들여 부하 분산을 실시한다. 상위 레이어가 아닌 하위 레이어의 TCP 레이어에서의 처리이므로 HTTP 헤더를 해석하지는 못한다. 그러므로 HTTP 헤더를 이용한 부하 분산은 불가능하다.
Gateway Load Balancer	투명한 네트워크 게이트웨이(즉, 모든 트래픽이 오가는 단일 지점)와 수요에 따라 트래픽을 분산하고 가상 어플라이언스를 조정하는 로드 밸런서를 결합한다. VPC의 라우팅 테이블에서 간단히 구성을 업데이트하면 GWLB로 트래픽을 보낼 수 있다. GWLB를 사용하는 고객은 가상 어플라이언스에서 트래픽의 부하를 분산하여 가상 어플라이언스를 탄력적으로 확장/축소할 수 있다.  GWLB는 정상 가상 어플라이언스를 통해 트래픽 흐름을 라우팅하여 가용성을 개선하고, 어플라이언스가 비정상 상태가 되면 다시 트래픽 흐름을 라우팅한다.
Classic Load Balancer	프론트 엔드 연결 - 클라이언트와 로드 밸런서 사이에 있다.  유휴 제한 시간이 경과할 때까지 데이터가 전송되거나 전송 또는 수신되지 않으면 로드 밸런서는 프론트 엔드 연결을 종료한다.  파일 업로드와 같이 시간이 오래걸리는 작업이 완료될 수 있도록 시간 여유를 두려면 유휴 제한 시간이 지나기 전에 최소 1바이트의 데이터를 전송하고 필요에 따라 유휴 제한 시간의 길이를 늘린다. 백엔드 연결 - 로드 밸런서와 등록된 EC2 사이에 있다. CLB는 등록된 인스턴스로 요청을 주기적으로 전송하여 상태를 확인한다. 이러한 테스트를 바로 상태 확인이라고 한다. 정상 인스턴스의 상태는 InService라고 표시되며 비정상적인 인스턴스는 OutOfService라고 표시된다. 로드 밸런서는 인스턴스가 정상 상태이든 비정상 상태이든 관계 없이 모든 인스턴스에 대해 상태 확인을 수행한다. 로드 밸런서는 정상 상태 인스턴스로만 요청을 라우팅한다. 인스턴스가 비정상 상태라고 판단되면 로드 밸런서는 이 인스턴스로의 요청 라우팅을 중지한다.  인스턴스가 정상 상태로 복구되면 로드 밸런서는 이 인스턴스로의 요청 라우팅을 재개

 

✅ ELB 특징

• 트래픽 분산
• 자동 확장
• 인스턴스의 상태를 자동 감지해서 오류가 있는 시스템은 배제
• 사용자 세션을 특정 인스턴스에 고정
• SSL 암호화 지원
• SSL의 경유지로 ELB를 사용하는 경우에 SSL 처리에 따른 부하를 ELB가 수용하게 된다.
• IPv4, IPv6 지원
• CloudWatch를 통해서 모니터링
• 사용한 시간과 통과한 트래픽에 따라서 종량제로 과금

 

✅ ELB 세션 유지방법

1. Sticky Session (고정 세션)
   한 사용자의 요청을 하나의 인스턴스와 연결하여 처리하게 만드는 기능
   ELB에서 독자적으로 발생한 쿼리를 사용하는 것과 애플리케이션에서 발행한 쿠키를 사용하는 것 중에 선택 가능
2. ElasticCache
   모든 인스턴스에서 세션 정보를 공유하도록 할 수 있다.
   내결함성, 가용성, 확장성을 고려해 요즘에는 거의 이 기술을 이용한다.

 

✅ ELB 용어

• 프록시 프로토콜
  사용자의 트래픽을 그냥 전달하는 것이 아닌 ELB의 주소를 담아서 보낸다.
  
  
• ELB 고정 세션
  • 로드 밸런서가 사용자 세션의 수명 동안 특정 인스턴스에 바인딩 할 수 있다.
  • 로드 밸런서 생성 쿠키를 이용하여 어플리케이션 인스턴스를 추적한다. 
• 연결 드레이닝 
  로드밸런서가 트래픽을 분산한 인스턴스를 특별한 이유로 종료시켜야 할 때 받은 트래픽을 모두 처리할 때까지 인스턴스의 종료를 지연시킨다.
  연결 드레이닝을 활성화하면 로드밸런서가 인스턴스의 등록 취소를 보고하기 전에 연결을 유지할 수 있는 최대 시간을 지정할 수 있다. 최대 제한 시간 값의 범위는 1~3600초이다. (기본은 300초)
  최대 제한 시간에 도달 시 로드 밸런서는 등록 취소중인 인스턴스로의 연결을 강제로 종료한다.
  
  
• 다중 로드밸런서
  접속하는 디바이스의 종류에 따라 다른 로드밸런서를 이용하게 한다.

---

✅ AWS Snowball이란 ?

• 대량의 데이터를 AWS로 이전할 때 네트워크로 전송하지 않고 디스크나 스토리지에 저장하여 물리적으로 전달하고 이를 업로드하여 주는 서비스
• AWS Snowball을 사용하면 마이그레이션, 단기 데이터 수집 또는 장기 배포 등을 위해 기계 학습, 데이터 분석, 프로세싱 및 스토리지를 위한 클라우드 기능을 엣지에서 사용할 수 있다.
• AWS Snowball 디바이스는 인터넷 연결 여부와 상관없이 작동하며 전용 IT 운영자가 필요하지 않고 원격 환경에서 사용 가능하도록 설계되었다.

 

✅ snowball 종류

• nowball Edge Compute Optimized - 높은 컴퓨팅 성능을 제공하여 고성능 워크로드에 적합하다.
• Snowball Edge Compute Optimized - 더 많은 스토리지를 제공하여 대규모 마이그레이션 및 용량 중심의 워크로드또는 큰 용량이 필요한 로컬 컴퓨팅에 적합하다.
  • Snowball Edge Compute Optimized는 블록 볼륨 및 Amazon S3 호환 객체 스토리지를 위한 80TB의 HDD 용량과 블록 볼륨을 위한 1TB의 SATA SSD를 제공한다. 컴퓨팅 리소스에 대해, 이 디바이스는 Amazon EC2 sbe1 인스턴스(C5와 동급)를 지원하기 위해 40개의 vCPU와 80GiB의 메모리를 제공한다.

---

✅ Route 53 

• AWS에서 제공하는 DNS(Domain Name Service)이다.

 

✅ 일반 DNS 이해

DNS의 동작 과정은 도메인을 IP로 변환하여 IP 네트워크 통신한뒤 목적지 IP를 찾아가는 과정이다.

 

✅ 일반 DNS와 Route 53의 차이점

1. Route 53에서 네임서버 등록 시 순서가 다르다.
2. Route 53은 Public Host Zone과 Private Host Zone이 있다.
   • Public Host Zone은 일반 네임서버로 글로벌하게 동작한다.
   • 일반 네임서버로 동작한다.
   • Private Host Zone은 AWS 내에서만 동작한다.
3. Route 53 특이 레코더, ALIAS (별칭)이 있다.
   
   • 도메인 자체에 대해 ALIAS를 줄 수 있다.
   • dns-book.com 도메인 자체에 대한 ALIAS Target을 www로 줄 수 있다.
   • 도메인 트래픽을 ELB 로드 밸런서로 라우팅하기위해 사용한다.
   • 별칭 레코드를 사용해 CloudFront 배포와 S3 버킷 등 선택한 AWS 리소스로 트래픽을 라우팅할 수 있다.
   • 호스팅 영역의 한 레코드에서 다른 레코드로 트래픽을 라우팅할 수도 있다.
   • 별칭 레코드를 사용하여 AWS 리소스로 트래픽을 라우팅하면 Route 53이 리소스의 변경 내용을 자동으로 인식한다. 예를 들어 example.com의 별칭 레코드가 lb1-1234.us-east-2.elb.amazonaws.com의 ELB 로드 밸런서를 가리킨다고 가정한다. 로드 밸런서의 IP 주소가 변경된다면 Route 53은 자동적으로 새로운 IP 주소를 사용하여 DNS 쿼리에 응답하기 시작한다.

 

+ CNAME 레코드와 별칭 레코드의 차이점

별칭 레코드는 루트 도메인과 하위 도메인 모두에 별칭 레코드를 만들 수 있지만 CNAME 레코드는 하위 도메인에 대해생성할 수 있다.
별칭 레코드는 zone apex라고 하는 DNS 네임스페이스의 최상위 노드에 별칭 레코드를 만들 수 있다.
ex) DNS 이름 example.com을 등록하면 zone apex는 example.com이다. 

 

 

✅ Route 53 쿼리 라우팅 정책

• 지리 위치 라우팅 정책 – 사용자의 위치에 기반하여 트래픽 라우팅하려는 경우에 사용합니다.
  지리적 라우팅을 사용하는 경우, 콘텐츠를 지역화하고 웹 사이트의 일부 또는 전체를 사용자의 언어로 제공할 수 있습니다. 또한 지리적 라우팅을 사용하여 배포권이 있는 위치에서만 콘텐츠를 배포할 수 있도록 제한할 수 있습니다. 또한 예측 가능하고 간편하게 관리할 수 있는 방식으로 엔드포인트 간에 로드를 분산하는 데 사용함으로써, 사용자의 위치가 동일한 엔드포인트에 일관되게 라우팅되도록 할 수도 있습니다.
• 단순 라우팅 정책 – 도메인에 대해 특정 기능을 수행하는 하나의 리소스만 있는 경우(예: example.com 웹 사이트의 콘텐츠를 제공하는 하나의 웹 서버)에 사용합니다.
• 장애 조치 라우팅 정책 – 액티브-패시브 장애 조치를 구성하려는 경우에 사용합니다.
• 지리 근접 라우팅 정책 – 리소스의 위치를 기반으로 트래픽을 라우팅하고 필요에 따라 한 위치의 리소스에서 다른 위치의 리소스로 트래픽을 보내려는 경우에 사용합니다.
• 지연 시간 라우팅 정책 – 여러 AWS 리전에 리소스가 있고 최상의 지연 시간을 제공하는 리전으로 트래픽을 라우팅하려는 경우에 사용합니다.
• 다중 응답 라우팅 정책 – Route 53이 DNS 쿼리에 무작위로 선택된 최대 8개의 정상 레코드로 응답하게 하려는 경우에 사용합니다.
• 가중치 기반 라우팅 정책 – 사용자가 지정하는 비율에 따라 여러 리소스로 트래픽을 라우팅하려는 경우에 사용합니다.

 

✅ Route 53 장애 조치 구성

액티브-액티브 장애 조치

• 모든 리소스를 대부분의 시간 동안 사용 가능하도록 하기위해 사용한다.
• 리소스를 사용할 수 없을 때는 Route 53이 비정상 상태임을 판별하여 쿼리에 응답할 때 그 리소스를 포함하지 않는다.
• 액티브-액티브 장애 조치에서 동일한 이름, 동일한 유형(예: A 또는 AAAA) 및 동일한 라우팅 정책(예: 가중치 또는 지연 시간)를 보유한 모든 레코드는 Route 53이 이를 비정상으로 간주하지 않는 이상 활성 상태입니다.
• Route 53은 정상 레코드를 사용하여 DNS 쿼리에 응답할 수 있다.

 

액티브-패시브 장애 조치

• 기본 리소스 또는 리소스 그룹이 대부분의 시간 동안 사용 가능하도록 하고 보조 리소스 또는 리소스 그룹은 기본 리소스가 사용 불가능할 경우를 대비해 대기 중에 있도록 하기 위해 사용한다.
• 쿼리에 응답할 때 Route 53은 정상적인 1차 리소스만을 포함한다. 모든 1차 리소스가 비정상이라면, Route 53은 DNS 쿼리에 응답할 때 정상적인 2차 리소스만을 포함시키기 시작한다.

 

 

 

참고 

https://web-front-end.tistory.com/74

https://jjon.tistory.com/entry/Amazon-Aurora-%EB%9E%80

https://dev.classmethod.jp/articles/developersio-korea-rds-aurora-basics-1/

https://overcome-the-limits.tistory.com/294

https://www.it-note.kr/366

https://pearlluck.tistory.com/181

https://aws-hyoh.tistory.com/128

https://brunch.co.kr/@topasvga/49

https://galid1.tistory.com/223