개요
AWS 환경에서 운영하는 서비스 중 하나가 Single AZ로 구성되어 있는 것을 알게 되었다.
인프라 관련 담당자에 의하면 기존에 IP 대역이 부족해서 단일로 구성했었고, 이후에 IP 대역 추가 작업이 있었다고 한다. 이에 따라 예기치 않은 사고로 서비스 장애가 발생할 가능성을 줄이기 위해 Multi AZ로 구성을 변경하려고 한다.
업무 역할 상 AWS 구성을 직접 관리하지는 못했으나…… 비슷한 작업을 할 때 참고할 수 있도록 어떤 순서로 진행했는지 기록해둔다.
+ 참고로 동작하고 있던 서비스는 Airflow와 Tomcat(API 서버)이다.
구성도
정확하진 않지만…… 기존 구성도는 대략 다음과 같다.
운영계이므로 Public Subnet과 Database 쪽 Subnet은 HA로 구성되어 있었지만, 실제로 서비스가 동작해야 하는 Private Subnet이 IP 부족으로 구성되어 있지 않은 상태이다. 또한 간략하게 표현하기 위해 구성도에서는 인스턴스 대수를 생략했는데, 가용성을 이유로 서버가 2대씩 동작하고 있는 상태다.
때문에 AZ-a의 네트워크 구성을 AZ-c의 네트워크 구성과 동일하게 맞추고, AZ-c에서 동작하고 있는 서버를 한 대씩 AZ-a로 이전하는 것을 목표로 한다. 서버 이전은 복제본 생성 후, 기존 서버를 삭제하는 방식으로 진행한다.
따라서 TO_BE 구성은 다음 그림과 같겠다.
작업 내용
1. AZ-a에 Private Subnet 생성
- 필요 시 VPC에 신규 CIDR을 추가한다.
- Subnet을 생성한다.
- Subnet 내 자원이 인터넷으로 아웃바운드 통신을 할 수 있도록 NAT Gateway를 생성하고, 라우팅 규칙을 추가한다.
- 필요 시 Private NACL을 적용한다.
2. 생성한 서브넷 내 자원 생성
- 서버 이전을 위해 AZ-c에서 동작하고 있는 기존 서버의 복제본을 생성한다.
- EC2를 시작할 때 기존 서버의 AMI를 이용하고, 스토리지 또한 기존 서버와 연결되어있는 EBS의 스냅샷을 이용하여 생성 및 Mount한다.
- AWS 역할, 보안 그룹 등의 기타 설정은 기존 서버를 참고하여 설정한다.
3. 네트워크 관련 부분 점검
- 만약 EFS를 마운트하여 사용했다면, 신규 서버에서 정상적으로 접근할 수 있는지 확인한다.
- 데이터베이스(RDS, Elasticache), 소스 저장소(GitLab), 배포 관련 서비스(Jenkins) 등 필요한 통신에 문제가 없는지 확인한다.
- 아웃바운드 통신 위주로 점검한다.
4. 모니터링 설정
- 운영계이므로 서버 장애 대응을 위한 리소스 모니터링 관련 프로세스가 정상적으로 동작하는지 확인한다.
5. 서비스 동작 확인
- 서비스 동작 확인에 필요한 조건이 모두 충족되었으면 서비스를 시작하여 동작에 이상이 없는지 확인한다.
7. 서비스 접근 허용
- 서비스가 정상적으로 동작하면 서비스 접근을 위한 인바운드 통신을 허용한다.
7. 기존 서버 중지
- AZ-c에서 삭제해야 할 자원의 동작을 중지시킨다. 롤백에 대비하여 바로 삭제하지 않도록 한다.
8. 서비스 모니터링
- 서버 이전을 완료한 이후에는 일정 기간 서비스에 이상이 없는지 모니터링해야 한다.
9. 자원 삭제
- 중지시켰던 AZ-c의 자원을 완전히 삭제한다.