Terraform을 사용하여 엔터프라이즈 규모로 중앙 집중식 로깅 설정 - 권장 가이드
요약사전 조건 및 제한 사항아키텍처도구모범 사례에픽문제 해결관련 리소스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Terraform을 사용하여 엔터프라이즈 규모로 중앙 집중식 로깅 설정

작성자: Aarti Rajput(AWS), Yashwant Patel(AWS), Nishtha Yadav(AWS)

요약

중앙 집중식 로깅은 조직의 운영, 보안 및 규정 준수에 대한 가시성을 제공하므로 조직의 클라우드 인프라에 매우 중요합니다. 조직이 여러 계정에서 AWS 환경을 확장함에 따라 구조화된 로그 관리 전략은 보안 운영을 실행하고 감사 요구 사항을 충족하며 운영 우수성을 달성하기 위한 기본이 됩니다.

이 패턴은 여러 AWS 계정 및 서비스의 로그를 중앙 집중화하여 복잡한 AWS 배포에서 엔터프라이즈 규모의 로깅 관리를 가능하게 하는 확장 가능하고 안전한 프레임워크를 제공합니다. 솔루션은 일관되고 반복 가능한 배포를 보장하고 수동 구성을 최소화하는 HashiCorp의 코드형 인프라(IaC) 도구인 Terraform을 사용하여 자동화됩니다. Amazon CloudWatch Logs, Amazon Data Firehose 및 Amazon Simple Storage Service(Amazon S3)를 결합하여 다음을 제공하는 강력한 로그 집계 및 분석 파이프라인을 구현할 수 있습니다.

  • 에서 조직 전체의 중앙 집중식 로그 관리 AWS Organizations

  • 보안 제어 기능이 내장된 자동 로그 수집

  • 확장 가능한 로그 처리 및 내구성 있는 스토리지

  • 간소화된 규정 준수 보고 및 감사 추적

  • 실시간 운영 인사이트 및 모니터링

이 솔루션은 CloudWatch Logs를 통해 Amazon Elastic Kubernetes Service(Amazon EKS) 컨테이너, AWS Lambda 함수 및 Amazon Relational Database Service(Amazon RDS) 데이터베이스 인스턴스에서 로그를 수집합니다. CloudWatch 구독 필터를 사용하여 이러한 로그를 전용 로깅 계정에 자동으로 전달합니다. Firehose는 장기 스토리지를 위해 Amazon S3에 대한 높은 처리량의 로그 스트리밍 파이프라인을 관리합니다. Amazon Simple Queue Service(Amazon SQS)는 객체 생성 시 Amazon S3 이벤트 알림을 수신하도록 구성됩니다. 이를 통해 다음을 포함한 분석 서비스와 통합할 수 있습니다.

  • 로그 검색, 시각화 및 실시간 분석을 위한 Amazon OpenSearch Service

  • SQL 기반 쿼리를 위한 Amazon Athena

  • 대규모 처리를 위한 Amazon EMR

  • 사용자 지정 변환을 위한 Lambda

  • 대시보드용 Amazon QuickSight

모든 데이터는 AWS Key Management Service (AWS KMS)를 사용하여 암호화되며, 환경 간에 일관된 구성을 위해 Terraform을 사용하여 전체 인프라가 배포됩니다.

이러한 중앙 집중식 로깅 접근 방식을 통해 조직은 보안 태세를 개선하고, 규정 준수 요구 사항을 유지하고, AWS 인프라 전반의 운영 효율성을 최적화할 수 있습니다.

사전 조건 및 제한 사항

사전 조건 

설정 AWS Control Tower, AFT 및 애플리케이션 계정 설정에 대한 지침은 에픽 섹션을 참조하세요.

필수 계정

의 조직은 다음 계정을 포함해야 AWS Organizations 합니다.

  • 애플리케이션 계정 - AWS 서비스 (Amazon EKS, Lambda 및 Amazon RDS)가 실행되고 로그를 생성하는 하나 이상의 소스 계정

  • 로그 아카이브 계정 - 중앙 집중식 로그 스토리지 및 관리를 위한 전용 계정

제품 버전

아키텍처

다음 다이어그램은 여러 애플리케이션 계정의 로그를 수집, 처리 및 전용 로그 아카이브 계정으로 저장하기 위한 확장 가능한 솔루션을 제공하는 AWS 중앙 집중식 로깅 아키텍처를 보여줍니다. 이 아키텍처는 Amazon RDS AWS 서비스, Amazon EKS 및 Lambda를 포함한의 로그를 효율적으로 처리하고 간소화된 프로세스를 통해 로그 아카이브 계정의 리전 S3 버킷으로 라우팅합니다.

여러 애플리케이션 계정에서 로그를 수집하기 위한 AWS 중앙 집중식 로깅 아키텍처입니다.

워크플로에는 다음 5가지 프로세스가 포함됩니다.

  1. 로그 흐름 프로세스

    • 로그 흐름 프로세스는 애플리케이션 계정에서 시작되며, 여기서는 일반, 오류, 감사, Amazon RDS의 느린 쿼리 로그, Amazon EKS의 컨트롤 플레인 로그, Lambda의 함수 실행 및 오류 로그와 같은 다양한 유형의 로그를 AWS 서비스 생성합니다.

    • CloudWatch는 초기 수집 지점 역할을 합니다. 각 애플리케이션 계정 내의 로그 그룹 수준에서 이러한 로그를 수집합니다.

    • CloudWatch에서 구독 필터는 중앙 계정으로 전달해야 하는 로그를 결정합니다. 이러한 필터를 사용하면 로그 전달을 세부적으로 제어할 수 있으므로 정확한 로그 패턴을 지정하거나 중앙 집중화를 위한 전체 로그 스트림을 지정할 수 있습니다.

  2. 교차 계정 로그 전송

    • 로그는 로그 아카이브 계정으로 이동합니다. CloudWatch 구독 필터는 교차 계정 전송을 용이하게 하고 리전 컨텍스트를 보존합니다.

    • 아키텍처는 다양한 로그 소스를 효율적으로 처리하여 최적의 성능과 확장성을 보장하기 위해 여러 병렬 스트림을 설정합니다.

  3. 로그 아카이브 계정의 로그 처리

    • 로그 아카이브 계정에서 Firehose는 수신 로그 스트림을 처리합니다.

    • 각 리전은 필요에 따라 로그를 변환, 변환 또는 보강할 수 있는 전용 Firehose 전송 스트림을 유지합니다.

    • 이러한 Firehose 스트림은 처리된 로그를 소스 애플리케이션 계정과 동일한 리전(다이어그램의 리전 A)에 있는 로그 아카이브 계정의 S3 버킷으로 전송하여 데이터 주권 요구 사항을 유지합니다.

  4. 알림 및 추가 워크플로

    • 로그가 대상 S3 버킷에 도달하면 아키텍처는 Amazon SQS를 사용하여 알림 시스템을 구현합니다.

    • 리전 SQS 대기열은 비동기 처리를 활성화하고 저장된 로그를 기반으로 추가 워크플로, 분석 또는 알림 시스템을 트리거할 수 있습니다.

  5. AWS KMS 보안을 위한

    아키텍처는 보안 AWS KMS 용를 통합합니다.는 S3 버킷에 대한 암호화 키를 AWS KMS 제공합니다. 이렇게 하면 저장된 모든 로그가 데이터 레지던시 요구 사항을 충족하도록 암호화 리전을 유지하면서 저장 시 암호화를 유지할 수 있습니다.

도구

