Google Cloud Well-Architected Framework: 金融サービス（FS）の視点のこのドキュメントでは、 Google Cloudで堅牢な FS ワークロードを構築、デプロイ、運用するための原則と推奨事項の概要について説明します。これらの推奨事項は、オブザーバビリティ、自動化、スケーラビリティなどの基本的な要素を設定するのに役立ちます。このドキュメントの推奨事項は、Well-Architected Framework のオペレーショナル エクセレンスの柱に沿っています。
Google Cloud の FS ワークロードは、規制が厳しく機密性が高いため、優れた運用が不可欠です。オペレーショナル エクセレンスにより、クラウド ソリューションは進化するニーズに適応し、価値、パフォーマンス、セキュリティ、信頼性の要件を満たすことができます。これらの領域で障害が発生すると、多大な金銭的損失、規制上の罰則、評判の低下につながる可能性があります。
オペレーショナル エクセレンスは、FS ワークロードに次のメリットをもたらします。
- 信頼と評判を維持する: 金融機関は、顧客の信頼に大きく依存しています。業務の中断やセキュリティ侵害は、この信頼を著しく損ない、顧客の離脱を招く可能性があります。オペレーショナル エクセレンスは、これらのリスクを最小限に抑えるのに役立ちます。
厳しい規制遵守要件を満たす: 金融サービスは、次のような多数の複雑な規制の対象となります。
規制へのコンプライアンスを実証し、ペナルティを回避するには、堅牢な運用プロセス、モニタリング、インシデント管理が不可欠です。
ビジネスの継続性と復元力を確保する: 金融市場とサービスは、多くの場合、継続的に運用されます。そのため、高可用性と効果的な障害復旧が最も重要です。オペレーショナル エクセレンスの原則は、復元性に優れたシステムの設計と実装の指針となります。信頼性の柱では、この分野に関する詳細なガイダンスを提供しています。
機密データを保護する: 金融機関は、機密性の高い顧客データや財務データを大量に扱います。データ侵害を防止し、プライバシーを維持するには、強力な運用管理、セキュリティ モニタリング、迅速なインシデント対応が不可欠です。セキュリティの柱では、この分野に関する詳細なガイダンスを提供しています。
重要なアプリケーションのパフォーマンスを最適化する: 取引プラットフォームやリアルタイム分析など、多くの金融アプリケーションでは、高いパフォーマンスと低レイテンシが求められます。これらのパフォーマンス要件を満たすには、高度に最適化されたコンピューティング、ネットワーキング、ストレージの設計が必要です。パフォーマンス最適化の柱では、この分野に関するガイダンスをさらに提供しています。
費用を効果的に管理する: 金融機関は、セキュリティと信頼性に加えて、費用対効果も重視しています。オペレーショナル エクセレンスには、リソース使用率の最適化とクラウド支出の管理に関するプラクティスが含まれます。費用最適化の柱では、この分野に関するガイダンスをさらに提供しています。
このドキュメントのオペレーショナル エクセレンスの推奨事項は、次の基本原則にマッピングされています。
SLA とそれに対応する SLO / SLI の定義
多くの FS 組織では、アプリケーションの可用性は通常、目標復旧時間（RTO）と目標復旧時点（RPO）の指標に基づいて分類されます。外部のお客様にサービスを提供するビジネスクリティカルなアプリケーションの場合は、サービスレベル契約（SLA）が定義されることもあります。
SLA には、ユーザー満足度の観点からシステムの動作を表す指標のフレームワークが必要です。サイト信頼性エンジニアリング（SRE）の手法を使用すると、必要なレベルのシステム信頼性を実現できます。指標のフレームワークを作成するには、ユーザーの視点からシステムの健全性を把握するために、主要な数値指標を定義してモニタリングする必要があります。たとえば、レイテンシやエラー率などの指標は、サービスのパフォーマンスを定量化します。これらの指標は、サービスレベル指標（SLI）と呼ばれます。効果的な SLI を開発することは、信頼性を客観的に評価するために必要な元データを提供するため、非常に重要です。
意味のある SLA、SLI、SLO を定義するには、次の推奨事項を考慮してください。
- 重要なサービスごとに SLI を開発して定義します。許容可能なパフォーマンス レベルを定義する目標値を設定します。
- SLI に対応するサービスレベル目標（SLO）を開発して定義します。たとえば、SLO では、リクエストの 99.9% のレイテンシが 200 ミリ秒未満である必要があると規定される場合があります。
- サービスが 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 を使用することで、エンジニアとデベロッパーは次のレベルで FS アプリケーションをモニタリングできます。
- アプリケーションがデプロイされているサービス（Google Kubernetes Engine や Cloud Run など）内で直接。
- ロードバランサなどのインフラストラクチャ コンポーネントによって提供されるログを使用する。
OpenTelemetry は、指標、トレース、ログなど、あらゆる種類のテレメトリーをキャプチャするためのオープンソース標準と一連のテクノロジーを提供します。Google Cloud Managed Service for Prometheus は、Prometheus の指標と運用を大規模に処理するための、フルマネージドでスケーラビリティに優れたバックエンドを提供します。
SLI、SLO、エラー バジェットの詳細については、SRE ハンドブックをご覧ください。
効果的なアラートとモニタリングのダッシュボードとメカニズムを開発するには、Google Cloud Observability ツールと Cloud Monitoring を組み合わせて使用します。セキュリティ固有のモニタリング機能と検出機能については、セキュリティの柱をご覧ください。
インシデント管理プロセスの定義とテスト
明確に定義され、定期的にテストされるインシデント管理プロセスは、 Google Cloudの FS ワークロードの価値、パフォーマンス、セキュリティ、信頼性に直接貢献します。これらのプロセスは、金融機関が厳格な規制要件を満たし、機密データを保護し、ビジネスの継続性を維持し、顧客の信頼を維持するのに役立ちます。
インシデント管理プロセスを定期的にテストすると、次のようなメリットがあります。
- ピーク負荷時のパフォーマンスを維持する: 定期的なパフォーマンス テストと負荷テストにより、金融機関は、クラウドベースのアプリケーションとインフラストラクチャが、パフォーマンスを低下させることなく、ピーク時の取引量、市場の変動、その他の高需要シナリオに対応できることを確認できます。この機能は、シームレスなユーザー エクスペリエンスを維持し、金融市場の需要を満たすために不可欠です。
- 潜在的なボトルネックと制限を特定する: ストレステストでは、システムを限界まで追い込むことで、金融機関は重要なオペレーションに影響を与える前に、潜在的なボトルネックとパフォーマンスの制限を特定できます。このプロアクティブなアプローチにより、金融機関はインフラストラクチャとアプリケーションを調整して、最適なパフォーマンスとスケーラビリティを実現できます。
- 信頼性と復元力を検証する: カオス エンジニアリングや障害のシミュレーションなどの定期的なテストは、金融システムの信頼性と復元力の検証に役立ちます。このテストにより、システムが障害から正常に復旧し、高可用性を維持できることが確認されます。これは、ビジネスの継続性に不可欠です。
- 効果的な容量計画を実行する: パフォーマンス テストでは、さまざまな負荷条件でのリソース使用率に関する貴重なデータが得られます。これは、正確な容量計画に不可欠です。金融機関は、このデータを使用して、将来の容量ニーズを事前に予測し、リソースの制約によるパフォーマンスの問題を回避できます。
- 新機能とコード変更を正常にデプロイする: 自動テストを 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 認定資格の取得を促し、組織がクラウドで成功するために必要なスキルを確実に身に付けられるようにします。