핵심 설계 사항
1. 오토스케일링을 사요안 동적 프로비저닝
2. 인메모리 데이터 액세스 사용
3. 고속의 RDB 서비스 이용
인메모리 캐시와 고속 RDB 활용
온라인 트랙잭션 처리 시간은 대부분을 데이터 액세스가 차지한다. 성능에 대한 병목이 발생하기 쉬워 데이터 액세스에 걸리는 지연 시간을 줄일 방법에 대해 알아보겠다.
1. Amazon ElastiCache
데이터를 인메모리 캐시 서비스인 아마존 일래스틱 캐시를 이용하면 된다. 자주 읽혀지는 데이터를 일래스틱 캐시에 캐시하여 빠르게 액세스 할 수 있다.
2. 빠른 RDS
RDB의 관리 서비스인 RDS는 여러 DB엔진을 지원한다. 이중 아마존에서 개발한 Aurora를 이용하는 것이다. Aurora는 MySQL 기반으로 아마존에서 독자적 커스터마이즈한 RDBMS이다.
추가로 네트워크 대역폭또한 중요한데 네트워크 품질이 안정화가 되있지 않다면 다이렉트커넥트를 이용하여 네트워크 연결 서비스를 만든다.
앱 서버의 스케일 아웃 자동화
오토 스케일링
오토 스케일링을 사용하여 작동하는 EC2의 인스턴스 수를 자동 조절할 수 있다. 인트라 웹 시스템에서 사용할 수 있는 방법으로 스케줄러에 의해 규모를 변경하는 예약된 조정, 모니터링에 따라 동적으로 변경되는 동적조정이 있다.
1. 예약 조정
예약조정은 업무 특성이나 과거 사용 패턴등을 바탕으로 예상 처리량이 많은 시기에 사용된다. 시간대에 맞추어 인스턴스가 추가되도록 예약된 작업을 설정하면된다. 인스턴스 수를 제어하는 것이므로 비용을 예측하기 쉽다.
2. 동적 조정
예기치 못한 피크 상태 발생에 대비하거나 예상되지만 필요한 리소스가 변동하는 경우에 사용된다. 보통 클라우드 워치와 함께 사용되며 이를 이용하여 CPU 사용율, 요청횟수 등을 모니터링하여 임계값에 도달했을때 추가 인스턴스가 시작하도록 한다. 사전 예측이 필요없지만 비용변동은 큰편이다.
이 두가지를 함께 사용할 수 있다. 평상시에는 예약조정 방식을 이용하여 EC2를 제어하고 업무 중요도가 높은 시간대에만 동적 조정 방법을 이용하여 오토스케일링을 활성화하면 비용 변동폭은 줄이면서 피크시 성능을 제어할 수 있다.
자동 배포를 통한 오토스케일링 적용(AMI)
1. 앱환경의 배포
앱이 이미 배포된 상태로 AMI를 준비해 두는 방법이다. 이 환경은 애플리케이션을 출시할때마다 AMI를 다시 만들어야 하여 출시 빈도가 낮은경우는 적합하지만 출시 빈도가 잦을 경우는 운용이 복잡하다. 출시 빈도가 높은경우 인스턴스 시작시 배포를 자동으로 실행하는 구조를 마련하는 것이 효율적이다. User data 기능을 통하여 배포 스크립트를 실행하면 새로 만들어지는 EC2에 애플리케이션 변경을 자동 반영할 수 있다.
2. 인스턴스 종료를 대비해 데이터 보존
오토 스케일링 그룹은 인스턴스 종료시 삭제되고 인스턴스의 휘발성 저장소의 데이터도 삭제된다. 따라서 애플리케이션의 로그 등 인스턴스 종료 후에도 사용되는 데이터는 EBS에 저장한다.
캐시 서비스
AWS는 일래스틱캐시와 RDB(Aurora)를 통하여 캐시 서비스를 제공한다. 일래스틱 캐시는 인메모리 데이터 캐시의 관리형 서비스이다. 온프래미스 환경에서도 자주 사용되는 맴캐시드와 레디스를 지원한다. 관리형 서비스 이기 때문에 장애시 클러스터 재구성과 패치 적용은 자동화 되어있다. RDS의 데이터를 캐시하는 경우 앱은 RDS와 별도의 API를 사용하여 액세스한다. 보통 일래스틱 캐시에는 캐시되기 좋은 데이터를 인메모리 캐시에 저장하여 사용하고 그밖에 데이터들은 RDBMS에 저장하여 사용된다.
Aurora
일래스틱 캐시를 사용하게 될 경우 RDBMS의 병목현상을 막기 위하여 등장한 오로라는 AWS에서 만든 RDS서비스이다. MySQL과 호환되며 PostgreSQL과도 호환되어 업무 시스템 구축에 사용할 수 있는 유력한 대안이다.
MySQL호환 오로라는 MySQL과의 호환성을 제공하면서도 여러 개선사항이 추가되었다. 가장 큰 차이점은 스토리지이다. 오로라는 로그 구조 저장소라는 추가 확장이 자유로운 저장소 시스템을 채택하고 있다. 시스템이 마치 로그 파일처럼 끝부분에 연속해서 업데이트 데이터를 저장해 나갈 수 있다. 일반적인 MySQL은 업데이트 시 갱신되는 행에 대하여 일관성 보장을 위해 잠금이 발생되지만 오로라는 이러한 잠금이 발생되지 않아 빠른속도로 데이터를 읽고 쓸 수 있다. 단편화가 발생되지만 스토리지 내부에서 처리되기 때문에 사용자는 신경 쓸 필요가 없다.
낮은 부하로 읽기 전용 복제본 추가 지원
읽기 전용 복제본의 부하를 줄일 수 있는 점도 고속화에 기여한다. 요청이 늘어나면 읽기전용 복제본을 증설항 전체 시스템의 처리량을 효율적으로 향상시킬 수 있다. 스토리지 계층과 DBMS를 분리하여 원본 DB인스턴스와 읽기전용 복제본이 동일한 스토리지를 사용하도록 설계 되어있다. MySQL의 경우 최대 5개이지만 Aurora는 15대까지 설치할 수 있다.트랜잭션의 동시 실행 수가 많으면서 데이터 크기가 클수록 MySQL과의 성능 차이가 명확하게 나타나게 된다. 그러나 성늘 특성이 일치하지 않는 애플리케이션의 경우 고속화에 다른 이점이 충분하지 않을 수도 있다.