AWS 서비스

  • Amazon CloudWatch는 로그, 지표 및 이벤트의 형태로 모니터링 및 운영 데이터를 수집하는 모니터링 및 관찰성 서비스입니다. AWS 및 온프레미스 서버에서 실행되는 AWS 리소스, 애플리케이션 및 서비스에 대한 통합 보기를 제공합니다.

  • CloudWatch Logs 구독 필터는 수신 로그 이벤트의 패턴과 일치하고 추가 처리 또는 분석을 위해 일치하는 로그 이벤트를 지정된 AWS 리소스에 전달하는 표현식입니다.

  • AWS Control Tower Account Factory For Terraform(AFT)은 계정을 프로비저닝하고 사용자 지정하는 데 도움이 되는 Terraform 파이프라인을 설정합니다 AWS Control Tower. AFT는 Terraform 기반 계정 프로비저닝을 제공하는 동시에 계정을 관리할 수 있습니다 AWS Control Tower.

  • Amazon Data Firehose는 Amazon S3, Amazon Redshift 및 Amazon OpenSearch Service와 같은 대상에 실시간 스트리밍 데이터를 제공합니다. 데이터 처리량에 맞게 자동으로 확장되므로 지속적인 관리가 필요하지 않습니다.

  • Amazon Elastic Kubernetes Service(Amazon EKS)는 Kubernetes를 사용하여 컨테이너화된 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있는 관리형 컨테이너 오케스트레이션 서비스입니다. Kubernetes 컨트롤 플레인 노드의 가용성과 확장성을 자동으로 관리합니다.

  • AWS Key Management Service (AWS KMS)는 데이터를 암호화하기 위한 암호화 키를 생성하고 제어합니다.는 이러한 서비스로 저장하는 데이터를 보호하는 AWS 서비스 데 도움이 되도록 다른와 AWS KMS 통합합니다.

  • AWS Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다. 각 트리거에 대한 응답으로 코드를 실행하여 애플리케이션을 자동으로 확장하고 사용한 컴퓨팅 시간에 대해서만 요금을 청구합니다.

  • Amazon Relational Database Service(RDS)는 클라우드에서 관계형 데이터베이스를 쉽게 설정, 운영 및 확장할 수 있는 관리형 관계형 데이터베이스 서비스입니다. 시간 소모적인 관리 작업을 자동화하는 동시에 비용 효율적이고 크기 조정 가능한 용량을 제공합니다.

  • Amazon Simple Queue Service(Amazon SQS)는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 분리 및 확장할 수 있는 메시지 대기열 서비스입니다. 메시지 지향 미들웨어를 관리하고 운영하는 복잡성을 제거합니다.

  • Amazon Simple Storage Service(Amazon S3)는 확장성, 데이터 가용성, 보안 및 성능을 제공하는 클라우드 기반 객체 스토리지 서비스입니다. 웹의 모든 위치에서 원하는 양의 데이터를 저장하고 검색할 수 있습니다.

기타 도구

  • Terraform은 HashiCorp의 코드형 인프라(IaC) 도구로, 클라우드 및 온프레미스 리소스를 생성하고 관리하는 데 도움이 됩니다.

코드

이 패턴의 코드는 GitHub 중앙 집중식 로깅 리포지토리에서 사용할 수 있습니다.

모범 사례

에픽

작업설명필요한 기술

AFT를 사용하여 AWS Control Tower 환경을 설정합니다.

  1. AWS Control Tower 설명서의 지침에 AWS Control Tower 따라 배포합니다.

  2. AWS Control Tower 설명서의 지침에 따라 AFT를 배포합니다.

관리자

조직에 대한 리소스 공유를 활성화합니다.

  1. 관리 계정 자격 증명을 사용하여 (AWS Command Line InterfaceAWS CLI)를 구성합니다.이 자격 증명은 관리할 관리 권한을 제공합니다 AWS Control Tower.

  2. 에서 다음 AWS CLI 명령을 실행합니다 AWS 리전.

    aws ram enable-sharing-with-aws-organization

    이렇게 하면 AWS Resource Access Manager ()를 지원하는 AWS Organizations 모든 리전에서의 조직 내에서 리소스를 공유할 수 있습니다AWS RAM.

관리자

애플리케이션 계정을 확인하거나 프로비저닝합니다.

사용 사례에 맞게 새 애플리케이션 계정을 프로비저닝하려면 AFT를 통해 계정을 생성합니다. 자세한 내용은 AWS Control Tower 설명서의 AFT를 사용하여 새 계정 프로비저닝을 참조하세요.

관리자
작업설명필요한 기술

Application_account 폴더 콘텐츠를 aft-account-customizations리포지토리에 복사합니다.

  1. aft-account-customizations 리포지토리의 루트 경로Application_account에 라는 폴더를 생성합니다. 이 리포지토리는 AFT를 설정할 때 자동으로 생성됩니다(이전 에픽 참조).

  2. centralised-logging-at-enterprise-scale-using-terraform 리포지토리의 루트 디렉터리로 이동하여 aft/account 디렉터리의 내용을 복사한 다음 리포aft-account-customizations지토리의 1단계에서 생성한 Application_account 디렉터리에 붙여 넣습니다.

  3. centralised-logging-at-enterprise-scale-using-terraform 리포지토리의 루트 디렉터리에서 Application_account 디렉터리의 내용을 aft-account-customizations리포지토리의 Application_account/terraform 디렉터리에 복사합니다.

  4. aft-account-customizations/Application_account/terraform.tfvars 파일에서 모든 파라미터가 해당 Terraform 구성 파일에서 인수로 전달되는지 확인합니다.

DevOps 엔지니어

애플리케이션 계정 설정을 위한 입력 파라미터를 검토하고 편집합니다.

이 단계에서는 CloudWatch 로그 그룹, CloudWatch CloudWatch 구독 필터, IAM 역할 및 정책, Amazon RDS, Amazon EKS 및 Lambda 함수에 대한 구성 세부 정보를 포함하여 애플리케이션 계정에서 리소스를 생성하기 위한 구성 파일을 설정합니다.

aft-account-customizations 리포지토리의 Application_account 폴더에서 조직의 요구 사항에 따라 terraform.tfvars 파일의 입력 파라미터를 구성합니다.

  • environment: 리소스가 배포될 환경의 이름(예: , proddev, staging)입니다.

  • account_name: 리소스가 생성될의 이름 AWS 계정 입니다.

  • log_archive_account_id: 로그를 보관할 AWS 계정 ID입니다.

  • admin_role_name: 리소스 관리에 사용할 관리 역할의 이름입니다.

  • tags: 모든 리소스에 적용할 공통 태그를 나타내는 키-값 페어의 맵입니다.

  • rds_config: Amazon RDS 인스턴스에 대한 구성 세부 정보가 포함된 객체입니다.

  • allowed_cidr_blocks: 리소스에 액세스할 수 있는 CIDR 블록 목록입니다.

  • destination_name: 로그가 스트리밍될 CloudWatch 대상의 Amazon 리소스 이름(ARN)을 생성하는 데 사용되는 변수입니다.

  • rds_parameters: Amazon RDS 파라미터 그룹 설정이 포함된 객체입니다.

  • vpc_config: VPC 구성 세부 정보가 포함된 객체입니다.

  • eks_config: Amazon EKS 클러스터에 대한 구성 세부 정보가 포함된 객체입니다.

  • lambda_config: Lambda 함수에 대한 구성 세부 정보가 포함된 객체입니다.

  • restrictive_cidr_range: 보안 그룹 규칙에 대한 제한적인 CIDR 범위의 목록입니다.

  • target_account_id: 리소스가 배포될 대상 로그 아카이브 계정의 AWS 계정 ID입니다.

DevOps 엔지니어
작업설명필요한 기술

Log_archive_account 폴더 콘텐츠를 aft-account-customizations리포지토리에 복사합니다.

  1. aft-account-customizations 리포지토리의 루트 경로Log_archive_account에 라는 폴더를 생성합니다.이 리포지토리는 AFT를 설정할 때 자동으로 생성됩니다.

  2. centralised-logging-at-enterprise-scale-using-terraform 리포지토리의 루트 디렉터리로 이동하여 aft/account 디렉터리의 내용을 복사한 다음 aft-account-customizations리포지토리의 이전 단계에서 생성한 Log_archive_account 디렉터리에 붙여 넣습니다.

  3. centralised-logging-at-enterprise-scale-using-terraform 리포지토리의 루트 디렉터리에서 Log_archive_account 디렉터리의 내용을 aft-account-customizations리포지토리의 Log_archive_account/terraform 디렉터리에 복사합니다.

  4. aft-account-customizations/Log_archive_account/terraform.tfvars 파일에서 모든 파라미터가 해당 Terraform 구성 파일에서 인수로 전달되는지 확인합니다.

DevOps 엔지니어

로그 아카이브 계정을 설정하기 위한 입력 파라미터를 검토하고 편집합니다.

이 단계에서는 Firehose 전송 스트림, S3 버킷, SQS 대기열, IAM 역할 및 정책을 포함하여 로그 아카이브 계정에서 리소스를 생성하기 위한 구성 파일을 설정합니다.

