GSP736

概要

Cloud Logging とそれに付随するツールの Cloud Monitoring は、双方とも Google Kubernetes Engine に密接に統合されたフル機能のプロダクトです。このラボでは、Cloud Logging が GKE クラスタとアプリケーションでどのように動作するかを学習します。また、一般的なロギングのユースケースを通じて、ログ収集のベスト プラクティスも学習します。

目標

このラボでは、次の方法について学びます。

• Cloud Monitoring を使用して問題を検出する
• Cloud Logging を使用して、GKE で動作しているアプリケーションの問題を解決する

ラボで使用されているデモ アプリケーション

具体例を示すために、GKE クラスタにデプロイされているサンプルのマイクロサービス デモアプリのトラブルシューティングを行います。このデモアプリには、さまざまなマイクロサービスと、その依存関係が含まれています。負荷生成ツールを使用してトラフィックを生成してから、Logging、Monitoring、GKE を使用してエラー（アラート / 指標）を表示し、Logging で根本原因を突き止め、Logging と Monitoring で問題の修正と修正確認を行います。

設定と要件

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

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

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

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

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

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

• ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

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

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

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

2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

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

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

3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

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

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

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

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

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

注: 左上にある [ナビゲーション メニュー] をクリックすると、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 の概要ガイドをご覧ください。

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

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

Cloud コンソールで次の gcloud コマンドを実行して、ラボのデフォルトのリージョンとゾーンを設定します。

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

タスク 1. インフラストラクチャ設定

Google Kubernetes Engine クラスタに接続し、そのクラスタが正しく作成されていることを確認します。

1. プロジェクト ID の変数を設定します。

export PROJECT_ID={{{project_0.startup_script.project | Project ID}}}

2. 次のコマンドを使用して、クラスタのステータスを表示します。

gcloud container clusters list

クラスタのステータスが「PROVISIONING」である場合は、

3. 少し待ってから、ステータスが「RUNNING」になるまで上記のコマンドを再度実行します。これには数分かかることがあります。

4. central という名前のクラスタが作成されていることを確認します。

ナビゲーション メニュー > [Kubernetes Engine] > [クラスタ] に移動して、Google Cloud Console で進行状況をモニタリングすることもできます。

5. クラスタのステータスが「RUNNING」になったら、クラスタの認証情報を取得します。

gcloud container clusters get-credentials central --zone $ZONE

出力:

Fetching cluster endpoint and auth data. kubeconfig entry generated for central.

7. ノードが作成されていることを確認します。

kubectl get nodes

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

NAME STATUS ROLES AGE VERSION gke-central-default-pool-5ff4130f-qz8v Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-ssd2 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-tz63 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-zfmn Ready 24d v1.27.2-gke.1200

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

次に、Hipster Shop というマイクロサービス アプリケーションをクラスタにデプロイし、モニタリング可能なワークロードを作成します。

1. 次のコマンドを実行してリポジトリのクローンを作成します。

git clone https://github.com/xiangshen-dk/microservices-demo.git

2. microservices-demo ディレクトリに移動します。

cd microservices-demo

3. kubectl を使用してアプリをインストールします。

kubectl apply -f release/kubernetes-manifests.yaml

4. すべてが正しく動作していることを確認します。

kubectl get pods

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

NAME READY STATUS RESTARTS AGE adservice-55f94cfd9c-4lvml 1/1 Running 0 20m cartservice-6f4946f9b8-6wtff 1/1 Running 2 20m checkoutservice-5688779d8c-l6crl 1/1 Running 0 20m currencyservice-665d6f4569-b4sbm 1/1 Running 0 20m emailservice-684c89bcb8-h48sq 1/1 Running 0 20m frontend-67c8475b7d-vktsn 1/1 Running 0 20m loadgenerator-6d646566db-p422w 1/1 Running 0 20m paymentservice-858d89d64c-hmpkg 1/1 Running 0 20m productcatalogservice-bcd85cb5-d6xp4 1/1 Running 0 20m recommendationservice-685d7d6cd9-pxd9g 1/1 Running 0 20m redis-cart-9b864d47f-c9xc6 1/1 Running 0 20m shippingservice-5948f9fb5c-vndcp 1/1 Running 0 20m

5. 次のステップに進む前に、すべての Pod が「Running」のステータスになるまでコマンドを再実行してください。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 アプリケーションをデプロイする

6. 次を実行して、アプリケーションの外部 IP を取得します。このコマンドは、サービスがデプロイされると IP アドレスを返します。そのため、外部 IP アドレスが割り当てられるまでこのコマンドを繰り返さなくてはならない場合があります。

export EXTERNAL_IP=$(kubectl get service frontend-external | awk 'BEGIN { cnt=0; } { cnt+=1; if (cnt > 1) print $4; }')

7. 最後に、アプリが起動して稼働していることを確認します。

curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP

確認結果は次のようになります。

200

アプリケーションがデプロイされたら、Google Cloud Console に移動してステータスを表示することもできます。

[Kubernetes Engine] > [ワークロード] ページに、すべての Pod に問題がないことが表示されます。

8. 次に [Services と Ingress] をクリックして、すべてのサービスに問題がないことを確認します。この画面のままで、アプリケーションのモニタリングを設定します。

タスク 3. アプリケーションを開く

1. frontend-external まで下にスクロールして、サービスのエンドポイント IP をクリックします。

アプリケーションが開いて、次のようなページが表示されます。

タスク 4. ログベースの指標を作成する

次に、Cloud Logging を構成してログベースの指標を作成します。これは、ログエントリから作成された Cloud Monitoring のカスタム指標です。ログベースの指標は、ログエントリ数のカウントと、ログ内の値分布の追跡に便利です。この場合、ログベースの指標を使用して、フロントエンド サービス内のエラーの数をカウントします。これで、ダッシュボードとアラートの両方で指標を使用できます。

1. Cloud コンソールに戻り、ナビゲーション メニュー で [ロギング] を開いて [ログ エクスプローラ] をクリックします。

2. [クエリを表示] をオンにして、[クエリビルダー] ボックスに次のクエリを追加します。

resource.type="k8s_container" severity=ERROR labels."k8s-pod/app": "recommendationservice"

3. [クエリを実行] をクリックします。

このクエリは、フロントエンド Pod からすべてのエラーを見つけられます。ただし、エラーがまだないため、この時点では結果が表示されません。

4. ログベースの指標を作成するために、[指標の作成] をクリックします。

5. 指標に「Error_Rate_SLI」という名前を付け、[指標を作成] をクリックしてログベースの指標を保存します。

作成した指標が、[ログベースの指標] ページのユーザー定義の指標の下に表示されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ログベースの指標を作成する

タスク 5. アラート ポリシーを作成する

アラートによって、クラウド アプリケーションの問題をタイムリーに認識し、問題をすばやく解決できます。次に Cloud Monitoring を使用し、先ほど作成したフロントエンド エラーのログベースの指標に基づきアラート ポリシーを作成して、フロントエンド サービスの可用性をモニタリングします。アラート ポリシーの条件が満たされると、Cloud Monitoring によりインシデントが作成されて Google Cloud コンソールに表示されます。

1. ナビゲーション メニュー で [Monitoring] を開いてから [アラート] をクリックします。

2. ワークスペースが作成されたら、上部の [CREATE POLICY] をクリックします。

注: 必要に応じて [試してみる] をクリックして最新のアラート作成フローをお試しください。

3. [指標を選択] プルダウンをクリックします。[Show only active resources & metrics] を無効にします。

4. リソースと指標名のフィルタ フィールドに「Error_Rate」と入力します。

5. [Kubernetes Container] > [Logs Based Metric] とクリックします。[logging/user/Error_Rate_SLI] を選択して [適用] をクリックします。

