arrow_back

Kubernetes Engine によるデプロイの管理

参加 ログイン

Kubernetes Engine によるデプロイの管理

1時間 クレジット: 5

GSP053

Google Cloud セルフペース ラボ

概要

DevOps のプラクティスでは、「継続的デプロイ」、「Blue / Green デプロイ」、「カナリア デプロイ」といったアプリケーション デプロイのシナリオを管理するために、複数のデプロイが定期的に利用されます。こうした複数の異種混合デプロイが使用される一般的なシナリオに対応できるように、このラボではコンテナのスケーリングと管理の演習を行います。

演習内容

  • kubectl ツールを使用する
  • デプロイの yaml ファイルを作成する
  • デプロイをリリース、更新、スケーリングする
  • デプロイとデプロイ スタイルを更新する

前提条件

  • このラボを受講する前に、少なくとも Docker の概要ラボと Hello Node Kubernetes ラボを受講しておく
  • Linux システムの管理スキル
  • DevOps 理論: 継続的デプロイの概念

デプロイの概要

異種混合デプロイでは通常、特定の技術的ニーズや運用上のニーズに対応するため、2 つ以上の異なるインフラストラクチャ環境またはリージョンを接続します。異種混合デプロイは、デプロイの仕様に応じて「ハイブリッド」、「マルチクラウド」、「パブリック-プライベート」と呼ばれます。このラボでは、単一のクラウド環境、複数のパブリック クラウド環境(マルチクラウド)、またはオンプレミス環境とパブリック クラウド環境の組み合わせ(ハイブリッドまたはパブリック-プライベート)において、複数のリージョンにまたがる異種混合デプロイを扱います。

単一の環境またはリージョンに限定されたデプロイでは、ビジネス上や技術上のさまざまな課題が発生する可能性があります。

  • リソースの上限: 単一の環境、特にオンプレミス環境では、本番環境のニーズを満たすコンピューティング リソース、ネットワーキング リソース、ストレージ リソースを確保できない場合があります。
  • 地理的範囲の制限: 単一環境のデプロイでは、地理的に離れた場所にいるユーザーが互いに 1 つのデプロイにアクセスする必要があります。つまり、ユーザーのトラフィックは、中心となる場所に到達するまでに世界中を移動する可能性があります。
  • 限られた可用性: ウェブ規模のトラフィック パターンを処理するアプリケーションは、フォールト トレランスと復元力を維持する必要があります。
  • ベンダー ロックイン: プラットフォームとインフラストラクチャがベンダーレベルで抽象化されるため、アプリケーションの移植が妨げられる場合があります。
  • 柔軟性の低いリソース: リソースが特定のコンピューティング、ストレージ、ネットワーキング サービスに限定される場合があります。

異種混合デプロイは、これらの課題に対処するのに役立ちますが、プログラマティックで確定的なプロセスと手順を使用して設計する必要があります。一度限りまたはその場しのぎのデプロイ手順では、デプロイやプロセスが脆弱になり、障害に耐えられない可能性があります。また、その場しのぎのプロセスはデータの消失やトラフィックのドロップを招く場合があります。優れたデプロイ プロセスは再現可能でなければならず、プロビジョニング、構成、メンテナンスの管理には、実績のあるアプローチが使用される必要があります。

異種混合デプロイの一般的なシナリオは、マルチクラウド デプロイ、オンプレミス データの外部接続、継続的インテグレーション / 継続的デリバリー(CI / CD)プロセスの 3 つです。

次の演習では、Kubernetes とその他のインフラストラクチャ リソースを使用して適切に設計されたアプローチとともに、異種混合デプロイの一般的な使用事例を実践します。

設定

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

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、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
	

ゾーンを設定する

ローカルゾーンとして us-central1-a を指定して次のコマンドを実行し、使用する GCP ゾーンを設定します。

gcloud config set compute/zone us-central1-a

このラボのサンプルコードを入手する

コンテナとデプロイを作成して実行するためのサンプルコードを入手します。

gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes .
cd orchestrate-with-kubernetes/kubernetes

5 つの n1-standard-1 ノードを含むクラスタを作成します(完了するまでに数分かかります)。

gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

Deployment オブジェクトの詳細

Deployment を使ってみましょう。まずは Deployment オブジェクトについて確認します。kubectlexplain コマンドを使用すると、Deployment オブジェクトに関する情報が表示されます。

kubectl explain deployment

--recursive オプションを使用してすべてのフィールドを確認することもできます。

kubectl explain deployment --recursive

ラボを進めながら explain コマンドを使用すると、Deployment オブジェクトの構造や、各フィールドの機能を理解するのに役立ちます。

