성능 효율성

성능 효율성 원칙에는 컴퓨팅 리소스를 시스템 요구 사항에 맞게 효율적으로 사용하고, 수요 변화 및 기술 진화에 발맞춰 그러한 효율성을 유지하는 능력이 포함됩니다.이(가) 포함됩니다.

성능 효율성 부문에서는 설계 원칙 개요, 모범 사례 및 질문 사항을 제공합니다. 구현 방법에 대한 규범적 지침은 성능 효율성 부문 백서에서 확인할 수 있습니다.

설계 원칙

클라우드에는 성능 효율성에 대한 five개의 설계 원칙이 있습니다.

정의

클라우드에는 성능 효율성에 대한 four개의 모범 사례 영역이 있습니다.

고성능 아키텍처 선택 시 데이터 기반 접근 방식을 취합니다. 상위 수준 설계에서 리소스 유형의 선택 및 구성에 이르기까지 아키텍처의 모든 측면에 대한 데이터를 수집합니다. 주기적으로 선택 사항을 검토함으로써 계속 진화하는 AWS 클라우드를 최대한 활용할 수 있습니다. 모니터링은 예상 성능과의 차이를 인지하고 관련 조치를 취할 수 있게 해 줍니다. 마지막으로 아키텍처는 압축 또는 캐싱을 사용하거나 일관성 요구 사항을 완화하는 등 트레이드오프를 통해 성능을 개선할 수 있습니다.

모범 사례

선택

특정 시스템에 대한 최적의 솔루션은 워크로드에 따라 달라지며, 흔히 여러 접근 방식이 복합적으로 사용됩니다. 설계가 잘된 시스템은 여러 개의 솔루션을 사용하고 다양한 특성을 사용하여 성능을 높입니다.

AWS에서는 리소스가 가상화되고 다양한 유형 및 구성으로 제공됩니다. 따라서 보다 쉽게 요구 사항과 일치하는 접근 방식을 찾을 수 있을 뿐만 아니라, 온프레미스 인프라에서는 쉽게 얻을 수 없는 다양한 스토리지 옵션을 찾을 수 있습니다. 예를 들어 Amazon DynamoDB와 같은 관리형 서비스는 완전관리형 NoSQL 데이터베이스로, 어떤 규모에서도 지연 시간이 한 자릿수 밀리초 단위로 매우 짧습니다.

다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

PERF 1: 최고의 성능을 내는 아키텍처를 어떻게 선택합니까?

아키텍처에 대한 패턴 및 구현을 선택할 때는 최적의 솔루션을 위한 데이터 기반 접근 방식을 사용합니다. AWS 솔루션즈 아키텍트, AWS 참조 아키텍처 및 AWS 파트너 네트워크(APN) 파트너는 이제까지 구축한 지식을 바탕으로 사용자가 아키텍처를 선택하는 과정을 도울 수 있습니다. 하지만 아키텍처를 최적화하기 위해서는 벤치마킹 또는 로드 테스트를 통해 획득한 데이터가 필요합니다.

아키텍처는 여러 아키텍처 접근 방식(예: 이벤트 기반, ETL 또는 파이프라인)을 결합하게 될 가능성이 높습니다. 아키텍처 구현에는 아키텍처 성능 최적화에 적합한 AWS 서비스를 사용하게 됩니다. 다음 단원에서는 네 가지의 고려해야 할 리소스 유형, 즉 컴퓨팅, 스토리지, 데이터베이스 및 네트워크에 대해 살펴봅니다.

컴퓨팅

특정 시스템에 대한 최적의 시스템은 애플리케이션 설계, 사용량 패턴 및 구성 설정에 따라 다를 수 있습니다. 아키텍처는 다양한 컴포넌트에 대해 서로 다른 컴퓨팅 솔루션을 사용하고 다양한 기능을 활성화하여 성능을 개선할 수 있습니다. 아키텍처에 대해 잘못된 컴퓨팅 솔루션을 선택하면 성능 효율성 저하로 이어질 수 있습니다.

AWS에서 인스턴스, 컨테이너, 함수 등 세 가지 형태의 컴퓨팅이 제공됩니다.

  • 인스턴스는 가상화된 서버이며, 따라서 버튼을 클릭하거나 API 호출을 통해 기능을 변경할 수 있습니다. 클라우드에서는 리소스를 한번 결정하면 그대로 고정되는 것이 아니므로 다양한 서버 유형을 시험해 볼 수 있습니다. AWS에서는 이러한 가상 서버 인스턴스를 다양한 제품군과 크기로 제공하며 솔리드 스테이트 드라이브(SSD)와 그래픽 처리 장치(GPU)를 비롯한 매우 다양한 기능을 제공합니다.

  • 컨테이너는 애플리케이션 및 종속성을 리소스가 격리된 프로세스에서 실행할 수 있는 운영 체제 가상화 방식입니다.

  • 함수는 실행하려는 코드에서 실행 환경을 추상화합니다. 예를 들어, AWS Lambda를 이용하면 인스턴스를 실행하지 않고도 코드를 실행할 수 있습니다.

