[고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Performance Efficiency Pillar — AWS Well-Architected Framework 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 2부로 구성되어 있으며 이 글은 2부입니다.
네트워크
특정 시스템에 대한 최적의 네트워크 솔루션은 지연 시간, 처리량 요구 사항에 따라 달라집니다. 사용자 또는 사내 리소스와 같은 물리적 제약은 에지 기술이나 리소스 배치를 사용하여 상쇄할 수 있는 위치 옵션을 구동합니다.
AWS에서는 네트워킹이 가상화되며 다양한 유형과 구성으로 제공됩니다. 이를 통해 네트워킹 방법을 필요에 따라 보다 쉽게 일치시킬 수 있습니다. AWS는 네트워크 트래픽을 최적화하기 위해 제품 기능(예: 향상된 네트워킹 인스턴스 유형, Amazon EBS 최적화 인스턴스, Amazon S3 전송 가속, 동적 CloudFront)을 제공합니다. AWS는 네트워크 거리 또는 지터를 줄이기 위한 네트워킹 기능(예: Amazon Route 53 지연 시간 라우팅, Amazon Virtual Private Cloud(Amazon VPC) endpoints 및 AWS Direct Connect)도 제공합니다.
Location
AWS 클라우드 인프라는 지역 및 가용성 영역을 기반으로 구축됩니다. 영역은 다중 가용성 영역을 가진 전 세계의 물리적 위치입니다.
가용성 영역은 각각 중복 전원, 네트워킹 및 연결을 갖춘 하나 이상의 개별 데이터 센터로 구성되어 있으며, 각각 별도의 시설에 들어 있습니다. 이러한 가용성 영역은 단일 데이터 센터에서보다 고가용성, 내결함성 및 확장성이 뛰어난 프로덕션 애플리케이션 및 데이터베이스를 운영할 수 있는 기능을 제공합니다.
몇 가지 주요 요소를 기반으로 배포에 적합한 영역 또는 영역을 선택합니다.
- 사용자가 있는 위치 : 애플리케이션 사용자와 가까운 지역을 선택하면 애플리케이션을 사용할 때 대기 시간이 줄어듭니다.
- 데이터가 있는 위치 : 데이터가 많은 애플리케이션의 경우, 지연 시간의 주요 병목현상은 데이터가 애플리케이션의 컴퓨팅 부분으로 전송되는 경우입니다. 애플리케이션 코드는 데이터에 최대한 가깝게 실행되어야 합니다.
- 다른 제약 사항 : 보안 및 규정 준수와 같은 제약 조건을 고려합니다.
배치 그룹
Amazon EC2는 네트워킹을 위한 배치 그룹을 제공합니다. 배치 그룹은 단일 가용성 영역 내에 있는 인스턴스의 논리적 그룹입니다. 지원되는 인스턴스 유형이 포함된 배치 그룹을 사용하면 애플리케이션이 대기 시간이 짧은 초당 20기가비트(Gbps) 네트워크에 참여할 수 있습니다. 배치 그룹은 낮은 네트워크 지연 시간, 높은 네트워크 처리량 또는 둘 모두의 이점을 제공하는 애플리케이션에 권장됩니다. 배치 그룹을 사용하면 네트워크 통신에서 지터를 낮출 수 있습니다.
Edge Locations
지연 시간에 민감한 서비스는 에지 위치의 글로벌 네트워크를 사용하여 에지에서 제공됩니다. 이러한 에지 위치는 일반적으로 CDN(Content Delivery Network) 및 DNS(Domain Name System)와 같은 서비스를 제공합니다. 이러한 서비스를 가장자리에 배치하면 컨텐츠 또는 DNS 확인 요청에 짧은 지연 시간으로 응답할 수 있습니다. 또한 이러한 서비스는 콘텐츠의 Geo Targeting(최종 사용자의 위치에 따라 다른 컨텐츠를 제공)과 같은 지리적 서비스를 제공하거나 최종 사용자에게 가장 가까운 지역(최소 지연 시간)으로 직접 라우팅할 수 있습니다.
CloudFront는 이미지, 스크립트, 비디오와 같은 정적 콘텐츠와 API 또는 웹 애플리케이션과 같은 동적 콘텐츠를 모두 가속화하는 데 사용할 수 있는 글로벌 CDN입니다. 이 제품은 컨텐츠를 캐슁하고 사용자에게 고성능 네트워크 연결을 제공하는 글로벌 에지 위치에 의존합니다. CloudFront는 컨텐츠 업로드 및 동적 애플리케이션과 같은 다른 많은 기능도 가속화하여 인터넷을 통해 트래픽을 처리하는 모든 애플리케이션에 성능을 더합니다.
Route 53은 가용성과 확장성이 뛰어난 클라우드 DNS 웹 서비스입니다. www.example.com과 같은 이름을 컴퓨터가 각 연결에 사용하는 192.168.2.1과 같은 숫자 IP 주소로 변환하여 최종 사용자를 인터넷 응용 프로그램으로 라우팅 할 수 있도록 개발자와 비즈니스에 매우 안정적이고 비용 효율적인 방법을 제공하도록 설계되었습니다. 다른. Route 53은 IPv6을 완벽하게 준수합니다.
지연 시간을 줄이고 콘텐츠 캐싱을 활성화하려면 에지 서비스를 사용해야 합니다. 이러한 접근 방식을 최대한 활용하려면 DNS와 HTTP/HTTPS 모두에 대해 캐시 제어를 올바르게 구성했는지 확인해야 합니다.
제품 특징
클라우드 컴퓨팅에서 네트워킹은 매우 중요하므로, 서비스는 일반적으로 네트워크 성능을 최적화할 수 있는 기능을 제공합니다. 네트워크 트래픽을 최적화하려면 EC2 인스턴스 네트워크 기능, 향상된 네트워킹 인스턴스 유형, Amazon EBS에 최적화된 인스턴스, Amazon S3 전송 가속화 및 동적 CloudFront와 같은 제품 기능을 고려해야 합니다.
Amazon S3 컨텐츠 가속화 기능은 CloudFront의 네트워킹 최적화를 통해 외부 사용자가 Amazon S3에 데이터를 업로드할 수 있도록 하는 기능입니다. 따라서 AWS Cloud에 대한 전용 연결이 없는 원격 위치에서 대량의 데이터를 쉽게 전송할 수 있습니다.
EC2 인스턴스는 향상된 네트워킹을 활용할 수도 있습니다. 향상된 네트워킹은 SR-IOV(단일 루트 I/O 가상화)를 사용하여 지원되는 인스턴스 유형에 대해 고성능 네트워킹 기능을 제공합니다. SR-IOV는 기존 가상화된 네트워크 인터페이스보다 높은 I/O 성능과 낮은 CPU 활용률을 제공하는 장치 가상화 방법입니다. 향상된 네트워킹은 더 높은 대역폭, 더 높은 초당 패킷(PPS) 성능을 제공하며 지속적으로 더 낮은 인스턴스 간 지연 시간을 제공합니다.
ENA(Amazon Elastic Network Adapter)는 단일 배치 그룹 내에서 인스턴스에 대해 20Gbps의 네트워크 용량을 제공함으로써 추가 최적화를 제공합니다.
Amazon EBS 최적화 인스턴스는 최적화된 구성 스택을 사용하고 Amazon EBS I/O에 추가 전용 용량을 제공합니다. 이 최적화는 Amazon EBS I/O와 사용자 인스턴스의 다른 트래픽 사이의 경합을 최소화하여 EBS 볼륨에 최고의 성능을 제공합니다.
네트워킹 기능
클라우드에서 솔루션을 설계할 때는 네트워크 거리 또는 지터를 줄이기 위한 네트워킹 기능을 고려해야 합니다.
Route 53의 지연 시간 기반 라우팅 (LBR)은 전 세계 잠재 고객의 애플리케이션 성능을 향상시키는 데 도움이됩니다. LBR은 고객이 애플리케이션을 실행중인 다른 AWS 리전의 실제 성능 측정을 기반으로 가장 빠른 경험을 제공하는 AWS 엔드 포인트 (EC2 인스턴스, 탄력적 IP 주소 또는 ELB로드 밸런서)로 고객을 라우팅함으로써 작동합니다.
AWS Direct Connect는 50Mbps에서 최대 10Gbps까지 AWS 환경에 대한 전용 연결을 제공합니다. 이를 통해 관리 및 제어되는 지연 시간 및 프로비저닝된 대역폭을 제공하므로 애플리케이션이 다른 환경에 쉽고 성능적으로 연결할 수 있습니다. AWS Direct Connect 파트너 중 하나를 사용하면 여러 환경에서 엔드 투 엔드 연결을 통해 일관된 성능을 갖춘 확장 네트워크를 제공할 수 있습니다.
Amazon VPC 엔드 포인트는 인터넷 게이트웨이 또는 NAT(네트워크 주소 변환) 인스턴스 없이도 AWS 서비스(예: Amazon S3)에 안정적으로 연결할 수 있습니다. VPC 엔드 포인트를 사용하면 VPC와 다른 AWS 서비스 간의 데이터가 Amazon 네트워크 내에서 전송되므로 인터넷 트래픽으로부터 인스턴스를 보호할 수 있습니다.
서비스 컨텐츠에 여러 인스턴스를 사용하려는 스케일아웃 아키텍처를 구현할 때 Amazon VPC 내에서 로드 밸런서를 활용할 수 있습니다. AWS는 ELB 서비스에서 응용 프로그램에 대한 여러 모델을 제공합니다. 애플리케이션 로드 밸런서는 HTTP 및 HTTPS 트래픽의 로드 밸런싱에 가장 적합하며 마이크로서비스 및 컨테이너를 비롯한 최신 애플리케이션 아키텍처의 제공을 목표로 하는 고급 요청 라우팅을 제공합니다.
네트워크 로드 밸런서는 성능이 매우 필요한 TCP 트래픽의 로드 밸런싱에 가장 적합합니다. 초저대 지연 시간을 유지하면서 초당 수백만 건의 요청을 처리할 수 있으며, 갑작스럽고 변덕스러운 트래픽 패턴을 처리하도록 최적화되어 있습니다.
주요 AWS 서비스
네트워킹 솔루션의 주요 AWS 서비스는 Route 53으로 지연 시간 기반 라우팅을 제공합니다. 또한 Amazon VPC 엔드 포인트 및 AWS Direct Connect를 사용하면 네트워크 거리 또는 지터를 줄일 수 있습니다.
Resources
네트워킹에 대한 AWS 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하시기 바랍니다.
Documentation
검토
솔루션을 처음 설계할 때는 선택할 수 있는 고정된 옵션 집합이 있습니다. 시간이 지나면서 아키텍처의 성능을 향상시킬 수 있는 새로운 기술과 접근 방식을 사용할 수 있게 됩니다. AWS Cloud에서는 인프라가 코드이기 때문에 새로운 기능과 서비스를 실험하기가 훨씬 쉽습니다.
AWS를 사용하면 고객의 요구에 따른 지속적인 혁신을 활용할 수 있습니다. 가격을 낮추고 새로운 지역, 엣지 로케이션, 서비스 및 기능을 정기적으로 출시합니다. 이러한 새로운 릴리스는 아키텍처의 성능 효율성을 긍정적으로 향상시킬 수 있습니다.
아키텍처 접근 방식을 확인한 후에는 벤치마킹 및 로드 테스트 데이터를 사용하여 리소스 유형 및 구성 옵션을 선택해야 합니다.
아키텍처에 데이터 중심 접근 방식을 채택하려면 다음 사항을 위탁하는 성능 검토 프로세스를 구현해야 합니다.
- Infrastructure as code: AWS CloudFormation 템플릿과 같은 접근 방식을 사용하여 인프라를 코드로 정의합니다. 템플릿을 사용하면 애플리케이션 코드 및 구성과 함께 인프라를 소스 제어에 배치할 수 있습니다. 이를 통해 소프트웨어를 개발하는 데 사용하는 것과 동일한 관행을 인프라에 적용하여 신속하게 반복할 수 있습니다.
- 배포 파이프 라인: 지속적인 통합/연속 구축(CI/CD) 파이프라인(예: 소스 코드 저장소, 빌드 시스템, 배포 및 테스트 자동화)을 사용하여 인프라를 구축할 수 있습니다. 따라서 반복할 때 반복 가능하고 일관되며 저렴한 방식으로 구축할 수 있습니다.
- 잘 정의된 메트릭: 핵심 성과 지표 (KPI)를 포착하기 위해 지표와 모니터링을 설정하십시오. 기술 및 비즈니스 메트릭을 모두 사용하는 것이 좋습니다. 웹 사이트 또는 모바일 앱의 경우 주요 지표는 첫 바이트 또는 렌더링 시간을 캡처합니다. 일반적으로 적용 가능한 다른 메트릭에는 스레드 수, 가비지 수집 속도 및 대기 상태가 포함됩니다. 요청 당 누계 누적 비용과 같은 비즈니스 메트릭을 통해 비용을 줄이는 방법을 알릴 수 있습니다. 메트릭 해석 방법을 신중하게 고려하십시오. 예를 들어 평균 대신 최대 또는 99 번째 백분위 수를 선택할 수 있습니다.
- 자동 성능 테스트: 배포 프로세스의 일부로 실행 중인 테스트가 성공적으로 통과된 후 성능 테스트를 자동으로 트리거 합니다. 자동화는 새로운 환경을 생성하고 테스트 데이터와 같은 초기 조건을 설정한 다음 일련의 벤치마크 및 로드 테스트를 실행해야 합니다. 이러한 테스트의 결과는 시간에 따른 성능 변화를 추적할 수 있도록 빌드에 다시 연결되어야 합니다. 장기 실행 테스트의 경우 파이프라인의 이 부분을 나머지 빌드에서 비동기식으로 만들 수 있습니다. 또는 Amazon EC2 스폿 인스턴스를 사용하여 밤새 성능 테스트를 실행할 수 있습니다.
- 부하 생성: 통합 또는 사전 기록된 사용자 이동 경로를 복제하는 일련의 테스트 스크립트를 생성해야 합니다. 이러한 스크립트는 잠재력이 있고 결합되지 않아야 하며 올바른 결과를 얻으려면 “예비 워밍업” 스크립트를 포함해야 할 수 있습니다. 가능한 한 테스트 스크립트가 운영 환경에서 사용 동작을 복제하도록 합니다. 소프트웨어 또는 SaaS(Software as a Service) 솔루션을 사용하여 로드를 생성할 수 있습니다. AWS 마켓플레이스 솔루션과 스폿 인스턴스를 사용하는 것을 고려합니다. 이러한 방식은 부하를 발생시키는 비용 효율적인 방법이 될 수 있습니다.
- 성능 가시성: 특히 각 빌드 버전에 대한 메트릭을 팀에서 확인할 수 있어야 합니다. 따라서 시간이 지남에 따라 상당한 양의 또는 부정적인 추세를 볼 수 있습니다. 또한 오류 또는 예외 수에 대한 메트릭을 표시하여 작업 시스템을 테스트하고 있는지 확인해야 합니다.
- 시각화: 성능 문제, 핫 스폿, 대기 상태 또는 낮은 활용률을 나타내는 시각화 기술을 사용합니다. 아키텍처 다이어그램에 성능 메트릭을 오버레이하면, 통화 그래프 또는 코드를 통해 문제를 보다 신속하게 식별할 수 있습니다.
이 성능 검토 프로세스는 기존 구축 파이프라인의 단순한 확장으로 구현된 후 테스트 요구 사항이 더욱 정교해짐에 따라 시간이 지남에 따라 진화할 수 있습니다. 미래의 아키텍처에서는 접근 방식을 일반화하고 동일한 프로세스와 아티팩트를 재사용할 수 있어야 합니다.
아키텍처의 성능이 좋지 않을 경우 이는 일반적으로 성능 검토 프로세스가 시행되지 않았거나 중단되었기 때문입니다. 아키텍처의 성능이 좋지 않은 경우 이 성능 검토 프로세스를 수행하면 Deming의 PDCA(계획 수행 검사 수행) 사이클을 적용하여 반복적인 개선을 추진할 수 있습니다.
벤치마킹
벤치마킹은 복합 테스트를 사용하여 구성 요소의 성능에 대한 데이터를 제공합니다. 이 섹션에서는 벤치마킹을 사용하여 워크로드를 개선하는 방법에 대해 설명합니다. 다른 벤더의 제품 또는 구현을 비교하기 위한 벤치마킹 사용은 다루지 않습니다.
벤치마킹은 일반적으로 로드 테스트보다 설정 속도가 빠르며 특정 구성 요소에 대한 기술을 평가하고자 할 때 사용됩니다. 벤치마킹은 테스트를 로드할 수 있는 전체 솔루션이 아직 없을 때 새 프로젝트의 시작 부분에서 자주 사용됩니다.
벤치마킹의 경우 성능 검토 프로세스를 따라야 합니다. 하지만 구축 파이프라인은 벤치마크 테스트 자체로 구성됩니다. 사용자 지정 벤치마크 테스트를 직접 작성하거나, TPC-DS와 같은 업계 표준 테스트를 사용하여 데이터 웨어하우징 워크로드를 벤치마킹할 수 있습니다. 업계 벤치마크는 여러 환경을 비교할 때 유용합니다. 사용자 지정 벤치마크는 아키텍처에서 수행할 것으로 예상되는 특정 유형의 작업을 대상으로 하는 데 유용합니다.
벤치마킹에서는 일반적으로 테스트 환경을 사전 예열하여 유효한 결과를 확보하는 것이 더 중요합니다. 동일한 벤치마크를 여러 번 실행해야 시간이 지남에 따라 차이가 있는지 확인할 수 있습니다.
벤치마크는 일반적으로 로드 테스트보다 실행 속도가 더 빠르기 때문에 구축 파이프라인에서 더 일찍 사용하여 팀에게 성능 편차에 대한 피드백을 더 빠르게 제공할 수 있습니다. 구성 요소 또는 서비스의 중요한 변화를 평가할 때 벤치마크는 벤치마크된 차이점을 기반으로 변경 노력을 정당화할 수 있는지 여부를 신속하게 확인할 수 있습니다. 로드 테스트는 전체 워크로드의 운영 성능을 알려주기 때문에 로드 테스트와 함께 벤치마킹을 사용해야 합니다.
주요 AWS 서비스
벤치마킹을 지원하는 주요 AWS 서비스는 AWS CodeDeploy 및 AWS CloudFormation입니다. 이러한 서비스를 사용하여 반복 가능한 방식으로 인프라 테스트를 자동화할 수 있습니다.
Resources
벤치마킹을 위한 AWS 모범 사례에 대한 자세한 내용은 다음 자료를 참조하시기 바랍니다.
Videos
Documentation
부하 테스트
로드 테스트는 실제 워크로드를 사용하므로 전체 솔루션이 프로덕션 환경에서 어떻게 작동하는지 확인할 수 있습니다. 로드 테스트는 프로덕션 데이터의 통합 버전 또는 제거된 버전을 사용하여 수행해야 합니다(민감한 정보 또는 식별 정보 제거). 전체 아키텍처를 실행하는 규모에 따라 재생되거나 미리 프로그래밍된 사용자 이동 경로를 애플리케이션 전체로 사용할 수 있습니다. 제공 파이프라인의 일부로 로드 테스트를 자동으로 수행하고 미리 정의된 KPI 및 임계값과 비교하여 필요한 성능을 지속적으로 얻을 수 있습니다.
Amazon CloudWatch는 아키텍처의 리소스 전반에서 메트릭을 수집할 수 있습니다. 또한 비즈니스 또는 파생 메트릭을 표면화하는 사용자 정의 메트릭을 수집하고 게시할 수도 있습니다. CloudWatch를 사용하면 테스트가 예상 성능을 벗어났음을 알리기 위해 임계값을 위반할 때를 나타내는 경보를 설정할 수 있습니다.
AWS 서비스를 사용하면 프로덕션 확장 환경을 실행하여 아키텍처를 적극적으로 테스트할 수 있습니다. 테스트 환경은 필요할 때만 비용을 지불하므로 사내 환경 사용 비용의 극히 적은 비용으로 전체 테스트를 수행할 수 있습니다. AWS Cloud를 활용하여 워크로드가 비선형적으로 확장되지 않거나 확장되지 않는 부분을 테스트해야 합니다. 스폿 인스턴스를 사용하여 낮은 비용으로 로드를 생성하고 운영 환경에 익숙해지기 전에 병목 현상을 발견할 수 있습니다.
아키텍처에 대한 중요 사용자 사례를 작성할 때 각 중요 사례가 얼마나 빨리 실행되어야 하는지와 같은 성능 요구 사항을 포함해야 합니다. 이러한 중요 사례의 경우 스크립트로 작성된 사용자 이동 경로를 추가로 구축하여 해당 사례의 요구 사항에 맞는 성능을 파악할 수 있어야 합니다.
로드 테스트를 실행하는 데 상당한 시간이 걸리는 경우 테스트 환경의 여러 복사본을 사용하여 병렬로 테스트해야 합니다. 비용은 비슷하지만 테스트 시간은 줄어듭니다. (EC2 인스턴스 하나를 100시간 동안 실행하는 것과 한 시간 동안 100개의 인스턴스를 실행하는 것은 동일합니다.) 또한 스폿 인스턴스를 사용하고 프로덕션에 사용하는 지역보다 비용이 낮은 지역을 선택하여 이러한 테스트 비용을 절감할 수 있습니다.
부하 테스트 클라이언트의 위치는 최종 사용자의 지리적 확산을 반영해야 합니다.
주요 AWS 서비스
로드 테스트를 지원하는 주요 AWS 서비스는 CloudWatch로, 로드 테스트 중에 전체 아키텍처가 어떻게 수행되는지에 대한 메트릭스를 수집할 수 있습니다. CloudWatch를 사용하면 사용자 지정 및 비즈니스 메트릭스를 생성할 수도 있습니다.
Resources
로드 테스트를 위한 AWS 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하시기 바랍니다.
Documentation
모니터링
아키텍처를 구현한 후에는 성능을 모니터링하여 고객이 문제를 인식하기 전에 문제를 해결할 수 있어야 합니다. 모니터링 메트릭을 사용하여 임계값을 위반할 때 경보를 발생시켜야 합니다. 알람은 성능이 나쁜 모든 구성요소를 대상으로 자동 작업을 트리거할 수 있습니다.
CloudWatch는 알림 경보를 모니터링하고 전송할 수 있는 기능을 제공합니다. 자동화를 사용하여 Amazon Kinesis, Amazon SQS(Amazon Simple Queue Service) 및 AWS Lambda를 통해 작업을 트리거하여 성능 문제를 해결할 수 있습니다.
능동적과 수동적
모니터링 솔루션은 능동 모니터링(AM)과 수동 모니터링(PM)의 두 가지 유형으로 나뉩니다. AM과 PM은 서로 보완하여 워크로드의 성능을 전체적으로 파악할 수 있습니다.
능동적 모니터링은 스크립트로 작성된 사용자 이동 경로에서 제품의 중요 경로를 통해 사용자 작업을 시뮬레이션합니다. AM은 워크로드의 성능과 가용성을 테스트하기 위해 지속적으로 수행되어야 합니다. AM은 지속적이고 가벼우며 예측 가능한 PM을 보완합니다. 모든 환경(특히 사전 프로덕션 환경)에서 실행되어 최종 사용자에게 영향을 미치기 전에 문제 또는 성능 문제를 식별할 수 있습니다.
수동적 모니터링은 일반적으로 웹 기반 워크로드에 사용됩니다. PM은 브라우저에서 성능 메트릭을 수집합니다(비 웹 기반 워크로드도 유사한 접근 방식을 사용할 수 있음). 모든 사용자(또는 사용자 부분 집합), 지리, 브라우저 및 장치 유형에서 메트릭을 수집할 수 있습니다. PM을 사용하여 다음 문제를 이해해야 합니다.
- 사용자 경험 성능 : PM은 사용자가 겪고 있는 작업에 대한 메트릭스를 제공하므로 프로덕션의 작동 방식을 지속적으로 볼 수 있을 뿐 아니라 시간이 지남에 따라 변화가 미치는 영향을 파악할 수 있습니다.
- 지리적 성능 변동성 : 워크로드에 글로벌 풋프린트가 있고 사용자가 전 세계에서 애플리케이션에 액세스하는 경우 PM을 사용하면 특정 지역의 사용자에게 영향을 미치는 성능 문제를 발견할 수 있습니다.
- API 사용의 영향 : 최신 워크로드는 내부 API 및 타사 API를 사용합니다. PM은 API 사용에 대한 가시성을 제공하므로 내부 API뿐 아니라 타사 API 공급자로부터 발생하는 성능 병목 현상을 식별할 수 있습니다.
단계
AWS에서의 모니터링은 다섯 가지 개별 단계로 구성되어 있으며, AWS의 안정성 백서에 자세히 설명되어 있습니다.
- 생성 — 모니터링 범위, 메트릭 및 임계 값
- 집계 — 여러 소스에서 완전한 보기 작성
- 실시간 처리 및 경보 — 인식 및 응답
- 스토리지 — 데이터 관리 및 보존 정책
- 분석 — 대시 보드, 보고 및 통찰력
CloudWatch는 AWS Cloud 리소스 및 AWS에서 실행되는 워크로드를 모니터링하는 서비스입니다. CloudWatch를 사용하여 메트릭을 수집 및 추적하고 로그 파일을 수집 및 모니터링하고 경보를 설정할 수 있습니다. CloudWatch는 EC2 인스턴스 및 RDS DB 인스턴스 같은 AWS 리소스와 애플리케이션 및 서비스에서 생성된 사용자 지정 메트릭과 애플리케이션에서 생성한 로그 파일을 모니터링할 수 있습니다. CloudWatch를 사용하면 리소스 활용도, 애플리케이션 성능 및 운영 상태에 대한 시스템 차원의 가시성을 확보할 수 있습니다. 이러한 통찰력을 사용하여 신속하게 대응하고 애플리케이션이 원활하게 실행되도록 할 수 있습니다.
CloudWatch 대시보드를 사용하면 AWS 리소스 및 사용자 지정 메트릭의 재사용 가능한 그래프를 생성하여 운영 상태를 모니터링하고 문제를 한 눈에 식별할 수 있습니다.
잘못된 긍정이 너무 많거나 데이터에 압도되지 않도록 하는 것이 효과적인 모니터링 솔루션의 핵심입니다. 자동 트리거는 사용자 오류를 방지하고 문제를 해결하는 데 걸리는 시간을 줄일 수 있습니다. 프로덕션 환경에서 시뮬레이션을 수행하는 게임 요일을 계획하여 알람 솔루션을 테스트하고 문제가 올바르게 인식되는지 확인합니다.
주요 AWS 서비스
모니터링을 지원하는 주요 AWS 서비스는 Amazon CloudWatch로, 확장 작업을 트리거할 수 있는 경보를 쉽게 생성할 수 있습니다. 다음 서비스 및 기능도 중요합니다.
- Amazon S3는 스토리지 계층 역할을 하며 라이프사이클 정책 및 데이터 관리를 지원합니다.
- Amazon EMR은 메트릭을 분석하여 성능을 모니터링할 수 있습니다.
Resources
성능 효율성을 높이기 위한 AWS Best Practice에 대해 자세히 알아보려면 다음 리소스를 참조하시기 바랍니다.
Videos
- AWS re:Invent 2015 | (DVO315) Log, Monitor and Analyze your IT with Amazon CloudWatch
- AWS re:Invent 2015 | (BDT312) Application Monitoring: Why Data Context Is Critical
Documentation
Trade-Offs
솔루션을 설계할 때는 최적의 접근 방식을 보장할 수 있도록 절충에 대해 생각해 보아야 합니다. 상황에 따라 일관성, 내구성 및 공간과 시간 또는 지연 시간을 교환하여 더 높은 성능을 제공할 수 있습니다.
AWS를 사용하면 몇 분 만에 글로벌에 진출하고 전 세계 여러 위치에 리소스를 배치하여 최종 사용자에게 보다 가까이 다가갈 수 있습니다. 또한 데이터베이스 시스템과 같은 정보 저장소에 읽기 전용 복제본을 동적으로 추가하여 기본 데이터베이스의 로드를 줄일 수 있습니다. 또한 AWS는 메모리 내 데이터 저장소 또는 캐시를 제공하는 Amazon ElastiCache와 정적 콘텐츠 복사본을 최종 사용자에게 더 가깝게 캐시하는 CloudFront와 같은 캐싱 솔루션도 제공합니다.
다음 섹션에서는 사용자가 할 수 있는 몇 가지 균형과 이를 구현하는 방법을 자세히 설명합니다.
캐싱
대부분의 워크로드는 진실의 근원 또는 통합 된 데이터보기를 제공하는 서비스 또는 데이터베이스와 같은 종속 구성 요소에 의존합니다. 일반적으로 이러한 아키텍처 구성 요소는 확장하기가 어렵고 워크로드 비용의 상당 부분을 나타냅니다. 캐싱을 사용하여 최신 상태 나 사용 된 메모리와 균형을 이루어 성능 효율성을 향상시킬 수 있습니다. 이러한 기술은 일반적으로 비동기식 또는 주기적으로 업데이트됩니다. 단점은 데이터가 항상 최신 정보가 아니기 때문에 항상 진실의 원천과 일치하지는 않는다는 것입니다.
애플리케이션 레벨
응용 프로그램 레벨 캐시 또는 기억을 사용하여 코드 레벨에서 이 절충을 수행 할 수 있습니다. 요청이 캐시 되면 실행 시간이 줄어 듭니다. 이를 통해 캐싱 레이어를 통해 수평으로 확장하고 가장 많이 사용되는 구성 요소의 부하를 줄일 수 있습니다.
메모리 내 및 분산 캐시는 크게 두 가지 경우에 사용됩니다. 즉, 애플리케이션의 사용자 세션과 같은 별개의 서버 간에 과도 데이터 및 상태를 조정하거나 메모리에서 직접 요청된 요소를 제공하여 읽기 집약적인 워크로드로부터 데이터베이스를 보호합니다.
Redis, Memcached 또는 Varnish와 같은 플랫폼은 Amazon EC2에 배포할 수 있으며 애플리케이션에 강력한 캐싱 엔진을 제공합니다. 이러한 플랫폼의 설계 및 규모는 일반적으로 인스턴스의 메모리를 기반으로 하며, 클러스터 모델을 활성화하려는 경우(예: Redis 클러스터링, ElastiCache-정합 해싱) 애플리케이션에서 적절한 키 관리를 설계합니다.
Amazon ElastiCache는 클라우드에서 메모리 내 데이터 저장소 또는 캐시를 쉽게 배포, 운영 및 확장할 수 있는 웹 서비스입니다. Memcached가 포함된 ElastiCache는 여러 노드로 메모리 내 캐시를 확장하는 샤딩을 지원합니다. Redis용 ElastiCache에는 클러스터링이 포함되어 있으며, 여러 개의 시드가 테라바이트 크기의 단일 메모리 내 키 값 저장소를 형성하고 있으며, 데이터 액세스 성능을 높이기 위해 샤드당 읽기 복제본을 구성합니다.
ElastiCache는 환경 확장, 자동 페일오버, 패치 적용 및 백업을 지원하는 완전히 관리되는 서비스입니다.
데이터베이스 레벨
데이터베이스 복제본은 마스터 데이터베이스에 대한 모든 변경 내용을 복제본(오라클 또는 SQL Server에서는 사용할 수 없음)으로 복제하여 성능 데이터베이스를 향상시킵니다. 이러한 복제를 통해 읽기 집약적인 데이터베이스 워크로드를 위해 단일 데이터베이스의 용량 제약 조건을 넘어 확장할 수 있습니다.
Amazon RDS는 읽기 복제본을 완전하게 관리되는 서비스로 제공합니다. 지정된 소스 데이터베이스의 복제본을 하나 이상 생성하고 데이터의 여러 복사본에서 대량 애플리케이션 읽기 트래픽을 제공하여 총 읽기 처리량을 높일 수 있습니다. 또한 데이터베이스 엔진이 지원하는 읽기 복제본에 인덱스를 추가해야 합니다. 예를 들어 MySQL 읽기 복제본에 인덱스를 추가할 수 있습니다. 지연 시간에 민감한 워크로드의 경우 다중 AZ 기능을 사용하여 가용성 영역 간 트래픽을 줄이기 위해 읽기 복제본이 있어야 하는 가용성 영역을 지정해야 합니다.
지리적 레벨
캐싱의 또 다른 예는 CDN을 사용하는 것입니다. 이는 클라이언트의 지연 시간을 줄이는 좋은 방법입니다. CDN은 정적 콘텐츠를 저장하고 동적 콘텐츠를 가속화하기 위해 사용해야 합니다. API에 CDN을 사용하는 것이 좋습니다. 동적 콘텐츠도 네트워크 최적화 방법을 사용하면 이점을 얻을 수 있습니다.
CloudFront는 글로벌 에지 위치 네트워크를 사용하여 동적, 정적, 스트리밍 및 대화형 콘텐츠를 포함한 전체 웹 사이트를 제공하는 데 사용할 수 있습니다. 컨텐츠에 대한 요청은 가장 가까운 에지 위치로 자동으로 라우팅되므로 콘텐츠는 최상의 성능을 제공합니다.
CloudFront는 Amazon S3, Amazon EC2, ELB 및 Route 53과 같은 다른 AWS 서비스와 작동하도록 최적화되었습니다. CloudFront는 또한 파일의 원본 및 최종 버전을 저장하는 비 AWS 오리진 서버와 원활하게 작동합니다.
주요 AWS 서비스
캐싱 솔루션의 핵심 AWS 서비스는 범용 애플리케이션 캐시를 제공하는 ElastiCache와 사용자에게 더 가까운 정보를 캐싱할 수 있는 CloudFront입니다.
Resources
캐싱에 대한 AWS 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하시기 바랍니다.
Documentation
Video
파티셔닝 또는 샤딩
일관성 제약으로 인해 단일 인스턴스가 필요한 관계형 데이터베이스와 같은 기술을 사용할 경우(고급 규격 인스턴스 및 스토리지 기능을 사용하여) 수직으로만 확장할 수 있습니다. 수직 확장 한계에 도달하면 데이터 분할 또는 샤딩이라는 다른 접근 방식을 사용할 수 있습니다. 이 모델을 사용하면 데이터가 여러 데이터베이스 스키마로 분할되고 각 데이터베이스는 자체적인 기본 DB 인스턴스에서 실행됩니다.
Amazon RDS는 여러 인스턴스를 실행하는 데 따른 운영 오버헤드를 제거하지만, 샤딩을 수행하면 애플리케이션이 여전히 복잡해집니다. 올바른 인스턴스로 쿼리할 수 있도록 데이터가 분할되는 방식을 인식하려면 애플리케이션의 데이터 액세스 계층을 수정해야 합니다. 프록시 또는 라우팅 메커니즘을 사용하여 애플리케이션에서 캐싱 코드를 제거하거나 데이터 액세스 계층에서 구현할 수 있습니다. 또한 스키마 변경은 여러 데이터베이스 스키마에서 수행되어야 하므로 이 프로세스를 자동화하기 위해 어느 정도의 노력을 기울일 필요가 있습니다.
일반적으로 NoSQL 데이터베이스 엔진은 데이터 파티션 분할 및 복제를 수행하여 읽기 및 쓰기를 수평으로 확장합니다. 이러한 작업은 애플리케이션의 데이터 액세스 계층에서 데이터 분할 논리를 구현할 필요 없이 투명하게 수행됩니다. 특히 Amazon DynamoDB는 테이블 크기가 커지거나 읽기 및 쓰기 프로비저닝 용량이 변경될 때 새 파티션을 추가하여 테이블 파티션을 자동으로 관리합니다.
파티셔닝 또는 쉐이딩은 쓰기 작업량이 많은 워크로드를 확장할 수 있는 방법을 제공하지만 모든 파티션이나 파드에 걸쳐 데이터를 균등하게 분산하고 액세스해야 합니다. 관계형 데이터베이스 솔루션의 복잡성을 유발할 수 있으며, 일반적으로 NoSQL 솔루션은 일관성을 거래하여 이를 제공할 수 있습니다.
주요 AWS 서비스
파티셔닝 또는 샤딩을 위한 주요 AWS 서비스는 자동으로 테이블 파티셔닝을 관리하는 Amazon DynamoDB입니다.
Resources
AWS의 파티션 분할 및 샤딩 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하시기 바랍니다.
Documentation
Video
압축
데이터를 압축하면 컴퓨팅 시간을 공간과 교환할 수 있으며 스토리지 및 네트워킹 요구 사항을 크게 줄일 수 있습니다. 압축은 파일 시스템, 데이터 파일 및 스타일시트 및 이미지와 같은 웹 리소스뿐 아니라 API와 같은 동적 응답에도 적용될 수 있습니다.
CloudFront는 가장자리에서의 압축을 지원합니다. 소스 시스템은 표준 방식으로 리소스를 제공할 수 있으며 CDN은 웹 클라이언트가 리소스를 지원할 수 있는 경우에만 자동으로 리소스를 압축합니다.
클라우드 내부 또는 외부로 대량의 정보를 전송할 때는 비네트워크 기반 솔루션을 고려해야 합니다. AWS Snowball은 보안 어플라이언스를 사용하여 대량의 데이터를 AWS Cloud로 전송하는 페타바이트 규모의 데이터 전송 솔루션입니다. AWS Snowball을 사용하면 높은 네트워크 비용, 긴 전송 시간, 보안 문제 등 대규모 데이터 전송과 관련된 일반적인 문제를 해결할 수 있습니다.
Amazon Redshift는 Columnar 데이터 스토리지와 함께 압축을 사용합니다. 데이터를 일련의 행으로 저장하는 대신 Amazon Redshift는 데이터를 열별로 구성합니다. 유사한 데이터가 Disk에 순차적으로 저장되므로 열 데이터 저장소를 행 기반 데이터 저장소보다 훨씬 더 많이 압축할 수 있습니다. Amazon Redshift는 여러 압축 기술을 사용하며, 종종 기존의 관계형 데이터 저장소에 비해 상당한 압축을 달성할 수 있습니다. 빈 테이블에 데이터를 로드할 때 Amazon Redshift는 자동으로 데이터를 샘플링하고 가장 적절한 압축 방식을 선택합니다.
주요 AWS 서비스
압축을 위한 핵심 AWS 서비스는 엣지에서의 압축을 지원하는 CloudFront입니다.
Resources
압축에 대한 AWS 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하시기 바랍니다.
Documentation
- Amazon CloudFront: Serving Compressed Files
- Amazon RedShift: Columnar Storage
- AWS Snowball: What Is AWS Snowball?
버퍼링
버퍼링은 대기열을 사용하여 생산자의 메시지(작업 단위)를 수락합니다. 복원력을 위해 대기열은 내구성을 갖춘 스토리지를 사용해야 합니다. 버퍼는 애플리케이션이 시간에 따라 다른 속도로 실행될 때 서로 통신할 수 있도록 하는 메커니즘입니다. 그런 다음, 메시지는 소비자가 읽을 수 있으며, 이를 통해 고객의 비즈니스 요구 사항을 충족하는 속도로 실행될 수 있습니다. 버퍼를 사용하면 생산자의 처리량을 소비자와 분리할 수 있습니다. 생산자가 데이터 내구성 및 역압(소비자가 느리게 작동하기 때문에 생산자가 느려지는 현상)에 대해 걱정할 필요가 없습니다.
즉시 처리할 필요가 없는 상당한 쓰기 로드를 생성하는 워크로드가 있는 경우 버퍼를 사용하여 소비자에 대한 수요를 완화할 수 있습니다.
AWS에서는 여러 서비스에서 버퍼링 접근 방식을 구현하도록 선택할 수 있습니다. Amazon SQS는 단일 소비자가 개별 메시지를 읽을 수 있는 대기열을 제공합니다. 아마존 키네시스는 많은 소비자들이 동일한 메시지를 읽을 수 있는 스트림을 제공합니다.
Amazon SQS 큐는 처리 대기 중인 메시지의 안정적이고 확장 가능하며 완전히 관리되는 저장소입니다. Amazon SQS를 사용하면 응용 프로그램에서 한 구성 요소가 생성한 메시지를 빠르고 안정적으로 대기시켜 다른 구성 요소가 사용할 수 있습니다. 이 접근 방식을 위해 생산자가 메시지를 게시하고 잘 알려진 주소에 상주하는 큐가 생성됩니다.
제작자는 비용을 절감하기 위해 Amazon SQS 배치 API 작업을 사용하여 메시지를 게시합니다. 소비자들은 인스턴스의 장애에 대처하기 위해 EC2 인스턴스의 고정 크기 자동 확장 그룹을 사용하여 잘 알려진 큐의 메시지를 읽습니다. 긴 폴링을 사용하면 Amazon SQS 대기열에서 메시지를 사용할 수 있는 즉시 검색할 수 있습니다. 긴 폴링을 사용하여 메시지 검색 비용을 줄입니다. Amazon SQS는 메시지 표시 기능을 사용하여 읽은 메시지를 숨깁니다.
메시지 가시성은 동일한 메시지를 두 번 처리할 수 있는 위험을 줄이지만 기본적으로 메시지를 한 번 이상 받을 수 있다는 것을 의미한다는 것을 알아야 합니다.
정확히 한 번 처리해야 하는 경우 먼저 FIFO(Amazon SQS) 대기열을 사용할 수 있습니다. 메시지 가시성을 통해 처리되지 않은 메시지가 다시 나타날 수 있습니다(예: 인스턴스 오류의 경우). 장시간 실행 중인 작업의 경우 가시성 제한 시간을 연장할 수 있습니다. 메시지가 처리된 후 응용 프로그램에서 메시지를 삭제해야 합니다.
다른 방법은 Amazon Kinesis를 사용하여 버퍼링을 제공하는 것입니다. 여러 소비자가 한 번에 동일한 메시지를 읽을 수 있다는 점에서 Amazon SQS와 다릅니다. 그러나 단일 메시지는 Kinesis Client Library(AWS Lambda)를 사용하여 읽히고, 스트림에 연결할 때 소비자가 제공하는 이름인 응용 프로그램을 위해 1개 및 1개 소비자에게 전달됩니다. 다른 응용 프로그램은 모두 동일한 메시지를 동시에 사용할 수 있으며 “게시 및 구독” 모델을 제공합니다.
버퍼를 사용하여 설계할 때는 두 가지 주요 고려 사항을 염두에 두어야 합니다. 첫째, 작업 생산과 작업 소비 사이에 허용되는 지연은 얼마입니까? 둘째, 중복된 업무 요청을 어떻게 처리할 계획입니까?
더 많은 소비자가 작업 항목을 소비하는 속도를 최적화하기 위해 스폿 인스턴스를 사용할 수 있습니다. 스폿 인스턴스를 사용하여 예비 Amazon EC2 컴퓨팅 용량에 입찰할 수 있습니다. Amazon SQS에서 중복된 메시지를 처리하려면, 정확히 한 번에 처리하는 기능을 제공하는 FIFO(First-out) 대기열을 먼저 사용하는 것이 좋습니다.
주요 AWS 서비스
버퍼링의 핵심 AWS 서비스는 대기열을 사용하여 생산자를 소비자와 분리할 수 있는 Amazon SQS입니다.
Resources
버퍼링에 대한 AWS 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하시기 바랍니다.
Documentation
결론
성능 효율성을 달성하고 유지하려면 데이터 중심의 접근 방식이 필요합니다. 성능을 향상시키기 위해 최적화할 수 있는 액세스 패턴 및 절충을 적극적으로 고려해야 합니다. 벤치마크 및 로드 테스트를 기반으로 검토 프로세스를 사용하면 적절한 리소스 유형 및 구성을 선택할 수 있습니다. 인프라를 코드로 처리하면 아키텍처를 신속하고 안전하게 발전시키는 동시에 데이터를 사용하여 아키텍처에 대한 사실 기반 결정을 내릴 수 있습니다. 능동 모니터링과 수동 모니터링을 함께 사용하면 시간이 지남에 따라 아키텍처 성능이 저하되지 않습니다.
AWS는 비즈니스 가치를 제공하는 동시에 성능 효율성을 갖춘 아키텍처를 구축할 수 있도록 지원합니다. 아키텍처를 진정한 성능을 발휘하려면 이 문서에서 설명하는 툴과 기술을 사용해야 합니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
