핵심 AWS 서비스의 성능 최적화
컴퓨트
컴퓨트서비스의 진정한 목적은 워크로드 수요에 맞춰 신속하고 효율적으로 컴퓨트 리소스를 제공하는 것이다.
EC2인스턴스 타입
인스턴스의 성능은 다양한 환경설정 변수에 의해 결정되며, 처리하려는 워크로드에 가장 적합한 인스턴스 타입을 선택할 수 있어야 한다.
워크로드에 적합한 인스턴스 타입을 결정할 떄 선택ㄷ할 수 있는 환경설정 파라미터는 아래와 같다.
| 인스턴스 파라미터 | 설명 |
|---|---|
| ECUs | EC2 컴퓨트 유닛, 인스턴ㅌ스 타입 간 컴퓨트 성능 비교에 유용 |
| vCPUs | 인스턴스에 할당된 가상 CPUs 수 |
| Physical Processor | 호스트 서버가 사용하는 프로세서 패밀리 |
| Clock Speed | 호스트 서버가 사용하는 클럭 스피드 |
| Memory | 인스턴스에 할당된 메모리 양 |
| Instance Storage | 로컬(단명) 인스턴스 스토어 볼륨의 크기 |
| Network Performance | 인스턴스의 데이터 전송 속도 |
서버리스 워크로드
EC2인스턴스를 사용하지 않고도 Lambda 같은 서버리스 함수를 이용하면 초경량의 리소스만을 사용해 거의 즉각적으로 우리가 원하는 컴퓨트 인프라를 사요할 수 있다.
주요 활용 사례
| 기술 | 활용사례 |
|---|---|
| EC2 인스턴스 | 복잡한 구성으로 장시간 실행되는 웹 애플리케이션 심층적인 모니터링 및 트래킹이 요구되는 업무 프로세스 |
| ECS 컨테이너 | 고확장성의 자동화된 애플리케이션 마이크로서비스 배포 |
| Lambda 함수 | 데이터 스트림 파싱 작업 |
스토리지
RAID 최적화 EBS 볼륨
RAID(Redundant Array of Independent Disks) 기반의 디스크 관리 기술을 이용해 데이터 스토리지의 성능 및 안정성을 높일 수 있다.
RAID는 다수의 드라이브 공간을 하나의 논리 드라이브에 통합하며, 드라이브 내ㅈ 전체 배열 구조에 데이터를 분산 또는 복제한다.
- RAID 0 : 대규모 트랜잭션 데이터를 처리하는 데이터베이스의 I/O 성능을 크게 높여준다.
- RAID 1 : 성능을 높여주지는 않지만 하나의 디스가 실패하더라도 피해를 최소화해 안정성을 높여준다.
- RAID 5/RAID 6 : 성능과 안정성 모두를 높이기 위한 옵션 but IOPS 소모등의 문제로 권장되지는 않는다.
S3 크로스 리전 복제
S3는 글로벌 서비스이지만 버킷의 데이터는 물리적인 AWS리전에 존재할 수 밖에 없으며 누구든 새 버킷 생성 시 리전부터 선택해야한다.
하지만 법적 규제 혹은 성능 개선을 위하여 S3데이터의 물리적인 저장 위치를 하나 이상의 리전으로 확대해야할 수 있다.
데이터 복제는 지리적 위치에 따른 전송지연을 최소화하 위한 방법이자 데이터의 안정성 및 내구성을 높이기 위한 방법이다.
S3 Cross-Region Replication(CRR)은 하나의 리전에 있는 버킷 데이터를 자동으로 그리고 비동기적으로 다른 리전의 버킷에 복제한다.
CRR은 콘텐츠를 복제할 원본 버킷에서 복제 규칙을 생성한 뒤 사용할 수 있다.
원본 버킷에서 객체가 삭제되면 대상 버킷에서도 해당 객체가 삭제된다. 단 대상 버킷의 버저닝 기능이 활성화돼 있으면 객체가 유지된다.
Amazon S3 Transfer Acceleration
로컬 PC에서 S3버킷으로 대용량 파일을 자주 전송하는 경우 이용하기 좋은 서비스이다. 이를 통해서 전송 속도를 높일 수 있다.
CloudFront와 S3 Origins
S3는 파일, 미디어 객체, 정적 웹사이트 등을 호스팅하기위한 훌륭한 플랫폼이다.
이들 객체에 대한 접속은 CloudFront를 이용해 최적화 할 수 있다.
대표적인 CloudFront 활용방식이 S3버킷을 원본으로 해 비디오 및 이미지 서비스를 제공하는 것이다.
좀 더 낮은 비용으로 데이터를 활용하기 위한 대표적인 것이 S3이다.
데이터베이스
EC2인스턴스에 직접 데이터베이스를 설치하고 운영할지 아니면 데이터베이스와 관련된 복잡한 업무를 AWS에 일임하고 Amazon RDS를 사용할 것인지 결정할 필요가 있다.
직접 운영을 한다면 좀 더 저렴한 비용으로, 더 많은 제어 권한을 가질 수 있지만.
완전관리형 RDS를 이용하면 소프트웨어 업데이트, 패치, 데이터 복제등 데이터베이스와 관련된 각종 부담에서 자유로워질 수 있다.
네트워크 최적화 및 로드 밸런싱
위치 기반 저지연성 라우팅 기법인 Route53와 CloudFront는 강력한 네트워킹 정책에 있어 중요한 요소이며, VPC엔드포인트와 AWS Direct Connect 또한 중요한 요소이다.
현재 클라우드에서 가장 융요한 네트워킹 성능 강화 기술은 로드 밸런싱이라고 할 수 도 있다.
로드 밸런서는 인프라 맨 앞에 위치해 고객의 콘텐츠에 대한 모든 요구를 분산, 처리하는 네트워크 서비스다.
현재 Elastic Load Balancer(ELB)는 두 가지 로드밸런서 타입을 제공한다.
- Application Load Balancer(ALB)
- Http/https 트래픽을담당
- 애플리케이션 레이어 7 에서 작동한다. (호스티 기반 라우팅 및 패스기반 라우팅 허용)- 사용자는 ALB를 이용해 마이크로서비스 또는 다른 티어 아키텍처 서비스에 트래픽을 전송할 수 있따.
- Network Load Balancer(NLB)
- TCP 트래픽을 담당한다.
- 애플리케이션 레이어 4에 해당한다.
- 고용량 데이터 전송 또는 급증하는 트래픽에 대응하기 적합하다.
- http/https 를 사용안하는 내부망 전용 애플리케이션에서도 사용가능
클라우드 인프라 자동화
가상화의 가장 큰 이점은 리소스를 스크립트화 할 수 있다는 것이다.
Amazon 클라우드의 모든 서비스, 객체, 프로세스는 스크립트로 관리할 수 있으며, 코드로서의 인프라 즉 IAC(infrastructure as code) 환경을 제공한다.
CloudFormation
AWS CloudFormation을 이용해 인프라 리소스 스택을 관리할 수 있다.
CloudFormation 템플릿은 JSON 또는 YAML포맷의 텍스트 파일이며, 특정 프로젝트 구현에 필요한 AWS리소스를 정의할 수 있다.
CloudFormation 템플릿을 이용해 리소스 스택을 손쉽게 복제 및 전달할 수 있다.
템플릿 작성 방법
- 브라우저 기반 드래그앤드롭 인터페이스 사용
- LAMP 웹서버, WordPress인스턴스 등의 사전 정의된 샘플 템플릿 활용
- 직접 템플릿 작성 후 업로드
CloudFormation 스택이랑 템플릿으로 정의한 리소스 그룹이며, 템플릿을 로딩해 스택을 생성할 수 있다.
스택을 삭제하면 해당 리소스도 모두 제거된다.
스택 생성하기
CloudFormation 템플릿의 Resources 섹션에 우리가 사용하려는 리소스에 대한 내용을 정의할 수 있다.
CloudFormation은 S3버킷에서 템플릿을 읽어올 수 있다.
다수의 스택 활용하기
목적에 따라 인프라 요소를 여러개의 스택으로 나눠서 정의할 수 있다. 리소스 생에주기 및 관리 주체에 따라 스택을 나눠서 정의
중첩 스택
스택간의 상호작용을 구현하는 방식중에 중첩 스택 방식이 있다.
CloudFormation 스택은 AWS 리소스 중 하나이므로, 템플릿 구성을 변경해 스택을 추가로 생성할 수 있다.
스택 업데이트 작업 속성
- 중단 없는 없데이트 : 업데이트 작업 중단 또는 물리적 ID의 변경 없이 일괄적으로 업데이트 진행
- 중단 허용 업데이트 : 다른 리소스의 개입 및 일시적인 중단은 허용하지만 물리적 ID는 변경되지 않는다.
- 대체 : CloudFormation이 아예 새로운 물리적 ID를 지닌 새 리소스를 생성한 뒤, 새 리소스에 대한 의존성 리소스를 표시하고 기존 리소스는 삭제한다.
스택 업데이트시 특정 리소스 제외
스택 생성 시 스택 정책을 사용하면 스택 업데이트 동장 시 특정 리소스만 업데이트에서 제외할 수 있다.
스택 정책은 아래와 같이 구성된다.
Effect,
Action(특정 케이스일때만 업데이트 되도록 설정),
Pricipal(*를 가지며 특정 실행 주체를 지정할 수 없다.) ,
Resource,
Condition(구체적인 리소스 타입 입력)등 으로 구성된다.
CloudFormation 은 특정 업데이트 동작이 스택 정책에 위배되는지 여부를 확인하지 않기 때문에 업데이트시 성공여부를 반드시 확인해야한다.
스택 정책 덮어쓰기
직접 업데이트로 스택 정책을 변경하는 경우, 업데이트 작업이 수행되는 동안에만 일시적으로 스택 정책을 덮어쓰기 할 수 있다.
서드파티 자동화 솔루션
Bash 나 Windows PowerShell을 이용해 인프라 자동화 스크립트를 생성할 수 있으며 이들 스크립트를 이용해 AWS계정에 접속하고 리소스 스택을 생성, 수정, 삭제 할 수 있따.
이들 도구 이외에 puppet, chef, ansible등 서드파티 환경설정 관리 도구를 이용해 AWS인프라를 관리할 수 있다.
AWS OpsWorks : Chef
스택 또는 레이어를 추가해 클라우드 인프라를 구성한다.
opsworks chef 배포에는 하나 이상의 앱이 포함된다. 앱은 스택에서 실행되는 인스턴스에 설치할 애플리케이션 코드와 원격 코드 저장소에 접근하기 위한 메타데이터 등을 가리킨다.
AWS OpsWorks: Puppet
Puppet master서버로 EC2인스턴스를 생성하며 R10k환경 및 모듈을 설정하고 원격 코드 저장소 접근 권한을 부여한다.
인프라 환경설정 검토 및 최적화
클라우드 인프라와 리소스 변경 사항 모니터링에는 다음 네가지 목표를 지닌다.
- 리소스 환경설정의 변경 사항을 관찰한다.
- AWS 서비스의 변경 사항을 관찰한다.
- 수동적으로 애플리케이션의 성능과 가용성을 모니터링 한다.
- 능동적으로 애플리케이션의 성능과 가용성을 검증한다.
AWS Well-Architected Tool
Well-Architected Tool은 우리가 현재 사용중인 AWS 리소스의 효율성 또는 적합성을 정기적으로 점검하기 위한 좋은 도구이다.
6대 기준인 보안성, 내구성, 성능효율성, 비용최적화, 운영우수성, 지속성 등을 기준으로 워크로드에 따른 환경구성의 적절성을 평가한 점수를 제시한다.
로드 테스트
실행중인 인프라에 대한 능동적 모니터링의 대표적인 방법 중 하나가 바로 로드테스트 또는 스트레스 테스트다. 로드 테스트는 통제된 환경에서 인프라에 워크로드를 추가해 나갈 때 리소스와 서비스가 로드 또는 테스트에 어떻게 반응하는지 확인하는 시뮬레이션 테스트이다. 직접 인프라가 처리해야할 트래픽을 높여가며 시행할수도 있고 AWS Marketplace에 등록된 테스트 전용 서드파티 도구를 이용해도 된다.
로드 테스트는 상용 환경을 최대한 유사하게 구현한 테스트 환경에서 시행하는 것이 일반적이다.
시각화
인프라에 대한 능동적 테스트 또는 수동적 테스트 결과는 모두가 원하는 방법으로 이해하기 쉽게 제공해야 한다.
CloudWatch의 대시보드를 잘 활영해서 구성하는것만으로도 인프라를 효과적으로 관리할 수 있다.
데이터 작업 최적화
데이터의 전송 속도를 현격하게 올릴 수 있는 방법은 바로 데이터 캐싱, 데이터 파티셔닝, 데이터 압축, 디커플링 기법 등이 있다.
캐싱
우리가 사용하는 애플리케이션이 S3버킷에 저장된 미디어 파일 또는 관계형 데이터베이스 등의 데이터에 매우 빈번하게 접속한다면, 클라이언트 가까이 이들 데이터의 사본을 생성해 두고 좀 더 신속하게 제공하는 방법이 있다. 캐싱은 바로 이를 위한 기술이다.
서버 내 시스템 메모리에 사본을 두거나, 캐싱 전용 데이터베이스에 사본 데이터를 저장한 뒤 매우 빠른 속도로 제공할 수 있다.
캐싱 사본은 최대 보존 시간이 경과하기 전까지 시스템에 유지되며 TTL 경과 후 해당 버전은 삭제되고, 데이터 소스에서 최신의 캐싱 버전으로 대체된다.
Amazon ElastiCache
ElastiCache 클러스터는 하나 이상의 노드로 구성된다.
노드 수와 인스턴스 타입은 애플리케이션에 대한 클라이언트의 요구 수준에 따라 달라진다.
ElasticCache 클러스터는 Memcached 엔진 또는 Redis 엔진을 이요해서 생성할 수 있다.
Memcached 버전은
설정 및 배포가 간단해서 확장성이 높으며 멀티 스레드 기반이므로 실행 속도도 빠르다. 하지만 해당 버전은 BLOB 객체만 읽고 쓸 수 있는 인메모리 키/밸류 데이터 스토어로서 모든 프로젝트에 적용하기엔 유연성이 부족하다.
Redis 버전의
클러스터는 객체 외에도 문자열, 리스트, 세트 등 다양한 복함 데이터 타입을 지원한다. 데이터는 디스크에 보존되므로 복원 필요시 스냅샷 데이터로 복원할 수 있다.
또한 Redis는 데이터 정렬 및 랭킹 기능을 제공하므로 게임 애플리케이션의 리딩보드 랭킹 구현도 쉽게 할 수 있다.
Redis의 영구 데이터 보존 방식을 이용해 세션 캐싱을 구현하고 성능을 높일 수 있다.
ElasticCache를 사용안한다면
안하고도 캐싱할 수 있는 방법은 EC2인스턴스에서 Varnish와 같은 리버스 프록시를 실행하면된다.
기타 캐싱 솔루션
애플리케이션 레벨에서의 캐싱 외에 우리의 데이터베이스에서 캐싱과 유사한 기법을 사용해 성능을 높일 수 있다.
RDB에서 읽기 사본을 추가해서 데이터베이스의 성능을 높일 수 있다.
혹은 CloudFront를 통해서 클라이언트 인근 엣지 로케이션의 S3에 저장된 미디어 객체의 사본을 생성한 뒤 전세계 사용자에게 매우 빠른 속도로 미디어 콘텐츠를 제공할 수 있다.
데이터 파티셔닝/샤딩
RDS데이터베이스에 대한 트래픽은 지속적으로 증가하는 경향이 있다.
이 경우 수직적 확장은 적용하기 어려운 경우가 많으며, 파티셔닝 또는 샤딩을 이용한 수평적 확장 기법으로 데이터베이스의 응답 속도를 눈에 띄게 높일 수 있다.
샤딩은 DB트래픽을 분산할 수 있는 중요한 수단으로 각 DB서버에서 데이터를 분할하여 저장하는 방식이다.
데이터 압축
네트워크 대역포에 한계가 있고 정기적으로 전송하는 데이터의 크기 또한 쉽게 줄일 수 없을 때 몇 가지 선택안이 있다.
전송 데이터의 크기를 줄이는 방법도 있고 네트워크의 한계를 우회할 방법도 존재한다.
데이터 크기를 줄이기 위해서는 디스크 압축 기술을 사용할 수있다.
압축 작업은 코드를 통해서 진행할 수도 잇지만 AWS 서비스 내에서 압축 작업이 진행되기도 한다. 예를들어 CloudFront가 파일 전송시 자동으로 압축하도록 설정할 수 있다.
네트워크의 한계를 우회할 방법은 Amazon 의 Snowball을 이용
해서 네트워크 전송이 아닌 스토리지 전용 장비로 페타바이트급 데이터를 전송할 수 있다. 대용량 데이터 사본을 암호화된 SnowBall 기기에 저장한 뒤 Amazon으로 돌려보내면 된다. 그러면 S3버킷에서 우리의 데이터를 확인 할 수 있다.
