オペレーショナル エクセレンス

アーキテクチャ フレームワークのこのセクションでは、ビジネス価値を提供するシステムを効率的に実行、管理、およびモニタリングすることにより、オペレーショナル エクセレンスがどのようにもたらされるかを探ります。

このフレームワークは、次の一連の記事で構成されています。

オペレーショナル エクセレンスは、もう 1 つの重要な原則である信頼性の構築に役立ちます(Google Cloud で信頼性の高いサービスを設計、運用するための関連する技術要件と手順要件については、信頼性のセクションをご覧ください)。

戦略

これらの戦略を使用して、オペレーショナル エクセレンスを実現します。

ビルド、テスト、デプロイを自動化する。継続的インテグレーションと継続的デプロイ(CI / CD)パイプラインを使用して、リリースに自動テストを組み込みます。自動化された統合テストとデプロイを実行します。

ビジネス目標の指標を監視する。関連するビジネス指標を定義、測定、通知します。

障害復旧テストを実施する。障害が発生するのを待ちません。代わりに、障害復旧手続きが機能することを定期的に確認し、プロセスを定期的にテストします。

ベスト プラクティス

オペレーショナル エクセレンスを実現するには、次の方法をおすすめします。

  • ソフトウェアの開発とリリースのスピードアップ。
  • システムの健全性とビジネスの健全性の監視。
  • 障害復旧に備えた計画と設計。

以下のセクションでは、ベスト プラクティスについて詳しく説明します。

開発とリリースのスピードアップ

CI / CD アプローチを使用して速度を上げます。まず、ソフトウェア開発チームの生産性を高め、統合テストをビルドプロセスにおいて自動化します。ビルドが特定のテスト基準を満たした後にデプロイを自動化します。デベロッパーは小規模で頻繁に変更を加えることができます。変更は入念にテストされ、デプロイにかかる時間が短縮されます。

このセクションでは、CI/CD アプローチの要素、リリース エンジニアリング、自動化、中央のコード リポジトリ、ビルド パイプライン、テスト、デプロイについて説明します。

リリース エンジニアリング

リリース エンジニアリングは、ソフトウェアの構築方法と提供方法を監督するジョブ機能です。リリース エンジニアリングは次の 4 つの方法で行われます。

  • セルフサービス モード。 ソフトウェア エンジニアがよくある間違いを避けるためのガイドラインを確立します。自動化されたプロセスによって適用されます。
  • 頻繁なリリース。 高速化はトラブルシューティングに役立ち、問題の修正を容易にします。頻繁なリリースは自動化された単体テストに依拠します。
  • ハーメティック ビルド。ビルドツールとの整合性を確保します。バージョンのビルドに使用するビルド コンパイラのバージョンを 1 か月前と比較します。
  • ポリシーの適用。すべての変更には、コードの審査が必要です。セキュリティを強化するための一連のガイドラインとポリシーを含めることが理想的です。これにより、コードのレビュー、トラブルシューティング、新しいリリースのテストが改善されます。

自動化

ビルドとリリースのパイプラインを自動化して、既知の問題をスキャンし、迅速なテストを実行します。また、自動化を使用して、反復的なタスクを排除することもできます。

中央のコード リポジトリ

必要に応じて、コードを中央のリポジトリに保存し、バージョニングしてラベルを付けます(test、dev、prod など)。これらの手順を行うことで、ビルド パイプラインで一貫した結果を得ることができます。Google Cloud では、コードを Cloud Source Repositories バージョンに保存し、さまざまなプロダクトと統合できます。

パイプラインの構築

ビルド構成をバージョニングして、すべてのビルドに一貫性を持たせ、必要に応じて最新の最適な構成にロールバックできるようにします。Google Cloud では、Cloud Build を使用して、アプリケーション パッケージをビルドするための依存関係とバージョンを定義できます。Cloud Functions を使用してビルドプロセスを定期的にトリガーしたり、新しいコードがチェックインされたときに特定のイベントでビルドをトリガーしたりできます。Cloud Functions を使用してテストをトリガーし、パイプライン全体を自動化することもできます。

テスト

テストはリリースの成功に不可欠です。テストの例を以下に示します。

  • 単体テスト。単体テストは高速で、迅速なデプロイに役立ちます。
  • 統合テスト。これらのテストは、相互接続されたサービスとの統合をテストするときに複雑になることがあります。
  • システムテスト。システムテストは時間がかかり、複雑ですが、デプロイ前にエッジケースを特定して問題を修正するのに役立ちます。

アプリケーションを本番環境にデプロイする前に、静的テスト、負荷テスト、セキュリティなど、他のテストを実行できます。テストを自動化したら、新しいテストを更新して追加し、デプロイの運用状況を改善して維持できます。

デプロイ

アプリケーションの展開方法を選択できます。カナリアテストを行ってシステムにエラーがないかどうかを確認することをおすすめします。これは、堅牢なモニタリング システムとアラート システムがある場合はより簡単です。Google Cloud では、マネージド インスタンス グループ(MIG)を使用して A/B テストやカナリアテストを行い、必要に応じて低速ロールアウトまたはロールバックを実行できます。

設計に関する質問

  • 開発チームはビルドとリリースをどのように管理しているか?
  • 開発チームはどの統合およびセキュリティ テストを採用しているか?
  • どのようにロールバックするか?

推奨事項

  • CI / CD パイプラインを本番環境にデプロイする唯一の方法にします。
  • CI / CD 環境を分離して保管します。
  • ビルドは 1 回のみで、パイプラインを介して結果をプロモートします。
  • CI / CD パイプラインを高速化します。
  • バージョン管理システムでのブランチを最小限に抑えます。

主なサービス

Cloud Source Repositories は、Google Cloud でホストされる多機能のプライベート Git リポジトリ サービスです。Cloud Source Repositories は、あらゆるアプリケーションやサービスの共同開発に使用できます。

Container Registry では、Docker イメージの一元的な管理と脆弱性分析を行えます。また、きめ細かなアクセス制御によって、どのユーザーが何にアクセスできるかを決定できます。CI / CD 統合がすでに組み込まれているため、完全に自動化された Docker パイプラインを設定すれば迅速なフィードバックを得ることができます。

Cloud Build は、Google Cloud インフラストラクチャでビルドを実行するサービスです。Cloud Build は、GitHub、Bitbucket、Cloud Storage、Cloud Source Repositories からソースコードをインポートし、仕様に合わせてビルドを実行して、Docker コンテナや Java アーカイブなどのアーティファクトを生成できます。

システムの健全性とビジネスの健全性の監視

DevOps リソースと評価(DORA)プロジェクトでは、次のようにモニタリングを定義しています。

モニタリングとは、ビジネス上の意思決定を行うために、情報を収集、分析、使用してアプリケーションやインフラストラクチャを追跡するプロセスです。モニタリングは、システムと作業に関する分析情報を提供する重要な機能です。

モニタリングを通じて、サービスに対する変更の影響を判断し、インシデント対応に科学的方法を適用して、ビジネス目標との整合性を測定できます。モニタリングを使用すると、次のことができます。

  • 長期的な傾向を分析する。
  • 一定期間のテストを比較します。
  • 重要な指標に関するアラートを定義します。
  • 関連性の高いリアルタイム ダッシュボードを作成します。
  • 振り返り分析を行います。

ビジネス主導の指標とシステムの健全性の指標の両方をモニタリングします。ビジネス主導の指標は、システムがビジネスをどの程度サポートしているかを理解するのに役立ちます。たとえば、アプリケーションでユーザーにサービスを提供する費用、再設計後のサイトへのトラフィック量の変化、サイトで商品を購入するのにかかる時間を監視できます。システムの状態の指標は、システムが正常に動作しているかどうか、および許容可能なパフォーマンス レベル内かどうかを理解するのに役立ちます。

システムをモニタリングするには、次の 4 つのシグナルを使用します。

  • レイテンシ。 リクエストの応答にかかる時間です。
  • トラフィック。システムに対する需要はどれくらいか。
  • エラー数。失敗したリクエストの割合です。リクエストの失敗は、明示的に失敗する場合(HTTP 500 など)、暗黙的に失敗する場合(HTTP 200 の成功のレスポンスでも内容の間違いなど)、またはポリシーによって失敗する場合(1 秒のレスポンス時間をコミットして、1 秒以上かかる場合はエラーなど)があります。
  • 飽和度。サービスの完全性を示し、最も制約のあるリソースを測定します(つまり、メモリ制約のあるシステムではメモリを表示し、I/O 制約のあるシステムでは I/O を表示します)。