kubectl explain deployment.metadata.name

Deployment の作成

deployments/auth.yaml 構成ファイルを更新します。

vi deployments/auth.yaml

エディタを起動します。

i

Deployment の containers セクションにある image を次のように変更します。

…
containers:
- name: auth
  image: kelseyhightower/auth:1.0.0
...

auth.yaml ファイルを保存します(Esc キーを押してから、次のように入力します)。

:wq

次に、簡単なデプロイを作成してみましょう。デプロイ構成ファイルを確認します。

cat deployments/auth.yaml

(出力)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth
spec:
  replicas: 1
  selector:
    matchLabels:
      app: auth
  template:
    metadata:
      labels:
        app: auth
        track: stable
    spec:
      containers:
        - name: auth
          image: "kelseyhightower/auth:1.0.0"
          ports:
            - name: http
              containerPort: 80
            - name: health
              containerPort: 81
...

Deployment でレプリカが 1 つ作成され、バージョン 1.0.0 の auth コンテナが使用されているのがわかります。

auth デプロイを作成するために kubectl create コマンドを実行すると、Deployment マニフェスト内のデータに準拠するポッドが 1 つ作成されます。つまり、replicas フィールドで指定された数字を変更することで、ポッドの数を増減できます。

では、kubectl create を使用して Deployment オブジェクトを作成しましょう。

kubectl create -f deployments/auth.yaml

Deployment が実際に作成されていることを確認します。

kubectl get deployments

Deployment が作成されると、Kubernetes はその ReplicaSet を作成します。次のように入力すると、Deployment の ReplicaSet が作成されたことを確認できます。

kubectl get replicasets

auth-xxxxxxx のような名前の ReplicaSet が表示されます。

最後に、Deployment の一部として作成されたポッドを確認します。ReplicaSet が作成されると、Kubernetes によってポッドが 1 つ作成されます。

kubectl get pods

次に、auth デプロイ用のサービスを作成します。サービス マニフェスト ファイルについてはすでにご存知のはずですから、ここでは説明しません。kubectl create コマンドを使用して auth サービスを作成します。

kubectl create -f services/auth.yaml

次に、同じ手順で hello Deployment を作成して公開します。

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

さらに、同じ手順でフロントエンド Deployment を作成して公開します。

kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

注: フロントエンドの ConfigMap が作成されました。

フロントエンドの外部 IP を取得して curl を実行し、フロントエンドを操作します。

kubectl get services frontend

サービスの外部 IP フィールドに入力されるまでに数秒かかる場合があります。これは正常です。フィールドにデータが入力されるまで、上記のコマンドを数秒ごとに再実行するだけです。

curl -ks https://<EXTERNAL-IP>

hello レスポンスが返されます。

kubectl の出力テンプレート機能を使用して、curl を 1 行で実行することもできます。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

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

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。Kubernetes クラスタに加え、Auth、Hello、フロントエンド Deployment が正常に作成されている場合は、評価スコアが表示されます。

Kubernetes クラスタと Deployment(Auth、Hello、フロントエンド)を作成する

Deployment をスケールする

作成した Deployment をスケーリングするには、spec.replicas フィールドを更新します。kubectl explain コマンドをもう一度使用して、このフィールドの説明を確認してください。

kubectl explain deployment.spec.replicas

replicas フィールドは、kubectl scale コマンドを使って簡単に更新できます。

kubectl scale deployment hello --replicas=5

注: 新しいポッドがすべて起動するまでに数分かかる場合があります。

Deployment が更新されると、Kubernetes は関連する ReplicaSet を自動的に更新し、ポッドの総数が 5 になるように新しいポッドを起動します。

5 つの hello ポッドが実行されていることを確認します。

kubectl get pods | grep hello- | wc -l

今度はアプリケーションを縮小します。

kubectl scale deployment hello --replicas=3

ここでも、正しい数のポッドが起動していることを確認します。

kubectl get pods | grep hello- | wc -l

Kubernetes のデプロイと、ポッドのグループを管理してスケーリングする方法について学びました。

ローリング アップデート

Deployment では、ローリング アップデートのメカニズムを使用してイメージを新しいバージョンに更新できます。Deployment を新しいバージョンで更新すると、ReplicaSet が新たに作成され、古い ReplicaSet のレプリカ数が減少するにつれて、新しい ReplicaSet のレプリカ数が徐々に増加します。

8d107e36763fd5c1.png

ローリング アップデートをトリガーする

Deployment を更新するには、次のコマンドを実行します。

kubectl edit deployment hello

Deployment の containers セクションにある image を次のように変更します。

