🎨 D’ART 배포 트러블 슈팅

 

👀 1. Problem Statement, 문제 상황

---

 

여러 레퍼런스를 조사하며 알게 된 AWS S3와 AWS CodeDeploy를 활용한 배포 방식을 사용하여 배포 환경을 구축하기 시작했다.

애플리케이션을 zip 파일로 만들어 S3에 업로드하여 CodeDeploy와 GitHub Actions를 사용해 자동화된 배포를 할 수 있었다.

Docker를 활용한 배포 방식을 도입하면서 기존 S3와 CodeDeploy를 통한 배포가 zip 파일을 업로드하는 방식으로, Redis나 MySQL과 같은 추가적인 서비스를 확장할 때 유연성과 확장성이 떨어졌기 때문이다.

Docker를 사용하면 이러한 문제를 해결할 수 있을 거라고 생각했다.

그래서 Docker 이미지를 생성하고 DockerHub에 업로드한 후 AWS EC2 환경에서 배포를 진행했다.

 

그러나 첫 번째 문제는 application-dev 파일을 gitignore에 추가해 GitHub에 포함되지 않도록 해서 Docker 이미지로 만들려고 했는데, EC2 환경에서 dev 파일을 인식하지 못하는 이슈가 생겼다.

 

두 번째 문제는 CI / CD 파이프라인의 중복 배포였다.

자동 CI / CD 파이프라인을 구축해 배포를 진행했는데, PR을 올리거나 코드 머지를 할 때마다 배포가 진행되는 이슈가 있었다.

그래서 리소스를 낭비하고 비용을 증가시켰고, 배포 환경의 지속적인 재시작을 한다는 문제점이 있었다.

 

🔥 2. Problem Analysis, 문제 분석

---

 

첫 번째 문제는 application-dev 파일이 gitignore에 포함되어 있어 Docker 이미지에 포함되지 않았고, AWS EC2 환경에서 필요한 설정 파일을 인식하지 못했다.

이건 설정 파일이 Docker 이미지에 포함되지 않기 때문에 발생한 문제였고, 민감한 정보를 포함한 설정 파일이 GitHub에 노출되는 위험이 있었다.

두 번째 문제는 CI / CD 파이프라인이 PR 생성과 코드 머지 이벤트를 구분하지 못해 두 이벤트 모두 배포를 트리거하는 설정이 문제였는데, 그로 인해 GitHub Actions 설정 파일이 제대로 분리되지 않아 중복 배포가 발생했다.

 

🔎 3. Solution Approach, 해결 과정

---

첫 번째 문제를 해결하기 위해 gitignore에서 application-dev 파일을 제외하고, 민감한 정보는 ENV 파일로 관리하기로 했다.

이를 위해서 GitHub Actions를 사용해 Secrets 변수를 설정하고, 배포 과정에서 해당 ENV 파일을 EC2 인스턴스로 복사했다.

이렇게 함으로써 민감한 정보가 GitHub에 노출되지 않고, 필요한 설정 파일을 EC2 환경에 적용할 수 있었다.

 

두 번째 문제 해결을 위해 GitHub Actions 설정 파일을 PR과 머지 이벤트로 분리했다.

PR 시에는 빌드와 테스트만 수행하고, 머지 시에만 실제 배포가 이루어지도록 했다. 따라서 각 이벤트별로 트리거 되는 작업을 명확하게 구분하여 설정했다.

 

name: Build for Push & PR

on:
  pull_request:
    types: [ "opened", "synchronize" ]
    branches: [ "develop", "main" ]

permissions:
  contents: read

jobs:
  build:
    ...

name: Build, Push Docker Image and Deploy to EC2 for Merge

on:
  pull_request:
    types: [ "closed" ]
    branches: [ "develop", "main" ]

permissions:
  contents: read

jobs:
  build:
    ...

 

📊 4. Outcome and Results, 결과 및 성과

---

AWS S3와 CodeDeploy 배포 방식에서 Docker를 활용한 방식으로 배포 환경을 구축하면서 확장성과 유연성을 챙겼고, 그래서 이후 Redis와 MySQL 그리고 Nginx를 추가할 수 있었다.

또한 Docker 이미지화를 통해 DockerHub에 업로드하고 이를 배포 환경에서 Pull 하는 방식으로 진행하면서 기존에 S3에 업로드하여 배포를 진행하는 방식에 비해 성능적인 이점을 챙길 수 있었다.

 

그리고 application-dev 파일 관련 이슈를 해결하여 Docker 이미지가 AWS EC2 환경에서 올바르게 동작할 수 있었고, 민감한 정보를 안전하게 관리하면서 배포 프로세스를 개선했다.

 

마지막으로 CI / CD 파이프라인의 중복 배포 문제를 해결하면서 리소스 낭비와 비용을 절감해서 배포 환경 안정화 및 배포 속도와 효율을 향상할 수 있었다.

 

✍️ 5. Lessons Learned and Future Plans, 교훈 및 향후 계획

---

이번 과정을 통해서 배포 환경에서 민감한 정보를 다루는 방법과 CI / CD 파이프라인 설정 시 이벤트 트리거를 명확히 구분하는 것이 필요하다는 것을 배웠다.

추가적으로 develop 용 EC2 인스턴스와 실제 운영이 될 EC2 인스턴스를 분리하여 배포 환경을 더욱 독립적으로 만들고, 이를 그린/레드 배포 방식을 활용하여 무중단 배포를 진행하고 싶은 욕심이 있었지만, 아쉽게도 프로젝트 기한이 얼마 남지 않아 적용해 보지 못했다.

또한, 추가적으로 모니터링과 로깅 시스템을 개선해서 문제가 발생을 했을 때 신속하게 대응할 수 있는 대비책도 고려해서 현재 프로젝트를 보완할 예정이다.