이제 CloudWatch 로그를 살펴볼텐데
CloudWatch 로그는 AWS에서
애플리케이션 로그를 저장하기에 완벽한 곳입니다
그러려면 먼저 로그 그룹을 정의해야 합니다
원하는 이름 뭐든 괜찮지만
보통은 여러분의 앱 중 하나를 대표하는 이름입니다
로그 그룹 안에는 다중 로그 스트림이 생기게 되고
앱 내의 로그 인스턴스나 특정 로그 파일
또는 클러스터의 일부인 특정 컨테이너를
나타냅니다
다음으로는 로그 expiration policy(만료 정책)을 정의하는데
기록은 무기한으로 유지시켜 만료되지 않도록
할 수도 있고 하루에서 10년 사이에
만료되게 할 수도 있습니다
CloudWatch 로그를 다양한 곳으로
보낼 수도 있습니다
예를 들어 Amazon S3에 일괄 전송한다거나
Kinesis Data Streams(키네시스 데이터 스트림), Kinesis Data Firehose(키네시스 데이터 파이어호스),
AWS Lambda(AWS Lambda), Amazon OpenSearch(Amazon 오픈서치) 등으로 보낼 수 있습니다
모든 로그는 기본적으로 암호화되며
원하실 경우 여러분만의 키를 넣은
KMS 기반 암호화도 가능합니다
그렇다면 CloudWatch 로그에는 어떤 데이터가 들어갈까요?
CloudWatch 로그에 들어가게 되는 로그는 어떤 것들일까요?
로그는 SDK나 CloudWatch Logs Agent(클라우드워치 로그 에이전트),
또는 CloudWatch Unified Agent(클라우드워치 통합 에이전트)를
통해 전송이 가능합니다
이제 CloudWatch 통합 에이전트가 CloudWatch로 로그를 보내고
CloudWatch 로그 에이전트는 잘 사용되지 않는 편입니다
Elastic Beanstalk의 경우에는 앱에서 CloudWatch로
직접 로그 수집을 하고
ECS는 컨테이너에서 CloudWatch로
일지를 바로 보냅니다
Lambda는 함수로부터 로그를 전송하고
VPC 메타데이터 네트워크 트래픽 특유의 로그는
VPC Flow Logs가 보냅니다
API Gateway(API 게이트웨이)에 들어간 리퀘스트는
모두 CloudWatch 로그로 보내집니다
CloudTrail은 필터를 통해
로그를 직접 전송할 수 있고
Route53는 서비스에 들어온
모든 DNS 쿼리를 기록합니다
CloudWatch 로그 내 로그 쿼리를 하고자 한다면
CloudWatch Logs Insights를 이용하시면 되는데
이것은 CloudWatch 로그에 내장된 쿼리 기능으로
쿼리를 작성할 수 있도록 해줍니다
쿼리를 적용할 시간대를 지정하면
visualization(시각화) 결과를
자동으로 얻게 됩니다
또한 이 visualization을 구성한
특정 로그 라인도 볼 수 있습니다
해당 visualization은 결과로 내보내거나
대시보드에 추가하는 방식 등으로
언제든 원할 때 재실행이 가능합니다
이렇듯 매우 편리한 기능으로
CloudWatch 로그 안에 있는 로그 데이터의 검색 및 분석을 할 수 있습니다
CloudWatch 로그 인사이트의 콘솔 중 일부로
다양한 단순(simple) 쿼리가 있습니다
예시로는, 가장 최근의 25개 이벤트를 찾거나
로그에 exceptions(예외)
또는 오류가 있었던 이벤트가 몇 개인지 확인한다거나
특정 IP를 찾는 것 등이 있습니다
여기에는 purpose-built query language(목적 기반 쿼리 언어)가 제공되는데
쿼리를 만들기 위한 모든 필드는
CloudWatch 로그를 기반으로 자동으로 확인되고, 이것으로 조건부 필터링이 가능합니다
aggregate statistics(집계 통계)를 계산할 수도 있고
이벤트를 정렬하거나 이벤트 수를 제한할 수도 있습니다
말씀드렸듯 이러한 쿼리는 저장하거나
대시보드에 추가가 가능합니다
여러 로그 그룹이 다른 계정에 있더라도
해당 로그 그룹에 한번에 쿼리를 날릴 수도 있습니다
CloudWatch 로그 인사이트는 실시간 엔진이 아닌
쿼리 엔진이기 때문에
쿼리를 실행하면
historical data만을 쿼리합니다
언급했던 바와 같이
CloudWatch 로그는 여러 곳으로 내보낼 수 있는데
첫 번째는 Amazon S3입니다
Amazon S3로 모든 로그를
일괄 전송하며
최대 12시간까지 소요될 수 있습니다
이러한 전송작업을 위한 API 호출을
CreateExportTask라고 합니다
이것은 일괄 전송이므로
실시간 또는 그 비슷한 정도마저도 아니기에
CloudWatch 로그의 Subscriptions를 사용해야만 합니다
이를 통해 로그 이벤트의 실시간 스트림을 확보하고
프로세싱과 분석을 할 수 있죠
이 데이터는 키네시스 데이터 스트림 또는 키네시스 데이터 파이어호스,
Lambda와 같은 여러 목적지로 보낼 수
있습니다
Subscription 필터를 지정해 어떤 종류의 로그 이벤트를
목적지로 전달할지도 지정할 수 있습니다
Subscription 필터를 이용하면 데이터를
키네시스 데이터 스트림으로 보낼 수 있고
이 기능을 사용하는 것은
Kinesis Data Firehose나
Kinesis Data Analytics, 또는 Amazon EC2 및 Lambda 등과의
통합된 사용을 원할 경우 좋은 방안이 될 수 있습니다
키네시스 데이터 파이어호스로 직접 전송하는 것 또한 가능한데
이로부터 거의 실시간으로 Amazon S3에 보내거나
OpenSearch Service 또는
Lambda로 보낼 수 있습니다
여러분만의 사용자 지정 Lambda 기능을 작성하거나
실시간으로 OpenSearch Service에 데이터를 보내는
기존 Lambda 기능을 사용할 수도 있습니다
그 외에도 이 Subscription 필터 덕분에
여러 CloudWatch 로그로부터 데이터를 집계해
여럿의 계정 및 리전으로 보낸다거나
특정 계정 내의 키네시스 데이터 스트림과 같은 공통된 목적지로 보내는 것이 가능합니다
그리고 키네시스 데이터 파이어호스를 거쳐
거의 실시간으로 Amazon S3에 전달되는 것입니다
분명 실행가능한
로그 집계 방법이며
이것의 핵심은 destination(목적지)라는 것을
이용하는 데에 있습니다
발신자 계정과 수신자 계정이 있다고
가정해 보겠습니다
CloudWatch 로그 Subscription 필터를 생성하면
이것이 수신자 계정 내의
키네시스 데이터 스트림의 가상 respresentant인
Subscription Destination으로 보내집니다
그런 다음 Destination Access Policy(목적지 액세스 정책)을 첨부해
첫 번째 계정으로 하여금 데이터를
이 목적지로 보낼 수 있도록 합니다
이어서 수신자 계정에 IAM Role을 생성하는데
이것은 키네시스 데이터 스트림에
기록을 전송할 권한을 가졌기에
첫 번째 계정이 해당 롤을 맡을 수 있도록 해야 합니다
이 모든 것이 준비되면
그제서야 비로소
한 계정의 CloudWatch 로그에서
다른 계정의 목적지로의 데이터 전송이 가능해집니다
이번 강의는 여기까지입니다
마음에 드셨길 바라며, 다음 강의에서 뵙겠습니다