라우팅 요청 - Amazon Simple Storage Service

라우팅 요청

CreateBucketConfiguration을 포함한 CreateBucket API를 사용하여 만든 버킷에 요청을 하는 프로그램은 리디렉션을 지원해야 합니다. 또한 DNS TTL을 지키지 않는 일부 클라이언트에서 문제가 발생할 수 있습니다.

이 단원에서는 Amazon S3과 함께 사용할 서비스 또는 애플리케이션을 설계할 때 고려할 라우팅 및 DNS 문제에 대해 설명합니다.

요청 리디렉션 및 REST API

Amazon S3에서는 Domain Name System(DNS)을 사용하여 요청을 처리할 수 있는 시설로 요청을 라우팅합니다. 이 시스템은 효율적으로 작동하지만 일시적인 라우팅 오류가 발생할 수 있습니다. 요청이 잘못된 Amazon S3 위치에 도착하는 경우 Amazon S3에서는 요청자에게 새 엔드포인트로 요청을 다시 전송하도록 지시하는 임시 리디렉션으로 응답합니다. 요청이 잘못 구성된 경우 Amazon S3에서는 영구 리디렉션을 사용하여 요청이 올바르게 수행되는 방법에 대한 지침을 제공합니다.

중요

이 기능을 사용하려면 Amazon S3 리디렉션 응답을 처리할 수 있는 애플리케이션이 있어야 합니다. <CreateBucketConfiguration> 없이 생성된 버킷으로만 작동하는 애플리케이션에 대해서는 유일하게 예외가 적용됩니다. 위치 제약에 대한 자세한 내용은 Amazon S3 버킷에 액세스 및 나열 단원을 참조하십시오.

2019년 3월 20일 이후에 시작된 모든 리전에 대해 요청이 잘못된 Amazon S3 위치에 도달하면 Amazon S3는 HTTP 400 Bad Request 오류를 반환합니다.

AWS 리전 활성화 및 비활성화에 대한 자세한 내용은 AWS 일반 참조의 AWS 리전 및 엔드포인트를 참조하세요.

DNS 라우팅

DNS 라우팅은 요청을 적절한 Amazon S3 시설로 라우팅합니다. 다음 그림 및 절차에는 DNS 라우팅의 예제가 나와 있습니다.


				DNS 서버가 클라이언트의 요청을 Facility B로 라우팅할 때 발생하는 단계를 보여주는 다이어그램
DNS 라우팅 요청 단계
  1. 클라이언트는 Amazon S3에 저장된 객체를 가져오기 위해 DNS 요청을 보냅니다.

  2. 클라이언트는 요청을 처리할 수 있는 설비의 IP 주소를 하나 이상 수신합니다. 이 예제에서 IP 주소는 Facility B에 대한 것입니다.

  3. 클라이언트는 Amazon S3 Facility B에 요청을 보냅니다.

  4. Facility B는 객체의 사본을 클라이언트로 반환합니다.

임시 요청 리디렉션

임시 리디렉션은 요청을 다른 엔드포인트로 다시 전송해야 하는 요청자에게 신호를 보내는 일종의 오류 응답입니다. Amazon S3의 분산 특성 때문에 요청이 일시적으로 잘못된 시설로 라우팅될 수 있습니다. 이러한 경우는 버킷을 만든 직후 또는 삭제한 직후에 발생할 가능성이 가장 높습니다.

예를 들어, 새 버킷을 만들고 이 버킷에 즉시 요청을 보내는 경우, 버킷의 위치 제한에 따라 임시 리디렉션을 수신할 수 있습니다. 미국 동부(버지니아 북부) AWS 리전에서 버킷을 생성한 경우 이곳 역시 기본 Amazon S3 엔드포인트이므로 리디렉션 현상이 나타나지 않습니다.

그러나 기타 리전에서 버킷을 생성한 경우 버킷의 DNS 항목이 전파되는 동안 이 버킷에 대한 모든 요청은 기본 엔드포인트로 이동합니다. 기본 엔드포인트에서는 HTTP 302 응답과 함께 요청을 정확한 엔드포인트로 리디렉션합니다. 임시 리디렉션에는 정확한 시설에 대한 URI가 포함되어 있어 이를 사용하여 요청을 즉시 재전송할 수 있습니다.

중요

이전 리디렉션 응답에서 제공한 엔드포인트를 재사용하지 마십시오. 긴 시간 동안 작동하는 것처럼 보일 수 있으나 예기치 않은 결과를 제공할 수 있으며 결국 예고 없이 실패하게 됩니다.

