Shipyard: Slack의 차세대 EC2 플랫폼 구축기

Slack은 장기 실행 EC2를 계속 수정하던 기존 방식에서 불변 AMI 기반 교체 배포로 전환해, 컨테이너로 옮기기 어려운 워크로드에도 현대적인 배포 방식을 적용함 공통 기반 이미지인 slack-zero 위에 서비스별 이미지를 쌓고, 무거운 구성은 이미지 베이킹에서 처리하며 환경별 비밀정보와 메타데이터만 부팅 시 적용함 배포 오케스트레이터 Gondola는 AMI와 버전이 지정된 Chef 아티팩트를 하나의 배포 단위로 관리하고, 지표 기반 단계적 배포·중단·자동 롤백을 수행함 Peekaboo는 전체 EC2 인벤토리를 거의 실시간으로 제공하고, The Reaper는 오염되거나 수명이 지난 인스턴스를 속도 제한과 일시정지 장치 아래 교체함 단기 실행 서비스에는 효과적이지만 데이터 노드, GitHub Enterprise, Atlassian JIRA처럼 빠르게 교체할 수 없는 장기 실행 인스턴스에는 별도의 패치 방식과 배포 실행기가 필요함 지속적으로 수정하는 EC2 모델의 한계 Slack은 기존 단일 Chef 스택을 복원력 있는 다중 스택 구조로 바꾸고, 버전이 지정된 cookbook 배포와 안전한 승격 절차를 도입해 수만 대의 EC2 인스턴스에 대한 신뢰성과 운영 통제력을 높였음 관련 과정은 Advancing Our Chef Infrastructure에서 확인할 수 있음 이후 분할된 프로덕션 환경, 신호 기반 Chef 실행, 개선된 롤아웃 방식을 도입해 팀이 cookbook을 다시 작성하지 않고도 장애의 영향 범위를 크게 줄였음 Safety Without Disruption 단계에서는 레거시 플랫폼을 안정적으로 유지하면서 향후 구조를 계획할 여유를 확보함 그러나 장기 실행 인스턴스를 계속 업데이트하는 모델은 서비스 단위 배포가 어렵고 인프라 드리프트를 피할 수 없으며, 여러 계층의 변경을 조율할수록 복잡해졌음 컨테이너가 일부 워크로드의 문제를 해결했지만 모든 시스템을 쉽게 이전할 수는 없어, 불변성·단계적 배포·자동 안전장치를 EC2에 직접 적용할 플랫폼이 필요했음 Shipyard가 제공하는 EC2 운영 모델 Shipyard는 인프라를 계속 수정할 인스턴스가 아니라 배포 가능한 아티팩트로 취급하는 Slack의 차세대 EC2 플랫폼임 서비스 단위 배포 기능을 빌드·오케스트레이션 시스템과 결합해, 애플리케이션 배포 플랫폼과 같은 수준의 안전성과 예측 가능성을 EC2 업데이트에 적용함 여러 아키텍처와 운영체제 지원 AMD...