# Shipyard: Slack의 차세대 EC2 플랫폼 구축기 > Clean Markdown view of GeekNews topic #31846. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31846](https://news.hada.io/topic?id=31846) - GeekNews Markdown: [https://news.hada.io/topic/31846.md](https://news.hada.io/topic/31846.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-27T09:35:02+09:00 - Updated: 2026-07-27T09:35:02+09:00 - Original source: [slack.engineering](https://slack.engineering/shipyard-how-we-built-slacks-next-generation-ec2-platform/) - Points: 2 - Comments: 0 ## Topic Body - 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](https://slack.engineering/advancing-our-chef-infrastructure/)에서 확인할 수 있음 - 이후 분할된 프로덕션 환경, 신호 기반 Chef 실행, 개선된 롤아웃 방식을 도입해 팀이 cookbook을 다시 작성하지 않고도 장애의 **영향 범위**를 크게 줄였음 - [Safety Without Disruption](https://slack.engineering/advancing-our-chef-infrastructure-safety-without-disruption/) 단계에서는 레거시 플랫폼을 안정적으로 유지하면서 향후 구조를 계획할 여유를 확보함 - 그러나 장기 실행 인스턴스를 계속 업데이트하는 모델은 서비스 단위 배포가 어렵고 **인프라 드리프트**를 피할 수 없으며, 여러 계층의 변경을 조율할수록 복잡해졌음 - 컨테이너가 일부 워크로드의 문제를 해결했지만 모든 시스템을 쉽게 이전할 수는 없어, 불변성·단계적 배포·자동 안전장치를 EC2에 직접 적용할 플랫폼이 필요했음 ### Shipyard가 제공하는 EC2 운영 모델 - **Shipyard**는 인프라를 계속 수정할 인스턴스가 아니라 배포 가능한 아티팩트로 취급하는 Slack의 차세대 EC2 플랫폼임 - 서비스 단위 배포 기능을 빌드·오케스트레이션 시스템과 결합해, 애플리케이션 배포 플랫폼과 같은 수준의 안전성과 예측 가능성을 EC2 업데이트에 적용함 - ## 여러 아키텍처와 운영체제 지원 - AMD64와 ARM 기반 Graviton을 비롯한 여러 CPU 아키텍처를 지원하며 Ubuntu, RHEL, Amazon Linux를 사용할 수 있음 - 팀은 별도 플랫폼 구현 없이 비용·성능·호환성에 따라 인스턴스와 운영체제를 선택할 수 있음 - 특히 컨테이너로 이전하기 어려운 **인프라 구성요소**, Kubernetes 워커 노드, egress 네트워크 스택에 적합함 - ## 지표 기반의 안전한 배포 - 각 서비스는 Gondola와 통합돼 [지표 기반 자동 안전 검사](https://slack.engineering/the-scary-thing-about-automating-deploys/)를 포함한 단계적 롤아웃을 실행함 - 서비스 상태 신호에 따라 배포를 자동 중단하거나 이전의 정상 버전으로 **자동 롤백**할 수 있음 - ## 빠르고 예측 가능한 프로비저닝 - 컨테이너와 유사한 **계층형 이미지** 구조를 사용해 공통 골든 기반 이미지 위에 서비스별 이미지를 구축함 - 실행 시 수행할 작업을 줄여 여러 리전에서 인스턴스가 빠르고 일관되게 가동됨 - ## 단순화된 구성 관리 - 과거에는 예약된 Chef 작업이 구성을 주기적으로 검사하고 다시 적용해 수동 변경이나 예상 밖의 변경을 원하는 상태로 되돌렸음 - Shipyard에서는 이미지 베이킹과 초기 프로비저닝처럼 명확한 생명주기 단계에서만 구성을 적용함 - 구성 관리 도구는 전체 시스템을 계속 수정하기보다 주로 서비스를 배포하는 데 활용됨 - 이에 따라 백그라운드 부하와 의도하지 않은 덮어쓰기가 줄고, 인스턴스가 시간에 따라 계속 변하지 않아 동작을 추론하기 쉬워짐 - ## 수명이 제한된 인스턴스 - 각 인스턴스에 **제한된 수명**을 부여하고 정기적으로 자동 교체함 - 잠재적 취약점이 문제를 일으킬 수 있는 시간을 줄이고, 팀이 실행 중인 인스턴스를 수정하는 대신 교체하도록 유도함 ### Peekaboo 인벤토리와 전체 플릿 가시성 - **Peekaboo**는 Chef Server 대신 클라우드 이벤트와 인스턴스 메타데이터를 이용해 EC2 플릿 상태를 거의 실시간으로 보여주는 인벤토리 시스템임 - Shipyard 외부에서 배포된 인스턴스도 추적해 전체 플릿을 한곳에서 확인할 수 있음 - AWS EventBridge, OpenSearch, Lambda로 구축됐으며 다음 인터페이스를 제공함 - 플릿 탐색용 UI - 시스템 통합용 API - 빠른 명령줄 확인을 위한 CLI - EC2 정보를 중앙화해 환경 전반의 원격 측정과 관리 지점을 단일화함 ### slack-zero 골든 기반 이미지 - **slack-zero**는 Compute Platform Team이 만들고 보안·모니터링 팀과 공동 관리하는 공통 머신 이미지임 - 모든 서비스가 상속하는 표준화되고 신뢰할 수 있는 기반이며, 서비스 팀은 그 위에서 자체 런타임 환경을 구성함 - 이미지에는 다음 요소가 포함됨 - 운영체제 기준선과 보안 강화 설정 - 네트워킹과 서비스 디스커버리 구성 - 모니터링 및 보안 에이전트 - 공통 도구와 기반 시스템 구성 - 기반 이미지는 **불변이면서 일시적**인 대상으로 취급됨 - 보안 패치, 모니터링 업데이트, 네트워킹 개선이 필요하면 새 slack-zero 이미지를 만듦 - 하위 서비스 이미지는 새 기반 위에서 다시 빌드해 수정 사항을 상속함 - ## AWS Image Builder를 선택한 이유 - slack-zero는 이전의 Packer 대신 **AWS Image Builder**로 구축함 - 생명주기 정책이 오래된 AMI를 자동 정리해 저장 비용을 줄임 - 새 이미지가 생성될 때 계정별 최신 AMI를 가리키는 AWS Systems Manager(SSM) 파라미터를 갱신하며, 서비스 파이프라인은 이를 읽어 최신 기반을 사용함 - 이미지 베이킹이 성공하면 EventBridge와 Lambda가 서비스 소유자 계정의 하위 파이프라인을 자동으로 시작함 - AMI를 게시하기 전 임시 인스턴스에서 검증 테스트를 실행해 프로덕션 롤아웃 위험을 줄임 ### 서비스 이미지의 베이킹과 프로비저닝 - 각 서비스 팀은 slack-zero를 기반으로 자체 AMI를 만들며, 공통 플랫폼 구성요소를 상속하면서 런타임 환경을 통제함 - 서비스 이미지 파이프라인은 다음 항목을 정의함 - 설치할 소프트웨어 - 서비스 구성 방식 - 해당 서비스의 인스턴스 초기화 절차 - 대부분의 구성을 이미지에 포함해 실행 속도와 일관성을 높이고 **구성 드리프트**를 최소화함 - ## 두 단계의 역할 분리 - **베이킹 단계**에서는 패키지와 환경 간에 공통인 구성을 설치해, 인스턴스가 실행 전부터 대부분 준비된 정상 상태를 갖추도록 함 - **프로비저닝 단계**에서는 부팅 시 비밀정보, 리전별 구성, 배포 메타데이터처럼 환경에 종속된 설정만 적용함 - 일반적으로 구성 파일 배치, 비밀정보 조회, 서비스 시작만 수행함 - 패키지 설치 같은 무거운 작업을 베이킹으로 옮겨 인스턴스가 수 분이 아닌 **수 초 안에 가동**될 수 있음 - 빠른 시작은 확장 이벤트, 순차 배포, 자동 인스턴스 교체에 중요하며 최소 프로비저닝은 런타임 적응 과정에서 발생할 드리프트를 억제함 ### AMI 교체 중심의 플릿 업데이트 - 변경 사항은 새 AMI를 만든 뒤 배포 파이프라인으로 롤아웃하며, 기존 인스턴스를 패치하지 않고 **통제된 교체**로 플릿을 갱신함 - Auto Scaling Group(ASG)은 AWS Instance Refresh, Kubernetes 워커 플릿은 Karpenter를 사용함 - 특별한 배포 요구가 있는 서비스는 별도 실행기를 추가할 수 있으며, Gondola가 서로 다른 패턴을 일관된 배포 경험으로 통합함 - ## 긴급 수정 경로 - 긴급 상황에서는 실행 중인 인스턴스에 제한적인 구성 변경을 적용할 수 있지만, 이후 정상 배포 파이프라인을 통해 해당 인스턴스를 교체해야 함 - AWS Systems Manager의 사전 정의 문서로 선택한 Chef recipe를 실행해 **긴급 수정**을 적용함 - 시스템이 안정되면 인스턴스를 순환시켜 의도한 불변 상태로 복귀함 ### Gondola의 단계적 배포 - 고객 파이프라인은 서비스와 운영 요구에 맞춘 여러 단계로 구성할 수 있음 - 각 Gondola 단계는 ASG, Kubernetes 클러스터, EC2 인스턴스 그룹 같은 하나의 배포 단위를 나타냄 - Egress Team은 각 가용 영역에 카나리와 프로덕션 ASG를 따로 두고, 업데이트가 순차적으로 흐르도록 단계를 배치함 - Gondola는 각 단계를 갱신하면서 주요 지표를 감시하고, 문제가 발견되면 자동 롤백해 장애 확산을 막음 - ## 배포 아티팩트와 실행기 - Gondola가 만드는 배포 패키지는 두 부분으로 구성됨 - 플릿에 배포할 **AMI** - Git 커밋과 연결된 버전 지정 recipe를 담은 **Chef 아티팩트** - 두 요소를 하나의 배포 단위로 취급하며, 각 단계는 서비스가 정의한 실행기를 통해 롤아웃함 - ASG 배포에서는 실행기가 새 AMI와 구성으로 시작 템플릿을 갱신함 - Chef 코드는 Amazon S3에 패키징됨 - 새 인스턴스의 내장 부트스트래퍼가 올바른 아티팩트를 가져와 관련 recipe를 실행함 - 구성 메타데이터를 이용해 해당 역할에 맞는 설정만 적용함 - Kubernetes 워커 플릿에서는 실행기가 Karpenter에 사용할 AMI와 동일한 구성 메타데이터를 전달하며, 노드도 같은 방식으로 부트스트랩됨 - 특수 배포용 실행기를 추가해도 AMI, 버전 지정 구성 아티팩트, 메타데이터 기반 부트스트랩 방식은 그대로 유지됨 ### 플랫폼 팀과 서비스 팀의 책임 분담 - Compute·Security·Monitoring 팀은 기반 계층의 전역 인프라 구성요소, 보안 패치, 필수 설정을 관리함 - 서비스 팀은 그 기반 위에 자체 소프트웨어와 서비스별 설정을 추가한 AMI를 구축함 - Compute 팀이 보안 패치, 모니터링 에이전트, 네트워킹 변경을 배포하면 서비스 팀은 갱신된 기반 이미지를 자체 AMI에 반영해야 함 - 이 **공유 책임 모델**은 서비스별 자율성을 유지하면서 플릿의 일관성·보안·신뢰성을 맞춤 ### 완전한 불변성이 아닌 비밀정보 예외 - Shipyard 인스턴스의 패키지와 구성은 대부분 베이킹 시 고정되지만 **비밀정보**는 예외임 - 각 인스턴스의 Consul Template 서비스가 플릿을 교체하지 않고 Vault의 새 비밀정보를 배포함 - 자격증명이나 인증서는 동적으로 갱신할 수 있으므로 Shipyard는 핵심 시스템과 서비스 계층만 고정된 **반불변 인프라**임 - 안정성과 예측 가능성을 유지하면서 중요한 런타임 비밀정보를 필요할 때 갱신할 수 있음 ### The Reaper의 교체 정책 - **The Reaper**는 두 종류의 입력으로 교체 대상을 결정함 - 보안 도구나 AWS EC2 이벤트 등 외부 시스템이 인스턴스가 원하는 상태를 벗어났다고 보내는 오염 신호 - 허용된 최대 수명보다 오래 실행됐는지 확인하는 정기 검사 - 어느 조건이든 충족하면 서비스 정책에 따라 인스턴스 교체를 예약함 - 수동 원격 접속은 긴급 상황을 위해 허용되지만, 프로덕션급 노드에 직접 접속하면 신호가 발생해 해당 인스턴스가 향후 교체 대상으로 표시됨 - Peekaboo와 연동해 플릿 전체의 인스턴스 나이를 추적하며, 최대 수명에 도달한 노드는 같은 정상 종료·교체 절차를 따름 - 향후에는 소프트웨어 업데이트나 구성 드리프트처럼 **의미 있는 변경**만 교체를 일으키고, 읽기 전용 또는 저위험 작업은 불필요한 순환을 만들지 않도록 문맥 인식 기능을 추가할 계획임 - ## 교체 속도와 비상 통제 - 내장 속도 제한으로 한 번에 교체할 수 있는 인스턴스 수를 서비스·리전·가용 영역별로 정해 갑작스러운 용량 영향을 막음 - S3에 제어 객체를 배치하는 전역 일시정지 장치인 “**big red button**”으로 장애나 위험이 큰 기간에 모든 Reaper 활동을 중단할 수 있음 - CLI에서 속도 제한 관리, 구성 확인, 전역 일시정지 활성화와 해제를 수행함 - 심층 조사가 필요한 break-glass 상황에서는 수명이 짧은 SSH 인증서 같은 통제된 접근 방식을 사용할 수 있음 ### Ship Quick을 이용한 실제 인프라 테스트 - **Ship Quick**은 플랫폼 팀과 서비스 소유자가 pull request를 병합하기 전에 실제 인프라에서 현실적인 베이킹·프로비저닝 테스트를 실행하는 개발자 워크플로임 - 개발자는 cookbook 저장소에서 CLI 명령을 실행하고 YAML 파일로 테스트 사례를 정의함 - Ship Quick은 다음 순서로 처리함 - cookbook을 패키징해 S3에 업로드함 - 워크플로 메시지를 큐로 전송함 - Longshoremen이 관리하는 워커 인스턴스가 작업을 가져옴 - 워커가 Auto Scaling Group에서 분리돼 Chef 워크플로를 실행함 - 로그를 CLI로 스트리밍한 뒤 종료되며, 개발자가 디버깅을 위해 유지하도록 선택할 수도 있음 - ## 기반 계층별 워커 플릿 - 부트스트랩 구조 때문에 두 개의 별도 워커 플릿을 운영함 - **기본 Ubuntu 플릿**은 slack-zero가 자기 자신 위에서 빌드될 수 없으므로 깨끗한 Ubuntu AMI에서 기반 이미지를 베이킹하고 테스트함 - **slack-zero 플릿**은 사전 베이킹된 slack-zero에 의존하는 서비스 팀 cookbook을 테스트함 - 프로덕션과 같은 기반에서 프로비저닝을 검증함 - 최신 이미지로 계속 갱신돼 현재 프로덕션 환경을 반영함 - 두 플릿 모두 수요에 따라 자동 확장됨 - 자체 AWS 계정에서 이미지를 만드는 팀은 전용 워커 플릿을 구성하고 Ship Quick 작업을 해당 플릿으로 보내 격리를 유지할 수 있음 ### 장기 실행 워크로드로의 확장 - Shipyard는 현재 **단기 실행 서비스**에서 효과적으로 작동하며, 레거시 EC2 플랫폼의 팀을 계속 온보딩하고 있음 - 다음 과제는 빠르게 순환시킬 수 없는 장기 실행 인스턴스임 - Slack 데이터 노드 - GitHub Enterprise 같은 싱글턴 서비스 - Atlassian JIRA 같은 서드파티 비즈니스 기술 인스턴스 - 이런 워크로드에는 안전한 패치·업데이트 방식과 The Reaper가 올바르게 처리할 수 있는 생명주기 정책이 필요함 - 서비스 팀과 협력해 Gondola용 **장기 실행 워크로드 실행기**를 개발하고 있으며, 채택 범위가 커지면서 도구·개발자 워크플로·배포 경험을 계속 개선할 계획임 - 향후 Shipyard API, 이미지 파이프라인, 개발자 워크플로, 인벤토리 시스템의 구성요소와 플랫폼 확장 과정에서 발생한 문제를 별도로 다룰 예정임 ## Comments _No public comments on this page._