arrow_back

Kubernetes Engine で Cloud Trace の使用

参加 ログイン

Kubernetes Engine で Cloud Trace の使用

1時間 クレジット: 5

GSP484

Google Cloud セルフペース ラボ

概要

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 を実行します。このアセットへのコントリビューターをお待ちしています。

アーキテクチャ

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

architecture.png

設定

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

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

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

必要なもの

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

  • 標準的なインターネット ブラウザ(Chrome を推奨)
  • ラボを完了するために十分な時間

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、ラボでは使用しないでください。

注: Chrome OS デバイスを使用している場合は、シークレット ウィンドウを開いてこのラボを実行してください。

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

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

    • [Google コンソールを開く] ボタン
    • 残り時間
    • このラボで使用する必要がある一時的な認証情報
    • このラボを行うために必要なその他の情報(ある場合)
  2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

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

    注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。
  3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

  4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

    重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。
  5. その後次のように進みます。

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

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。 ナビゲーション メニュー アイコン

Google Cloud Shell の有効化

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

GCP Console の右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

Cloud Shell アイコン

[続行] をクリックします。

cloudshell_continue

環境のプロビジョニングと接続には少し時間がかかります。接続すると、すでに認証されており、プロジェクトは PROJECT_ID に設定されています。例えば:

Cloud Shell 端末

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

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

gcloud auth list

出力:

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

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

gcloud config list project
	

出力:

[core]
project = <project_ID>
	

出力例:

[core]
project = qwiklabs-gcp-44776a13dea667a6
	

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

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

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

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

cd gke-tracing-demo

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

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

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

gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

Terraform の概要

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

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

Terraform の実行

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

初期化

上の認証を設定して、インフラストラクチャをデプロイすることができます。

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

cd terraform

provider.tf ファイルを更新します。

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

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

nano provider.tf

以下のように、google プロバイダのファイルで version を指定する文字列がある場合は、そのファイルを削除してください。

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

CTRL + X > Y > Enter でファイルを保存します。

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

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

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

そのためには、次のように入力します。

terraform init

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

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

../scripts/generate-tfvars.sh

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

gcloud config list

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

デプロイメント

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

terraform plan

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

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

terraform apply

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

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

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

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

Terraform を使用して必要なインフラストラクチャをセットアップする

Monitoring ワークスペースを作成する

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

  1. Cloud Console で、ナビゲーション メニュー > [Monitoring] をクリックします。

  2. Monitoring Overview ページが開いたら、メトリック スコープ プロジェクトの準備は完了です。

Overview.pngMonitoringWindow.png

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

Cloud Shell に戻って「Apply complete!」 というメッセージが表示されたら、コンソールに戻ります。ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] の順に選択してクラスタを表示します。

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

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

kubectl apply -f tracing-demo-deployment.yaml

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

アプリケーションがデプロイされるまでに数分かかる場合があります。もし、ワークロード コンソールが「Does not have minimum availability.」のステータスで次のようになっている場合には

minimum-availability.png

ステータスバーに 「OK」が表示されるまでページを更新します。

workload-running.png

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

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

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

[進行状況を確認] をクリックしてタスクを完了したことを確認します。 デモ アプリケーションを正常にデプロイすると、スコアが表示されます。

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

有効化

テレメトリ データの生成

デモ アプリケーションのデプロイが完了すると、公開サービスのリストが表示されるはずです。引き続き Kubernetes ウィンドウで、[Services と Ingress] をクリックして、公開されているサービスが表示されます。

services-ui.png

tracing-demo というロードバランサの横に表示されている エンドポイント をクリックすると、ブラウザの新しいタブでデモアプリのウェブページが開きます。なお、実際に表示される IP アドレスは、おそらく上の例とは異なるものになります。表示されるページは、次のように単純なものです。

hello-world-browser.png

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

custom-message-browser.png

ご覧のように、string パラメータが指定されていない場合には、デフォルト値 Hello World が使用されます。このアプリは、トレース テレメトリ データの生成に使用されます。意味のあるデータを生成するには、「CustomMessage」の部分を独自のメッセージで置き換えます。

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

[進行状況を確認] をクリックしてタスクを完了したことを確認します。テレメトリ データを正常に作成すると、スコアが表示されます。

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

トレースの調査

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

[自動リロード]切り替えボタンをスライドして、最新のデータを表示します。

trace-ui.png

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

span-ui-full.png

上のバーは、ルートスパンと呼ばれ、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 モニタリング に指標をそれぞれ公開することには触れておきます。

Console でナビゲーション メニュー > モニタリング > Metrics Explorer を選択します。

[メトリックの選択] フィールドで、[VM インスタンス] > [インスタンス] > [CPU 使用率] を選択し、[適用] をクリックします。

metric-select.jpg

クラスタで実行されているさまざまなポッドについて、このメトリックのグラフが表示されます。

ログを表示するため、ナビゲーション メニュー > Logging を選択します。

ログのフィールド セクションで、以下のように指定します。

  • RESOURCE TYPE: Kubernetes Container
  • クラスタ名: tracing-demo-space
  • 名前空間名: default

logs-fields-results.jpg

独自の環境でのトラブルシューティング

考えられるいくつかのエラーは 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

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

kubectl get pod

(出力)

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

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

kubectl describe pod tracing-demo

次のステップで使用できるように 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 を実行してアプリケーションのデフォルトの認証情報を生成し直してください。

破棄

このラボで使用したすべてのリソースのシャットダウンは Qwiklabs によって行われますが、クラウドのマナーを守りながら費用を節約するために、独自の環境のクリーンアップに必要な操作を以下に示します。

terraform destroy

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

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

お疲れさまでした

CloudOpsGKE_125x135.png

クエストを完了する

このセルフペース ラボは、Qwiklabs のクエストである Google Cloud's Operations Suite on GKEの一部です。クエストとは、学習パスを構成する一連のラボで、クエストを完了すると、成果が認められて上のバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクさせることができます。このラボを終えてこちらのクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能なその他の Qwiklabs のクエストもご覧ください

次のラボを受講する

Kubernetes Engine でのロールベース アクセス制御の使用に関するクエストを続けるか、以下のおすすめのラボをご確認ください。

次のステップと詳細情報

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

Kubernetes

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

OpenCensus

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

Spring Sleuth

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

Cloud モニタリング

Operations は、ロギングとモニタリング、関連する機能を提供する Google Cloud のツールスイートです。このドキュメントとデモは、Cloud モニタリング が提供する Cloud Trace 機能に特に関連したものです。

Terraform

Terraform は、宣言型の Infrastructure as Code ツールであり、構成ファイルを使用して、クラウド内でのインフラストラクチャのデプロイと進化を自動化することができます。

Zipkin

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

すでに Zipkin 向けに設定されているアプリケーションでは、Zipkin コレクタを使用して Zipkin テレメトリ データを Cloud モニタリング イベントに適合させることができます。Zipkin コレクタは、次のようにして Kubernetes Engine にデプロイできます。

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

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

ラボを終了する

ラボでの学習が完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Qwiklabs から削除され、アカウントの情報も消去されます。

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

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

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

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

フィードバック、ご提案、修正事項がございましたら、[サポート] タブからお知らせください。

マニュアルの最終更新日:2022 年 3 月 21 日
ラボの最終テスト日: 2022 年 3 月 21 日

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