ロギング

ロギング サービスはシステムのモニタリングに不可欠です。指標はモニタリングする特定の項目の基礎となりますが、ログにはデバッグ、セキュリティ関連の分析、コンプライアンス要件に必要な、重要な情報が含まれます。Google Cloud には、Google Cloud からのログデータやイベントの保存、検索、分析、モニタリング、アラートに使用できる、統合ロギング サービスである Cloud Logging が含まれています。Cloud Logging は、Google Cloud サービスから自動的にログを収集します。これらのログを使用して、モニタリング用の指標を作成し、Cloud StorageBigQueryPub/Sub などの外部サービスにログをエクスポートできます。

指標

デプロイの動作を測定するための指標を定義します。指標の定義が常にビジネスニーズに対応していることを確認し、指標を組み合わせてサービスレベル インジケーター(SLI)を作成することを検討してください。詳細については、信頼性をご覧ください。

インフラストラクチャやネットワークからビジネス ロジックまで、サービスのすべてのレベルで指標が生成されます。以下に例を示します。

  • ロードバランサによって測定される 1 秒あたりのリクエスト数。
  • ディスクあたりの合計読み取りディスク ブロック数。
  • 特定のネットワーク インターフェースを介して送信されたパケット。
  • 特定のプロセスのメモリ ヒープサイズ。
  • レスポンス レイテンシの分布。
  • データベース インスタンスによって拒否された無効なクエリの数。

モニタリング

複雑なアプリケーションをモニタリングすることは、それ自体が重要な技術的取り組みです。Google Cloud は、Google Cloud オペレーション スイートに含まれるマネージド サービスである Cloud Monitoring を提供します。Cloud Monitoring を使用して Google Cloud サービスとカスタム指標をモニタリングできます。CloudMonitoring は、サードパーティのモニタリング ツールと統合するための API を提供します。

Cloud Monitoring は、インフラストラクチャからの指標、ログ、イベントを集約して豊富な観測可能シグナルのセットを提供します。デベロッパーやオペレーターはこれを使用して速やかに根本原因を分析し、平均修復時間(MTTR)を短縮できます。ビジネス目標に合わせてアラートやカスタム指標を定義し、システムの状態を集計、可視化、モニタリングできます。

Cloud Monitoring は、クラウドとオープンソース アプリケーション サービス用のデフォルトのダッシュボードを提供します。指標モデルを使用すると、強力な可視化ツールでカスタム ダッシュボードを定義し、Metrics Explorer でグラフを構成できます。

ダッシュボード

モニタリングを実施したら、アクションに関連するダッシュボードを作成します。ダッシュボードはシンプルで読みやすいものにします。短期的またはリアルタイムの分析と長期的な分析の両方を行い、可視化する必要があります。詳細については、信頼性をご覧ください。

アラート

アラート システムがシステムをモニタリングする 4 つの重要な信号に直接マッピングされていることを確認してください。これにより、パフォーマンスを経時的に比較して、機能の速度の判断や、変更のロールバックができます。

アラートはアクションがとれるものにします。アラートを送信する場合は、説明を追加し、オンコールの担当者がすぐに対処するために必要なすべての情報を提供します。アラートに対処する方法を理解するために、数回のクリックやナビゲーションが必要ではいけません。

頻繁に発生するエラー修正の排除や自動化などにより、常に手間を省くようにします。それにより、オンコールの担当者は、運用コンポーネントの信頼性を高めることに集中できます。詳細については、信頼性をご覧ください。

エスカレーション パス

適切に定義されたエスカレーション パスは、Google Cloud プロダクトのサポートを受けるまでの労力を削減するための鍵となります。これには、Google のサポートチームとの連携方法、サポート エンジニア向けのアーキテクチャ ドキュメントの検索、停止時の通信方法の定義、問題の診断とモニタリングとロギングの設定が含まれます。

エスカレーション パスを定義するには、セキュリティ管理者、ネットワーク管理者、システム管理者が Google Cloud からの重要なメールやアラートを適切に受信できるようにします。これにより、管理者は情報に基づいて意思決定を行い、問題を早期に解決できます。同様に、プロジェクト オーナーが重要なメールを受信できるように、メール ルーティングが可能なユーザー名を持っていることを確認します。

