높은 처리량을 위한 수평 크기 조정 및 요청 병렬화

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 S3 REST API 소개를 참조하세요.

마지막으로, DNS에 주의를 기울여 Amazon S3 IP 주소의 광범위한 풀로 요청이 확산되고 있는지 다시 확인하는 것이 중요합니다. DNS는 수많은 IP 엔드포인트 목록을 통해 Amazon S3 주기에 대해 쿼리합니다. 그러나 단일 IP 주소를 재사용하는 캐싱 해석기 또는 애플리케이션 코드는 주소 다양성과 그에 따른 로드 밸런싱의 이점을 얻지 못합니다. netstat 명령줄 도구와 같은 네트워크 유틸리티 도구는 Amazon S3과 통신하는 데 사용되는 IP 주소를 표시할 수 있으며, 사용할 DNS 구성에 대한 가이드를 제공합니다. 이러한 가이드에 대한 자세한 내용은 요청 라우팅을 참조하세요.