過去の「安全策」が負の遺産に
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
-
製品資料
[o9ソリューションズ・ジャパン株式会社] 「改正物流効率化法対策」徹底解説 総物流費を抑制するサプライチェーン戦略 -
製品資料
[o9ソリューションズ・ジャパン株式会社] 「サプライチェーン最適化」実践ガイド:効果的な意思決定を実現する秘訣とは? -
製品資料
[株式会社リンプレス] 非デジタル/IT人材を「自走するDX推進者」に変えるための育成ロードマップ -
市場調査・トレンド
[ワンアイルコンサルティング株式会社] AI時代の組織設計:「判断と責任」を人に残すための2つの原則とは? -
技術文書・技術解説
[ワンアイルコンサルティング株式会社] システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
2
「完璧な設計」なのに3000万円溶けた AWSの失敗事例から学ぶ3つの教訓
-
3
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
4
高額な「AI PC」を一般従業員も使えたら? 費用のハードルを一気に下げる方法
-
5
「コピペ運用の限界」に直面するAI活用 7割超が“別画面”のまま使う理由は?
-
6
LLMの「過学習」、正しく説明している文章はどれ?
-
7
「AIバブル」は崩壊するのか? 熱狂の後に来る“尻拭い”と4つの防衛策
-
8
IT調達担当者が知るべき「IT機器 大インフレ時代の前向きな選択肢」
-
9
クラウド資格コレクターは評価されない? 年収1000万を分ける“OSの理解度”
-
10
2035年までに1億4500万台、急拡大する「フィジカルAI」市場の勝者は誰か
ホワイトペーパーランキング PR
-
1
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
3
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
4
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
5
「Google Workspace」活用事例34選、先進の生成AIによる組織変革の全貌
-
6
生成AIで文書活用を進めるには? 効率化と安全性をどう両立する
-
7
「人員を増やす」という選択肢はない 情シスが負の連鎖から抜け出すには?
-
8
「問題が深刻化しやすいプロジェクト管理」から脱却する方法とは?
-
9
Linuxのスキルを証明する“激推し”の認定資格はこれだ
-
10
NTTドコモが実践したクラウド統合監視 業務量2倍でも残業削減を実現できた理由
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー