Shipyard: Slack의 차세대 EC2 플랫폼을 구축한 방법
Slack은 장기 실행 EC2 인스턴스를 지속적으로 수정하는 기존 운영 방식의 한계를 해결하기 위해 차세대 EC2 플랫폼인 Shipyard를 구축했다. Shipyard는 EC2를 계속 변경되는 서버가 아니라 빌드·배포 가능한 불변 아티팩트로 다루며, 점진적 배포와 메트릭 기반 자동 중단·롤백을 지원한다. 이를 통해 컨테이너로 전환하기 어려운 워크로드에도 현대적인 배포 안정성과 예측 가능성을 제공한다. ## 기존 EC2 운영 방식의 한계 - Chef 기반으로 장기간 실행되는 인스턴스를 계속 업데이트하는 방식은 다음 문제를 낳았다. - 서비스 단위 배포가 복잡함 - 인프라 드리프트가 시간이 지날수록 누적됨 - 여러 계층의 변경 사항을 조율해야 함 - 수동 변경과 자동 설정 적용이 충돌할 수 있음 - Slack은 기존 Chef 환경을 다중 스택, 버전 관리, 분리된 프로덕션 환경, 신호 기반 실행 등으로 개선했지만 근본적인 구조적 한계는 남아 있었다. - 컨테이너가 일부 문제를 해결했지만 인프라 컴포넌트, Kubernetes 워커 노드, egress 네트워크 스택 등은 쉽게 컨테이너화하기 어려웠다. ## Shipyard의 핵심 방향 - 인스턴스를 지속적으로 수정하는 대신 이미지와 배포 산출물을 중심으로 운영한다. - 서비스 단위 배포 기능을 제공해 애플리케이션 배포와 유사한 방식으로 EC2 인프라를 관리한다. - 빌드 파이프라인, 배포 오케스트레이션, 자동 안전 장치를 긴밀하게 연동한다. - 인프라 변경을 불변성, 점진적 롤아웃, 자동화된 안전 검증을 갖춘 배포 과정으로 전환한다. ## 멀티 아키텍처와 멀티 운영체제 - AMD64와 ARM 기반 AWS Graviton 인스턴스를 모두 지원한다. - Ubuntu, RHEL, Amazon Linux 등 여러 운영체제를 사용할 수 있다. - 비용, 성능, 호환성에 따라 서비스별 실행 환경을 선택할 수 있다. - 컨테이너 전환이 어려운 다양한 EC2 워크로드를 동일한 플랫폼에서 운영할 수 있다. ## 메트릭 기반 점진적 배포 - Shipyard는 Slack의 배포 오케스트레이션 시스템인 Gondola와 통합된다. - 배포 과정에서 서비스 상태 지표를 기반으로 자동 안전 검사를 수행한다. - 오류율, 성능 저하 등 서비스 헬스 신호가 나빠지면 배포를 자동으로 중단할 수 있다. - 문제가 발생하면 이전의 정상 버전으로 자동 롤백할 수 있다. - 따라서 배포 실패의 영향 범위를 줄이고, 운영자의 수동 판단 의존도를 낮춘다. ## 계층형 이미지와 빠른 프로비저닝 - 컨테이너 이미지와 유사한 계층형 이미지 구조를 사용한다. - 공통 인프라 요소를 포함한 골든 베이스 이미지를 먼저 만들고, 그 위에 서비스별 이미지를 쌓는다. - 인스턴스 시작 시 수행해야 할 작업을 줄여 리전 간에도 빠르고 예측 가능한 프로비저닝이 가능하다. - 실행 시점에 많은 설정을 적용하던 기존 방식보다 부팅 과정의 변동성이 작다. ## 설정 관리 방식의 변화 - 기존에는 실행 중인 인스턴스가 주기적으로 Chef 작업을 실행해 설정을 확인하고 원하는 상태로 되돌렸다. - Shipyard에서는 이미지 생성과 초기 프로비저닝 같은 명확한 수명 주기 단계에서 설정을 적용한다. - 설정 관리 도구는 시스템 전체를 계속 수정하기보다 서비스 배포에 집중한다. - 이 방식의 장점은 다음과 같다. - 백그라운드 작업 부하 감소 - 수동 변경의 의도치 않은 덮어쓰기 방지 - 시간이 지나면서 인스턴스 상태가 달라지는 현상 감소 - 시스템 동작과 장애 원인 분석의 단순화 ## Peekaboo 기반 실시간 인벤토리 - Shipyard는 EC2 플릿을 거의 실시간으로 확인하기 위한 인벤토리 시스템 Peekaboo를 제공한다. - 기존처럼 Chef Server를 단일 정보 원천으로 사용하지 않고 AWS 이벤트와 인스턴스 메타데이터를 직접 활용한다. - Shipyard로 배포되지 않은 인스턴스도 추적해 전체 EC2 플릿을 한곳에서 확인할 수 있다. - AWS EventBridge, OpenSearch, Lambda를 기반으로 구축되었다. - UI, API, CLI를 제공해 다음 작업을 지원한다. - 전체 인스턴스 상태 탐색 - 다른 시스템과의 통합 - 명령줄에서 빠른 상태 확인 - 중앙화된 가시성을 통해 어떤 인스턴스가 어디에 있고 어떤 상태인지 파악하기 쉬워진다. ## 짧은 수명의 불변 인스턴스 - 각 EC2 인스턴스에 제한된 수명을 부여하고 정기적으로 자동 교체한다. - 인스턴스를 직접 수정해 오래 유지하기보다 새 이미지를 배포해 교체하는 방식을 채택한다. - 보안 취약점이 노출된 채 남아 있는 시간을 줄일 수 있다. - 운영팀은 개별 서버를 고치는 대신 최신 이미지를 기반으로 인스턴스를 재생성하는 데 집중한다. - 결과적으로 EC2 플릿의 상태를 지속적으로 신선하게 유지할 수 있다. ## Golden Base Image인 slack-zero - Shipyard의 기반에는 Slack Compute Platform Team이 관리하는 공통 이미지 `slack-zero`가 있다. - 보안 및 모니터링 팀과 협력해 표준화된 기반 환경을 유지한다. - 포함 내용: - 운영체제 기본 설정과 보안 강화 - 네트워크 및 서비스 디스커버리 설정 - 모니터링·보안 에이전트 - 공통 도구와 기반 시스템 설정 - 서비스는 `slack-zero`를 기반으로 필요한 런타임과 애플리케이션 요소를 추가한다. - 기반 이미지는 불변이지만 영구적으로 유지하지는 않는다. - 보안 패치, 모니터링 업데이트, 네트워크 개선이 필요하면 새 이미지를 생성한다. - 서비스 이미지는 최신 `slack-zero`를 기반으로 다시 빌드해 변경 사항을 상속한다. ## AWS Image Builder 활용 - Slack은 기존 Packer 대신 AWS Image Builder를 사용해 `slack-zero`를 생성한다. - AWS Image Builder의 장점으로 다음이 언급된다. - 수명 주기 정책을 통한 오래된 AMI 자동 정리 - AMI 저장 비용 절감 - 새 이미지가 생성될 때 SSM Parameter에 최신 AMI 정보를 게시 - 이를 통해 서비스 이미지 빌드와 인스턴스 교체 과정에서 최신 기반 이미지를 일관되게 참조할 수 있다. Shipyard의 핵심은 EC2를 수동으로 계속 관리하는 서버가 아니라, 버전이 지정된 이미지로 빌드하고 안전하게 교체하는 배포 대상으로 바꾸는 데 있다. EC2를 계속 사용해야 하지만 컨테이너의 불변성, 계층형 이미지, 점진적 배포, 자동 롤백의 이점을 원하는 조직이라면 이와 같은 플랫폼 접근이 효과적이다.
원문 읽기(새 탭에서 열림)