Amazon Web Services ブログ

Karpenter を採用することで Slack はどのように業務効率とコスト効率を高めたか

この記事は How Slack adopted Karpenter to increase Operational and Cost Efficiency (記事公開日: 2024 年 5 月 3 日) を翻訳したものです。

Bedrock – Slack の内部 Kubernetes プラットフォーム

Slack は人々、会話、アプリ、システムを 1 つの場所につなぐ AI を活用した業務用のプラットフォームです。Slack は、コンテナのデプロイや管理をシンプルにするために、”Bedrock” というコードネームの内部コンピューティングオーケストレーションプラットフォームを Amazon Elastic Kubernetes Service (Amazon EKS) を採用して構築しました。Bedrock は、単一の YAML ファイルでビルド、デプロイ、ランタイム環境を処理することで、Slack 内部の開発者の複雑さを大幅に軽減しています。また、Jenkins、FQDN サービスディスカバリー、Nebula overlay network などのツールを活用して効率的な運用を実現しています。Slack のアプリケーションの 80% 以上が Bedrock で稼働しており、テストの精度が向上し、インフラストラクチャの管理が洗練されたことで、開発者はより効率的に作業できるようになりました。

この投稿では、Slack がどのようにして Amazon EKS でコンテナプラットフォームをモダナイズし、Karpenter を活用してどのようにコスト削減と運用効率の改善を実現したかについて詳しく説明します。

運用効率向上の必要性

Karpenter を利用する前は、Amazon EKS のコンピューティングをオートスケーリングするための別のソリューションを利用していました。しかし内部チームのニーズが高まるにつれて制限に直面しました。アプリケーションの増加と、インスタンスタイプやインスタンスニーズの増加に伴い、複数の Auto Scaling Group (ASG) を管理する必要がありました。Slack には厳しいコンプライアンス要件があり、数千のワーカーノードを持つ複数の EKS クラスターを頻繁に更新する必要がありました。これらの頻繁な更新と複数の ASG の管理が重なり、全体的なアップグレードのペースが遅くなっていました。また、現行の設定では単一レプリカのアーキテクチャを使用していたことを懸念していました。Slack にはノードの起動を高速化し、高可用性を実現し、より優れた cluster bin packing を提供できる堅牢なオートスケーラーが必要でした。

ソリューション概要

前述した運用上の課題を克服するため、Slack はスケジューリングできない Pod に応答して新しいノードを自動的にプロビジョニングするオープンソースのクラスタオートスケーラーである Karpenter の使用を決定しました。Karpenter は、保留中の Pod の集約リソース要件を評価し、それらを実行するための最適なインスタンスタイプを選択します。非 DaemonSet の Pod が無いインスタンスを終了またはスケールインして無駄をなくします。また、 Pod を積極的に移動させ、より安価なノードに置き換えてクラスターコストを削減する統合機能をサポートしています。

これらの機能すべてが Slack の課題に対処し、AWS チームの支援を得て、Bedrock の環境で Karpenter の検証に成功しました。前述の機能に加えて、Karpenter が Amazon Elastic Compute Cloud (Amazon EC2) のフリート API に直接呼び出しを行うことで、遅延なしに適切なコンピューティングリソースを確保できる点が重要でした。

私たちは入念な 2 段階のフェーズで旅を始めました。

第 1 フェーズでは、コアとなる Deployment とアプリケーションとともに、マネージドノードグループ上に Karpenter を展開しました。Karpenter はアプリケーションの一部についてのみ検証され、この段階では統合機能は無効化されていました。

第 2 フェーズでは、Karpenter 自身を Karpenter が管理するノード上で実行したくなかったため、Karpenter Controller のワークロードを専用の ASG に移行しました。すべてのユースケースについて徹底的な試験と慎重な検討を行った後、最終的に数千以上のワーカーノードを実行する 200 を超える EKS クラスター全体に Karpenter を展開しました。また、 Slack はコスト削減を実現するため Karpenter の統合機能も有効にしました。

Karpenter の段階的ロールアウトにより、Karpenter を有効化するクラスターを制御できました。これにより、Karpenter でワークロードのパフォーマンスを検証し、問題が報告された場合は迅速にロールバックを行うことができました。ワークロードに適切な request / limits の設定がない場合、Karpenter は小さなインスタンスを割り当てるか、大きなインスタンスの一部分しか割り当てられず、負荷が増加すると Pod の頻繁な作成と削除が起きていました。Karpenter は Slack がこの点を発見するのを助け、サービス所有者と協力して Pod が適切なノードに割り当てられるよう要件を設定する形で Slack のプラットフォームを改善することができました。特定のインスタンスタイプが必要なワークロードについては、Slack が NodePool のカスタムリソースを調整し、Karpenter の Well-known labels を使って Pod を特定のインスタンスタイプに固定できました。

