大規模障害から学んだ教訓
お得な「スポットインスタンス」を95%活用 大手旅行検索サイトのAWS運用術
旅行検索サービスのSkyscannerは月間1億6000万人超の利用者を抱える。モノリシックなシステムからコンテナへの移行を経て、障害耐性を高めたセルベースアーキテクチャに到達するまでの軌跡を紹介する。
トラベル市場のオンライン検索が普及する中、旅行比較サイトは膨大な数のパートナーと連携し、絶えず変動する価格データをリアルタイムで処理する役割を担う。
旅行検索サービスを展開する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は、いかにしてこの壁を乗り越えたのか。
巨大クラスタの崩壊とセルベースアーキテクチャへの移行
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」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
4
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
5
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
7
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
8
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
9
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
10
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー