slack·2026년 7월 14일·5분 읽기큐레이션 요약

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를 계속 사용해야 하지만 컨테이너의 불변성, 계층형 이미지, 점진적 배포, 자동 롤백의 이점을 원하는 조직이라면 이와 같은 플랫폼 접근이 효과적이다.

원문 읽기(새 탭에서 열림)

chefAWSamazon-ec2opensearch+4

slack·2025년 10월 23일·3분 읽기큐레이션 요약

셰프 인프라 개선: 방해받지 않는 안전

Slack은 Chef Policyfiles로 전환하는 대신, 기존 cookbook과 role을 유지하면서 EC2 프로비저닝 구조를 개선하는 방식을 선택했다. 단일 프로덕션 환경을 `prod-1`부터 `prod-6`까지 분리하고, 카나리와 단계적 릴리스 트레인을 도입해 잘못된 변경의 영향 범위를 줄였다. 그 결과 대규모 확장이나 배포 중에도 문제를 조기에 발견하고 안전하게 롤백·수정할 수 있는 경로를 마련했다. ## Policyfiles 대신 기존 구조 개선 - Policyfiles를 도입하면 roles와 environments를 대체하고 여러 팀의 cookbook을 수정해야 했다. - 장기적으로는 안전성이 높아질 수 있지만, 단기적으로는 수십 개 팀의 대규모 작업과 새로운 변경 위험이 발생했다. - Slack은 기존 cookbook과 role을 변경하지 않고 EC2 프레임워크를 보강하는 방향을 택했다. ## 단일 프로덕션 환경의 위험 - 기존에는 모든 인스턴스가 하나의 `production` Chef environment를 공유했다. - 인스턴스별 cron 작업을 가용 영역(AZ)마다 분산해 Chef 실행 시점을 staggered 방식으로 조정했다. - 이 방식은 잘못된 변경이 전체 노드에 동시에 적용되는 것을 막아 주었지만, 새로 생성된 노드는 즉시 최신 변경을 가져갔다. - 따라서 대규모 scale-out 중 잘못된 cookbook 버전이 수십~수백 개의 새 노드에 한꺼번에 적용될 수 있었다. ## `prod-1`~`prod-6` 환경 분리 - 단일 production environment를 다음과 같이 6개 bucket으로 나눴다. - `prod-1` - `prod-2` - `prod-3` - `prod-4` - `prod-5` - `prod-6` - 서비스 팀은 계속 인스턴스를 “prod”로 실행하지만, 실제 Chef environment는 인스턴스의 AZ에 따라 결정된다. - 노드가 여러 환경에 균등하게 분산되므로 하나의 변경이 전체 프로덕션에 미치는 blast radius가 줄어든다. - 각 environment를 독립적으로 업데이트할 수 있어 특정 AZ 그룹만 대상으로 변경을 검증할 수 있다. ## Poptart Bootstrap의 역할 - Slack의 기본 AMI에는 부팅 시 실행되는 `Poptart Bootstrap` 도구가 포함되어 있다. - 주요 역할은 다음과 같다. - Chef node object 생성 - 필요한 DNS 레코드 설정 - 부팅 성공·실패 결과를 Slack 채널에 알림 - 환경 분리를 위해 노드의 AZ ID를 검사하고 해당 노드를 `prod-1`~`prod-6` 중 하나에 자동 배정하도록 확장했다. - 서비스 팀이 별도의 프로비저닝 방식을 학습하거나 cookbook을 수정하지 않아도 인프라 구조 변경을 적용할 수 있었다. ## 카나리 환경 `prod-1` - `prod-1`은 카나리 프로덕션 환경으로 사용된다. - 새 cookbook 변경이 있으면 매시간 최신 버전을 배포한다. - sandbox와 dev를 거친 변경을 실제 프로덕션 환경에서 작은 규모로 먼저 실행한다. - 모든 production 환경을 통과한 뒤에야 테스트하는 방식보다, 변경이 도입된 시점과 장애 발생 시점의 거리가 짧아 원인 추적이 쉽다. - 누적된 대규모 변경이 아니라 비교적 작은 단위의 artifact를 검증할 수 있다. ## `prod-2`~`prod-6`의 릴리스 트레인 - `prod-2`부터 `prod-6`까지는 순차적인 release train 방식으로 업데이트된다. - 새 버전을 `prod-2`에 배포하기 전, 기존 버전이 `prod-2`에서 `prod-6`까지 성공적으로 진행됐는지 확인한다. - 각 환경의 배포가 완료되어야 다음 단계가 진행되므로 회귀 문제가 전체 프로덕션으로 확산되는 것을 방지한다. - 여러 production environment가 항상 일정한 버전 순서를 유지하도록 설계되어 있다. ## 시간 기반 배포 흐름 - 매시 정각에 최신 cookbook 변경을 sandbox에 반영한다. - 이후 Kubernetes CronJob이 dev 환경으로 변경을 진행한다. - 매시 30분부터 production rollout이 시작된다. - 예를 들어 artifact A가 생성되면: - 정각: sandbox와 dev가 A로 업데이트 - 30분: `prod-1`이 A를 받아 카나리 테스트 - 이후: `prod-2`부터 `prod-6`까지 단계적으로 A를 적용 - 그 사이 새 변경으로 artifact B, C가 생성되더라도 기존 릴리스 트레인의 진행 상태를 고려해 순차적으로 배포한다. 실용적으로는 기존 배포 시스템을 전면 교체하기보다, 환경 분리·카나리·단계적 rollout처럼 변경의 영향 범위를 줄이는 장치를 먼저 도입하는 것이 효과적이다. 특히 대규모 인프라에서는 새 노드가 어떤 버전을 자동으로 받는지와, 실패한 변경이 어디까지 확산될 수 있는지를 별도로 통제해야 한다.

원문 읽기(새 탭에서 열림)

chef쿠버네티스aws-ec2canary-deployment+3

datadog·2017년 8월 23일원문

Vagrant와 Terraform으로 지원 확장 (새 탭에서 열림)

Datadog의 솔루션 팀은 고객이 사용하는 다양한 기술 스택과 복잡한 인프라 환경에서 발생하는 문제를 정확히 재현하기 위해 Vagrant와 Terraform을 활용한 자동화된 샌드박스 시스템을 구축했습니다. 인프라 구축 과정을 코드화하여 팀 전체가 공유함으로써, 개별 엔지니어가 생소한 기술을 매번 처음부터 학습하고 설치해야 하는 비효율을 제거하고 문제 해결 속도를 획기적으로 높였습니다. 결과적으로 로컬 가상 머신과 클라우드 인스턴스를 자유롭게 오가는 유연한 디버깅 환경을 통해 팀 간 협업과 고객 지원의 품질을 극대화할 수 있었습니다. **Vagrant 프로비저닝을 통한 환경 구축 자동화** * 고객의 특정 OS, 커널 버전, 복잡한 통합 도구(Kafka, MS SQL, RabbitMQ 등)를 수동으로 설치하는 것은 시간이 많이 걸리고 오류가 발생하기 쉽습니다. * Vagrant의 '프로비저닝(Provisioning)' 기능을 활용하여, 인프라 설치 및 설정에 필요한 모든 명령어를 `setup.sh`와 같은 쉘 스크립트에 담아 자동화했습니다. * 한 번 작성된 프로비저닝 스크립트는 팀 공용 GitHub 저장소에 저장되어, 다른 팀원들이 동일한 이슈를 처리할 때 `vagrant up` 명령어 하나만으로 즉시 동일한 환경을 갖출 수 있게 합니다. **샌드박스 저장소의 구조화 및 유연성 확보** * 저장소는 운영체제와 배포판, 서비스 이름에 따라 계층적으로 디렉토리를 나누어 관리하며, 각 디렉토리에는 `Vagrantfile`, `setup.sh`, 그리고 설정 파일 등이 담긴 `/data` 폴더를 포함합니다. * 엔지니어 개인별로 달라야 하는 설정(호스트 이름, API 키, 태그 등)은 `.sandbox.conf.sh`라는 로컬 설정 파일에 분리하여 관리함으로써 스크립트의 범용성을 유지합니다. * 이를 통해 새로운 환경이 필요할 때 기존 템플릿을 복사하여 빠르게 변형할 수 있으며, 팀 내 기술적 노하우가 코드를 통해 자연스럽게 축적됩니다. **Terraform을 이용한 클라우드 확장 및 협업** * 로컬 가상 머신 사용 시 발생하는 RAM 자원 부족 문제를 해결하고 팀원 간 환경을 쉽게 공유하기 위해 Terraform을 도입하여 AWS EC2 인스턴스를 활용합니다. * Vagrant에서 사용하던 `setup.sh`와 `/data` 파일을 그대로 재사용하면서, 인스턴스 생성을 위한 `.tf` 파일만 추가하여 로컬과 클라우드 환경 간의 일관성을 유지합니다. * 클라우드 기반 샌드박스를 활용하면 여러 시간대의 팀원들이 동일한 원격 환경에 접속해 조사를 이어갈 수 있으며, 고객과의 실시간 상담 중에도 미리 준비된 환경을 즉시 배포하여 대응할 수 있습니다. **실용적인 결론** 반복적인 환경 구축이 필요한 기술 지원이나 개발 팀이라면 인프라를 코드로 관리(IaC)하는 것이 필수적입니다. Vagrant로 로컬에서 가볍게 시작하되, 동일한 프로비저닝 스크립트를 Terraform과 공유할 수 있도록 설계하면 로컬의 편의성과 클라우드의 협업 능력을 동시에 잡을 수 있습니다. 특히 `setup.sh`와 같은 범용 스크립트를 중심에 두면 도구가 바뀌어도 재사용성을 높일 수 있습니다.

chefPostgreSQLDocker & 컨테이너Terraform+4