Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: 무중단 배포 Workflow 전략 수정 #565 #568

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

Ho-Tea
Copy link
Contributor

@Ho-Tea Ho-Tea commented Dec 9, 2024

⭐️ Issue Number

🚩 Summary

  • DEV환경 EC2내부에 아래와 같이 쉘 스크립트를 미리 지정

    xxx-origin으로 표현된 쉘 스크립트는 해당 변경작업 전에 구성되었던 것입니다

    image
  • deploy.sh 정상 실행 확인 완료
    스크린샷 2024-12-09 오후 5 28 35

  • rollback.sh 정상 실행 확인 완료
    image

  • switch.sh 정상 실행 확인 완료
    image

🛠️ Technical Concerns

🙂 To Reviewer

우선은 새로운 workflow를 생성하여 테스트를 진행하는 것으로 구성하였습니다!
변경사항들에 대한 기록은 노션페이지를 참고해주시면 감사하겠습니다

📋 To Do

@Ho-Tea Ho-Tea added backend We are backend>< ⚙️ build 빌드 관련 (빌드 스크립트 수정 등) ⛏️ chore 기타 변경사항 (위 사항 외 자잘한 수정) labels Dec 9, 2024
@Ho-Tea Ho-Tea added this to the sprint-7 milestone Dec 9, 2024
@Ho-Tea Ho-Tea self-assigned this Dec 9, 2024
@linirini
Copy link
Contributor

구현하시느라 수고하셨습니다. 호티!
덕분에 당시 저희가 설계했던 전략에 대해 저울질도 해보고, 나아가 고민해볼 수 있을 것 같아요:)
포트 전환을 일괄적으로 함에 따라 구버전과 신버전이 **공존**하는 시간을 줄이고, 저희 통제 아래 관리할 수 있을 것 같아요.
하지만, 아래와 같은 문제점도 있을 것 같으니 고민해보면 좋을 것 같습니다.
시나리오: DB 스키마에 변경 사항을 포함하는 신 버전 배포

  1. 롤백 및 포트 전환에는 얼마만큼의 시간이 걸릴까요?
    신 버전 배포가 완료되는 순간 DB 스키마도 변경 사항이 반영이 되었을 것입니다. (flyway를 사용하고 있으니까요!)
    만약, 하위호환이 불가능한 변경 사항이었다면, 롤백 및 포트 전환까지의 시간동안 서비스는 장애가 발생할 것 같아요. 신버전 실행 후 롤백 및 포트 전환 스크립트 실행 완료까지 얼마만큼의 시간이 걸리는지 체크해보면 어떨까요?
  2. 만약 일부 서버에서 배포에 실패하여 롤백한다면, DB는 롤백이 되지 않을텐데 이에 대한 전략을 구상해보았나요?
    일부 서버에서 배포에 실패하여 롤백이 발생해도, DB는 자동으로 롤백되지 않아요. 그렇다고 했을 때 하위 호환 측면에서는 문제가 되지 않을 수 있겠지만, 저희가 flyway를 사용하고 있기 때문에 버전 체크 시 오류로 판단할 수 있지 않을까요? DB에 대한 롤백 전략도 함께 고민해보면 좋을 것 같아요!
  3. 포트 전환 스크립트는 얼마만큼의 시간이 걸리는가, 두 개의 서버에서 포트 전환 스크립트를 동시에 실행했을 때 버전 호환 문제가 생기는 텀은 어느정도인가?
    기존의 스크립트는 병렬로 prod-a와 prod-b가 배포 스크립트를 실행했습니다. 그랬을 때 두 서버가 버전이 충돌하는 시간이 이전 스크립트와 현재 스크립트가 얼마나 달라졌는지 수치로 직접 확인해보면 좋을 것 같아요!

저도 고민해보았지만, 제일 안전한 방법은 DB 변경 작업을 포함한 배포는 사용자 유입이 적은 시간대에 잠시 서버를 중단하는 것이지 않을까 싶네요! 호티도 함께 고민해보면 좋을 것 같아서 공유합니다.

Copy link
Contributor

@BurningFalls BurningFalls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

노션에 정리한 내용 읽어봤습니다. 내용이 깔끔해서 금방 이해할 수 있었어요. 정리하느라 수고하셨습니다 호티!

한 가지 고민해볼 부분이 있어서 말씀드리고 approve 합니다.

만약에 EC2 자체에 문제가 생겨서 컨테이너 두 개가 다 내려갔고,
그 상태에서 deploy.sh 를 실행했는데 컨테이너를 띄우는데 실패한 경우,
컨테이너의 총 개수는 0개가 됩니다.
따라서 1개 이하의 컨테이너가 존재하므로, rollback.sh 에서 아무 동작도 수행하지 않아서
결국 아무런 컨테이너를 띄우지 않게 됩니다.
이를 방지할 수 있는 로직을 넣으면 좋을 것 같아요.

그리고 추가로, 이 로직은 최소 하나의 컨테이너를 유지하여 서버 접속이 가능하도록 만드는 게 목적이기 때문에, 적정 횟수(예를 들면 세 번)만큼 시도하고 그래도 안되면 중단하고 잘못되었다는 신호를 보내도록 하는 반복문이 있으면 좋을 것 같아요.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend We are backend>< ⚙️ build 빌드 관련 (빌드 스크립트 수정 등) ⛏️ chore 기타 변경사항 (위 사항 외 자잘한 수정)
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

3 participants