Amazon Linux 1 지원 종료: 운영 서버를 안전하게 교체한 방법
지원 종료된 Amazon Linux 1 서버를 발견한 뒤 인플레이스 업그레이드 대신 새 환경을 병행 구축하고, 실제 메시지 처리까지 검증해 전환한 기준을 정리했다.
이 글의 목차사용 중인 운영체제의 정확한 수명부터 확인했다8
기존 회사의 메시지 발송 서버를 점검하다가 운영체제가 이미 지원 종료 상태라는 것을 확인했다.
미적용 패치도 128개가 쌓여 있었다.
운영체제는 애플리케이션이 사용하는 프로세스, 파일, 네트워크와 시스템 라이브러리의 바닥을 관리한다.
그 바닥이 지원을 받지 못하면 애플리케이션 코드를 그대로 두어도 새 보안 수정과 버그 수정을 받기 어려워진다.
문제는 “업데이트 명령을 실행하면 되는가”가 아니었다.
외부 요청을 받아 메시지를 보내는 서버라서 운영 중인 환경을 직접 크게 바꿨다가 실패하면 발송 경로 자체가 멈출 수 있었다.
나는 기존 서버를 고쳐 새 서버로 만드는 대신, 새 환경을 옆에 준비하고 검증이 끝난 뒤 서비스 경로를 바꾸는 방식을 택했다.
예를 들어 문자나 이메일 발송 서버가 멈추면 회원가입 인증, 주문 알림과 비밀번호 재설정이 한꺼번에 지연될 수 있다.
서버 한 대의 업데이트처럼 보여도 사용자 입장에서는 여러 기능의 입구가 동시에 닫히는 변경이었다.
사용 중인 운영체제의 정확한 수명부터 확인했다
원본 업무 기록에는 기존 환경이 Amazon Linux 2018.03 계열이고 지원 종료일이 2023년 12월 31일이라고 남아 있었다.
AWS 공식 문서는 이 제품을 Amazon Linux AMI 또는 Amazon Linux 1이라고 부른다.
AWS의 Amazon Linux AMI 지원 종료 공지는 마지막 2018.03 릴리스가 2023년 12월 31일에 지원 종료됐고, 이후 보안 업데이트와 버그 수정이 제공되지 않는다고 설명한다.
Amazon Linux AMI 공식 FAQ에서도 2024년 1월 1일부터 보안 업데이트와 버그 수정이 없다고 확인할 수 있다.
이 날짜를 확인한 이유는 “버전이 오래돼 보인다”는 인상과 공급자가 유지보수를 끝냈다는 사실을 구분하기 위해서였다.
128개라는 숫자도 같은 방식으로 해석했다.
미적용 패치 수만으로 위험도를 확정할 수는 없지만, 앞으로의 보안 수정까지 끊긴 환경을 교체해야 한다는 판단에는 충분했다.
같은 점검을 다시 한다면 서버에서 다음처럼 제품과 커널 정보를 먼저 읽는다.
cat /etc/os-release
uname -r/etc/os-release는 배포판 이름과 버전을 기록한 표준 파일이고, uname -r은 현재 실행 중인 Linux 커널 버전을 보여 준다.
둘 다 설정을 바꾸지 않는 조회 명령이다.
이미지 이름이나 자산 관리표만 믿지 않고 실제 인스턴스의 값을 확인하려고 함께 사용한다.
인플레이스 업데이트보다 병행 환경을 택했다
운영체제 교체에는 크게 두 가지 접근이 있었다.
인플레이스 업데이트는 현재 서버 안에서 패키지와 운영체제를 바꾸는 방식이다.
서버를 하나만 유지해도 된다는 장점이 있지만, 시스템 라이브러리나 설정이 어긋나면 현재 서비스와 복구 경로가 함께 흔들릴 수 있다.
병행 전환은 기존 환경을 유지한 채 새 서버를 만들고 애플리케이션을 배포한 다음, 검증이 끝났을 때 트래픽이나 작업 경로를 바꾸는 방식이다.
흔히 블루·그린 전환이라고 부르며, 기존 환경과 새 환경을 두 색으로 구분해 설명하는 배포 방식이다.
추가 인프라 비용과 환경 간 설정 차이를 관리해야 하지만, 실패하면 기존 경로로 되돌리기 쉽다는 장점이 있었다.
이번 메시지 서버에서는 중단 위험을 낮추는 일이 우선이라 병행 전환을 선택했다.
Amazon Linux의 메이저 버전 사이에는 인플레이스 업그레이드가 지원되지 않는다.
AWS는 AL1에서 AL2, AL2에서 AL2023처럼 메이저 버전이 바뀌는 경우 새 운영체제로 마이그레이션하라고 안내한다.
따라서 이번 선택은 위험을 낮추기 위한 운영 판단이면서, 제품이 제공하는 업그레이드 경로에도 맞았다.
선택 기준을 일반화하면 다음과 같다.
| 상황 | 더 적합한 접근 | 판단 이유 |
|---|---|---|
| 지원 중인 같은 메이저 버전의 보안 패치 | 테스트 후 인플레이스 업데이트를 검토 | 변경 범위가 패키지 수준이고 백업·복구 절차를 준비할 수 있다 |
| 지원 종료 또는 메이저 버전 변경 | 새 환경 병행 구축 | 라이브러리·설정 차이를 운영 서버 밖에서 검증할 수 있다 |
| 단일 서버이며 중단을 허용할 수 있음 | 백업 후 계획된 교체도 가능 | 추가 환경 비용보다 단순한 운영이 중요할 수 있다 |
| 인증·메시지·결제처럼 중단 영향이 큼 | 블루·그린 전환을 우선 검토 | 기존 경로를 복구 대상으로 남길 수 있다 |
이 표는 모든 시스템에 그대로 적용하는 규칙이 아니다.
데이터를 로컬 디스크에 저장하는지, 외부 상태 저장소를 쓰는지와 허용 가능한 중단 시간을 함께 봐야 한다.
새 환경의 정확한 운영체제 버전은 기록에 남아 있지 않아 특정 제품명은 쓰지 않았다.
현재 새 환경을 설계한다면 AWS의 Amazon Linux 문서에서 지원 중인 배포판과 수명 주기를 다시 확인해야 한다.
새 서버는 “프로세스 실행 중”만으로 통과시키지 않았다
새 환경에는 애플리케이션과 필요한 설정을 배포한 뒤 세 단계의 검증 기준을 뒀다.
첫째, 서버 프로세스가 정상적으로 실행 중인지 확인했다.
프로세스가 실행 중이라는 사실은 프로그램이 시작 단계에서 즉시 종료되지 않았다는 최소 조건이다.
둘째, 애플리케이션이 사용하는 데이터베이스에 연결되는지 확인했다.
운영체제가 바뀌면 인증서, 네트워크 설정, 시스템 라이브러리 차이 때문에 프로그램은 떠 있어도 외부 시스템과 통신하지 못할 수 있다.
셋째, 실제 메시지 처리 로그의 상태와 시각을 확인했다.
헬스 체크 주소가 200을 반환해도 업무 데이터가 끝까지 처리됐다는 뜻은 아니기 때문이다.
공개용으로 단순화한 전환 조건은 다음과 같다.
const candidate = await provisionNewHost();
await candidate.deploy(messageServerImage);
const health = await candidate.verify({
process: 'running',
database: 'connected',
latestMessageStatus: 'done',
});
if (!health.ok) throw new Error('cutover aborted');
await traffic.switchTo(candidate);process: 'running'은 프로그램 기동 여부를 확인한다.
database: 'connected'는 데이터 저장소까지 통신할 수 있는지 확인한다.
latestMessageStatus: 'done'은 실제 업무 흐름의 마지막 상태를 확인하기 위해 선택한 조건이다.
cutover aborted는 검증 하나라도 실패하면 서비스 경로를 새 서버로 바꾸지 않는다는 뜻이다.
이 코드는 내부 배포 도구의 원문이 아니라 판단 순서를 설명하기 위해 일반화한 예시다.
전환과 철거를 같은 순간에 하지 않았다
새 환경이 준비됐다고 기존 서버를 곧바로 종료하지 않았다.
서비스 경로를 바꾸는 전환과 기존 환경을 없애는 철거 사이에 관찰 구간을 두어야 되돌릴 대상이 남는다.
전환 직후에는 최신 메시지 처리 로그 3건이 모두 done 상태인지 확인했다.
3/3건 done은 새 경로에서 실제 메시지가 끝까지 처리됐다는 전환 직후의 확인값으로 사용했다.
문제가 생겼다면 기존 경로로 되돌리고 새 환경의 로그와 설정을 다시 확인할 계획이었다.
AWS의 마이그레이션 롤백 전략도 블루·그린 패턴에서 기존 환경으로 트래픽을 되돌리는 방식을 대표적인 복구 경로로 설명한다.
데이터를 직접 저장하는 서버라면 두 환경의 데이터 동기화와 역방향 복구 절차도 전환 전에 설계해야 한다.
전환 후 확인한 결과
지원 종료 환경을 새 환경으로 교체했고, 전환 전에는 프로세스와 데이터베이스 연결을 확인했다.
전환 직후 최신 메시지 처리 로그 3건도 모두 done이었다.
정확한 중단 시간과 전후 처리량은 당시 계측하지 않아 무중단이라는 표현은 사용하지 않았다.
다음 작업에서는 전환 창 전후의 처리 건수, 실패율, 처리 지연의 p95, 큐 적재량을 함께 남기는 편이 좋다.
p95는 처리 시간을 빠른 순서로 세웠을 때 95%가 이 값 이내에 끝났음을 보여 주는 지표다.
평균만으로는 드물게 매우 늦어진 메시지를 놓칠 수 있어 전환 전후의 긴 지연을 확인하는 데 도움이 된다.
다시 쓸 수 있는 지원 종료 서버 교체 체크리스트
- 운영체제 이름과 릴리스를 확인하고 공급자의 공식 지원 종료일을 기록한다.
- 미적용 패치를 심각도와 외부 노출 경로별로 분류한다.
- 현재 서버의 프로세스, 설정, 인증서, 네트워크, 예약 작업과 외부 연결을 목록으로 만든다.
- 새 환경을 별도로 만들고 같은 애플리케이션과 설정을 재현한다.
- 프로세스 기동, 데이터베이스 연결, 실제 업무 처리의 세 단계로 검증한다.
- 전환을 멈출 조건과 기존 환경으로 되돌릴 조건을 숫자로 정한다.
- 전환과 기존 환경 철거 사이에 관찰 시간을 둔다.
- 중단 시간, 성공률, 처리량, 지연과 큐 적재량을 같은 시간 범위로 비교한다.
- 기존 환경을 제거하기 전에 로그와 복구 자료를 보존한다.
운영 중인 경로를 먼저 끊지 않는 접근은 보안그룹 규칙을 지우기 전에 먼저 길을 하나 더 만들었다에서도 같은 원칙으로 사용했다.
전환 뒤 지표가 잠시 오지 않는 상황까지 감시하려면 CloudWatch 알람이 ‘데이터 없음’을 장애로 판단하고 있었다의 구분도 함께 볼 수 있다.
결론: 업데이트보다 되돌릴 수 있는 교체가 중요했다
지원 종료 서버를 발견했을 때 가장 위험한 선택은 아무것도 하지 않는 것만이 아니었다.
운영 중인 서버를 그 자리에서 크게 바꾸고 복구 대상을 없애는 일도 위험했다.
이번에는 새 환경을 병행 구축하고, 프로세스·데이터베이스·실제 메시지를 검증하고, 경로를 전환하고, 관찰 뒤 기존 환경을 철거하는 순서로 작업을 닫았다.
새 버전의 이름보다 먼저 전환 조건과 복귀 조건을 정했기 때문에 운영 경로를 잃지 않고 교체를 마칠 수 있었다.