画面は次のようになります。

6. ローリング ウィンドウ関数を Rate に設定します。

7. [Next] をクリックします。

8. 0.5 をしきい値に設定します。

期待どおりエラーはなく、アプリケーションは可用性のサービスレベル目標（SLO）を達成しています。

9. もう一度 [NEXT] をクリックします。

10. [通知チャンネルを使用] をオフにします。

11. Error Rate SLI などのアラート名を入力してから、[NEXT] をクリックします。

12. アラートを確認して [ポリシーを作成] をクリックします。

注: このラボでは通知チャンネルを作成しませんが、本番環境で稼働しているアプリケーションでは作成することをおすすめします。これにより、メール、モバイルアプリ、SMS、Pub/Sub、Webhook などで通知が送信されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 アラート ポリシーを作成する

アプリケーション エラーをトリガーする

次に、負荷生成ツールを使用して、ウェブ アプリケーションにトラフィックを生成します。このバージョンのアプリケーションにはバグが意図的に導入されているため、特定量のトラフィック量でエラーがトリガーされます。各ステップを実行して、バグを特定して修正します。

1. ナビゲーション メニュー から [Kubernetes Engine]、次に [Service と Ingress] を選択します。

2. loadgenerator-external サービスを探して endpoints リンクをクリックします。

または、新しいブラウザタブまたはウィンドウを開き、IP をコピーして URL フィールド（例: http://\[loadgenerator-external-ip\]）に貼り付けることもできます。

Locust 負荷生成ツールページが表示されます。

Locust はオープンソースの負荷生成ツールで、ウェブアプリの負荷テストを行うことができます。これは複数のユーザーが同時にアプリケーションのエンドポイントを特定の割合でアクセスするのをシミュレートできます。

1. 300 人のユーザーが 30 の生成率でアプリにアクセスするのをシミュレートします。Locust は、ユーザーが 300 人になるまで 1 秒あたり 30 人のユーザーを追加します。

2. ホスト フィールドには、frontend-external を使用します。[Services と Ingress] ページから URL をコピーします。その際、ポートを必ず除いてください。次に例を示します。

3. [Start swarming] ボタンをクリックします。数秒で約 300 ユーザーが事前定義した URL をヒットします。

4. [Failures] タブをクリックしてエラーが生じていることを確認します。HTTP 500 エラーが多数表示されます。

一方、ホームページからプロダクトをクリックすると、目に見えて遅いか、次のようなエラーが送信されます。

アラートとアプリケーション エラーの確認

1. Cloud コンソール の [ナビゲーション メニュー] で [Monitoring]、次に [アラート] をクリックします。logging/user/Error_Rate_SLI に関するインシデントがすぐに表示されます。インシデントがすぐに表示されない場合は、1～2 分待ってからページを更新してください。アラート発出まで最大 5 分かかる場合があります。

2. インシデントのリンクをクリックします。

詳細ページが表示されます。

3. [ログを表示] リンクをクリックして Pod のログを表示します。

4. [ログ フィールド エクスプローラ] パネルで [エラー] ラベルをクリックして、エラーのみのクエリを行うこともできます。

または、クエリのプレビュー フィールドをクリックしてクエリビルダーを表示し、[重大度] プルダウンをクリックして [エラー] をクエリに追加できます。[追加] ボタンをクリックしてから [クエリを実行] をクリックします。プルダウン メニューでは複数の重大度値を追加できます。

いずれも、severity=ERROR がクエリに追加されます。この場合、recommendationservice Pod のすべてのエラーが表示されます。

5. エラーイベントを開いてエラーの詳細を表示します。次に例を示します。

6. textPayload を開きます。

7. エラー メッセージをクリックし、[概要行にフィールドを追加] を選択してエラー メッセージが概要フィールドとして表示されるようにします。

