기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon Data Firehose의 데이터 전송 이해 Firehose 스트림으로 데이터를 전송하면 선택한 대상에 자동으로 데이터가 전송됩니다. 다음 표는 다양한 대상으로의 데이터 전송을 설명합니다. | Destination | 세부 정보 | | --- | --- | | Amazon S3 | Amazon S3로 데이터를 전송할 때 Firehose는 Firehose 스트림의 버퍼링 구성에 따라 여러 수신 레코드를 연결합니다. 그런 다음 Amazon S3 객체로 레코드를 Amazon S3에 전송합니다. 기본적으로 Firehose는 구분 기호 없이 데이터를 연결합니다. 레코드 사이에 새 줄 구분 기호를 사용하려면 [Firehose 콘솔 구성](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-s3) 또는 [API 파라미터](https://docs.aws.amazon.com/firehose/latest/APIReference/API_Processor.html)에서 기능을 활성화하여 새 줄 구분 기호를 추가할 수 있습니다. Firehose와 Amazon S3 대상 사이의 데이터 전송은 TLS(HTTPS)로 암호화됩니다. | | Amazon Redshift | Amazon Redshift로 데이터를 전송하는 경우 Firehose는 먼저 수신 데이터를 앞서 설명한 형식으로 S3 버킷에 전송합니다. 그러면 Firehose는 Amazon Redshift **COPY** 명령을 실행하여 S3 버킷의 데이터를 Amazon Redshift 프로비저닝된 클러스터 또는 Amazon Redshift Serverless 작업 그룹으로 로드합니다. Amazon Data Firehose가 여러 수신 레코드를 Amazon S3 객체로 연결한 후 Amazon S3 객체를 Amazon Redshift 프로비저닝된 클러스터 또는 Amazon Redshift Serverless 작업 그룹에 복사할 수 있는지 확인하세요. 자세한 내용은 [Amazon Redshift COPY 명령 데이터 형식 파라미터](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-format.html)를 참조하세요. | | OpenSearch Service 및 OpenSearch Serverless | OpenSearch Service 및 OpenSearch Serverless로 데이터를 전송하기 위해 Amazon Data Firehose는 Firehose 스트림의 버퍼링 구성에 따라 수신 레코드를 버퍼링합니다. 그런 다음 OpenSearch Service 클러스터 또는 OpenSearch Serverless 컬렉션에 여러 레코드를 인덱싱하기 위한 OpenSearch Service 또는 OpenSearch Serverless 대량 요청을 생성합니다. 레코드를 Amazon Data Firehose로 보내기 전에 레코드가 UTF-8로 인코딩되어 단일 줄 JSON 객체에 결합되었는지 확인해야 합니다. 또한 레코드 단위로 설정되는 명시적 인덱스를 이용해 대량 요청을 하기 위해서는 OpenSearch Service 클러스터에 대한 rest.action.multi.allow\$1explicit\$1index 옵션이 true(기본값)로 설정되어야 합니다. 자세한 정보는 Amazon OpenSearch Service 개발자 안내서의 [OpenSearch Service Configure 고급 옵션](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-advanced-options)을 참조하세요. | | Splunk | Splunk로 데이터를 전송하기 위해 Amazon Data Firehose는 전송하는 바이트를 연결합니다. 줄 바꿈 문자와 같은 데이터의 구분 기호를 원하는 경우 이를 직접 삽입해야 합니다. Splunk가 모든 구분 기호를 구문 분석하도록 구성되어야 합니다. S3 오류 버킷(S3 백업)에 전송된 데이터를 다시 Splunk로 리드라이브하려면 [Splunk 설명서](https://www.splunk.com/en_us/blog/tips-and-tricks/aws-technical-add-on-simplifying-error-data-re-ingestion.html)에 설명된 단계를 따릅니다. | | HTTP 엔드포인트 | 지원되는 타사 서비스 공급자가 소유한 HTTP 엔드포인트로 데이터를 전송하는 경우, 통합된 Amazon Lambda 서비스를 사용하여 수신 레코드를 서비스 공급자의 통합에서 예상하는 형식과 일치하는 형식으로 변환하는 함수를 생성할 수 있습니다. 허용되는 레코드 형식에 대한 자세한 내용은 대상으로 선택한 HTTP 엔드포인트의 타사 서비스 공급자에게 문의하세요. | | Snowflake | Snowflake로 데이터를 전송하기 위해 Amazon Data Firehose는 내부적으로 1초 동안 데이터를 버퍼링하고 Snowflake 스트리밍 API 작업을 사용하여 Snowflake에 데이터를 삽입합니다. 기본적으로 삽입하는 레코드는 매초마다 플러시되고 Snowflake 테이블에 커밋됩니다. 삽입 호출을 수행하면 Firehose는 데이터가 Snowflake에 커밋되는 데 걸린 시간을 측정하는 CloudWatch 지표를 내보냅니다. 현재 Firehose는 단일 JSON 항목만 레코드 페이로드로 지원하며 JSON 배열은 지원하지 않습니다. 입력 페이로드가 유효한 JSON 객체인지 확인하고 불필요한 큰따옴표나 작은따옴표 또는 이스케이프 문자 없이 잘 구성되었는지 확인합니다. | 각 Firehose 대상에는 고유한 데이터 전송 빈도가 있습니다. 자세한 내용은 [버퍼링 힌트 구성](create-configure-backup.md#buffering-hints) 섹션을 참조하세요. **중복 레코드** Amazon Data Firehose는 데이터 전송에 최소 한 번(at-least-once) 시맨틱을 사용합니다. 데이터 전송 시간이 초과되는 등의 일부 상황에서, 원본 데이터 전송 요청이 진행될 경우 Amazon Data Firehose에서 전송을 재시도하면 중복이 발생할 수 있습니다. 이는 Amazon S3 대상, Apache Iceberg 테이블 및 Snowflake 대상을 제외한 Amazon Data Firehose가 지원하는 모든 대상 유형에 적용됩니다. **Topics** + [AWS 계정 및 리전 간 전송 이해](across.md) + [HTTP 엔드포인트 전송 요청 및 응답 사양에 대한 이해](httpdeliveryrequestresponse.md) + [데이터 전송 실패 처리](retry.md) + [Amazon S3 객체 이름 형식 구성](s3-object-name.md) + [OpenSearch Service 인덱스 교체 구성](es-index-rotation.md) + [데이터 전송 일시 중지 및 재개](pause-restart-stream.md) # AWS 계정 및 리전 간 전송 이해 Amazon Data Firehose는 AWS 계정 간 HTTP 엔드포인트 대상으로의 데이터 전송을 지원합니다. 대상으로 선택한 Firehose 스트림과 HTTP 엔드포인트는 서로 다른 AWS 계정에 속할 수 있습니다. Amazon Data Firehose는 AWS 리전 간 HTTP 엔드포인트 대상으로의 데이터 전송도 지원합니다. 한 AWS 리전의 Firehose 스트림에서 다른 리전의 HTTP 엔드포인트로 데이터를 전송할 수 AWS 있습니다. 또한 Firehose 스트림의 데이터를 AWS 리전 외부의 HTTP 엔드포인트 대상으로 전송할 수 있습니다. 예를 들어 HTTP 엔드포인트 URL을 원하는 대상으로 설정하여 온프레미스 서버로 전송할 수 있습니다. 이러한 시나리오의 경우 전송 비용에 추가 데이터 전송 요금이 더해질 수 있습니다. 자세한 내용은 “On-Demand Pricing”(온디맨드 요금) 페이지의 [데이터 전송](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer)을 참조하세요. # HTTP 엔드포인트 전송 요청 및 응답 사양에 대한 이해 Amazon Data Firehose가 사용자 지정 HTTP 엔드포인트에 데이터를 성공적으로 전송하기 위해서는 이러한 엔드포인트가 특정 Amazon Data Firehose 요청 및 응답 형식을 사용하여 요청을 수락하고 응답을 보내야 합니다. 이 섹션에서는 Amazon Data Firehose 서비스가 사용자 지정 HTTP 엔드포인트에 보내는 HTTP 요청의 형식 사양과 Amazon Data Firehose 서비스가 예상하는 HTTP 응답의 형식 사양에 대해 설명합니다. Amazon Data Firehose에서 요청 제한 시간을 초과하기 전까지 HTTP 엔드포인트는 3분 이내에 요청에 응답해야 합니다. Amazon Data Firehose는 알맞은 형식을 준수하지 않는 응답을 전송 실패로 간주합니다. ## 요청 형식 **경로 및 URL 파라미터** 이는 단일 URL 필드의 일부로 사용자가 직접 구성합니다. Amazon Data Firehose는 수정하지 않고 구성된 대로 이를 전송합니다. https 대상만 지원합니다. 전송 스트림 구성 중에 URL 제한이 적용됩니다. HTTP 엔드포인트 데이터 전송에 대해서는 현재 포트 443만 지원됩니다. **HTTP 헤더 - X-Amz-Firehose-Protocol-Version** 이 헤더를 사용하여 요청/응답 형식의 버전을 표시합니다. 현재 1.0이 유일한 버전입니다. **HTTP 헤더 - X-Amz-Firehose-Request-Id** 이 헤더의 값은 디버깅 및 중복 제거 목적으로 사용할 수 있는 불분명한 GUID입니다. 엔드포인트 구현은 이 헤더의 값을, 가능하면 성공 및 실패한 요청 모두에 대해 기록해야 합니다. 요청 ID는 같은 요청을 여러 번 시도해도 동일하게 유지됩니다. **HTTP 헤더 - Content-Type** Content-Type 헤더의 값은 항상 `application/json`입니다. **HTTP 헤더 - Content-Encoding** 요청을 전송할 때 GZIP을 사용하여 본문을 압축하도록 Firehose 스트림을 구성할 수 있습니다. 이 압축이 활성화되면, 표준 관행에 따라 Content-Encoding 헤더의 값은 gzip으로 설정됩니다. 압축이 활성화되지 않으면, Content-Encoding 헤더 자체가 없습니다. **HTTP 헤더 - Content-Length** 이 헤더는 표준 방식으로 사용됩니다. **HTTP 헤더 - X-Amz-Firehose-Source-Arn:** ASCII 문자열 형식으로 표현된 Firehose 스트림의 ARN입니다. ARN은 리전, AWS 계정 ID 및 스트림 이름을 인코딩합니다. 예를 들어 `arn:aws:firehose:us-east-1:123456789:deliverystream/testStream`입니다. **HTTP 헤더 - X-Amz-Firehose-Access-Key** 이 헤더에는 API 키 또는 다른 자격 증명이 포함됩니다. 전송 스트림을 만들거나 업데이트할 때 API 키(인증 토큰)를 만들거나 업데이트할 수 있습니다. Amazon Data Firehose는 액세스 키의 크기를 4,096바이트로 제한합니다. Amazon Data Firehose는 어떤 방식으로도 이 키를 해석하려는 시도를 하지 않습니다. 구성된 키는 그대로 이 헤더 값에 복사됩니다. 그러나 Secrets Manager를 사용하여 키를 구성하는 경우 보안 암호는 특정 JSON 객체 형식인 `{"api_key": "..."}`을(를) 따라야 합니다. 그 내용은 임의적이며 JWT 토큰 또는 ACCESS\$1KEY를 나타낼 가능성이 있습니다. 엔드포인트에 다중 필드 자격 증명(예: 사용자 이름 및 암호) 이 필요한 경우, 모든 필드의 값을 엔드포인트가 인식하는 형식(JSON 또는 CSV)으로 단일 액세스 키 내에 함께 저장해야 합니다. 원본 콘텐츠가 바이너리인 경우, 이 필드는 Base-64로 인코딩될 수 있습니다. Amazon Data Firehose는 구성된 값을 수정 및/또는 인코딩하지 않고 해당 콘텐츠를 그대로 사용합니다. **HTTP 헤더 - X-Amz-Firehose-Common-Attributes** 이 헤더에는 전체 요청 및/또는 요청 내의 모든 레코드와 관련된 공통 속성(메타데이터)이 포함됩니다. 이는 Firehose 스트림을 만들 때 사용자가 직접 구성합니다. 이러한 속성 값은 다음 스키마를 사용하여 JSON 객체로 인코딩됩니다. ``` "$schema": http://json-schema.org/draft-07/schema# properties: commonAttributes: type: object minProperties: 0 maxProperties: 50 patternProperties: "^.{1,256}$": type: string minLength: 0 maxLength: 1024 ``` 다음은 그 예입니다. ``` "commonAttributes": { "deployment -context": "pre-prod-gamma", "device-types": "" } ``` **본문 - 최대 크기** 최대 본문 크기는 사용자가 구성하며 압축 전 최대 64MiB까지 가능합니다. **본문 - 스키마** 본문에는 다음과 같은 JSON Schema(YAML로 작성)를 사용한 단일 JSON 문서가 포함됩니다. ``` "$schema": http://json-schema.org/draft-07/schema# title: FirehoseCustomHttpsEndpointRequest description: > The request body that the Firehose service sends to custom HTTPS endpoints. type: object properties: requestId: description: > Same as the value in the X-Amz-Firehose-Request-Id header, duplicated here for convenience. type: string timestamp: description: > The timestamp (milliseconds since epoch) at which the Firehose server generated this request. type: integer records: description: > The actual records of the Firehose stream, carrying the customer data. type: array minItems: 1 maxItems: 10000 items: type: object properties: data: description: > The data of this record, in Base64. Note that empty records are permitted in Firehose. The maximum allowed size of the data, before Base64 encoding, is 1024000 bytes; the maximum length of this field is therefore 1365336 chars. type: string minLength: 0 maxLength: 1365336 required: - requestId - records ``` 다음은 그 예입니다. ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599 "records": [ { "data": "aGVsbG8=" }, { "data": "aGVsbG8gd29ybGQ=" } ] } ``` ## 응답 형식 **오류 발생 시 기본 동작** 응답이 아래 요구 사항을 준수하지 못하는 경우, Firehose 서버는 이를 본문 없이 500 상태 코드가 있는 것처럼 처리합니다. **상태 코드** HTTP 상태 코드는 반드시 2XX, 4XX 또는 5XX 범위에 있어야 합니다. Amazon Data Firehose 서버는 리디렉션(3XX 상태 코드)을 따르지 않습니다. 레코드를 HTTP/EP에 성공적으로 전송한 것으로 간주되는 것은 응답 코드 200뿐입니다. 응답 코드 413(크기 초과)은 영구 실패로 간주되며, 이 코드가 구성되면 레코드 배치가 오류 버킷으로 전송되지 않습니다. 다른 모든 응답 코드는 재시도 가능한 오류로 간주되며, 이후 설명할 백오프 재시도 알고리즘이 적용됩니다. **헤더 – 콘텐츠 유형** 허용되는 유일한 콘텐츠 유형은 애플리케이션/json입니다. **HTTP 헤더 - Content-Encoding** 콘텐츠 인코딩은 사용하지 않아야 합니다. 본문은 반드시 압축을 풀어야 합니다. **HTTP 헤더 - Content-Length** 응답에 본문이 있는 경우 반드시 Content-Length 헤더가 있어야 합니다. **본문 - 최대 크기** 응답 본문의 크기는 1MiB 이하여야 합니다. ``` "$schema": http://json-schema.org/draft-07/schema# title: FirehoseCustomHttpsEndpointResponse description: > The response body that the Firehose service sends to custom HTTPS endpoints. type: object properties: requestId: description: > Must match the requestId in the request. type: string timestamp: description: > The timestamp (milliseconds since epoch) at which the server processed this request. type: integer errorMessage: description: > For failed requests, a message explaining the failure. If a request fails after exhausting all retries, the last Instance of the error message is copied to error output S3 bucket if configured. type: string minLength: 0 maxLength: 8192 required: - requestId - timestamp ``` 다음은 그 예입니다. ``` Failure Case (HTTP Response Code 4xx or 5xx) { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": "1578090903599", "errorMessage": "Unable to deliver records due to unknown error." } Success case (HTTP Response Code 200) { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090903599 } ``` **오류 응답 처리** 모든 오류 사례에서 Amazon Data Firehose 서버는 지수 백오프 알고리즘을 사용하여 동일한 레코드 배치의 전송을 다시 시도합니다. 지터 계수 (15%)인 초기 백오프 시간(1초)을 사용하여 재시도가 백오프되고, 이후 재시도할 때마다 지터가 추가된 공식(초기 백오프 시간\$1 (승수(2) ^ retry\$1count))을 사용하여 백오프됩니다. 백오프 시간은 최대 2분 간격으로 제한됩니다. 예를 들어, 'n번째 재시도' 시 백오프 시간은 최대(120, 2^n) \$1 무작위(0.85, 1,15)입니다. 이전 방정식에서 지정된 파라미터는 변경될 수 있습니다. 지수 백오프 알고리즘에 사용되는 정확한 초기 백오프 시간, 최대 백오프 시간, 승수 및 지터 백분율은 AWS Firehose 설명서를 참조하세요. 이후에 다시 시도할 때마다 레코드가 전송되는 액세스 키 및/또는 대상은 업데이트된 Firehose 스트림 구성에 따라 변경될 수 있습니다. Amazon Data Firehose 서비스는 최선의 방법으로 여러 번의 재시도에 걸쳐 동일한 요청 ID(request-id)를 사용합니다. 이 최신 기능은 HTTP 엔드포인트 서버에서 중복 제거 목적으로 사용할 수 있습니다. Firehose 스트림 구성에 따라 허용된 최대 시간이 지난 후에도 요청이 전달되지 않는 경우, 스트림 구성에 따라 레코드 배치를 오류 버킷에 선택적으로 전송할 수 있습니다. ## 예제 CWLog 소싱 요청의 예: ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599, "records": [ { "data": { "messageType": "DATA_MESSAGE", "owner": "123456789012", "logGroup": "log_group_name", "logStream": "log_stream_name", "subscriptionFilters": [ "subscription_filter_name" ], "logEvents": [ { "id": "0123456789012345678901234567890123456789012345", "timestamp": 1510109208016, "message": "log message 1" }, { "id": "0123456789012345678901234567890123456789012345", "timestamp": 1510109208017, "message": "log message 2" } ] } } ] } ``` # 데이터 전송 실패 처리 각 Amazon Data Firehose 대상마다 고유한 데이터 전송 실패 처리 방식이 있습니다. OpenSearch, Splunk, HTTP 엔드포인트 등 다양한 대상에 대해 Firehose 스트림을 설정할 때, 전송에 실패한 데이터를 백업할 수 있는 S3 버킷도 설정합니다. 전송 실패 시 Firehose가 데이터를 백업하는 방법에 대한 자세한 내용은 이 페이지의 관련 대상 섹션을 참조하세요. 전송되지 못한 데이터를 백업할 수 있는 S3 버킷에 대한 액세스 권한 부여 방법에 대해서는 [Firehose에 Amazon S3 대상 액세스 권한 부여](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3)를 참조하세요. Firehose가 (a) 스트림 대상으로 데이터를 전송하지 못하고 (b) 전송 실패에 따라 백업 S3 버킷에 데이터 쓰기에 실패한 경우, 데이터가 대상으로 전달되거나 백업 S3 위치에 기록될 때까지 스트림 전송을 사실상 일시 중지합니다. ## Amazon S3 S3 버킷에 대한 데이터 전송은 여러 가지 이유로 실패할 수 있습니다. 예를 들어 버킷이 더 이상 존재하지 않거나, Amazon Data Firehose가 맡은 IAM 역할에 버킷 액세스 권한이 없거나, 네트워크 장애 또는 이와 유사한 이벤트가 발생하는 경우입니다. 이러한 조건에서 Amazon Data Firehose는 전송에 성공할 때까지 최대 24시간 동안 계속 재시도를 합니다. Amazon Data Firehose의 최대 데이터 스토리지 시간은 24시간입니다. 24시간 넘게 데이터 전송에 실패할 경우 데이터를 잃게 됩니다. S3 버킷에 대한 데이터 전송은 여러 가지 이유로 실패할 수 있습니다. + 버킷이 더 이상 존재하지 않습니다. + Amazon Data Firehose에서 수임하는 IAM 역할에는 버킷에 대한 액세스 권한이 없습니다. + 네트워크 문제가 발생했습니다. + HTTP 500 또는 기타 API 실패와 같은 S3 오류가 발생했습니다. 이러한 경우 Amazon Data Firehose는 전송을 재시도합니다. + **DirectPut 소스:** 재시도는 최대 24시간 동안 계속됩니다. + **Kinesis Data Streams 또는 Amazon MSK 소스:** 재시도는 스트림에 정의된 보존 정책까지 무기한 계속됩니다. Amazon Data Firehose는 Lambda 처리 또는 파켓 변환이 실패할 때만 실패한 레코드를 S3 오류 버킷으로 전송합니다. 다른 장애 시나리오에서는 보존 기간에 도달할 때까지 S3를 계속 재시도합니다. Firehose가 S3에 레코드를 성공적으로 전송하면 S3 객체 파일이 생성되고 부분 레코드 실패 시 자동으로 전송을 재시도하고 성공적으로 처리된 레코드로 동일한 S3 객체 파일을 업데이트합니다. ## Amazon Redshift Amazon Redshift 대상에 대해 Firehose 스트림 생성 시 재시도 기간(0\$17200초)을 지정할 수 있습니다. 여러 가지 이유로 인해 Amazon Redshift 프로비저닝된 클러스터 또는 Amazon Redshift Serverless 작업 그룹으로의 데이터 전송이 실패할 수 있습니다. 예를 들어 Firehose 스트림의 잘못된 클러스터 구성, 클러스터 또는 작업 그룹의 유지 관리 진행, 네트워크 장애 등이 이유가 될 수 있습니다. 이러한 조건에서 Amazon Data Firehose는 지정된 시간 동안 재시도를 수행하고 이 Amazon S3 객체의 특정 배치를 건너뜁니다. 건너뛴 객체의 정보는 `errors/` 폴더의 매니페스트 파일로 S3 버킷에 전송되며, 이를 수동 채우기에 사용할 수 있습니다. 매니페스트 파일로 데이터를 수동으로 COPY하는 방법에 대한 내용은 [매니페스트를 사용한 데이터 파일 지정](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-files-using-manifest.html)을 참조하세요. ## Amazon OpenSearch Service 및 OpenSearch Serverless OpenSearch Service 및 OpenSearch Serverless 대상의 경우 Firehose 스트림 생성 시 재시도 기간(0\$17200초)을 지정할 수 있습니다. 여러 가지 이유로 OpenSearch Service 클러스터 또는 OpenSearch Serverless 컬렉션으로의 데이터 전송이 실패할 수 있습니다. 예를 들어 Firehose 스트림의 잘못된 OpenSearch Service 클러스터 또는 OpenSearch Serverless 컬렉션 구성, OpenSearch Service 클러스터 또는 OpenSearch Serverless 컬렉션의 유지 관리 진행, 네트워크 장애 또는 이와 유사한 이벤트 발생 등이 이유가 될 수 있습니다. 이러한 조건에서 Amazon Data Firehose는 지정된 시간 동안 재시도를 수행하고 특정 인덱스 요청을 건너뜁니다. 건너뛴 문서는 `AmazonOpenSearchService_failed/` 폴더를 통해 S3 버킷에 전송되며, 이를 수동 채우기에 사용할 수 있습니다. OpenSearch Service의 경우 각 문서의 JSON 형식은 다음과 같습니다. ``` { "attemptsMade": "(number of index requests attempted)", "arrivalTimestamp": "(the time when the document was received by Firehose)", "errorCode": "(http error code returned by OpenSearch Service)", "errorMessage": "(error message returned by OpenSearch Service)", "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)", "esDocumentId": "(intended OpenSearch Service document ID)", "esIndexName": "(intended OpenSearch Service index name)", "esTypeName": "(intended OpenSearch Service type name)", "rawData": "(base64-encoded document data)" } ``` OpenSearch Serverless의 경우 각 문서의 JSON 형식은 다음과 같습니다. ``` { "attemptsMade": "(number of index requests attempted)", "arrivalTimestamp": "(the time when the document was received by Firehose)", "errorCode": "(http error code returned by OpenSearch Serverless)", "errorMessage": "(error message returned by OpenSearch Serverless)", "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)", "osDocumentId": "(intended OpenSearch Serverless document ID)", "osIndexName": "(intended OpenSearch Serverless index name)", "rawData": "(base64-encoded document data)" } ``` ## Splunk Amazon Data Firehose는 Splunk로 데이터를 전송할 때 Splunk로부터 확인을 기다립니다. 오류가 발생하거나 확인 제한 시간 내에 확인 메시지가 도착하지 않을 경우, Amazon Data Firehose는 재시도 기간 카운터를 시작합니다. 재시도 지속시간이 만료될 때까지 재시도합니다. 그 다음 Amazon Data Firehose는 이를 데이터 전송 실패로 간주하고 데이터를 Amazon S3 버킷에 백업합니다. Amazon Data Firehose는 Splunk로 데이터를 전송할 때마다(최초 시도이든 재시도이든 상관없이) 확인 제한 시간 카운터를 다시 시작합니다. 그런 다음 Splunk로부터 수신 확인을 기다립니다. 재시도 기간이 만료되어도, Amazon Data Firehose는 확인을 수신하거나 확인 제한 시간에 도달할 때까지 확인을 기다립니다. 확인 시간이 초과한 경우 Amazon Data Firehose는 재시도 카운터에 시간이 남아 있는지 확인합니다. 시간이 남은 경우 다시 시도하여 확인을 수신하거나 재시도 시간이 만료되었는지 확인할 때까지 논리를 반복합니다. 확인 수신에 실패하는 것이 발생할 수 있는 유일한 데이터 전송 오류는 아닙니다. 데이터 전송 오류의 다른 유형에 대한 내용은 [Splunk 데이터 전송 오류](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-splunk-errors)를 참조하세요. 모든 데이터 전송 오류는 재시도 지속시간이 0보다 클 경우 재시도 로직을 트리거합니다. 다음은 오류 레코드의 예입니다. ``` { "attemptsMade": 0, "arrivalTimestamp": 1506035354675, "errorCode": "Splunk.AckTimeout", "errorMessage": "Did not receive an acknowledgement from HEC before the HEC acknowledgement timeout expired. Despite the acknowledgement timeout, it's possible the data was indexed successfully in Splunk. Amazon Data Firehose backs up in Amazon S3 data for which the acknowledgement timeout expired.", "attemptEndingTimestamp": 13626284715507, "rawData": "MiAyNTE2MjAyNzIyMDkgZW5pLTA1ZjMyMmQ1IDIxOC45Mi4xODguMjE0IDE3Mi4xNi4xLjE2NyAyNTIzMyAxNDMzIDYgMSA0MCAxNTA2MDM0NzM0IDE1MDYwMzQ3OTQgUkVKRUNUIE9LCg==", "EventId": "49577193928114147339600778471082492393164139877200035842.0" } ``` ## HTTP 엔드포인트 대상 Amazon Data Firehose는 HTTP 엔드포인트 대상으로 데이터를 전송하고 이 대상의 응답을 기다립니다. 오류가 발생하거나 응답 제한 시간 내에 응답 메시지가 도착하지 않을 경우, Amazon Data Firehose는 재시도 기간 카운터를 시작합니다. 재시도 지속시간이 만료될 때까지 재시도합니다. 그 다음 Amazon Data Firehose는 이를 데이터 전송 실패로 간주하고 데이터를 Amazon S3 버킷에 백업합니다. Amazon Data Firehose는 HTTP 엔드포인트 대상으로 데이터를 전송할 때마다(최초 시도이든 재시도이든 상관없이) 확인 제한 시간 카운터를 다시 시작합니다. 그런 다음 HTTP 엔드포인트 대상에서 응답이 도착하기를 기다립니다. 재시도 기간이 만료되어도, Amazon Data Firehose는 응답을 수신하거나 응답 제한 시간에 도달할 때까지 응답을 기다립니다. 응답 시간이 초과한 경우 Amazon Data Firehose는 재시도 카운터에 시간이 남아 있는지 확인합니다. 시간이 남은 경우 다시 시도하여 응답을 수신하거나 재시도 시간 만료가 확인될 때까지 논리를 반복합니다. 응답 수신에 실패하는 것이 발생할 수 있는 유일한 데이터 전송 오류는 아닙니다. 데이터 전송 오류의 다른 유형에 대한 내용은 [HTTP 엔드포인트 데이터 전송 오류](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-http-errors)를 참조하세요. 다음은 오류 레코드의 예입니다. ``` { "attemptsMade":5, "arrivalTimestamp":1594265943615, "errorCode":"HttpEndpoint.DestinationException", "errorMessage":"Received the following response from the endpoint destination. {"requestId": "109777ac-8f9b-4082-8e8d-b4f12b5fc17b", "timestamp": 1594266081268, "errorMessage": "Unauthorized"}", "attemptEndingTimestamp":1594266081318, "rawData":"c2FtcGxlIHJhdyBkYXRh", "subsequenceNumber":0, "dataId":"49607357361271740811418664280693044274821622880012337186.0" } ``` ## Snowflake Snowflake 대상의 경우 Firehose 스트림을 생성할 때 선택 사항으로 재시도 기간(0\$17,200초)을 지정할 수 있습니다. 재시도 기간의 기본값은 60초입니다. Snowflake 테이블로 데이터 전송 시 잘못된 Snowflake 대상 구성, Snowflake 중단, 네트워크 장애 등의 몇 가지 이유로 실패할 수 있습니다. 재시도할 수 없는 오류에는 재시도 정책이 적용되지 않습니다. 예를 들어 테이블에 누락된 추가 열이 있어서 Snowflake가 JSON 페이로드를 거부하는 경우, Firehose는 전송을 재시도하지 않습니다. 대신 JSON 페이로드 문제로 인한 모든 삽입 실패 관련 백업을 S3 오류 버킷에 생성합니다. 마찬가지로 잘못된 역할, 테이블 또는 데이터베이스로 인해 전송이 실패하는 경우 Firehose는 재시도하지 않고 S3 버킷에 데이터를 기록합니다. 재시도 기간은 Snowflake 서비스 문제, 일시적인 네트워크 결함 등으로 인한 오류에만 적용됩니다. 이러한 조건에서 Firehose는 지정된 기간 동안 재시도한 후 S3에 데이터를 전송합니다. 실패한 레코드는 snowflake-failed/ 폴더에 전송되어 수동 채우기가 가능합니다. 다음은 S3에 전송하는 각 레코드에 대한 JSON 예제입니다. ``` { "attemptsMade": 3, "arrivalTimestamp": 1594265943615, "errorCode": "Snowflake.InvalidColumns", "errorMessage": "Snowpipe Streaming does not support columns of type AUTOINCREMENT, IDENTITY, GEO, or columns with a default value or collation", "attemptEndingTimestamp": 1712937865543, "rawData": "c2FtcGxlIHJhdyBkYXRh" } ``` # Amazon S3 객체 이름 형식 구성 Firehose가 Amazon S3에 데이터를 전송하면 S3 객체 키 이름은 ** 형식을 따르며, 접미사는 *-------- * 형식을 따릅니다. 이 형식은 1로 시작되며 Firehose 스트림의 구성이 변경될 때마다 1씩 증가합니다. Firehose 스트림 구성(예: S3 버킷 이름, 버퍼링 힌트, 압축, 암호화)을 변경할 수 있습니다. 이 작업은 Firehose 콘솔 또는 [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html) API 작업을 사용하여 수행할 수 있습니다. *<평가된 접두사>*의 경우 Firehose는 `YYYY/MM/dd/HH` 형식에 기본 시간 접두사를 추가합니다. 이 접두사는 버킷에 논리적 계층 구조를 생성하는데, 계층 구조 내에서 슬래시(/) 하나당 한 계층을 생성합니다. 런타임 시 평가되는 표현식을 포함하는 사용자 지정 접두사를 지정하면 이 구조를 수정할 수 있습니다. 사용자 지정 접두사를 지정하는 방법에 대한 자세한 정보는 [Custom Prefixes for Amazon Simple Storage Service Objects](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html)(Amazon Simple Storage Service 객체의 사용자 지정 접두사)를 참조하세요. 기본적으로 시간 접두사 및 접미사에 사용되는 시간대는 UTC이지만 원하는 시간대로 변경할 수 있습니다. 예를 들어 UTC 대신 일본 표준시를 사용하려면 AWS Management Console 또는 [API 파라미터 설정(CustomTimeZone)](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html)에서 시간대를 아시아/도쿄로 구성할 수 있습니다. 다음 목록에는 S3 접두사 구성 시 Firehose가 지원하는 시간대가 포함되어 있습니다. ## 지원되는 시간대 다음은 Firehose가 S3 접두사 구성 시에 지원하는 시간대 목록입니다. ------ #### [ Africa ] ``` Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers Africa/Asmera Africa/Bangui Africa/Banjul Africa/Bissau Africa/Blantyre Africa/Bujumbura Africa/Cairo Africa/Casablanca Africa/Conakry Africa/Dakar Africa/Dar_es_Salaam Africa/Djibouti Africa/Douala Africa/Freetown Africa/Gaborone Africa/Harare Africa/Johannesburg Africa/Kampala Africa/Khartoum Africa/Kigali Africa/Kinshasa Africa/Lagos Africa/Libreville Africa/Lome Africa/Luanda Africa/Lubumbashi Africa/Lusaka Africa/Malabo Africa/Maputo Africa/Maseru Africa/Mbabane Africa/Mogadishu Africa/Monrovia Africa/Nairobi Africa/Ndjamena Africa/Niamey Africa/Nouakchott Africa/Ouagadougou Africa/Porto-Novo Africa/Sao_Tome Africa/Timbuktu Africa/Tripoli Africa/Tunis Africa/Windhoek ``` ------ #### [ America ] ``` America/Adak America/Anchorage America/Anguilla America/Antigua America/Aruba America/Asuncion America/Barbados America/Belize America/Bogota America/Buenos_Aires America/Caracas America/Cayenne America/Cayman America/Chicago America/Costa_Rica America/Cuiaba America/Curacao America/Dawson_Creek America/Denver America/Dominica America/Edmonton America/El_Salvador America/Fortaleza America/Godthab America/Grand_Turk America/Grenada America/Guadeloupe America/Guatemala America/Guayaquil America/Guyana America/Halifax America/Havana America/Indianapolis America/Jamaica America/La_Paz America/Lima America/Los_Angeles America/Managua America/Manaus America/Martinique America/Mazatlan America/Mexico_City America/Miquelon America/Montevideo America/Montreal America/Montserrat America/Nassau America/New_York America/Noronha America/Panama America/Paramaribo America/Phoenix America/Port_of_Spain America/Port-au-Prince America/Porto_Acre America/Puerto_Rico America/Regina America/Rio_Branco America/Santiago America/Santo_Domingo America/Sao_Paulo America/Scoresbysund America/St_Johns America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Tegucigalpa America/Thule America/Tijuana America/Tortola America/Vancouver America/Winnipeg ``` ------ #### [ Antarctica ] ``` Antarctica/Casey Antarctica/DumontDUrville Antarctica/Mawson Antarctica/McMurdo Antarctica/Palmer ``` ------ #### [ Asia ] ``` Asia/Aden Asia/Almaty Asia/Amman Asia/Anadyr Asia/Aqtau Asia/Aqtobe Asia/Ashgabat Asia/Ashkhabad Asia/Baghdad Asia/Bahrain Asia/Baku Asia/Bangkok Asia/Beirut Asia/Bishkek Asia/Brunei Asia/Calcutta Asia/Colombo Asia/Dacca Asia/Damascus Asia/Dhaka Asia/Dubai Asia/Dushanbe Asia/Hong_Kong Asia/Irkutsk Asia/Jakarta Asia/Jayapura Asia/Jerusalem Asia/Kabul Asia/Kamchatka Asia/Karachi Asia/Katmandu Asia/Krasnoyarsk Asia/Kuala_Lumpur Asia/Kuwait Asia/Macao Asia/Magadan Asia/Manila Asia/Muscat Asia/Nicosia Asia/Novosibirsk Asia/Phnom_Penh Asia/Pyongyang Asia/Qatar Asia/Rangoon Asia/Riyadh Asia/Saigon Asia/Seoul Asia/Shanghai Asia/Singapore Asia/Taipei Asia/Tashkent Asia/Tbilisi Asia/Tehran Asia/Thimbu Asia/Thimphu Asia/Tokyo Asia/Ujung_Pandang Asia/Ulaanbaatar Asia/Ulan_Bator Asia/Vientiane Asia/Vladivostok Asia/Yakutsk Asia/Yekaterinburg Asia/Yerevan ``` ------ #### [ Atlantic ] ``` Atlantic/Azores Atlantic/Bermuda Atlantic/Canary Atlantic/Cape_Verde Atlantic/Faeroe Atlantic/Jan_Mayen Atlantic/Reykjavik Atlantic/South_Georgia Atlantic/St_Helena Atlantic/Stanley ``` ------ #### [ Australia ] ``` Australia/Adelaide Australia/Brisbane Australia/Broken_Hill Australia/Darwin Australia/Hobart Australia/Lord_Howe Australia/Perth Australia/Sydney ``` ------ #### [ Europe ] ``` Europe/Amsterdam Europe/Andorra Europe/Athens Europe/Belgrade Europe/Berlin Europe/Brussels Europe/Bucharest Europe/Budapest Europe/Chisinau Europe/Copenhagen Europe/Dublin Europe/Gibraltar Europe/Helsinki Europe/Istanbul Europe/Kaliningrad Europe/Kiev Europe/Lisbon Europe/London Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Minsk Europe/Monaco Europe/Moscow Europe/Oslo Europe/Paris Europe/Prague Europe/Riga Europe/Rome Europe/Samara Europe/Simferopol Europe/Sofia Europe/Stockholm Europe/Tallinn Europe/Tirane Europe/Vaduz Europe/Vienna Europe/Vilnius Europe/Warsaw Europe/Zurich ``` ------ #### [ Indian ] ``` Indian/Antananarivo Indian/Chagos Indian/Christmas Indian/Cocos Indian/Comoro Indian/Kerguelen Indian/Mahe Indian/Maldives Indian/Mauritius Indian/Mayotte Indian/Reunion ``` ------ #### [ Pacific ] ``` Pacific/Apia Pacific/Auckland Pacific/Chatham Pacific/Easter Pacific/Efate Pacific/Enderbury Pacific/Fakaofo Pacific/Fiji Pacific/Funafuti Pacific/Galapagos Pacific/Gambier Pacific/Guadalcanal Pacific/Guam Pacific/Honolulu Pacific/Kiritimati Pacific/Kosrae Pacific/Majuro Pacific/Marquesas Pacific/Nauru Pacific/Niue Pacific/Norfolk Pacific/Noumea Pacific/Pago_Pago Pacific/Palau Pacific/Pitcairn Pacific/Ponape Pacific/Port_Moresby Pacific/Rarotonga Pacific/Saipan Pacific/Tahiti Pacific/Tarawa Pacific/Tongatapu Pacific/Truk Pacific/Wake Pacific/Wallis ``` ------ **을 제외한 접미사 필드는 변경할 수 없습니다. 데이터 형식 변환 또는 압축을 사용하면 Firehose는 구성을 기반으로 파일 확장자를 추가합니다. 다음 표는 Firehose가 추가하는 기본 파일 확장명을 설명합니다. | 구성 | 파일 확장명 | | --- | --- | | 데이터 형식 변환: Parquet | .parquet | | 데이터 형식 변환: ORC | .orc | | 압축: Gzip | .gz | | 압축: Zip | .zip | | 압축: Snappy | .snappy | | 압축: Hadoop-Snappy | .hsnappy | Firehose 콘솔이나 API에서 원하는 파일 확장자를 지정할 수도 있습니다. 파일 확장자는 마침표(.)로 시작해야 하며 문자 0\$19a\$1z\$1-\$1.\$1‘()를 포함할 수 있습니다. 파일 확장자는 128자를 초과할 수 없습니다. **참고** 파일 확장자를 지정하면 [데이터 형식 변환](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html) 또는 압축을 사용할 때 Firehose가 추가하는 기본 파일 확장자를 재정의합니다. # Amazon S3 객체의 사용자 지정 접두사 이해 Amazon S3에 전달되는 객체는 <평가된 접두사><접미사>의 [이름 형식](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-namekey)을 따릅니다. 런타임에 평가되는 표현식을 포함하는 사용자 지정 접두사를 지정할 수 있습니다. 지정한 사용자 지정 접두사는 기본 접두사인 `yyyy/MM/dd/HH`를 재정의합니다. 사용자 지정 접두사에 `!{namespace:value}` 형식의 표현식을 사용할 수 있으며, 여기서 `namespace`는 다음 섹션에서 설명하듯이 다음 중 하나가 될 수 있습니다. + `firehose` + `timestamp` + `partitionKeyFromQuery` + `partitionKeyFromLambda` 슬래시로 끝나는 접두사는 Amazon S3 버킷에서 자리 표시자로 나타납니다. 자세한 내용은 *Amazon Data FirehoseDeveloper 안내서*의 [Amazon S3 객체 이름 형식](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name)을 참조하세요. ## `timestamp` 네임스페이스 이 네임스페이스에 유효한 값은 유효한 [Java DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) 문자열입니다. 예를 들어 2018년에 `!{timestamp:yyyy}` 표현식은 `2018`로 평가됩니다. 타임스탬프 평가 시, Firehose는 기록되는 Amazon S3 객체에 포함된 가장 오래된 레코드의 근사 도착 타임스탬프를 사용합니다. 기본적으로 타임스탬프는 UTC입니다. 하지만 원하는 시간대를 지정할 수 있습니다. 예를 들어 UTC 대신 일본 표준시를 사용하려는 경우 AWS Management Console 또는 API 파라미터 설정([CustomTimeZone](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html))에서 시간대를 아시아/도쿄로 구성할 수 있습니다. 지원되는 시간대 목록을 보려면 [Amazon S3 객체 이름 형식](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name)을 참조하세요. 동일한 접두사 표현식에 `timestamp` 네임스페이스를 한 번 넘게 사용할 경우 각 인스턴스는 동일한 시간으로 평가됩니다. ## `firehose` 네임스페이스 이 네임스페이스에는 `error-output-type` 값과 `random-string` 값을 사용할 수 있습니다. 다음 표에는 사용 방법이 나와 있습니다. **`firehose` 네임스페이스 값** | 변환 | 설명 | 입력 예 | 출력 예시 | 참고 | | --- | --- | --- | --- | --- | | error-output-type | Firehose 스트림 구성 및 실패 이유에 따라 \$1processing-failed, AmazonOpenSearchService-failed, splunk-failed, format-conversion-failed, http-endpoint-failed\$1 문자열 중 하나로 평가됩니다.동일한 접두사 표현식에 한 번 넘게 사용할 경우 각 인스턴스는 동일한 오류 문자열로 평가됩니다. | myPrefix/result=\$1\$1firehose:error-output-type\$1/\$1\$1timestamp:yyyy/MM/dd\$1 | myPrefix/result=processing-failed/2018/08/03 | error-output-type 값은 ErrorOutputPrefix 필드에만 사용할 수 있습니다. | | random-string | 11자의 무작위 문자열로 평가됩니다. 동일한 접두사 표현식에 한 번 넘게 사용할 경우 각 인스턴스는 새로운 무작위 문자열로 평가됩니다. | myPrefix/\$1\$1firehose:random-string\$1/ | myPrefix/046b6c7f-0b/ | 두 접두사 유형 모두에 사용할 수 있습니다.형식 문자열 선두에 이를 배치하여 무작위의 접두사를 얻을 수 있으며, 경우에 따라 이 접두사는 Amazon S3를 통해 최고의 처리량을 얻기 위해 필요한 경우가 있습니다. | ## `partitionKeyFromLambda` 및 `partitionKeyFromQuery` 네임스페이스 [동적 파티셔닝](dynamic-partitioning.md)의 경우, S3 버킷 접두사에 다음 표현식 형식을 사용해야 합니다: `!{namespace:value}`, 여기서 네임스페이스는 `partitionKeyFromQuery` 또는 `partitionKeyFromLambda`이거나, 둘 다일 수 있습니다. 인라인 구문 분석을 사용하여 소스 데이터에 대한 파티션 키를 생성하는 경우 다음 형식으로 지정된 표현식으로 구성되는 S3 버킷 접두사 값을 지정해야 합니다: `"partitionKeyFromQuery:keyID"`. AWS Lambda 함수를 사용하여 소스 데이터에 대한 파티션 키를 생성하는 경우 다음 형식으로 지정된 표현식으로 구성되는 S3 버킷 접두사 값을 지정해야 합니다: `"partitionKeyFromLambda:keyID"`. 자세한 내용은 [Amazon Firehose 스트림 생성](basic-create.md#basic-create.title)의 “Amazon S3를 대상으로 선택”을 참조하세요. ## 의미 체계 규칙 `Prefix` 및 `ErrorOutputPrefix` 표현식에 적용되는 규칙은 다음과 같습니다. + `timestamp` 네임스페이스의 경우 작은따옴표로 묶이지 않은 문자가 평가됩니다. 즉, 값 필드에서 작은따옴표로 이스케이프 처리된 문자열은 문자로 처리됩니다. + 타임스탬프 네임스페이스 표현식을 포함하지 않는 접두사를 지정할 경우, Firehose는 `Prefix` 필드의 값에 `!{timestamp:yyyy/MM/dd/HH/}` 표현식을 추가합니다. + `!{` 시퀀스는 `!{namespace:value}` 표현식에만 나타날 수 있습니다. + `Prefix`에 표현식이 없을 경우에만 `ErrorOutputPrefix`가 null이 될 수 있습니다. 이 경우 `Prefix`는 `yyyy/MM/DDD/HH/`로 평가되고 `ErrorOutputPrefix`는 `yyyy/MM/DDD/HH/`로 평가됩니다. `DDD`는 해당 연도의 날짜를 나타냅니다. + `ErrorOutputPrefix`에 표현식을 지정할 경우, 최소 한 개의 `!{firehose:error-output-type}` 인스턴스를 포함시켜야 합니다. + `Prefix`에는 `!{firehose:error-output-type}`을 포함할 수 없습니다. + `Prefix` 또는 `ErrorOutputPrefix`는 평가 후 512자를 넘을 수 없습니다. + 대상이 Amazon Redshift인 경우, `Prefix`에 표현식이 포함되어서는 안 되며, `ErrorOutputPrefix`는 null이어야 합니다. + 대상이 Amazon OpenSearch Service 또는 Splunk이고 지정된 `ErrorOutputPrefix`가 없는 경우 Firehose는 실패한 레코드에 `Prefix` 필드를 사용합니다. + 대상이 Amazon S3인 경우 Amazon S3 대상 구성의 `Prefix` 및 `ErrorOutputPrefix`를 각각 성공 레코드 및 실패 레코드에 사용합니다. AWS CLI 또는 API를 사용하는 경우 `ExtendedS3DestinationConfiguration`을 사용하여 자체 `Prefix`와 `ErrorOutputPrefix`로 Amazon S3 *백업* 구성을 지정할 수 있습니다. + 를 사용하고 대상을 Amazon S3로 AWS Management Console 설정하면 Firehose는 각각 성공적인 레코드`Prefix`와 실패한 레코드에 대해 대상 구성`ErrorOutputPrefix`에서 및를 사용합니다. 표현식을 사용하여 접두사를 지정하는 경우 `!{firehose:error-output-type}`를 포함한 오류 접두사를 지정해야 합니다. + 를 AWS CLI, API와 `ExtendedS3DestinationConfiguration` 함께 사용하거나를 지정하는 CloudFormation경우 `S3BackupConfiguration`Firehose는 기본를 제공하지 않습니다`ErrorOutputPrefix`. + ErrorOutputPrefix 표현식을 생성할 때 `partitionKeyFromLambda` 및 `partitionKeyFromQuery` 네임스페이스를 사용할 수 없습니다. ## 접두사의 예 **`Prefix` 및 `ErrorOutputPrefix`의 예** | Input | 평가된 접두사(2018년 8월 27일 오전 10:30 UTC) | | --- | --- | | `Prefix`: 지정 안 함 `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/` | `Prefix`: `2018/08/27/10` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/` | | `Prefix`: `!{timestamp:yyyy/MM/dd}` `ErrorOutputPrefix`: 지정 안 함 | 잘못된 입력: 접두사에 표현식이 포함된 경우 ErrorOutputPrefix는 null이 될 수 없음 | | `Prefix`: `myFirehose/DeliveredYear=!{timestamp:yyyy}/anyMonth/rand=!{firehose:random-string}` `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/!{timestamp:yyyy}/anyMonth/!{timestamp:dd}` | `Prefix`: `myFirehose/DeliveredYear=2018/anyMonth/rand=5abf82daaa5` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/2018/anyMonth/10` | | `Prefix`: `myPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/` `ErrorOutputPrefix`: `myErrorPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/!{firehose:error-output-type}` | `Prefix`: `myPrefix/year=2018/month=07/day=06/hour=23/` `ErrorOutputPrefix`: `myErrorPrefix/year=2018/month=07/day=06/hour=23/processing-failed` | | `Prefix`: `myFirehosePrefix/` `ErrorOutputPrefix`: 지정 안 함 | `Prefix`: `myFirehosePrefix/2018/08/27/` `ErrorOutputPrefix`: `myFirehosePrefix/processing-failed/2018/08/27/` | # OpenSearch Service 인덱스 교체 구성 OpenSearch Service 대상의 경우 **NoRotation**, **OneHour**, **OneDay**, **OneWeek**, **OneMonth** 등 다섯 가지 옵션 중 하나로 시간 기반 인덱스 로테이션 옵션을 지정할 수 있습니다. 선택한 교체 옵션에 따라 Amazon Data Firehose가 UTC 도착 타임스탬프의 일부를 지정된 인덱스 이름에 추가합니다. 그리고 추가된 타임스탬프를 회전시킵니다. 다음 예는 각 인덱스 로테이션 옵션에 대한 OpenSearch Service의 결과 인덱스 이름을 보여주며, 여기서 지정된 인덱스 이름은 **myindex**이고 도착 타임스탬프는 `2016-02-25T13:00:00Z`입니다. | RotationPeriod | IndexName | | --- | --- | | NoRotation | myindex | | OneHour | myindex-2016-02-25-13 | | OneDay | myindex-2016-02-25 | | OneWeek | myindex-2016-w08 | | OneMonth | myindex-2016-02 | **참고** `OneWeek` 옵션에서, Data Firehose는 <연도>-w<주 번호>(예:`2020-w33`) 형식을 사용하여 인덱스를 자동 생성하며, 여기서 주 번호는 UTC 시간 및 다음 미국 규칙에 따라 계산됩니다. 한 주는 일요일에 시작함 한 해의 첫 주는 그 해에 토요일이 포함된 첫 번째 주가 됨 # 데이터 전송 일시 중지 및 재개 Firehose 스트림을 설정한 후 스트림 소스에서 사용 가능한 데이터는 지속적으로 대상에 전송됩니다. 스트림 대상을 일시적으로 사용할 수 없는 상황이 발생하는 경우(예: 계획된 유지 관리 작업 진행), 데이터 전송을 일시적으로 중지하고 대상이 다시 사용 가능해지면 재개하는 것이 좋습니다. **중요** 아래 설명된 접근 방식을 사용하여 스트림을 일시 중지 및 재개하면 스트림을 재개한 후 Amazon S3의 오류 버킷으로 전송되는 레코드가 거의 없는 반면 나머지 스트림은 계속 대상으로 전송되는 것을 확인할 수 있습니다. 이는 해당 접근 방식의 알려진 제한 사항으로, 여러 번의 재시도 후에도 대상으로 전송되지 못한 소수의 레코드가 실패한 것으로 처리되기 때문입니다. ## Firehose 스트림 일시 중지 Firehose의 스트림 전송을 일시 중지하려면 먼저 전송 실패에 대해 Firehose가 S3 백업 위치에 쓸 수 있는 권한을 제거합니다. 예를 들어 OpenSearch 대상과의 Firehose 스트림을 일시 중지할 경우 권한을 업데이트하여 이 작업을 수행할 수 있습니다. 자세한 정보는 [Grant Firehose Access to a Public OpenSearch Service Destination](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-es)(Firehose에 퍼블릭 OpenSearch Service 대상에 대한 액세스 권한 부여)을 참조하세요. 작업 `s3:PutObject`에 대한 `"Effect": "Allow"` 권한을 제거하고, 실패한 전송의 백업에 사용되는 S3 버킷에 대해 작업 `s3:PutObject`에 대한 `Effect": "Deny"` 권한을 적용하는 명령문을 명시적으로 추가합니다. 그런 다음 스트림 대상을 끄거나(예: 대상 OpenSearch 도메인 끄기) Firehose가 대상에 쓸 수 있는 권한을 제거합니다. 다른 대상에 대한 권한을 업데이트하려면 [Controlling Access with Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html)(Amazon Data Firehose를 사용한 액세스 제어)에서 해당 대상에 대한 섹션을 확인하세요. 이 두 작업이 완료되면 Firehose의 스트림 전송이 중단되며 [Firehose용 CloudWatch 지표](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html)를 통해 이를 모니터링할 수 있습니다. **중요** Firehose의 스트림 전송을 일시 중지할 때는, 스트림 전송이 재개되고 데이터가 대상으로 전달될 때까지 스트림 소스(예: Kinesis Data Streams 또는 Managed Service for Kafka)가 데이터를 보존하도록 구성되어야 합니다. 소스가 DirectPUT인 경우 Firehose는 24시간 동안 데이터를 보존합니다. 데이터 보존 기간이 만료되기 전에 스트림을 재개하여 데이터를 전송하지 않으면 데이터가 손실될 수 있습니다. ## Firehose 스트림 재개 전송을 재개하려면, 먼저 대상을 켜고 Firehose에 스트림을 대상으로 전송할 권한이 있는지 확인하여 스트림 대상에 대한 이전의 변경 사항을 되돌립니다. 그런 다음, 실패한 전송을 백업하기 위해 S3 버킷에 적용되는 권한에 대한 이전의 변경 사항을 되돌립니다. 즉, 작업 `s3:PutObject`에 대한 `"Effect": "Allow"` 권한을 제거하고, 실패한 전송의 백업에 사용되는 S3 버킷에 대해 작업 `s3:PutObject`에 대한 `"Effect": "Deny"` 권한을 제거합니다. 마지막으로 [Firehose용 CloudWatch 지표](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html)를 통해 모니터링하여 스트림이 대상으로 전송되고 있는지 확인합니다. 오류를 확인하고 문제를 해결하려면 [Firehose에 대한 Amazon CloudWatch Logs 모니터링](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html)을 사용하세요.