Amazon EKS での Bottlerocket と Karpenter の採用 〜 Cordial の旅路 〜

この記事は Cordial’s journey implementing Bottlerocket and Karpenter in Amazon EKS (記事公開日: 2024 年 8 月 8 日) を翻訳したものです。

概要

Cordial は、マーケティング戦略を完全に自動化するためのツールを提供するクロスチャネルマーケティングプラットフォームです。マーケティングの遂行を自動化することで、Cordial はテクノロジーチームが本来の強みである構築と創造性に集中できるようにします。Cordial の堅牢なプラットフォームを使用して、マーケターにデータアクセスと管理を委任することで、テクノロジーチームを支援します。顧客中心のアプローチで設計された Cordial は、データを活用して創造性を高め、効率を向上させ、コストを削減し、収益性の高い成長を促進する AI (人工知能) 搭載の高速、柔軟、相互接続された一連のツールとサービスを提供します。

2014 年の発足以来、大手企業ブランドは Cordial を選び、メール、SMS、モバイルアプリ、ソーシャルメディア、ダイレクトメールなどを横断して高い転換率のメッセージを自動化し、スケーラブルな収益の促進と長期的な顧客との関係を実現しています。Cordial は 2022 年と 2023 年の Deloitte Technology Fast 500TM で最も成長が早い企業に選ばれ、テクノロジー、成長、企業文化に関する複数の賞を受賞しています。

この指数関数的な成長を維持し、将来の拡大に備えるため、Cordial は次世代のインフラストラクチャプラットフォームを構築する旅に出ました。その中核となるコンピューティングプラットフォームは Amazon Elastic Kubernetes Service (Amazon EKS) で、以前のプラットフォームは Amazon Elastic Compute Cloud (Amazon EC2) 上にありました。この記事では、Cordial が Amazon EKS 環境内で Bottlerocket をオペレーティングシステム (OS)、Karpenter をノードライフサイクルマネージャーとして実装した旅路に迫り、運用効率の向上とセキュリティ体制の改善を目指しました。

セキュリティ体制と運用効率の改善

Amazon EKS を利用する前は、アプリケーションを Amazon EC2 上で実行し、複数の Auto Scaling グループがスケーリングプロセスを容易にしていました。クロスチャネルマーケティングプラットフォームとして、アプリケーションの動作には次の 2 つの重要な原則がありました。

• クライアントからのメッセージは即座に送信される必要
  • クライアントがメッセージ配信をトリガーするたびに、遅延なく即座に送信する必要があります。
• クライアントからのメッセージは常に送信される可能性
  • このサービスのリアルタイム性から、メッセージは予測可能なパターンなしに常に送信される可能性があります

クライアントが増えるにつれ、以下のような運用効率と セキュリティ体制の制限に直面しました。

• アプリケーションの起動の遅延
• コンピューティングのスケーリングの課題
• スポットインスタンスなどのコスト効率の良いインスタンス購入オプションが利用できない課題
• デバッグのワークフローが非効率的

チャレンジ-1: 起動時間の遅延とコンピューティングのスケーリングの課題

最初の大きな課題は、ノードの起動とアプリケーションの起動にかかる時間でした。インスタンスのユーザーデータスクリプトを使用して、起動時にアプリケーション環境をインストールおよび構成しました。ユーザーデータのシェルスクリプト内で実行された自動タスクには、Amazon Elastic Block Store (EBS) ボリュームのフォーマットなどの一般的な構成要件、アプリケーションレベルの依存関係のインストール、特定のランタイムパラメータを使用したアプリケーション環境のブートストラップなどがありました。

そのため、アプリケーションがクライアントリクエストを受け付けられるようになるまでに、標準の Amazon EC2 Auto Scaling プロビジョニングプロセスから最大 5 分の遅延が発生していました。この起動の遅さにより、ワークロードの需要に基づいてリアルタイムにキャパシティを追加することができず、これがインスタントメッセージ配信の目標に直接影響を与えていました。

クライアントのリクエストをすぐに処理できるようにするため、一部の容量がアイドル状態になっていたにもかかわらず、常に最大容量を維持する必要がありました。これにより、運用が非効率的なデザインになってしまいました。

チャレンジ-2: スポットインスタンスが利用できない課題

ノードの起動プロセスが 5～10 分かかるため、残念ながらサービス品質を維持しながら Spot Instance の中断の 2 分間の警告に安全に対応することができませんでした。これにより、Spot Compute の使用が不可能になり、コスト効率が悪くなりました。

チャレンジ-3: セキュリティ強化の課題

当社のソリューションでは、コンプライアンス目標を維持するために、Center for Internet Security (CIS) ベンチマークチェックを備えた汎用 OS を使用していました。将来の成長に向けたソリューションを計画する必要があったため、セキュリティ対策を強化するために、最小限のパッケージ、攻撃対象領域の縮小、そして既定の強化機能を備えたコンテナに最適化された OS を検討する必要がありました。

チャレンジ-4: デバッグワークフローの改善

デバッグのワークフローでは、ワーカーノードにログを記録し、基盤となるノード上のプロセスを監視およびデバッグするために strace ユーティリティをインストールする必要がありました。これはアクセスの観点からセキュリティーリスクとなります。そのため、デバッグパッケージがブートアップ時に既定でインストールされないようにすることが、セキュリティの観点から要件となりました。これにより運用オーバーヘッドも増加し、継続的な監視が必要となりました。

ソリューションの概要