…
containers:
  image: kelseyhightower/hello:2.0.0
...

保存して終了します。

保存してエディタを終了すると、更新された Deployment がクラスタに保存され、Kubernetes がローリング アップデートを開始します。

Kubernetes によって作成された新しい ReplicaSet を確認します。

kubectl get replicaset

ロールアウト履歴にも新しいエントリが表示されます。

kubectl rollout history deployment/hello

ローリング アップデートを一時停止する

実行中のロールアウトで問題が検出された場合は、一時停止してアップデートを中止し、次の手順を試してください。

kubectl rollout pause deployment/hello

ロールアウトの現在の状態を確認します。

kubectl rollout status deployment/hello

ポッドで直接確認することもできます。

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

ローリング アップデートを再開する

ロールアウトが一時停止されるということは、一部のポッドが新しいバージョンで、その他のポッドは古いバージョンであることを意味します。resume コマンドを使用してロールアウトを続行してください。

kubectl rollout resume deployment/hello

ロールアウトの完了後に status コマンドを実行すると、次のように表示されます。

kubectl rollout status deployment/hello

(出力)

deployment "hello" successfully rolled out

アップデートをロールバックする

新しいバージョンでバグが検出されたと仮定します。この場合は新しいバージョンに問題があると考えられるため、新しいポッドに接続したユーザーにこれらの問題が発生することになります。

調査後にきちんと修正したバージョンをリリースするために、以前のバージョンにロールバックする必要があります。

rollout コマンドを使用して、以前のバージョンにロールバックします。

kubectl rollout undo deployment/hello

履歴でロールバックを確認します。

kubectl rollout history deployment/hello

最後に、すべてのポッドが以前のバージョンにロールバックされていることを確認します。

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

これで完了です。Kubernetes デプロイのローリング アップデートと、ダウンタイムなしでアプリケーションを更新する方法について学びました。

カナリア デプロイ

本番環境で一部のユーザーを対象に新しいデプロイをテストする場合は、カナリア デプロイを使用します。カナリア デプロイでは、一部のユーザーに変更をリリースすることで、新しいリリースに伴うリスクを軽減できます。

カナリア デプロイを作成する

カナリア デプロイは、新しいバージョンを含む独立したデプロイと、通常の安定したデプロイとカナリア デプロイの両方を対象とするサービスで構成されています。

48190cf58fdf2eeb.png

まず、新しいバージョン用の新しいカナリア デプロイを作成します。

cat deployments/hello-canary.yaml

(出力)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
        track: canary
        # Use ver 2.0.0 so it matches version on service selector
        version: 2.0.0
    spec:
      containers:
        - name: hello
          image: kelseyhightower/hello:2.0.0
          ports:
            - name: http
              containerPort: 80
            - name: health
              containerPort: 81
...

カナリア デプロイを作成します。

kubectl create -f deployments/hello-canary.yaml

カナリア デプロイが作成されると、hellohello-canary の 2 つのデプロイが存在することになります。次の kubectl コマンドを使用して確認してください。

kubectl get deployments

hello サービスのセレクタは、本番環境デプロイメントとカナリア デプロイメントの両方のポッドに一致する app:hello セレクタを使用します。ただし、カナリア デプロイのポッド数は少ないため、少数のユーザーにしか表示されません。

カナリア デプロイを確認する

リクエストに応じて提供される hello バージョンを確認できます。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

これを数回実行すると、一定のリクエストが hello 1.0.0 によって処理され、ごく一部(1/4 = 25%)が 2.0.0 によって処理されることがわかります。

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

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。カナリア デプロイメントが正常に作成されている場合は、評価スコアが表示されます。

カナリア デプロイメント

本番環境でのカナリア デプロイメント - セッション アフィニティ

このラボで Nginx サービスに送信された各リクエストは、カナリア デプロイで処理される可能性がありましたが、カナリア デプロイでユーザーが処理されることを避けたい場合もあります。たとえば、アプリケーションの UI が変更されるユースケースで、ユーザーを混乱させたくないときなどです。このような場合は、ユーザーをいずれかのデプロイに「固定」できます。

これは、セッション アフィニティを指定してサービスを作成することで実現できます。これにより、同じユーザーが常に同じバージョンで処理されます。以下の例では、サービスは以前と同じですが、新しく追加された sessionAffinity フィールドが ClientIP に設定されているため、同じ IP アドレスを持つすべてのクライアントのリクエストは、同じバージョンの hello アプリケーションに送信されることになります。

kind: Service
apiVersion: v1
metadata:
  name: "hello"
