お得な「スポットインスタンス」を95％活用 大手旅行検索サイトのAWS運用術：大規模障害から学んだ教訓

旅行検索サービスのSkyscannerは月間1億6000万人超の利用者を抱える。モノリシックなシステムからコンテナへの移行を経て、障害耐性を高めたセルベースアーキテクチャに到達するまでの軌跡を紹介する。

[TechTargetジャパン]

　トラベル市場のオンライン検索が普及する中、旅行比較サイトは膨大な数のパートナーと連携し、絶えず変動する価格データをリアルタイムで処理する役割を担う。

　旅行検索サービスを展開するSkyscannerは、2025年時点で月間1億6000万人以上のエンドユーザーを抱え、1800万本以上のフライトルートの検索を可能にしている。ピーク時には毎秒5000件のリクエストを受け、1日に1000億件の価格データを処理している。

　2014年時点でのSkyscannerのシステムは、単一のオンプレミスサーバで動くモノリシックな状態だった。そこからオンプレミスサーバとクラウドサービスを併用するシステム構成、コンテナ化によるマイクロサービスアーキテクチャへと段階的な移行を進めてきた。2019年には約500件のサービスを、Amazon Web Services（AWS）のマネージド型Kubernetesサービスである「Amazon Elastic Kubernetes Service」（Amazon EKS）で動かし、開発速度の向上を実現する。

　しかし、単一の巨大なKubernetesクラスタへの依存が、後にシステム全体を巻き込む深刻な障害を引き起こすことになる。この巨大なクラスタの課題に直面したSkyscannerは、いかにしてこの壁を乗り越えたのか。

巨大クラスタの崩壊とセルベースアーキテクチャへの移行

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

複雑なシステム運用

• 複雑なKubernetesクラスタは“手作業”では守れない？　「SLM」が導く解決策
• NikeやeBayが陥った「OpenTelemetry」の穴　監視インフラ運用の“泥臭い実態”

　2025年に開催されたAWSの年次技術カンファレンス「AWS re:Invent 2025」のセッション「ARC209 - Architecting for hypergrowth: Scaling to 200 million users w/ Skyscanner」では、Skyscannerが構築した分散アーキテクチャの詳細が説明された。

　コンテナ化の導入によって開発効率は高まったものの、Skyscannerのシステムは次第に大き過ぎて失敗が許されない巨大な単一障害点と化していった。2019年半ばには、この巨大クラスタに起因する大規模な障害が頻繁に発生し、開発者の業務体験の悪化を招くことになる。

　そこでSkyscannerは、障害の影響範囲を最小限に抑えるため、アーキテクチャの抜本的な見直しを実施した。巨大なクラスタを分割し、小さく構成可能な「セル」を複数展開する「セルベースアーキテクチャ」への移行だ。

　改修後のシステムは4つのアクティブなリージョンに展開され、リージョンごとに複数のセルを持つ構造をとる。クラスタのサイズをあらかじめ制限し、仮に1つのクラスタがダウンしても全体の可用性に影響を与えない仕組みを構築した。サービスは1リージョン内で少なくとも3つのクラスタに展開され、部分的な障害が起きることを通常の状態として受け入れる設計としたのが大きな特徴だ。

コンピューティングリソースの95％をスポットインスタンスで運用

　月間10億回以上の検索クエリを処理するSkyscannerにとって、インフラの費用管理はスケーリングと同等に重要な意味を持つ。同社は、余剰リソースを低価格で利用できる契約形態「スポットインスタンス」をコンピューティングリソースの95％に割り当てて運用し、大幅な費用削減に貢献する体制を敷く。

　この大規模運用を支えるのが、オープンソースのKubernetes用クラスタオートスケーラーである「Karpenter」だ。Skyscannerは4リージョン、12のゾーンにわたり、250種類以上の異なるインスタンスタイプを組み合わせて利用する。システムがこれらのインスタンスを動的に割り当て、要件に最適な計算資源を選択することで、運用管理特有の複雑さを軽減する。

キャッシュ戦略による負荷分散

　リアルタイムで1日1000億件の価格データをパートナーから受け取るシステム運用において、データベースへの直接の問い合わせは致命的なボトルネックになり得る。実行しなくて済むデータベースへのアクセスが最良であるという考えに従い、Skyscannerは徹底したキャッシュ戦略を導入した。

　検索セッションやパートナーの価格提示データ、ルート情報などを一時保存するために、分散キャッシュ（データを複数機器のメモリに分散保持する仕組み）を利用し、リージョンごとに数百TBのメモリ領域を活用する。これによって、バックエンドのデータベースやパートナーの外部システムへの負荷を最小限に抑えつつ、エンドユーザーに対する高速な検索結果の表示の維持に努める。

　Skyscannerは1日に約550億件発生するシステムイベントをデータレイクに蓄積している。独自のサービスを用いて小さなバッチ単位でデータをストリームに書き込み、情報の重要度に応じて異なる経路に振り分けることで、効率的なデータ処理経路の構築に成功した。

障害から学んだ設定管理の重要性

　分散アーキテクチャは高い可用性を提供する一方で、運用設定の複雑化という新たなリスクを生む。Skyscannerは2021年に誤った設定内容を一斉に適用してしまい、数分間で24のクラスタ全てのアプリケーション領域を削除してしまうという致命的なインシデントを経験した。

　この教訓からSkyscannerは、設定の変更を単なる設定ファイルではなく、プログラムのソースコードと同等に扱う方針を徹底した。事前のテストや静的解析、包括的なコードレビューを必須化し、全体に影響を及ぼす設定変更は極力避け、特定のサービスやセルに範囲を限定して変更を加えるよう運用手順を改めている。

　Skyscannerは、インフラ専任のエンジニアリングチームを組成し、本番システムの安定運用だけではなく、ツール群の継続的な改善への取り組みを進めている。完璧なシステムを最初から求めるのではなく、ビジネスの成長に合わせて拡張性がある技術を選択し、歩みを止めずにシステムを改善し続けるアプローチこそが、2億人規模の利用者を安定して支える真のインフラになる。

本稿は、AWSが2025年12月9日に公開した動画「AWS re:Invent 2025 - Architecting for hypergrowth: Scaling to 200 million users w/ Skyscanner-ARC209」を基に作成しました。