Google Cloud への移行: 環境の最適化

Last reviewed 2023-12-07 UTC

このドキュメントは、Google Cloud への移行の最適化フェーズを計画し設計するうえで役立ちます。ワークロードを Google Cloud にデプロイしたら、環境の最適化を開始できます。

このドキュメントは、Google Cloud への移行に関する次の複数のパートからなるシリーズの一部です。

次の図は、移行の過程を示しています。

4 フェーズの移行パス

最適化フェーズでは、初期 Deployment よりも効率が高まるように環境を調整します。

このドキュメントでは、Google Cloud への移行後に既存の環境の最適化を計画する際に役立つ情報を提供します。また、最適化の機会について検討している場合、その概要を把握するためにも利用できます。

最適化フェーズの構造は、このシリーズでの移行のフレームワーク、つまり評価、計画、デプロイ、最適化に従います。この多彩なフレームワークを使用すれば、移行プロセスの全体を計画し、また各フェーズで個々のアクションを分割できます。最適化フェーズの最後のステップが完了したら、このフェーズを最初から再スタートさせて、新しいターゲットを見つけ最適化できます。最適化フェーズは最適化ループとして定義されています。ループの実行は、最適化イテレーションとして定義されています。

最適化は、終わることのない継続的な作業です。環境の進化に伴い環境を常に最適化していきます。管理されていない重複した作業を回避するため、測定可能な最適化の目標を設定し、目標達成時には作業を停止します。その後いつでも新しく意欲的な目標を設定できますが、最適化にはリソース、時間、労力、スキルの点で費用がかかることを考慮してください。

次の図は、最適化ループを示しています。

最適化のディシジョン ツリーこれを拡大した図があります。最適化ディシジョン ツリーをご覧ください。

このドキュメントでは、最適化ループの、次の繰り返し可能な手順を行います。

  1. 環境、チーム、フォロー中の最適化ループを評価します。
  2. 最適化の要件と目標を設定します。
  3. 環境を最適化し、チームをトレーニングします。
  4. 最適化ループを調整します。

このドキュメントでは、サイト信頼性エンジニアリング（SRE）の原則とコンセプトについて説明します。Google は、数十億のユーザーにサービスを提供する世界規模のインフラストラクチャを効率的かつ確実に運用するために SRE 規律を策定しました。多くのビジネス プロセスやコラボレーション プロセスを変更する必要がある場合、組織に完全な SRE 規律を導入することは実用的ではありません。組織に最適な SRE 規律のサブセットを適用するほうが簡単である場合があります。

環境、チーム、最適化ループを評価する

最適化タスクを開始する前に、環境を評価する必要があります。環境の最適化にて、現在チームに欠けているスキルが必要になることがあるため、チームのスキル評価も必要です。最後に、最適化ループを評価する必要があります。ループは、他のリソースと同様に最適化できるリソースです。

環境を評価する

環境を深く理解する必要があります。最適化を成功させるには、環境の仕組みを理解し、改善の余地がある部分を特定する必要があります。この評価では、最適化フェーズや次の最適化のイテレーションと比較するためのベースラインを確立します。

Google Cloud への移行: ワークロードの評価と調査には、ワークロードの評価と環境の評価に関する広範なガイダンスが記載されています。最近 Google Cloud への移行が完了した場合、環境の構成、管理、メンテナンスに関する詳細情報がすでに用意されています。それ以外の場合、そのガイダンスが環境の評価に利用できます。

チームを評価する

自分の環境を明確に把握している場合、チームのスキルを評価して把握します。まず、すべてのスキル、各スキルの専門知識レベル、各スキルについて最も知識のあるチームメンバーをリストします。次のフェーズでこの評価を使用して、最適化の目標を達成するために欠けている必要スキルを見つけます。たとえば、マネージド サービスを使用するには、そのサービスのプロビジョニングと構成、およびサービスとやりとりするスキルが必要です。Memorystore を使用して環境内のアプリケーションにキャッシュ レイヤを追加する場合は、そのサービスを使用できる専門知識が必要です。

環境を最適化すると、ビジネス プロセスやコラボレーション プロセスに影響することがあります。たとえば、セルフマネージド サービスの代わりにフルマネージド サービスを使用すれば、オペレータの時間を捻出して手間を省くことができます。

最適化ループを評価する