上記の課題に対処するため、私たちは複数フェーズからなる取り組みを開始しました。。

フェーズ-1 では、メッセージングコンポーネントをコンテナ化し始めました。これにより、依存関係が減り、スケーラビリティの問題に対処できるようになります。

フェーズ-2 では、コンテナ化されたアプリケーションの管理、スケーリング、デプロイに必要なコアコンピューティングプラットフォームとして Amazon EKS に焦点を当てました。最初は、マネージド型ノードグループを使用してワーカー ノードをプロビジョニングし、Cluster Autoscaler を使用して必要なスケーリングプロセスを処理する標準的なセットアップから始めました。この結果、ユーザーデータスクリプトの削除に伴う起動時間の短縮など、すぐに成果が得られました。これは、ほとんどの構成が Kubelet レベルまたはコンテナレベルで構成可能だったためです。これにより、アプリケーションの起動プロセスは、当初の 5 〜 10 分の待ち時間から大幅に短縮されました。起動プロセスが高速化したことから、ワークロードの一部のプロセスでスポットインスタンスの実装も開始しました。

このセットアップを迅速に行うには、予想していたよりも複雑で時間がかかりました。さまざまな顧客をオンボーディングし始めると、クラスターには、ユニークな要件とスポットプールの多様性に対応するために、複数のインスタンスタイプ、サイズ、アーキテクチャが必要になりました。Cluster Autoscaler には、いくつかの課題がありました。ノードグループ内で使用されるインスタンスタイプは、正確なスケーリング計算のために同じ RAM と CPU コア数を持つ必要があったためです。これにより、Compute Optimized と General Purpose インスタンスタイプなど、混在したキャパシティのノードグループを作成することができませんでした。さらに、同じ Auto Scaling グループ内で、さまざまなインスタンスサイズやアーキテクチャ (x86 と ARM) のノードグループを作成することもできませんでした。Cluster Autoscaler にはスポット容量を優先し、オンデマンドをフォールバックオプションとして定義するための優先スケーリングの機能がありますが、コントローラーの処理に時間がかかりすぎました。

フェーズ-3 では、スケーラビリティの課題に対処するため、Kubernetes 向けに構築されたオープンソースのノードライフサイクル管理プロジェクト Karpenter を採用しました。Karpenter 内の NodePool カスタムリソース定義により、複数のインスタンスタイプ、サイズ、アーキテクチャに関する要件を解決できました。Karpenter が “instant” タイプの EC2 Fleet API と連携してノードをプロビジョニングしたことで、ノードの起動時間を 30 秒以下に抑えることができました。また、Karpenter 固有の中断制御フローと中断予算を組み合わせることで、未使用の容量を統合し、コスト効率の良い設計を実現できました。

フェーズ-4 では、セキュリティ体制を強化するため、AWS がコンテナ実行用に設計したオープンソースの Linux ベースの OS である Bottlerocket の実装を開始しました。

• 一般的な Linux ディストリビューションでデフォルトでインストールされているパッケージ、ツール、インタープリター、依存関係の多くは、コンテナをホストするだけでは必要ありません。Bottlerocket はこれらの余分なソフトウェアを除外することでセキュリティオーバーヘッドを改善しました。
• Bottlerocket は API 中心の設計を採用しており、Report API を備えています。これにより、OS レベルのレポーティングを自動化するメカニズムが提供されました。Bottlerocket Report API を使用して、Bottlerocket と Kubernetes CIS ベンチマークに対してレポートを実行できました。
• Phase-3 までのソリューションでは、sed (ストリームエディター) を使用して Kubelet の JSON 設定ファイルを直接変更する必要があり、エラーが発生しやすいワークフローでした。しかし、Bottlerocket は Kubernetes 設定を行うための宣言型の TOML 設定フォーマットを提供してくれたため、より簡単に設定ができ、複雑さが低減されました。
• Bottlerocket には SELinux の強制モードの設定が組み込まれており、すべての非特権コンテナに制限の厳しい container_t ラベルが付与されます。また、セキュアシェルアクセスを提供しないことで、Bottlerocket は既存のメカニズムと併せて、開発者のデバッグ環境周りに必要なモニタリングフレームワークを安全な方法で実現するのに役立ちました。

達成された成果と次のステップ

上記の設計を実装した後、次の図に示すように、Horizontal Pod Autoscaler が Custom Metrics を使用するようにすることで、Pod のスケーリングプロセスの改善も開始しました。

Amazon EKS、Karpenter、Bottlerocket を使用することで、クラスターのサイズをその時点で必要な作業に合わせて調整し、必要に応じて拡大縮小できます。Karpenter の高速なノードプロビジョニング時間、多様な計算オプション、ノード統合機能により、常にピーク容量で実行する必要がなくなり、運用効率が向上し、ソリューションのコンピューティング部分だけで約 18% のコスト削減と 80% の起動時間改善が実現しました。Bottlerocket の目的別設計と API 中心の設計により、セキュリティが強化され、Karpenter と組み合わせることで、将来のスケーリングに適した設計のソリューションが実現しました。

結論

この記事では、Cordial チームが Amazon EKS、Karpenter、Bottlerocket を実装することでユーザーエクスペリエンスを改善した方法について説明しました。AWS と Cordial の協力により、Cordial のアプリケーション環境のモダナイゼーションが成功しました。また、Cordial がビジネス価値を高めるために、環境をさらに最適化することに注力していることも説明しました。

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