Slack은 왜 EC2를 고치지 않고 통째로 바꾸기 시작했을까요

Slack은 왜 EC2를 고치지 않고 통째로 바꾸기 시작했을까요

Slack Shipyard EC2 플랫폼 썸네일

수만 대의 EC2를 오래 켜 둔 채 설정을 계속 덧대면 서버마다 상태가 달라져요. Slack은 이 문제를 줄이려고 실행 중인 서버를 고치는 방식에서 새 AMI로 서버를 교체하는 방식으로 옮겼어요. Shipyard는 컨테이너로 옮기기 어려운 워크로드에도 불변 인프라와 단계적 배포를 적용한 플랫폼이에요. 1 2

핵심 요약

구분	Slack이 택한 방식	운영에서 얻는 효과
서버 상태	실행 중인 EC2를 반복 수정하지 않고 새 AMI로 교체해요	서버마다 설정이 달라지는 구성 드리프트를 줄여요
이미지 구조	공통 기반 이미지 `slack-zero` 위에 서비스별 이미지를 쌓아요	보안·관측·네트워크 기준을 공통으로 유지해요
배포	Gondola가 지표를 보며 단계별로 교체해요	이상 징후가 생기면 중단하거나 이전 버전으로 되돌려요
인벤토리	Peekaboo가 전체 EC2 상태를 거의 실시간으로 모아요	Shipyard 밖에서 만든 인스턴스까지 한곳에서 확인해요
수명 관리	The Reaper가 오래됐거나 오염된 인스턴스를 교체해요	취약한 상태가 장기간 남을 가능성을 낮춰요

1. EC2를 계속 고치는 대신 새 이미지로 교체해요

Slack의 기존 환경에서는 Chef가 장기 실행 인스턴스의 설정을 주기적으로 확인하고 원하는 상태로 되돌렸어요. 운영 규모가 커지자 서비스 단위 배포가 복잡해졌고, 여러 계층의 변경을 맞추는 일도 어려워졌어요. 수동 변경과 시간 차이 때문에 서버 상태가 조금씩 달라지는 구성 드리프트도 남았어요. 2

Shipyard는 EC2를 계속 손보는 서버가 아니라 버전이 붙은 배포 아티팩트로 다뤄요. 패키지 설치와 공통 설정처럼 무거운 작업은 AMI를 만드는 단계에서 끝내요. 인스턴스가 켜질 때는 비밀정보, 리전별 설정, 배포 메타데이터만 적용해요. Slack 설명에 따르면 이 구조에서는 인스턴스가 수 분이 아니라 수 초 안에 준비될 수 있어요. 2

slack-zero가 공통 기준선을 만들어요

모든 서비스 이미지는 `slack-zero`라는 골든 베이스 이미지에서 출발해요. 운영체제 보안 기준, 네트워크와 서비스 디스커버리 설정, 모니터링·보안 에이전트, 공통 도구가 이 이미지에 들어가요. 플랫폼 팀이 기반 이미지를 갱신하면 서비스 팀은 새 기반 위에서 자신의 AMI를 다시 만들어요.

728x90

Slack은 기존 Packer 대신 AWS Image Builder를 사용해요. 오래된 AMI 정리, 최신 이미지의 SSM 파라미터 등록, EventBridge와 Lambda를 통한 하위 파이프라인 실행, 게시 전 임시 인스턴스 검증을 한 흐름에 묶었어요. 서비스 팀은 공통 기준을 물려받으면서도 런타임과 서비스별 설정을 직접 관리해요.

완전한 불변성보다 운영 가능한 경계를 골랐어요

Shipyard는 실행 중인 모든 값을 고정하지 않아요. Vault에 있는 자격증명과 인증서는 Consul Template을 통해 갱신해요. 패키지와 핵심 설정은 이미지에 고정하고, 수명이 짧은 비밀정보는 런타임에 바꿀 수 있게 나눴어요. 불변 인프라 원칙을 지키면서 자격증명 교체까지 서버 재배포에 묶지 않은 선택이에요.

Gondola가 교체 순서와 안전장치를 맡아요

Gondola는 AMI와 특정 Git 커밋에 연결된 Chef 아티팩트를 하나의 배포 단위로 관리해요. Auto Scaling Group, Kubernetes 클러스터, EC2 그룹을 단계별 배포 대상으로 구성할 수 있어요. 각 단계에서 서비스 지표를 확인하고 문제가 감지되면 다음 단계로 넘어가지 않거나 이전 정상 버전으로 되돌려요.

실제 교체 방식은 워크로드에 맞춰 달라져요. Auto Scaling Group은 AWS Instance Refresh를 사용하고, Kubernetes 워커는 Karpenter에 새 AMI와 구성 메타데이터를 전달해요. 특수한 서비스는 별도 실행기를 붙일 수 있지만, 버전이 정해진 이미지와 구성 아티팩트를 함께 옮긴다는 원칙은 같아요.

Peekaboo와 The Reaper가 플릿 상태를 연결해요

Peekaboo는 AWS EventBridge, OpenSearch, Lambda를 이용해 EC2 인벤토리를 만들어요. Chef Server만 바라보지 않고 클라우드 이벤트와 인스턴스 메타데이터를 수집해요. Shipyard를 거치지 않은 인스턴스도 추적하며 UI, API, CLI에서 같은 인벤토리를 볼 수 있어요.

The Reaper는 보안 도구가 보낸 오염 신호와 인스턴스의 최대 수명을 확인해 교체 대상을 정해요. 운영자가 프로덕션 노드에 직접 접속한 경우도 교체 신호로 남길 수 있어요. 교체 속도는 서비스·리전·가용 영역별로 제한하고, 문제가 생기면 S3의 제어 객체로 전체 동작을 멈출 수 있어요. 대규모 자동 교체가 한꺼번에 용량을 줄이지 않도록 제동 장치를 따로 둔 셈이에요.

모든 EC2를 같은 속도로 바꿀 수는 없어요

현재 구조는 빠르게 교체할 수 있는 서비스에 잘 맞아요. 데이터 노드, GitHub Enterprise 같은 단일 인스턴스 서비스, Atlassian JIRA처럼 교체가 까다로운 장기 실행 워크로드에는 별도 패치 절차와 생명주기 정책이 필요해요. Slack도 이를 다음 과제로 남겨 뒀어요. 1

그래서 Shipyard를 그대로 복제하기보다 워크로드를 먼저 나눠야 해요. 상태가 외부 저장소에 있고 여러 인스턴스로 분산된 서비스는 이미지 교체가 쉬워요. 로컬 상태가 크거나 단일 노드 의존성이 높은 시스템은 백업, 복구 시간, 순차 교체 가능 범위를 따로 설계해야 해요.

왜 중요한가요

Shipyard 사례는 컨테이너 전환이 어려운 EC2도 이미지 빌드, 단계적 배포, 지표 기반 중단, 자동 롤백을 묶으면 애플리케이션과 비슷한 방식으로 운영할 수 있다는 점을 보여줘요. 핵심은 AMI 하나가 아니에요. 공통 기반 이미지의 소유권, 서비스별 이미지 빌드, 배포 오케스트레이션, 전체 인벤토리, 수명 만료 정책이 함께 움직여야 해요. 2

도입 전에 확인할 기준도 구체적이에요. 인스턴스를 교체해도 데이터가 보존되는지, 상태 지표가 롤백 판단에 충분한지, 새 기반 이미지가 서비스 이미지로 전달되는지, 긴급 수정 뒤 정상 이미지로 복귀하는지가 먼저예요. 이 연결이 빠지면 불변 AMI를 만들어도 오래된 인스턴스와 예외 설정이 다시 쌓일 수 있어요.

참고 자료

1. Shipyard: Slack의 차세대 EC2 플랫폼 구축기 — GeekNews
2. Shipyard: How We Built Slack’s Next-Generation EC2 Platform — Slack Engineering