最適化ループは最適化できるリソースです。この評価で収集したデータを使用して、最後の最適化イテレーションにおけるチームのパフォーマンスを明確に把握します。たとえば、イテレーション期間の短縮を目標とする場合は、前回のイテレーションに関するデータ（複雑さや達成したい目標など）が必要です。また、最後のイテレーションで発生したすべてのブロッカーに関する情報も必要です。ブロッカーが再発した場合は緩和策を講じます。

この最適化のイテレーションが初回である場合は、パフォーマンスを比較するためのベースラインの確立に十分なデータがない可能性があります。最初のイテレーションでチームが期待するパフォーマンスについて、一連の仮説を立てます。最初の最適化イテレーションの後、ループとチームのパフォーマンスを評価し、仮説と比較します。

最適化の要件と目標を設定する

最適化タスクを開始する前に、そのイテレーションについて明確に測定可能な一連の目標の案を作成します。

この手順では、次のアクティビティを行います。

  1. 最適化の要件を定義します。
  2. 最適化の要件に応じて、測定可能な最適化目標を設定します。

最適化の要件を定義する

最適化フェーズの要件をリストします。要件は改善の必要性を表し、必ずしも測定可能である必要はありません。

ワークロード、環境、最適化ループの品質特性から始めて、要件の設定に役立つアンケートの下書きを作成できます。アンケートには、環境、プロセス、ワークロードに役立つ特性を含めます。

品質特性を定義する際は、さまざまな情報源を利用できます。たとえば、ソフトウェア プロダクトの品質特性を定義している ISO/IEC 25010 標準や、Google Cloud 設定チェックリストを参考にできます。

たとえば、アンケートでは次の質問ができます。

  • インフラストラクチャとそのコンポーネントを垂直または水平にスケールできますか？
  • インフラストラクチャで、人の手を加えずに変化をロールバックできますか？
  • インフラストラクチャとワークロードをモニタリングリングするシステムは用意されていますか？
  • インフラストラクチャのインシデント管理システムはありますか？
  • 計画した最適化の実装にどれくらい時間がかかりますか？
  • 過去のイテレーションですべての目標を達成できましたか？

このアンケートの回答から、最適化イテレーションの要件リストを作成します。たとえば、要件は次のようになります。

  • アプリケーションのパフォーマンスを向上させる。
  • 環境のコンポーネントの可用性を高める。
  • 環境のコンポーネントの信頼性を高める。
  • 環境の運用コストを削減する。
  • 固有のリスクを軽減するため、最適化のイテレーション期間を短縮する。
  • 開発期間を短縮し、市場投入までの時間を短くする。

改善領域のリスト作成が完了したら、リストに含まれた要件を評価します。この評価では、最適化への要件を分析して競合を探し、リストの要件に優先順序を付けます。たとえば、アプリケーションのパフォーマンスを向上させると、運用コストの削減と競合する場合があります。

測定可能な目標を設定する

要件のリストを確定したら、各要件に対して測定可能な目標を定義します。複数の要件が同じ目標を共有する場合があります。不確実な部分がある場合や、すべての要件に対して目標を設定できない場合は、このイテレーションの評価フェーズに戻って不足情報を収集し、要件を再度定義します。

これらの目標の定義については、SRE 規律の 1 つ、サービスレベル指標（SLI）とサービスレベル目標（SLO）の定義を利用できます。

  • SLI は、提供するサービスレベルの定量的な指標です。たとえば、主要な SLI として平均リクエスト レイテンシ、エラー率、またはシステム スループットがあります。
  • SLO は、SLI で測定したサービスレベルの目標値または値の範囲です。たとえば、平均リクエスト レイテンシの SLO が 100 ミリ秒未満に設定されることがあります。

SLI と SLO を定義した後、SLI の測定に必要なすべての指標の収集が完了していないことに気づくでしょう。これらの指標の収集は、最初に取り組むべき最適化の目標となります。モニタリング システムの拡張に関連する目標を設定し、SLI に必要なすべての指標を収集します。

環境とチームを最適化する

環境、チーム、最適化のループを評価し、イテレーションの要件と目標を設定できたら、最適化の手順を実行します。

この手順では、次のアクティビティを行います。

  1. 環境、チーム、最適化のループを測定します。
  2. これらの測定から得られたデータを分析します。
  3. 最適化アクティビティを実行します。
  4. もう一度、測定と分析を行います。

環境、チーム、最適化ループを測定する

モニタリング システムを拡張して、環境、チーム、最適化ループのデータを収集し、最適化後の比較に使用するベースラインを設定します。

このアクティビティは、評価フェーズで行った内容に基づいて行われます。要件と目標を設定したら、最適化目標に関連した測定のためにどのような指標を収集したらよいかがわかります。たとえば、SLO とそれに対応する SLI を定義して環境内ワークロードのレスポンス レイテンシを短縮する場合、データを収集してその指標を測定する必要があります。

指標の把握はまた、チームや最適化ループにも適用されます。モニタリング システムを拡張してデータを収集すれば、チームと最適化ループに関連する指標を測定できます。たとえば、SLO と SLI を使用して最適化のイテレーション期間を短縮する場合、データを収集してその指標を測定する必要があります。

モニタリング システムの拡張に必要な指標を設計すると、データの収集により環境やプロセスに影響が生ずる可能性があることを考慮してください。パフォーマンスへの影響を判断するため、測定に適用する指標とサンプル間隔を評価します。たとえば、サンプリング頻度が高い指標ではパフォーマンスが低下するため、さらなる最適化が必要になります。

Google Cloud では、Cloud Monitoring を利用して、データの収集に必要な指標を実装できます。ワークロードにカスタム指標を直接実装する場合は、Cloud Monitoring のための Cloud クライアント ライブラリまたは OpenTelemetry を使用できます。Google Kubernetes Engine（GKE）を使用している場合は、GKE 使用状況測定を使用して、CPU、GPU、TPU の使用状況などに関する情報を収集し、リソース使用量を Namespace やラベルで分割できます。

最後に、Cloud アーキテクチャ センターと Google Cloud ホワイトペーパーを出発点として使用し、環境を最適化するためにチームで身に付ける必要があると考えられる新しいスキルを見つけます。

データの分析

データを収集したら、そのデータを分析して評価し、最適化の要件と目標に対する環境、チーム、最適化ループのパフォーマンスを把握します。

特に、次の点について環境を評価します。

  • SLO
  • 業界ベスト プラクティス
  • 技術的負債のない環境

最適化の目標に沿って設定した SLO は、期待を満たしているかどうかの判断に役立ちます。SLO を満たしていない場合、チームや最適化ループを強化する必要があります。たとえば、ワークロードのレスポンス レイテンシが特定のパーセンタイル内に収まるよう SLO を設定し、その基準に達しない場合、これが、ワークロードの該当部分を最適化する必要性を知らせるシグナルとなります。

また、その状況を業界で定評のあるベスト プラクティスと比較することもできます。たとえば、Google Cloud 設定チェックリストは、エンタープライズ ワークロード向けにプロダクション レディな構成する場合に役立ちます。GKE を使用している場合は、コンテナ運用のベスト プラクティスに従っているかどうかを確認できます。

データを収集したら、環境を最適化して費用効率を高める方法を検討できます。Cloud Billing データを BigQuery にエクスポートし、データを Looker Studio で分析して使用リソース数を把握、支出パターンがあればそれを抽出します。

最後に、環境を技術的負債のない環境と比較して、長期的な目標を達成しているかどうか、技術的負債が増えているかどうかを確認します。たとえば、モニタリング対象の環境内のリソース数と、前回のイテレーション以降にプロビジョニングしたリソース数の比率について SLO を設定できます。これらの新しいリソースをカバーするようにモニタリング システムを拡張しなかった場合、技術的負債が増加します。技術的負債の変化を分析する際は、変化が生じた要因も考慮してください。たとえば、ビジネスニーズにより技術的負債が増加した場合や、予期できなかった場合が該当します。技術的負債が変化した要因を把握することで、今後の最適化目標についての洞察を得ることができます。

Google Cloud で環境をモニタリングするには、Monitoring を使用してグラフ、ダッシュボード、アラートを設計します。次に、Cloud Logging データを転送すると、詳細な分析と長期保存期間を設定できます。たとえば、集約シンクを作成し、Cloud Storage、Pub/Sub、BigQuery をエクスポート先として使用できます。データを BigQuery にエクスポートすると、Looker Studio を使用してデータを可視化できるため、傾向を把握して予測を立てられます。また、Recommender、Security Command Center などの評価ツールを使用して、環境とプロセスを自動的に分析し、最適化ターゲットを探すことができます。

