TL;DR

  • PAX는 예측 가능한 워크로드와 AWS의 간헐적 연결 문제를 고려해 Q3에 프로덕션을 자체 운영 서버로 이전했으며, 새 서버 운영 비용은 기존 AWS 구성보다 약 82% 낮음.
  • 새 환경은 전용 Linux 서버, PostgreSQL, Node 애플리케이션, Nginx, Cloudflare Tunnel로 구성되며, 테넌트별 데이터베이스와 런타임 구성은 기존과 동일함.
  • 하드웨어 장애에 대비해 암호화된 오프사이트 백업, 트랜잭션 로그 아카이브, 별도 소스·구성 파일 백업, 분리 보관 가능한 이동식 백업을 유지함.
  • 배포는 개발 워크스테이션의 단일 명령으로 테스트·빌드·패키징·SHA-256 매니페스트 생성을 거쳐 SSH로 전송되며, 테넌트별 헬스 체크를 통과한 릴리스만 적용됨.
  • 데이터베이스를 먼저 옮기고 라우팅을 바꾼 전환 작업은 저트래픽 시간대의 34분 점검 창에 완료됐으며, 관찰 기간에는 AWS 환경을 롤백용으로만 유지함.

이전을 결정한 배경

  • 기존 PAX는 애플리케이션을 EC2에서, PostgreSQL 데이터베이스를 RDS에서 운영했으며, 월 비용은 감당 가능한 수준이고 시스템도 대부분 정상 작동했지만 실제 워크로드는 유연한 용량을 거의 필요로 하지 않았음.
  • 사용자가 PAX에 접속하지 못하는 짧은 연결 단절이 반복됐지만 애플리케이션, 데이터베이스, 서버는 모두 정상으로 보고됐고, 조사 시점에는 사이트가 다시 작동하며 AWS에도 장애 기록이 없는 경우가 많았음.
  • 원인은 밝혀지지 않았으며 네트워크 경로, 구성, 여러 계층 간 상호작용 가운데 무엇이 문제였는지 로그와 메트릭으로 확인할 수 없었음.
  • AWS 구성은 애플리케이션 서버 한 대와 단일 가용 영역의 RDS 데이터베이스였음. 자동 백업과 특정 시점 복구는 이전 글에 설명한 대로 작동했지만, 자동 장애 조치에 대비해 두 번째 애플리케이션 서버와 데이터베이스를 유지하려면 더 크고 비용이 높은 구성이 필요했음.
  • PAX의 경우 완전히 이해할 수 있는 더 작은 시스템을 소유하고 운영하는 편이 합리적이라고 판단함.

현재 PAX 구성

  • PAX는 전용 Linux 서버에서 PostgreSQL, Node 애플리케이션, Nginx, 표준 시스템 서비스를 실행함.
  • 애플리케이션 앞단에는 Cloudflare가 계속 위치하며, Cloudflare Tunnel이 아웃바운드 연결을 통해 웹 트래픽을 전달하므로 애플리케이션과 데이터베이스에 공개 인바운드 포트가 필요하지 않음.
  • Cloudflare는 AWS에서 수행한 일부 네트워킹 작업과 비교해 사용하기가 매우 수월했음.
  • 테넌트 아키텍처는 기존과 동일함.
  • 각 회사는 자체 PostgreSQL 데이터베이스와 런타임 구성을 보유함.
  • PAX는 데이터베이스 쿼리 전에 테넌트를 식별해 회사별 데이터를 분리함.
  • 스택은 널리 쓰이고 문서화가 잘된 구성 요소로 이뤄져 있으며, 한 사람이 Cloudflare에서 애플리케이션을 거쳐 PostgreSQL까지 요청 흐름을 추적할 수 있음. 현재 PAX의 트래픽과 팀 규모에 맞는 구성임.

