AWS Elastic Beanstalk에서 플랫폼 버전 변경 후 겪은 문제
7min read
Background
현재 AWS에서 제공하는 관리형 서비스인 Elastic Beanstalk(이하 EB)으로 서버 인스턴스들을 관리하고 있습니다.
EC2 인스턴스를 띄워서 하나하나 붙이는 것에 비해, EB는 웹 서비스의 API 서버를 운영할 때 필요한 공통 요소들을 통합해서 제공해줍니다.
이를테면 로드밸런서, 오토스케일링, 프록시 서버, 로깅, 배포 같은 서비스들입니다. 거의 모든 웹서비스들에서 필요한 기능들입니다.
이런 복잡한 리소스들을 생성하는 시점에 손쉽게 구성할 수 있어, 안정적인 서비스를 적은 비용으로 만들 수 있습니다.
이런 EB의 장점을 적절히 활용하면 API 서버 운영 오버헤드를 최소화 시킬 수 있습니다. 물론 규모가 작을 때의 이야기입니다.
자주 사용하는 언어 및 런타임(Java, Node.js, Docker 등)을 제공하고 있어 간단히 아키텍처를 테스트하는 용도로도 좋습니다.
이렇게 장점이 많은 EB이지만, 이번에 Node 플랫폼 버전을 업그레이드하면서 장점이 곧 단점이 될 수 있다는 것을 배웠습니다.
이런 의미에서 플랫폼의 버전을 업그레이드 하는 과정에서 겪은 장애를 기록했습니다.
Node 버전 업그레이드 이유
아래 두 이유로 Node 업그레이드가 필요했습니다.
- Elastic Beanstalk에서 Node 16 플랫폼 버전의 지원이 종료됐습니다.
- 버전 변경 과정에서 필요한 작업들 정리
1번 항목은 직접적인 교체 이유였지만 큰 부분은 아니었습니다. 16버전 사용에 비용이나 성능에 문제가 있었던 것은 아니었기 때문입니다. 당장 바꾸지 않아도 큰 문제는 없었습니다. 사실 3번이 가장 큰 관심사였습니다. 현재 아키텍처에서 버전 업그레이드를 진행하면 어떤 오버헤드가 발생하는지 파악할 필요가 있었습니다. 이후 이런 오버헤드를 줄여서, 더 변경하기 쉬운 아키텍처로 개선하는 것의 출발점으로 삼은 작업이었습니다.
플랫폼 버전 변경 과정
서비스 중단 없이 Elastic Beanstlak의 플랫폼 버전을 올리려면 블루그린 방식으로 진행하면 됩니다. 환경을 복제해서 새로운 인스턴스를 하나 더 만들고, 생성과 테스트가 완료되면 트래픽을 새 인스턴스로 옮기는 것입니다. 저희는 Route 53으로 도메인을 관리하고 있어서 Route 53에서 트래픽을 옮겨주면 되었습니다.
발생한 문제 - 로드밸런서 교체
Elastic Beanstalk의 환경을 처음 구성할 때 로드밸런서의 기본 설정은 해당 환경 전용으로 새로 생성해서 사용하는 것입니다.
따라서 기본 설정을 그대로 적용하면, 서비스 도메인에 레코드로 연결된 기존 로드밸런서(환경전용)들의 별칭을 새로 생성된 환경 전용의 로드밸런서로 바꿔주어야 했습니다.
문제는 이렇게 기존 환경 전용 ALB에 연결된 레코드들이 생각보다 많았고, 수작업으로 교체작업을 진행해야 했으므로 비효율적이었습니다.
심지어 기존 환경 ALB를 대상그룹으로 설정한 NLB가 있어서, 이 NLB의 대상그룹은 제때 교체되지 않아 해당 NLB로 들어오는 트래픽은 모두 오류가 발생했었습니다.
이처럼 Elastic Beanstalk 전용의 관리형 로드밸런서를 사용하면 이런 문제가 발생합니다.
로드밸런서를 자동으로 생성해주고 관리해주므로 오버헤드가 적지만, 환경 자체를 변경하는 수준의 변경사항이 생기는 경우 로드밸런서-환경 간 의존성이 있으므로 오류 대응이 어려워집니다.
EB에서 처음 구성할 때 전용 로드밸런서로 구축했다면 중간에 리소스 간에 공유되는 로드밸런서로 변경할 수 없습니다. 환경을 처음부터 다시 만들어야합니다.
EC2 대시보드에서 먼저 로드밸런서를 생성하고, 그 다음 Elastic Beanstalk 환경을 새로 구축할 때 만들어둔 로드밸런서를 연결하면 됩니다.
후기
사실 이렇게 외부 관리형 컴포넌트들을 하나씩 분리하다보면 결국 관리형 서비스를 사용하는 의미가 점점 희석되는 것 같긴 합니다. 그래도 서비스 초창기에 운영 오버헤드를 대폭 줄일 수 있고, 이후 필요한 시점에 점진적으로 분리해서 운영 방식을 개선시킬 수 있으므로 장기적인 관점에서는 사용 가치가 충분한 것 같습니다.