過去の「安全策」が負の遺産に
Expediaがインフラ設定の“闇”を解明した方法 年間2000万ドル削減の裏側
インフラの規模拡大に伴い、クラウドサービスの費用削減とシステムの信頼性維持は相反する課題になりがちだ。財務チーム主導の強引な費用削減は障害のリスクを招くExpedia Groupはこのジレンマをどう打破したのか。
インフラが大規模化する中で、開発者が円滑な開発・運用を進められるように共通インフラの構築や自動化、共通ツールの提供などを担う「プラットフォームエンジニア」は重要なポジションだ。しかしほとんどの場合、システムの安定稼働や信頼性を優先するあまり、過剰な安全マージン(バッファー)として余分なコンピューティングリソースを確保しがちだ。一方で財務データのみを基に費用削減を進める財務(FinOps)チームは、システムの実際の挙動を把握しないままコンピューティングリソースの縮小を求め、結果として遅延悪化などのシステム障害を引き起こすリスクがあった。
旅行予約サイトを運営するExpedia Groupは、自社開発のマルチテナント型コンテナ管理システム「Runtime Compute Platform」(RCP)において、この課題に取り組んだ。システムの挙動を最も深く理解しているプラットフォームエンジニアが主導し、過去の不要な設定を見直した。結果として、システムの安定性を維持したまま平均稼働ノード数を600から300に半減させ、年間で2000万ドルに上るインフラ費用の削減を実現した。
Expedia Groupは具体的にどのような指標を用い、複雑なシステムをどのように作り変えたのか。同社のプラットフォームエンジニアが、無駄を削ぎ落とすために実践した独自の工夫と自動化の仕組みに迫る。
正常な稼働状態を示す「ベースライン」の確立
本稿は、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」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。
関連記事
新着ホワイトペーパー PR
-
製品資料
[ファインディ株式会社] AI利用率だけでは説明できない成果 開発組織の競争力を生む「開発資本」とは? -
製品資料
[ニュータニックス・ジャパン合同会社] AI活用を成功へ導く、シンプルで費用対効果に優れたクラウド基盤とは? -
製品資料
[ニュータニックス・ジャパン合同会社] マネージドKubernetesには限界も――メリットをフル活用する新たな選択肢とは? -
技術文書・技術解説
[ニュータニックス・ジャパン合同会社] 決断の日が迫る「vSphere 8」サポート終了問題 考慮すべきリスクと選択肢は? -
製品資料
[サイバーソリューションズ株式会社] メール誤送信対策のルールが肥大化 苦しむ情シスはどうすれば救われるのか?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
2
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
3
Copilot導入で陥る“目的化”の落とし穴 定着の鍵は「作り込まない」こと
-
4
「アップグレードできないJava」をどう守る IBMとRed HatがAIで400件超修正
-
5
パッチなしで「今すぐサーバを落とせ」 Kiteworks異例警告の波紋
-
6
IT製品の導入に関するアンケート「セキュリティ」編
-
7
OpenAIやAnthropicでさえ制御不能 2026年夏「3大サイバー攻撃」の衝撃
-
8
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
9
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
10
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
ホワイトペーパーランキング PR
-
1
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
2
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
3
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
4
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
5
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
6
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
7
Linux初心者でも知らないとまずい「RHEL」「SLES」の違いとは?
-
8
東大教授と考える、AI時代の「データ主権」「信頼性」「ガバナンス」の在り方
-
9
「IT史に名を残すシステム障害」8選
-
10
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー