ECS로 운영하는 서비스의 로그를 AWS에서 수집하지 못하고 있다.
DataDog과 같은 로그 수집 어플리케이션 도입을 고민하고 있었지만, 우선은 AWS에 로그를 올려보는 것을 목표로 한다.
CloudWatch에 로그를 수집하기 위해서는 먼저 로그 그룹이 존재해야 한다.
AWS CloudWatch에 접속하여 로그 그룹를 생성해준다.
로그 그룹 이름과 보존 기간을 설정해준다. CloudWatch의 프리티어 로그 용량은 5GB이고, 초과분에 대해서 요금이 지불된다. 로그가 생성되면 총 로그 크기를 확인할 수 있으니 초기에는 여유롭게 설정해줘도 된다.
새로운 로그 그룹에 로그를 작성하기 위해서는 컨테이너 설정을 해주어야 한다.
컨테이너는 테스크를 새로 만들어 설정해줄 수 있기 때문에 AWS ECS에서 새로운 테스크정의를 생성해준다.
자신의 환경에 맞추어 선택한다. 필자는 EC2를 사용하기 때문에 EC2를 선택해주었다.
새로 생성할 테스크의 이름과 네트워크 모드를 설정해준다.
컨테이너를 생성해준다. 컨테이너 이름과 이미지를 보관하고 있는 repository와 tag를 입력해준다.
이후 설정들 모두 자기 환경에 맞추어 작성해주면 된다.
컨테이너 생성 페이지에서 스토리지 및 로깅 탭을 찾을 수 있다.
로그 구성에서 Key값을 위와같이 설정해준다.
awslogs-group : 위에서 설정해준 로그 그룹 이름을
awslogs-region : 로그 그룹이 존재하는 리전
awslogs-stream-prefix : 자유롭게 설정
또한 위와 같이 Auto-configure CloudWatch Logs를 체크해주면 AWS에서 기본값으로 설정을 해주는데, 본문 1번에서 로그 그룹 생성을 자동으로 해주는 옵션이다. 그러나 로그 그룹 이름이 마음에 들지 않고 직관성이 떨어질 수 있기 때문에 두가지 방법을 모두 소개했다.
위에서 만든 Task를 사용하는 서비스를 새로 생성해주어야 한다.
Task를 만들 때 처럼 자신의 서비스에 맞는 옵션들을 선택해주면 된다.
3번까지 모두 거친 후에 서비스가 운영되기 시작하면 원하는 대로 로그가 찍히는 모습니다.
로그가 찍히기 시작한 새로운 서비스를 제외한 기존 운영되고 있는 서비스는 내려주었다.
운영되는 서비스의 API 가 문제 없이 동작하는지 API서버, 웹페이지 모두 확인해주었다.
EC2에 접속해서 도커가 의도대로 동작하고 있는지 따로 확인해준다.
해결 2번에서 Task를 생성하면, 해당 테스크의 json 데이터를 확인할 수 있다.
해당 json 전문을 기존 프로젝트의 task.json으로 옮겨준다.
또한 깃허브 액션에서 사용되는 workflow도 위의 설정에 맞추어 수정한다.
깃허브에서도 워크플로우가 잘 돌아가는 것을 확인하면 모든 작업이 마무리된다.
원하는 결과대로 설정이 완료됐고 로그도 잘 찍히는 모습을 확인했다.
로그는 찍는 것도 중요하지만 로그를 실시간으로 확인하고 운영하는 사람이 확인할 수 있도록 노티를 줄 수 있어야 한다.
CloudWatch에서 로그를 분석하고 특정 상황에서 알림을 보낼 수 있도록 설정하는 것도 추후에 필요할 것 같다.