25일차 AWS

RDS(Relational Database Service)

AWS에서 제공하는 관계형 데이터베이스 서비스이자 클라우드에서 관계형 데이터베이스를 간편하게 설정, 운영 및 확장할 수 있도록 하드웨어 프로비저닝, 데이터베이스 설정, 패치 및 백업과 같은 시간 소모적인 관리 작업을 자동화하고, 사용자가 애플리케이션에 집중하여 애플리케이션에 필요한 빠른 성능, 고가용성, 보안 및 호환성을 제공할 수 있도록 지원해주는 서비스이다.

 

EC2 인스턴스에 MySQL 같은 관계형 데이터베이스 엔진을 설치하면 되는데 굳이 데이터베이스만 분리해 RDS를 사용할 이유는 무엇일까

 

EC2 인스턴스에 관계형 데이터베이스 엔진을 설치는 개인 소유의 차량에 비유할 수 있다. 유지 보수, 보험처리 같은 일들을 온전히 운전자가 부담해야 하며 차량 정비를 위해서 정비소에 주기적으로 방문해야 하고, 기타 차량과 관련된 다른 일이 생길 때 들여야 하는 시간과 수고가 크다.

 

RDS를 이용하는 것은 렌터카 회사에서 차량을 대여에 비유할 수 있다. 렌터카 회사에서 차량을 대여하면 대여 차량과 관련하여 시간이 들어가는 일들을 렌터카 회사에서 대신 처리하며 운전자는 차량을 관리하는 일에 대해서 시간을 따로 쏟을 필요 없이 운전만 하면 되기에 매우 편리하다. RDS를 이용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리하며 사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낀다.

 

 또한 RDS 이용시 다양한 데이터 베이스 엔진 선택지를 제공하여 필요와 목적에 맞게 데이터 베이스 서버를 선택하여 효율을 높일 수 있다.

 

 

 

관계형 데이터베이스의 개요

 

데이터베이스 관리 시스템, 즉 DBMS는 데이터 저장, 조직화, 인출과 관련된 제반 업무를 관장하는 소프트웨어이다. 그중 관계형 데이터베이스에서 정보는 열과 행으로 이뤄진 테이블에 저장되고, 테이블에 저장된 데이터는 공통 키 또는 공통 컨셉에 따라 서로 관계를 유지하며, 테이블에서 데이터를 인출할 때 이와 같은 관계성을 이용한다는 측면에서 관계형 데이터베이스라는 이름이 붙었다.

 

 

 

Amazon RDS의 엔진

 

• Aurora MySQL
• Aurora PostgreSQL
• Oracle
• SQL Server
• MySQL
• PostgreSQL
• MariaDB

 

 

 

데이터베이스 호스팅 방식

 

온프레미스 데이터 센터에 데이터베이스 호스팅

사용자의 데이터 센터에 데이터베이스를 호스팅 하면 전원, 네트워크 환경설정, 서버 환경설정부터 애플리케이션 최적화, 데이터베이스 소프트웨어 업그레이드 등까지 데이터 센터 운영을 위한 제반 업무를 모두 수행해야 한다.

Amazon EC2 서버에 데이터베이스 호스팅

EC2 서버에 데이터베이스를 호스팅하면 사용자는 DB 소프트웨어 설치, 패치, 데이터베이스 백업, 앱 최적화등을 관리하고, AWS는 OS 설치, 서버 유지 보수, 서버 랙 관리, 네트워크 관리 등의 업무를 처리한다.

Amazon RDS를 이용해 데이터베이스 호스팅

Amazon RDS를 이용해 데이터베이스를 호스팅 하면, AWS가 데이터베이스 설치부터 업그레이드 등, 데이터베이스 호스팅과 관련된 모든 복잡한 업무를 대신 처리한다. 사용자는 애플리케이션 최적화에만 집중하면 됩니다. RDS의 주요 장점은 다음과 같다.

 

• 인프라 관리 불필요 : 사용자는 데이터베이스와 관련된 어떤 인프라도 직접 관리할 필요가 없으며 AWS가 데이터베이스와 관련된 모든 업무를 대신 처리한다.
• 즉각적 프로비저닝 :데이터베이스 프로비저닝은 거의 즉시 이루어지며 클릭 몇 번만으로 원하는 사양의 RDBMS를 배포할  수 있다.
• 확장성 관리 : 매우 간단하게 스케일업 및 스케일다운할 수 있으며, 사용자가 원하는 내용대로 환경을 설정할 수 있다. 언제든  컴퓨팅 또는 메모리 리소스의 확장성을 조절할 수 있다.
• 애플리케이션 호환성 : 다양한 데이터베이스 엔진을 지원하므로 업계에서 널리 사용되는 데이터베이스 애플리케이션, 커스텀    코드, 기업에서 이미 사용 중인 데이터베이스 도구 등과 완벽하게 호환된다.
• 고가용성 : 멀티 AZ 환경에 데이터를 프로비전하면, 동기적으로 데이터를 복제해 다른 AZ의 대기 인스턴스에 저장한다.
• 보안 유지 : 대기 상태 데이터 및 이동 상태 데이터의 암호화를 지원하며, 이를 이용해 대기 상태의 데이터를 암호화할 수 있으며, SSL 기법을 이용해 전송 상태의 데이터를 암호화할 수 있다.

 

RDS 고가용성 구현

 