ここで、RecommendationService サービスにエラーが多数あることを確認できます。エラー メッセージに基づくと、RecommendationService が一部のダウンストリーム サービスに接続できず、プロダクトまたは推奨事項のいずれかを取得できなかったようです。ただし、エラーの根本原因はまだはっきりしません。

アーキテクチャ図を再確認すると、RecommendationService がフロントエンド サービスに推奨事項のリストを提供します。一方で、フロントエンド サービスと RecommendationService の両方とも、プロダクトを一覧するために ProductCatalogService を呼び出します。

次のステップでは、犯人と思しき ProductCatalogService の指標に異常値がないかを確認します。ログで詳細を確認して分析情報を取得できます。

Kubernetes ダッシュボードとログを使用したトラブルシューティング

1. 最初に指標を確認する場所の一つは、Monitoring コンソールの Kubernetes Engine セクション（[ナビゲーション メニュー] > [Monitoring] > [ダッシュボード] > [GKE]）です。

2. [ワークロード] セクションを表示します。

3. [Kubernetes Engine] > [ワークロード] > [productcatalogservice] に移動します。サービスの Pod が継続的にクラッシュして再起動していることが確認できます。

次に、ログに何か気になるものがないか確認します。

コンテナログを簡単に取得する方法は 2 つあります。

1. [ログ] タブをクリックして最新のログを見ます。次に、ログパネルの右上端にある外部リンクボタンをクリックして、ログ エクスプローラに戻ります。

2. [概要] ページで、[Deployment の詳細] ページの [Container logs] リンクをクリックします。

[ログ エクスプローラ] ページに戻ります。GKE で表示したコンテナのログに対して特にフィルタリングされた事前定義済みクエリがここに表示されます。

ログビューアでは、ログ メッセージとヒストグラムにより、コンテナが短時間でプロダクトのカタログを繰り返しパースしていることが示されます。これは非常に非効率だと思われます。

クエリ結果の最後に、次のようなランタイム エラーがある可能性があります。

panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation

これが実際に Pod をクラッシュさせている可能性があります。

理由をもっとよく把握するために、コードでログ メッセージを検索します。

1. Cloud Shell で、次のコマンドを実行します。

grep -nri 'successfully parsed product catalog json' src

出力は次のようになります。これには、行番号の付いたソースファイル名があります。

src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")

2. ソースファイルを表示するには、Cloud Shell のメニューで [エディタを開く] ボタン、次に [新しいウィンドウで開く] をクリックします（「サードパーティの Cookie が無効になっているため、コードエディタを読み込めません」というエラーが表示されたら、Chrome ページの上部にある目のアイコンをクリックします）。

3. microservices-demo/src/productcatalogservice/server.go のファイルをクリックして、237 行までスクロールすると、readCatalogFile メソッドがこのメッセージを出力するのがわかります。

コードを参照すると、ブール型変数の reloadCatalog が真の場合、サービスが呼び出されるたびに不必要にプロダクト カタログを再読み込みしてパースしていることがわかります。

コードで reloadCatalog 変数を検索すると、これは環境変数 ENABLE_RELOAD によって制御されており、状態に関するログ メッセージを書き込んでいることが確認できます。

このメッセージをクエリに追加してログを再度確認し、エントリがないか判断します。

1. ログ エクスプローラを開いたタブに戻り、次の行をクエリに追加します。

jsonPayload.message:"catalog reloading"

そして、クエリビルダーの全クエリは次のようになります。

resource.type="k8s_container" resource.labels.location="{{{project_0.startup_script.zone | ZONE}}}" resource.labels.cluster_name="central" resource.labels.namespace_name="default" labels.k8s-pod/app="productcatalogservice" jsonPayload.message:"catalog reloading"

2. [クエリを実行] を再度クリックして、コンテナログで「Enable catalog reloading」というメッセージを探します。これにより、カタログの再読み込み機能が有効になっていることを確認できます。

この時点で、フロントエンド エラーは、すべてのリクエストに対してカタログを読み込むオーバーヘッドによって引き起こされていたことが確認できます。読み込みを増やすと、オーバーヘッドによりサービスが失敗をしてエラーが生じます。

タスク 6. 問題を修正して結果を確認する

コードとログに記載されていることに基づき、カタログの再読み込みを無効にして問題を修正できます。ここで、プロダクト カタログ サービスの ENABLE_RELOAD 環境変数を削除します。変数を変更したら、アプリケーションを再度デプロイして、見つかった問題が変更によって解消されたことを確認します。

1. [ターミナルを開く] ボタンをクリックして、Cloud Shell ターミナルに戻ります（閉じていた場合）。

2. 次のコマンドを実行します。

grep -A1 -ni ENABLE_RELOAD release/kubernetes-manifests.yaml

出力には、マニフェスト ファイルの環境変数の行番号が示されます。

373: - name: ENABLE_RELOAD 374- value: "1"

3. 以下を実行してこの 2 行を削除し、再読み込みを無効にします。

sed -i -e '373,374d' release/kubernetes-manifests.yaml

4. 次に、マニフェスト ファイルを再度適用します。

kubectl apply -f release/kubernetes-manifests.yaml

productcatalogservice のみが構成されていることがわかります。他のサービスは変更されていません。

5. Deployment の詳細ページに戻り（ナビゲーション メニュー > [Kubernetes Engine] > [ワークロード] > [productcatalogservice]）、Pod が正常に動作するまで待ちます。2～3 分待つか、またはクラッシュしなくなったことが確認できるまで待ちます。

6. もう一度 [Container logs] リンクをクリックすると、繰り返し表示されていた successfully parsing the catalog json メッセージが消えていることを確認できます。

7. ウェブアプリ URL に戻ってホームページのプロダクトをクリックすると、応答性もずっと良くなっており、HTTP エラーも表示されないはずです。

8. 負荷生成ツールに戻り、右上の [Reset Stats] ボタンをクリックします。失敗の割合がリセットされて上昇していないことを確認できます。

上記すべてのチェックは、問題が修正されたことを示します。HTTP 500 エラーがまだ表示される場合、あと数分待ってからプロダクトを再度クリックしてみてください。

お疲れさまでした

Cloud Logging と Cloud Monitoring を使用して、意図的に誤った構成をしたマイクロサービス デモアプリでエラーを見つけました。これは、本番環境で GKE アプリの問題を絞り込むときに使用するトラブルシューティングのプロセスと同様です。

最初に GKE にアプリをデプロイしてから、フロントエンド エラーの指標とアラートを設定しました。次に、負荷を生成して、アラートがトリガーされたことを確認しました。アラートに基づき、Cloud Logging を使用して問題を特定のサービスに絞りました。そして、Cloud Monitoring と GKE UI を使用して GKE サービスの指標を検証しました。問題を修正するため、更新済みの構成を GKE にデプロイして、修正によってログのエラーが解消されたことを確認しました。

クエストを完了する

このセルフペース ラボは、Qwiklabs の「Google Cloud's Operations Suite on GKE」クエストの一部です。クエストとは学習プログラムを構成する一連のラボのことで、完了すると成果が認められてバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。このラボの修了後、次のクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能な全クエストについては、Google Cloud Skills Boost カタログをご覧ください。

次のラボを受講する

「Kubernetes Engine での Cloud Logging」に進んでクエストを続けるか、以下のおすすめのラボをご確認ください。

• Cloud Operations for GKE
• Cloud Monitoring APM によるサイトの信頼性のトラブルシューティング

次のステップと詳細情報

• このラボは、GKE で動作しているアプリに対する Logging の使用に関するこちらのブログ投稿をベースにしています。
• DevOps チームが Cloud Monitoring および Logging を使用して問題をすばやく見つける方法に関するフォローアップ投稿も、よろしければご覧ください。

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2023 年 7 月 31 日

ラボの最終テスト日: 2023 年 7 月 31 日

Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。