GSP484

概要

HTTP リクエストを処理したり、API を提供したりする本番環境システムをサポートする際には、エンドポイントのレイテンシを測定して、システムのパフォーマンスが仕様の範囲から外れたタイミングを検出することが重要です。モノリシック システムでは、こうした単一のレイテンシ測定が動作の問題の検出および診断に役立つ場合があります。ただし、最新のマイクロサービス アーキテクチャでは、1 回のリクエストが完全に処理されるまでに、そのリクエストから他のシステムに対する多数の追加リクエストが発生するため、こうした測定はずっと困難になります。

基盤となるシステムでパフォーマンスが悪化すると、そのシステムに依存しているその他すべてのシステムにも影響が及ぶ可能性があります。レイテンシはサービス エンドポイントごとに測定できますが、パブリック エンドポイントでの動作速度の低下を、動作に問題がある特定のサブサービスと相互に関連付けることは困難な場合があります。

次に、分散トレースについて説明します。分散トレースでは、リクエストと一緒に渡されたメタデータを使用して、サービス階層間でリクエストを相互に関連付けます。マイクロサービス アーキテクチャですべてのサービスからテレメトリー データを収集し、最初のリクエストのトレース ID をすべての従属リクエストに伝播すると、デベロッパーは、どのサービスが速度の低下を引き起こしてシステムの残り部分に影響を及ぼしているかをずっと容易に特定できます。

Google Cloud には、ロギング、モニタリング、分散トレースに対応するプロダクト スイートの Operations が用意されています。このラボでは、Kubernetes Engine へのデプロイを取り上げ、分散トレースを実装している多層アーキテクチャの具体例を示します。また、Terraform を利用して、必要なインフラストラクチャを構築します。

このラボは、GKE Binary Authorization に関する理解を深めていただくために GKE Helmsman のエンジニアによって作成されました。デモは、Cloud Shell で gsutil cp -r gs://spls/gke-binary-auth/* . および cd gke-binary-auth-demo コマンドを実行するとご覧いただけます。このアセットへのコントリビューションをぜひお寄せください。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モード（推奨）またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。 左側の [ラボの詳細] ペインには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] ペインでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] ペインでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

2. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

3. [承認] をクリックします。

4. 出力は次のようになります。

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

デモのクローンを作成する

1. 次のコマンドを実行して、このラボに必要なリソースのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/gke-tracing-demo

2. このデモ用のディレクトリに移動します。

cd gke-tracing-demo

リージョンとゾーンを設定する

一部の Compute Engine リソースは、リージョン内やゾーン内に存在します。リージョンとは、リソースを実行できる特定の地理的位置です。1 つのリージョンには 1 つ以上のゾーンがあります。

リージョンとゾーンについてのドキュメントで、リージョンとゾーンの詳細と一覧をご確認ください。

次のコマンドを実行して、ラボのリージョンとゾーンを設定します（最適なリージョンとゾーンを使用できます）。

gcloud config set compute/region {{{ project_0.default_region | REGION }}} gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

アーキテクチャ

このラボでは、最初に Kubernetes Engine クラスタをデプロイします。その後、このクラスタに対し、前段にロードバランサを伴う簡単なウェブ アプリケーションをデプロイします。このウェブアプリは、ユーザーが指定したメッセージを Cloud Pub/Sub トピックに公開します。このアプリケーションは計測可能になっており、自らに対する HTTP リクエストが結果としてトレースの作成につながり、そのトレースのコンテキストが Cloud Pub/Sub パブリッシュ API リクエストに反映されます。こうしたリクエストから得られる相互に関連するテレメトリー データは、Cloud Trace コンソールで参照できます。

Terraform の概要

Terraform は、Infrastructure as Code と不変のインフラの原則に従い、インフラストラクチャの望ましい状態を宣言型で記述することをサポートします。記述子を適用すると、Terraform は Google Cloud APIs を使用して、一致するリソースのプロビジョニングと更新を行います。Terraform は望ましい状態と現在の状態を比較することにより、すべてを削除してやり直さなくても増分変更を行うことができます。たとえば、Terraform は Google Cloud プロジェクトやコンピュート インスタンスなどの作成、Kubernetes Engine クラスタの設定とそのクラスタへのアプリケーションのデプロイも行うことができます。要件が変わった場合は記述子を変更すると、Terraform はそれに応じてクラウド インフラストラクチャを調整します。

この例では、Terraform を使用して Kubernetes Engine クラスタを起動します。その後、Kubernetes コマンドを使用して、このクラスタにデモ アプリケーションをデプロイします。 デフォルトでは、Google Cloud 内の Kubernetes Engine クラスタは、事前に構成された Fluentd ベースのコレクタとともに起動します。このコレクタは、該当するクラスタのロギング イベントを Cloud Monitoring に転送します。このデモアプリを操作すると、Cloud Trace UI に表示されるトレース イベントが生成されます。

Terraform の実行

このデモには、3 つの Terraform ファイルが付属します。これらのファイルは、プロジェクトの /terraform サブディレクトリにあります。最初の main.tf ファイルは Terraform を使うための出発点です。このファイルは、使用される機能、操作されるリソース、結果として得られる出力を記述します。2 番目のファイルは provider.tf です。このファイルは、どのクラウド プロバイダおよびバージョンが Terraform コマンドのターゲットになるか（今回は Google Cloud）を示します。最後のファイル variables.tf には、Terraform への入力として使用される変数のリストが格納されています。main.tf で参照されている変数のうち、デフォルト設定が variables.tf で構成されていないものについては、実行時にプロンプトが表示されます。

タスク 1. 初期化

認証が前述のように構成されていた場合は、インフラストラクチャのデプロイを今すぐ開始できます。

• プロジェクトのルート ディレクトリから次のコマンドを実行します。

cd terraform

provider.tf ファイルを更新する

provider.tf スクリプト ファイルから Terraform のプロバイダ バージョンを削除します。

1. provider.tf スクリプト ファイルを編集します。

nano provider.tf

2. ファイルに以下のような google プロバイダの静的バージョン文字列がある場合は削除します。

.... provider "google" { project = var.project version = "~> 2.10.0" }

3. Ctrl+X > Y > Enter キーを押してファイルを保存します。

変更後の provider.tf スクリプト ファイルは次のようになります。

... provider "google" { project = var.project }

この場所から Terraform の初期化を行います。

4. 次のように入力します。

terraform init

すると、Terraform に必要な依存関係として、デモ アプリケーションのデプロイ先となる Google Cloud プロジェクトと Google Cloud ゾーンがダウンロードされます。Terraform 側でこれらの値が不明の場合は、その入力を求めるメッセージが表示されます。デフォルトでは、Terraform が terraform.tfvars というファイル、または接尾辞 .auto.tfvars の付いたファイルを現在のディレクトリ内で探して、これらの値を取得します。

このデモには、プロジェクトおよびゾーンの指定を促し、それらの値を terraform.tfvars ファイルに保存する、便利なスクリプトが用意されています。

5. 次のようにして実行します。

../scripts/generate-tfvars.sh 注: ファイルがすでに存在する場合は、エラーが表示されます。

このスクリプトは、gcloud コマンドから得られる事前に構成された値を使用します。そうした値が構成されていない場合は、その設定方法を示すエラー メッセージが表示されます。既存の値は、次のコマンドによって表示できます。

gcloud config list

6. 表示された値がデモ アプリケーションの実行用に想定している場所と一致しない場合は、terraform.tfvars ファイル内の値を適切な値に変更します。

タスク 2. デプロイ

1. Terraform の初期化が済んだら、Terraform が実行する処理を次のコマンドによって確認できます。

terraform plan

このコマンドを使用すると、設定が正しいことを視覚的に確認できます。エラーが検出された場合にはそれも確認できます。必須ではありませんが、Terraform を使用しているインフラストラクチャの変更前には、必ずこのコマンドを実行することをおすすめします。

2. 確認が済んだら、必要なインフラストラクチャを設定するように Terraform に指示します。

terraform apply

行われる変更の内容が表示され、yes による確認を求められます。

注: ゾーン変数に関連する非推奨の警告が表示された場合でも、無視してラボを進めてください。

ビルドの完了を待っている間に、このラボの後半で使用する Cloud Monitoring ワークスペースを設定します。

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。Terraform に必要なインフラストラクチャが正常にデプロイされていれば、評価スコアが表示されます。

Terraform を使用して必要なインフラストラクチャを設定する

Monitoring の指標スコープを作成する

Google Cloud プロジェクトに関連付けられた Monitoring の指標スコープを設定します。次の手順に沿って、Monitoring を無料でお試しいただける新しいアカウントを作成します。

• Cloud コンソールで、ナビゲーション メニュー（）> [すべてのプロダクトを表示] > [オブザーバビリティ] > [Monitoring] をクリックします。

Monitoring の [概要] ページが開いたら、指標スコープのプロジェクトの準備は完了です。

タスク 3. デモ アプリケーションをデプロイする

1. Cloud Shell に戻って「Apply complete!」というメッセージが表示されたら、コンソールに戻ります。

2. ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] の順に選択してクラスタを表示します。

3. ナビゲーション メニューをクリックし、[分析] セクションが表示されるまで下方向にスクロールし、[Pub/Sub] をクリックして [トピック] と [サブスクリプション] を確認します。

4. ここで、Kubernetes の kubectl コマンドを使用してデモ アプリケーションをデプロイします。

kubectl apply -f tracing-demo-deployment.yaml