aft-account-customizations 리포지토리의 Log_archive_account 폴더에서 조직의 요구 사항에 따라 terraform.tfvars 파일의 입력 파라미터를 구성합니다.

  • environment: 리소스가 배포될 환경의 이름(예: , proddev, staging)입니다.

  • destination_name: 로그가 스트리밍될 CloudWatch 대상의 ARN을 생성하는 데 사용되는 변수입니다.

  • source_account_ids: 로그 대상에 구독 필터를 넣을 수 있는 AWS 계정 IDs. 중앙 집중식 로깅에 대해 활성화하려는 수만큼 계정 IDs를 입력할 수 있습니다.

DevOps 엔지니어
작업설명필요한 기술

옵션 1 - AFT에서 Terraform 구성 파일을 배포합니다.

AFT에서는 구성이 변경된 코드를 GitHub aft-account-customizations리포지토리로 푸시하면 AFT 파이프라인이 트리거됩니다. AFT는 변경 사항을 자동으로 감지하고 계정 사용자 지정 프로세스를 시작합니다.

Terraform(terraform.tfvars) 파일을 변경한 후 변경 사항을 커밋하고 aft-account-customizations리포지토리에 푸시합니다.

$ git add *
$ git commit -m "update message"
$ git push origin main
참고

다른 브랜치(예: dev)를 사용하는 경우를 브랜치 이름으로 main 바꿉니다.

DevOps 엔지니어

옵션 2 - Terraform 구성 파일을 수동으로 배포합니다.

AFT를 사용하지 않거나 솔루션을 수동으로 배포하려는 경우 Application_account 및 Log_archive_account 폴더에서 다음 Terraform 명령을 사용할 수 있습니다.

  1. GitHub 리포지토리를 복제하고 terraform.tfvars 파일에서 입력 파라미터를 구성합니다.

  2. 다음 명령 실행:

    $ terraform init

  3. 변경 사항 미리 보기:

    $ terraform plan

    이 명령은 Terraform 구성을 평가하여 리소스의 원하는 상태를 결정하고 이를 인프라의 현재 상태와 비교합니다.

  4. 변경 사항 적용:

    $ terraform apply

  5. 계획된 변경 사항을 검토하고 프롬프트에 yes를 입력하여 애플리케이션을 진행합니다.

DevOps 엔지니어
작업설명필요한 기술

구독 필터를 확인합니다.

구독 필터가 애플리케이션 계정 로그 그룹에서 로그 아카이브 계정으로 로그를 올바르게 전달하는지 확인하려면:

  1. 애플리케이션 계정에서 CloudWatch 콘솔을 엽니다.

  2. 탐색 창에서 로그 그룹(Log groups)을 선택합니다.

  3. 각 로그 그룹(/aws/rds, /aws/eks, /aws/lambda)을 선택하고 구독 필터 탭을 선택합니다.

    Terraform 구성 파일에서 지정한 이름을 기반으로 대상 ARN을 가리키는 활성 구독 필터가 표시됩니다.

  4. 구독 필터를 선택하여 구성 및 상태를 확인합니다.

DevOps 엔지니어

Firehose 스트림을 확인합니다.

로그 아카이브 계정의 Firehose 스트림이 애플리케이션 로그를 성공적으로 처리하는지 확인하려면:

  1. 로그 아카이브 계정에서 Firehose 콘솔을 엽니다.

  2. 왼쪽 탐색 창에서 Firehose 스트림을 선택합니다.

  3. Firehose 스트림을 선택하고 다음을 확인합니다.

    • 대상에 올바른 S3 버킷이 표시됩니다.

    • 모니터링 탭에는 성공적인 전송 지표가 표시됩니다.

    • 최근 전송 타임스탬프는 최신입니다.

DevOps 엔지니어

중앙 집중식 S3 버킷을 검증합니다.

중앙 집중식 S3 버킷이 로그를 올바르게 수신하고 구성하는지 확인하려면:

  1. 로그 아카이브 계정에서 Amazon S3 콘솔을 엽니다.

  2. 각 중앙 로깅 버킷을 선택합니다.

  3. AWSLogs/AccountID/Region/Service 폴더 구조를 탐색합니다.

    타임스탬프(YYYY/MM/DD/HH)별로 구성된 로그 파일이 표시됩니다.

  4. 최신 로그 파일을 선택하고 형식과 데이터 무결성을 확인합니다.

