2022-11-28-TIL

Today I Learned

배포할 때 고려해야할 사항

서버의 배포를 할 때 고려해야할 순서가 있다. 먼저, 배포 대상 서버의 순서를 정한다. 예를 들어, FE 서버가 BE 서버의 API에 의존하고 있다면, BE 서버를 먼저 배포하고나서 FE 서버를 배포해야한다. 물론, 이때는 만일 FE에서 사용(의존)하고 있는 API가 변경되면 안되고, 확장되는 형태로 배포되는 것이 바람직하다. BE 서버에서 의존하고 있는 또 다른 서버가 있다면, 그 서버가 같은 맥락에서 먼저 배포되어야 한다.

두 번째로, BE 서버의 배포 내용에서 DB 스키마 변경이 있다면, DB 스키마가 반드시 먼저 변경 되고나서 배포되어야 한다. 논리적인 순서상으로 당연한 내용이지만, 이 부분에서 종종 실수를 할 수 있다. 따라서 실수를 하지 않도록 검증하는 절차나 툴을 사용하는 것이 안전하다.

서버 배포를 시작하기 전에 해당 서버가 Graceful Shutdown이 지원되는지에 따라 서버의 로그를 확인해야할 수 있다. 만일 Graceful Shutdown이 지원되지 않거나, 사용하는 메시지 큐 서비스(RabbitMQ, Kafka 등)가 메시지 처리가 중간에 끊어졌을때의 처리정책도 알고 있어야하며, 그에따라 배포전략을 달리 해야한다.

• https://www.rabbitmq.com/confirms.html
• https://blog.devgenius.io/guaranteed-message-delivery-with-rabbitmq-5211cff5f1e3
• https://medium.com/@andy.bryant/processing-guarantees-in-kafka-12dd2e30be0e

배포를 진행할 때는 단위 테스트를 돌리는 절차가 포함되어 있는 것이 안전하다. 최종적으로 코드를 병합하는 과정에서, 또는 프로그래머의 단순 실수로 포함되어야 할 코드가 누락된다던가, 포함되지 말아야 할 코드가 포함되는 경우가 발생할 수 있기 때문이다.

마지막으로, 배포중에는 서버의 로그를 실시간으로 모니터링하면서 서버의 배포가 잘 진행되었는지, 에러로그가 찍히지는 않는지 확인해야한다. 위의 절차를 충분히 따라했다면 핫픽스로 재배포하는 일은 거의 없을것이다.