re:Invent 2025: Monzo Bankのマルチクラウドレジリエンス戦略とSEEMSフレームワーク
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Architecting resilient multicloud operations, feat. Monzo Bank (HMC201)
この動画では、AWSのPrincipal TechnologistであるClark RicheyとBruno Emer、そしてMonzo BankのSenior Staff EngineerであるAndrew Lawsonが、マルチクラウド環境におけるレジリエンス戦略について解説しています。複雑性とレジリエンスは敵対関係にあることを前提に、SEEMSフレームワーク（Single point of failure、Excessive load、Excessive latency、Misconfiguration and bugs、Shared fate）を用いた障害モードの分析手法を紹介。特にMonzoが構築したMonzo Stand-inという、Google Cloud上で稼働する18のサービスからなる最小限の重要機能プラットフォームの実装事例が詳述されています。プライマリのAWS環境とは完全に独立したシステムで、毎日実際の顧客トラフィックでテストを実施し、数秒以内に自動切り替えが可能な設計となっており、プライマリプラットフォームのコストの約1%で運用されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション開始：マルチクラウドとレジリエンスの関係性
こんにちは。本日はこのセッションにお越しいただきありがとうございます。ランチタイムの開催ということで、皆さんにとって厳しい時間帯だということは承知しています。まず最初に、簡単な質問をさせてください。手を挙げていただきたいのですが、カピバラが本当に好きな方はいらっしゃいますか?ええ、私もです。このトークとは何の関係もありません。ただ今日はカピバラにちょっとハマっているだけです。でももう一つ、トークに関連した質問をさせてください。ここにいる方で、マルチクラウドについて検討している、または組織で積極的にマルチクラウドを実践している方はいらっしゃいますか?素晴らしい。その手を少しの間挙げたままにしておいてください。レジリエンスを高めることを懸念してマルチクラウドを実践している方、または誰かからマルチクラウドがレジリエンスを高めるかどうか尋ねられたことがある方は、手を挙げたままにしておいてください。素晴らしい。それでは間違いなく正しいセッションに来ていただいています。
私の名前はClark Richeyです。AWSのPrincipal Technologistで、本日は私のチームの同僚である、もう一人のPrincipal TechnologistのBruno Emerと、そしてさらに重要なことに、Monzo BankのSenior Staff EngineerであるAndrew Lawsonと一緒に登壇しています。本日は皆さんにマルチクラウドレジリエンスについてお話しします。まず、いくつかの重要な概念を確認して、全員が同じ認識で同じことについて話せるようにします。 その一環として、SEEMSと呼ばれるフレームワークに移ります。これはレジリエンスと潜在的な障害モードについて構造化された方法で考えるためのものです。そこから、マルチクラウド環境でレジリエントになる方法についてのベストプラクティスをいくつか掘り下げていきます。そして皆さんがずっと待ち望んでいた部分、つまりAndrewがMonzo Bankが実際にどのようにアプリケーションでこれを実現しているかについてお話しする部分に入ります。
それでは先ほど申し上げたように、いくつかの重要な概念について全員の認識を合わせたいと思います。もし私がこの部屋を回って、マルチクラウドと言ったときに何を思い浮かべるか全員に尋ねたら、おそらく100通りの異なる答えが返ってくるでしょうし、それは全く問題ありません。ここAWSでは、マルチクラウドについて話すとき、実際に複数のクラウドサービスプロバイダーでアプリケーションを運用している組織のことを指しています。例えば、すべてのアプリケーションがAWSにあるだけで、誰もがそうであるようにOffice 365を使っているという場合、それは私たちが話していることではありません。実際に複数のクラウドサービスプロバイダーで自社のビジネスアプリケーションを運用していることを指します。AWSでは、マルチクラウドとは人、プロセス、そしてテクノロジーが一体となって、意図的な方法でビジネス目標の達成を支援することだと考えています。本日はもちろん、そのテクノロジーの側面に焦点を当てますが、マルチクラウド環境でレジリエントであることに関連する人とプロセスについても触れます。
マルチクラウドは本質的にレジリエンスを高めるのか？複雑性との関係
Clarkがマルチクラウドとその意味について話していましたが、皆さんが自問するかもしれない自然な質問は、レジリエンスについてはどうかということです。なぜなら私たちはそれについて話し始めましたし、これはセッションのタイトルにも入っているからです。そして実際のところ、マルチクラウドについて話すとき、これは本質的に全体的なレジリエンスを高めるものではありません。レジリエンスと複雑性に関しては、それらは実際には敵対関係にあることを私たちは皆理解しています。複雑性が増すと、実際にはレジリエンスが低下する傾向があります。なぜなら途中で失敗する可能性のあるものが増えるからです。そしてこれは私たちが望んでいることではありません。
しかしこれは、マルチクラウドが役に立たないということではありません。マルチクラウドの実装が実際に全体的なレジリエンスを高めるのに役立つ、または全体的なレジリエンスに関して必要な目標を達成するのに役立つ特定の状況があります。例を挙げましょう。ある国のリージョンでワークロードを実行していて、そのクラウドの主要なクラウドサービスプロバイダーがその国に1つのリージョンしか持っていないとします。そしてディザスタリカバリソリューションを構築する必要があり、例えば規制上の必要性からデータをその国の外に出すことができないとします。さて、このケースでは、マルチクラウドは非常に有効な答えになります。これは実装することで、ディザスタリカバリの実践を実装するのに役立ち、それによって全体的なレジリエンスを高めるのに役立つものです。
そして、ここにいる皆さん全員がもっと詳しく聞きたいと思っていることは分かっています。そして、Monzoがどのようにそれを実現したかについて話してくれるAndrewがいます。落ち着いて、チャンネルはそのままで、ここに留まっていてください。数分後にAndrewにマイクを渡します。Monzoがどのようにそれを実現したかという素晴らしいストーリーを聞くことができますが、その前にもう少しだけ私たちと一緒にいてください。
そして、Clarkがやったのと同様に、私もレジリエンスとは何かについて話すことから始めたいと思います。そうすることで、概念について皆さんが同じ認識を持てるようにしたいのです。レジリエンスについて話すとき、私たちはアプリケーションスタック全体において、障害を防止し、軽減し、そしてできるだけ早く復旧するという概念について話しています。つまり、レジリエントなアプリケーションとは、障害の発生を防ぐアプリケーションです。もし障害が発生する場合は、それを軽減し、影響範囲を縮小し、そして実際に障害から復旧して、できるだけ早く通常の運用状態に戻ることができるアプリケーションです。
AWSのレジリエンス思考：高可用性、ディザスタリカバリ、そしてResilience Life Cycle Framework
AWSにおけるレジリエンスの考え方は、実際にこのメンタルモデルに従っています。このメンタルモデルをここで皆さんと共有したいと思います。そうすることで、全員が同じ認識を持ち、私たちがどのように考えているかを理解できるようにしたいのです。実際のところ、私たちはレジリエンシーを単一のもの、つまり実行する単一のアクションとして理解していません。これは実装すれば、アプリケーションスタックで発生する可能性のあるすべての問題を魔法のように解決したり、修正したり、軽減したり、予測したりするようなものではありません。
実際には、さまざまな障害モードやさまざまなカテゴリーの障害に対処するのに役立つ、異なるプラクティスがあります。その中で最初にお話ししたいのは、高可用性という概念です。高可用性について話すとき、一般的にHAと呼ばれますが、プライマリサイトにワークロードを配置し、単一障害点という概念を回避することについて話しています。つまり、プライマリサイトを使用してほぼすべてを複製しているということです。これは、アプリケーションが直面する可能性のある最も一般的な日常的な問題に対処するのに役立ちます。
次にお話ししたいプラクティスは、ディザスタリカバリ、つまりDRの概念です。これは前のセッションですでに触れました。DRのアイデアは本質的に、アプリケーションまたはアプリケーションの一部を実装する別のサイトを持つことから生まれています。そして、プライマリサイトに重大な問題が発生した場合、そのセカンダリサイトでワークロードを実行し始めることになります。つまり、ここでは2つの異なるサイトについて話しているのです。
そして繰り返しになりますが、私が先ほど申し上げ始めたように、私たちはレジリエンスを単一のアクション、単一のものとは捉えていません。これらのプラクティスは必要です。私たちはそれらを信じていますが、同時にお客様としては、CI/CD、オブザーバビリティスタック、デプロイメント、プラットフォームの管理といった概念を考え抜く必要があることも理解しています。そして、すべてをレジリエントな方法で行う必要があります。ですから、これは本当にHAとDRのプラクティス実装の両方に浸透するものなのです。
そして、これは私たちAWSがお客様に伝えるだけで、お客様自身で解決してもらうというものではありません。実際に、お客様がここでのレジリエンスという概念をナビゲートするのを支援するための追加のメカニズムを作成しました。今日最初にお話ししたいのは、私たちが発表したものです。確か約2年前にリリースしたもので、Resilience Life Cycle Frameworkと呼ばれています。
レジリエンスについて考えるとき、私たちはこれがソフトウェア開発ライフサイクルのさまざまな領域に組み込まれる必要があるものだと理解しています。レジリエンスは、ソリューションをアーキテクトするときに存在する必要があるものであり、ソリューションをエンジニアリングするときに存在する必要があるものであり、ソリューションを運用するときに存在する必要があるものです。そのことを考え抜き、お客様がこれをナビゲートするのを支援するために、私たちはLife Cycle Frameworkを作成しました。これは実際に5つの異なるステージで構成されており、お客様がソフトウェア開発ライフサイクルに沿って各フェーズで何をする必要があるかを考えるのを支援することを目的としています。
まずSet Objectivesフェーズから始まります。これはよりビジネス的な会話です。次にDesign and Implementに進み、Evaluating Tasksに進み、Operateに進み、最後にRespond and Learnです。これはすべてが本番環境にあるときで、実装できる多くのプラクティスを呼び出します。しかし、フレームワーク自体を持つことよりも重要なのは、これがすべて文化の概念と密接に結びついていることを理解することです。私たちはこれを文化に組み込みたいのです。そうすることで、システムを構築するとき、それに関わるすべてのチームがレジリエンスについて考えるようになります。
SEEMSフレームワーク：5つの能力と障害カテゴリー
さて、お話ししたいもう一つのリソースは、SEEMSフレームワークのアイデアです。Clarkがアジェンダでこれについて話していたのをご覧になったと思いますが、それが帰着するところは、ワークロードがどのように失敗する可能性があるか、または特定のワークロードがレジリエントと見なされるために必要な能力は何かを考えることです。私たちは、レジリエントと見なされるためには、すべてのワークロードが5つの特定の能力を持つ必要があることを理解しています。冗長性について話しています。十分なキャパシティを持つことについて話しています。ワークロードがタイムリーに回答や応答を提供することについて話しています。これを私たちはtimely outputと呼んでいます。ワークロードがまさにシステムに期待することを実行することについて話しています。そして、ワークロード内に正しい障害分離境界を実装することについて話しています。
これらのカテゴリーが一致しない場合、私たちが失敗のカテゴリーと呼んでいるものが発生します。これはつまり、私たちがSEEMSと呼んでいるものです。基本的に、これらの失敗のカテゴリーは、これらの能力が一致しない時に起こることなんです。システムに冗長性がない場合、単一障害点という概念が見られることになります。追加の容量を処理するのに十分な処理能力がない場合、過剰な負荷と呼ばれるものが発生します。ワークロードがタイムリーに応答していない場合、過剰なレイテンシーが見られることになります。ワークロードが本来すべきことをしていない場合、これは非常に多くの場合、設定ミスやバグが原因で起こります。そして障害が実際に障害分離境界を越えている場合、私たちは共有運命という概念が見られることになります。これが本当にSEEMSフレームワークがどのように構成されているか、そしてどこから来ているかということです。
ここでもう一つ触れておきたいのは、この特定のセッションでは主にこれがどのように機能するか、そしてディザスタリカバリの実践のためのマルチクラウドアプローチに焦点を当てていくということです。アクティブ-アクティブのマルチクラウドについて話しているわけではありません。これは今日カバーする内容ではありません。私たちは間違いなく、ディザスタリカバリの実践をどのように構築するか、そして複数のプロバイダーにまたがってディザスタリカバリの実装を構築する際に考慮すべきことについてお話しします。
複雑性はレジリエンスの敵：冷蔵庫の例と障害分離境界、そしてライフボート戦略
AWSでは、複雑性とレジリエンスは敵であるという言葉があります。これはどういう意味でしょうか？では、例えを挙げてみましょう。会場を見渡そうとすると、難しいですね。ここにいる皆さんの中には、おそらくこのような冷蔵庫を持っていた、あるいは親や祖父母が持っていたという方もいらっしゃるかもしれませんね。そうでしょう？これらは本当にシンプルな装置でした。背面にフロンガスの入ったコイルとファンがありました。本当に良いものであれば、中に電球があったかもしれません。それだけです。非常にシンプルで、永遠に持ちました。20年から30年、問題ありませんでした。故障する可能性のあるものがほとんどなかったんです。
一方、私はこのような冷蔵庫を持っています。朝、階下に降りてくると、文字通り冷蔵庫がソフトウェアアップデートを実行しているのが見えることがあります。そのたびに、まだ動く冷蔵庫があることを祈りながら指を交差させています。毎日、食べ物がまだ冷たいと、感謝しています。これは10年、20年、30年も持ちません。毎日動き続けているのが奇跡です。つまり、クールですか？はい、でもレジリエントですか？他の冷蔵庫ほどではありません。
なぜでしょうか？繰り返しになりますが、複雑なシステムでは、それが冷蔵庫であれソフトウェアであれ、より多くのものが故障する可能性があります。より多くのものは、より多くの潜在的な障害点を意味します。これが、複雑性がレジリエンスを低下させる、またはレジリエンスの敵であると言う時の意味です。そしてもちろん、私たちは分散された世界で構築することが、マルチクラウドの世界は言うまでもなく、本質的に複雑であることを知っています。
しかし、良いニュースもあります。その良いニュースの一つが、私たちが障害分離境界と呼んでいるものです。これは私たちがAWSアーキテクチャの内部で提供しているもので、他のクラウドサービスプロバイダーも同様に持っています。障害分離境界の考え方は、これらはインフラストラクチャやアーキテクチャに本質的に備わっている構造であり、障害が発生した場合、その障害がその境界内に封じ込められるというものです。マルチクラウドについて話しているので、ここで取り上げる障害分離境界は、クラウドサービスプロバイダーのものです。クラウドサービスプロバイダーは本質的に障害分離境界なのです。
ここにAWSと、皆さんが選ぶもう一つのあまり好きではないクラウドサービスプロバイダーの図があります。そして、もし何かが起こったとしましょう、例えば、怒った火の蜂がそのプロバイダーに現れたとします、それは問題になる可能性があります。しかし、障害分離境界であるため、AWSは影響を受けません。逆に、公平を期すために言うと、AWSにも怒った火の蜂が現れる可能性はあります、それは良くないことです。そして同じように、もう一方のクラウドサービスプロバイダーは、障害分離境界のおかげで、影響を受けません。
なぜそれが重要なのでしょうか？なぜ私はそれを気にする必要があるのでしょうか？では、マルチクラウドレジリエンスを実現するための実際のベストプラクティスについて話し始めましょう。ここに私の定常状態のフルワークロードがあります。これは、最も重要な機能から最も重要度の低い機能まで、ビジネスを運営するために行うすべてのことであり、選択したクラウドサービスプロバイダー上で実行されています。すべてが順調で、良好で、物事はうまくいっていますある日まで、そうではなくなります。
そして、Brunoが先ほど述べたように、私の場合、データ主権やデータ保護などの規制要件があるため、そのデータを別の国に移動することはできません。そして、私が選択したプライマリクラウドサービスプロバイダーは、その国に別のリージョンを持っていません。そこで救命ボート戦略の登場です。私は定常状態の最小限の重要な機能をもう一方のクラウドサービスプロバイダーで起動します。先ほど話した障害分離境界により、定常状態のフルワークロードをダウンさせた原因が、もう一方のクラウドサービスプロバイダーで私に影響を与えることを防ぎます。そして、定常状態のフルワークロードを修復している間、ビジネスを維持し機能させるために本当に必要な、コアとなる重要なビジネスサービスだけを実行します。
一般的に、マルチクラウドとマルチクラウドレジリエンス戦略について考える際には、選択したクラウドサービスプロバイダーがレジリエンス、障害分離境界、およびプライマリクラウドサービスプロバイダー内でレジリエントであるために役立つそのプロバイダー固有の他の機能のためにどのようにアーキテクチャされているかを理解することが本当に重要です。そして、それについて考えていく中で、私たちがユーザーストーリーまたはユーザージャーニーと呼ぶものを使って考えることを強くお勧めします。その考え方は、顧客やユーザーがビジネスの観点から、ビジネス目標を達成するためにサービスまたは一連のサービスを通じてエンドツーエンドで実行する具体的なアクションについて考えるというものです。これを言うのは、ビジネスにとって何が重要で、そのビジネス機能を実現するために実際にどのサービスが機能している必要があるかを、トップダウンのビジネスの観点から考えることができるようになるからです。
単一障害点（SEEMS の S）：通信、CI/CD、セキュリティ、ネットワーク接続の考慮
それでは改めて、何を実装する必要があるのか、このライフボート戦略を構築する際に、あるいはセカンダリプロバイダーでDRを使用する場合でも、ワークロードを分散させる際に注目すべき点について、皆さんに考えていただきたいと思います。そして、特にSEEMSの最初のS、つまり単一障害点について話すとき、アプリケーションコンポーネントに注目しがちであることは理解しています。しかし、ここで少し視野を広げて、単一障害点が問題になり得る他の領域についても考えていただきたいと思います。
最初に触れたい領域は、システムの通信について本当に考えることです。これは必ずしもクラウドプロバイダー間のシステムの通信ということではなく、ユーザーがどのようにシステムにアクセスするのか、システムがどのように依存関係にアクセスするのか、あるシステムがセカンダリプロバイダーにデプロイしている最小システムの一部である可能性のある他のシステムとどのように通信するのかについて考えてください。そしてこのため、DNSのようなインフラストラクチャコンポーネントに単一障害点を持たないようにすることが極めて重要です。DNSは、そのように考えると、通信のバックボーンと言えるものですから。
もう一つ避けなければならないのは、CI/CDパイプラインに関連する単一障害点を持つことです。これについて考えるとき、そしてClarkが先ほど挙げたAWSと異なる障害分離境界の例を使うと、これらの異なるCSP全体でデプロイメントを実行できる能力を持ちたいですし、それを独立して行えるようにしたいのです。CI/CDが異なるプロバイダーで異なる方法でシステムをデプロイする能力に影響を与えることは望ましくありません。ですからCI/CDについて考えてください。セキュリティコンポーネントについても確実に考える必要があります。最も避けたいのは、DRをアクティブ化したのに、システムにアクセスする必要があるのにできない、なぜなら認証フローがプライマリCSPにあり、何らかの形で障害の影響を受けているという状況です。
ですから、認証プロセスについて考えてください。使用するAuthNやAuthZリクエストの目的を果たすシステムについて考えてください。そして最後に、ネットワーク接続について確実に考える必要があります。システムがどのように相互作用するのかを考えてください。ユーザーがどのようにセカンダリCSPに接続するのかを考えてください。オンプレミス環境がセカンダリCSPとどのように通信するのかについても考えてください。単一障害点を持ちたくありません。すべての通信が流れる中心的な場所があって、問題が発生したときにその中心的な場所も影響を受けるという状況は避けたいのです。ですから、これらは本当にいくつかの事柄、いくつかの領域であり、皆さんに考えていただき、そこに単一障害点を持たないようにしていただきたいと思います。
過剰負荷（SEEMS の E）：キャパシティ管理とクォータ制限への対処
次にEは過剰負荷についてです。過剰負荷が各クラウドサービスプロバイダーにおける各アプリケーションにどのような影響を与えるかを理解することが重要です。もちろん、プライマリクラウドサービスプロバイダーにおいて可能な限り回復力を持つことをお勧めしたいですし、その一部として、そのアプリケーションが過剰負荷をどのように処理するか、その状況に対処するために負荷削減を行ったり、キャパシティをスケールアップしたりするためにどのようなメカニズムを用意しているかを理解することが含まれます。しかし、ライフボート戦略においても同様にそれを用意しておくことが等しく重要です。ある時点でそのライフボートを起動してフェイルオーバーせざるを得なくなったとき、まったく無関係な理由で予期しない顧客の急増が発生する可能性は十分にあります。ですから、そのライフボートは、プライマリアプリケーションと同じように過剰負荷に対処するキャパシティを持つ必要があるのです。
そして、これら2つのクラウドサービスプロバイダー間に、どのようなデータアクセスパターンが存在するのか、もしあれば、それを理解する必要があります。つまり、2つの別々のアプリケーションを起動している間も、例えば、両者の間で同期されるデータがある可能性があり、それが各アプリケーションの負荷にどのような影響を与えるかを理解する必要があるのです。すべてのクラウドサービスプロバイダーは、クォータとサービス制限を提供しており、これらは特定の期間にどれだけのサービスを使用できるかを管理しています。
各クラウドサービスプロバイダーはそれを少しずつ異なる方法で処理しているため、各プロバイダーにおいて、自分たちの制限、それらがどのように設定されているか、そしてそれが過剰な負荷を管理するための戦略とどのように関連しているかを認識しておく必要があります。このトークの残りの部分で、私たちがこれについて多く話しているのを聞くことになるでしょう。これらをテストすることは非常に重要です。複雑な環境なのです。今や複数のシステムがあり、これらの各システムが過剰な負荷に対してどのように応答するかを知る唯一の方法は、定期的に高負荷に対してテストすることです。
過剰なレイテンシー（SEEMS の2つ目のE）：キャッシング、データアクセスパターン、依存関係の測定
それでは、SEEMSの2つ目のE、過剰なレイテンシーについて見ていきましょう。レイテンシーは興味深いものです。なぜなら、多くの場合、お客様とレイテンシーについて話をしていると、システムは動いているけれど少し時間がかかっているだけだ、という考え方があるからです。しかし現実には、システムがユーザーが待つ意思のある時間よりも長く応答または処理に時間がかかっている場合、ユーザーの視点からすると、システムは利用不可能なのです。つまり、過剰なレイテンシーとレジリエンシーの間には直接的な関係があり、私たちは間違いなくそれについて考える必要があります。
レイテンシーに対処するために、いくつかのヒントやコツを共有できます。その最初のものは、可能な限り常にキャッシングメカニズムを活用することです。それらはレイテンシーを削減し、システムをよりスケールアウトできるようにする傾向があります。キャッシングメカニズムを適切に活用するとはどういうことかというと、実装する際に、いわゆるバイモーダル動作を避けることを考える必要があるということです。バイモーダル動作とは何を意味するかというと、システムが接続を受け取るたびに、ある動作を提供し、ある振る舞いを示すということです。パスの中で何かが変わった場合、システムが異なる動作をすることは必ずしも望ましくありません。システムには一貫して動作してほしいのです。追加の環境で何が起こっているかは関係ありません。
例えば、キャッシングメカニズムを実装している場合、ユーザーはキャッシュからデータを取得し、それは高速です。しかし、キャッシュに問題があったらどうでしょうか？DR環境をアクティブ化したらどうでしょうか？キャッシュはコールドな状態で起動するため、データはまだロードされていません。アプリケーションがデータベースにデフォルトで接続し始めたらどうでしょうか？ユーザーは追加のレイテンシーを目にする可能性があり、つまりシステムは異なる状況下で異なる動作をすることになります。ですから、キャッシュを実装する場合は、常にそれを考え抜くことを忘れないでください。バイモーダル動作の概念を避けたいのです。これが適切に使用するということの本当の意味なのです。
もう一つは、データアクセスパターンを理解することです。データがどこから来て、どこへ行くのかを理解する必要があります。エンドユーザーや、もしあなたが依存関係として使用されている場合は下流システムに対して、どのような情報を共有しているのかを理解する必要があります。なぜなら、データアクセスパターンを理解することで、それをどのように改善し、そのコミュニケーションのレイテンシをどのように削減するかについて考え始めることができるからです。
依存関係について言えば、もう一つ非常に重要なことがあります。特にライフボート戦略を採用する場合ですが、外部依存関係へのレイテンシを測定する方法を理解することです。これが意味するのは、プライマリCSP上で実行している場合です。あなたのシステムには、環境内に存在しない依存関係があります。例えば、サードパーティの依存関係だとしましょう。DRを有効化して、セカンダリCSPにある最小環境に移行します。セカンダリCSPには同じ依存関係がありますが、その依存関係はアプリケーションと一緒に移動していません。このケースで何が起こるかというと、これらの依存関係が何であるか、アプリケーションの動作がどうなるか、そしてライフボート戦略を使用してDRを有効化する場合にアプリケーションと一緒に何を移動する必要があるかを理解できるように、これをマッピングすることが極めて重要です。
そして最後になりますが、Clarkが前のEでこれについて言及しました。私も再度これについて言及します。これをどのように処理し、システムにどのように影響するかを理解するための最良の方法は、テストを通じてです。ですから、負荷をかけてシステムをテストすることは絶対に必要ですが、レイテンシにも注意を払う必要があります。最小環境でもシステムをテストして、レイテンシに何が起こるかを確認する必要があります。オブザーバビリティプラットフォーム上でそれに関する特定のメトリクスを持ち、そのような状況下でシステムがどのように動作しているかを検証するためにテストを行う必要があります。
設定ミスとバグ（SEEMS の M）：オブザーバビリティと自動ロールバックの重要性
そしてMは私たちを設定ミスとバグに導きます。これは間違いなく、すべての分散システムにおける障害の最も一般的な原因です。そして、非分散システムについても同じことが言えると私はあえて言いたいと思います。私は知っています。なぜなら私はソフトウェアエンジニアで、コードを書いてすべてのテストが一発で通るときは、どこかで本当に何か間違ったことをしたと分かるからです。私たちは人間としてソフトウェアを書き、人間としてそれを設定し、そして間違いを犯します。これらの間違いは、不適切なデプロイメントや、システムをダウンさせる設定ミスを引き起こす可能性があります。ですから、システムの非常に優れたオブザーバビリティを持ち、特にソフトウェアのデプロイメントや設定の変更が行われているときに、システムへの影響が何であるかを理解したいのです。
何か悪いことが起きている場合、それはその変更に関連している可能性があるでしょうか？もしそうなら、その変更を自動的にロールバックして、既知の最後の良好な状態に戻すプロセスを用意しておきたいのです。事後に、何が間違っていたのかを把握することができます。その瞬間に私が気にかけているのは、ビジネスを復旧させて稼働させること、そしてその不適切な変更や設定ミスによる影響範囲を削減することだけです。
これらの新しいコードリリースや設定変更を、これまでお話ししてきた障害分離境界に確実に合わせていきたいと思います。フルワークロードと最小限の重要機能のために完全に別々のアプリケーションを用意している理由の一つは、これらの障害分離境界を意図せず侵害しないようにするためです。もし同じアプリケーションを異なる場所に配置していて、不良なコードデプロイメントがあった場合、今度は2つの場所に不良なコードが存在することになり、両方に同じコードを同時にデプロイすることでこれらの障害分離境界を結合してしまったため、複数の場所でダウンすることになります。
先ほど申し上げたように、デプロイメントだけでなく一般的に言って、オブザーバビリティは障害分離境界に沿ったものでなければなりません。各CSPのアプリケーションが正常かどうかを常に監視したいですし、その情報、つまり入ってくるメトリクスが実際にどこから来ているのか、どのアプリケーションから、どのCSPからなのかを理解する必要があります。もちろん、各クラウドサービスプロバイダーと各下位環境で徹底的にテストを続けていきます。つまり、両方のクラウドサービスプロバイダーの両方のアプリケーションに対して、テスト、統合テスト、ステージング、プロダクション前環境などを用意することになります。
共有運命（SEEMS の S）：障害分離境界の維持と人・プロセス・テクノロジーの統合
そして、SEEMSの最後のS、shared fateについてです。覚えていらっしゃると思いますが、このプレゼンテーションの中で私のお気に入りのスライドは、境界があって、問題が個々のCSP内に封じ込められるというものでした。これがまさに私たちが話していることであり、ライフボート戦略を実装する際、あるいは実質的にあらゆるタイプのディザスタリカバリを実装する際に達成したいことです。この場合、問題が一つのCSPから別のCSPへカスケードすることは望んでいません。
ディザスタリカバリを起動する際には、最小限のシステムが、ディザスタリカバリの起動を引き起こした問題の影響を受けることなく、独立して稼働していることを望みます。それを実現するための第一のことは、CSP間の依存関係を避けるべきだということです。つまり、システム間のトラフィックをできるだけ最小限に抑えたいのです。一つのCSPに配置されているアプリケーションが、別のCSPに配置されているアプリケーションを呼び出すようなことは避けたいのです。これがある時点で必要になる可能性があることは理解していますが、できる限り最小限に抑えたいと思います。プライマリ環境が何らかの理由で影響を受けたり障害が発生したりした場合、セカンダリ環境が完璧に動作することを望むため、そのような依存関係は持ちたくないのです。
これを実現するもう一つの方法は、常にデータをアプリケーションと一緒に移動させることを忘れないでください。つまり、プライマリプロバイダー上の、プライマリCSP上にあるフルワークロードには、アプリケーション層があり、データベース層があるかもしれません。アプリケーション層に問題がある場合、アプリケーションとデータの両方を移動させたいのです。アプリケーションだけを移動させて、データを元の場所に残しておくようなことはしたくありません。これにはいくつかの理由があります。明らかに、アプリケーションが一つのCSPにあって、データベースが別のCSPの反対側にある場合、追加のレイテンシが発生する可能性があります。望まない通信を実装してしまう可能性があります。そして繰り返しになりますが、プライマリCSPの問題によっては、実際にセカンダリ側のシステムがダウンする可能性があります。ですから、それを使用したくないのです。
もう一つのプラクティスは、CSP間で常に可視性を実装することを忘れないでください。つまり、CSP 2はCSP 1のステータスを理解できる必要があり、その逆も同様です。基本的に避けたいのは、プライマリCSP上にあるシステムが正常に動作していると伝えてくるだけの状況です。もちろんこのデータは重要ですが、それを外挿したいわけです。外部からシステムがどのように動作しているかを測定し、理解したいのです。これがまさに差分オブザーバビリティという概念と呼ばれるもので、このタイプのパターンを実装する際、このタイプのデプロイメントを実装する際に極めて重要です。
そして繰り返しになりますが、必ず共有依存関係をマッピングしてください。例えば、プライマリCSP上で動作しているシステムがオンプレミスに依存関係を持っているとします。それをアクティベートして、セカンダリCSPにシステムを移動します。依存関係はまだオンプレミスにあります。それらがどれなのかを知りたいですよね。接続性があるかどうかを理解したいですし、2つ目のシステムがその依存関係とどのように通信するのかも理解したいわけです。
ですからここでは、それらがどのように機能するかを認識し、その依存関係への最終的な影響を依存関係内だけに封じ込める方法をどのように軽減できるかを認識することが重要なのです。これがSEEMSフレームワークとそのベストプラクティスについてお話しする内容のほぼすべてです。
マルチクラウドにおけるレジリエンスのベストプラクティスをまとめますと、繰り返しになりますが、テスト、継続的な、継続的なテストです。複雑なシステムですから、テストはこれまで以上に重要です。オブザーバビリティ。BrunoもI私も、オブザーバビリティのさまざまな側面について言及しました。オブザーバビリティは、クラウド上で分散システムを運用する上で、最も困難で微妙な側面の一つです。もちろん、マルチクラウド環境ではさらに困難になります。これには時間がかかることを覚悟してください。1回目や2回目で正しくできるわけではありません。これは旅なのです。メトリクスを取得し、どれだけうまくいっているかを測定し、そして各インクリメントで少しずつ改善していくことを決意してください。これはライフサイクルなのです。
そしてオートメーション。オートメーションは1つのクラウドでも2つのクラウドでも絶対に重要ですが、繰り返しになりますが2つの場合はさらに重要になります。何かが起こった場合、障害が発生した場合、私のディザスタリカバリプラン、例えばライフボート戦略の起動などが自動化されていることを確認したいのです。そうすることで、その障害から回復するのにかかる時間を短縮できます。そしておそらくさらに重要なのは、高ストレスの期間中に人間が多くの手動ステップを実行してミスを犯す機会を減らすことができるということです。
それでは、ベストプラクティスの続きですが、SEEMSフレームワークをベースラインとして、今お話しした内容を振り返ってみると、私たちはテクノロジーについてかなり多くのことをお話ししました。DNS、認証について話しましたし、データベースとそのレプリケーション方法についても話しました。しかし、このタイプのパターンを実装する際には、適切なサービスや適切なテクノロジースタックを選ぶだけの問題ではないということを、非常に明確にしておきたいと思います。私たちは間違いなく、人、プロセス、そしてテクノロジーをビジネスニーズと非常に密接に連携させることについて話しているのです。
私たちには間違いなく人が必要ですし、チームに、オペレーターに理解してもらいたいのです。いつボタンを押すのか、DRを起動するときはどうするのか。どこに行けばいいのか。情報はどこにあるのか。誰に電話すればいいのか。何をする必要があるのか。結局のところ、私たちは人に頼っているのです。たとえ多くの自動化があったとしても、そして自動化なしでは成功しないとしても、人は依然として非常に重要な部分なのです。
これらの人々がこれらの変更を実装する必要があるとき、私たちはプロセスを持ちたいですよね。例として、DRを起動する場合、誰に電話すればいいのか。誰とコミュニケーションを取る必要があるのか。情報はどこにあるのか。データベースはどこにあるのか。顧客に何か伝える必要があるのか。パートナーに何か伝える必要があるのか。ですから、プロセスは極めて重要であり、それらを文書化する必要があります。プロセスとは、単にプロセスを定義するだけでなく、それらのプロセスを検証し、テストし、ドキュメントに適切に記述されていることを確認し、オンボーディングされるすべての人がそれらのプロセスがどのようなものかを認識していることを意味します。
そして最後に、私たちは間違いなくテクノロジーについて話します。サービスについて考えます。どのようにデプロイするかを考えます。コンピュートインフラストラクチャについて考えますよね。ですから、これら3つの異なる領域すべてについて考える必要があります。つまり、適切なサービスを選ぶだけではなく、人、プロセス、そしてテクノロジーについても考えるということです。それを実行する際には、そこにあるすべてのものが非常に連携している必要があります。
そして繰り返しになりますが、実装時に顧客が行う必要のある課題や多くのことについて、かなり多くお話ししてきたことは承知しています。これらすべてが真実であるとはいえ、現実には、マルチクラウドは実際に全体的なレジリエンスを向上させるのに役立つのです。ここでは事例を紹介したかったですし、実装時に顧客が注目すべき領域を本当にお伝えしたかったのです。なぜなら、Clarkが冷蔵庫の例で共有したように、私たちは複雑さを減らしたいと考えており、複雑さに対処する際には、それがどこにあるのか、そしてどのようにより良くできるのかを理解したいからです。しかし現実には、そうです、マルチクラウドは非常に良いアイデアになり得ますし、実際にレジリエンスを向上させるのに役立つのです。
それでは、これが実際にどのように実装されているかについて、もっと詳しくお話しいただくために、Andrewをステージにお招きしたいと思います。Monzo Bankが複数のクラウドプロバイダーにまたがってDR戦略をどのように構築してきたか、もう少し詳しく共有していただきます。ありがとうございます、Andrew。
Monzo Bankの実践事例：Monzo Stand-inによるマルチクラウドディザスタリカバリの実装
皆さんこんにちは、Andrewです。私はMonzoのエンジニアです。もしMonzoのことを聞いたことがない方がいらっしゃれば、Monzoはイギリス、アメリカ、そして近々ヨーロッパのいくつかの市場で展開している個人向けおよびビジネス向けの銀行です。25歳から34歳の成人の50%以上がMonzoを利用しています。そして私たちのミッションは、お金を誰にとっても使いやすくすることです。これらのお客様は、自分のお金を自分のために働かせるためにMonzoを使っています。私たちは完全にデジタルのみで運営しているため、テクノロジーにおける回復力は、私たちにとっても、お客様にとっても、本当に本当に重要なのです。
過去2年間で、イギリスの主要な9つのリテール銀行が、ITの障害によって合計803時間のダウンタイムに見舞われました。この数字に背景を説明すると、これら9つのイギリスの銀行は、イギリスのリテール預金の90%以上、そしてイギリスのリテールバンキング人口の80%以上を占めています。つまり、イギリスで銀行を利用している方は、ほぼ確実にこれらの障害の影響を受けているということです。
これらの障害が起こるのは、これらの銀行が信頼性を気にかけていないからではありません。彼らは信頼性の高いシステムを確保するために、非常に多くの時間、お金、労力を費やしていますが、それでもこうしたインシデントは起き続けているのです。もしMonzoのシステムがダウンしたら、お客様の生活に非常に大きな影響を与えることになります。食料品を買えなくなったり、帰りのタクシーに乗れなくなったり、請求書の支払いができなくなったり、あるいは自分のお金が安全かどうかを確認することさえできなくなるかもしれません。ですから、私たちはこれについて何をすべきか、本当に真剣に考えなければなりません。
Amazon AWSのようなCSPが提供する回復力は、通常本当に十分なものですので、信頼性の高いシステムを構築するには、まず彼らのガイダンスに従うことから始まります。AWSのようなクラウドサービスプロバイダーは、多くの同一拠点にあるサーバーにワークロードを分散させることを支援してくれますし、ハードウェア障害を自動的に回復できるものとして受け入れることを可能にしてくれます。同一拠点にあるサーバーから次の明らかな論理的ステップは、複数のデータセンターとアベイラビリティゾーンにワークロードを分散させることで、単一のサイトがダウンすることへの回復力を得ることができます。ここでは、ホストマシンとデータセンターの障害に対処していますので、私たちが見逃している何か他のものがあるはずです。
Active-activeプラットフォームは、私たちのほとんどにとって実用的ではないと考えています。それが単一のクラウドサービスプロバイダー内でのマルチリージョンであろうと、複数のクラウドサービスプロバイダーにまたがるマルチクラウドであろうと、これはほとんどの場合うまくいかないと私たちは考えています。AWSのようなCSPは、単一のクラウド内でマルチリージョンワークロードをサポートする製品を提供していますが、これらの製品は単一のクラウドサービスプロバイダー内でのグローバルなクラウド障害を完全には解決しません。Monzoでは、これらの製品に依存するだけでは、私たちが抱える根本的な回復性の問題を解決できないことを認識しています。ですから、複数のクラウドプロバイダーをどのように使用するかを検討し、これらの製品に組み込まないようにする必要があります。
マルチリージョンやマルチクラウドの設計は、技術的に複雑なデータ同期の問題や複雑さも引き起こし、システムのレイテンシーを増加させる可能性があります。先ほどお話ししたように、新しいリージョンや新しいクラウドを追加するたびに、インフラストラクチャのコストが倍増します。先ほどお話しした従来のディザスタリカバリのセットアップも、最も起こりやすい障害の原因を解決しないと私たちは考えています。まず、非アクティブなリカバリサイトに対して絶対的な信頼を構築し維持することは困難です。レバーを引くという決断を下すことは、深刻なインシデントの最中では非常に複雑で、決断するのが非常に難しいのです。
最も重要なのは、2つのサイトで同じソフトウェアを実行すると、最終的には同じ方法で障害が発生するということです。2023年に英国の航空業界と観光業界に影響を与えたインシデントは、この非常に興味深い例です。彼らが構築したシステムには、インシデントが検出されてから数秒以内に起動する自動フェイルオーバーを備えた、本当に印象的なディザスタリカバリサイトがありました。しかし、両方のサイトで同じソフトウェアを実行していたため、セカンダリのディザスタリカバリサイトもまったく同じ方法で障害が発生しました。そのため、ディザスタリカバリサイトで障害から復旧することができませんでした。そのレポートへのリンクは、後ほどスライドで共有します。
そこで、私たちは何か違うことをする必要があると考え、Monzo Stand-inと呼ばれるシステムを構築しました。これは、新しいソフトウェア、新しいデータで一から構築され、別のクラウドサービスプロバイダーにデプロイされており、常に稼働していて数秒以内に本番ワークロードを引き受ける準備ができています。左側には、通常のMonzoアプリの体験がどのようなものかが表示されており、右側には、Monzo Stand-inアプリの体験が表示されています。これは、私たちのアプリのはるかに縮小されたバージョンです。
Stand-inアプリは、Stand-in中でもまだできることの種類を説明しています。カードでの支払い、銀行振込の送信、お金がまだ存在していて問題ないことの確認などですが、最終的には通常のアプリのはるかに縮小されたバージョンです。Monzo Stand-inのアプリ体験をシンプルかつ機能的に保つことは、私たちにとって本当に重要な設計原則です。Clarkが先ほど述べたように、これらの機能を本当にシンプルに保つことで、最も依存する必要があるときにこれらのコンポーネントが障害を起こすリスクを減らすことができます。それでも、Stand-inアプリにはMonzoらしさを感じてもらいたいと思っています。
複雑さのレイヤーや大量の機能を追加しないという選択により、Monzo Stand-inのフロントエンドとバックエンドの両方を非常にシンプルに保つことができ、本当に信頼できるものになっています。こちらが私たちのインフラストラクチャがどのように機能するかを説明する高レベルの図です。左側、AWS内には、私たちのプライマリプラットフォームがあります。3,000以上のサービスが数十万のレプリカにデプロイされており、共有プラットフォームコンポーネントの上に構築され、さらにその上にEKS、Amazon Keyspacesなどのようなインフラストラクチャとプロダクトがあります。
右側には、Google Cloud内で稼働している私たちのStand-inプラットフォームがあります。わずか18のサービスしかなく、これらはプライマリプラットフォームで実行しているサービスとは別のサービスです。プライマリプラットフォームの一部のサービスと似た動作を実行しますが、完全に別のものであり、この場合もプラットフォームコンポーネントを使用していますが、Google Cloudのプロダクトラインナップを使用しています。
Monzo Stand-inは、決済処理のような最も重要なシステムの障害を検知してから数秒以内に自動的にアクティベートできます。モバイルアプリなどへのAPIトラフィックを提供する場合は、立ち上げに数分かかりますが、それもかなり迅速に切り替えることができます。プライマリプラットフォームでは、Stand-inプラットフォームにデータを同期できる必要があります。プライマリプラットフォーム内には、Stand-in data syncerと呼ばれるシステムがあり、プライマリプラットフォームで起こっているすべてのイベントを消費しています。
簡単な例を挙げると、アカウントが開設されたり、トランザクションが作成されたり、カードが期限切れになったりした場合、このdata syncerシステムはそれらのイベントを消費しているだけです。ほぼリアルタイムで、そのデータを効果的に変換してStand-inプラットフォームにロードしています。プライマリプラットフォームが障害を起こす時点があり、同期されているデータの一部がまだ転送中であることは分かっています。そのETLシステムを本当に、本当にシンプルにしたいので、できる限り複雑さを減らしています。そのために、データの一部が障害時にまだ転送中である可能性があるというリスクを効果的に受け入れています。
また、Stand-inプラットフォームからプライマリプラットフォームへデータを同期することについても考える必要があります。データというのは、実際にはMonzo Stand-inが決済処理などを行う際に下した処理決定のことです。例えば、顧客がWhole Foodsで100ドル使ったとします。この場合、決済はMonzo Stand-inで処理され、承認または拒否の決定は、この場合Stand-inプラットフォームのMastercardプロセッサーによって行われます。
そのStand-inプラットフォームのMastercardプロセッサーは、Stand-in内のその顧客の残高を更新し、機能を縮小したアプリで顧客が確認できるトランザクションを作成します。そして、私たちがadviceと呼ぶメッセージも発行します。このadviceは、事実上、プライマリプラットフォームに対して、すでに下された決定を伝えるものです。このadviceメッセージは、将来のある時点で私たちのプライマリプラットフォームによって消費されます。それが完全にダウンしていてすべてが復旧した場合でも、部分的にダウンしていた場合でも同様です。
そのStand-in adviceコンシューマーは、事実上、adviceを受け取り、プライマリプラットフォーム内のこれらのプロセッサーに送信して、adviceの効果を適用します。私たちは新しい決定を作り直したくありません。なぜなら、事実上、この顧客はすでに100ドル分の食料品を持ってWhole Foodsから出て行ってしまっているからです。私たちは異なる決定を下すことはできないので、事実上、Stand-in内で下された決定を適用しているのです。また、私たちはadviceキューが、Monzo Stand-inがプライマリプラットフォームなしで最大2週間動作するように設計されていることを認識しています。
事実上、これらのadviceメッセージは、プライマリプラットフォームがそれらを消費できるようになるまでキューに入れられます。プライマリプラットフォームがオンラインに戻ったら、そのadviceキューの遅延をほぼゼロまで減らすことができるまで、Monzo Stand-in内で動作を続けます。これは、基本的に支払いを処理するとすぐに処理していることを示しています。adviceメッセージをほぼリアルタイムで処理している時点に達したら、切り替え中にいくつかのメッセージが処理中である可能性があるというリスクがまだあることはわかっています。しかし、繰り返しになりますが、それはシステムの複雑さを軽減するために私たちが受け入れることを選択したリスクです。
2つのプラットフォーム間で、私たちはコントロールプレーンを運用しており、これが事実上、どのプラットフォームがどの時点でどの決定を行う責任があるかを交渉し、決定します。このコントロールプレーンは、どのAPIが私たちのモバイルアプリにサービスを提供するかを制御します。
それは、どの決済システムがstand-inまたはプライマリプラットフォーム内で実行されるべきか、顧客の何パーセントがどのプラットフォームにルーティングされるべきか、さらにはどの正確な顧客がどこにルーティングされるべきかを決定します。私たちは、ご覧いただけるシンプルなCLIのように、これらすべてを行うための手動コントロールを持っています。これが、私たちが最初にシステムを構築してロールアウトした方法です。現在では、障害を検知するとすぐに自動的にMonzo Stand-inに切り替える自動化が多数ありますが、自動化システムが失敗した場合に備えて、これらの手動コントロールは常に必要になります。
決済ネットワークからのインバウンドトラフィックは、Monzo Stand-inで決済を処理している場合でも、依然としてプライマリプラットフォームを経由してルーティングされています。プライマリプラットフォームがダウンしている場合に動作するように、このMonzo Stand-inプラットフォーム全体を構築したことを考えると、これは本当にばかげているように聞こえますよね。しかし通常の場合、プライマリプラットフォームのほとんどの部分はまだ稼働していますし、プライマリプラットフォームのエッジネットワークとコントロールプレーンのみに依存すれば、これら2つのプラットフォーム間で顧客のサブセットを好きなようにルーティングできるんです。自動的にロールアウトを有効にすることができます。しかしプライマリプラットフォームが完全にダウンしている場合でも、Monzo Stand-inから決済ネットワークに直接接続することができます。
バックグラウンドでは、スタンドイン中に、モバイルアプリは常にスタンドインプラットフォームとプライマリプラットフォームの両方と通信しています。プライマリプラットフォームの場合はAWSからAPI.Monzo.comを通じて、実質的に類似したAPIを提供していますし、スタンドインプラットフォーム用には完全に異なるドメインがあり、これらのAPIの一部で類似したインターフェースを持っています。Brunoが以前説明していたSEEMSフレームワークについて考えると、私たちはモバイルクライアントに提供する別々のAPIを持つことを選択しました。そしてそれらの別々のAPIは、完全に異なるDNSプロバイダーを持つ別々のドメイン上にあります。つまり、DNSを単一障害点として依存しないようにしたんです。
Monzo Stand-inは、いつでもすぐに使えるように、常に、常に毎日稼働しています。毎日、顧客のサブセットをMonzo Stand-inに登録しています。これらの顧客は本番環境の顧客であり、テストではありません。実際の生活で、実際に、彼らはアプリを開くとスタンドインにいることがわかります。フォールバックシステムをテストするために彼らを使用していることを説明し、彼らの決済はMonzo Stand-inで処理されます。彼らはスタンドインアプリの縮小された機能を使用することになり、これは私たちにとって、すべてのデータ同期、決済ネットワークへのメッセージング、以前お話ししたすべてのアドバイス処理、すべてをエンドツーエンドでテストするのに本当に役立ちます。これは私たちにとって本当に、本当に強力なんです。もし顧客がスタンドインにない機能を本当に使いたい場合は、単にオプトアウトすればよく、それによってMonzo Stand-inのテストからすぐに外れます。
これはすべて、この顧客がスタンドインにルーティングされることを正確に指定できるコントロールプレーンによって実現されています。それが可能なのは、スタンドインを使用している間、プライマリプラットフォームを通じて決済やその他のものをルーティングできるからです。また、シャドーテストも行っています。つまり、プライマリプラットフォームで処理するすべての決済は、同じ決済について判断を下すために、非同期でスタンドインプラットフォームにも送信されるということです。これで2つの判断ができます。プライマリプラットフォームからの判断は、実質的に尊重され、決済ネットワークに送り返されるものです。スタンドインで下された判断は、プライマリプラットフォームですでに下した判断と比較し、時間の経過とともに乖離する差異を効果的に監視してアラートを出します。
2つのプラットフォームが常に同じ判断を下すことは期待していません。常にかなり近いことは期待していますが、実質的に、プライマリプラットフォームで時間の経過とともに変更が発生し、それがスタンドインプラットフォームでも変更されていない場合、その違いを発見できるようになっています。プライマリプラットフォームが完全にダウンしている場合に、プライマリプラットフォームを経由せずにスタンドインプラットフォームで決済を処理できることを確認するために、スタンドインから接続できることを知りたいんです。そこで毎日、Monzo Stand-inを決済ネットワークに直接接続する自動テストを実行しています。インバウンド決済トラフィックの一部を受信し、それらの決済を処理し、判断を下し、その判断を決済ネットワークに送り返します。そして繰り返しになりますが、これは大きなエンドツーエンドです。アドバイスがプライマリプラットフォームに送り返されるところまで、全体のエンドツーエンドのフローを再び確認しています。
このテストの主な目的は、具体的にはネットワーク接続が生きていて、必要な時に使用できることをテストすることです。また、Stand-inプラットフォームに同期されているデータと、戻ってくるアドバイスの両方に対して、整合性テストも実行しています。これが私たちにとって役立つのは、2つのデータセットが実質的に乖離していくような、システム的な問題を時間をかけて検出できることです。これらすべてをモニタリングしてアラートを出すことができますし、差異を発見した場合は自動的に修正も行います。これらすべてのテストとすべての作業によって、Stand-inプラットフォームが期待通りに動作しているという継続的な高い確信が得られ、本当に必要な時、インシデント発生時に使用するのが非常に簡単になります。
Monzo Stand-inは、様々な深刻度の実際のインシデントで使用されてきました。私たちはMonzo Stand-inを、プライマリプラットフォーム全体がダウンするような最も深刻な障害時に役立つように構築しました。しかし実際には、それよりもはるかに多くのケースで使用してきました。プライマリプラットフォームの一部の部分的な障害から、主要なインフラストラクチャの障害まで、Monzo Stand-inを使用してきました。時には全体ではなく、単に一部の顧客をMastercardの決済にルーティングしたり、一部の顧客を別の特定の決済プロセッサーにルーティングしたりすることもあります。しかし場合によっては、アプリ、すべての決済など、全体を使用することもあります。
時々、Monzo Stand-inについて話すと聞かれる質問として、これは莫大なコストがかかるのではないか、というものがあります。Stand-inプラットフォームの複雑性が低減されているため、常にバックグラウンドで実行していても、プライマリプラットフォームのコストの約1%しかかかりません。ですから、実際にはそれほど多くのコストはかかっていません。2つの完全に異なるプラットフォームを持つのは、メンテナンスが大変ではないか、という質問もあります。答えは単純に、いいえ、です。ライブラリのバージョンや言語のバージョンなどは自動的に更新していますが、過去1年間で、明示的な変更のうち1%未満しかStand-inプラットフォームに対して明示的に行われていないので、メンテナンスの負担は本当にありません。
そして最後に、私も構築すべきか、という質問だと思います。決定は本当にあなた次第ですが、この決定が最もうまく機能するのは、製品においてクライアント側とサーバー側の両方を運用している場合だけだと私は考えています。可用性があなたとあなたの顧客にとって絶対的に重要であり、ダウンタイムを一切許容できず、そして私が話したこれらのトレードオフのいくつかを受け入れるというビジネス上の決定ができる場合です。このような場合、この設計は本当にうまく機能すると思います。これらのケースが当てはまらない限り、うまく適合しないかもしれないと思います。それではClarkにお返しします。
ありがとう、Andrew。感謝します。それではまとめに入ります。当然のことながら、 テストがいかに重要かを強調して終わりたいと思います。私たちは両方のクラウドサービスプロバイダーで、下位環境、プロダクション前環境、ステージング環境などで、アプリケーションをテストします。 負荷をかけてテストします。レイテンシーに関する様々な条件下でテストします。そして常にテストします。つまり、 ライフボートに対してテストトラフィックを実行します。それが合成的なものであれ、実際のプロダクション顧客トラフィックの一定の割合であれ、このようにして、そのシステムが確実に稼働し、期待通りに動作していることを高い確信を持って知ることができ、ビジネスが必要とする時にそこにあるようにします。
最後に、お時間があればぜひチェックしていただきたい他のセッションをいくつかご紹介させてください。ボードには3つ掲載されています。ここには載っていないのですが、実は明日の午後、私が登壇するセッションがありまして、AWSでマルチクラウド管理を一元化する方法についてお話しします。AWS villageにはキオスクがありまして、デモや靴下、さらにはクラウドのかわいいタトゥーシールやステッカーなど、そしてAWSが提供するマルチクラウド機能に関するより多くの情報をご用意しています。そして、Andrewと私は、本日午後2時から3時まで、AWS villageの中央にあるMeet the Expertブースにおります。ですので、本日ここでお答えできなかったご質問などがございましたら、ぜひお越しいただいてお話しできればと思います。
そして、皆さんのマルチクラウドジャーニー、そしてレジリエンスジャーニーをより速く進めていただくために役立つと思われるリソースをいくつか共有させていただきます。追加のリンクをいくつかご用意しています。AWSマルチクラウドページ、そして最近立ち上げられたAWSマルチクラウドブログがあり、AWSサービスを使ってマルチクラウドシステムを構築する方法についての追加情報をご覧いただけます。こちらには、Andrewがお話ししたStand-inプラットフォームをMonzoがどのように構築したかについて語っているブログ記事へのリンクもあります。たくさんの有益な情報があります。また、Andrewが言及していた2023年5月のCivil Aviation Authorityのレポートへのリンクもご用意しています。そちらもぜひご覧ください。
それでは、皆さん、ご参加いただきありがとうございました。今週Vegasにお越しいただき、このセッションにご参加いただき、ありがとうございます。Andrew、Monzoについてお話しいただき、ありがとうございました。モバイルアプリでセッションの評価をお忘れなくお願いします。そして、追加のご質問や、お話ししたいことがございましたら、私たちは確実にこの辺りにおりますので。エキスパートブースにもおりますので。本日は皆さんとご一緒できて本当に嬉しかったです。 ありがとうございました。ありがとうございます。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion