Google Cloud Well-Architected Framework: FSI の視点のこのドキュメントでは、Google Cloudで信頼性の高い金融サービス業界（FSI）のワークロードを設計、デプロイ、運用するための原則と推奨事項の概要について説明します。このドキュメントでは、高度な信頼性プラクティスとオブザーバビリティをアーキテクチャ ブループリントに統合する方法について説明します。このドキュメントの推奨事項は、Well-Architected Framework の信頼性の柱に沿っています。
金融機関にとって、信頼性と復元力に優れたインフラストラクチャは、ビジネス上のニーズと規制上の義務の両方です。Google Cloud の FSI ワークロードの信頼性を確保するには、潜在的な障害点を理解して軽減し、リソースを冗長的にデプロイして、復旧を計画する必要があります。運用の復元力は信頼性の結果です。これは、中断を吸収し、適応し、復元する能力です。運用の復元力は、FSI 組織が厳格な規制要件を満たすのに役立ちます。また、お客様に許容できない損害が生じるのを防ぐこともできます。
Google Cloud の信頼性の重要な構成要素は、リージョン、ゾーン、クラウド リソースのさまざまなロケーション スコープ（ゾーン、リージョン、マルチリージョン、グローバル）です。マネージド サービスの使用、リソースの分散、高可用性パターンの実装、プロセスの自動化により、可用性を向上させることができます。
規制要件
FSI 組織は、米国の Federal Reserve System、EU の European Banking Authority、英国の Prudential Regulation Authority などの規制機関による厳格な信頼性要件の下で運営されています。世界中の規制当局は、金融の安定性と消費者保護に不可欠なオペレーショナル レジリエンスを重視しています。オペレーショナル レジリエンスとは、中断に耐え、効果的に復旧し、重要なサービスを維持する能力のことです。これには、技術リスクと第三者への依存関係を管理するための調和のとれたアプローチが必要です。
ほとんどの法域の規制要件には、次の共通のテーマがあります。
- サイバーセキュリティと技術的な復元力: サイバー脅威に対する防御を強化し、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 構成を使用します。
- 同期レプリケーションでリージョン Persistent Disk を使用して、データの可用性を向上させます。
詳細については、 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%（0.99 × 0.99）にしかなりません。
- 並列化されたサービスでは、各サービスが独立して実行され、個々のサービスが他のサービスの可用性の影響を受けないため、集約された可用性が 99.99% と高くなります。集約された並列化サービスの式は 1 − (1 − A) × (1 − B) です。
アプリケーション スタックの全体的な稼働時間の要件を満たすのに役立つ、稼働時間 SLA を備えた Google Cloud サービスを選択します。
アーキテクチャを設計する際は、可用性、運用の複雑さ、レイテンシ、費用のトレードオフを考慮してください。一般的に、可用性の 9 の数を増やすとコストが増加しますが、規制要件を満たすことができます。
たとえば、99.9% の可用性（スリー ナイン）は、24 時間の 1 日で 86 秒のダウンタイムが発生する可能性があることを意味します。一方、99%（ツーナイン）は、同じ期間で 864 秒のダウンタイムを意味します。これは、スリーナインの可用性よりも 10 倍長いダウンタイムです。
重要な金融サービスの場合、アーキテクチャ オプションが制限されることがあります。ただし、可用性の要件を特定し、可用性を正確に計算することが重要です。このような評価を行うことで、設計上の決定がアーキテクチャと予算に与える影響を評価できます。
堅牢な DR 戦略を実装する
ゾーン停止やリージョン停止など、さまざまな障害シナリオに対応した明確な計画を作成します。明確に定義された障害復旧（DR）戦略により、中断から復旧し、影響を最小限に抑えて通常の運用を再開できます。
DR と高可用性（HA）は異なるコンセプトです。一般に、クラウド デプロイでは、DR はマルチリージョン デプロイに適用され、HA はリージョン デプロイに適用されます。これらのデプロイ アーキタイプは、さまざまなレプリケーション メカニズムをサポートしています。
- HA: 多くのマネージド サービスでは、デフォルトで単一リージョン内のゾーン間で同期レプリケーションが行われます。このようなサービスは、目標復旧時間（RTO）と目標復旧時点（RPO）がゼロまたはゼロに近い値をサポートします。このサポートにより、SPOF のないアクティブ / アクティブ デプロイ トポロジを作成できます。
- DR: 複数のリージョンにデプロイされたワークロードで、マルチリージョン サービスまたはグローバル サービスを使用しない場合は、レプリケーション戦略を定義する必要があります。レプリケーション戦略は通常、非同期です。このようなレプリケーションが重要なアプリケーションの RTO と RPO に与える影響を慎重に評価します。フェイルオーバーに必要な手動または半自動のオペレーションを特定します。
金融機関の場合、フェイルオーバー リージョンの選択は、データ主権とデータ所在地に関する規制によって制限されることがあります。2 つのリージョンにまたがるアクティブ / アクティブ トポロジが必要な場合は、特にデータ レプリケーションが重要な場合に、Spanner や Cloud Storage などのマネージド マルチリージョン サービスを選択することをおすすめします。
以下の推奨事項を参考にしてください。
- データにマネージド マルチリージョン ストレージ サービスを使用します。
- 永続ディスク内のデータのスナップショットを作成し、マルチリージョン ロケーションに保存します。
- リージョン リソースまたはゾーンリソースを使用する場合は、他のリージョンへのデータ レプリケーションを設定します。
- DR 計画を定期的にテストして、計画が有効であることを確認します。
- RTO と RPO、およびそれらと管轄区域の金融規制で規定されている影響許容度との相関関係を把握します。
詳細については、クラウド インフラストラクチャの停止に対する障害復旧の設計をご覧ください。
マネージド サービスを活用する
可能な場合は、マネージド サービスを使用して、バックアップ、HA、スケーラビリティの組み込み機能を利用します。マネージド サービスを使用する際の推奨事項は次のとおりです。
- Google Cloudでマネージド サービスを使用します。SLA に基づく 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 上に構築された Cloud Composer などです。
インフラストラクチャのプロビジョニングと復旧のプロセスを自動化する
自動化により、人的ミスを最小限に抑え、インシデントへの対応に必要な時間とリソースを削減できます。自動化を使用すると、障害からの復旧を迅速に行い、より一貫性のある結果を得ることができます。リソースのプロビジョニングと復元を自動化するには、次の推奨事項を検討してください。
- Terraform などの Infrastructure as Code（IaC）ツールを使用して、人的ミスを最小限に抑えます。
- フェイルオーバー プロセスを自動化して、手動による介入を減らします。自動レスポンスを使用すると、障害の影響を軽減することもできます。たとえば、Eventarc または Workflows を使用して、監査ログで検出された問題に応じて修復アクションを自動的にトリガーできます。
- オートスケーリングを使用して、フェイルオーバー中にクラウド リソースの容量を増やします。
- プラットフォーム エンジニアリングを採用して、サービス デプロイ時にクラウド トポロジー全体にわたって規制要件のポリシーとガードレールを自動的に適用します。