다음 그림 및 절차에는 임시 리디렉션의 예제가 나와 있습니다.


				클라이언트가 B에 요청을 전송하고 C로 리디렉션될 때 발생하는 단계를 보여주는 다이어그램
임시 요청 리디렉션 단계
  1. 클라이언트는 Amazon S3에 저장된 객체를 가져오기 위해 DNS 요청을 보냅니다.

  2. 클라이언트는 요청을 처리할 수 있는 설비의 IP 주소를 하나 이상 수신합니다.

  3. 클라이언트는 Amazon S3 Facility B에 요청을 보냅니다.

  4. Facility B에서는 Location C에서 사용 가능한 객체를 나타내는 리디렉션을 반환합니다.

  5. 클라이언트에서 Location C로 요청을 다시 전송합니다.

  6. Facility C에서 객체의 사본을 반환합니다.

영구 요청 리디렉션

영구 리디렉션은 요청에 리소스의 주소가 부적절하게 지정되었음을 나타냅니다. 예를 들어, <CreateBucketConfiguration>을 사용하여 생성한 버킷에 경로 스타일 요청을 사용하여 액세스하는 경우 영구 리디렉션이 발생합니다. 자세한 내용은 Amazon S3 버킷에 액세스 및 나열 섹션을 참조하세요.

개발 중에 이러한 오류를 쉽게 발견할 수 있도록 요청이 자동으로 올바른 위치를 따라가도록 하는 Location HTTP 헤더를 이 유형의 리디렉션에 포함하지 않습니다. 올바른 Amazon S3 엔드포인트 사용에 대한 도움을 받으려면 결과 XML 오류 문서를 참조하십시오.

요청 리디렉션 예제

다음은 임시 요청 리디렉션 응답의 예제입니다.

REST API 임시 리디렉션 응답

HTTP/1.1 307 Temporary Redirect Location: http://awsexamplebucket1.s3-gztb4pa9sq.amazonaws.com/photos/puppy.jpg?rk=e2c69a31 Content-Type: application/xml Transfer-Encoding: chunked Date: Fri, 12 Oct 2007 01:12:56 GMT Server: AmazonS3 <?xml version="1.0" encoding="UTF-8"?> <Error> <Code>TemporaryRedirect</Code> <Message>Please re-send this request to the specified temporary endpoint. Continue to use the original request endpoint for future requests.</Message> <Endpoint>awsexamplebucket1.s3-gztb4pa9sq.amazonaws.com</Endpoint> </Error>

SOAP API 임시 리디렉션 응답

참고

HTTP를 통한 SOAP 지원은 중단되었지만 SOAP는 HTTPS를 통해 계속해서 사용할 수 있습니다. Amazon S3의 새로운 기능들은 SOAP에서 지원되지 않습니다. SOAP를 사용하는 대신 REST API 또는 AWS SDK를 사용하는 것이 좋습니다.

<soapenv:Body> <soapenv:Fault> <Faultcode>soapenv:Client.TemporaryRedirect</Faultcode> <Faultstring>Please re-send this request to the specified temporary endpoint. Continue to use the original request endpoint for future requests.</Faultstring> <Detail> <Bucket>images</Bucket> <Endpoint>s3-gztb4pa9sq.amazonaws.com</Endpoint> </Detail> </soapenv:Fault> </soapenv:Body>

DNS 고려 사항

Amazon S3의 설계 요구 사항 중 하나는 고가용성입니다. 이 요구 사항을 충족하는 한 가지 방법은 필요에 따라 DNS의 Amazon S3 엔드포인트와 연결된 IP 주소를 업데이트하는 것입니다. 이러한 변경 내용은 수명이 짧은 클라이언트에는 자동으로 반영되지만, 일부 수명이 긴 클라이언트에는 반영되지 않습니다. 수명이 긴 클라이언트는 이러한 변경 사항을 활용하기 위해 주기적으로 Amazon S3 엔드포인트를 재확인하는 특별 작업을 수행해야 합니다. 가상 머신(VM)에 대한 자세한 내용은 다음을 참조하십시오.

  • Java의 경우 Sun의 JVM이 기본적으로 DNS 조회를 영구 캐시합니다. 이 동작을 변경하는 방법에 대한 자세한 내용은 InetAddress 설명서의 "InetAddress Caching" 단원을 참조하십시오.

  • PHP의 경우, 가장 인기 있는 배포 구성에서 실행되는 PHP VM이 VM이 재시작될 때까지 DNS 조회를 캐싱합니다. getHostByName PHP 문서를 참조하십시오.