CD - 100-hours-a-week/21-iceT-wiki GitHub Wiki

1. 배포 속도 및 정확성 향상

• 기존 Koco 서비스에는 로컬 빌드 → SCP 전송 및 SSH 접속 → 수동 재시작 등 여러 단계를 사람이 직접 수행
• 이 과정에서 실수 가능성이 존재하고, 시간이 오래 걸림 (약 30분 소요)
• CD 파이프라인을 통해 배포 과정을 자동화하면, 클릭 한 번 또는 Git 태그 푸시만으로 3~5분 내 안정적으로 배포 가능
• 또한, 매일 새로운 코테 정답 업데이트, 챗봇, 커뮤니티 기능을 갖춘 본 서비스는 기능 개발을 자주 업데이트할 필요가 있어, 빠르고 신뢰성 있는 자동 배포 체계가 필요하다.

2. 무중단 서비스 운영

• 서비스는 매일 오전 9시 30분~10시 사이가 최대 트래픽 시간대(동시 접속자 약 150명 예상)
• 정기 배포는 금요일 18시로 설정되어 있지만, 배포 실패 시 복구가 느리면 사용자에게 영향이 갈 수 있음
• CD를 통해 헬스 체크 + 롤백 전략 포함된 Blue-Green 배포를 구성함으로써(추후 카나리 배포 적용), 배포 중에도 서비스 중단 없이 안정적인 전환 가능

3. 서비스 신뢰도 확보

• 해설 제공 서비스는 정확성과 신뢰가 핵심인데, 배포 오류나 장애가 빈번하면 사용자 신뢰가 급격히 저하됨
• 자동화된 CD 파이프라인은 테스트, 헬스 체크, 모니터링까지 포함하여 배포 이후 안정성을 확보하고, 이상 징후 발생 시 빠르게 대응 가능함

4. 개발 효율성 향상 및 반복 가능한 배포

• 수동 배포는 담당자가 없으면 실행이 어렵고, 주석/명령 실수로 배포 상태가 달라질 수 있음
• CD는 누가 해도 동일한 결과가 나오는 반복 가능한 배포 환경을 제공하여, 팀워크와 생산성 향상에 기여함

5. MVP 단계에서의 민첩한 반복 개선을 가능하게 함

• 현재는 MVP 단계로, 기능 개선과 수정이 빈번하게 이뤄짐
• CD 파이프라인을 통해 작은 변경도 빠르게 반영하고 즉시 배포 가능, 사용자 피드백을 빠르게 반영하는 애자일한 개발/배포 사이클을 구축할 수 있음

• 스테이징 환경: 자동 배포(Continuous Deployment) 적용
• 운영(프로덕션) 환경: 승인 후 배포(Continuous Delivery) 방식 채택

• 초기: Blue-Green 배포 전략 적용
  • 기존 서비스 버전(Green)을 유지한 상태에서 새로운 버전(Blue)을 별도로 배포
  • 배포 완료 후 검증을 거쳐 트래픽을 새로운 버전으로 전환
  • 오류 발생 시 즉시 기존 버전으로 복귀 가능


• 추후: 카나리 배포 전략 도입 예정
  • 초기에는 일부 사용자에게만 새로운 버전을 노출하여 안정성을 검증
  • 점진적으로 전체 사용자로 트래픽을 확장
  • 장애 발생 시 영향을 최소화하고 빠르게 복구 가능

우리 서비스는 코딩테스트 해설집을 제공하는 플랫폼으로, 매일 오전 9시 30분부터 10시까지가 최대 트래픽 시간대이며, 이때 최대 동시 접속자 수는 약 150명으로 예상됩니다.

사용자는 짧은 시간 안에 문제 풀이 및 해설을 확인하기 때문에, 순간적인 접속 지연이나 서비스 중단은 사용자 경험에 매우 치명적일 수 있습니다.