RDS는 고가용성(high availability) 아키텍처를 지원하며 데이터베이스가 잠시라도 셧다운 되면 기업의 모든 업무가 마비될 수 있기 때문에, 모든 데이터 서비스의 근원인 데이터베이스는 본질적으로 고가용성 아키텍처를 따른다.

 

가장 단순한 아키텍처 : 싱글 AZ 배포

RDS를 상용화 환경이 아닌 개발 환경에서 데이터베이스를 사용하거나 클라우드 기반 데이터베이스에 대한 경험을 얻는 차원에서 사용하는 거라면, 싱글 AZ 환경에서 RDS 인스턴스를 론칭해도 무방하다. 이때 사용자는 VPC 내에서 필요한 수준의 스토리지를 붙여서 하나의 RDS 인스턴스를 사용하게 된다.

고가용성 아키텍처 : 멀티 AZ 배포

기업에게 매우 중요한 데이터베이스를 실행하거나, 데이터를 절대 잃어버려서는 안 되는 경우, 설정된 복원 소요 시간이 매우 촉박하거나 가동 정지 시간이 일절 허용되지 않는 경우, 멀티 AZ 환경에서 데이터베이스를 배포해야 한다. 멀티 AZ 아키텍처에 데이터베이스를 배포하려면, 사용자가 먼저 기본 데이터베이스 인스턴스를 어느 AZ에 놓을지 정해야 하며 RDS는 또 다른 AZ에 대기 인스턴스 또는 스탠바이 인스턴스 및 스토리지를 선택해 배포하게 된다. 대기 인스턴스는 기본 인스턴스와 동일한 타입으로 배포되고, 스토리지 또한 기본 스토리지와 동일한 환경 설정 내용으로 구성된다.

 

 

멀티 AZ 아키텍처의 경우 마스터 데이터베이스라고 부르는 기본 데이터베이스가 모든 트래픽을 처리하고, 스탠바이 데이터베이스는 애플리케이션이 실행되고 있는 기본 데이터베이스가 셧다운 되는 상황을 대비해 가동 가능 상태에서 대기하게 된다. RDS는 기본 데이터베이스는 정상 상태를 유지하도록 하고, 대기 데이터베이스는 즉시 복구가 가능하도록 대기 상태를 유지한다.

 

이때 대기 데이터베이스는 대기라는 상태에 있는 한 작동시킬 수 없고, 기본 데이터베이스와 대기 데이터베이스에 동시에 트래픽을 분산시킬 수는 없으며 이는 액티브 및 패시브(active/passive) 데이터베이스 모델과 비슷한 개념이다. 기본 데이터베이스의 데이터는 동기적으로 대기 데이터베이스의 스토리지에 복제된다.

 

RDS는 장애 발생 시 다양한 유형의 대응 방식을 자동으로 적용해, 호스트 인스턴스 셧다운, 스토리지 장애, 기본 인스턴스의 네트워크 연결 단락, AZ 자체 셧다운 등의 장애 상황에 대처 가능하다. 장애 대응 상황이 발생하면, 대기 데이터베이스가 기본 데이터베이스의 역할을 이어받아서 새로운 기본 데이터베이스로서 모든 애플리케이션의 트래픽을 처리하게 됩니다. RDS의 멀티 AZ 아키텍처에서 애플리케이션은 장애 발생 시 자동으로 DNS 장애 대응 기능을 활성화시켜, 기본 인스턴스와 대기 인스턴스를 맵핑한 DNS 엔드포인트를 이용해 데이터베이스에 연결된다. 따라서 사용자는 장애 대응을 위해 애플리케이션을 새로운 기본 데이터베이스에 연결할 필요가 없다.

 

RDS 확장성 구현

 

RDS에서 실행되는 데이터베이스의 확장성을 관리할 수 있는 다양한 방법이 존재한다. 사용자는 여러가지 이유로 RDS에서 데이터베이스의 확장성을 높이려 한다. 예를 들어, 애플리케이션의 사용자 수가 증가하면서, 기업은 CPU와 메모리 용량 부족으로 서비스 성능 저하를 경험하게 된다. 혹은 적절한 워크로드 분석 없이 애플리케이션을 상용화한 경우에도 확장성 제고의 필요성을 느끼게 된다.

 

즉, 기업이 성장함에 따라 워크로드가 추가되고 이는 확장성을 구현함에 따라 해결할 수 있습니다. 확장성을 구현하는 데는 아래와 같은 방법이 있습니다.

인스턴스 타입 변경

확장성 조절을 위한 가장 간단한 방법은 데이터베이스 인스턴스 타입을 변경하는 것이다. 하나의 인스턴스 클래스에서 다른 인스턴스 클래스로 변경함으로써 스케일업 또는 스케일 다운할 수 있다.

 

이러한 변경 사항을 즉시 적용하면, 인스턴스 클래스 변경에 따라 약간의 가동 정지시간(downtime)이 발생할 수 있으므로, 애플리케이션이 이러한 가동 정지시간에 영향을 받지 않도록 확인해야 한다.

읽기 사본 활용

마스터 데이터베이스의 Read-Only 복사본으로 마스터 베이스와 동기화 상태를 유지하며, RDS는 RDBMS 엔진에 따라 최대 15개의 읽기 사본을 지닐 수 있다. 읽기 사본은 read-only 쿼리의 부담을 줄여주며, 마스터 데이터베이스의 워크로드를 감소시키는 장점이 있다.

 

