Google Cloud Well-Architected Framework: FSI の視点のこのドキュメントでは、 Google Cloudで堅牢な金融サービス業界（FSI）ワークロードを構築、デプロイ、運用するための原則と推奨事項の概要について説明します。これらの推奨事項は、オブザーバビリティ、自動化、スケーラビリティなどの基本的な要素を設定するのに役立ちます。このドキュメントの推奨事項は、Well-Architected Framework のオペレーショナル エクセレンスの柱に沿っています。
FSI ワークロードは規制が厳しく、機密性が高いため、 Google Cloud では運用効率が非常に重要です。オペレーショナル エクセレンスにより、クラウド ソリューションは進化するニーズに適応し、価値、パフォーマンス、セキュリティ、信頼性に関する要件を満たすことができます。これらの分野で障害が発生すると、多額の財務上の損失、規制上の罰則、評判の低下につながる可能性があります。
オペレーショナル エクセレンスは、FSI ワークロードに次のメリットをもたらします。
- 信頼と評判を維持する: 金融機関は顧客の信頼に大きく依存しています。業務の中断やセキュリティ侵害は、この信頼を大きく損ない、顧客離れを引き起こす可能性があります。運用上の卓越性は、こうしたリスクを最小限に抑えるのに役立ちます。
厳格な規制要件を満たす: FSI は、次のような多数の複雑な規制の対象となります。
規制遵守を実証し、罰則を回避するには、堅牢な運用プロセス、モニタリング、インシデント管理が不可欠です。
ビジネスの継続性と復元性を確保する: 金融市場とサービスは、多くの場合、継続的に運営されています。そのため、高可用性と効果的な障害復旧が最も重要になります。オペレーショナル エクセレンスの原則は、復元性に優れたシステムの設計と実装を導きます。信頼性の柱には、この分野に関するガイダンスが記載されています。
機密データを保護する: 金融機関は、機密性の高い顧客データと金融データを大量に処理します。データ漏洩を防ぎ、プライバシーを維持するには、強力な運用管理、セキュリティ モニタリング、迅速なインシデント対応が不可欠です。セキュリティ ピラーでは、この分野に関するガイダンスを提供しています。
クリティカル アプリケーションのパフォーマンスを最適化する: 取引プラットフォームやリアルタイム分析など、多くの金融アプリケーションでは、高パフォーマンスと低レイテンシが求められます。これらのパフォーマンス要件を満たすには、高度に最適化されたコンピューティング、ネットワーキング、ストレージの設計が必要です。この点については、パフォーマンス最適化の柱で詳しく説明しています。
費用を効果的に管理する: 金融機関は、セキュリティと信頼性に加えて、費用対効果も重視しています。運用上の優秀性には、リソース使用率の最適化とクラウド費用の管理に関するプラクティスが含まれます。この分野については、費用最適化の柱で詳細なガイダンスを提供しています。
このドキュメントのオペレーショナル エクセレンスの推奨事項は、次の基本原則にマッピングされています。
SLA と対応する SLO および SLI を定義する
多くの FSI 組織では、アプリケーションの可用性は通常、目標復旧時間（RTO）と目標復旧時点（RPO）の指標に基づいて分類されます。外部顧客にサービスを提供するビジネス クリティカルなアプリケーションの場合は、サービスレベル契約（SLA）も定義されることがあります。
SLA には、ユーザー満足度の観点からシステムの動作を表す指標のフレームワークが必要です。サイト信頼性エンジニアリング（SRE）の手法は、必要なレベルのシステム信頼性を実現する方法を提供します。指標のフレームワークを作成するには、ユーザーの視点からシステムの健全性を把握するための重要な数値指標を定義してモニタリングします。たとえば、レイテンシやエラー率などの指標は、サービスのパフォーマンスを定量化します。これらの指標は、サービスレベル指標（SLI）と呼ばれます。効果的な SLI を開発することは、信頼性を客観的に評価するために必要な生データを提供するため、非常に重要です。
意味のある SLA、SLI、SLO を定義するには、次の推奨事項を検討してください。
- 各重要なサービスの SLI を開発して定義します。許容可能なパフォーマンス レベルを定義する目標値を設定します。
- SLI に対応するサービスレベル目標（SLO）を開発して定義します。たとえば、リクエストの 99.9% のレイテンシが 200 ミリ秒未満である必要があるという SLO を設定できます。
- サービスが SLO を満たしていない場合に実施する必要がある内部の是正措置を特定します。たとえば、プラットフォームの復元力を高めるために、開発リソースを問題の修正に集中させる必要がある場合があります。
- 各サービスの SLA 要件を検証し、SLA をサービス ユーザーとの正式な契約として認識します。
サービスレベルの例
次の表に、支払いプラットフォームの SLI、SLO、SLA の例を示します。
| ビジネス指標 | SLI | SLO | SLA |
|---|---|---|---|
| 支払トランザクションの成功 | 開始されたすべての支払いトランザクションのうち、正常に処理されて確認されたトランザクションの割合を定量的に測定したもの。 例: （成功したトランザクション数 ÷ 有効なトランザクションの合計数）× 100。5 分間のローリング ウィンドウで測定されます。 |
特定の期間にわたって、支払い取引の成功率を高い水準で維持するための内部目標。 例: 無効なリクエストと計画メンテナンスを除き、ローリングの 30 日間の期間で 99.98% の支払いトランザクション成功率を維持する。 |
支払い取引処理の成功率と速度に関する契約上の保証。 例: サービス プロバイダは、クライアントが開始した支払い取引の 99.0% が 1 秒以内に正常に処理され、確認されることを保証します。 |
| 支払い処理のレイテンシ | クライアントによる開始から最終確認までの支払いトランザクションの処理にかかる平均時間。 例: 5 分間のローリング ウィンドウで測定された、トランザクション確認の平均レスポンス時間（ミリ秒単位）。 |
支払いトランザクションの処理速度に関する内部目標。 例: 30 日間のローリング ウィンドウで、支払いトランザクションの 99.5% が 400 ミリ秒以内に処理されるようにします。 |
指定された期間内に決済処理に関する重大な問題を解決するという契約上のコミットメント。 例: 重要な支払い処理の問題（トランザクションの 1% 以上に影響する停止と定義）の場合、サービス プロバイダは、問題が報告または検出されてから 2 時間以内に解決することを約束します。 |
| プラットフォームの可用性 | コアの支払い処理 API とユーザー インターフェースが動作し、クライアントからアクセスできる時間の割合。 例: （合計運用時間 - ダウンタイム）÷ 合計運用時間 × 100（1 分ごとに測定）。 |
コア決済プラットフォームの稼働時間に関する内部目標。 例: 予定されたメンテナンスの時間枠を除き、1 暦月あたり 99.995% のプラットフォームの可用性を実現します。 |
支払いプラットフォームの最小稼働時間に関する、お客様に対する正式な法的拘束力のあるコミットメント。これには、コミットメントを満たせなかった場合の責任も含まれます。 例: プラットフォームは、予定されたメンテナンスの時間枠を除き、各暦月で 99.9% 以上の可用性を維持します。可用性が最低レベルを下回った場合、クライアントは、0.1% の低下ごとに月額サービス料金の 5% のサービス クレジットを受け取ります。 |
SLI データを使用して、システムが定義された SLO 内にあるかどうかをモニタリングし、SLA が満たされていることを確認します。明確に定義された SLI のセットを使用することで、エンジニアとデベロッパーは次のレベルで FSI アプリケーションをモニタリングできます。
- アプリケーションがデプロイされているサービス（GKE や Cloud Run など）内。
- ロードバランサなどのインフラストラクチャ コンポーネントから提供されるログを使用する。
OpenTelemetry は、指標、トレース、ログなど、あらゆる種類のテレメトリーをキャプチャするためのオープンソース標準と一連のテクノロジーを提供します。Google Cloud Managed Service for Prometheus は、指標と Prometheus の大規模な運用のためのフルマネージドでスケーラビリティの高いバックエンドを提供します。
SLI、SLO、エラー バジェットの詳細については、SRE ハンドブックをご覧ください。
効果的なアラートとモニタリングのダッシュボードとメカニズムを開発するには、Google Cloud Observability ツールと Google Cloud モニタリングを併用します。セキュリティ固有のモニタリング機能と検出機能については、セキュリティ ピラーをご覧ください。
インシデント管理プロセスを定義してテストする
明確に定義され、定期的にテストされるインシデント管理プロセスは、 Google Cloudの FSI ワークロードの価値、パフォーマンス、セキュリティ、信頼性に直接貢献します。これらのプロセスは、金融機関が厳格な規制要件を満たし、機密データを保護し、事業継続性を維持し、顧客の信頼を維持するのに役立ちます。
インシデント管理プロセスの定期的なテストには、次のようなメリットがあります。
- ピーク負荷時のパフォーマンスを維持する: 定期的なパフォーマンス テストと負荷テストを実施することで、金融機関は、クラウドベースのアプリケーションとインフラストラクチャが、パフォーマンスの低下を招くことなく、ピーク時の取引量、市場の変動、その他の高需要のシナリオに対応できることを確認できます。この機能は、シームレスなユーザー エクスペリエンスを維持し、金融市場のニーズを満たすうえで不可欠です。
- 潜在的なボトルネックと制限事項を特定する: ストレステストでは、システムを限界までプッシュします。これにより、金融機関は、重要なオペレーションに影響が及ぶ前に、潜在的なボトルネックとパフォーマンスの制限事項を特定できます。この事前対応型のアプローチにより、金融機関はインフラストラクチャとアプリケーションを調整して、最適なパフォーマンスとスケーラビリティを実現できます。
- 信頼性と復元力を検証する: カオス エンジニアリングやシミュレートされた障害などの定期的なテストは、金融システムの信頼性と復元力を検証するのに役立ちます。このテストにより、システムが障害から正常に復旧し、高可用性を維持できることが保証されます。これは、事業継続に不可欠です。
- 効果的な容量計画を実施する: パフォーマンス テストでは、さまざまな負荷条件でのリソース使用率に関する貴重なデータが提供されます。これは、正確な容量計画に不可欠です。金融機関は、このデータを使用して、将来の容量ニーズを事前に予測し、リソース制約によるパフォーマンスの問題を回避できます。
- 新機能とコード変更を正常にデプロイする: 自動テストを CI/CD パイプラインに統合すると、変更と新しいデプロイが本番環境にリリースされる前に、徹底的に検証されます。このアプローチにより、運用の中断につながる可能性のあるエラーや回帰のリスクが大幅に軽減されます。
- システムの安定性に関する規制要件を満たす: 金融規制では、重要なシステムの安定性と信頼性を確保するために、堅牢なテスト手法を導入することが求められることがよくあります。定期的なテストは、これらの要件への準拠を実証するうえで役立ちます。
インシデント管理プロセスを定義してテストするには、次の推奨事項を検討してください。
明確なインシデント対応手順を確立する
確立された一連のインシデント対応手順には、次の要素が含まれます。
- インシデント コマンダー、調査担当者、コミュニケーション担当者、技術専門家に対して定義された役割と責任。効果的かつ協調的な対応を確保します。
- インシデント発生時に情報が迅速かつ効果的に共有されるように定義された、コミュニケーション プロトコルとエスカレーション パス。
- コミュニケーション、トリアージ、調査、解決の手順を概説するランブックまたはプレイブックに記載されている手順。
- チームが効果的に対応するための知識とスキルを身につけるための定期的なトレーニングと準備。
パフォーマンス テストと負荷テストを定期的に実装する
定期的なパフォーマンス テストと負荷テストを実施することで、クラウドベースのアプリケーションとインフラストラクチャがピーク時の負荷を処理し、最適なパフォーマンスを維持できるようになります。負荷テストでは、現実的なトラフィック パターンをシミュレートします。ストレステストでは、システムを限界まで動作させて、潜在的なボトルネックとパフォーマンスの制限を特定します。Cloud Load Balancing などのプロダクトや負荷テスト サービスを使用して、実際のトラフィックをシミュレートできます。テスト結果に基づいて、クラウド インフラストラクチャとアプリケーションを調整し、最適なパフォーマンスとスケーラビリティを実現できます。たとえば、リソース割り当てを調整したり、アプリケーション構成を調整したりできます。
CI/CD パイプライン内のテストを自動化する
自動テストを CI/CD パイプラインに組み込むと、デプロイ前に変更を検証することで、クラウド アプリケーションの品質と信頼性を確保できます。このアプローチにより、エラーや回帰のリスクが大幅に軽減され、より安定した堅牢なソフトウェア システムを構築できます。CI/CD パイプラインには、単体テスト、統合テスト、エンドツーエンド テストなど、さまざまな種類のテストを組み込むことができます。Cloud Build や Cloud Deploy などのプロダクトを使用して、CI/CD パイプラインを作成して管理します。
改善とイノベーションを継続的に行う
クラウドの金融サービス ワークロードの場合、クラウドへの移行は最初のステップにすぎません。継続的な強化とイノベーションは、次の理由で不可欠です。
- イノベーションを加速する: AI などの新しいテクノロジーを活用して、サービスを改善します。
- コストを削減する: 非効率な部分を排除し、リソースの使用を最適化します。
- アジリティの強化: 市場や規制の変化に迅速に対応します。
- 意思決定の改善: BigQuery や Looker などのデータ分析プロダクトを使用して、情報に基づいた選択を行います。
継続的な改善とイノベーションを確保するには、次の推奨事項を検討してください。
定期的に振り返りを行う
振り返りは、インシデント対応手順を継続的に改善し、定期的なパフォーマンス テストと負荷テストの結果に基づいてテスト戦略を最適化するために不可欠です。レトロスペクティブを効果的に行うには、次のことを行います。
- チームに、経験を振り返り、うまくいったことを特定し、改善すべき点を特定する機会を与えます。
- プロジェクトのマイルストーン、重大なインシデント、重要なテスト サイクルの後に、振り返りを行います。チームは成功と失敗の両方から学び、プロセスとプラクティスを継続的に改善できます。
- 開始-停止-継続モデルなどの構造化されたアプローチを使用して、振り返りセッションが生産的で、実行可能なステップにつながるようにします。
- 振り返りを使用して、変更管理の自動化をさらに強化して信頼性を高め、リスクを軽減できる領域を特定します。
学習する文化を育む
学習文化は、Google Cloudでの新しいテクノロジーの安全な探索を促進します。たとえば、AI や ML の機能を活用して、不正行為の検出やパーソナライズされた財務アドバイスなどのサービスを強化します。学習文化を促進するには、次のことを行います。
- チームが実験を行い、知識を共有し、継続的に学習することを奨励します。
- 失敗を成長と改善の機会と捉える、誰も責めない文化を採用します。
- チームがリスクを冒して革新的なソリューションを検討できる、心理的に安全な環境を構築します。チームは成功と失敗の両方から学び、より回復力と適応力のある組織につながります。
- インシデント管理プロセスとテスト演習から得られた知識の共有を促進する文化を育みます。
クラウド テクノロジーの最新情報を入手する
継続的な学習は、新しいセキュリティ対策を理解して実装し、高度なデータ分析を活用してより優れた分析情報を取得し、金融業界に関連する革新的なソリューションを採用するために不可欠です。
- 最新の進歩、機能、ベスト プラクティスに関する情報を常に把握することで、 Google Cloud サービスの可能性を最大限に引き出します。
- 新しい機能とサービスが導入されたら、プロセスをさらに自動化し、セキュリティを強化し、アプリケーションのパフォーマンスとスケーラビリティを向上させる機会を特定します。 Google Cloud
- 関連するカンファレンス、ウェビナー、トレーニング セッションに参加して、知識を広げ、新機能を理解します。
- チームメンバーに Google Cloud 認定資格の取得を促し、組織がクラウドで成功するために必要なスキルを確実に身につけられるようにします。