spec:
  sessionAffinity: ClientIP
  selector:
    app: "hello"
  ports:
    - protocol: "TCP"
      port: 80
      targetPort: 80

このテスト環境の設定は簡単ではないためここでは行いませんが、本番環境でのカナリア デプロイには sessionAffinity を使用することをおすすめします。

Blue / Green デプロイ

オーバーヘッド、パフォーマンスへの影響、ダウンタイムを最小限に抑えながら徐々にアプリケーションをデプロイできるローリング アップデートは、理想的な方法です。さらに、完全にデプロイされるまで新しいバージョンを指定しないようにロードバランサを変更すると効果的な場合があります。これには、Blue / Green デプロイが有効です。

Kubernetes は、古い「Blue」バージョン用と新しい「Green」バージョン用に 2 つの異なるデプロイを作成することでこれを実現します。「Blue」バージョンには既存の hello デプロイを使用します。このデプロイには、ルータとして機能するサービスを介してアクセスします。新しい「Green」バージョンが稼働したら、サービスを更新してそのバージョンを使用するように切り替えます。

9e624196fdaf4534.png

Blue / Green デプロイの欠点は、アプリケーションをホストするために必要なクラスタのリソースが少なくとも 2 倍になることです。アプリケーションの両方のバージョンを同時にデプロイする前に、クラスタに十分なリソースがあることを確認してください。

サービス

既存の hello サービスを使用しますが、app:helloversion: 1.0.0 のセレクタを持つように更新してください。 このセレクタは、既存の「Blue」デプロイとは一致しますが、「Green」デプロイとは一致しません。使用するバージョンが異なるからです。

まずはサービスを更新します。

kubectl apply -f services/hello-blue.yaml
: これは自動的にパッチが適用されるため、[resource service/hello is missing] という警告は無視してください。

Blue / Green デプロイを使用したアップデート

Blue / Green デプロイ スタイルをサポートするために、新しいバージョン用に「Green」デプロイを新たに作成します。この Green デプロイによって、バージョン ラベルとイメージパスが更新されます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
        track: stable
        version: 2.0.0
    spec:
      containers:
        - name: hello
          image: kelseyhightower/hello:2.0.0
          ports:
            - name: http
              containerPort: 80
            - name: health
              containerPort: 81
          resources:
            limits:
              cpu: 0.2
              memory: 10Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 81
              scheme: HTTP
            initialDelaySeconds: 5
            periodSeconds: 15
            timeoutSeconds: 5
          readinessProbe:
            httpGet:
              path: /readiness
              port: 81
              scheme: HTTP
            initialDelaySeconds: 5
            timeoutSeconds: 1

Green デプロイを作成します。

kubectl create -f deployments/hello-green.yaml

Green デプロイを作成して適切に起動したら、現在のバージョンである 1.0.0 がまだ使用されていることを確認します。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

次に、新しいバージョンを指定するようにサービスを更新します。

kubectl apply -f services/hello-green.yaml

サービスが更新されると、すぐに「Green」デプロイが使用されるようになり、常に新しいバージョンが使用されていることが確認できます。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Blue / Green ロールバック

必要に応じて、同じ方法で古いバージョンにロールバックできます。「Blue」デプロイがまだ実行されている間に、サービスを古いバージョンに戻すだけです。

kubectl apply -f services/hello-blue.yaml

サービスを更新すると、ロールバックが完了します。再度、正しいバージョンが使用されていることを確認してください。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

これで完了です。Blue / Green デプロイと、バージョンをすべて一度に切り替える必要があるアプリケーションにアップデートをデプロイする方法について学びました。

これで完了です。

これで Kubernetes によってデプロイを管理するハンズオンラボが終了しました。このラボでは、kubectl コマンドライン ツールと、YAML ファイルに設定されたさまざまなスタイルのデプロイ構成を活用して、デプロイをリリース、更新、スケーリングできました。この基礎演習で培ったスキルは、実際の DevOps 環境で問題なく役立つことでしょう。

6d0798e24a18671b.png Solutions_Kubernetes_125.png CloudEngineeringExaPrep_125.pmg DevOpsTransparent_125.png

クエストの終了

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

Kubernetes のスキルを実証し、知識を検証するためのハンズオン チャレンジラボをお探しですか。このクエストを完了すると、この追加の チャレンジラボを完了して、専用の GoogleCloud デジタルバッジを受け取ります。

final-deploy-kubernetes.png

次のラボの受講

以下のおすすめもご確認ください。

次のステップと詳細情報

Google Cloud Training & Certification

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

マニュアルの最終更新日: 2021 年 1 月 18 日
ラボの最終テスト日: 2021 年 1 月 18 日

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