Shipyard: Slackの次世代EC2プラットフォーム構築記

• Slackは、長期稼働するEC2を継続的に変更していく従来方式から、不変AMIベースの置き換えデプロイへ移行し、コンテナ化が難しいワークロードにもモダンなデプロイ手法を適用した
• 共通ベースイメージであるslack-zeroの上にサービス別イメージを積み重ね、重い構成処理はイメージのベイク時に行い、環境ごとのシークレットとメタデータだけを起動時に適用する
• デプロイオーケストレーターGondolaは、AMIとバージョン管理されたChefアーティファクトを1つのデプロイ単位として扱い、メトリクスベースの段階的デプロイ・停止・自動ロールバックを実行する
• 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更新にも適用する

• 複数アーキテクチャとOSのサポート

  • AMD64やARMベースのGravitonを含む複数のCPUアーキテクチャをサポートし、Ubuntu、RHEL、Amazon Linuxを利用できる
  • チームは別個のプラットフォーム実装なしに、コスト・性能・互換性に応じてインスタンスとOSを選択できる
  • 特に、コンテナへ移行しにくいインフラコンポーネント、Kubernetesワーカーノード、egressネットワークスタックに適している

• メトリクスベースの安全なデプロイ

  • 各サービスはGondolaと統合され、メトリクスベースの自動安全チェックを含む段階的ロールアウトを実行する
  • サービス状態シグナルに応じてデプロイを自動停止したり、直前の正常バージョンへ自動ロールバックしたりできる

• 高速で予測可能なプロビジョニング

  • コンテナに似たレイヤー型イメージ構造を採用し、共通のゴールデンベースイメージの上にサービス別イメージを構築する
  • 実行時の作業を減らすことで、複数リージョンでインスタンスが高速かつ一貫して起動する

• 単純化された構成管理

  • 従来は定期実行されるChefジョブが構成を継続的に検査して再適用し、手動変更や想定外の変更を望ましい状態へ戻していた
  • Shipyardでは、イメージベイクや初期プロビジョニングのような明確なライフサイクル段階でのみ構成を適用する
  • 構成管理ツールはシステム全体を継続的に変更するのではなく、主にサービスのデプロイに活用される
  • その結果、バックグラウンド負荷と意図しない上書きが減り、インスタンスが時間とともに変化し続けないため、挙動を推論しやすくなる

• 寿命が制限されたインスタンス

  • 各インスタンスに限定された寿命を与え、定期的に自動で置き換える
  • 潜在的な脆弱性が問題を起こしうる時間を短縮し、チームが実行中のインスタンスを修正する代わりに置き換えるよう促す

Peekabooインベントリとフリート全体の可視性

• Peekabooは、Chef Serverの代わりにクラウドイベントとインスタンスメタデータを使って、EC2フリートの状態をほぼリアルタイムで表示するインベントリシステムである
• Shipyard外でデプロイされたインスタンスも追跡し、フリート全体を一か所で確認できる
• AWS EventBridge、OpenSearch、Lambdaで構築されており、次のインターフェースを提供する
  • フリート探索用UI
  • システム統合用API
  • すばやいコマンドライン確認のためのCLI
• EC2情報を中央集約することで、環境全体のテレメトリと管理ポイントを一本化する

slack-zeroゴールデンベースイメージ

• slack-zeroは、Compute Platform Teamが作成し、SecurityチームとMonitoringチームが共同で管理する共通マシンイメージである
• すべてのサービスが継承する標準化された信頼性の高い土台であり、サービスチームはその上で独自のランタイム環境を構成する
• イメージには次の要素が含まれる
  • OSのベースラインとセキュリティ強化設定
  • ネットワーキングとサービスディスカバリの構成
  • モニタリングおよびセキュリティエージェント
  • 共通ツールと基盤システム構成
• ベースイメージは不変かつ一時的な対象として扱われる
  • セキュリティパッチ、モニタリング更新、ネットワーキング改善が必要になれば、新しいslack-zeroイメージを作成する
  • 下位のサービスイメージは新しいベース上で再ビルドされ、修正内容を継承する

• AWS Image Builderを選んだ理由

  • slack-zeroは、従来のPackerではなくAWS Image Builderで構築する
  • ライフサイクルポリシーが古いAMIを自動整理し、保存コストを削減する
  • 新しいイメージが生成されると、アカウントごとの最新AMIを指すAWS Systems Manager(SSM)パラメータを更新し、サービスパイプラインはそれを読んで最新ベースを利用する
  • イメージベイクが成功すると、EventBridgeとLambdaがサービスオーナーアカウントの下流パイプラインを自動で開始する
  • AMI公開前に一時インスタンスで検証テストを実行し、本番ロールアウトのリスクを低減する

サービスイメージのベイクとプロビジョニング

• 各サービスチームはslack-zeroをベースに独自のAMIを作成し、共通プラットフォームコンポーネントを継承しながらランタイム環境を制御する
• サービスイメージパイプラインは次の項目を定義する
  • インストールするソフトウェア
  • サービスの構成方法
  • そのサービスのインスタンス初期化手順
• 構成の大半をイメージに含めることで、実行速度と一貫性を高め、構成ドリフトを最小化する

• 2段階の役割分離

  • ベイク段階では、パッケージや環境間で共通の構成をインストールし、インスタンスが起動前からほぼ準備済みの正常状態を持つようにする
  • プロビジョニング段階では、起動時にシークレット、リージョン別構成、デプロイメタデータのような環境依存設定だけを適用する
  • 通常は、構成ファイル配置、シークレット取得、サービス起動だけを行う
  • パッケージインストールのような重い作業をベイクへ移すことで、インスタンスは数分ではなく数秒で起動できる
  • 高速起動はスケールイベント、段階的デプロイ、自動インスタンス置き換えで重要であり、最小限のプロビジョニングはランタイム適応過程で生じるドリフトを抑制する

AMI置き換え中心のフリート更新

• 変更は新しいAMIを作成した後、デプロイパイプラインでロールアウトし、既存インスタンスをパッチせずに制御された置き換えでフリートを更新する
• Auto Scaling Group(ASG)はAWS Instance Refreshを、KubernetesワーカーフリートはKarpenterを使用する
• 特別なデプロイ要件を持つサービスは別の実行基盤を追加でき、Gondolaが異なるパターンを一貫したデプロイ体験として統合する

• 緊急修正経路

  • 緊急時には、稼働中インスタンスに限定的な構成変更を適用できるが、その後は通常のデプロイパイプラインを通じて当該インスタンスを置き換える必要がある
  • AWS Systems Managerの事前定義ドキュメントで選択したChef recipeを実行し、緊急修正を適用する
  • システムが安定したら、インスタンスを入れ替えて意図した不変状態へ戻す

Gondolaの段階的デプロイ

• 顧客パイプラインは、サービスと運用要件に合わせた複数段階で構成できる
• 各Gondolaステージは、ASG、Kubernetesクラスター、EC2インスタンスグループといった1つのデプロイ単位を表す
• Egress Teamは各アベイラビリティゾーンにカナリア用と本番用のASGを別々に配置し、更新が順次流れるようステージを構成している
• Gondolaは各ステージを更新しながら主要メトリクスを監視し、問題が見つかれば自動ロールバックして障害の拡大を防ぐ

• デプロイアーティファクトと実行基盤

  • Gondolaが作成するデプロイパッケージは2つの要素で構成される
    • フリートにデプロイするAMI
    • Gitコミットと結び付いたバージョン指定recipeを含むChefアーティファクト
  • この2要素を1つのデプロイ単位として扱い、各ステージはサービスが定義した実行基盤を通じてロールアウトする
  • 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は、2種類の入力によって置き換え対象を決定する
  • セキュリティツールや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へストリーミングした後に終了し、開発者がデバッグのため保持することも選べる

• ベースレイヤー別のワーカーフリート

  • ブートストラップ構造のため、2つの別個のワーカーフリートを運用している
  • 基本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、イメージパイプライン、開発者ワークフロー、インベントリシステムの各コンポーネントや、プラットフォーム拡張の過程で生じた課題を別途取り上げる予定である