Mythex 서버를 ARM으로 옮긴 이유

9월 19일, 우리는 Mythex의 프로덕션 백엔드를 x86 서버에서 더 작은 ARM 기반 AWS Graviton 서버로 옮겼고, 플랫폼 데이터베이스도 Graviton 인스턴스로 옮겼습니다. 계기는 간단했습니다. 각 사용자의 앱을 실행하고 빌드하는 무거운 작업을 격리된 프로젝트별 샌드박스로 옮긴 뒤, 우리의 주요 서버는 메모리의 약 3분의 1 정도만 사용했습니다. 더 작은 ARM 머신이 실제 부하에 맞았고, 월 서버 비용은 약 30% 줄었습니다.

지금 우리 서버가 하는 일

초기에는 백엔드 서버가 많은 일을 직접 했습니다. 9월 중순쯤 우리는 비싼 부분을 — 프로젝트별 코드 실행, 패키지 설치, 앱 빌드 — 비공개 클라우드 샌드박스, 프로젝트당 하나로 옮기는 작업을 마쳤습니다. 이것이 각 프로젝트에 격리된 환경과 라이브 미리보기를 제공하는 방식이기도 합니다.

우리 서버에 남은 것은 조율입니다. API, 샌드박스와 게시를 관리하는 오케스트레이터, 인증, 청구, 게이트웨이입니다. 이 작업은 꾸준하고 가볍습니다. 이동 후 서버는 약 3배 용량의 머신에서 약 1.3GB의 메모리 피크를 보였습니다.

왜 ARM인가

AWS의 Graviton 프로세서는 AWS가 설계한 ARM 칩입니다. 같은 비용으로 비슷한 x86 인스턴스보다 대개 더 많은 용량을 얻거나, 같은 용량을 더 적은 비용으로 얻을 수 있습니다. 우리 작업 부하(Node.js 서비스, Docker, Postgres)에는 x86에 묶여 있을 이유가 없습니다.

우리는 다음을 옮겼습니다.

앱 서버 두 대: 중형 x86 인스턴스에서 RAM 2GB짜리 작은 Graviton 인스턴스로.
플랫폼 데이터베이스: 작은 x86 데이터베이스 인스턴스에서 그에 해당하는 Graviton 인스턴스로.

한 가지 실제 복잡성: 두 아키텍처용 이미지

우리 스테이징 환경은 여전히 작은 x86 서버에서 실행됩니다. 프로덕션은 이제 ARM에서 실행됩니다. 한쪽용으로 빌드된 컨테이너 이미지는 다른 쪽에서 실행되지 않습니다.

그래서 이제 모든 이미지는 하나의 태그 아래 두 아키텍처용으로 빌드됩니다. 멀티 아키텍처 이미지입니다. Docker는 각 머신에서 맞는 변형을 자동으로 고르며, 배포 파이프라인은 어느 환경에 푸시하는지 알 필요가 없습니다. 대가는 CI 빌드가 길어지는 것이고, 이득은 스테이징과 프로덕션이 정확히 같은 태그에서 정확히 같은 코드를 실행한다는 것입니다.

이동 전에 롤백 계획 세우기

라이브 서비스 아래에서 CPU 아키텍처를 바꾸는 것은 몇 분 안에 되돌릴 수 있어야 하는 종류의 변경입니다. 전환하기 전에 우리는 다음을 했습니다.

이전 서버 템플릿 버전을 이름 붙은 롤백 대상으로 보관했습니다.
데이터베이스 크기를 조정하기 직전에 데이터베이스 스냅샷을 찍었습니다.
이동과 되돌리는 방법을 다루는 런북을 작성했습니다.

롤백이 필요하지 않았습니다. 그래도 같은 방식으로 다시 할 것입니다.

주의해서 볼 것

더 작은 서버는 여유가 적습니다. 그래서 두 가지가 따라옵니다.

무거운 작업이 이 서버들로 다시 옮겨진다면, 2GB로는 부족합니다. 그때의 해결책은 x86으로 돌아가는 것이 아니라 더 큰 Graviton 사이즈입니다.
작은 머신에는 스왑이 필요합니다. 일주일 뒤 이 서버 중 하나가 기술적으로 메모리가 바닥나지 않았는데도 메모리 압박으로 멈췄습니다. 누락된 스왑 파일 이야기를 참고하세요.

우리가 얻은 교훈

아키텍처를 바꾼 뒤에는 다시 측정하세요. 작업을 샌드박스로 옮기면서 서버가 필요로 하는 것이 바뀌었는데, 인스턴스 크기는 그것을 따라가지 못했습니다.
멀티 아키텍처 이미지만 있다면, ARM은 일반적인 웹 스택에 위험이 낮은 이득입니다.
롤백을 먼저 작성하세요. 실제로 쓰지 않더라도 변경을 훨씬 차분하게 만들어 줍니다.