개요
2023.08.29 - [Airflow] OS 업그레이드 작업 기록 - 서비스 검증 환경 구성 고민에서는 OS 업그레이드 작업 중 서비스 계정의 UID:GID 변경을 위한 검증 환경을 어떻게 구성할 지에 대해 고민했었다.
이 글에서는 구성은 끝났고, 어떻게 서비스를 검증했는지, 검증 작업 수행 순서 등에 대해 적어둔다.
현재 구성도는 대략 아래 사진과 같다. 인스턴스에 _NEW가 붙은 리소스가 신규 OS 서버이다.
서비스 검증 방법
신규 OS를 사용하는 서버에 Airflow 설치를 완료하고 서비스가 동작하기 위한 조건을 모두 갖췄다는 전제하에 서비스 검증을 진행한다. 가급적 서비스 중단 없이 진행하고자 블루-그린 업데이트를 수동으로 수행하는 모습으로 진행을 해보았다.
WebServer / Celery Flower
WebServer / Celery Flower 두 개 서비스는 Airflow Task 동작에 영향을 미치지 않는 요소라 편하게 진행했다. 두 서비스 모두 웹 접속을 해보는 게 가장 확실한 검증 방법이므로 사전에 NLB의 Target Group에 인스턴스는 미리 추가 등록해 두었다.
1. 기존 Master 1의 프로세스를 종료한다.
2. 신규 Master 1_NEW의 프로세스를 실행한다.
3. 기존 Master 2의 프로세스를 종료한다.
4. 신규 Master 2_NEW의 프로세스를 실행한다.
5. 웹 브라우저를 통해 WebServer / Celery Flower에 정상적으로 접속되는지 확인한다.
Airflow Log 경로가 달라져서 그런지 신규 서버에서 프로세스를 돌렸을 때는 기존에 저장되어 있던 Airflow Task Log를 웹에서 확인할 수 없었다. 만약 서버 운영 전환을 바로 할 수 없는 상태고, Task 로그를 자주 확인한다면 서비스 검증을 완료한 후 서버 운영 전환할 때까지는 기존 서버에서 웹서버를 동작시키는 것이 좋겠다.
Celery Flower는 어느 서버에서 동작하든 상관없는 것 같다.
Scheduler / Celery Worker
Scheduler와 Celery Worker는 Airflow Task 동작에 영향을 미치는 요소기 때문에 좀 더 주의해서 진행했다. Celery Worker의 경우 서비스를 종료하는 대신, Flower를 이용해 서버에 Task가 스케쥴링되지 않도록 Task Queue를 삭제했다가 다시 생성하는 방식으로 진행해도 된다.
1. 기존 Worker 1의 Task Queue를 제거한다.
2. 기존 Master 1의 Scheduler를 종료한다.
3. 신규 Master 1_NEW의 Scheduler를 실행한다.
4. 신규 Worker 1_NEW의 프로세스를 실행한다.
5. 기존 Worker 2의 Task Queue를 제거한다.
6. 기존 Master 2의 Scheduler를 종료한다.
7. 신규 Master 2_NEW의 Scheduler를 실행한다.
8. 신규 OS를 사용하는 서버만을 이용해 Airflow Task가 정상적으로 동작하는지 확인한다.
서비스 검증을 완료했다면 서버 운영 전환 시점과 추가로 처리 및 검증할 부분이 없는지 고려해보아야 하겠다.