MVP 초기에는 서비스 신뢰성과 무중단을 최우선으로 해야 하므로, 검증 후 한 번에 전체 트래픽을 전환하는 Blue-Green 배포를 적용합니다. 이를 통해 빠른 롤백이 가능하고, 서비스 초기 품질을 안정적으로 관리할 수 있습니다.

서비스가 점차 안정되고 기능 개선 및 버그 수정이 잦아질 경우,

• 운영 환경의 변경 주기가 짧아지고, 다양한 코드 변경이 누적되면서 단번에 전체 사용자에게 배포할 경우, 예상치 못한 오류나 성능 저하가 전체 사용자에게 즉시 영향을 미칠 위험이 커집니다.
• 특히, 모든 사용자가 동시에 새로운 버전을 사용하게 되면, 소수의 이상 징후만으로도 서비스 전체에 장애가 발생할 수 있어, 복구 작업 부담과 장애 리스크가 급격히 증가합니다.

따라서 일부 사용자 그룹에만 새 버전을 노출하여 안정성을 검증하고, 문제가 없을 때 점진적으로 배포를 확장하는 카나리 배포 전략을 통해 운영 리스크를 최소화할 필요가 있습니다.

또한, 우리 서비스는 매일 새로운 문제와 해설 업데이트가 필요한 구조이기 때문에,

• 콘텐츠 특성상 사용자에게 매일 새로운 문제를 제공해야 하며,
• 이에 따라 문제 데이터, 해설 데이터뿐 아니라 관련 기능(출제 로직, 해설 페이지 렌더링 등) 업데이트도 빈번하게 발생할 가능성이 높습니다.
• 결과적으로 배포 주기가 짧아지고, 배포 빈도 또한 점차 증가할 수밖에 없습니다.

빈번한 배포 환경에서는, 대규모 일괄 배포 방식보다는 소규모 분산 배포를 통한 리스크 통제가 필수적이기 때문에, 카나리 배포 방식이 점진적으로 필요하게 됩니다.

마지막으로, 금요일 오후 18시 정기 배포 이후 비교적 사용자 접속이 적은 야간 시간대를 활용하여 모니터링 및 안정성 확보 시간을 가질 수 있어, 운영 효율성 측면에서도 유리합니다.

이번 CD(Continuous Delivery/Deployment) 파이프라인은 스테이징 자동화 배포 → 운영 배포 승인 → Blue-Green 또는 카나리 배포 → QA 및 모니터링 → 최종 확정까지 체계적으로 관리하는 구조로 설계되었습니다.

특히, Blue-Green 배포와 카나리 배포를 적용하든, 수동 배포를 진행하든 관계없이, Slack 알림 발송, 운영 QA 점검, 초기 집중 모니터링 등의 운영 흐름은 동일하게 필수 절차로 포함되어야 합니다. 수동 배포 환경에서도 이러한 운영 프로세스를 엄격히 준수하여 서비스 안정성과 배포 신뢰성을 확보합니다.

• Push release tag
• Build artifact
• 스테이징 자동 배포
• 스테이징 자동화 테스트

• 성공 시: 운영 배포 승인 요청, 운영 배포 승인
• 실패 시: 배포 차단 및 Slack 알림

• Blue 버전 배포
• Health Check 성공 시 트래픽 전환 (Green → Blue)
• 배포 완료 후 QA 검증 및 초기 집중 모니터링
• 이상 발생 시 Green으로 롤백

• 5~10% 카나리 배포
• 모니터링 후 점진적 트래픽 확장 (10%→30%→70%→100%)
• 이상 발생 시 카나리 롤백

• Health Check 실패 시 배포 중단 및 롤백
• 초기 모니터링 중 이상 발생 시 긴급 롤백 또는 핫픽스

• 스테이징 테스트 실패 시 알림
• 운영 배포 승인 요청 알림
• 배포 시작, 완료, 이상 발생, 롤백 등 상태별 알림

키워드: 스테이징 자동화 → 운영 승인 → Blue-Green/카나리 배포 → QA → 모니터링 → 확정 or 롤백 대응

