Monzo Stand-In: クラウド障害時でもサービス継続を可能にするバックアップインフラ

顧客は、カードでの支払い、銀行振込、請求書の支払いなどを、1日24時間、年中無休で利用できることを当然のことと考えています。彼らの生活にメンテナンスのためのダウンタイムはないため、私たちもそうあるべきではありません。私たちは、技術的な移行やその他の日常業務中のダウンタイムのリスクを最小限に抑えるために、エンジニアリングの労力を多く費やしていますが、予期せぬインシデントによる予期せぬ停止を完全に排除することは不可能です。 Monzoでは信頼性を真剣に受け止めているため、顧客が当社の重要なサービスを引き続き利用できるように、もう一層の防御層を追加するために、Monzo Stand-inという完全に独立したバックアップバンキングインフラを構築しました。Monzo Stand-inは、信頼性の高いサービスを提供する主要なメカニズムではなく、最後の手段としてのバックアップと見なしています。 Monzo Stand-in アーキテクチャ Monzo Stand-inは、Google Cloud Platform（GCP）上で実行される独立したシステム群であり、主要なインシデントが発生した場合に、Amazon Web Services（AWS）で実行されているプライマリプラットフォームを引き継ぐことができます。カードでの支払い、現金引き出し、銀行振込の送受信、口座残高と取引の確認、カードのフリーズ/アンフリーズなど、Monzoの最も重要な機能をサポートしています。 プライマリプラットフォームとStand-inプラットフォームは互いに独立して実行されており、それぞれがデータベース、キューイングシステム、ロッキングメカニズムなどの一般的なプラットフォームコンポーネントの上に、独自のサービスセットを実行するKubernetesクラスタで構成されています。各プラットフォームで実行されるサービスは、Stand-inプラットフォームのサービスがプライマリプラットフォームで実行されることはなく、その逆も同様であるという点でユニークです。これは、カード決済の処理のような両プラットフォームで共通の動作であっても同様です。 各プラットフォームは、取引の承認または拒否について独自の決定を下すことができ、複数の物理データセンターを介して決済ネットワークへの独自の接続を確立できます。 Monzo Stand-inは、Stand-inを使用している間に提供される限定的な機能に対応するために調整された、限定されたAPIエンドポイントセットも実行します。Monzoアプリは、バックグラウンドで定期的にMonzo Stand-inが有効になっているかを確認し、有効になっている場合は、最も重要な機能をサポートする簡略化されたUIに切り替わります。 異なるシステムがリスクを軽減するのに役立ちます Monzo Stand-inのために、プライマリプラットフォームで実行しているのと同じサービスを展開するのではなく、ゼロから新しいサービスを構築するのは奇妙に思えるかもしれませんが、このアプローチを取るにはいくつかの動機があります。 もし同じサービスセットを実行しようとすると、両方のプラットフォーム間で全てのデータを複製する必要が生じます。これをうまく行うには、データの強力な整合性を維持する必要があります。これは、データベースへの書き込みが両方のプラットフォームにデータが書き込まれた場合にのみ成功と見なされることを意味します。どちらかのプラットフォームが利用できなくなった場合、整合性を犠牲にすることなく何も書き込めなくなり、可用性を向上させるのではなく、全体的な可用性を低下させることになります。 強力なデータ整合性を維持する代わりに、レプリケーションはノンブロッキングであり、最終的に整合性が取れることを受け入れますが、私たちのレジャーのようなシステムは、最終的に整合性が取れるデータを許容することはできません。 異なるソフトウェアが同じ障害を被る可能性を減らします プライマリプラットフォームはAWSのアベイラビリティゾーン全体で運用されており、全てのサービスの複数のレプリカを実行しています。私たちはシステムをスケーラブルに設計し、非クリティカルな依存関係がエラーを起こした場合には、優雅に低下させます。プライマリプラットフォームの設計にレジリエンスが組み込まれているとしても、このような複雑なシステムは予期せぬ方法で失敗する可能性があります。 プライマリプラットフォームが失敗する可能性のある理由は数多くあります。私たちが軽減したいリスクはクラウドプロバイダーの障害であると考えるのは簡単ですが、コードやプロセスのバグが障害の原因である可能性も同様に高いです。 従来の災害復旧システムは、主にハードウェア障害を考慮しており、プラットフォームの最も可能性の高いリスクはネットワーク障害やディスク障害であると想定しています。AWS、GCP、Azureなどのクラウドプラットフォームプロバイダーは、ハードウェア障害による障害のほとんどを解決していますが、災害復旧は実際には進化していません。今日では、それら全てで同じソフトウェアを実行している場合、データセンターの数がいくつあっても関係ありません。 Stand-in環境とプライマリプラットフォームとの独立性が高ければ高いほど、同じ問題がStand-inプラットフォームに影響を与えるリスクは小さくなります。私たちのケースでは、プライマリプラットフォームとStand-inプラットフォームは、それぞれが取引を承認できる独自のカード発行処理コードを実行しています。プラットフォームは同様に動作することが期待されていますが、私たちはそれらを別々に実装し、共有コードへの依存を可能な限り最小限に抑えることを目指しています。 最小限のシステムは莫大な費用がかからない 私たちはプラットフォームの運用コストを非常に注意深く監視しています。Monzo Stand-inは、バックグラウンドで実行し続けるためのプライマリプラットフォームのコストの約1%で済み、主要なインシデント中に有効にした場合でも、このコストはわずかに増加する程度と予想されます。代わりに、同じシステム全てを実行し、全てのデータを複製したい場合、コンピューティング能力とそれを維持するために必要な人員のコストははるかに大きくなり、総プラットフォームコストを倍増させる可能性があります。 プラットフォーム間のデータ同期 Monzo Stand-inには、サポートする少数の機能をサポートするために必要な最小限の状態のみが含まれています。これには、残高や限定的な過去の取引情報、支払い処理に必要なカードと口座に関する詳細情報、ポットや受取人などのリストが含まれます。プライマリプラットフォームでこれらのデータのいずれかが変更されるたびに、Stand-in Data Syncerがそれらの更新をStand-inプラットフォームに書き込みます。プライマリプラットフォームで作成された全ての処理結果、状態遷移、その他の効果はイベントシステムに公開され、Stand-in Data Syncerはこれらのイベントのサブセットを消費して、Stand-inプラットフォームの状態を更新するプロセスをトリガーします。 プライマリからStand-inプラットフォームに同期される全てのデータは、不変として扱われます。Stand-inプラットフォームが完全に整合性の取れた世界のビューで実行されているとは期待していませんが、実際には同期のリアルタイム性により、ビューはほぼ完璧な整合性に近いです。私たちはこの最終的な整合性が取れる同期プロセスの遅延を非常に注意深く監視し、遅延が許容範囲を超えた稀なケースではアラートを発します。 トークン化されたデータ（例：カードPANを暗号化したもの）は、同期のために類似していますが若干異なるフローに従い、各プラットフォームのトークン化システム間で、異なるキ​​ーセット（図ではAとBとラベル付け）で暗号化されたデータを交換します。 Monzo Stand-inからの状態同期 Monzo Stand-inが有効になると、プライマリプラットフォームで行われるのと同様の処理決定と状態遷移が生成されますが、これはプライマリプラットフォームではないため、これらの結果はStand-inで運用されている期間中のみ権威を持ちます。 Monzo Stand-inは、プライマリプラットフォームから同期された不変データとは別に新しい状態を保存し、プライマリプラットフォームが利用可能になった際に消費できるように、耐久性のあるキューに全ての効果のログを記録します。プライマリプラットフォームが部分的にしか利用できない場合、このキューをすぐに消費できるかもしれませんが、完全な障害が発生している場合は、将来の日付でしか消費できないかもしれません。 このログ内の効果の記録はMonzo Advicesと呼ばれます。なぜなら、それらはそれぞれ、例えば承認されたカード決済のように、作成された効果についてプライマリプラットフォームに通知するからです。そして、プライマリプラットフォームがこれらのAdvicesの効果をそのまま適用することを期待しています。 プライマリプラットフォームは私たちの記録システムであり、真実の記録を維持しています。Monzo Stand-inが有効になっている間、それは一度も私たちの記録システムの役割を担うことはありません。これは、Monzo Stand-inの顧客の残高の潜在的に不整合なビューからMonzo Advicesをそのまま適用することにより、プライマリプラットフォームが顧客の残高を不整合と見なしている取引を承認した可能性があることを意味します。