BLOG
고객이 구현하려고 하는 가장 일반적인 사용 사례 중 하나는 다양한 유형의 로그를 AWS 인프라에 중앙 집중화하여 이러한 로그를 보안, 모니터링 또는 분석 목적으로 활용할 수 있도록 하는 것입니다. AWS 서비스 로그를 중앙 집중화한다는 것은 다양한 AWS 서비스에서 생성된 모든 로그를 한 곳에 밀어 넣는 것을 의미합니다. 고객은 중앙 위치를 통해 조직의 모든 계정에서 생성된 로그를 쉽게 관리하고 데이터에 대한 제한과 보안을 적용할 수 있습니다. 로그를 중앙 집중화하면 이 데이터를 백업하는 프로세스를 설정하고 데이터 보존을 위한 수명 주기 정책을 설정할 수도 있습니다.
Amazon CloudWatch는 DevOps 엔지니어, 개발자, SRE(사이트 안정성 엔지니어) 및 IT 관리자를 위해 구축된 모니터링 및 관찰 가능 서비스입니다. CloudWatch는 애플리케이션을 모니터링하고, 시스템 전반의 성능 변화에 대응하며, 리소스 활용도를 최적화하고, 운영 상태를 통합적으로 파악할 수 있는 데이터 및 실행 가능한 통찰력을 제공합니다. Amazon EC2, Amazon DynamoDB, Amazon S3, Amazon ECS, Amazon EKS, AWS Lambda 등 70개 이상의 AWS 서비스와 통합되며, 세부 1분 메트릭과 사용자 지정 메트릭을 최대 1초까지 세분화하여 로그에 자동으로 게시하므로 추가 컨텍스트를 위해 로그에 심층 분석할 수 있습니다. Amazon CloudWatch Logs를 사용하면 확장성이 뛰어난 단일 서비스로 사용하는 모든 시스템, 애플리케이션 및 AWS 서비스의 로그를 중앙 집중화할 수 있습니다. 그런 다음 쉽게 보거나, 특정 오류 코드 또는 패턴을 검색하거나, 특정 필드를 기준으로 필터링하거나, 나중에 분석할 수 있도록 안전하게 보관할 수 있습니다. 이렇게 하면 CloudWatch 로그 그룹에서 이러한 로그를 선택하여 Amazon S3와 같은 중앙 집중식 위치에 푸시할 수 있는 공통 패턴을 설계하고 설정할 수 있습니다. S3의 모든 로그는 Amazon Athena를 사용하여 쿼리하거나 빅 데이터 처리를 위해 Amazon Redshift와 같은 데이터 웨어하우스에 푸시할 수 있습니다.
솔루션 개요
이 솔루션은 데이터를 실시간으로 처리할 수 있는 기능을 제공하는 Amazon Kinesis Data Firehose를 주로 활용합니다. 이 데이터를 기반으로 중요한 사용 사례를 구현할 수 있습니다. 중앙 집중식 로깅 계정은 Kinesis Firehose에 연결된 Log Destination 엔드 포인트를 표시합니다. Amazon Kinesis Firehose는 모든 데이터를 Amazon S3 버킷에 푸시하도록 구성되어 있습니다. Firehose는 또한 AWS Lambda 함수를 호출하여 S3 버킷에 푸시되기 전에 데이터를 압축 해제하고 포맷합니다. Kinesis Firehose 구성을 사용하면 AWS Glue를 사용하여 데이터를 변환한 후 대상으로 푸시할 수 있습니다. Firehose는 S3와 함께 Amazon Redshift, Amazon Elasticsearch Service 및 Splunk와 같은 다른 목적지도 지원합니다. 이 솔루션은 Glue를 사용한 데이터 변환 기능을 제공하지 않지만 필요할 경우 이 솔루션에 쉽게 통합할 수 있습니다.
솔루션에 사용된 AWS 서비스
- Amazon Kinesis Data Firehose– 데이터 레이크, 데이터 저장소 및 분석 툴에 스트리밍 데이터를 안정적으로 로드할 수 있는 가장 쉬운 방법입니다.
- AWS Lambda– 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있습니다. 비용은 사용한 만큼만 지불합니다.
- Amazon Simple Storage Service (Amazon S3)– 업계 최고의 확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스입니다.
- AWS Cloud Development Kit는 익숙한 프로그래밍 언어를 사용하여 클라우드 애플리케이션 리소스를 모델링하고 프로비저닝하는 오픈 소스 소프트웨어 개발 프레임워크입니다.
배포 시스템
전제조건:
- AWS CLI 액세스 권한이 있는 AWS 계정
- 로그 데이터의 소스로 사용할 수 있는 CloudWatch 로그 그룹. 사용할 수 없는 경우 Blueprint hello-world 람다를 생성하고 한 번 테스트하여 해당 CloudWatch 로그 그룹을 자동으로 생성하십시오.
솔루션을 AWS에 배포하는 명령
GitHub에서 솔루션 코드를 복제합니다.
$ git clone https://github.com/aws-samples/aws-centralize-logs-using-cdk.git
코드가 다운로드되면 다음 명령을 실행하여 컴퓨터에서 솔루션을 컴파일합니다.
$ cd central-logs-cdk
$ dotnet build src
솔루션을 단일 AWS 계정에 배포하는 경우 다음을 수행합니다.
1단계: 배포에 필요한 리소스로 환경을 준비하는 다음 명령을 실행합니다
$ cdk bootstrap
2단계: 아래 명령(명령 실행 전에 AWS-ACCOUNT-ID를 AWS 계정 번호로 교체)을 실행하여 로그를 수신, 처리 및 S3에 푸시하는 데 필요한 리소스를 배포합니다.
. $ cdk deploy LogDestinationStack –parameters LogDestinationStack:SourceAccountNumber=”*AWS-ACCOUNT-ID*”
참고: 명령의 출력을 확인하십시오. 성공하면 아래의 캡처 화면과 같이 명령줄에 LogDestinationARN을 가진 출력값이 나타납니다. 또한 AWS 콘솔에서도 아래 그림과 동일하게 확인할 수 있습니다. 2단계로 진행하기 전에 LogDestinationARN 출력값을 복사하십시오.
3단계: 위의 LogDestinationStack 배포
출력에서 LogDestinationArn 값을 복사하거나 AWS 콘솔에서 가져올 수 있습니다. 출력 탭에 있으며, LOG-DESTING-ARN을 이 탭으로 교체합니다. 또한 아래 명령을 실행하기 전에 CloudWatch-LOGroup을 CloudWatch Log 그룹의 이름으로 대체합니다.
$ cdk deploy LogSourceStack –parameters LogSourceStack:LogGroupName=”*CLOUDWATCH-LOGGROUP*” –parameters LogDestinationArn=”*LOG-DESTINATION-ARN*”
솔루션을 별도의 소스 및 대상 AWS 계정에 배포하는 경우 다음을 수행합니다.
1단계: 로그를 S3 버킷에 저장할 Logs Destination AWS 계정에 대해 다음 명령을 실행합니다(명령 실행 전에 소스-AWS-ACCOUNT-ID의 계정 번호로 교체합니다)
$ cdk deploy LogDestinationStack –parameters LogDestinationStack:SourceAccountNumber=”*SOURCE-AWS-ACCOUNT-ID*”
2단계: CloudWatch 로그가 있는 로그 소스 AWS 계정에 대해 다음 명령을 실행하십시오. 위의 LogDestinationStack 배포 출력에서 LogDestinationAnl 값을 복사하고 LOG-DESTING-ARN을 그것으로 교체하십시오. 또한 명령을 실행하기 전에 CloudWatch-LOGroup을 CloudWatch Log 그룹의 이름으로 바꿔주십시오.
$ cdk bootstrap
$ cdk deploy LogSourceStack –parameters LogSourceStack:LogGroupName=”*CLOUDWATCH-LOGGROUP*” –parameters LogDestinationArn=”*LOG-DESTINATION-ARN*”
솔루션 테스트 및 유효화
명령이 성공적으로 실행되면 필요한 모든 AWS 서비스가 계정에 배포됩니다. LogSourceStack을 배포할 때 사용한 CloudWatch Log 그룹이 수신한 모든 로그를 Kinesis Data Firehose에 푸시하도록 가입되어 S3 버킷(중앙 로그-ACCHATCH-ID)으로 푸시합니다. 아래 다이어그램은 로그가 저장될 S3 버킷을 보여줍니다.
정리
로그를 저장하기 위해 생성된 S3 버킷을 삭제합니다(LogDestination Stack이 배포된 AWS 계정에 대해 실행). 명령을 실행하기 전에 AWS-ACCOUNT-ID를 AWS 계정 번호로 바꿉니다.
$ aws s3 rb s3://central-logs-*AWS-ACCOUNT-ID* –force
다음 명령을 실행하여 LogSource Stack으로 배포된 리소스를 정리합니다.
$ cdk destroy LogSourceStack
다음 명령을 실행하여 LogDestination Stack으로 배포된 리소스를 정리합니다.
$ cdk destroy LogDestinationStack
결론
오늘은 로그 데이터의 중요성을 강조하며, CloudWatch Logs가 왜 비즈니스 크리티컬 사용 사례에 활용할 수 있는 훌륭한 소스인지를 설명해 드렸습니다. 본 블로그 글에서 제공된 솔루션을 통해 고객은 이를 기존 인프라에 신속하게 구성 및 구축할 수 있으며, AWS 로그를 중앙 집중화하는 프로세스를 시작할 수 있습니다.
더불어 AWS CDK를 사용하여 인프라를 코드로서 구축 및 배치할 때의 이점을 살펴보았는데, AWS CDK의 다양한 프로그래밍 언어 지원은 조직 내 개발자들이 가장 편한 프로그래밍 언어로 인프라를 코딩할 수 있게 합니다.
본 솔루션 구축과 관련하여 궁금한 사항이 있으시면 GitHub에 문의를 남겨주시기 바랍니다.
참고 자료
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.