• 스테이징 자동화 테스트 실패 시: Slack 알림 발송
• 스테이징 테스트 성공 시: 운영 배포 승인 요청 Slack 알림
• 운영 배포 시작 시: Slack 알림 발송
• 운영 배포 성공 시: Slack 알림 발송
• 헬스체크 실패/긴급 롤백 발생 시: 긴급 롤백 Slack 알림
• 최종 QA 완료 후 배포 확정: Slack 알림 발송

• Slack Incoming Webhook을 생성하여 GitHub Secrets에 SLACK_WEBHOOK_URL로 저장

- name: Slack 알림 - 스테이징 테스트 실패
  if: failure()
  run: |
    curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"⚠️ [스테이징 테스트 실패] - 배포가 차단되었습니다."}' \
    ${{ secrets.SLACK_WEBHOOK_URL }}

- name: Slack 알림 - 운영 배포 승인 요청
  if: success()
  run: |
    curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"🚀 [스테이징 테스트 성공] 운영 배포 승인 요청을 해주세요."}' \
    ${{ secrets.SLACK_WEBHOOK_URL }}

- name: Slack 알림 - 운영 배포 시작
  run: |
    curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"🚀 [운영 배포 시작] 배포를 시작합니다."}' \
    ${{ secrets.SLACK_WEBHOOK_URL }}

- name: Slack 알림 - 운영 배포 완료
  run: |
    curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"🎉 [운영 배포 완료] QA를 시작해주세요."}' \
    ${{ secrets.SLACK_WEBHOOK_URL }}

- name: Slack 알림 - 헬스체크 실패 및 롤백
  if: failure()
  run: |
    curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"🔥 [운영 헬스체크 실패] 긴급 롤백을 수행합니다!"}' \
    ${{ secrets.SLACK_WEBHOOK_URL }}

- name: Slack 알림 - 최종 배포 확정
  run: |
    curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"✅ [운영 배포 확정] 서비스가 정상 운영 중입니다."}' \
    ${{ secrets.SLACK_WEBHOOK_URL }}

• ⚠️ 경고 (테스트 실패)
• 🚀 시작 (배포 시작)
• 🎉 성공 (배포 완료)
• 🔥 긴급 (롤백)
• ✅ 최종 완료 (QA 확정)

• 배포 대상: AWS EC2 인스턴스 (Ubuntu, Amazon Linux2 등 예상)
• 방식: GitHub Actions + SSH 배포 + systemd 서비스 재시작
• 테스트 및 모니터링: Health Check 스크립트 + Slack 알림

1. CI와 CD를 하나의 플랫폼에서 통합 관리 가능

• 이미 CI 파이프라인을 GitHub Actions로 구성하고 있기 때문에, 별도의 도구 없이 CD까지 GitHub Actions 내에서 이어서 구성 가능
• 빌드, 테스트, 배포까지 전체 DevOps 흐름을 하나의 워크플로우 파일로 관리 가능

2. GitHub 저장소 이벤트 기반 자동화에 최적화

• release-* 태그 푸시 등 GitHub 내 이벤트(trigger)에 매우 쉽게 연동 가능
• push, pull_request, tag, schedule 등 다양한 조건에 따른 배포 자동화 구성이 간단

3. 학습 및 유지보수가 간단함

• 다른 CD 도구(Jenkins, ArgoCD 등)에 비해 설정이 직관적이고, YAML 기반으로 쉽게 이해 가능
• 작은 팀이나 MVP 단계에서 도입 장벽이 낮고, 유지보수가 쉬움

4. 외부 도구 설치 없이 바로 실행 가능

• GitHub Actions는 GitHub 환경 내에서 바로 실행되므로, Jenkins처럼 별도 서버 구성 없이도 운영 가능
• AWS EC2배포 시에도 scp, ssh 액션을 통해 간단하게 배포 자동화 구현 가능

5. 비용 효율성과 GitHub 연동성