推奨事項

  • ビジネスニーズに合った関連指標を選択します。
  • 必要に応じて、Cloud Monitoring を使用し、カスタム指標のモニタリング エージェントをデプロイします。
  • すべてのログエントリに対して Cloud Logging が構成されていることを確認します。
  • 成功率や失敗率など、明確に定義されたアラートを設計します。
  • 対処するための情報を含むアラートを発行します。
  • ロールベースまたはエンタープライズ サポート パッケージの購入を検討ください。
  • エスカレーション パスを定義し、Cloud サポートと連携しながら、時間、プロダクト、場所などの有用な指標を提供します。

主なサービス

Cloud Monitoring は、指標の収集、集計、ダッシュボードのほか、ウェブ アプリケーションやその他のインターネットアクセスの可能なサービスに対するアラート フレームワークとエンドポイント チェックを提供します。

Cloud Logging を使用すると、クラウドやオープンソースのアプリケーション サービスから BigQuery、Cloud Storage、Pub/Sub のログをフィルタリング、検索、表示、エクスポートできます。ダッシュボードとアラートに組み込まれているログの内容に基づいて指標を定義できます。

Cloud Debugger は、アプリケーション リクエストを停止または遅延させずに、本番環境の任意のコード位置でアプリケーションの状態を検査して、アプリケーションの本番データをソースコードに接続します。

Error Reporting は、クラウドアプリケーションのエラーを分析して集計し、新しいエラーが検出されたときに通知します。

Claud Trace は、App Engine 用にレイテンシのサンプリングを行い、URL ごとの統計とレイテンシの分布を含めてレポートします。

Cloud Profiler は、本番環境アプリケーションでのリソース消費の継続的なプロファイリングを提供し、パフォーマンスの問題を特定して排除するのに役立ちます。

リソース

ログをエクスポートするための設計パターン

障害復旧に備えた設計

障害のシナリオを予測して処理するようにシステムを設計することで、大災害が発生してもシステムへの影響が最小限に抑えられます。障害を予測するには、サービスとデータをバックアップおよび復元するための明確に定義され、定期的にテストされた障害復旧(DR)計画が必要です。

サービスが中断される事態はいつでも発生する可能性があります。ネットワークに障害が発生することや、最新のアプリケーション更新が重大なバグを引き起こすことがあり、自然災害への対処が必要になる場合もあります。予想外の事態が発生した場合に備え、十分に検証された、対象が明確で信頼性の高い DR 計画を作成することが重要です。

計画

DR は事業継続計画の一環です。DR 計画はビジネスへの影響の分析から着手します。この分析で次の 2 つの主要な指標を定義します。

  • 復旧時間目標(RTO)。アプリケーションがオフラインである状態が許容される最大時間です。通常、この値はサービスレベル契約(SLA)の一部として定義されます。

  • 復旧時点目標(RPO)。重大なインシデントが原因でアプリケーションからデータが失われている状態が許容される最大時間です。この指標はデータの用途によって異なります。たとえば、頻繁に変更されるユーザーデータの場合、RPO はわずか数分になる可能性があります。重要度が低く、変更頻度が低いデータの場合、RPO が数時間になることもあります。この指標は、失われたデータの量や質ではなく時間の長さのみを表します。

通常、RTO 値と RPO 値が小さいほど(つまり、アプリケーションが中断から迅速に回復する必要がある)、アプリケーションの実行コストが高くなります。次のグラフは RTO / RPO に対するコストの割合を示しています。

RTO / RPO に対するコストの比率。アプリケーションの復旧が速いほど、アプリケーションの実行コストが高くなります。

RTO と RPO の値が小さいほど複雑になることが多いため、管理オーバーヘッドは同様の曲線を描きます。たとえば、高可用性(HA)アプリケーションでは、物理的に離れた 2 つのデータセンター間の分散の管理、レプリケーションの管理などが必要になります。

