출처 AWS 시스템 설계와 마이그레이션을 보고 정리한 내용입니다.
웹 서비스, 업무용 시스템에 관계 없이 시스템은 요청이 쇄도하는 피크 시간이 있습니다. 피크 시간은 시스템 특성 계정, 요일 등의 시작적욘 요인 이나 돌발적인 요인등 다양한 요인이 얽혀 날마다 변화하기 때문에 예사아힉 어렵고, 설계 시 엔지니어들을 고민하게 만드는 요인입니다.
온프레미스 시스템을 구축할 경우 과거 정보에 의해서 요청 수를 책상 위에서 예측하고 거기에 일정량의 여유율을 곱해서 서버 사양을 결정합니다. 하지만 이런 예상은 매우 어렵고 요청 수가 예상을 뛰어넘어 장애의 원인이 되거나 예상을 밑돌아 인프라 리소스를 낭비하기도 합니다.
ELB 하위에 여러 EC2 인스턴스를 연결하고, 요청을 각 인스턴스에 분산시킵니다. AWS ELB는 관리 콘솔이나 AWS API를 사용해서 쉽게 짧은 리드 타임으로 로드 밸런서 기능을 사용할 수 있습니다.
ELB에는 표준 로드 밸런스 CLB, ABL 라는 로드 밸런서가 있습니다. 여기서는 최근에 릴르즈된 기능도 풍부한 ALB를 사용한다고 전제하고 설명하겠습니다.
어느 정도의 엑세스 증가를 급격한 증가라고 판단하는 가가 중요한데 AWS의 문서에서에 따르면 5분에 50%이상 트래픽이 늘어나느 경우에 사전 워밍 신청을 해야한다고 나와있습니다.
ELB에는 관리하고 있는 EC2 인스턴스가 제대로 동작하고 있는지를 확인하는 기능이 있습니다. 제대로 동작하지 않은 인스턴스는 포기하고 요청을 보내지 않도록하고, Auto Scaling 기능과 연계해서 제외한 만큼 인스턴스를 보충할 수 있기 때문에 트러블에 영향이 사용자에게 미치치 않습니다.
상태 확인은 다음과 같은 매개변수를 정의 할 수 있기 때문에 시스템 특성에 따라 튜닝할 수 있습니다.
- 어떤 파일을 확인하는가?
- 몇 초 마다 파일을 확인하는가
- 몇 번연속으로 엑세스 실패하면 분리하는가
- 몇 번 연속으로 섹세스 성공하면 연결하는가
ELB가 관리하는 여러 대의 EC2 인스턴스가 있는 경우, 동일한 이용자가 요청할 때마다 엑세스하는 인스턴스가 바뀔 가능성이 있습니다. 따라서 로그인 후 액세스하려는 서버에 세션 정보가 없는 있고, 그 때는 기대한 처리를 실행할 수 없게 됩니다.
상태 유지 세션은 동일한 사용자의 요청을 모두 같은 EC2 인스턴스에게 분배하는 기능입니다. 그러나 사용자는 원래부터 엑세스하고 있던 인스턴스에 처리가 계속해서 할당되게 됩니다. 이런구조는 인스턴스가 늘려도 효과를 보기가 어렵습니다. 반대로 인스턴스의 수가 감소한 경우 해당 인스턴스에 처리된 사용자의 상태 정보가 사라지므로 계속해서 처리를 못할 수 있습니다.
이 문제를 환벽하게 해결하려면 뒤에서 설명할 인 메모리 캐시 패턴을 사용해서 세션 정보를 인 메모리 캐시에 저장하는 등 서버에서 상태를 관리하지 않은 비 상태 유지 구성을 취해야합니다.
Auto Scaling은 서버의 이용 상황에 따라 자동으로 서버의 수를 증가시키는 기능입니다.
가장 쉬운 스케일 방식 희망 대수를 수동으로 변경하면 그 대수가 되도록 스케일 할 수 있습니다. 최소 대수보다 적은 대수,최대 대수보다 많은 대수로 설저하는 것은 불가능합니다.
최소 대수를 희망 대수 값과 동일하게 설정해 초기의 인스턴스 대수를 유지하는 방식입니다. Auto Scaling 그룹 인스턴스에 뭔가 문제가 발생하고 유효한 인스턴스의 수가 줄었을 때 자동으로 인스턴스가 구축되는, 최소한으로 필요한 인스턴스 대수를 유지하는 방식입니다.
설저한 시간에 맞춰 서버 대수를 증감시키는 방식 18 시부터 22시 까지 요청이 많은 서비스에 대해서 17:55에 인스턴스를 8대로 한다. 등 같은 피크 시간이 왔다 갔다 하거나 인스턴스를 시작하는데 시간이 걸리는 것을 고려해서 시간을 결정해야 합니다.
서비스의 이용 상황에 따라 동적으로 대수를 증감시크는 방식입니다. 예를 들면
CPU의 평균 사용률이 70%를 넘으면 2대의 인스턴스를 늘리겠다.
일단 CPU의 평균 사용률이 50%를 넘으면 1대 추가, 거기서 80%를 넘으면 1대 또 추가
피크 시간을 예측하기 어려운 경우에 유효한 설정이라고 할 수 있습니다.
규칙 기반 Scaling 정책 설정은 스케일 인 조건도 설정할수있습니다. 위 조건과 반대로 CPU 사용률이 떨어지면 1대 스케일 인 같은 설정을 할 수 있습니다.
이런 설정을 자주하면 스케일 아웃/인이 반복될 위험이있습니다.
웹서버에 비해 데이터베이스를 스케일 아웃하는 것은 어렵습니다. DB 서버의 부하를 줄이기 위한 또 다른 방법으로 인 메모리 캐시를 시용하는 방법이 있습니다. 웹서버에서 데이터베이스로 쿼리를 실행했을 때 결과를 캐시에 저장해두고, 이후의 액새스는 데이터베이스가 아니라 캐시에 데이터를 반환해서 데이터베이스의 부하를 줄이는 방법입니다.
또 한 세션정보와 같은 서버 간에 공유하며 자주 액세스 되는 정보를 데이터베이스에 저장하면 읽기 처리가 과하게 발생하해서 전체 시스템의 성능에 영향을 미칠 우려가 있습니다. 그래서 세션 정보를 인 메모리 캐시 Key - Value 저장소에 저장하면 이러한 영향을 줄일 수 있습니다.
AWS에서는 완전 관리형 인 메모리 캐시 서비스인 Amonze ElastiCache 라는 서비스가 있습니다.
AWS 리소스의 설정을 JSON, YAML 형식으로 기재한 템플릿을 만들고 해당 템플릿에서 AWS 리소스를 자동으로 구축하는 서비스
Beanstallk의 반대로 AWS 서비스 군의 특징과 특성을 이해하고 인프라 설계를 할 수 있다는 전제가 되기 때문에 난이도는 가장 높다고 할 수있습니다.
Chref 기반 인프라 구성 관리 서비스입니다. 레시피를 이용해서 구성을 정의 및 관리하고 EC2 인스턴스에 대한 각종 서비스의 설치 및 구성을 자동화합니다.
주로 사용하는 인프라 구성의 자동 구축 및 애플리케이션 배포 자동화 서비스입니다. AWS에서 인프라 구축 및 미들웨어 설치 및 설정 작업을 할 필요가 없기 때문에 비즈니스적으로 가치를 창출하는 서비스의 기능 개발에 집중할 수 있습니다.
AWS를 잘 아는 맴버가 없는 경우 AWS의 일반 구성으로 스몰 스타트할 수 있다는 장점이있습니다. 일반적인 구성에서 벗어나게되면 이용할 수 없기 때문에 구성의 자유도가 낮은 것이 단점있습니다. 서비스 시작 단계에서 유용하게 사용할 수 있습니다.
CDN은 정적 콘텐츠를 빠르게 전달하는 시스템입니다. 웹 서비스의 이요자가 많아지면 서버 측의 부하가 높아져서 성능 문제가 발생할 수 있습니다.
이미지를 전달하는 웹서버 앞단에 캐시 서버를 준비해 둡니다. 그리고 사용자의 요청을 우선 캐시 서버에 도착하게 해 두고, 만약 캐시 서버가 컨텐츠를 반활 할 수 있는 오리진 서버 대신 정적 콘텐츠를 보내줍니다 캐시 서버에 콘텐츠를 반환할 수 없는 경우 예전 처럼 오리진 서버로 취득하러 갑니다. 그리고 취즉한 콘텐츠를 캐시 서버에 캐시하게 됩니다. 이런 방식으로 서버의 부하를 감소를기대할 수 있습니다. 캐시 서버를 각지에 분산시킴으로써 최종 사용자로부터 가장 가까운 캐시 서버에서 컨텐츠를 반환할 수 있습니다.
CloundFront는 이미지나 동영샅 같은 정적 콘텐츠를 캐시해서 오리진 서버 대신 전달하는 CDN 서비스입니다. CloundFront는 전 세계에 엣지 로케이션이 있고 이용자로부터 가장 가까운 엣지 로케이션에서 콘텐츠를 제공합니다.
클라이언트가 *.CloundFront.net 라는 도메인에 요청을 보내면 CloundFront용 DNS가 가장 가까운 엣지 로케이션의 IP주소를 반환하기 때문에 이용자와 응용 프로그램 개발자는 어떤 엣지 로케이션에 요청을 보내야 하는지를 신경 쓰지 않아도 최적화된 상태로 사용할 수있습니다.
정적 콘텐츠의 유형에 따라 캐시 설정을 최적화합니다. 업데이트 빈도가 높거나 오래된 콘텐츠가 표시되면 안되는 경우에 TTL을 짧게 하거나 캐시하지 않은 설정을 사용하고, 그렇지 않은 콘텐츠에 긴 TTL을 설정합니다. 또한 브라우저 캐시 설정과 CloundFront 캐시 설정의 조합에 따라 캐시의 동작이 바뀔 수 있습니다.
요청된 콘텐츠마다 캐시 적중률을 리포팅하는 기능이 있습니다. 정기적으로 이 보고서를 확인하고 적중률이 현저히 낮은 것을 캐시할 수 없는지 검토하고 사이트의 성능을 향상시킬 수 있는지 검토 가능합니다.
오리진 서버에 장개가 발생했을 때도 에러 페이지를 표시하도록 설정할 수 있습니다. 모든 EC2 인스턴스에 문제가 발생하더라도 에러 페이지는 S3에서 반환할 수있습니다.
비 상태(stateless)로 설계한 EC2는 여려 개 준비하로 로드 밸런서를 요청하면 분배함으로써 단 일 서버에 장애가 발생하더라도 시스템 전체가 다운되지 않도록 설계할 수 있습니다. 하지만 데이터 상태를 유지하는 데이터베이스는 상태 유지(statefull)로 할 수 밖에 없습니다.
데이터베이스 가용성을 높이기 위해 레플리케이션(복제) 및 미너링이라는 방법을 취합합니다. 마스터 DB와 슬레이브 DB를 준비하고 평상시에는 애플리케이션에서 마스터 DB에 읽고 쓰기를 합니다. 그리고 마스터 DB와 슬래이브 DB 사이를 동기화하고 보존하고 있는 데이터를 동일한 상태로 만들어 둡니다. 이런 상태를 유지함으로써 마스어 DB가 문제가 발생했을 때 애플리켜이션이 바라보는 곳을 슬레이브 DB로 전환 해서 시스템이 정지되지 않게 할 수 있습니다.
DB 한쪽의 인스턴스가 장애가 발생했을 때 자동으로 장애 조치가 이뤄집니다. 애플리케이션은 RDS가 제공하는 DB 엔드포인트를 연결 대상으로 이용하지만 장애 조치 시에는 바라보는 엔드포인트를 자동으로 슬레이브 DB의 IP 주소로 전환합니다.
이런 풍부한 기능을 GUI나 커멘드라인에서 간단히 구축할 수 있다 점이 RDS의 강점입니다.
운용에 필요한 백업 취득 및 패치 적용 기능이 미리 표준 으로 제공된다는 것입니다.
RDS에서는 이러한 기능을 기본으로 제공합니다. 백업에 관해서 저익적으로 스냅숏 및 트랜잭션 로그를 S3에 저장할 수 있습니다. 이들을 이용해 DB 인스턴스의 재구축이나 지정한 시간의 상태로 DB 인스턴스를 복구할 수 도있습니다.
CloudWatch를 설정하고 각 지펴의 중감을 모니터링 할 수 있도록 설정합니다. 릴리즈 직후에닌 요청량을 예상하기 어렵기 때문에 특히 주의해야합니다. RDS 인스턴스의 부하가 높은 경우에는 스케일 업을 검토합니다.
마스터 슬레이브 구송으로 RDS 인스턴스의 확장 및 패치 적용 등의 유지보수에 의한 정지 시간을 단축할 수 있습니다.
CloudWatch는 AWS의 각종 리소스 및 서비스를 모니터링하기 위한 햄심서비스입니다. AWS에서 실행되는 리소스의 다양한 정보를 수집할 수 있습니다.
EC2 인스턴스에서 출력되는 로그를 수집, 모니터링하고 설정된 조건과 일치하면 통보하는 서비스로 CloudWatch Logs가 있습니다.
CloudWatch Logs를 이용하면 각 인스턴스에 에이전트를 설치해야합니다. CloudWatch Logs를 사용하면 자바 애플리케이션의 특정 예외가 로그에 출력되는 경우에 감지하거나 아파치의 에러 로그에 특정 문자열이 출력된 경우를 감지하는 것이 가능합니다.
- 로그의 추적 및 Export
- 검색 특정 문자열 필터링
- 필터링 결과의 그래프화
- Amazon SNS와 연계한 경보 설정
- Amazon Kinessis나 Lambda와 실시간 연계