re:Invent 2025: Booking.comのミッションクリティカルな予約システムをServerlessで現代化した事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Designing mission critical applications with serverless services (CNS362)
この動画では、Booking.comが20年以上稼働していたミッションクリティカルな予約システムをAWS Serverlessで現代化した事例が紹介されています。Perlで書かれたモノリスは90以上の依存関係を持ち、密結合により変更が脆く、デプロイが困難でした。チームはStep FunctionsとLambdaを活用し、shadow trafficアプローチでテストを実施。オンボーディング時間を4ヶ月から1ヶ月に短縮し、市場投入までの時間を大幅に改善しました。また、strangler fig patternやbranch by abstractionなど、モノリス分解のパターンや、EventBridge Pipesを使った非同期通信による顧客体験の向上方法も解説されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
ミッションクリティカルなシステムの課題と分散システムの必要性
こんなシナリオを想像してみてください。あなたは組織内のミッションクリティカルなシステムの保守を担当するチームの一員です。このシステムは企業にとって非常に重要で、数百人の開発者がこの巨大なアプリケーション上で一緒に作業できるようにスケールすることを可能にしています。当然のことながら、そうすることには利点があり、開発者による素晴らしい仕事がたくさん行われていますが、課題もあります。以前は週に複数回デプロイしていたのに対して、今は月に1回のデプロイになっています。テストライフサイクルには数十分かかり、デプロイ時に多くの問題があるためロールバックが必要になることもあります。これ、心当たりのある人もいるんじゃないでしょうか。
私にはあります。私はこのような種類のアプリケーションで多く仕事をしており、必要に応じて分散システムを活用することの利点を理解しています。なぜなら、アーキテクチャは永遠ではないからです。このセッションでは、Booking.com がサーバーレスを活用することで、私が説明した課題を克服するためにどのようにモダナイゼーションの旅を進めたのかを見ていきます。私の名前は Luca Mezzalira です。Amazon Web Services のプリンシパルサーバーレススペシャリストです。
本日は Sara Gerion と一緒です。皆さん、こんにちは。私は Sara です。オランダのアムステルダムを拠点とするプリンシパルソリューションズアーキテクトです。私は observability、resilience、surveillance に情熱を持っています。そして私は Zeeshan Pervaiz です。Booking.com のエンジニアリングマネージャーです。私のチームは Booking.com の20年前のレガシー予約システムのモダナイゼーションを担当していました。
では始めましょう。ですが、その前に分散システムが何かを理解する必要があります。よく素晴らしい定義をたくさん見かけますが、 私にとって最高の定義はこれです。 分散システムは生きたシステムです。分散システムには注意とケアが必要だというマインドセットを持ち、何度も何度も反復し、時には自分たちの決定に異議を唱えることを始めれば、成功への道は半分進んだようなものです。
通常、分散システムを採用する場合、特定の目標に到達したいと考えます。 最初のものは組織のスケーラビリティです。新しいチームやパートナーをシステムに接続して、特定の機能の提供を加速させる可能性を持ちたいのです。 ビジネスアジリティも必要です。つまり、内部または外部で、あるいは業界内で何か起こって、別の方向へのシフトが必要になった場合、システムの一部を変更するだけで対応できるようになりたいのです。 また、より速いフィードバックループも必要です。DORA メトリクスについて聞いたことのある人も多いと思いますが、これらはこの非常に複雑な世界で成功するためのメトリクスです。 さらに重要なことに、チームの外部依存性を減らしたいのです。なぜなら、現実には、数百人のエンジニアが一緒に働いているモノリスで作業する場合、ある時点で調整が多くなるため、スピードを落とさなければならないからです。
モジュール性とServerlessによる価値創出への転換
外部の依存関係を減らし、認知負荷を軽減し、最終的には影響範囲を縮小したいということですね。アプリケーションやサービスをデプロイするときに、そのサービスがダウンしても、モノリシックなシステムで起こるような、システム全体への影響は出ないということです。それを実現するには、モジュール性を活用する必要があると思います。モジュール性とは何かを理解してみましょう。それは、独立した部品で構成されており、それらが組み合わさることで完全な全体を形成するという特性です。最も重要なのは、システムがモジュール性を欠いている場合、1つのコンポーネントへの調整が他のコンポーネントの機能に影響を与えるということです。これはテクノロジー側だけで見られるものではありません。これはケンブリッジ辞書からの定義で、あらゆるものに適用されるモジュール性の定義です。
私たちの場合、モジュール性はさまざまな方法で表現できます。例えばコードを使う方法もあります。強力なカプセル化を活用し、数十年にわたって非常にうまく機能してきた設計パターンを使うということです。しかし、ある時点で、10年間稼働しているソフトウェアを持つようになると、こうしたことが薄れ始める可能性があります。ビジネスロジックを環境から分離するかもしれません。例えば hexagonal architecture を使うことで、ですが、開発チームの規律が必要になります。チームは変わることもありますし、人が会社を去ったり、他のチームに移ったりすることもあります。ですから、コードを使ったモジュール性は実現できますが、多くの規律が必要です。
一方で、インフラストラクチャレベルでモジュール性を適用することもできます。そこではアーキテクトとしての意図をより多くの方法で表現するオプションがあります。必要に応じて同期プログラミングと非同期プログラミングを使いたいのです。なぜなら、それによってより回復力があり、スケーラブルなシステムを持つことができるからです。コードを書くよりも設定することが多くなります。なぜなら、serverless システムの中には多くの組み込み動作が利用可能だからです。さらに重要なのは、開発するものに対してより多くの制御ができるということです。システムの一部だけを開発し、特定の動作はすでにサービスの中に組み込まれているからです。AWS で考えていることは、serverless は Lambda と関連付けられるだけではなく、戦略だということです。差別化されていない重い作業を取り除き、その負担を私たちが引き受けることで、ビジネス価値を最大化できる戦略です。コードを書くことではなく、価値を生み出すことが重要なのです。
Serverless を採用すると、API を定義し、ビジネスロジックを定義することに焦点を当てます。残りのすべては私たちが対応します。仕事に適したサービスを選択すれば、うまくいきます。
顧客との関わりで目撃していることは、パラダイムシフトです。私は通常、毎年50～100の顧客と関わっています。新しい顧客を獲得するには、より良い製品を構築する必要があります。つまり、より頻繁にイノベーションを起こし、競合他社と比べて先を行く必要があります。機能をより速くリリースする必要があります。なぜなら、それが私たちの仮説をテストする唯一の方法だからです。DORA metrics はこの場合に非常に役立ちます。ですから、ビジネスロジックにより多くの焦点を当て、ソフトウェアシステムを分離する必要があります。Serverless はあなたが行う必要があることに対して完璧にフィットしているように見えます。
Serverless はしばしばイベント駆動型アーキテクチャのみを実現するものと考えられていますが、それは真実ではありません。Serverless は単なるツールであり、必要なあらゆるアーキテクチャを表現することができます。マイクロサービスと HTTP レスポンスを使用したポイント・ツー・ポイント通信を望みますか？それができます。システムの一部が、後ほど Sara と一緒に見るように、このアプローチから恩恵を受けるため、イベント駆動型アーキテクチャを使用したいですか？それもできます。データアーキテクチャにも使用できます。私は、ETL のために、またはデータレイクに向けてデータを引き出すために serverless サービスを使用している顧客が非常に多くいます。また、アーキテクチャのエッジでも使用できます。
Integration patterns は serverless を使用する私のお気に入りの方法の 1 つです。なぜなら、SaaS 製品はしばしば私たちが認識する必要があるクォータを持っているからです。システム内にあるのと同じスループットで毎秒それをハンマーで叩くことはできません。これらの種類のパターンとアーキテクチャは、serverless で使用できるものです。しかし、これ以上の前置きなしに、Booking.com がこのすべての素晴らしさをどのように取り入れているかについての議論を開始する Zeeshan を紹介させてください。
Booking.comの20年前の予約システムとモノリスの限界
Luca、serverless の基礎概念と関連するアーキテクチャパターンについて説明していただきありがとうございます。私の名前は Zeeshan で、過去 3 年間 Booking.com で働いています。私のチームの目標は 1 つだけでした。20 年以上前の予約システムを近代化することです。それはミッションクリティカルなシステムでした。しかし、始める前に、1 つ質問させてください。Booking.com を通じて旅行を予約したことのある人は何人いますか？何人か手を挙げていますね。ありがとうございます。私たちのプラットフォームを選んでいただきありがとうございます。
Booking では、人生は経験でできていると信じています。互いに共有する経験です。大きな経験も小さな経験も、だからこそ毎日何百万人もの顧客が Booking.com をプラットフォームとして選び、世界を体験しています。したがって、私たちのミッションは、すべての人が世界を体験しやすくすることです。その中核は、毎日何百万もの予約を処理する Booking.com のミッションクリティカルな予約システムによって支えられています。規模が大きいため、競争力を保つには、より速く機能を提供する必要があり、その機能は顧客に価値をもたらす必要がありますが、また迅速かつ確実に提供する必要があります。そうすることで、顧客は自分たちの経験を楽しむことができます。
しかし、エンジニアリングチームは常に改善とタイムトゥマーケットの短縮を求めるプレッシャーの下にあります。これは彼らに多くのプレッシャーを与えており、明らかにエンジニアリングチームにとってそれほど簡単ではありません。近代化した理由の「なぜ」の部分に入る前に、ビジネスが要求するペースで機能をより速く提供することを本当に妨げていたいくつかのことについて話したいと思います。
では最初のものから始めましょう。Booking.com は最初はモノリスでした。 Perl で書かれていました。始まった当初は、小さくて、まとまりのある、簡単なリポジトリでした。ビルドも簡単で、テストも簡単で、デプロイも簡単でした。しかし、機能とチームが増えるにつれて、クロスデペンデンシーが増加し、ビルドが遅くなり、テストが膨れ上がり、境界が曖昧になってきました。密結合により、変更は脆くなり、デプロイは苦痛になり、デバッグは悪夢になってしまいました。全体的には、それは大きな泥団子に成り果ててしまったのです。チームはその後、選択を迫られました。脆いモノリスシステムにパッチを当て続けるか、それともサービスに分割して近代化するか、です。
90以上の依存関係と密結合がもたらした技術的・組織的課題
チームが直面した課題をどのように解決したかを見る前に、彼らが直面していた具体的な問題について少し話しましょう。 私たちのレガシーシステムは 90 以上のデペンデンシーを持っていました。 これにはサービスとデータベーステーブルも含まれていました。それらのデペンデンシーの 80% 以上がハードデペンデンシーでした。つまり、何か障害が発生すると、他のシステムにカスケード効果が生じていたのです。
このような巨大なデペンデンシーのウェブは、Luca も言及していた弱いモジュール性をもたらしました。さらに、データレイヤーに漏れた境界があり、内部データモデルが他のサービスに公開されていたため、サービスはカプセル化を侵食していました。密結合した Perl モノリスだったため、 開発者は好きなところ、そしてデータが利用可能なところならどこにでもコードを追加していました。これは結合度の蔓延をもたらしました。異なるサービス間で使用される共有データモデルもあり、この過度な結合と広い影響範囲の結果として、単一の障害がカスケードし、モジュールは優雅に劣化することができませんでした。
私たちが直面したもう一つの課題は、予約ワークフローとデータ構造におけるドメイン分散でした。 異なるドメインからのロジックが蓄積されていました。価格設定、手数料、カスタマーサービス、メッセージング、不正検知など、その他多くのものが含まれていました。ドメイン境界は曖昧でした。例えば、予約ワークフローでは手数料が計算されていましたが、これは独立して行うことができたはずです。別の例では、予約システムが料金を計算してから、私たちが所有していないデータベースに書き込んでいたため、予約ドメインの外にありました。
これらの問題の多くは、共有所有権またはまったく所有権がない状態をもたらしました。 チームは頻繁に適切な所有者を見つけるのに問題に直面し、クリーンアップされずに残された多くのデッドコードを発見しました。これにより、停止中のルート原因分析を実行し、コードが何をしているかを知っている所有者を見つけることが困難になりました。私たちのシステムはベアメタルサーバー上で実行されていました。これには独自のメンテナンスの課題がありました。 ロジックが 1 つの巨大なサービスにバンドルされており、ロールアウトの変更はリスキーで、セキュリティパッチの適用、故障したサーバーの交換、更新の実行など、サーバーメンテナンスに多くの時間が費やされていました。
定期的な手動でのキャパシティチェックが必要でした。サーバーが正しく設定されており、負荷に対応できることを確認するためです。ある程度は自動化されていましたが、これに多くの時間がかかっていて、その時間を顧客向けの新機能開発に充てることができたはずです。これらは単なる技術的な問題ではなく、チームにも大きな影響を与えていました。チームは所有権に関連する問題に対処するのに多くの時間を費やしていて、これは楽しいトピックではありませんでした。これによってバーンアウト、チームのモチベーション低下、そして結果的なエンゲージメント低下につながりました。一方で、新しいチームメンバーのオンボーディングに4ヶ月かかっていて、その前の段階でも、ドメイン知識の50%を習得させるのに約50%の時間がかかっていました。
ドキュメンテーションが不足していて、システムは非常に複雑でした。この高い複雑性、不明確な所有権、そして複数のドメインが混在していることが、バグと障害につながり、チームの KTLO が増加していました。これらすべてが組み合わさって、チームが新機能開発に充てることができたはずの大きなエネルギーを消費していました。チームはこの状況は続けられないという判断に至りました。ちょうどその時期に、実装する必要がある大量の機能リストを受け取りました。チームは、持続可能で将来に対応できるようにするには、システムを現代化する以外に方法がないと判断しました。
North Star アーキテクチャの策定とAWS Serverlessへの決断
私たちは将来のニーズと、目的に適った状態を保つために必要な機能を検討し始めました。チームが予約ドメインでの実践的な経験から得た学習に基づいて、チームが経験していた問題をリストアップしました。そして、そのリストから本当に取り組む必要があると思われるいくつかのことを優先順位付けしました。それらの中には、未知のコードの分離、境界の定義、カップリングの除去などが含まれていました。そして、修正したいことの優先順位付けされたリストを使って、North Star アーキテクチャを考案しました。
North Star アーキテクチャ、つまり私たちのターゲットアーキテクチャは、不明確な境界、コードのカップリング、そして不要な依存関係の削減に関連する問題を解決することを目的としていました。私たちは高レベルのアーキテクチャを考案しました。これはプラットフォーム非依存的なもので、その時点ではクラウドへの移行について考えていませんでしたが、システムをモジュール化するアーキテクチャを設計し、そのためのさまざまなアプローチを検討していました。このアーキテクチャを手に入れた後、社内の多くのアーキテクト、クラウドアーキテクトを含む、そしていくつかのプリンシパルデベロッパーによってレビューされました。私たちの議論の中で、将来のアーキテクチャは段階的な変換を経るべきだという傾向がありました。最初のものから次のものへ、そして3番目のものへと段階的に進むのではなく。
AWS マネージドサービスに直接移行して、クラウドのメリットを享受すべきだという意見でした。私たちの要件の1つは、分離されたフローとモジュール化されたコードを持つことでした。AWS を見てみると、Step Functions と Lambda のオファリングが私たちが必要としていたものを提供していました。Lambda はロジックをより小さな再利用可能な関数に分割でき、Step Functions はこれらの再利用可能な関数を明確で分離されたワークフローにオーケストレーションできます。すべてこれらは、可観測性とモニタリングなどのボックスから出た機能を提供しながら実現できます。
私たちの全体的な方針は、ミッションクリティカルなワークロードを使ってサーバーレスの利用を先駆けることでした。しかし問題は、私たちのチームはクラウドの経験がなく、ましてやサーバーレスについては全く経験がなかったということです。ですから、チームがどのように進めるべきかは明確ではありませんでした。リーダーシップからサポートが提供されるという約束があったにもかかわらず、チームはサーバーレスについて懐疑的でした。
チームメンバーの中には「リスクを取るべきではない、リスクが大きすぎる」と言う人もいました。意見を持たない人もいれば、「やってみよう」と言う人もいました。彼らが持っていた仮定のいくつかは、AWS を学ぶのに時間がかかりすぎるだろう、Lambda 関数はパフォーマンスのボトルネックを生じさせるだろう、コストが高すぎるだろう、Booking.com の内部インフラストラクチャに接続するのは難しいだろう、そしてなぜこのような実験のためにミッションクリティカルなシステムを選ぶのかということでした。
しかし、エンジニアリングマネージャーとして、私はこれがチームの学習にとって大きな機会であることを認識していました。私はチームに異なることをするよう求め、AWS での実践的な経験を得ることを確認しました。また、これは私たちの内部クラウドチームがミッションクリティカルなワークロードから学び、このワークロードがサーバーレス上でどのように機能するかを見る絶好の機会でもありました。多くのチーム討論、一対一のミーティング、そして鼓舞するようなスピーチの後、チームを鼓舞するために最初の Lambda を書く必要がありました。
その後、チームは概念実証に取り組み始めました。概念実証のために、私たちは AWS Cloud から私たちのオンプレミスのサービスの 1 つに来るリクエストをテストするために非常にシンプルなユースケースを選びました。Lambda は私たちの内部依存関係の 1 つを呼び出し、その後いくつかのデータを取得します。私たちがテストしたかったのは、パフォーマンスの観点からどのように機能するか、そして私たちが作成しようとしていたリクエストのボリュームでコストがどのようになるかということでした。
これが機能したとき、チームの自信が高まりました。明らかになったことの 1 つは、Booking.com の内部インフラストラクチャに接続することは難しいだろうということでした。しかし、私たちはマネージドサービスの観点から非常に良い結果も見ました。この概念実証で後に知ることになったいくつかの欠けていた点がありました。例えば、マルチリージョンのデプロイメントや、インシデント管理やサービス間統合などの他の内部ツールへの接続方法をテストすることができませんでした。しかし、少なくとも、もし先に進むなら、それは機能するだろうという自信を得ることができました。
Proof of Concept での学習を踏まえて、決断が下されました。AWS serverless を使って現代化していくということです。そして Proof of Concept により、選択したソリューションが私たちにとって機能するという確信が得られました。 チームは serverless アーキテクチャを構築することに決めました。しかし、アーキテクチャを見る前に、Proof of Concept からの主な学習は何だったのでしょうか。
チームは AWS がオペレーショナルな部分の多くを処理してくれるため、ビジネスロジックにより多く集中できるようになったことが分かりました。私たちのチームがサーバーの管理やアップデートなど、そういったことに費やす時間を 5 パーセントから 10 パーセント削減できることに気付きました。他の AWS サービスとの統合はシームレスでした。例えば、後に Step Functions と接続しました。チームは時間をかけて serverless 上の最終的なソリューションを策定し、それが私たちのクラウドアーキテクトによってレビューされ、承認されました。
Step FunctionsとLambdaによる新システムとShadow Trafficアプローチ
では、このソリューションがどのようなものかを説明していきます。 左側には Booking インフラストラクチャが見えます。右側にも Booking サービスが見えます。そして中央には、私たちが構築した新しいソリューションと新しい予約システムがあります。 これらの Lambda 関数の 1 つが中央に見える Step Function をトリガーします。そして Step Function の内部には、異なることを行っていた 15 個の他の Lambda がありました。
また、DynamoDB を使ってリクエストを一時的に保存しました。データベースのサイズが増加しないようにそれに time-to-live を設定しましたが、これにより私たちの作業がより簡単になりました。Step Functions を通じて、必要に応じてリクエストから DynamoDB のデータにアクセスすることができました。私たちに必要なデータの部分だけを選択します。全体的に、非常に柔軟で疎結合されたアーキテクチャが実現されました。例えば、最後に SNS を使って異なる通知を異なる SQS キューにファンアウトしているのが見えます。そして反対側には、このキューから非同期で読み取っている別の Lambda があります。基本的に、私たちはシステムを疎結合にしていました。
全体的に、これが私たちが構築したアーキテクチャです。 ここで Step Functions の実行をハイライトしたいと思います。緑色のブロックに注目すると、上部の大きなブロックはこれらすべての Lambda 関数の並列実行を表しています。その実行が完了した後、左側の別の Lambda を呼び出し、それがさらに別の並列ブロックを呼び出します。ここで重要なのは、これらすべてのラインで、キャッチブロックであるということです。これは Step Functions に組み込まれているので、エラーハンドリングが組み込まれています。このコードをもう維持する必要がないため、これは多くの時間を節約します。
スムーズな道のりではありませんでした。多くの問題に直面しましたが、私たちはそれらを解決したいと考え、粘り強く対応しました。それらは体系的に解決されていきました。 私たちが直面した最大の問題の一つは Lambda のレイテンシーとコールドスタートでした。上に表示されているチャートについて説明します。これは、私たちのユースケースに最も適した設定を見つけるために実施した実験からのレイテンシーチャートです。左側には、0.5 GB のメモリを備えた provisioned concurrency が表示されています。中央には、1 GB のメモリを備えた provisioned concurrency が表示されています。右側では、Java を使用していたため SnapStart を使用しました。AWS は Lambda をウォームアップするためのソリューションとして SnapStart を提供しており、provisioned concurrency も同じ機会を提供しています。しかし、中央の設定が信頼できるものだと判断したため、1 GB のメモリを備えた provisioned concurrency を選択しました。
下のグラフを見ると、結果はまだ私たちにとって十分ではなかったことがわかります。私たちは 3,200 ミリ秒から始まりました。これは Lambda で得ていたレイテンシーです。しかし、下のセクションに SDK optimizations、Jakarta optimizations、その他の最適化が記載されているのが見えます。ここで私たちはコードを最適化して、Java 内のオブジェクトをウォームアップし、Java の初期化時間を削減しました。これにより、Lambda が既にウォームアップされているのと同じ効果を実現しました。これによってレイテンシーは 140 ミリ秒に削減され、非常に良い結果となりました。
チームがモダナイゼーションプロジェクトに取り組み始めたとき、別の問題に直面しました。私たちは開発環境という 1 つの環境しかなく、チームには 6 人がいました。AWS 内で個人用環境を作成するためのソリューションを考え出すために、クラウドチームと協力する必要がありました。彼らは AWS と協力して、私たちにソリューションを提供してくれました。それ以前は、チームはタイムスライシングを行っており、通信のオーバーヘッドが多くありました。このソリューションを早期に採用したため、その中にいくつかの問題があり、チームがさらなる課題に直面することになりましたが、時間とともにソリューションは成熟していきました。1 つのチームから 3 つのチームに拡大し、最終的には 25 人がこの環境を使用していました。内部の予約ツールの一部は、AWS での処理の設定の準備ができていませんでした。
いくつかの重要な機能が不足していました。例えば、マルチリージョンデプロイメントがありませんでした。私たちはそれをどのようにするのかわかりませんでしたし、カナリアデプロイメント、ロールバック、ホットフィックス、フィーチャーフラグをどのようにするかについて明確な戦略がありませんでした。これらはすべて適切な運用に不可欠です。また、コンプライアンスチームは本番環境のリクエストを承認することに少し抵抗がありました。これが初めてのことだったため、コントロールが整備されていることを確認したいと考えていました。それは数ヶ月間の説明と、それがどのように機能するのか、そして私たちのユースケースが何であるかについての何度もの往復を要しました。私たちは彼らのすべての懸念に対処する必要がありました。
最終的に、私たちは構築したものをテストしたいと考えました。前述したアーキテクチャを構築するのに 1 年ちょっとかかりました。 ほとんどの時間は依存関係の理解に費やされました。私たちはいくつかのキャパシティ制約を抱えており、内部の調整もありました。ですから、開発全体に時間がかかったわけではありません。基本的なユースケースを開発した後、このテスト方法と、このソリューションが本番環境で機能することを確認する方法について考え始めました。私たちは shadow traffic アプローチを採用することにしました。
Shadow traffic というのは、システムを最新化する際に機能のギャップを見つけるためのアプローチです。図で見ていただけるように、基本的には本番環境に来るリクエストのコピーを作成して、それを新しいサービスに転送し、その結果を比較するというものです。私たちも同様のアプローチを取りました。重複したリクエストが作成されて、それが最新化されたバックエンドに送られ、最後にレガシーバックエンドと最新化されたバックエンドからの出力が、私たちのデータ品質チェッカーによって比較されました。そのためのスクリプトを作成しました。そのスクリプトは出力レポートを生成し、そこに不一致が記載されていました。その情報に基づいて、私たちは 2 つのシステム間のギャップがどこにあるのかを特定することができました。
このアプローチには本当にたくさんの利点がありました。
Shadow traffic アプローチにより、反復的な開発ができました。新しい機能をテストするのに自信を持つことができ、前に進む自信を得ることができました。この実行中に、データ品質のギャップを特定し、また新しいシステムで 100% の shadow traffic を実行したため、システムのパフォーマンスチューニングもできました。1 から 100% にスケールして、全体的な負荷がどのように機能しているのか、そしてどのくらいのコストがかかるのかを見ることができました。すべての問題が 100% の shadow traffic で発生する可能性があることを理解するために、1 ヶ月間実行し続けました。また、コストについても良い見通しを得ることができ、将来のコストを予測することもできました。
実験的アプローチによる段階的移行と市場投入時間の短縮
本番環境に移行する際には、実験的なアプローチを go-live 戦略として使用しました。これは Booking で非常に一般的なものです。基本的には、トラフィックの一定の割合を新しいシステムに渡し、ベースとバリアント間でどのように異なるかを観察しました。会社のメトリクスが影響を受けず、ビジネスが影響を受けないようにしたかったので、実験的なアプローチを取りました。これは高リスクの移行のリスクを軽減し、実世界の問題をより早く探索し、ステークホルダーとの信頼を構築するのに役立つからです。
ミッションクリティカルなシステムだったため、実験的なアプローチを使用し、段階的にトラフィックをスケールしました。ここで見ていただけるように 1、10、30、45、90、100 という段階を作成しました。問題は、最初にこのトラフィックをどのように分割するかということでした。私たちはデータサイエンスチームと協力して、過去のデータを確認し、トラフィックを異なる支払いタイミングに分割する方法を見て、これが私たちが使用した基準です。もちろん、あなたのユースケースでは、あなた自身のユースケースに基づいて他の何かを見つける必要があるでしょう。
最終的に私たちが達成したかったことは実現できたのか？すべての努力は報われたのか？まず第一に、組織全体のための多くの技術的な機能を解放することができました。例えば、AWS からオンプレミスのサービスへの通信が可能になりました。Lambda は Kafka トピックに書き込むことができるようになりました。また、以前は利用できなかった内部のモニタリング、可観測性ツール、インシデント管理ツールとも統合することができました。さらに、特にオンプレミスのサービスと接続する際のサービス間認証のために Vault 統合も実現しました。
得られたメリットの一つは、オンボーディング時間の短縮です。新しい開発者が非常に早く生産性を発揮できるようになりました。新しい開発者が初月のうちに最初のマージリクエストを作成できるようになったのですが、これまでは 4 ヶ月かかっていました。豊富なリソースと充実したドキュメントが利用可能で、AWS の動作方法が非常に標準的だったため、人材のオンボーディングが高速化しました。開発者体験が向上しました。CloudWatch、メトリクス、X-Ray トレーシング、Step Function 実行ワークフローなど、すぐに利用できるツールが多数あるため、デバッグが高速化しました。
バグを発見した場合、数時間以内に根本原因分析を非常に迅速に実施し、最初の修正マージリクエストを作成することができるようになりました。これらすべてが開発者体験を向上させ、インシデント対応を高速化するのに役立ちました。また、市場投入までの時間も短縮されました。これは私たちが達成したかった主要なメトリクスです。アーキテクチャの俊敏性により、物事を素早く移動させることができます。特定の例として、Lambda の並列ブロック全体を非同期から同期に移行する必要がありましたが、それはわずか 2 週間で完了しました。システムが非常に柔軟で、物事を移動させるのが簡単だったため、私たちにとって大した問題ではありませんでした。
市場投入までの時間の短縮という点で、素晴らしい成果が見られています。ここで皆さんに質問したいのですが、Booking.com を使って Las Vegas への旅行を予約したことのある人はどのくらいいますか？皆さんの予約は 100% Booking の最新化されたシステムを通じて行われました。そのシステムは AWS Serverless に基づいています。チームは最近、新しいシステムでの 100% トラフィックというマイルストーンを達成し、古い予約作成エンドポイントを廃止しました。つまり、すべての新しい予約がこの新しいシステムを通じて行われているということです。このマイルストーンは、他のチームも私たちのプラットフォームを使用し、より迅速に機能を提供する道を開きました。また、変更とキャンセルのユースケースもあり、同じプラットフォーム上で非常に迅速にユースケースを提供しています。
まとめると、私たちの最新化の過程と、達成したかったこと、そして目標が何であったかについてお話ししました。AWS サービスがどのように変革に使用できるか、そして皆さんのニーズと使用例に何が適しているかを探索していただきたいという洞察が得られたことを願っています。最後に一つの引用句でお別れして、より広い業界経験に基づくサービスパターンについて詳しく説明するために Sarah をお招きします。
マイグレーションの7つのRとモノリス分解のパターン
ありがとうございます、Jason。私たちは今、Booking.com の Accommodation Reservation Backend、つまり ARB についての素晴らしいストーリーを聞きました。彼らがレガシーなオンプレミスシステムをフルサーバーレスアーキテクチャに現代化するための変革の旅を歩んだ方法についてです。彼らはこの飛躍を遂行する大胆な選択をしましたが、実は、これが AWS のお客様がマイグレーションと現代化を行う唯一の方法ではありません。
AWS では、マイグレーションパスウェイの 7 つの R と呼ばれるものを特定しています。Retain、Retire、Relocate、Re-host があります。また、Re-platform、Repurchase、Refactor もあります。Refactor は、ご想像の通り、今日の議論の主なテーマです。Refactor は本質的に、オンプレミスから AWS へのマイグレーションを行い、クラウドネイティブ機能の利点を解き放つためにサーバーレステクノロジーをすぐに採用するという飛躍を意味しています。重要なのは、万能なアプローチは存在しないということです。世界中のさまざまなサイズの企業は、自社のユースケースに適したもの、そして自社の要件に最も適したものを選択する必要があります。
先ほど示したスライドはテクノロジーについて述べていますが、ソフトウェアの現代化とアーキテクチャの現代化について考えるとき、それはテクノロジーだけではありません。テクノロジー、プロセス、そして人についてです。それを三角形として考えてください。この三角形のいずれかの側面が弱いと、他の側面と柱に影響を与えます。あなたの企業の場合、最初から 3 つの柱すべてが完璧ではないかもしれません。
人、プロセス、テクノロジーと言うとき、私が意味するのは、あなたの企業がオンプレミスで運用していた技術的およびビジネス上の文脈、そしてクラウドで運用することになる文脈について深い理解を持つ多分野横断的なチームが必要だということです。人々が迅速に意思決定を行い、反復的な進歩を可能にするプロセスが必要です。最後に、あなたの特定のユースケースに最も適したテクノロジーが必要です。万能なソリューションは存在せず、1 つの柱で経験する成功または問題は、他のすべてに波及効果をもたらす可能性があります。
実践的な例を通じて説明させてください。お客様は、自社のシステムまたはコードベースに対して monorepo を採用するか、複数のリポジトリを採用するかの選択に直面することがあります。表面的には、これは技術的な決定のように聞こえますが、もっと深く見てみましょう。Monorepo を採用することを決定すると、これには技術的な結果が伴います。この大規模なコードベースを管理するための既製のツーリングの可用性が低くなる可能性があります。実際には、これは、すぐに利用可能なものを使用するのではなく、コードベースを管理し、保守し、ゼロから構築するための独自の特定のツーリングを構築する必要があることを意味します。
プロセスの観点からすると、monorepoを持っているということは、trunk-based developmentを採用できるということになり、それがプロセスの進め方に影響を与えます。人的な観点からすると、monorepoを持っているということは、チーム間でのマージリクエストの頻度が高くなる、あるいはタッチポイントが増えるという結果につながる可能性があります。これがmonorepoの選択肢ですが、複数のリポジトリを使う場合、技術的な観点からすると、これらの異なるコードベースをより独立して管理するためのツールが最初から揃っています。プロセスの観点からすると、これはシステム間の通信のために厳密なAPIコントラクトを強制する必要があるかもしれないということを意味します。人的な観点からすると、これらのチームが異なるコードベースでより独立して動作するため、協力する頻繁な機会がないという結果につながります。
ご覧の通り、万能なアプローチというものは存在せず、あなたのユースケースに合ったものを選択することが重要です。この三角形を私たちの アプリケーションを現代化するためのガイド原則として保ちながら、高度に結合されたモノリスを疎結合なサービスの集合にどのように変換するのでしょうか。これを達成するにはさまざまな方法があります。
非常に有名なものから始めましょう。strangler fig patternです 。このパターンは、ホスト木をゆっくりと置き換えるこの植物のユースケースから名前が付けられています。名前が示す通り、これは段階的な現代化についてのものです。例えば、モノリスから離れてAWSへの移行を望むe-commerceの組織を考えてみましょう。彼らはどのようにしてこれを行うのでしょうか。最初のフェーズを見てみましょう。モノリスでは、異なるコア機能があります。product management、order management、そしてinvoicingです。最初は、これらはすべてオンプレミスにあります。
strangler fig patternの次のフェーズでは、企業は現代化のためのユースケースを特定します。この場合、invoicingです。このcoexistenceフェーズでは、何が起こるかというと、レガシーシステムと新しく現代化されたシステムが共存できるようにするルーティングレイヤーがあります。invoicingコンポーネントが現代化されてクラウドに移動されると、トラフィックはこれら2つの共存するシステムにルーティングされます。最初のフェーズが成功したら、他のすべてを段階的に移動させて、最終的にはすべてが新しく現代化されたアプリケーションになります。
次に私たちが通常特定するパターンはbranch by abstractionです。これは共有機能を現代化する際に特に価値があります。これは私たちが先ほど説明したパターンに似ているように聞こえるかもしれませんが、最初のものはより2つの異なるシステムでのルーティングと共存についてでした。これは同時に2つの実装を持つことの複雑さを抽象化することについてです。この場合、product management、order management、そしてinvoicing managementの機能を持つe-commerceの企業があります。私たちは、それらすべてが依存する共通の機能があることを特定しました。notification機能です 。
顧客が何かを購入する場合のことを考えてみてください。注文メールサマリーがあって、顧客に注文について知らせます。それはいろいろなことについてのものになります。請求書についてのものになることもありますし、カタログに追加された新しい製品について顧客に知らせることもできます。これは、これらすべてのサービス全体で共有される機能です。このパターンが行うことは、同時に2つの実装を持つことの複雑さを隠すことです。
次に、decomposed by business capability パターンがあります 。この場合、capability は order service または order management 機能になる可能性があり、ビジネス機能と capability によって情報を得られたアーキテクチャ境界を使用して最新化することを決定します。ビジネス capability は、最新化のマップになります。次に、decomposed by subdomain があります 。これは他のものと似ているように聞こえるかもしれませんが、わずかに異なります。
order notification について考えてみてください。order service があり、イベントを公開します。このイベントは、異なるものに関連する内部銀行システムの通知をトリガーします。アーキテクチャを最新化することを決定するとき、ビジネス機能は実際には注文がどこで処理されているかに応じて異なることに気付きます。US で発生する注文の場合、州に応じて異なるビジネスロジックが必要な注文があります。California は異なる規制を持つ可能性があります。
プライバシー通知、顧客データなどに基づいて異なる方法で行う必要があることがあります。例えば Europe では、GDPR コンプライアンスと Europe に関連する他のコンプライアンスがあるため、異なるビジネスロジックがあります。最新化プロセス中に、これはかなり異なることに気付きます。これが意味することは、会社として、subdomain がシステムのアーキテクチャ境界に情報を提供することを決定するということです。
この場合、AWS Lambda order service があり、イベントを公開します。その後、Amazon SNS があり、このイベントを US ベースの Lambda に伝播させます。これは異なるビジネスロジックを持っています。一方、Europe ベースの顧客向けに同様のアーキテクチャがあります。その後、このロジックをカプセル化して、US 顧客に影響を与えることなく、または逆にこのロジックを簡単に変更できます。
では、トランザクションによる分解についてお話しします。もう一度、注文機能について考えてみてください。モダナイズしようとするにつれて、顧客が注文を作成しようとするときのユーザー体験と、顧客が注文をキャンセルしようとするときのユーザー体験が少し異なることに気づきます。アーキテクトやビルダーとして、顧客が注文を作成しようとするときは、即座のフィードバックが必要です。ほぼ瞬時に返ってくるべきです。しかし、顧客が注文をキャンセルすることを決めると、それは時間がかかる一連のアクションをトリガーします。そして顧客は、そのオーケストレーションの結果がどうなるかをすぐに知る必要はありません。ただ、注文が送信されたということを知っていればいいのです。
このような異なるユーザー体験があなたのアーキテクチャの境界を決めます。トランザクション、つまり作成またはキャンセルに基づいて異なるアーキテクチャを分離して実装することで、この2つのことを異なる方法で処理できるようになります。上の最初のもの、注文の作成では、Amazon API Gateway、AWS Lambda、Amazon DynamoDB を使用できます。ユーザーが注文を作成し、データを DynamoDB に保存して、非常に迅速に応答を得ます。注文をキャンセルしたい場合は、大量のデータを処理し、異なるバンキングシステムや、場合によっては他のサードパーティシステムと通信する必要があります。これには時間がかかります。ですから、この場合、API Gateway と AWS Step Functions が必要になり、このオーケストレーションを管理します。
次に、チームベースのサービス分解があります。3つの柱、つまり人、プロセス、テクノロジーについて話したことを覚えていますか。このパターンは興味深いです。なぜなら、この場合、人があなたのアーキテクチャの境界を決めるからです。注文コードベースと注文システムに精通していて、それを所有するチームがあります。次に、製品機能とコードベースを管理するプロダクトチーム、そして請求チームと支払いチームがあります。これはあなたのモノリスを分解する興味深い方法です。
非同期通信パターンによる顧客体験の再定義とソフトウェアの成長
これまで、セミナーについて探索してきました。strangler パターンまたは branch by extraction パターンがモノリスの分解にどのように役立つかを見てきました。しかし、モダナイズの際に注目する価値のある別の重要な側面があります。それは、サービスがどのように相互に通信するかということです。モノリスを分割するにつれて、コンポーネント間の通信方法を、顧客体験を改善し、チーム間のコミュニケーションも改善する方法で再考することができるかについて考えてみてください。三角形は、プロセス、人、テクノロジーについてのものであることを思い出してください。
サーバーレスを採用することの重要な側面の1つは、ユーザー体験についてのあなた自身の仮定に異議を唱えることができるということです。また、システムがどのように通信すべきか、チームがどのように通信できるかについても異議を唱えることができます。これにより、全体的な顧客満足度、市場投入までの時間などを改善できます。e コマース組織の例に戻りましょう。プロダクトチームが新しいギフトコード機能を実装したいというアイデアを思いついたとしましょう。
皆さんのチームはギフトコードサービスを実装する必要があります。このギフトコードは、他の SaaS ベンダー内の他のサードパーティギフトコードシステムと通信する必要があります。ギフトコードは内部システムに接続される必要があります。例えば、ユーザーアカウントが引き換えに接続される必要があります。このギフトコードをリアルタイムで検証するには、CRM システム、つまりこのギフトコードを検証する外部システムが必要です。
同期的な世界を考えてみてください。ホリデーシーズンやピークシーズンの間に何が起こる可能性があるかを考えてみてください。顧客の視点から見ると、顧客は皆さんの e コマースウェブサイトにアクセスしてギフトコードを引き換えようとします。ギフトコードの検証と引き換えのプロセスは通常同期的ですが、これはピークシーズンやピーク期間中に問題になります。なぜなら、皆さんの CRM は、皆さんがコントロールできない外部 CRM かもしれず、それが困難を経験しているかもしれず、応答時間が長くなるからです。これは同期的な世界では、皆さん自身のシステムにも顧客のユーザーエクスペリエンスにも影響を与えます。これは良くありません。どのように考え直すことができるでしょうか。AWS のサーバーレスサービスを活用して、これをどのようにアーキテクチャできるでしょうか。
ここがサーバーレスが非同期パターンで輝く場所です。ギフトコードが入力されると、すぐに Amazon DynamoDB に保存します。DynamoDB ストリームは EventBridge Pipes をトリガーし、イベント伝播を処理します。システムは複数の外部システム全体でコードを検証する必要があります。ロイヤルティプログラムプロバイダーにポイント残高をチェックさせ、不正検出など。正当性を確認する必要があります。その後、EventBridge Pipes に依存して、ペイロードを変換し、CRM が必要とする CRM フォーマットに準拠させることができます。
コードが無効な場合、既存の通知サービスを通じて顧客に通知できます。一方、顧客は、これは非常に重要ですが、即座の応答を楽しむことができ、買い物を続けることができます。なぜなら、最初に同期的なフィードバックループがあるからです。この場合、そしてこれは重要ですが、すべてが非同期であるべきだと言っているわけではありません。これは非常に重要です。サーバーレスの美しさは、これらのパターンを混ぜることができるということです。この場合、買い物の部分でのギフトコード検証と充実のために EventBridge Pipes を非同期で使用しますが、その後、チェックアウト部分で同期 API 呼び出しに切り替えます。即座の会話が絶対に必要な場合にのみ同期呼び出しを使用します。
これは実装についてだけではありません。これはユーザーエクスペリエンスとシステム統合についての私たちの仮定を考え直すことについてです。時には最良のソリューションは、ビジネスコンテキストが許す場合、即座の一貫性を手放して最終的な一貫性を優先することです。最後に、Pipes は内部ユーザー管理サービスからのユーザーデータでイベントを充実させます。フローを再度見ると、Amazon API Gateway と AWS Lambda、DynamoDB があり、同期部分を処理して顧客エクスペリエンスを向上させます。その後、EventBridge に対するイベント伝播があり、非同期エクスペリエンスを処理します。これにより、私たちのシステムがどのように機能するか、顧客エクスペリエンスがどのようであるべきか、私たちのチームがどのように協力すべきか、何を所有するか、そしてこれらのアーキテクチャをどのようにモジュール化して、より高速な開発とより良いエクスペリエンスを実現できるかを考え直すことができます。
では、本日のモダナイゼーションについての議論をまとめていきましょう。 ここまで私たちが議論してきたことを振り返ってみます。分散システムは生きたシステムです。つまり、静的でも不変でもありません。皆さんの企業や組織が進化し成長するのと同じように、システムも進化し成長していくのです。皆さんのプロセスも変わりますし、人も成長していきます。セミナーを通じて、また宿泊予約についてのインスピレーションを与えてくれるストーリーを通じて、私たちは lift and shift を超えた思考ができるようになりました。Serverless を単なるテクノロジーとしてだけでなく、重要な戦略的決定として考えることができるようになったのです。
モノリスを分解するときのパターンについて見てきました。例えば strangler fig pattern のようなパターンが何であるか、そして何を分解してモダナイズできるかを理解しました。ビジネス機能によって分解することを考えてみてください。最終的に、私たちは DynamoDB、EventBridge、Lambda、API Gateway といった AWS サービスを使用することで、システムにおける非同期通信をどのようにアンロックできるか、そして自分たち自身の仮定にどのようにチャレンジできるかを理解しました。最後に、このセッションを本当に重要なことで締めくくりたいと思います。そして、これを皆さんが家に持ち帰ってもらいたいのです。 ソフトウェアを構築するのではなく、成長させてください。ソフトウェアは不変ではありません。ソフトウェアは進化するのです。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion