Pattern 3. 성능 요구사항을 만족하는 설계하기, 다섯 배 빠른 AWS 전용 DB 엔진 도입

인트라 웹 시스템 설계

-회계, 급여, 등의 업무 시스템을 AWS에 구축, 처리량이 증가하는 마감 전후 온라인 트랜잭션의 응답을 3초 이내로 안정

 

인프라 핵심 설계

1. 오토스케일링을 사용한 동적 프로비저닝(오토스케일링은 모니터링 서비스인 아마존 클라우드 워치와 함께 사용)

 - 업무 스케줄이나 피크 시의 리소스 상황에 맞추어 처리능력을 증감시킨다.

2. 인메모리 데이터 액세스 사용

 - 높은 빈도로 액세스 되는 데이터는 인메모리 캐시를 사용하여 데이터 액세스 지연을 줄인다. 

3. 고속의 RDB 서비스 이용

- 새로운 RDB 서비스인 Amazon RDS for Aurora 사용

 

1. 인메모리 캐시와 고속 RDB 활용

데이터 액세스에서 발생하는 처리시간, 성능에 따른 병목현상 줄이기 위한 2가지 방법 

 1)인메모리 캐시 서비스인 아마존 일래스틱 캐시 이용(자주 읽히는 데이터 일래스틱 캐시에 캐시 하여 빠르게 액세스 할 수 있도록 처리

 

2) 빠른 RDS이용 : MySQL을 기초로 하여 아마존이 독자적으로 커스터마이징 한 MySQL 호환 오로라 사용(Amazon Aurora MySQL)

 

3) 아마존에는 전용선인 아마존 다이렉트 커넥트가 있다. 

 

배워서 바로쓰는 14가지 AWS 구축 패턴 P49

 

2. 애플리케이션 서버 스케일 아웃 자동화

오토스케일링을 사용해 EC2 인스턴스 수를 자동으로 조정한다. 인스턴스 수 조정은 스케일링 정책에서 설정.

1) 스케줄러에 의해 정해진 수로 규모를 변경하는 '예약된 조정' (필요한 리소스 규모가 파악된 경우 스케줄러를 사용해 계획적으로 규모를 조정)

2) 인스턴스 사용 모니터링(아마존 클라우드 워치) 결과에 따라 동적으로 변경하는 '동적 조정'이 있다.(피크 시의 필요 리소스 규모 파악이 어려우면 CPU 사용률, 요청 수 등에 따라 규모를 조정한다.)

-> 이 둘은 함께 사용할 수 있다. 예약된 조정 방식으로 EC2 인스턴스 수를 제어하고 업무 중요도가 높은 시간대만 동적 조정 방법으로 오토스케일링을 활성화하면 비용의 변동 폭을 줄일 수 있다. 

 

3. 오토스케일링 그룹 설정 시 세 가지 주의점

 1) AMI(가상서버 템플릿) 만들기 

 2) 관리 콘솔에서 '오토스케일링 그룹'을 작성한다. 오토스케일링 그룹은 EC2 인스턴스 집합으로서 인스턴스 수를 설정할 수 있다. 

배워서 바로쓰는 14가지 AWS 구축 패턴 P51

3) 클라우드워치에 의한 모니터링 설정. EC2 인스턴스를 증감시키는 경우 클라우드 워치 모니터링 항목에 대해 임계값을 설정한다. 모니터링 항목의 임계값 설정을 통해 인스턴스 수를 증가시키는 트리거와 감소시키는 트리거를 만든다. 

4) 스케일링 정책의 설정 : 

 가. '예약된 조정'(스케줄러에 의해)으로 스케일링 정책의 최소 크기와 최대 크기만 설정해서 인스턴스 수를 변화시키고 싶을 때 명령행(AWS CLI)에서 인스턴스 수를 늘리거나 줄인다. 

 나. 클라우드 워치에 의해 파악할 경우 최소 크기와 최대 크기이외에 그룹 크기(오토스케일링 그룹의 EC2 인스턴스 수)의 증가 정책과 축소 정책을 설정한다. 

5) EC2 인스턴스의 구매 옵션 선택 

 가. 구매옵션은 온디멘드 인스턴스

 나. 스팟 인스턴스 

 

4. 자동 배포로 오토스케일링 간편하게 적용

오토스케일링 그룹에서 AMI 작성 시 고려할 점

 1) 애플리케이션 환경의 배포. 오토스 케일리에서 인스턴스가 시작되고 나서 요청을 처리할 수 있으려면 애플리케이션 실행 환경을 제공하여 배포해야 한다. 가장 간단한 방법은 이미 배포된 상태로 AMI를 준비해둔다. 아니면 EC2 인스턴스가 생성될 때 스크립트를 실행하는 '사용자 데이터'라는 기능을 통해 배포 스크립트를 실행해 새로 만들어지는 EC2 인스턴스에 애플리케이션 변경을 자동으로 반영되게 구축

 2) 인스턴스 종료에 대비해 데이터를 보존하는 방법을 만들어 두어야 한다. 인스턴스는 종료 시 삭제되며 인스턴스의 휘발성 저장소(메모리, 인스턴스 스토어)의 데이터도 삭제된다. 로그 등 인스턴스 종료 후에도 사용하는 데이터는 EBS에 저장해 두어야 한다. 

 

5. 마스터 데이터나 세션 정보 캐시하기 

일래스틱 캐시는 맴캐시드(Memcached)와 레디스(Redis)를 지원한다. RDS의 데이터를 캐시 하는 경우, 애플리캐이션은 RDS와 별도의 API를 사용해 액세스 한다. 

제한된 메모리 용량을 효율적으로 사용할 수 있도록 크기가 작으면서도 참조 빈도가 높은 데이터를 저장하는 데 적합하다. 여러 프로세스가 동일한 데이터를 업데이트할 경우 일관성 유지가 보장되지 않는다. 따라서 자주 업데이터 되지 않거나 일관성이 보장되지 않아도 문제가 없는 데이터에 대한 캐시로서만 이용해야 한다. 무중단이 요구되는 시스템에서는 일래스틱 캐시에 액세스 할 수 없는 경우 DB에 액세스 하도록 애플리케이션에서 처리해야 한다.

 

6. 읽기/쓰기가 빠른 RDS for Aurora

오로라는 로그 구조 저장소(Log-Structured Storage)라는 추가 확장이 자유로운 저장소 시스템을 채택하고 있다. 일반적인 MySQL은 업데이터 시에 갱신되는 행에 대해 잠금이 발생하며 참조 시에도 읽기에 대한 일관성을 보장하기 위해 잠금이 발생한다. 이로 인해 동시에 많은 트랜잭선이 병행하여 실행되면 처리량이 저하된다. (자세한 구조는 책 p56 참고)

 

7. 낮은 부하로 읽기 전용 복제본 추가 지원하기 

DB 서버를 수평적으로 확장해서 읽기 전용 DB서버를 증설하여 전체 시스템의 처리량을 효율적으로 향상시킬 수 있다. 

 

 

 

#참조 : 배워서 바로 쓰는 14가지 AWS 구축 패턴