Well-Architected Framework の金融サービス（FS）の視点のこのドキュメントでは、 で堅牢な FS ワークロードを構築、デプロイ、運用するための原則と推奨事項の概要について説明します。Google Cloud Google Cloudこれらの推奨事項は、オブザーバビリティ、自動化、スケーラビリティなどの基本的な要素を設定するのに役立ちます。このドキュメントの 推奨事項は、Well-Architected Framework の オペレーショナル エクセレンスの柱 に沿っています。
オペレーショナル エクセレンスは、規制が厳しく機密性の高い FS ワークロードにとって非常に重要です。 Google Cloud オペレーショナル エクセレンスにより、クラウド ソリューションは進化するニーズに適応し、価値、パフォーマンス、セキュリティ、信頼性に関する要件を満たすことができます。 これらの領域で障害が発生すると、多額の金銭的損失、規制上の罰則、評判の低下につながる可能性があります。
オペレーショナル エクセレンスは、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% にします（スケジュールされたメンテナンスの時間枠を除く）。 |
支払いプラットフォームの最小稼働時間に関する、クライアントに対する正式な法的拘束力のあるコミットメント（満たせなかった場合の結果を含む）。 例: プラットフォームは、スケジュールされた メンテナンスの時間枠を除き、1 暦月あたり 99.9% 以上の可用性を維持します。可用性が最小レベルを下回った場合、クライアントは 0.1% 低下するごとに月額サービス手数料の 5% のサービス クレジットを受け取ります。 |
SLI データを使用して、システムが定義された SLO 内にあるかどうかをモニタリングし、SLA が満たされていることを確認します。適切に定義された SLI のセットを使用することで、エンジニアとデベロッパーは、次のレベルで FS アプリケーションをモニタリングできます。
- アプリケーションがデプロイされているサービス（GKE や Cloud Run など）内で直接。
- ロードバランサなどのインフラストラクチャ コンポーネントによって提供されるログを使用する。
OpenTelemetry は、指標、トレース、ログなど、あらゆる種類のテレメトリーをキャプチャするためのオープンソース標準と一連のテクノロジーを提供します。Google Cloud Managed Service for Prometheus は、 Prometheus の指標とオペレーションを大規模に実行するためのフルマネージドでスケーラブルなバックエンドを提供します。
SLI、SLO、エラー バジェットの詳細については、 SRE ハンドブックをご覧ください。
効果的なアラートとモニタリングのダッシュボードとメカニズムを開発するには、 Google Cloud Observability ツールと Google Cloud Monitoringを併用します。 セキュリティ固有のモニタリング機能と検出機能については、 次の セキュリティの柱をご覧ください。
インシデント管理プロセスの定義とテスト
適切に定義され、定期的にテストされるインシデント管理プロセスは、 の FS ワークロードの価値、パフォーマンス、セキュリティ、信頼性に直接貢献します。 Google Cloudこれらのプロセスは、金融機関が厳格な規制要件を満たし、センシティブ データを保護し、ビジネスの継続性を維持し、お客様の信頼を維持するのに役立ちます。
インシデント管理プロセスの定期的なテストには、次のメリットがあります。
- ピーク負荷時のパフォーマンスを維持する: 定期的なパフォーマンス テストと負荷 テストにより、金融機関は、クラウドベースの アプリケーションとインフラストラクチャが、トランザクション量のピーク、市場の 変動、その他の高需要シナリオに対応できることを、パフォーマンスの 低下なしに確認できます。この機能は、シームレスなユーザー エクスペリエンスを維持し、金融市場の需要を満たすために不可欠です。
- 潜在的なボトルネックと制限を特定する: ストレステスト では、システムを限界までプッシュし、金融機関が 重要なオペレーションに影響を与える前に、潜在的なボトルネックとパフォーマンスの制限を 特定できます。このプロアクティブなアプローチにより、金融機関はインフラストラクチャとアプリケーションを調整して、最適なパフォーマンスとスケーラビリティを実現できます。
- 信頼性と復元力を検証する: カオス エンジニアリングや障害のシミュレーションなどの定期的なテストは、金融システムの信頼性と復元力を検証するのに役立ちます。このテストにより、システムが障害から正常に復旧し、高可用性を維持できることが保証されます。これは、ビジネスの継続に不可欠です。
- **効果的な容量計画を実施する**: パフォーマンス テストでは、さまざまな負荷条件でのリソース使用に関する貴重なデータが提供されます。これは、正確な容量計画に不可欠です。 金融機関は、このデータを使用して、将来の容量ニーズをプロアクティブに予測し、リソースの制約によるパフォーマンスの問題を回避できます。
- 新しい機能とコードの変更を正常にデプロイする: 自動テストを 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 認定資格 を取得するよう奨励し、組織がクラウドでの成功に必要なスキルを 確実に習得できるようにします。