デプロイしたアプリケーションは、[Kubernetes Engine] > [ワークロード] で確認できます。また、このアプリケーション用に作成されたロードバランサは、コンソールの [Services と Ingress] セクションで確認できます。

下の画像のように「Does not have minimum availability」というステータスが [ワークロード] コンソールに表示されると、アプリケーションがデプロイされるまでに数分かかる場合があります。

5. このような場合は、ステータスバーに「OK」が表示されるまでページを更新します。

ちなみに、次のコマンドを使用すると、エンドポイントをプログラムによって取得できます。

echo http://$(kubectl get svc tracing-demo -n default -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。デモ アプリケーションが正常にデプロイされている場合は、評価スコアが表示されます。

デモ アプリケーションをデプロイする

タスク 4. 検証

テレメトリー データの生成

デモ アプリケーションのデプロイが完了すると、公開サービスのリストが表示されるはずです。

1. 引き続き [Kubernetes Engine] ウィンドウで、[Services と Ingress] をクリックして公開サービスを表示します。

2. tracing-demo というロードバランサの横に表示されているエンドポイントをクリックすると、ブラウザの新しいタブでデモアプリのウェブページが開きます。

なお、実際に表示される IP アドレスは、おそらく上の例とは異なるものになります。表示されるページは、次のように単純なものです。

3. URL に ?string=CustomMessage という文字列を追加し、メッセージが表示されるようにします。

ご覧のように、string パラメータが指定されていない場合には、デフォルト値 Hello World が使用されます。このアプリは、トレース テレメトリー データの生成に使用されます。

4. 意味のあるデータを生成するには、「CustomMessage」の部分を独自のメッセージで置き換えます。

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。テレメトリー データが正常に生成されている場合は、評価スコアが表示されます。

テレメトリー データを生成する

トレースの調査

1. コンソールで、ナビゲーション メニュー > [トレース] > [Trace エクスプローラ] を選択します。縦軸の指標をレイテンシとしてタイムライン上にトレース イベントがプロットされたグラフが表示されるはずです。

2. [自動再読み込み] 切り替えボタンをクリックして、最新のデータを表示します。

注: 点をハイライト表示するとビューが展開されます。

3. グラフ上にある点のいずれかをクリックします。2 本のバーが並んだ棒グラフが表示されますが、上のバーのほうが下のバーよりも長くなっています。

上のバーは、ルートスパンと呼ばれ、HTTP リクエストの期間、すなわちリクエストの最初のバイトが到着してからレスポンスの最後のバイトが送信されるまでの時間を表します。下のバーは、メッセージを Pub/Sub トピックに送信する際に行われたリクエストの期間を表します。

HTTP リクエストの処理は Pub/Sub API の呼び出しによってブロックされるので、HTTP リクエストの期間内に費やされる時間のほとんどを Pub/Sub インタラクションが占めていることは明らかです。つまり、アプリケーションの各層を計測可能にすることで、ボトルネックがどこにあるかを容易に特定できます。

Pub/Sub メッセージの pull

このドキュメントの「アーキテクチャ」セクションで述べたように、デモアプリで生成されたメッセージは Pub/Sub トピックに公開されます。

こうしたメッセージは、gcloud CLI を使用してトピックから消費できます。

gcloud pubsub subscriptions pull --auto-ack --limit 10 tracing-demo-cli

出力:

DATA: Hello World MESSAGE_ID: 4117341758575424 ORDERING_KEY: ATTRIBUTES: DELIVERY_ATTEMPT: DATA: CustomMessage MESSAGE_ID: 4117243358956897 ORDERING_KEY: ATTRIBUTES: DELIVERY_ATTEMPT:

メッセージをトピックから pull しても、トレースにはまったく影響しません。ここでは、確認のためにメッセージの消費者を示しただけです。

モニタリングとロギング

Cloud によるモニタリングとロギングは今回のデモの範囲外ですが、デプロイしたアプリケーションが Cloud Logging にログを、Cloud Monitoring に指標をそれぞれ公開することは知っておくとよいでしょう。

1. コンソールで、ナビゲーション メニュー > [Monitoring] > [Metrics Explorer] を選択します。

2. [指標を選択してください] フィールドで [VM インスタンス] > [インスタンス] > [CPU 使用率] を選択し、[適用] をクリックします。

クラスタで実行中の各 Pod について、この指標をプロットしたグラフが表示されるはずです。

3. ログを表示するには、ナビゲーション メニュー > [ロギング] を選択します。

4. [ログのフィールド] セクションで、次のように設定します。

• RESOURCE TYPE: Kubernetes Container
• CLUSTER NAME: tracing-demo-space
• NAMESPACE NAME: default

タスク 5. 独自の環境でのトラブルシューティング

考えられるいくつかのエラーは kubectl コマンドを使用して診断できます。 たとえば、デプロイは次のようにして表示できます。

