개요
2023.08.29 - [Airflow] OS 업그레이드 작업 기록 - 서비스 검증 환경 구성 고민
2023.09.04 - [Airflow] OS 업그레이드 작업 기록 - 서비스 검증
위 두 개 글에서 Airflow OS 업그레이드 작업 중 서비스 계정의 UID:GID 변경을 위한 검증 환경을 어떻게 구성할지, 그리고 서비스 검증 방법에 대해 고민하고 진행한 내용을 정리했다.
이 글은 서비스 검증까지 완료한 상태에서 서비스 이관을 위해 고민했던 점을 적어둔다.
이슈 사항
현재 구성도는 대략 아래 사진과 같다. 인스턴스에 _NEW가 붙은 리소스가 신규 OS 서버이다.
그리고 작업하고 있는 Airflow는 CeleryExecutor를 사용하는 만큼 Worker를 scalable 하게 사용한다.
보통 AWS 환경에서 서버 scaling을 뜻하면 AWS AutoScaling 기능을 생각하는데, 이 글에서 다루는 환경은 AWS AutoScaling 기능을 사용하지 않는다. Dag가 동작하면서 Worker를 Launch 하여 Task를 해당 Worker에서 처리한 후, Worker를 Terminate 한다. 이를 위해 Worker AMI를 사용하는 Launch Templete을 사용한다.
즉, 신규 OS로 서비스 이관을 하기 위해서는 서비스 동작이 보장된 Woker 1_NEW의 AMI를 사용한 Worker 2의 생성과 Worker의 Launch Templete 업데이트도 필요하다. LT를 통해 시작한 서버는 Worker 프로세스가 부팅 시 자동으로 시작될 수 있도록 설정해야 한다.
이런 상태에서 서비스 중단 없이, 그리고 서버 담당자와 작업 일정을 협의하지 않고 자체적으로 신규 서버로 서비스 이관을 수행할 수 있을까? 어떤 순서로 진행해야 최대한 효율적으로 작업할 수 있을까?
방안
서비스 이관 관련해서 고려했던 방안은 다음과 같다.
1. 서버 담당자와 서비스 이관 및 서버 운영 전환을 위한 일정을 조율하여 작업한다.
=> 안전하고 확실하게 Scheduler, Worker를 포함한 모든 서비스를 이관할 수 있지만, 별도로 일정 조율이 필요하다. 불필요하게 작업 일정을 조율하고 싶진 않아 크게 고려하지 않았다.
2. 서버 담당자에게 요청하여 Worker 2를 생성하고 Worker Launch Templete을 업데이트한다.
=> Worker 1_NEW가 부팅 시 Worker 프로세스가 시작되게 설정한 상태의 AMI를 이용해 Worker 2를 생성하면 Worker 프로세스가 시작하는 시점을 서비스 담당자 쪽에서 제어할 수 없게 된다. Task 실행에 영향을 미치는 Scheduler, Worker 프로세스는 가급적 서비스 이관을 하면서 시작하는 게 좋을 것 같아 이 방안은 적절하지 않아 보였다.
물론 부팅 시 Worker 프로세스가 시작되지 않게 설정한 상태의 AMI로 Worker 2를 생성하고, 부팅 시 Worker 프로세스가 시작되게 설정한 상태의 AMI로 Launch Templete을 업데이트해도 되겠지만, AMI를 두 번 생성해야 한다는 점이 효율적이지 않았다.
3. 서버 담당자에게 요청하여 Worker Launch Templete을 업데이트하고 Worker 2를 생성한다.
=> AWS AutoScaling 기능은 Launch Templete 버전 기본값을 의존하는데, 작업 중인 Airflow는 Launch Templete을 이용해 서버를 시작할 때 사용할 Launch Templete과 버전을 지정해서 사용한다. 즉, 신규 OS를 사용한 Launch Templete 사용 시점을 서비스 담당자가 제어할 수 있다. 또한 Worker 1_NEW의 복제한 것과 같기 때문에 Worker 2를 생성하기 전까지 임시로 서버를 올려서 사용할 수 있다.
다만 프로세스 자동 재시작 스크립트로 인해 Worker가 프로세스 실행 상태면서 Task는 처리하지 않는 상태를 유지할 수 있는지가 고민이 되었는데,
2023.09.05 - [Airflow] Celery worker의 queue 삭제 시 프로세스 종료 여부에서 확인해 본 결과 Flower로 Task Queue를 삭제하면 딱 원하는 상태를 유지할 수 있었다.
서비스 이관 시점을 서비스 담당자가 결정할 수 있고, 서버 담당자와 서버 운영 전환 작업을 일정 협의하지 않고 진행할 수 있기 때문에 Launch Templete 먼저 업데이트하고, Worker 2를 생성하기로 했다.