このドキュメント（Google Cloud Well-Architected Framework: 金融サービス（FS）の視点）では、 Google Cloudで信頼性の高い FS ワークロードを設計、デプロイ、運用するための原則と推奨事項の概要について説明します。このドキュメントでは、高度な信頼性プラクティスとオブザーバビリティをアーキテクチャ ブループリントに統合する方法について説明します。このドキュメントの推奨事項は、Well-Architected Framework の信頼性の柱に沿っています。
金融機関にとって、信頼性と復元性に優れたインフラストラクチャは、ビジネス上のニーズであると同時に、規制上の要件でもあります。Google Cloud の FS ワークロードの信頼性を確保するには、潜在的な障害点を理解して軽減し、リソースを冗長にデプロイして、復旧を計画する必要があります。運用上の復元力は、信頼性の結果です。これは、中断を吸収し、適応し、回復する能力です。運用上のレジリエンスは、金融サービス組織が厳格な規制要件を満たすのに役立ちます。また、お客様に許容できない損害を与えないようにすることもできます。
Google Cloud の信頼性の構成要素は、リージョン、ゾーン、クラウド リソースのさまざまなロケーション スコープ（ゾーン、リージョン、マルチリージョン、グローバル）です。可用性を向上させるには、マネージド サービスの使用、リソースの分散、高可用性パターンの実装、プロセスの自動化を行います。
規制要件
金融サービス機関は、米国の連邦準備制度、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 サービスを選択します。
アーキテクチャを設計する際は、可用性、運用の複雑さ、レイテンシ、費用のトレードオフを考慮してください。一般に、可用性の 9 の数を増やすと費用は高くなりますが、規制要件を満たすのに役立ちます。
たとえば、99.9% の可用性（スリーナイン）は、24 時間で 86 秒のダウンタイムが発生する可能性があることを意味します。これに対し、99%（2 つの 9）は、同じ期間に 864 秒のダウンタイムが発生することを意味します。これは、3 つの 9 の可用性よりも 10 倍長いダウンタイムです。
重要な金融サービスの場合、アーキテクチャのオプションが制限されることがあります。ただし、可用性の要件を特定し、可用性を正確に計算することが重要です。このような評価を行うことで、設計上の決定がアーキテクチャと予算に与える影響を評価できます。
堅牢な DR 戦略を実装する
ゾーンやリージョンの停止など、さまざまな障害シナリオに対して明確に定義された計画を作成します。明確に定義された障害復旧（DR）戦略により、中断から復旧し、影響を最小限に抑えて通常業務を再開できます。
DR と高可用性（HA）は異なるコンセプトです。クラウド デプロイでは、一般に、DR はマルチリージョン デプロイに適用され、HA はリージョン デプロイに適用されます。これらのデプロイ アーキタイプは、さまざまなレプリケーション メカニズムをサポートしています。
- HA: 多くのマネージド サービスでは、デフォルトで単一リージョン内のゾーン間で同期レプリケーションが提供されます。このようなサービスは、目標復旧時間（RTO）と目標復旧時点（RPO）がゼロまたはゼロに近い値をサポートします。このサポートにより、SPOF のないアクティブ / アクティブ デプロイ トポロジを作成できます。
- DR: 2 つ以上のリージョンにデプロイされるワークロードの場合、マルチリージョン サービスまたはグローバル サービスを使用しない場合は、レプリケーション戦略を定義する必要があります。レプリケーション戦略は通常、非同期です。このようなレプリケーションが重要なアプリケーションの 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 などのオープン形式へのデータのエクスポートをサポートしていることを確認します。サービスがオープン テクノロジーに基づいているかどうかを確認します。たとえば、GKE では Open Container Initiative（OCI）形式や Managed Service for Apache Airflow がサポートされています。
インフラストラクチャのプロビジョニングと復旧のプロセスを自動化する
自動化により、人的ミスを最小限に抑え、インシデントへの対応に必要な時間とリソースを削減できます。自動化を使用すると、障害からの復旧を迅速化し、より一貫した結果を得ることができます。リソースのプロビジョニングと復元を自動化するには、次の推奨事項を検討してください。
- Terraform などの Infrastructure as Code（IaC）ツールを使用して、人的ミスを最小限に抑えます。
- フェイルオーバー プロセスを自動化することで、手動による介入を減らします。自動レスポンスを使用すると、障害の影響を軽減することもできます。たとえば、Eventarc または Workflows を使用して、監査ログで確認された問題に対応して是正措置を自動的にトリガーできます。
- 自動スケーリングを使用して、フェイルオーバー中にクラウド リソースの容量を増やす。
- プラットフォーム エンジニアリングを採用することで、サービス デプロイ時にクラウド トポロジ全体に規制要件のポリシーとガードレールを自動的に適用します。