Amazon S3의 성능 디자인 패턴
Amazon S3에서 객체를 업로드하고 검색할 애플리케이션을 설계할 때, 최상의 애플리케이션 성능을 얻기 위해 모범 사례 설계 패턴을 사용합니다. 또한 애플리케이션 아키텍처를 계획할 때 고려해야 할 성능 지침도 제공합니다.
성능을 최적화하려면 다음과 같은 설계 패턴을 사용할 수 있습니다.
주제
자주 액세스하는 콘텐츠에 캐싱 사용
Amazon S3에 데이터를 저장하는 많은 애플리케이션은 사용자가 반복적으로 요청하는 데이터의 "작업 집합"을 제공합니다. 워크로드가 공통 객체 집합에 반복적인 GET 요청을 보내는 경우 Amazon CloudFront, Amazon ElastiCache 또는 AWS Elemental MediaStore와 같은 캐시를 사용하여 성능을 최적화할 수 있습니다. 캐시를 성공적으로 채택하면 지연 시간이 짧아지고 데이터 전송률이 높아질 수 있습니다. 그리고 캐싱을 사용하는 애플리케이션은 Amazon S3에 직접 요청을 거의 보내지 않아 요청 비용을 줄일 수 있습니다.
Amazon CloudFront는 지리적으로 분산된 대규모 PoP(Point of Presence) 집합에서 Amazon S3의 데이터를 투명하게 캐시하는 고속 콘텐츠 전송 네트워크(CDN)입니다. 여러 리전 또는 인터넷을 통해 객체에 액세스할 수 있는 경우 CloudFront를 사용하면 객체에 액세스하는 사용자 가까이에서 데이터를 캐싱할 수 있습니다. 이로 인해 인기 있는 Amazon S3 콘텐츠를 고성능으로 전달할 수 있습니다. CloudFront에 대한 자세한 내용은 Amazon CloudFront 개발자 안내서를 참조하십시오.
Amazon ElastiCache는 관리형 인 메모리 캐시입니다. ElastiCache를 사용하면 메모리에 객체를 캐시하는 Amazon EC2 인스턴스를 프로비저닝할 수 있습니다. 이 캐싱은 GET 지연 시간이 크게 감소하고 다운로드 처리량이 상당히 증가합니다. ElastiCache를 사용하려면 캐시를 핫 객체로 채우고 Amazon S3에서 요청하기 전에 캐시에 핫 객체가 있는지 확인하도록 애플리케이션 로직을 수정합니다. ElastiCache를 사용하여 Amazon S3 GET 성능을 향상시키는 예는 블로그 게시물 Amazon ElastiCache for Redis를 사용한 Amazon S3 가속화
AWS Elemental MediaStore는 Amazon S3의 비디오 워크플로와 미디어 전송 전용으로 제작된 캐싱 및 콘텐츠 배포 시스템입니다. MediaStore는 비디오 전용 통합 스토리지 API를 제공하며, 성능에 민감한 비디오 워크로드에 권장됩니다. MediaStore에 대한 자세한 내용은 AWS Elemental MediaStore 사용 설명서를 참조하세요.
지연 시간에 민감한 애플리케이션의 제한 시간 및 재시도
애플리케이션이 Amazon S3에서 재시도를 해야 한다는 응답을 수신하는 경우가 있습니다. Amazon S3는 버킷 및 객체 이름을 연결된 객체 데이터에 매핑합니다. 애플리케이션의 요청 속도가 높으면(일반적으로 적은 수의 객체에 대해 초당 5,000건 이상의 연속 요청) HTTP 503 slowdown 응답이 수신될 수 있습니다. 이러한 오류가 발생하면 각 AWS SDK는 지수 백오프를 사용하여 자동 재시도 로직을 구현합니다. AWS SDK를 사용하지 않는 경우 HTTP 503 오류 수신 시 재시도 로직을 구현해야 합니다. 백오프 기법에 대한 자세한 내용은 Amazon Web Services 일반 참조의 오류 재시도 횟수 및 지수 백오프AWS를 참조하세요.
Amazon S3는 새로운 연속 요청 속도에 따라 자동으로 조정되어 동적으로 성능을 최적화합니다. Amazon S3가 새로운 요청 속도에 대해 내부적으로 최적화하는 동안 최적화가 완료될 때까지 일시적으로 HTTP 503 요청 응답을 받게 됩니다. Amazon S3가 새로운 요청 속도에 대해 성능을 내부적으로 최적화한 후에는 일반적으로 모든 요청이 재시도 없이 처리됩니다.
지연 시간에 민감한 애플리케이션의 경우 Amazon S3는 느린 작업을 추적하고 적극적으로 재시도할 것을 권고합니다. 요청을 재시도 할 때 Amazon S3에 대한 새 연결을 사용하고 새로운 DNS 조회를 수행하는 것이 좋습니다.
다양한 크기의 요청(예: 128MB 이상)을 생성할 때, 달성 중인 처리량을 추적하고 요청 중 가장 느린 5%를 재시도하는 것이 좋습니다. 일반적으로 지연 시간 중간값이 수십 밀리초 범위인 작은 요청(예: 512KB 미만)을 생성할 때는 2초 후 GET 또는 PUT 작업을 재시도하는 것이 좋습니다. 추가 재시도가 필요할 경우 가장 좋은 방법은 백오프입니다. 예를 들어 2초 후 재시도하고, 그로부터 4초 후 두 번째로 재시도하는 것이 좋습니다.
애플리케이션이 Amazon S3에 고정 크기 요청을 하는 경우, 각 요청에 대해보다 일관된 응답 시간을 기대할 것입니다. 이 경우 간단한 전략은 요청 중 가장 느린 1%를 확인하고 재시도하는 것입니다. 흔히 한 번의 재시도만으로도 지연 시간을 줄이는 데 효과적입니다.
서버 측 암호화에 AWS Key Management Service(AWS KMS)를 사용하는 경우 사용 사례에 지원되는 요청 속도에 대한 정보는 AWS Key Management Service 개발자 안내서의 제한을 참조하세요.
높은 처리량을 위한 수평 확장 및 요청 병렬화
Amazon S3는 매우 큰 분산 시스템입니다. 규모를 활용하려면 병렬 요청을 Amazon S3 서비스 엔드포인트까지 수평으로 조정하는 것이 좋습니다. 이 유형의 조정 방법은 Amazon S3 내에서 요청을 분산할 뿐만 아니라, 네트워크를 통해 여러 경로에 걸쳐 부하를 분산하기에도 좋습니다.
높은 처리량 전송의 경우, Amazon S3는 다중 연결을 사용하여 병렬로 데이터를 GET 또는 PUT하는 애플리케이션 사용을 권고합니다. 예를 들어 AWS Java SDK의 Amazon S3 Transfer Manager에서 지원하며, 다른 AWS SDK의 대부분은 비슷한 구조를 제공합니다. 일부 애플리케이션의 경우 서로 다른 애플리케이션 스레드나 다른 애플리케이션 인스턴스에서 동시에 여러 요청을 실행하여 병렬 연결을 구현할 수 있습니다. 취할 수 있는 가장 좋은 방법은 애플리케이션과 액세스 중인 객체의 구조에 따라 다릅니다.
AWS SDK에서 전송 관리를 사용하는 대신, AWS SDK를 사용하여 GET 및 PUT 요청을 직접 실행할 수 있습니다. 이 방법을 사용하면 워크로드를 보다 직접적으로 조정할 수 있으며 SDK의 재시도 지원과 발생할 수 있는 HTTP 503 응답 처리 기능을 계속 활용할 수 있습니다. 일반적으로 리전 내 큰 객체를 Amazon S3에서 Amazon EC2로 다운로드할 때 객체의 바이트 범위에 대한 동시 요청을 8~16MB의 세부 수준으로 수행하는 것이 좋습니다. 원하는 각각의 85~90MB/s의 네트워크 처리량에 대해 한 건의 동시 요청을 하십시오. 10Gb/s 네트워크 인터페이스 카드(NIC)를 포화시키려면 별도의 연결을 통해 약 15건의 동시 요청을 사용할 수 있습니다. 더 많은 연결을 통해 동시 요청을 수직 확장하여 25Gb/s 또는 100Gb/s NIC와 같은 더 빠른 NIC를 포화시킬 수 있습니다.
동시에 생성할 요청 수를 조정할 때 성능 측정이 중요합니다. 한 번에 하나의 요청으로 시작하는 것이 좋습니다. 달성되는 네트워크 대역폭과 애플리케이션이 데이터 처리에 사용하는 다른 리소스의 사용을 측정하십시오. 그런 다음 병목 리소스(즉, 사용률이 가장 높은 리소스), 따라서 유용할 가능성이 있는 요청 수를 식별할 수 있습니다. 예를 들어 한 번에 하나의 요청을 처리하면 CPU 사용량이 25%가되며 최대 4개의 동시 요청을 수용할 수 있습니다. 측정은 필수적이며, 요청 속도가 증가함에 따라 리소스 사용을 확인할 필요가 있습니다.
애플리케이션에서 REST API를 사용하여 Amazon S3에 직접 요청을 제출하는 경우 HTTP 연결 풀을 사용하고 일련의 요청에 대해 각각의 연결을 다시 사용하는 것이 좋습니다. 요청별 연결 설정을 피하면 요청마다 TCP slow-start 및 SSL(Secure Sockets Layer) 핸드셰이크를 수행할 필요가 없습니다. REST API 사용에 대한 자세한 내용은 Amazon Simple Storage Service API 참조를 참조하세요.
마지막으로, DNS에 주의를 기울여 Amazon S3 IP 주소의 광범위한 풀로 요청이 확산되고 있는지 다시 확인하는 것이 중요합니다. DNS는 수많은 IP 엔드포인트 목록을 통해 Amazon S3 주기에 대해 쿼리합니다. 그러나 단일 IP 주소를 재사용하는 캐싱 해석기 또는 애플리케이션 코드는 주소 다양성과 그에 따른 로드 밸런싱의 이점을 얻지 못합니다. netstat 명령줄 도구와 같은 네트워크 유틸리티 도구는 Amazon S3와의 통신에 사용되는 IP 주소를 표시할 수 있으며, 사용할 DNS 구성에 대한 지침을 제공합니다. 이 지침에 대한 자세한 내용은 요청 만들기 섹션을 참조하세요.
Amazon S3 Transfer Acceleration을 사용하여 지리적으로 다른 데이터 전송 가속화
Amazon S3 Transfer Acceleration을 사용하여 빠르고 안전한 파일 전송 구성은 Amazon S3를 사용하여 전 세계에 분산된 클라이언트와 리전 애플리케이션 간의 물리적 거리로 인해 발생하는 지연 시간을 최소화하거나 없애는 데 효과적입니다. Transfer Acceleration은 데이터 전송을 위해 CloudFront에서 전 세계에 분산된 엣지 로케이션을 사용합니다. AWS 엣지 네트워크는 50개 이상의 위치에 상호 접속 위치(POP)를 보유합니다. 현재는 CloudFront를 통해 콘텐츠를 배포하고 Amazon Route 53에 대해 수행된 DNS 쿼리에 신속하게 응답하는 데 사용됩니다.
또한 엣지 네트워크는 Amazon S3와 주고 받는 데이터 전송을 가속화합니다. 대륙 내부 및 대륙 간에 데이터를 전송하고, 인터넷 연결이 빠르며, 대용량 객체를 사용하거나 업로드할 콘텐츠가 많은 애플리케이션에 이상적입니다. 엣지 로케이션에 도착한 데이터는 최적화된 네트워크 경로를 통해 Amazon S3로 라우팅됩니다. 일반적으로 Amazon S3 리전에서 멀어질수록 Transfer Acceleration을 사용하면 더 높은 속도 향상을 기대할 수 있습니다.
새 버킷 또는 기존 버킷에 Transfer Acceleration을 설정할 수 있습니다. 별도의 Amazon S3 Transfer Acceleration 엔드포인트를 사용하여 AWS 엣지 로케이션을 사용할 수 있습니다. Transfer Acceleration이 클라이언트 요청 성능에 유익한지 테스트하는 가장 좋은 방법은 Amazon S3 Transfer Acceleration 속도 비교 도구