すべての測定データを分析したら、次の 2 つの質問に答えてください。

  1. 最適化の目標を達成していますか？

    「はい」と答えた場合、この最適化イテレーションは完了し、新しい最適化を開始できます。「いいえ」と回答した場合は、2 つ目の質問に進みます。

  2. 予算を設定したリソースがあれば、このイテレーションで設定した最適化目標を達成できますか？

この質問に答えるには、時間、経費、専門知識など、必要なリソースをすべて考慮します。「はい」と回答した場合は、次のセクションに進みます。それ以外の場合は、このイテレーションに使用できるリソースを考慮して最適化の目標を再定義します。たとえば、固定したスケジュールで制約を受けている場合は、次のイテレーションで推進する最適化の目標を設定する必要があります。

チームを最適化する

環境の最適化は継続的な課題であり、評価と分析を通じて表面化したチームに欠けているスキルが必要になります。そのため、新しいスキルを身に付けプロセスを効率化してチームを最適化することが、最適化活動の成功に不可欠となります。

チームを最適化するには、以下を実施する必要があります。

  • トレーニング プログラムを設計して実装する。
  • チームの構造と文化を最適化する。

チームに欠けているスキルを習得するには、研修プログラムを設計して実施するか、Google Cloud のトレーニング担当者が提供するプログラムを利用します。詳細については、Google Cloud への移行: ワークロードの評価と検出をご覧ください。

チームを最適化すると同時に、構造や文化に改善する余地がある場合もあります。どの企業も独自の歴史と独自性を持ち、チームの構造や文化の進化に貢献しているため、理想的な状況を事前に規定することは困難です。

変革型リーダーシップは、DevOps プラクティスの採用を目的として組織の変化を実行し、測定するための一般的なフレームワークを学ぶ出発点となります。効率的な DevOps カルチャーを組織に導入する方法については、サイト信頼性エンジニアリング（SRE）で SRE 方法論の包括的な説明をご覧ください。サイトの信頼性に関するワークブックでは、具体的な例を使って SRE の原則と実践方法を説明しています。

環境を最適化する

指標データの測定と分析により、最適化が必要な箇所がわかります。

このセクションでは、Google Cloud 環境の一般的な最適化手法について説明します。使用しているインフラストラクチャやサービスに固有の最適化アクティビティを実行することもできます。

すべてをコード化する

Google Cloud などのパブリック クラウド環境を導入する最大のメリットの一つは、Cloud APIs などの明確なインターフェースを使用してリソースをプロビジョニング、構成、管理できることです。任意に選んだツールを使用して、Infrastructure as Code（IaC）プロセスとバージョン管理システムを定義できます。

Terraform などのツールを使用して Google Cloud リソースをプロビジョニングしてから、Ansible、Chef、Puppet などのツールを使用して、これらのリソースを構成できます。IaC プロセスは、最適化タスクの効果的なロールバック戦略の実装に役立ちます。インフラストラクチャを説明するコードに適用した変化を元に戻すことができます。また、変化をテストすることで、インフラストラクチャの更新時に発生する予期しない失敗を回避できます。

さらに、同様のプロセスを適用して指針のような環境の他の要素をコード化できます。その際、たとえば、Open Policy Agent やオペレーション コードである GitOps などのツールを使用します。

そのため、初期の最適化イテレーションで IaC プロセスを採用すれば、さらなる最適化アクティビティをコードとして定義できます。また、プロセスを段階的に適用して、環境に適したものかを評価することもできます。

すべてを自動化する

環境全体を完全に最適化するには、リソースを効率的に使用する必要があります。つまり、トイルを省いてリソースを節約し、最適化のような価値を生み出す重要なタスクに再投資する必要があります。

SRE の推奨事項に従い、自動化を強化することでトイルを省くことができます。自動化タスクがすべて、高度に専門化したソフトウェア エンジニアリング スキルや多大な労力を必要とするわけではありません。短いスクリプトを定期的に実行することで、1 日に数時間を節約できることもあります。Google Cloud では、Google Cloud CLI などのツール、Cloud APIs、Cloud Scheduler、Cloud Composer、Cloud Run などのマネージド サービスが提供されており、これらを用いて繰り返し作業を自動化できます。