다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

PERF 2: 컴퓨팅 솔루션을 어떻게 선택합니까?

컴퓨팅 사용을 설계할 때는 이용 가능한 탄력성 메커니즘을 활용하여 수요 변화에 맞춰 성능을 유지할 수 있는 충분한 용량을 확보해야 합니다.

스토리지

특정 시스템에 대한 최적의 스토리지 솔루션은 액세스 접근 방식 종류(블록, 파일, 객체), 액세스 패턴(랜덤 또는 순차), 필요한 처리량, 액세스 빈도(온라인, 오프라인, 보관), 업데이트 빈도(WORM, 동적) 및 가용성과 내구성 제약 사항에 따라 다릅니다. 설계가 잘 된 시스템은 여러 개의 스토리지 솔루션을 사용하고 다양한 특성을 사용하여 성능을 향상시킵니다.

AWS에서 스토리지는 가상화되며 다양한 유형으로 제공됩니다. 이는 스토리지 방식을 요구에 보다 밀접하게 맞출 수 있게 하며, 온프레미스 인프라에서는 쉽게 얻을 수 없는 다양한 스토리지 옵션을 제공합니다. 예를 들어, Amazon S3는 99.999999999%의 내구성을 제공하도록 설계되었습니다. 또한 마그네틱 하드 디스크 드라이브(HDD)에서 솔리드 스테이트 드라이브(SSD)로 변경할 수 있으며, 몇 초 안에 한 인스턴스에서 다른 인스턴스로 가상 드라이브를 쉽게 이동할 수 있습니다.

다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

PERF 3: 스토리지 솔루션을 어떻게 선택합니까?

스토리지 솔루션을 선택할 때는 액세스 패턴과 일치하도록 선택하는 것이 원하는 성능을 구현하는 데 매우 중요합니다.

데이터베이스

특정 시스템에 대한 최적의 데이터베이스 솔루션은 가용성, 일관성, 파티션 허용 오차, 지연 시간, 내구성, 확장성, 쿼리 기능에 대한 요구 사항에 따라 달라질 수 있습니다. 여러 시스템은 다양한 하위 시스템에 서로 다른 데이터베이스 솔루션을 사용하고 다양한 기능을 활성화하여 성능을 개선할 수 있습니다. 시스템에 대해 잘못된 데이터베이스 솔루션 및 기능을 선택하면 성능 효율성이 저하될 수 있습니다.

Amazon RDS는 완전관리형 관계형 데이터베이스를 제공합니다. Amazon RDS를 이용하면 가동을 중단하는 경우가 거의 없이 데이터베이스의 컴퓨팅과 스토리지 리소스를 확장할 수 있습니다. Amazon DynamoDB는 어떤 규모에서도 지연 시간이 한 자릿수 밀리초 단위로 매우 짧은 완전관리형 NoSQL 데이터베이스입니다. Amazon Redshift는 페타바이트 규모의 관리형 데이터 웨어하우스로, 성능 또는 용량을 변경해야 할 경우 노드 수 또는 유형을 변경할 수 있습니다.

다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

PERF 4: 데이터베이스 솔루션 선택 방법

한 워크로드의 데이터베이스 접근 방식(RDBMS, NoSQL)은 시스템의 성능 효율에 큰 영향을 미치지만, 이는 보통 데이터 기반 접근 방식보다는 조직적 기본 사항에 따라 선택됩니다. 스토리지와 마찬가지로 워크로드의 액세스 패턴을 고려하는 것이 중요하며, 다른 비데이터베이스 솔루션이 보다 효율적으로 문제(예: 검색 엔진 또는 데이터 웨어하우스 사용)를 해결할 수 있는지 여부도 고려해야 합니다.

네트워크

특정 시스템에 맞는 최적의 네트워크 솔루션은 지연 시간, 처리량 요구 사항 등에 따라 다양합니다. 사용자 또는 온프레미스 리소스와 같은 물리적 제약은 엣지 기술 또는 리소스 배치를 통해 보완될 수 있는 위치 옵션을 구동시킵니다.

AWS에서 네트워킹은 가상화되고 다양한 유형 및 구성으로 제공됩니다. 따라서 네트워킹 방식을 요구에 보다 밀접하게 맞출 수 있습니다. AWS는 네트워크 트래픽을 최적화하는 제품 기능(예: 향상된 네트워킹, Amazon EBS 최적화 인스턴스, Amazon S3 전송 가속 기능, 동적 Amazon CloudFront)을 제공합니다. 또한 AWS는 네트워크 거리 또는 지터를 줄이기 위한 네트워킹 기능(예: Amazon Route53 지연 시간 기반 라우팅, Amazon VPC 엔드포인트 및 AWS Direct Connect)도 제공합니다.

다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

PERF 5: 네트워킹 솔루션을 어떻게 구성합니까?

네트워크 솔루션을 선택할 때는 위치를 고려해야 합니다. AWS를 사용하면 리소스를 사용할 위치 가까이 해당 리소스가 배치되도록 선택하여 거리를 줄일 수 있습니다. 리전, 배치 그룹 및 엣지 로케이션을 활용하여 성능을 현저히 개선할 수 있습니다.

검토

솔루션 설계 시 선택할 수 있는 옵션은 한정되어 있습니다. 그러나 시간이 지나면 아키텍처의 성능을 향상시킬 수 있는 새로운 기술과 접근 방식을 사용할 수 있게 됩니다.

AWS를 사용하면 고객의 요구를 충족하기 위해 지속적인 혁신의 혜택을 받을 수 있습니다. AWS는 정기적으로 새로운 리전, 엣지 로케이션, 서비스 및 기능을 출시합니다. 이들 모두는 아키텍처의 성능 효율성을 확실히 개선할 수 있습니다.

다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

PERF 6: 새 릴리스를 활용하여 워크로드를 어떻게 발전시킵니까?

어떤 조건이 아키텍처 성능을 제약하는지 이해하면 해당 제약 조건을 완화할 수 있는 릴리스를 찾아볼 수 있습니다.

모니터링

아키텍처를 구현한 후에는 고객이 인지하기 전에 모든 문제를 해결할 수 있도록 성능을 모니터링해야 합니다. 임계값을 초과할 경우 경보가 생성되도록 모니터링 측정치를 사용해야 합니다. 경보는 성능이 불량한 구성 요소를 해결하기 위한 자동 작업을 트리거할 수 있습니다.

Amazon CloudWatch는 모니터링 기능 및 알림 경보 전송 기능을 제공합니다. 자동화를 이용하면 Amazon Kinesis, Amazon Simple Queue Service(Amazon SQS) 및 AWS Lambda를 통해 작업을 트리거하여 성능 문제를 해결할 수 있습니다.

다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

PERF 7: 리소스가 기대만큼의 성능을 보장하는지 어떻게 모니터링 합니까?

정책 오차 또는 데이터가 과도하게 발생하지 않도록 하는 것이 효과적인 모니터링 솔루션의 핵심입니다. 자동 트리거는 수동 작업으로 인한 오류를 방지하고 문제 해결 시간을 단축시킬 수 있습니다. 프로덕션 환경에서 시뮬레이션을 통해 경보 솔루션이 올바로 문제를 인지하는지 테스트하는 실전 연습을 계획하십시오.

트레이드오프

솔루션을 설계할 때는 최적의 접근 방식을 선택할 수 있도록 트레이드오프를 고려해야 합니다. 상황에 따라 일관성 및 내구성을 위해 시간 또는 지연 시간을 희생함으로써 보다 높은 성능을 제공할 수 있습니다.

AWS를 사용하면 몇 분 내에 전 세계의 여러 위치에 리소스를 배포하여 최종 사용자에게 더욱 가깝게 다가갈 수 있습니다. 또한 데이터베이스 시스템과 같은 정보 스토어에 읽기 전용 복제본을 동적으로 추가하여 기본 데이터베이스의 부하를 줄일 수 있습니다. 또한 AWS는 인 메모리 스토어 또는 캐시를 제공하는 Amazon ElastiCache와 같은 캐싱 솔루션과 정적 콘텐츠의 사본을 최종 사용자에게 더 가깝게 캐싱하는 Amazon CloudFront를 제공합니다. Amazon DynamoDB Accelerator(DAX)는 Amazon DynamoDB 앞에 연속 읽기/연속 쓰기 분산 캐싱 계층을 제공하여 동일한 API를 지원하면서도 캐시 내에 있는 엔터티에 대해 1밀리초 미만의 지연 시간을 제공합니다.

다음 질문은 성능 효율성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

PERF 8: 성능 향상을 위해 트레이드 오프를 어떻게 사용합니까?

트레이드오프는 아키텍처의 복잡성을 증가시킬 수 있으며 측정 가능한 이점이 달성되는지 확인하기 위한 로드 테스트가 필요합니다.

주요 AWS 서비스

성능 효율성에 필수적인 AWS 서비스은(는) Amazon CloudWatch, 리소스와 시스템을 모니터링하여 전반적인 성능 및 운영 상태를 확인할 수 있도록 해 주며,이며, 다음 서비스 및 기능이 성능 효율성의 four개 영역을 지원합니다.

리소스

성능 효율성 관련 AWS 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조하십시오.

Performance Efficiency Pillar
Amazon S3 Performance Optimization
Amazon EBS Volume Performance
AWS re:Invent 2016: Scaling Up to Your First 10 Million Users (ARC201)
AWS re:Invent 2017: Deep Dive on Amazon EC2 Instances