| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
- gitlab
- DP
- 나무 조경
- softeer
- 자바
- Terraform
- 도커
- ECS
- IAC
- Cloud Engineer
- CI/CD
- spring boot
- Saa
- 나무섭지
- 자격증
- aws ecs
- 코딩테스트
- cloud
- 자동화
- resultMap
- Java
- dfs
- docker
- phi squared
- AWS
- gitlab runner
- 소프티어
- 파이프라인
- 백준
- 배포
- Today
- Total
성장하는 개발자의 블로그
[AWS CloudWatch] - CI/CD 파이프라인 구축하기 6 (AWS CloudWatch) 본문
안녕하세요. ECS 인프라를 구축하고, 수동으로 배포해본 뒤, 마지막에는 GitLab CI/CD를 이용해 배포를 자동화하는 파이프라인까지 완성했습니다.
오늘은 이 시리즈의 마지막 편으로, 우리가 배포한 애플리케이션이 잘 동작하는지 확인할 수 있는 CloudWatch를 이용한 로깅(Logging) 방법을 알아보고, 지금까지 구축한 전체 시스템의 아키텍처를 정리하며 대장정을 마무리하겠습니다.
1. CloudWatch Logs 연동: 컨테이너의 목소리 듣기
자동으로 배포된 애플리케이션에서 문제가 발생했을 때, 우리는 어떻게 원인을 파악할 수 있을까요? 컨테이너 환경에서는 문제가 생겼을 때 ssh로 서버에 직접 접속하여 로그를 확인하기가 어렵습니다. 컨테이너는 언제든지 사라지고 다시 생성될 수 있기 때문입니다. 따라서 로그를 외부의 중앙화된 장소로 보내는 것이 필수적입니다.
ECS는 AWS의 로깅 서비스인 CloudWatch Logs와 아주 쉽게 연동할 수 있습니다. 설정은 '태스크 정의'에서 이루어집니다.
3부에서 작성했던 .gitlab-ci.yml의 deploy 스크립트 중, 새로운 태스크 정의용 JSON을 만드는 부분을 수정하여 로깅 설정을 추가해야 합니다.
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/my-app-task",
"awslogs-region": "ap-northeast-2",
"awslogs-stream-prefix": "ecs"
}
}
- logConfiguration 블록을 태스크 정의의 containerDefinitions 항목 내에 추가합니다.
- logDriver: awslogs를 지정하여 CloudWatch Logs를 사용하겠다고 명시합니다.
- awslogs-group: 로그가 저장될 로그 그룹의 이름을 지정합니다. 존재하지 않으면 자동으로 생성됩니다.
- awslogs-region: 로그 그룹이 위치할 AWS 리전을 지정합니다.
- awslogs-stream-prefix: 로그 스트림(개별 컨테이너 로그) 이름의 접두사를 지정합니다.
이 수정사항을 적용하여 git push하면, 새로운 파이프라인이 실행되고 배포된 태스크부터는 모든 로그가 CloudWatch로 전송되기 시작합니다.
2. CloudWatch 콘솔에서 실시간 로그 확인하기
이제 실제로 로그를 확인해 보겠습니다.
이곳에 접속하면, 방금 전 우리가 지정한 이름(awslogs-group의 값)으로 로그 그룹이 생성된 것을 볼 수 있습니다. 해당 그룹을 클릭하여 들어가면, 현재 실행 중인 컨테이너별로 로그 스트림이 생성되어 있고, 각 스트림을 클릭하여 애플리케이션이 출력하는 로그를 실시간으로 확인할 수 있습니다.

3. 최종 아키텍처 구성도 정리 🗺️
이제 만든 전체 CI/CD 파이프라인의 흐름을 한 장의 그림으로 정리해보겠습니다.

이 구성도는 개발자의 git push 한 번으로 시작하여, GitLab Runner가 이미지를 빌드 및 ECR에 푸시하고, ECS 서비스를 업데이트하여 새로운 컨테이너를 배포한 뒤, 사용자는 로드 밸런서를 통해 서비스에 접근하고, 모든 로그는 CloudWatch에 기록되는 전 과정을 한눈에 보여줍니다.
4. 시리즈를 마치며
이것으로 총 6부에 걸친 ECS 배포 환경 구축 시리즈를 마무리합니다. 우리는 ECR 저장소 생성을 시작으로, ECS 클러스터와 EC2 인프라를 구축하고, 콘솔을 통해 수동 배포를 경험하며 ECS의 구조를 이해했습니다. 그리고 마침내 Dockerfile과 .gitlab-ci.yml을 통해 이 모든 과정을 자동화하는 파이프라인까지 완성했습니다.
이제 개발자가 코드를 작성하고 푸시하는 것만으로, 빌드, 배포, 그리고 로깅의 기반까지 이어지는 현대적인 DevOps 파이프라인의 핵심을 직접 구축해보았습니다. 이 경험이 여러분의 다음 프로젝트에 훌륭한 밑거름이 되기를 바랍니다.
긴 시리즈를 함께해주셔서 감사합니다.
'CI_CD' 카테고리의 다른 글
| [Docker, GitLab] - CI/CD 파이프라인 구축하기 5 (Dockerfile, gitlab-ci 파일 설정) (3) | 2025.07.24 |
|---|---|
| [AWS ECS] - CI/CD 파이프라인 구축하기 4 (AWS ECS 설정) (0) | 2025.07.16 |
| [AWS ECS] - CI/CD 파이프라인 구축하기 3 (AWS ECS 설정) (0) | 2025.07.08 |
| [AWS ECR] - CI/CD 파이프라인 구축하기 2 (AWS ECR 생성과 Docker 이미지의 구조 파헤치기) (0) | 2025.06.30 |
| [GitLab] - CI/CD 파이프라인 구축하기 1 (Gitlab Runner 설치) (0) | 2025.06.23 |