Slack Bedrock における EKS クラスターのアーキテクチャ

得られた成果

フリート全体に Karpenter をロールアウトした後、ASG ノードに taint を適用し、アプリケーションを Karpenter が管理するインスタンスに移行するプロセスを開始しました。この取り組みから得られた成果は、大きく、定量化可能なものでした。

Karpenter の助けにより、Slack は保留中の Pod がリクエストしたリソースに基づいて、8xlarge から 32xlarge までの幅広いインスタンスタイプを活用し、アプリケーションを適切に bin packing することができました。この結果、クラスターの使用率が上がり、コスト削減に繋がりました。特定のインスタンスを要求しないワークロードは、利用可能なリソースを効率的に活用するようになりました。さらに、Karpenter の統合機能により、以前のソリューションのように複数のアベイラビリティーゾーン (AZ) にまたがる最小の ASG サイズとしてアイドル状態のインスタンスを維持するのではなく、アイドルインスタンスの削除が確実に行われるようになりました。加えて、Karpenter の迅速なスケーリング判断により、ノードのプロビジョニング時間が短縮されたことを確認しています。

成果についてまとめると、 Pod のリソース要求に基づくインスタンスの動的選択と、EKS クラスターを管理する Terraform ファイルにインスタンスタイプをハードコードしないことで、 Pod の起動が高速化されました。また、アップグレード手順中にノードをスムーズに削除・ローテーションできるため、Slack のシステムアップグレードに関する懸念も解消されました。Karpenter が 直接 Amazon EC2 のフリート API と対話できること、およびリトライ機構の改善により、AZ の障害発生時の復旧も高速になりました。アプリケーションは、AWS で利用可能な容量までインスタンスをスケールアウトできるため、ASG の管理オーバーヘッドが少なく、Slack ユーザーの体験も向上しています。Slack は現在、ミッションクリティカルなアプリケーションのバースト的なスケーリング活動に備えて、カスタムのオーバープロビジョニングで Karpenter を運用しています。

Slackは、Helm のテンプレート機能を活用して、Karpenter の Helm チャートをカスタマイズし、200 を超える EKS クラスター全体で単一の NodePool と EC2NodeClass を使用しています。

Karpenter が提供するインスタンスファミリーには幅広いインスタンスタイプが用意されているため、Slack の技術チームは動的スケジューリングの制約を使用する際に、簡単にインスタンスタイプを切り替えられることが便利だと感じています。これにより、インフラストラクチャチームの RTB の負担が軽減され、ASG 設定を維持する際に見られたようなインスタンスタイプ変更のリスクも低減されました。Karpenter を活用することで、Slack は EKS のコンピューティングコストを 12% 削減できました。

今後の機能強化

Slack は現在、運用をさらに改善しコスト削減を進めるため、Karpenter の設定の合理化に取り組んでいます。ロードマップには以下の機能が含まれています:

  • Kubelet のカスタマイズ: Infrastructure-as-a-Code (IaC) ソリューションを介してではなく、Karpenter の EC2NodeClass 内で kubelet フラグを使用することで、インスタンスの起動時間を改善します。
  • Warmpool/minimum: Karpenter がオープンソース化されたことを受け、Amazon EC2 フリート API コールを発行するのではなく、Karpenter がウォームプールからインスタンスを選択することで起動時間を短縮する方法について、Slack は貢献を検討しています。
  • Disruption control: Slack は、統合によって発生する障害を制御し、アプリケーションの可用性への影響を制限するために、障害制御機能を活用しています。

まとめ

この投稿では、Slack の Bedrock チームが Karpenter の実装により Amazon EKS クラスターの運用とコスト削減をどのように改善したかについて説明しました。AWS と Slack の協力体制が Karpenter の成功裏の展開と Slack の Amazon EKS 環境のモダナイズに不可欠でした。また、Slack が Karpenter を EKS クラスターのオートスケーラーとして活用することで、アップグレードのペースを改善し、さらなるコスト削減を実現できたことも取り上げました。今後は Slack が新機能への貢献と活用を通じて Karpenter 環境をさらに最適化し、Amazon EKS 上に堅牢なプラットフォームを構築することに注力していきます。

翻訳はソリューションアーキテクトの加治が担当しました。原文はこちらです。