kubectl get deployment tracing-demo

出力:

NAME READY UP-TO-DATE AVAILABLE AGE tracing-demo 1/1 1 1 21m

describe を指定すると、より詳細な情報を表示できます。

kubectl describe deployment tracing-demo

次のコマンドは、デプロイ済み Pod のリストを表示します。

kubectl get pod

出力:

NAME READY STATUS RESTARTS AGE tracing-demo-59cc7988fc-h5w27 1/1 Running 0 23m

この場合も、describe によって Pod の詳細を確認できます。

kubectl describe pod tracing-demo

1. Pod 名を次のステップ用にメモします。

2. Pod 名がわかったら、その名前を使用してログをローカルで表示します。

kubectl logs <LOG_NAME>

出力:

10.60.0.1 - - [22/Jun/2018:19:42:23 +0000] "HEAD / HTTP/1.0" 200 - "-" "-" Publishing string: Hello World 10.60.0.1 - - [22/Jun/2018:19:42:23 +0000] "GET / HTTP/1.1" 200 669 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"

Terraform の実行中に、インストール スクリプトの実行が「アクセスが拒否されました」というエラーで失敗することがあります。 Terraform で使用している認証情報には、選択されているプロジェクトでリソースを作成するのに必要な権限がありません。gcloud config list で表示されるアカウントに、リソースの作成に必要な権限があることを確認してください。権限がある場合は、gcloud auth application-default login を実行してアプリケーションのデフォルト認証情報を生成し直してください。

タスク 6. 破棄

• このラボで使用したすべてのリソースは Qwiklabs によってシャットダウンされますが、次のクリーンアップ手順に従うことで、費用を抑えてクラウドにおけるマナーを保つことができます。

terraform destroy

apply の場合と同様、yes による確認を求めるメッセージが Terraform によって表示されます。

Terraform は作成したリソースのトラッキングを行っているので、クラスタ、Pub/Sub トピック、Pub/Sub サブスクリプションを破棄することができます。

注: ゾーン変数に関連する非推奨の警告が表示された場合でも、無視してください。

お疲れさまでした

次のステップと詳細情報

以下に、さらに詳しく調査するための関連資料を示します。

Kubernetes

Kubernetes とは、マイクロサービス アーキテクチャでよく使用されるコンテナ オーケストレーション プラットフォームです。Google Cloud には、Kubernetes Engine というマネージド バージョンの Kubernetes が用意されています。

OpenCensus

OpenCensus は、トレース テレメトリー データのキャプチャおよび公開のための標準化されたライブラリを提供しています。ライブラリは使用頻度の高い複数の言語で提供され、Cloud Monitoring や Zipkin など、多数のトレース プラットフォームがサポートされています。このドキュメントで説明したデモは、OpenCensus を使用してテレメトリー データを Cloud Monitoring に公開しています。

Spring Sleuth

Spring Sleuth は、広く普及している Spring フレームワークを使用した Java アプリケーションの計測手法を提供します。Spring Sleuth は分散トレース テレメトリー コレクタに対する抽象化をサポートしているので、デベロッパーは Zipkin や Cloud Monitoring、その他のトレース エンジンの切り替えをシームレスに行うことができます。

Cloud のモニタリング

Operations は、ロギング、モニタリング、トレース、関連機能を提供する Google Cloud のツールスイートです。このドキュメントとデモでは、Cloud が提供する Cloud Trace 機能に重点が置かれています。

Terraform

Terraform は宣言型の Infrastructure as Code ツールであり、構成ファイルを使って、クラウドでインフラストラクチャを自動的にデプロイして進化させます。

Zipkin

Zipkin は分散トレースの普及に貢献した分散トレースツールです。

すでに Zipkin 向けに計測可能になっているアプリケーションでは、Zipkin コレクタを使用して Zipkin テレメトリー データを Cloud Monitoring イベントに適合させることができます。Zipkin コレクタは、次のようにして Kubernetes Engine にデプロイできます。

kubectl run stackdriver-zipkin --image=gcr.io/stackdriver-trace-docker/zipkin-collector --expose --port=9411

このコマンドは、よく知られている Zipkin ポート 9411 にコレクタをデプロイします。ローカルポート上でこのコレクタを探しているアプリケーションは、コレクタと Zipkin サーバーを区別できませんが、テレメトリー データは Cloud Trace に表示されます。

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボのプラットフォームから、アカウントと使用したリソースが削除されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

マニュアルの最終更新日: 2023 年 9 月 28 日

ラボの最終テスト日: 2023 年 9 月 28 日

Copyright 2024 Google LLC. 本ソフトウェアは「現状有姿」で提供されており、いかなる使用および目的に関しても保証および表明は伴いません。本ソフトウェアのご利用には、Google との契約が適用されます。