• GitHub Actions는 개인 또는 소규모 프로젝트에 대해 무료 요금제로도 충분히 사용 가능
• GitHub와의 시크릿 관리, 버전 컨트롤, PR 연동 등 통합성이 뛰어남

• systemd service에 ExecStartPre로 헬스 체크 후 실행
• 실패 시 디스코드 알림 → 기존 디렉토리로 symlink 복구 → 재시작

on:
  push:
    tags:
      - 'release-*'

• release-로 시작하는 태그(ex. release-v1.0)를 푸시하면 자동으로 CD 파이프라인이 실행돼서 AWS 서버에 배포가 진행

- name: Download React Build Artifact
  uses: actions/download-artifact@v3
  with:
    name: react-build


name: Deploy React via SSH
uses: appleboy/[email protected]
with:
host: ${{ secrets.AWS_HOST }}
username: ubuntu
key: ${{ secrets.AWS_SSH_KEY }}
source: "frontend/build/"
target: "/home/ubuntu/deployments/react-build/"


name: Replace Nginx Static Files
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.AWS_HOST }}
username: ubuntu
key: ${{ secrets.AWS_SSH_KEY }}
script: |
sudo rm -rf /var/www/html/*
sudo cp -r /home/ubuntu/deployments/react-build/* /var/www/html/
sudo systemctl reload nginx

- name: Download Build Artifact
  uses: actions/download-artifact@v3
  with:
    name: springboot-jar


name: Deploy via SSH
uses: appleboy/[email protected]
with:
host: ${{ secrets.AWS_HOST }}
username: ubuntu
key: ${{ secrets.AWS_SSH_KEY }}
source: "build/libs/myapp.jar"
target: "/home/ubuntu/deployments/myapp-blue.jar"


name: Run Remote Deploy Script
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.AWS_HOST }}
username: ubuntu
key: ${{ secrets.AWS_SSH_KEY }}
script: |
sudo systemctl stop spring.service
sudo cp /home/ubuntu/deployments/myapp-blue.jar /opt/myapp/app.jar
sudo systemctl start spring.service

- name: Download FastAPI Artifact
  uses: actions/download-artifact@v3
  with:
    name: fastapi-src


name: Deploy FastAPI via SSH
uses: appleboy/[email protected]
with:
host: ${{ secrets.AWS_HOST }}
username: ubuntu
key: ${{ secrets.AWS_SSH_KEY }}
source: "fastapi/"
target: "/home/ubuntu/deployments/fastapi-blue/"


name: Run FastAPI Deploy Script
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.AWS_HOST }}
username: ubuntu
key: ${{ secrets.AWS_SSH_KEY }}
script: |
sudo systemctl stop fastapi.service
sudo rm -rf /opt/fastapi/*
sudo cp -r /home/ubuntu/deployments/fastapi-blue/* /opt/fastapi/
sudo systemctl start fastapi.service

// 애플리케이션 포트 (기본: 8080)
PORT=8080
// 헬스체크 요청
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" "$URL")
if [ "$RESPONSE" -eq 200 ]; then
echo "✅ Spring Boot 애플리케이션이 정상적으로 실행 중입니다."
exit 0
else
echo "❌ 헬스체크 실패: 상태 코드 $RESPONSE"
exit 1
fi

PORT=8000
ENDPOINT="/health"
URL="<http://localhost&gt;:$PORT$ENDPOINT"
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" "$URL")
if [ "$RESPONSE" -eq 200 ]; then
echo "✅ FastAPI 헬스체크 성공 (HTTP 200)"
exit 0
else
echo "❌ FastAPI 헬스체크 실패: 상태 코드 $RESPONSE"
exit 1
fi

# 심볼릭 링크 교체 방식
ln -sfn /var/www/app-blue /var/www/html
sudo systemctl reload nginx

• GitHub Secrets 사용:
  • AWS_HOST
  • AWS_SSH_KEY
• 서비스 내부 환경변수는 .env 파일이 아닌 systemd 환경 설정 파일로 관리