すべてをモニタリングする

環境に関する評価値の詳細を収集できない場合、前提条件を支持するデータがないため環境を改善できません。つまり、最適化の目標を達成するために何をすべきかわからないということです。

包括的なモニタリング システムは、環境の不可欠なコンポーネントです。システムは、最適化目標達成のため、評価する必要があるすべての重要な指標をモニタリングします。モニタリング システムを設計する場合は、少なくとも 4 つのゴールデン シグナルをモニタリングするよう計画します。

Monitoring や Logging などのマネージド サービスを使用すると、複雑なモニタリング ソリューションを設定することなく環境をモニタリングできます。

複数のクラウド環境を同時に使用する特定の物理的な場所やサービスにのみデータを格納するデータ制限ポリシーを遵守するためには、ハイブリッド環境とマルチクラウド環境をモニターできるモニタリング システムを実装する必要があるかもしれません。

クラウド対応のアプローチを採用する

クラウド対応とは、クラウド上でアプリケーションを設計し実行する効率的な方法を表すパラダイムです。Cloud Native Computing Foundation（CNCF）は、クラウドネイティブ アプリケーションを、コンテナ、サービス メッシュ、マイクロサービス、イミュータブル インフラストラクチャ、宣言型 API などのテクノロジーにより、スケーラブルで復元性があり、管理と観測が可能なアプリケーションとして定義しています。Google Cloud では、GKE、Cloud Run、Cloud Service Mesh、Logging、Monitoring などのマネージド サービスを提供して、ユーザーがクラウド対応のアプリケーションを設計して実行できるよう支援します。

クラウド対応の技術の詳細については、CNCF トレイルマップと CNCF クラウド ネイティブ インタラクティブ ランドスケープをご覧ください。

費用管理

請求モデルと費用モデルが異なるため、Google Cloud などのパブリック クラウド環境の費用最適化は、オンプレミス環境の費用最適化とは異なります。

詳細については、Google Cloud への移行: 費用を最小限に抑えるをご覧ください。

再度、測定と分析をする

イテレーション最適化アクティビティを完了したら、測定と分析をイテレーションで目標を達成したかどうかを確認します。次の質問に答えます。

  • 最適化の目標を達成しましたか？

    「はい」と回答した場合は、次のセクションに移動できます。

    「いいえ」と回答した場合は、環境とチームを最適化するフェーズの最初に戻ります。

最適化ループをチューニングする

このセクションでは、このイテレーションで使用した最適化ループをチームの構造と環境に適合するよう更新し、変更します。

最適化ループをコード化する

最適化ループを効率的に最適化するには、標準化され、わかりやすく管理可能で、かつ変化を受け入れる形でループを文書化して定義する必要があります。Cloud Composer などのフルマネージド サービスを使用して、ワークフローの作成、スケジュール、モニタリング、管理ができます。また、ビジネス プロセスモデルと表記法（BPMN）などでプロセスを表すこともできます。その後、これらのプロセスを標準化された言語、たとえばビジネス プロセス実行言語（BPEL）でコード化できます。IaC の導入後は、コードでプロセスを記述することで、環境の残りの部分を IaC の導入後に管理できます。

最適化ループを自動化する

最適化ループをコード化したら、繰り返し作業を自動化して手間と時間を節約し、最適化ループを効率化できます。データの測定やチームが分析する集計レポートの作成など、人間の判断が不要なすべてのタスクを自動化できます。たとえば、Cloud Monitoring を使用してデータ分析を自動化し、定義した SLO を環境が満たしているかどうかを確認できます。最適化は終わりのないタスクであるため、最適化ループをイテレーションすることで、小さい自動化でもその積み重ねによって効率が大きく向上する場合があります。

最適化ループをモニタリングする

環境内のすべてのリソースと同じように、最適化ループをモニタリングして予期した運用がなされているかを確認し、ボトルネックや今後の最適化の目標も探します。チームが各最適化ステップで費やした時間とリソースの数を追跡することで、モニタリングを開始できます。たとえば、問題追跡システムとプロジェクト管理ツールを使用して、プロセスをモニタリングし、問題解決時間や完了までの時間などの指標に関連する統計情報を抽出できます。

次のステップ