이중화와 복구 체계

  • 프로덕션은 물리 서버 한 대에서 실행되므로 하드웨어 장애가 발생하면 다른 장비에서 PAX를 복원해야 함. 복구에 필요한 자료는 두 곳 이상에 보관함.
  • PostgreSQL 데이터베이스는 암호화된 오프사이트 오브젝트 스토리지에 백업함.
  • 트랜잭션 로그를 지속적으로 아카이브함.
  • 정기 전체 백업과 차등 백업으로 여러 복구 시점을 확보함.
  • 소스 코드, 배포 파일, 비공개 구성, 로컬 Git 기록은 별도로 백업함.
  • 일반 파일과 논리 데이터베이스 내보내기를 포함한 암호화 이동식 백업도 보관함. 이 백업은 서버와 클라우드 계정에서 분리해 다른 장소에 둘 수 있음.
  • 전환 전에 별도 환경에서 데이터베이스를 복원해 데이터와 권한이 올바르게 복구되는지 확인했으며, 소스 및 구성 백업에서 파일도 복원함.
  • 해당 장소의 정전은 지금까지 몇 분을 넘긴 적이 없는 것으로 파악됨. UPS는 정전 중 추가 작동 시간을 제공하고 배터리 잔량이 낮아지면 서버를 정상 종료할 수 있음.
  • 로컬 모니터링은 PAX, 데이터베이스, 최신 백업의 경과 시간을 확인함.

더 단순해진 배포

  • AWS에서 운영하던 PAX는 GitHub 워크플로와 배포 웹훅을 사용했으며, 현재 배포는 개발 워크스테이션에서 단일 명령으로 시작함.
  • 워크스테이션을 떠나기 전에 명령이 집중 테스트를 실행하고 클라이언트를 빌드한 뒤 릴리스를 패키징하고 SHA-256 매니페스트를 생성함. 이후 SSH로 서버에 전송함.
  • 프로덕션 서버는 파일을 검증하고 각 테넌트에 별도의 런타임 트리를 준비함.
  • Nginx와 모든 테넌트의 헬스 체크를 통과한 릴리스만 승인함. 롤백을 위해 이전 릴리스 몇 개를 보관하며 오래된 빌드 파일은 자동으로 제거함.

전환 절차

  • 데이터베이스를 먼저 처리한 뒤 라우팅을 변경함.
  • AWS에서 프로덕션 쓰기를 동결하고 최종 RDS 스냅샷을 생성한 다음, 모든 프로덕션 데이터베이스를 내보내 검증하고 아카이브를 새 서버로 복사함.
  • 데이터베이스를 복원한 뒤 구조와 권한을 점검하고 새로운 오프사이트 백업을 만든 다음 PAX를 시작함. 액세스를 다시 열기 전에는 각 프로덕션 도메인을 테스트함.
  • 전환은 예정된 저트래픽 시간대에 진행됐으며 점검 창은 34분이었음.
  • 관찰 기간에는 기존 AWS 환경을 서비스에서 제외하고 롤백용으로만 보관함. 모든 프로덕션 쓰기는 새 서버에서 처리함.

운영 비용

  • 새 서버에서 PAX를 운영하는 비용은 기존 AWS 구성보다 약 82% 낮은 것으로 추산함.
  • 현재 지속적으로 발생하는 주요 비용은 전기료임.

얻은 점

  • 가장 큰 개선점은 가시성임. PAX가 어디에서 실행되는지 정확히 알고 하드웨어, 운영체제, 데이터베이스, 애플리케이션, 방화벽, 백업, 네트워크 경로를 직접 점검할 수 있음.
  • AWS에서 반복된 간헐적 연결 문제는 이와 반대되는 경험이었음. 모든 대시보드와 애플리케이션 로그가 정상으로 보여도 사용자가 PAX에 접속하지 못하는 경우가 있었고, 정상 모니터를 살펴보는 데 시간을 들여도 원인에 가까워지지 않았음.
  • 새 시스템은 소규모 팀이 처음부터 끝까지 이해할 수 있을 만큼 단순함. 시스템을 구축하고 문서화했으며 복원도 수행해, 예상치 못한 동작이 발생할 때 어디를 살펴봐야 하는지 파악하고 있음.