DevOps 엔지니어

SQS 대기열을 검증합니다.

SQS 대기열이 새 로그 파일에 대한 알림을 수신하는지 확인하려면:

  1. 로그 아카이브 계정에서 Amazon SQS 콘솔을 엽니다.

  2. 왼쪽 탐색 창에서 대기열을 선택합니다.

  3. 구성된 각 대기열을 선택하고 메시지 전송 및 수신을 선택합니다.

    새 로그 파일에 대한 S3 이벤트 알림이 포함된 메시지가 표시됩니다.

  4. 메시지를 선택하여 올바른 S3 객체 정보가 포함되어 있는지 확인합니다.

DevOps 엔지니어
작업설명필요한 기술

옵션 1 - AFT에서 Terraform 구성 파일을 폐기합니다.

Terraform 구성 파일을 제거하고 변경 사항을 푸시하면 AFT가 리소스 제거 프로세스를 자동으로 시작합니다.

  1. aft-account-customizations 리포지토리로 이동합니다.

  2. terraform 디렉터리로 이동합니다.

  3. 다음 파일을 삭제합니다.

    • modules 디렉터리

    • iam.tf

    • versions.tf

    • variables.tf

    • outputs.tf

    • terraform.tfvars

  4. main.tf 파일의 내용을 지웁니다.

  5. 변경 사항을 리포지토리에 푸시합니다.

    # Stage all changes
$ git add *

# Commit cleanup changes
$ git commit -m "Remove AFT customizations"

# Push to repository
$ git push origin main
    참고

    다른 브랜치(예: dev)를 사용하는 경우를 브랜치 이름으로 main 바꿉니다.

DevOps 엔지니어

옵션 2 - Terraform 리소스를 수동으로 정리합니다.

AFT를 사용하지 않거나 리소스를 수동으로 정리하려는 경우 Application_account 및 Log_archive_account 폴더에서 다음 Terraform 명령을 사용합니다.

  1. Terraform 구성을 초기화합니다.

    $ terraform init

    이 명령은 Terraform을 초기화하고 현재 상태에 대한 액세스를 보장합니다.

  2. 정리 변경 사항 미리 보기:

    $ terraform destroy

    이 명령은 폐기할 리소스를 평가하고 원하는 상태를 인프라의 현재 상태와 비교합니다.

  3. 정리를 실행합니다. 메시지가 표시되면 yes를 입력하여 폐기 계획을 확인하고 실행합니다.

DevOps 엔지니어

문제 해결

문제Solution

CloudWatch Logs 대상이 생성되지 않았거나 비활성 상태입니다.

다음 사항을 검증합니다.

  1. 로그 아카이브 계정에서 대상 정책에 다음이 포함되어 있는지 확인합니다.

    • 올바른 소스 계정 보안 주체입니다.

    • 올바른 작업(logs:PutSubscriptionFilter).

    • 유효한 대상 ARN입니다.

  2. Firehose 스트림이 존재하고 활성 상태인지 확인합니다.

  3. 대상에 연결된 IAM 역할에 Firehose에 대한 권한이 있는지 확인합니다.

구독 필터가 실패했거나 보류 중 상태로 멈췄습니다.

다음을 확인하세요.

  1. 애플리케이션 계정에서 IAM 역할에 다음이 있는지 확인합니다.

    • 를 호출할 수 있는 권한PutSubscriptionFilter.

    • CloudWatch Logs와의 신뢰 관계입니다.

  2. 대상 ARN이 올바른지 확인합니다.

  3. CloudWatch Logs에서 특정 오류 메시지를 확인합니다.

Firehose 전송 스트림에는 수신 레코드가 표시되지 않습니다.

다음을 확인합니다.

  1. Firehose IAM 역할에 다음이 있는지 확인합니다.

    • Amazon S3에 쓸 수 있는 권한.

    • 암호화가 활성화된 경우 AWS KMS 키에 대한 액세스입니다.

  2. 다음에 대한 CloudWatch 지표 검토:

    • IncomingRecords

    • DeliveryToS3.Records

  3. 버퍼 설정 및 전송 구성을 확인합니다.

관련 리소스