Well-Architected Framework の金融サービス（FS）の視点に関するこのドキュメントでは、 Google Cloud で信頼性の高い FS ワークロードを設計、デプロイ、 運用するための原則と推奨事項の概要について説明します Google Cloud。このドキュメントでは、高度な信頼性のプラクティスとオブザーバビリティをアーキテクチャ ブループリントに統合する方法について説明します。このドキュメントの推奨事項は、 信頼性の柱 の Well-Architected Framework に沿っています。
金融機関にとって、信頼性と復元力のあるインフラストラクチャは、ビジネス ニーズと規制上の義務の両方です。 で FS ワークロードの信頼性を確保するには、潜在的な障害点 を理解して軽減し、リソースを冗長的にデプロイして、復旧を計画する必要があります。Google Cloud 運用の復元力は信頼性の結果です。停止を吸収し、適応し、復旧できる能力です。運用の復元力は、FS 組織が厳格な規制要件を満たすのに役立ちます。また、顧客に許容できない損害を与えることを防ぐこともできます。
における信頼性の重要な構成要素は、リージョン、ゾーン、クラウド リソースのさまざまなロケーション範囲（ゾーン、リージョン、マルチリージョン、グローバル）です。 Google Cloud マネージド サービスの使用、リソースの分散、高可用性パターンの実装、プロセスの自動化により、可用性を向上させることができます。
規制要件
FS 組織は、米国の連邦準備制度、EU の欧州銀行監督局、英国の健全性規制機構などの規制 機関による厳格な信頼性義務の下で運営されています。世界的に、規制当局は運用の復元力を重視しています。これは、金融の安定と消費者保護に不可欠です。運用の復元力とは、停止に耐え、効果的に復旧し、重要なサービスを維持する能力です。これには、技術的なリスクとサードパーティへの依存関係を管理するための調和のとれたアプローチが必要です。
ほとんどの管轄区域の規制要件には、次の共通のテーマがあります。
- サイバーセキュリティと技術的な復元力: サイバー脅威に対する防御を強化し、IT システムの復元力を確保します。
- サードパーティ リスク管理: 情報通信技術（ICT）のプロバイダへのアウトソーシング サービスに関連するリスクを管理します。
- 事業継続とインシデント対応: 停止時に重要なオペレーションを維持し、効果的に復旧するための堅牢な計画。
- 金融の安定の保護: 金融システム全体の健全性と安定性を確保します。
このドキュメントの信頼性に関する推奨事項は、次の基本原則にマッピングされています。
- マルチゾーン デプロイとマルチリージョン デプロイを優先する
- 単一障害点（SPOF）を排除する
- 総可用性を理解して管理する
- 堅牢な DR 戦略を実装する
- マネージド サービスを活用する
- インフラストラクチャのプロビジョニングと復旧のプロセスを自動化する
マルチゾーン デプロイとマルチリージョン デプロイを優先する
重要な金融サービス アプリケーションの場合は、少なくとも 2 つのリージョンと各リージョン内の 3 つのゾーンに分散されたマルチリージョン トポロジを使用することをおすすめします。このアプローチは、ゾーンとリージョンの停止に対する復元力にとって重要です。1 つのゾーンまたはリージョンで障害が発生した場合、ほとんどの地域の適用法令では、2 番目のゾーンが深刻な停止の影響を受ける可能性があるため、規制でこのアプローチが規定されることがよくあります。1 つのロケーションで障害が発生すると、他のロケーションで追加のトラフィックが非常に多くなる可能性があるためです。
ゾーンとリージョンの停止に対する復元力を構築するには、次の推奨事項を検討してください。
- ロケーション範囲が広いリソースを優先します。可能であれば、ゾーンリソースではなくリージョン リソースを使用し、リージョン リソースではなくマルチリージョン リソースまたはグローバル リソースを使用します。このアプローチは、バックアップを使用してオペレーションを復元する必要性を回避するのに役立ちます。
- 各リージョンで、2 つではなく 3 つのゾーンを活用します。フェイルオーバーを処理するには、推定値の 3 分の 1 以上容量をオーバープロビジョニングします。
- 次の例のように、アクティブ / アクティブ デプロイを実装して、手動による復旧手順を最小限に抑えます。
- Spanner などの分散データベースは、リージョン間で組み込みの冗長性と同期を提供します。
- Cloud SQL の HA 機能 は、ゾーン間の読み取り レプリカを使用して、アクティブ / アクティブに近いトポロジを提供します。リージョン間の目標復旧時点（RPO）は 0 に近い値になります。
- Cloud DNS を使用して、ユーザー トラフィックをリージョン間で分散し、各リージョンに リージョン ロードバランサをデプロイします。要件と重要度に応じて、グローバル ロードバランサも検討できます。詳細については、マルチリージョン デプロイでのグローバル ロード バランシングの利点とリスクをご覧ください。
- データを保存するには、 Spanner や Cloud Storage などのマルチリージョン サービスを使用します。
単一障害点を排除する
リソースをさまざまなロケーションに分散し、冗長リソースを使用して、単一障害点（SPOF）がアプリケーション スタック全体に影響しないようにします。
SPOF を回避するには、次の推奨事項を検討してください。
- 単一のアプリケーション サーバーまたはデータベースのみをデプロイしないようにします。
- マネージド インスタンス グループ（MIG）を使用して、障害が発生した VM の自動再作成を確保します。
- ロード バランシングを実装して、使用可能なリソース間でトラフィックを均等に分散します。
- Cloud SQL などのデータベースに HA 構成を使用します。
- 同期レプリケーションで リージョン永続ディスク を使用して、データの可用性を向上させます。
詳細については、 のワークロードに適した信頼性の高いインフラストラクチャを設計する Google Cloudをご覧ください。
総可用性を理解して管理する
システムの全体的または総可用性は、システムの各階層またはコンポーネントの可用性の影響を受けることに注意してください。 アプリケーション スタックの階層数は、スタックの総可用性とは逆の関係です。総可用性を管理するには、次の推奨事項を検討してください。
多層スタックの総可用性を計算するには、 tier1_availability × tier2_availability × tierN_availabilityの式を使用します。
次の図は、4 つのサービスで構成される多層システムの総可用性の計算を示しています。
上の図では、各階層のサービスの可用性は 99.9% ですが、システムの総可用性は 99.6%（0.999 × 0.999 × 0.999 × 0.999）と低くなっています。一般に、多層スタックの総可用性は、可用性が最も低い階層の可用性よりも低くなります。
可能な場合は、 チェーンではなく 並列化を選択します。並列化されたサービスでは、エンドツーエンドの可用性は各サービスの可用性よりも高くなります。
次の図は、チェーン方式と並列化方式を使用してデプロイされた 2 つのサービス A と B を示しています。
上記の例では、両方のサービスの SLA は 99% であり、実装方法に応じて次の総可用性になります。
- チェーン サービス の総可用性は 98%（.99 × .99）のみです。
- 並列化されたサービス は、各サービスが独立して実行され、個々のサービスが他のサービスの可用性の影響を受けないため、総可用性が 99.99% と高くなります。並列化されたサービスの集計の式は、 1 − (1 − A) × (1 − B) です。
アプリケーション スタックに必要な全体的な稼働時間のレベルを満たすのに役立つ、稼働時間 SLA を持つサービスを選択します。 Google Cloud
アーキテクチャを設計する際は、可用性、運用の複雑さ、レイテンシ、費用のトレードオフを考慮してください。可用性のナインの数を増やすと一般的にコストは高くなりますが、規制要件を満たすことができます。
たとえば、99.9% の可用性（スリーナイン）は、24 時間で 86 秒のダウンタイムが発生する可能性があることを意味します。一方、99%（ツーナイン）は、同じ期間で 864 秒のダウンタイムが発生することを意味します。これは、スリーナインの可用性よりも 10 倍のダウンタイムです。
重要な金融サービスの場合、アーキテクチャの選択肢が限られている可能性があります。ただし、可用性の要件を特定し、可用性を正確に計算することが重要です。このような評価を行うことで、設計上の決定がアーキテクチャと予算に与える影響を評価できます。
堅牢な DR 戦略を実装する
ゾーンとリージョンの停止など、さまざまな障害シナリオに対応した明確な計画を作成します。明確に定義された障害復旧（DR）戦略により、停止から復旧し、影響を最小限に抑えて通常のオペレーションを再開できます。
DR と高可用性（HA）は異なるコンセプトです。クラウド デプロイの場合、一般に、DR はマルチリージョン デプロイに適用され、HA はリージョン デプロイに適用されます。これらの デプロイ アーキタイプ は、異なるレプリケーション メカニズムをサポートしています。
- HA: 多くのマネージド サービスは、デフォルトで単一リージョン内の ゾーン間で同期レプリケーションを提供します。このようなサービスは、目標復旧時間（RTO）と目標復旧時点（RPO）が 0 または 0 に近い値をサポートしています。 このサポートにより、SPOF のないアクティブ / アクティブ デプロイ トポロジを作成できます。
- DR: 2 つ以上のリージョンにデプロイされたワークロードの場合、 マルチリージョン サービスまたはグローバル サービスを使用しない場合は、 レプリケーション戦略を定義する必要があります。通常、レプリケーション戦略は非同期です。 このようなレプリケーションが重要なアプリケーションの RTO と RPO に与える影響を慎重に評価します。フェイルオーバーに必要な手動または半自動のオペレーションを特定します。
金融機関の場合、フェイルオーバー リージョンの選択は、データの主権とデータ所在地に関する規制によって制限される可能性があります。2 つのリージョン間でアクティブ / アクティブ トポロジが必要な場合は、特にデータ レプリケーションが重要な場合に、Spanner や Cloud Storage などのマネージド マルチリージョン サービスを選択することをおすすめします。
次の推奨事項を検討してください。
- データにはマネージド マルチリージョン ストレージ サービスを使用します。
- 永続ディスク内のデータのスナップショットを作成し、スナップショットを マルチリージョン ロケーションに保存します。
- リージョン リソースまたはゾーンリソースを使用する場合は、他のリージョンへのデータ レプリケーションを設定します。
- 計画を定期的にテストして、DR 計画が有効であることを確認します。
- RTO と RPO、および管轄区域の金融規制で規定されている影響許容度との相関関係に注意してください。
詳細については、 クラウド インフラストラクチャの停止に対する障害復旧の設計をご覧ください。
マネージド サービスを活用する
可能な場合は、マネージド サービスを使用して、バックアップ、HA、スケーラビリティの組み込み機能を利用します。マネージド サービスを使用するには、次の推奨事項を検討してください。
- でマネージド サービスを使用します。 Google CloudSLA に基づく HA を提供します。また、組み込みのバックアップ メカニズムと復元力機能も備えています。
- データ管理には、 Cloud SQL、 Cloud Storage、 および Spannerなどのサービスを検討してください。
- コンピューティングとアプリケーション ホスティングには、 Compute Engine マネージド インスタンス グループ（MIG） と Google Kubernetes Engine（GKE）クラスタを検討してください。 リージョン MIG と GKE リージョン クラスタは、ゾーンの停止に対する復元力を備えています。
- リージョンの停止に対する復元力を向上させるには、マネージド マルチリージョン サービスを使用します。
- 固有の特性を持つサービスの終了計画の必要性を特定し、必要な計画を定義します。FCA、PRA、EBA などの金融規制当局は、クラウド プロバイダとの関係が終了した場合に、データ取得とオペレーションの継続のための戦略と緊急時対応計画を企業に求めています。 企業は、クラウド契約を締結する前に終了の実現可能性を評価し、オペレーションを中断することなくプロバイダを変更できる能力を維持する必要があります。
- 選択したサービスが、CSV、Parquet、Avro などのオープン形式へのデータのエクスポートをサポートしていることを確認します。サービスが Open Container Initiative（OCI）形式の GKE サポート や Apache Airflow 上に構築された Managed Service for Apache Airflowなどのオープン テクノロジーに基づいているかどうかを確認します。
インフラストラクチャのプロビジョニングと復旧のプロセスを自動化する
自動化は、人的ミスを最小限に抑え、インシデント対応に必要な時間とリソースを削減するのに役立ちます。自動化を使用すると、障害からの復旧を迅速に行い、より一貫した結果を得ることができます。リソースのプロビジョニングと復旧の方法を自動化するには、次の推奨事項を検討してください。
- Terraform などの Infrastructure as Code（IaC）ツールを使用して、人的ミスを最小限に抑えます。
- フェイルオーバー プロセスを自動化して、手動による介入を減らします。自動レスポンスを使用すると、障害の影響を軽減することもできます。たとえば、Eventarc または Workflows を使用して、監査ログで確認された問題に応じて修復アクションを自動的にトリガーできます。
- フェイルオーバー時に、自動スケーリングを使用してクラウド リソースの容量を増やします。
- プラットフォーム エンジニアリングを採用して、サービス デプロイ時にクラウド トポロジ全体にわたって規制要件のポリシーとガードレールを自動的に適用します。