또 읽기 사본은 고가용성 구현 매커니즘으로 사용할 수 있다. 예를 들어 마스터 데이터베이스와 읽기 사본을 운용 중인 상황에서 마스터 데이터베이스가 다운되면 읽기 사본이 마스터로 승격될 수 있으며 데이터가 비동기적으로 복제되므로 데이터의 손실 가능성이 존재하기 때문에 데이터 손실에 주의해야 한다.

 

 

 

 

 

 

Auto Scaling Group

 

Auto Scaling은 미리 정해 놓은 규칙에 따라 워크로드(작업량)를 자동으로 확대 또는 축소할 수 있는 기술로 클라우드가 제공하는 탄력성에 의해 만들어지고, 사용자의 요구 수준을 반영할 수 있는 기술이다.

 

Auto Scaling을 이용하면 처리 요구량이 급등하는 시기, 즉 피크 워크로드에 맞춰 새 리소스를 자동으로 추가하고 환경 설정하고, 처리 요구량이 줄어들면 해당 리소스를 감소시키기 때문에, 과잉 프로비전을 할 필요성이 사라진다.

 

프로비전(provision) 필요한 컴퓨팅 리소스들을 필요한 곳에 배치, 유휴 자원들을 다시 회수하는 일련의 작업들을 의미한다.

 

 

Auto Scaling의 장점

• 동적 스케일링 : Auto Scaling의 가장 큰 장점은 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링할 수 있다는 점이다. 스케일 업 할 수 있는 서버의 수에는 제한이 없고, 필요한 경우 서버 두 대에서 수백 ~ 수만 대의 서버로 즉시 스케일 업할 수 있다.
• 로드 밸런싱 : Auto Scaling은 리소스를 동적으로 스케일업 혹은 스케일 다운한다. 로드밸런서와 함께 사용하면, 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배할 수 있으며, 다수의 AZ에 분포된 EC2 인스턴스에 대한 워크로드도 자동으로 분배하도록 설정할 수 있다. 따라서 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리할 수 있다.
• 타겟 트래킹 : 사용자는 특정 타겟에 대해서만 Auto Scaling을 할 수 있으며, 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정한다.
• 헬스 체크와 서버 플릿 관리 : Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있다. 헬스 체크를 하는 과정에서 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체한다.

다수의 EC2 서버에서 애플리케이션을 호스팅 하는 경우, 이들 일련의 EC2 서버 집합을 AWS는 서버 플릿(Fleet)이라 부른다. Auto Scaling은 적정 수준의 서버 플릿 용량을 유지하는 데도 도움을 준다. 예를 들어, 어떤 기업의 애플리케이션이 6대의 EC2 서버에서 실행 중일 때 6대 서버에 대한 헬스 체크 상태를 모니터링하다가 특정 서버에 문제가 생기면 즉시 대응 조치를 할 수 있다. 한 대 또는 그 이상의 서버가 다운되면 Auto Scaling은 6대의 서버 인스턴스 처리 용량을 유지하기 위해 부족분만큼의 서버를 추가로 실행시키는 방식으로 서버 플릿을 유지한다.

 

EC2 Auto Scaling 활용

 

Auto Scaling은 EC2 인스턴스뿐만 아니라 다른 인스턴스와도 결합 가능하지만, EC2 사용자에게 가장 인기가 많은 서비스이며 EC2 Auto Scaling은 오직 EC2 서버라는 리소스만 대상으로 한다

 

시작 템플릿(Launch Configuration)

Auto Scaling으로 인스턴스를 확장 또는 축소하려면 어떤 서버를 사용할지 결정해야 한다. 이는 시작 템플릿을 통해서 가능하며, AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있다. 만약 시작 템플릿을 사용하고 있지 않고 시작 템플릿을 생성하지 않으려는 경우에는 대신 시작 구성을 생성할 수 있다. 시작 구성은 EC2 Auto Scaling이 사용자를 위해 생성하는 EC2 인스턴스 유형을 지정한다는 점에서 시작 템플릿과 비슷하며 사용할 AMI의 ID, 인스턴스 유형, 키 페어, 보안 그룹 등의 정보를 포함시켜서 시작 구성을 생성합니다.

Auto Scaling 그룹 생성

Auto Scaling 그룹은 스케일업 및 스케인 다운 규칙의 모음으로 EC2 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있으므로 Auto Scaling 그룹을 생성하기 위해서는 스케일링 정책 및 유형에 대해서 잘 숙지하고 있어야 한다.

Scaling 유형

• 인스턴스 레벨 유지 : 기본 스케일링 계획으로도 부르며, 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있다. 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정하면 된다.
• 수동 스케일링 : 기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있다. 수동 스케일링을 선택하면 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가 또는 삭제해야 한다.(비추천)
• 예측 스케일링 : 트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링을 사용하는 것이 좋습니다. 예를 들어 낮 시간대에는 트래픽이 최고치에 이르고 밤 시간대에는 트래픽이 거의 없다면 낮 시간대에 서버를 증설하고 밤 시간대에 스케일 다운하는 규칙을 추가하면 됩니다.
• 동적 스케일링 : 수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법이다. CloudWatch는 모니터링하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정한다. 예를 들어 CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우 Auto Scaling이 작동돼 새 서버를 추가하는 방식이다. 이와 같은 스케일링 정책을 정의할 때는 항상 스케일 업과 스케일 다운 두 가지의 정책을 작성해야 한다.

동적 스케일링의 유형

• 타겟 트랙킹 스케일링 : 미리 정의된 성능 지표를 이용하거나, 커스텀 성능지표를 사용하여 타겟 값으로 설정할 수 있다.
• 단순 스케일링 : 단 하나의 스케일링 설정에 따라 그룹의 현재 용량을 늘리거나 줄인다. 예를 들어 CPU 활용지표가 80% 에 도달할 때 하나의 인스턴스를 추가하고, 40% 미만으로 떨어질 때 인스턴스 하나를 감소시키는 방식이 있다. 이때 새 인스턴스를 시작 혹은 정지시키기 위한 대기 시간도 정의할 수 있으며 이를 쿨다운 기간이라고 부른다.
• 단계 스케일링 : 단순 스케일링은 특정 이벤트에 대해 매번 같은 액션을 한다면, 단계 스케일링은 좀 더 세분화해서 단계를 나누어 규칙을 추가할 수 니다.

인스턴스 삭제 정책

Auto Scaling은 스케일업 정책은 물론 스케일다운 정책도 반영한다. 스케일다운 정책이 적용되면, EC2 인스턴스가 삭제되며, 서버를 셧다운 하는 것은 리소스 관리 측면에서도 꼭 필요한 일다.

 

스케일다운 정책에서는 명확하게 몇 개의 인스턴스를 삭제할 것인지 정의할 수 있으며, 어떤 인스턴스를 먼저 셧다운 할 것인지 환경 설정을 통해 결정할 수 있다.

 

인스턴스 삭제 정책 방법

• 사용자의 서버 플릿에서 가장 오랫동안 실행된 서버를 삭제한다. 가장 오랫동안 실행된 서버일수록 패치 수준이 낮고 메모리 누수 등의 문제가 누적해 있을 가능성이 크기 때문에 이를 삭제함으로써 최신의 성능 기준을 유지할 수 있다는 장점이 있다.
• 시간 단위 과금이 임박한 서버를 삭제한다. 이 서버를 삭제하면 Auto Scaling의 특유 장점을 최대한 살려, 과금 부담을 줄일 수 있다.

 

 

 

Elastic Load Balancing

 

로드 밸런싱

로드 밸런싱

서비스 규모가 커지면 물리/가상 서버 한 대로는 모든 서비스를 수용할 수 없게 된다. 서버 한 대로 서비스를 제공할 수 있는 용량이 충분하더라도 서비스를 단일 서버로 구성하면 해당 서버의 애플리케이션, 운영체제, 하드웨어에 장애가 발생했을 때 정상적인 서비스를 제공할 수 없으므로 서비스 가용성을 높이기 위해 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데, 각 서버의 IP 주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정해야 한다. 이런 경우 로드 밸런서를 사용한다. 로드 밸런서는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 서비스 요청을 분산시켜 부하를 분산하며 이러한 작동을 로드 밸런싱이라고 하며, 부하 분산이라고도 한다. 

 

ELB(Elastic Load Balancing)

AWS에서 서비스하는 로드밸런싱이며, 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산한다. 등록된 대상의 상태를 모니터링하면서 상태가 양호한 대상으로만 트래픽을 라우팅 한다.

 

 

 

ELB의 장점

 

• 고가용성 : ELB는 고가용성 아키텍처를 구현하는데 도움을 준다. ELB는 다수의 EC2 인스턴스, 컨테이너 등에 트래픽을 분산시키며 다수의 AZ에 배포된 EC2 인스턴스에 애플리케이션을 배포해 트래픽을 여러 AZ로 분산시킬 수 있으며 하나의 AZ가 모두 다운돼도 사용자의 애플리케이션은 문제없이 실행 상태를 유지할 수 있다.
• 탄력성 : ELB의 최대 장점은 자동적 확장성이다. 관리자는 인스턴스 추가 또는 삭제를 위한 어떤 수작업도 할 필요가 없으며, 수동으로 뭔가를 할 여지도 없다.
• 안전성 : 통합 인증관리, SSL 복호화, 포트 포워딩 등 다수의 보안 기능을 제공한다. 현대 웹사이트 운영자는 웹 애플리케이션 레벨에도 암호화 기법을 적용하며, 다수의 보안 정책을 제공한다.
• 높은 처리량 : ELB는 트래픽 증가를 처리할 수 있도록 설계되었으며 초당 수백만 개의 요청을 로드 밸런싱할 수 있다. 또한, 갑작스럽고 변동이 심한 트래픽 패턴도 처리할 수 있다.

 

작동 방식

로드 밸런서는 클라이언트에 대한 단일 접점으로 클라이언트에서 오는 트래픽을 허용하고 하나 이상의 가용 영역에서 등록된 대상(EC2 인스턴스)으로 요청을 라우팅 한다. 로드 밸런서는 등록된 타겟의 상태를 모니터링하고 정상 타깃으로만 트래픽이 라우팅한다. 로드 밸런서가 비정상 타겟을 감지하면 해당 타겟으로 트래픽 라우팅을 중단하고 다시 정상으로 감지되면 트래픽을 해당 타겟으로 다시 라우팅한다.

 

리스너는 구성한 프로토콜 및 포트를 사용하여 클라이언트의 연결 요청을 확인한다. 리스너에 대해 정의한 규칙에 따라 로드 밸런서가 등록된 타깃으로 요청을 라우팅 하는 방법이 결정된다. 각 규칙은 우선 순위, 하나 이상의 작업, 하나 이상의 조건으로 구성되며 규칙에 대한 조건이 충족되면 작업이 수행된다. 각 리스너에 대한 기본 규칙을 정의해야 하며, 필요에 따라 추가 규칙을 정의할 수 있다.

리스너 :외부의 요청을 받아들이는 역할 ( 사용자의 요청을 받아들이고 적절한 대상그룹으로 라우팅하는 역할 )

 

각 타겟 그룹은 지정한 프로토콜과 포트 번호를 사용하여 EC2 인스턴스 같은 하나 이상의 등록된 타겟으로 요청을 라우팅한다. 여러 대상 그룹에 타겟을 등록할 수 있으며 타겟 그룹 기준으로 상태 확인을 구성할 수 있다. 로드 밸런서의 리스너 규칙에서 지정한 타겟 그룹에 등록된 모든 타겟에서 헬스 체크를 수행한다.

 

ELB의 유형

 

Application Load Balancer

 

Application Load Balancer는 OSI 모델의 레이어 7에 해당하며, HTTP와 HTTPS를 지원한다. 로드 밸런서는 요청을 받으면 우선순위에 따라 리스너 규칙을 평가하여, 적용할 규칙을 결정한 다음 규칙 작업의 타겟 그룹에서 타겟을 선택한다. 애플리케이션 트래픽의 콘텐츠를 기반으로 다른 타겟 그룹에 요청을 라우팅하도록 리스너 규칙을 구성할 수 있다.

 

ALB에서는 헤더 수정이 가능합니다. 예로 X-Forwarded-For 헤더에 클라이언트 IP주소를 넣듯 필요한 정보를 헤더로 삽입할 수 있다.

또한 ALB의 호스트 기반 라우팅을 통해 HTTP 헤더의 Host 필드에 따라 클라이언트 요청을 라우팅 할 수 있고, 경로 기반 라우팅을 통해 HTTP 헤더의 URL 경로에 따라 클라이언트 요청을 라우팅 할 수 있다.

 

Network Load Balancer

 

Network Load Balancer는 TCP 로드 밸런서라고 부르며, OSI 모델의 레이어 4에서 작동한다. 로드 밸런서가 연결 요청을 받으면 기본 규칙의 타겟 그룹에서 대상을 선택합니다. 리스너 구성에 지정된 포트에서 선택한 타겟에 대한 TCP 연결을 열려고 시도한다.

 

TCP 트래픽의 경우, 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트, TCP 시퀀스 번호에 따라 흐름 해시 알고리즘을 사용하여 타겟을 선택하며 클라이언트로부터의 TCP 연결은 소스 포트와 시퀀스 번호가 서로 다르므로 다른 타겟에 라우팅될 수 있습니다. 각 TCP 연결은 연결 수명 동안 하나의 타겟에 라우팅 된다.

 

UDP 트래픽의 경우, 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트에 따라 흐름 해시 알고리즘을 사용하여 타겟을 선택한다. UDP 흐름은 소스와 목적지가 동일하기 때문에 수명이 다할 때까지 일관되게 단일 타겟으로 라우트되며 서로 다른 UDP 흐름에는 서로 다른 소스 IP 주소와 포트가 있으므로 다른 타겟으로 라우팅 될 수 있다.

 

 

다중 AZ의 활용

Auto Scaling과 ELB를 활용해 애플리케이션을 구현할 때는 가능한 다중 AZ를 기반으로 할 것을 권장한다. 왜냐하면 AZ가 고가용성을 구현하기 위한 기본 구조이기 때문이다. ELB가 트래픽을 AZ 간에 균등하게 배분할 수 있으므로, AWS 생태계를 기반으로 서비스를 구현할 때 다중 AZ 구조의 활용은 당연한 것이다.

 

 

다중 AZ의 문제점은 무엇과 해결방안

노드 밸런서 노드가 균등하게 부담을 분배하기 때문에 AZ 별 부하분산 대상의 숫자가 균형을 이루지 않는 경우, 숫자가 적은 AZ 쪽에 있는 인스턴스에 부담이 쏠릴 수 있다.

로드밸런서 노드 : ELB는 VPC 내에서 하나의 형태로 존재하고 다수의 네트워크 인터페이스를 가지는데 이 다수의 인터페이스가 로드밸런서 노드이다.

 

Cross Zone Load Balancing

AZ별 부하분산 대상의 숫자가 균형을 이루지 않는 경우 교차 영역 로드밸런싱을 활성화하면 AZ를 가리지 않고 고르게 부하를 분산한다.

 

ALB에는 기본적을 활성화되었으며, NLB에는 비활성화되어있으며, 로드밸런서 생성 후 언제든지 설정 가능하다.

 

타켓수가 달라 한쪽에 몰린 상태                                                                          교차 영역 로드밸런싱으로 분산된 상태

 

 

Sticky Session

 

특정 세션의 요청을 처음 처리한 서버로만 전송하는 것을 의미한다.

 

ELB는 트래픽에 따라서 인스턴스에 요청을 분산하여 전달하기 때문에 A 서버는 세션정보를 가지고 있지만, B 서버는 가지고 있지 않을 수 있는 상황이 발생하며 이런 경우 로그인해서 새로고침을 했더니 로그아웃이 되어 버릴 수도 있다.

 

 

Sticky Session을 사용하면 처음 요청을 받았던 서버로 재전송하기 때문에 이러한 문제점을 해결할 수 있지만 로드밸런싱이 잘 동작하지 않을 수 있으므로 특정 서버에만 과부하가 올 수 있으며 특정 서버 오류 시 해당 서버에 붙어있는 세션들이 소실될 수 있다. 

 

또 이러한 Sticky Session의 해결책으로 Session Clustering을 이용하는데 여려 WAS세션을 동일한 세션으로 관리하는 것이다.

 

 

CloudFront

 

AWS에서 제공하는 CDN 서비스이다.

 

전 세계 티어 1,2,3의 이동통신사와 협력하여 네트워크에 연결된 글로벌 CDN 서비스로서 저지연성과 고속전송속성을 지닌 콘텐츠 배포 기능을 제공하며, 콘텐츠 사용자와 가까운 지역(엣지 로케이션)에 네트워크망을 구축하고, 지역별 엣지 캐시를 통해 사용자 경험 수준을 높일 수 있게 한다. 정적 콘텐츠 뿐만 아니라 동적 콘텐츠도 지원하며, 사용자 요청은 가장 가까운 엣지 로케이션에서 처리된다.

 

 

엣지 로케이션 CloudFront는 엣지 로케이션이라 부르는 글로벌 데이터센터 네트워크를 통해 콘텐츠를 배포한다. 엣지 로케이션은 전 세계 주요 대도시에 위치하며, AWS 리전 시설의 위치와는 다를 수 있으며 지역별 엣지 캐시 지역별 엣지 캐시는 오리진 웹 서버와 엣지 로케이션 사이에 위치해 사용자에게 직접 콘텐츠를 전송한다. 특정 콘텐츠의 인기가 줄어들수록 개별 엣지 로케이션에서는 해당 객체를 삭제해 인기가 많은 콘텐츠를 제공할 수 있는 여유 공간을 확보하고, 지역별 엣지 캐시는 엣지 로케이션보다 높은 수준의 캐싱 능력을 바탕으로 좀 더 오랜 시간 캐싱 데이터를 유지할 수 있다. 이와 같은 캐싱 데이터가 존재하면 사용자의 콘텐츠 요청 시, CloudFront는 오리진 웹 서버에 돌아갈 필요 없이 지역별 엣지 캐시로 사용자 요청에 대응하기 떄문에 콘텐츠 제공 성능이 높아지며 지역별 엣지 캐시는 CloudFront의 기본 기능이므로 사용자는 별도의 설정 작업을 하거나 비용을 부담할 필요가 없다.

 

CloudFront의 활용 시나리오

 

 

• 정적 콘텐츠 캐싱 CloudFront의 가장 대표적인 활용방식이다. 사진, 영상, 자바스크립트, 스타일시트 등의 정적 콘텐츠 전송 속도를 높여주고 사용자는 엣지 로케이션을 통해 요청한 콘텐츠를 제공받는다.
• 동적 콘텐츠 네트워크 최적화를 통한 동적 콘텐츠 가속화 기능을 제공하며, EC2 서버에서 실행 중인 애플리케이션 또는 웹사이트를 CloudFront와 통합할 수 있다.
• DDoS 공격 대응 CloudFront는 OSI 모델의 L3, L4, L7을 보호할 수 있는 AWS Shield, WAF를 통합해 DDoS 공격을 방어할 수 있으며 TLS 연결 및 서명 URL을 통한 사용자 인증 등의 기능을 제공한다.
• 강화된 보안성 CloudFront는 SSL(HTTPS) 방식의 보안 기능을 제공하며, 보안이 강화된 API, SSL/TSL 적용, advanced SSL 기능을 자동으로 적용할 수 있다. 더불어 모든 인프라와 프로세스는 중요 콘텐츠의 보안 수준을 유지하기 위해 PCI, DDS, HIPAA, ISO 규정을 준수한다.

 

 

CloudFront의 적용 방식

 

경로 패턴 매칭

• 사용자는 웹사이트 또는 애플리케이션의 URL 경로 패턴에 따라 다양한 캐시 제어 동작을 설정할 수 있다. 예를 들어 CloudFront가 이미지 뷰어로부터 요청을 받으면 요청 경로는 images/*. jpg와 같은 경로 패턴과 비교해 그에 맞는 제어 동작을 적용하며 사용자는 이와 같은 경로 패턴에 따라 HTTP/HTTPS 프로토콜 설정, 헤어 또는 캐싱 옵션 설정, 쿠키 및 쿼리 문자열 포워딩 설정, 접근 제한 등의 방식으로 특정 오리진으로 요청을 전송할 수 있다.

헤더

• 헤더 값을 통해 요청 헤더를 오리진 캐시로 포워딩할 수 있으므로, 디바이스의 헤더를 확인한 뒤 그에 맞는 동작을 적용할 수 있다. 예를 들어 동일한 사이트를 접속한 노트북 사용자와 스마트폰 사용자의 요청에 각기 다른 반응을 제공할 수 있다.

쿼리(query) 문자열 및 쿠키

• 웹 애플리케이션 중 일부는 오리진으로 정보를 전달하기 위해 쿼리 문자열을 사용하며 쿼리 문자열은 웹 요청의 일부로,? 기호 다음에 나오며, 하나 이상의 파라미터를 & 기호로 연결해 사용한다.

서명 URL

• 정적 콘텐츠를 S3 버킷에 옮긴 뒤에는 CloudFront의 서명 URL 방식을 통해 해당 콘텐츠에 대한 비인가 접근을 막을 수 있다. 서명 URL에는 만료일 및 만료 시간 등의 부가 정보가 포함돼 있어 콘텐츠에 대한 접근을 조금 더 세심하게 제어할 수 있고 서명 URL을 이용해 웹 서버가 S3 버킷의 콘텐츠에 접근할 수 있는 시간 또는 방식을 제어할 수 있으며, 사용자가 특정 콘텐츠에 대한 접근을 요청할 경우 접속 시간 제약이 설정된 서명 URL 링크를 전달받게 된다.

서명 쿠키

• 서명 쿠키는 기능상으로는 서명 URL과 거의 동일하며 단지 HTTP 쿠키에 추가 정보를 넣는다는 점이 다르다. 서명 쿠키는 다수 객체에 대한 접근 제어, URL 변경 없이 동일 객체에 대한 접근 제어를 해야 할 때 유용하며 작동방식은 다음과 같다. 사용자가 웹사이트에서 인증을 받으면 Set-Cookie 헤더가 사용자 계정에 전달되며 이는 사용자 디바이스의 쿠키에 적용되며 사용자가 제한 객체에 대한 접근을 요청하면 브라우저는 요청에 포함된 쿠키를 포워딩한다. 그러면 CloudFront가 쿠키 속성을 확인해 접근 허용 또는 차단 여부를 결정하게 된다.

 

CloudFront 기능

 

지역 제한 기능

 

사용자가 콘텐츠에 대한 요청을 하면 CloudFront는 사용자의 위치에 상관없이 콘텐츠를 전송하기에 특정 국가의 콘텐츠 요청을 거부하려면 다음과 같은 지역 제한 기능을 사용하면 된다.

• 접속 허용 국가 목록인 화이트리스트를 기반으로 요청 콘텐츠에 대한 접근을 허용하는 방법
• 접속 금지 국가 목록인 블랙리스트를 기반으로 요청 콘텐츠에 대한 접근을 거절하는 방법

 

 

 

오류 처리 기능

 

콘텐츠 요청에 대해 오리진 서버가 HTTP 4xx, 5xx 상태 코드를 반환하면 사용자에게 커스텀 오류 페이지를 제공할 수 있다. 예를 들어 커스텀 오리진 서버가 사용 불능 상태고, 5xx 응답을 반환하면, CloudFront는 S3에 호스팅 된 정적 페이지를 제공할 수 있다. 또 최소 유지시간(TTL)을 정의해 CloudFront 캐시 오류를 얼마나 오래 유지할지 조절할 수 있다.

 

 

 

 

 

 

Route 53

 

Route53은 관리형 DNS(Domain Name Service) 서비스이며 사용자의 요청을 EC2 인스턴스, ELB 로드밸런서, S3 버킷 등 AWS 내의 인프라에 연결시켜주며, AWS 외부의 인프라에도 연결시킬 수 있다. 리전과 독립적으로 작동하기 때문에 다수의 리전을 교차해 연결할 수 있고, 다수의 리전과 VPC 간의 DNS 주소변환도 가능하다. 퍼블릭 DNS 기록 관리 기능 외에도 도메인 등록, 신규 도메인을 위한 DNS 생성, 기존의 도메인에 DNS 기록 전송 등 다양한 기능을 제공한다.

 

 

Route53은 알리아스(Alias Records, 또는 존 에이펙스 Zone Apex)를 지원한다. 존 에이펙스는 웹사이트의 루트 도메인을 의미하며, CloudFront를 이용해 루트 도메인으로 콘텐츠를 전송할 수 있다. 즉, http://www.example.com 주소와 http://example.com 주소 모두 동일한 페이지로 연결되도록 할 수 있다. DNS 명세서에는 CNAME이 아닌 IP주소(A주소 기록)를 가리키는 존 에이펙스를 입력해야 하며, 이때 Route53의 알리아스 기록을 사용하면 된다.

 

지원하는 라우팅 정책

 

가중치 라운드 로빈(Weighted Round Robin)

 

하나의 웹사이트를 위한 여러 대의 웹서버 같은 경우처럼, 동일한 기능을 수행하는 여러 개의 리소스를 보유하고 있다면 Route53을 이용해서 리소스 별로 트래픽을 분산시킬 수 있으며 그중 한 방법이 가중치 라운드 로빈이다. 가중치 라운드 로빈은 이제 막 소프트웨어 설정을 변경한 서버에 소량의 트래픽만(새 서버세 10%, 기존 서버에 90%를 분산)을 보내 성능 및 안전 여부를 확인할 수 있다.

 

지연 기반 라우팅(Latency-Based Routing)

 

동일한 기능을 수행하는 다수의 EC2 기반 데이터 센터에 리소스를 확보하고 있다면 특정 리소스에 대한 DNS 쿼리 요청 시, Route53을 이용해 신속하게 응답할 수 있는 방법이 지연 시간 기반 라우팅이다. 이를 통해 글로벌 사용자를 확보한 애플리케이션의 성능을 높일 수 있으며 다수의 AWS 리전에서 실행되는 애플리케이션을 Route53 엣지 로케이션에 연결해 최저 지연 시간으로 글로벌 사용자에게 서비스를 제공할 수 있다.

 

장애 대응 라우팅(Failover Routing)

 

능동적 혹은 수동적 페일오버 즉, 장애 대응을 통해 가용 리소스 쪽으로 트래픽을 라우팅 하고 싶다면 Route 53의 장애 대응 라우팅을 이용한다. 특정 리전에서 모든 리소스를 제공하는 상황에서 해당 리전에 장애가 발생하면, 장애 대응 라우팅을 통해 정상적으로 작동 중인 리전으로 트래픽을 라우팅 할 수 있다.

 

지역 DNS 라우팅(Geo DNS Routing)

 

사용자의 지역에 따라 DNS 쿼리에 응답하도록 하려면 지역 DNS 라우팅을 이용하면 된다. Route 53의 지역 DNS 라우팅은 요청 발신지를 기준으로 가장 가까운 엔드포인트로 트래픽을 라우팅 하며, 지역에 특화된 콘텐츠 서비스를 제공하거나 특정 지역에서 금지 규정이 있는 콘텐츠는 배포되지 않도록 할 수 있다.

 

 

VPC(Virtual Private Cloud)

 

클라우드 내 프라이빗 공간을 제공함으로써, 클라우드를 퍼블릭과 프라이빗 영역으로 논리적으로 분리할 수 있게 하는 서비스이다.

 

이전에 VPC가 없었을 때는 클라우드에 있는 리소스를 격리할 수 있는 방법이 없었고, 따라서 인스턴스들이 서로 거미줄처럼 연결되고, 인터넷과 연결되어 시스템의 복잡도를 엄청나게 끌어올릴 뿐만 아니라, 의존도를 높였다. 따라서 유지 및 관리에 많은 비용과 노력을 투입해야 하는 단점이 있었다. 그러나 VPC를 분리함으로써 확장성을 가질 수 있고, 네트워크에 대한 완전한 통제권을 가질 수 있다.

 

 

IP Address

 

IP는 컴퓨터 네트워크에서 장치들이 서로를 인식하고 통신을 하기 위해서 사용하는 특수한 번호로, IPv4, IPv6로 나뉘어 있으며 혼용하여 사용하고 있다.

IPv4

위에서 보이는 십진수의 형태는 보기 편하도록 변형한 것이고, 실제의 형태는 2진수 8자리의 형태, 즉 각 8bit(비트)씩 총 32bit로 구성되어 있다. 이때 각 8bit를 Octet이라고 부르며, .으로 구분합니다. 그러므로 IPv4는 4개의 Octet(옥텟)으로 이루어져 있다고 할 수 있다.

 

 

CIDR(Classless inter-domain routing)

 

CIDR는 사이더라고 불리며, 클래스 없는 도메인 간 라우팅 기법으로 1993년 도입되기 시작한 국제 표준의 IP주소 할당 방법이며, IP 클래스 방식을 대체한 방식이다.

 

기존에는 클래스에 따라 정해진 Network Address와 Host Address를 사용해야 했다면, CIDR은 원하는 블록만큼 Network Address를 지정하여 운용할 수 있다.

 

/16은 첫 16bit를 Network Address로 사용한다는 의미로, 뒤에 16bit만 사용할 수 있습니다. 총 2^16인 65,536개의 IP주소를 사용할 수 있는 커다란 네트워크 블록을 이러한 방식으로 표시합니다.

 

CIDR 블록	IP주소의 수
/28	16
/24	254
/20	4094
/18	16,382
/16	65,536

 

 

서브넷(Subnet)

 

서브넷은 서브 네트워크(Subnetwork)의 줄임말로 IP 네트워크의 논리적인 하위 부분을 가리킨다. 서브넷을 통해 하나의 네트워크를 여러 개로 나눌 수 있으며 VPC를 사용하면 퍼블릭 서브넷, 프라이빗 서브넷, VPN only 서브넷 등, 필요에 따라 다양한 서브넷을 생성할 수 있다.

• 퍼블릭 서브넷 : 인터넷을 통해 연결할 수 있는 서브넷
• 프라이빗 서브넷 : 인터넷을 연결하지 않고, 보안을 유지하는 배타적인 서브넷
• VPN only 서브넷 : 기업 데이터 센터와 VPC를 연결하는 서브넷

서브넷은 VPC의 CIDR 블록을 이용해 정의되며, 최소 크기의 서브넷은 /28입니다. 이때 주의할 점은 서브넷은 AZ당 최소 하나를 사용할 수 있고, 여러 개의 AZ에 연결되는 서브넷은 만들 수 없다.

 

Tips ) AWS가 확보한 서브넷 중 처음 네 개의 IP주소와 마지막 IP주소는 인터넷 네트워킹을 위해 예약되어 있다. 서브넷에서 가용 IP주소를 계산할 때는 항상 이 부분을 기억하고 있어야 합니다. 예를 들어, 10.0.0.0/24 체계의 CIDR 블록이 있는 서브넷에서 10.0.0.0, 10.0.0.1, 10.0.02, 10.0.0.3, 10.0.0.255 등 5개의 IP주소는 예약되어 있습니다.

 

라우팅 테이블(Routing Table)

 

라우팅 테이블은 트래픽의 전송 방향을 결정하는 라우트와 관련된 규칙을 담은 테이블로 목적지를 향한 최적의 경로로 데이터 패킷을 전송하기 위한 모든 정보를 담고 있다. 쉽게 말하자면 라우팅 테이블은 하나의 지점에서 또 다른 지점으로 가기 위한 모든 정보를 제공하기 위한 테이블이며 모든 서브넷은 라우팅 테이블을 지닌다.

 

예를 들어 아래의 캡처본과 같이 특정 VPC의 서브넷이 라우팅 테이블에 인터넷 게이트웨이(VPC와 인터넷 간 통신을 가능하게 하는 구성요소)를 포함하고 있다면, 해당 서브넷은 인터넷 액세스 권한 및 정보를 가진다.

각각의 서브넷은 항상 라우팅 테이블을 가지고 있어야 하며, 하나의 라우팅 테이블 규칙을 여러 개의 서브넷에 연결하는 것도 가능하다. 서브넷을 생성하고 별도의 라우팅 테이블을 생성하지 않으면 클라우드가 자동으로 VPC의 메인 라우팅 테이블을 연결한다.

 

VPC관련 동영상