RTO と RPO の値は通常、サービスレベル目標(SLO)という別の指標に含められます。SLO は SLA の測定可能な重要要素であり、

  • SLA は、提供されるサービスの内容、サービスのサポート方法、時間、ロケーション、コスト、パフォーマンス、ペナルティ、当事者の責任を包括的に規定する契約です。
  • SLO は、SLA の個々の測定可能な特性(可用性、スループット、頻度、レスポンス時間、品質など)を表します。

1 つの SLA に多数の SLO を含めることができます。RTO と RPO は測定可能であるため、SLO と見なされます。

インフラストラクチャの要件

DR では、次のようなさまざまな要件を考慮することをおすすめします。

  • 容量: 必要に応じたスケーリングに十分なリソースを確保する。
  • セキュリティ: 資産を保護するための物理的なセキュリティ対策を実施する。
  • ネットワーク インフラストラクチャ: ファイアウォールやロードバランサなどのソフトウェア コンポーネントを含める。
  • サポート: 保守を実施し、問題に対処する熟練した技術者を配備する。
  • 帯域幅: 負荷のピークに対応可能な帯域幅を計画する。
  • 設備: 機器や電源などの物理的なインフラストラクチャを確保する。

Google Cloud での障害復旧

Google Cloud は、オンプレミスよりも RTO と RPO の要件を満たすためのコストを削減できます。Google Cloud は、物理ハードウェアに関連する複雑な要因のほとんどまたはすべてを回避し、プロセスの多くのビジネスコストを削減します。さらに、管理の簡素化に重点を置いた Google Cloud は、複雑なアプリケーションの管理コストを削減できるように設計されています。

Google Cloud には、DR 計画に関連するいくつかの機能があります。

グローバルなネットワーク。 Google のコンピュータ ネットワークは、その規模、先進性ともに世界有数を誇ります。Google のバックグラウンド ネットワークは、高度なソフトウェア定義ネットワーキングを使用し、エッジキャッシング サービスを使用して、高速で一貫性のあるスケーラブルなパフォーマンスを実現します。

冗長性。 世界中の複数の拠点(PoP)によって、強力な冗長性が確保されます。データは複数のロケーションにあるストレージ デバイスに自動的にミラーリングされます。

スケーラビリティ。Google Cloud は、Google の他のプロダクト(検索や Gmail など)と同様に、トラフィックが急増してもスケールできるように設計されています。App EngineCompute Engine オートスケーラー、Datastore などのマネージド サービスは、アプリケーションを必要に応じて拡大縮小できるように自動スケーリングを提供します。

セキュリティ。Google セキュリティ モデルは、Gmail や G Suite などの Google アプリケーションで 15 年以上にわたってお客様のセキュリティを保護してきた、豊富な経験に基づいて構築されています。また、Google のサイト信頼性エンジニアリング チームは、高可用性を確保し、プラットフォーム リソースの不正使用を防止します。

コンプライアンス。Google は独立した第三者による監査を定期的に実施し、Google Cloud がセキュリティ、プライバシー、コンプライアンスの各規制とベスト プラクティスに適合しているか確認します。Google Cloud は、ISO 27001、SOC 2/3、PCI DSS 3.2 などの認証を遵守しています。

推奨事項

  • RTO と RPO の目標を定義します。
  • データとアプリケーションのソリューションに基づいて DR 計画を設計します。
  • 1 年に 1 回以上手動で DR 計画をテストします。
  • 制御されたフォールト インジェクションの実装を評価して、リグレッションを早期に検出します。
  • カオス エンジニアリングを活用してリスク領域を見つけます。

主なサービス

Persistent Disk スナップショットは、増分バックアップまたは Compute Engine 仮想マシン(VM)のスナップショットを提供します。これをリージョン間でコピーして、災害発生時に永続ディスクを再作成するために使用できます。

ライブ マイグレーションでは、ホストシステムでソフトウェア / ハードウェアの更新などのイベントが発生しても、VM インスタンスの実行が継続されます。

Cloud Storage は、バックアップなどの特定のユースケースに適した Nearline や Coldline などのストレージ クラスを提供するオブジェクト ストアです。

Cloud DNS は自動復旧プロセスの一環として、DNS エントリをプログラムで管理する方法を提供します。Cloud DNS は、Anycast ネームサーバーの Google グローバル ネットワークを使用して、全世界のあらゆる場所からお客様の DNS ゾーンをサポートし、高い可用性と低レイテンシを提供します。

リソース