Expediaがインフラ設定の“闇”を解明した方法 年間2000万ドル削減の裏側：過去の「安全策」が負の遺産に

インフラの規模拡大に伴い、クラウドサービスの費用削減とシステムの信頼性維持は相反する課題になりがちだ。財務チーム主導の強引な費用削減は障害のリスクを招くExpedia Groupはこのジレンマをどう打破したのか。

[TechTargetジャパン]

　インフラが大規模化する中で、開発者が円滑な開発・運用を進められるように共通インフラの構築や自動化、共通ツールの提供などを担う「プラットフォームエンジニア」は重要なポジションだ。しかしほとんどの場合、システムの安定稼働や信頼性を優先するあまり、過剰な安全マージン（バッファー）として余分なコンピューティングリソースを確保しがちだ。一方で財務データのみを基に費用削減を進める財務（FinOps）チームは、システムの実際の挙動を把握しないままコンピューティングリソースの縮小を求め、結果として遅延悪化などのシステム障害を引き起こすリスクがあった。

　旅行予約サイトを運営するExpedia Groupは、自社開発のマルチテナント型コンテナ管理システム「Runtime Compute Platform」（RCP）において、この課題に取り組んだ。システムの挙動を最も深く理解しているプラットフォームエンジニアが主導し、過去の不要な設定を見直した。結果として、システムの安定性を維持したまま平均稼働ノード数を600から300に半減させ、年間で2000万ドルに上るインフラ費用の削減を実現した。

　Expedia Groupは具体的にどのような指標を用い、複雑なシステムをどのように作り変えたのか。同社のプラットフォームエンジニアが、無駄を削ぎ落とすために実践した独自の工夫と自動化の仕組みに迫る。

正常な稼働状態を示す「ベースライン」の確立

併せて読みたいお薦め記事

インフラをどう最適化するか

• AWSに必須　コストやパフォーマンスを最適化する「6つの柱」とは？
• プラットフォームエンジニアリングが「“何でも屋”にされる開発者」を救う

　本稿は、2026年3月に開催された「CNCF-hosted Co-located Events Europe 2026」におけるセッション「When Platform Engineers Lead FinOps: Driving Reliability and $20M in Savings」の講演内容を基にしている。登壇者はExpedia Groupのアディティヤ・シャルマ氏とモヒット・クマール氏だ。

　Expedia GroupのRCPは、コンテナオーケストレーションツール「Kubernetes」のマネージドサービス「Amazon Elastic Kubernetes Service」（Amazon EKS）による数百のKubernetesクラスタと、仮想マシンサービス「Amazon Elastic Compute Cloud」（Amazon EC2）の数千のインスタンス（ノード）で構成されている。その中で、1万以上のワークロードが稼働する大規模なシステムだ。

　最適化の第一歩は、費用データの単純な可視化にとどまらず、システムの挙動と結び付けた明確な指標を持つことだった。あるクラスタのCPU使用率が35％だった場合、財務的な視点だけでは単なる「無駄」に見える。しかし、突発的なトラフィックの急増やノード障害への備え、デプロイ時の余剰枠といったシステムの状況を考慮すると、それが本当に不要な空き容量なのか、意図的な安全マージンなのかは判断が分かれる。

　そこでExpedia Groupのプラットフォームエンジニアは、稼働率のデータにシステム構成の文脈を組み合わせ、正常な稼働状態を定義する「ベースライン」を確立した。具体的には、健全なクラスタ使用率の範囲を55〜70％の「最適ゾーン」（安全な最適化領域）と定め、30％以下を「過剰」（無駄）、80％以上を「リスクゾーン」（信頼性の危機）として定義した。この明確な指標によって、プラットフォームエンジニアは当てずっぽうではなく、確かな根拠を持って安全にコンピューティングリソースを最適化できるようになった。

過去の「安全策」という名のレガシー設定を処理する

　システムが時間をかけて拡大する過程で、過去のトラブル回避や安全性のために適用された保守的な設定がそのまま累積することがある。Expedia Groupも例外ではなく、こうしたレガシーな設定を再評価したところ、使用頻度の低い固定ノードプールや、必要以上に巨大なインスタンスタイプ、過剰なバッファーといった無駄なパターンが浮き彫りになった。

　これらは当時の判断としては正しかったが、ワークロードの進化やスケーリング技術の向上に適合しなくなっていた。そこでプラットフォームエンジニアは過去の利用傾向をデータに基づいて分析し、安全に最適化できる箇所を特定した。本番環境への急激な変更を避けるため、制御された実験環境のもとで段階的に設定を変更し、連続的に監視することで、信頼性を犠牲にすることなく不要なインフラ費用を削ぎ落とした。

構造的な無駄を解消するアーキテクチャの再設計

　部分的な設定調整にとどまらず、システムの構造そのものを変革したことが、稼働ノード数の半減という劇的な成果をもたらした。Expedia Groupが実施した主な工夫は以下の3点だ。

1．コンピューティングリソースの特性に応じたノードプールの分離

　従来は、高価なGPUインスタンスを含む共通のノードプールに、多様なワークロードが混在していたため、GPUを必要としない処理に対しても意図せず高価なノードが割り当てられる無駄が生じていた。そこで、GPU専用のノードプールを新設して処理を完全に分離し、費用の不透明さと無駄なプロビジョニングを解消した。

2．バッチ処理環境の最適化と安定化

　データ分析などのバッチジョブが、応答速度を重視する一般のアプリケーションと同じノードプールで実行されていた。自動最適化ツール「Karpenter」の過度なリソース集約ロジックによって、ノードの起動と停止のループが頻繁に発生し、処理が停滞する問題があった。これに対し、バッチジョブ専用のノードプールを設けて自動集約機能を無効化することで、クラスタ内の不要な処理の滞留を防ぎ、結果として月間の平均ノード数を600から300に減らすことに成功した。

3．通信制御機能（サービスメッシュ）の動的スケーリング

　システム全体に展開される通信制御コンポーネント「IstioD」について、従来はクラスタの規模に応じて数十から数百個の固定数を配置するという、安全だが非効率な設定になっていた。これを、実際の負荷を示す指標（Prometheusのpilot_xdsメトリック）に基づき、必要に応じて自動で増減させる動的スケーリング手法（KEDA）へと変更した。この結果、パフォーマンスを維持したまま、該当する稼働数を約50％削減することに成功した。

インフラ設計そのものに効率性を組み込む今後の展望

　今回の取り組みを通じて得られた最大の教訓は、費用の最適化は財務チームだけの仕事ではなく、インフラを構築するプラットフォームエンジニアの責任であるという点だったという。財務チームが費用の可視化や予算管理のシグナルを提供し、プラットフォームエンジニアがシステムの挙動や特性を考慮して安全な手段を実装するという連携があって初めて、持続的な成果が生まれる。

　Expedia Groupは今後、インフラの設計段階から初期設定として効率性の思想を組み込み、自動化された仕組みの中で高度な可用性と費用対効果を両立させる体制をグローバルに拡張する方針だ。

本稿は、CNCFが2026年4月14日に公開した動画「When Platform Engineers Lead FinOps: Driving Reliability and $20M in... Aditya Sharma & Mohit Kumar」を基に作成しました。