ESPv2 を使用して Knative serving 用の Cloud Endpoints gRPC を設定する
このページでは、Knative serving 用に Cloud Endpoints を設定する方法について説明します。Endpoints は Extensible Service Proxy V2（ESPv2）を API ゲートウェイとして使用します。Knative serving 向けに API 管理機能を提供するには、GKE クラスタで実行中の Knative serving にビルド済みの ESPv2 コンテナをデプロイします。
この設定では、ESPv2 がサービスに対するすべてのリクエストを傍受し、必要なチェック（認証など）を行ってから、該当するサービスを呼び出します。サービスが応答すると、ESPv2 はテレメトリーを収集して報告します。
Endpoints の概要については、Endpoints についてと Endpoints アーキテクチャをご覧ください。
タスクリスト
次のタスクリストを参照しながら、チュートリアルを実施してください。このチュートリアルを完了するには、すべてのタスクを行う必要があります。
Google Cloud プロジェクトを作成する。独自の Knative serving をデプロイしていない場合は、サンプルのサービスをデプロイします。始める前にをご覧ください。
Knative serving を有効にして GKE クラスタを作成します。
Endpoints API を記述する gRPC API 構成ドキュメントを作成し、Knative serving サービスへのルートを構成します。Endpoints を構成するをご覧ください。
gRPC API 構成ドキュメントをデプロイしてマネージド サービスを作成します。Endpoints 構成をデプロイするをご覧ください。
Endpoints サービス構成で新しい ESPv2 Docker イメージをビルドします。新しい ESPv2 イメージをビルドするをご覧ください。
新しい ESPv2 Knative serving イメージをデプロイします。ESPv2 Cloud Run イメージをデプロイするをご覧ください。
ESPv2 Knative serving サービスへのドメイン マッピングを作成します。
API にリクエストを送信して構成をテストする。
サービスに対するアクティビティを追跡します。API の活動を追跡するをご覧ください。
クリーンアップします。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
- 後で必要になるため、プロジェクト ID をメモしておきます。このページでは以降、このプロジェクト ID を ESP_PROJECT_ID とします。
- gcloud CLI をダウンロードしてインストールします。
gcloud コマンドラインを設定する
Anthos の Knative serving 用に gcloud CLI を設定するには:
gcloud CLI がデータやサービスにアクセスできるように承認されていることを確認します。
ログインします。
gcloud auth login
表示された新しいブラウザタブで、ESPv2 を Knative serving にデプロイするために作成した Google Cloud プロジェクトの編集者またはオーナーのロールが割り当てられているアカウントを選択します。
インストールした
gcloudコンポーネントをアップデートします。gcloud components update
プラットフォームを
gkeに設定し、gcloudのデフォルト プロジェクト設定を先ほど作成したものに設定します。gcloud config set run/platform gke
gcloud config set project ESP_PROJECT_IDESP_PROJECT_ID は、作成したプロジェクトのプロジェクト ID に置き換えます。
新しいクラスタに必要なゾーンを設定します。GKE がサポートされていれば、どのゾーンでも使用できます。次に例を示します。
gcloud config set compute/zone ZONE
ZONE は、実際のゾーンに置き換えます。たとえば、
us-central1-aを使用します。GKE でサポートされている任意のゾーンを使用できます。プロジェクトで次の API を有効にします。これは、クラスタの作成や、コンテナのビルドと Google Container レジストリへのパブリッシュで必要になります。
gcloud services enable container.googleapis.com containerregistry.googleapis.com cloudbuild.googleapis.com
Knative serving を有効にした GKE クラスタを作成する
クラスタを作成して、Google Cloud 上の Knative serving 用に有効にするには:
次のコマンドで新しいクラスタを作成します。
gcloud container clusters create CLUSTER_NAME \ --addons=HttpLoadBalancing,CloudRun \ --machine-type=n1-standard-4 \ --num-nodes=3
CLUSTER_NAME は、クラスタに付ける名前で置き換えます。
これらの手順では、クラスタの自動スケーリングを有効にしてクラスタのサイズを変更することはできませんが、Google Cloud の Knative serving ではクラスタ内のインスタンスが自動的にスケーリングされます。
クラスタの作成が完了するまで待機します。作成プロセス中に、次のようなメッセージが表示されます。
Creating cluster CLUSTER_NAME...done. Created [https://container.googleapis.com/v1/projects/ESP_PROJECT_ID/zones/ZONE/clusters/CLUSTER_NAME].
また、出力には、出力の
NODE_VERSION列のクラスタのバージョンも示されます。たとえば、1.15.11-gke.1や1.14.10-gke.27です。このドキュメントの後半で使用するので、クラスタのバージョンをメモしておいてください。gcloud CLI を使用するときに指定しなくても済むように、新しいクラスタとクラスタのロケーションを
gcloudのデフォルトに設定します。gcloud config set run/cluster CLUSTER_NAME
gcloud config set run/cluster_location ZONE次のコマンドを使用して、新しいクラスタの詳細を表示します。
gcloud container clusters describe CLUSTER_NAME
次のコマンドを使用して、クラスタの認証情報を取得します。
gcloud container clusters get-credentials CLUSTER_NAME
サンプルの gRPC Cloud Run サービスをデプロイする
作成したクラスタに「grpc-bookstore」Cloud Run for Anthos のサンプルコンテナをデプロイするには:
gRPC Python クイックスタートの手順に沿って、gRPC と gRPC ツールをインストールします。
この gRPC サーバーのサンプルには、Python の「grpc-bookstore service」のビルド済み Docker イメージが含まれています:
gcr.io/endpointsv2/python-grpc-bookstore-server:2。「grpc-bookstore」をクラスタにデプロイするには、次のコマンドを使用します。gcloud run deploy GRPC_SERVICE \ --image=gcr.io/endpointsv2/python-grpc-bookstore-server:2 \ --platform=gke \ --connectivity=internal \ --use-http2
サービスが外部からアクセスできないように、これを内部サービスとして指定します。
GRPC_SERVICE は、サービスに付ける名前で置き換えます。例:
gcloud run deploy grpc-bookstore \ --image=gcr.io/endpointsv2/python-grpc-bookstore-server:2 \ --platform=gke \ --connectivity=internal \ --use-http2
完了すると、次のメッセージが表示されます。
Service [grpc-bookstore] revision [grpc-bookstore-00001-nuk] has been deployed and is serving 100 percent of traffic at http://grpc-bookstore.default.svc.cluster.local
内部サービスを作成すると、GKE によって DNS 名（この例では
grpc-bookstore.default.svc.cluster.local）が作成されます。この DNS 名はクラスタ自体から発信されるリクエストの場合のみ解決でき、外部リクエストの場合は解決できません。外部のクラスタからこの DNS にアクセスすることはできません。詳細については、Cloud Run サービスをご覧ください。サービスが正常に動作していることを確認するには、同じ Docker イメージを使用してポッドをクラスタにデプロイします。イメージには、内部サービスのテストに使用できる「grpc-bookstore」用の gRPC クライアント コードが含まれています。
上記と同じクラスタにポッドをデプロイするには、次の
kubectlコマンドを使用します。kubectl run grpc --generator=run-pod/v1 \ --image=gcr.io/endpointsv2/python-grpc-bookstore-server:2
このイメージには、クラスタ内からクライアント リクエストを行うために使用できる
bookstore_client.pyスクリプトが含まれています。注:
kubectlの新しいバージョンでは、このコマンドによって次の警告が表示されることがあります。Flag --generator has been deprecated, has no effect and will be removed in the future".この警告は無視しても問題ありません。
前の手順で Docker イメージをデプロイしたときに、クラスタに作成された「grpc-bookstore」Pod の名前を取得します。
kubectl get pods
出力は次の形式のようになります。
NAME READY STATUS RESTARTS AGE grpc 1/1 Running 0 23h
ここで、
grpは「grpc-bookstore」Pod の名前です。続行する前に、Pod の [ステータス] が [実行中] であることを確認します。次のコマンドを使用して、「grpc-bookstore」サービスに対してクライアント リクエストを行います。
kubectl exec grpc -ti -- python3 bookstore_client.py \ --host grpc-bookstore.default.svc.cluster.local --port=80
このコマンドは、クラスタ内で
bookstore_client.pyスクリプトを内部的に実行し、gRPC リクエストをホスト名grpc-bookstore.default.svc.cluster.localの「grpc-bookstore」サービスに送信します。すべてが正常に機能している場合、次のような形式のレスポンスが返されます。
ListShelves: shelves { id: 1 theme: "Fiction" } shelves { id: 2 theme: "Fantasy" }
Endpoints の設定
バックエンド サービスのサーフェスと認証要件を記述する gRPC API 仕様が必要です。
gRPC API 仕様の name フィールドの設定について
gRPC API 仕様の name フィールドで、Cloud Run for Anthos サービスへのアクセスに使用する Endpoints サービス名を指定します。Endpoints サービス名は、ドメイン名の形式になっています。
API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog
Endpoints サービス名はドメイン名に対応しているため、名前は次のルールに従う必要があります。
- 使用できるのは小文字、数字、ピリオド、ダッシュのみです。
- ダッシュで始めることはできません。
- アンダースコアを含めることはできません。
例:
grpc-boostore-api.endpoints.ESP_PROJECT_ID.cloud.goog
gRPC API 仕様の作成
bookstore-grpc サンプルには、ローカルにコピーして構成する必要のあるファイルが含まれています。
gRPC API 仕様用の新しいディレクトリ（
my-anthos-grpcなど）を作成します。次に、cd を実行してこのディレクトリに移動します。gRPC クライアント コードが新しいディレクトリに対してホストされる git リポジトリのクローンを作成します。
git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
作業ディレクトリに移動します。
cd python-docs-samples/endpoints/bookstore-grpc/
このディレクトリには bookstore.proto ファイルが含まれます。このファイルによって、Bookstore サービスの API が定義されます。
サービスの
.protoファイルから、自己完結型 protobuf 記述子ファイルを作成します。作業ディレクトリの下に
generated_pb2ディレクトリを作成します。protocプロトコル バッファ コンパイラを使用して、記述子ファイルapi_descriptor.pbを作成します。bookstore.protoが含まれるディレクトリで、次のコマンドを実行します。python3 -m grpc_tools.protoc \ --include_imports \ --include_source_info \ --proto_path=. \ --descriptor_set_out=api_descriptor.pb \ --python_out=generated_pb2 \ --grpc_python_out=generated_pb2 \ bookstore.proto
上記のコマンドでは、
--proto_pathが現在の作業ディレクトリに設定されています。gRPC ビルド環境で、.proto入力ファイルに別のディレクトリを使用する場合は、bookstore.protoを保存したディレクトリをコンパイラが検索するように--proto_pathを変更します。現在の作業ディレクトリ（
bookstore.protoを含む同じディレクトリ）のapi_config_anthos.yamlファイルを変更して、ファイルに次の内容を追加します。type: google.api.Service config_version: 3 # # Name of the service configuration. # name: API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog # # API title to appear in the user interface (Google Cloud console). # title: Bookstore gRPC API In Cloud Run Anthors apis: - name: endpoints.examples.bookstore.Bookstore # # Create a DNS record to map your service name to IP address # endpoints: - name: API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog target: IP_ADDRESS # # Specify the backend address to route to # backend: rules: - selector: "*" address: grpc://GRPC_SERVICE.default.svc.cluster.local disable_auth: true # # API usage restrictions. # usage: rules: # ListShelves methods can be called without an API Key. - selector: endpoints.examples.bookstore.Bookstore.ListShelves allow_unregistered_calls: trueyaml 形式ではインデントが重要です。
nameフィールドに、Cloud Run for Anthos サービスへのアクセスに使用する Endpoints API のドメイン名を次の形式で指定します。API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog例:
grpc-bookstore-api.endpoints.ESP_PROJECT_ID.cloud.googendpointsセクションでは、cloud.googドメインにあるエンドポイント サービスの DNS エントリを次の形式で登録します。endpoints: - name: API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog target: IP_ADDRESSIP_ADDRESS は、クラスタの
istio-ingressサービスの IP です。この IP アドレスを確認する方法は次のとおりです。Cloud Console で Google Kubernetes Engine ページに移動します。
左側のナビゲーション パネルで、[Services と Ingress] をクリックして、サービスのリストを表示します。
クラスタ バージョンが
1.15.3-gke.19以降、1.14.3-gke.12以降、1.13.10-gke.8以降のいずれかに相当する場合は、下方向にスクロールしてistio-ingressサービスを表示します。それ以外のクラスタ バージョンの場合は、istio-ingressgatewayサービスまで下にスクロールします。ロードバランサの横に表示されている外部 IP アドレスをコピーします。このとき、ポート設定（表示されている場合）は省きます。たとえば、IP が
XX.XXX.XX.XXX:15020の場合、:15020は省略します。表示されている他の IP アドレスは無視してください。
backendセクションのaddressフィールドは、Cloud Run の「grpc-bookstore」サービスの内部 DNS 名をプロトスキームgrpc://で指定し、このサービスへの認証を無効にします。address: grpc://GRPC_SERVICE.default.svc.cluster.local disable_auth: true
例:
address: grpc://grpc-bookstore.default.svc.cluster.local disable_auth: true
これは、ESPv2 から Cloud Run for Anthos サービスへの呼び出しがクラスタ内から内部呼び出しとして行われるために必要です。したがって、認証は必要ありません。
api_config_authos.yamlファイルのtitleプロパティの値をメモします。title: Bookstore gRPC API In Cloud Run Anthostitleプロパティの値は、構成をデプロイした後の Endpoints サービスの名前になります。gRPC API のドキュメントを保存します。
Endpoints に必要な OpenAPI ドキュメントのフィールドについては、Endpoints を構成するをご覧ください。
Endpoints 構成をデプロイする
Endpoints 構成をデプロイするには、gcloud endpoints services deploy コマンドを使用します。このコマンドを実行すると、Service Management を使用してマネージド サービスが作成されます。
Endpoints 構成をデプロイするには:
gRPC のドキュメントが格納されているディレクトリに移動します。
構成をアップロードしてマネージド サービスを作成します。
gcloud endpoints services deploy api_descriptor.pb api_config_anthos.yaml \ --project ESP_PROJECT_ID
これにより、
api_config_anthos.yamlファイルのnameフィールドに指定した名前で、新しい Endpoints サービスが作成されます。Endpoints サービスは OpenAPI ドキュメントに従って構成されています。Service Management でサービスの作成と構成が行われるとき、情報がターミナルに出力されます。デプロイが完了すると、次のようなメッセージが表示されます。
Service Configuration [CONFIG_ID] uploaded for service [API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog]
CONFIG_ID は、デプロイによって作成される一意の Endpoints サービス構成 ID です。例:
Service Configuration [2019-02-01r0] uploaded for service [grpc-bookstore-api.endpoints.ESP_PROJECT_ID.cloud.goog]
サービス構成 ID は、日付スタンプとそれに続くリビジョン番号で構成されます。同じ日に
api_config_anthos.yamlを再度デプロイすると、サービス構成 ID のリビジョン番号が増分されます。Google Cloud コンソールで [Endpoints] > [サービス] ページを開くと、サービス構成とデプロイの履歴を確認できます。エラー メッセージが表示された場合は、Endpoints 構成のデプロイのトラブルシューティングをご覧ください。
必要なサービスの確認
Endpoints と ESP を使用するには、少なくとも次の Google サービスの有効化が必要です。| 名前 | タイトル |
|---|---|
servicemanagement.googleapis.com |
Service Management API |
servicecontrol.googleapis.com |
Service Control API |
endpoints.googleapis.com |
Google Cloud Endpoints |
ほとんどの場合、gcloud endpoints services deploy コマンドによってこれらの必須サービスが有効化されます。ただし、以下の状況では、gcloud コマンドは正常に完了しますが、必須サービスが有効になりません。
Terraform などのサードパーティのアプリケーションを使用していて、上記のサービスを含めていない場合。
上記のサービスが明示的に無効にされている既存の Google Cloud プロジェクトに Endpoints 構成をデプロイした場合。
必要なサービスが有効になっていることを確認するには、次のコマンドを実行します。
gcloud services list
必要なサービスが表示されない場合は、次のコマンドを使用してサービスを有効にします。
gcloud services enable servicemanagement.googleapis.comgcloud services enable servicecontrol.googleapis.comgcloud services enable endpoints.googleapis.com
Endpoints サービスも有効にします。
gcloud services enable ENDPOINTS_SERVICE_NAME
ENDPOINTS_SERVICE_NAME を確認するには、次のいずれかを行います。
Endpoints 構成をデプロイ後、Cloud Console の [Endpoints] ページに移動します。[サービス名] 列に、考えられる ENDPOINTS_SERVICE_NAME のリストが表示されます。
OpenAPI の場合、ENDPOINTS_SERVICE_NAME は OpenAPI 仕様の
hostフィールドで指定したものです。gRPC の場合、ENDPOINTS_SERVICE_NAME は gRPC Endpoints 構成のnameフィールドで指定したものです。
gcloud コマンドの詳細については、gcloud サービスをご覧ください。
新しい ESPv2 Knative serving イメージをビルドする
新しい ESPv2 Docker イメージに Endpoints サービス構成をビルドします。このイメージを作成したら、それをクラスタにデプロイできます。
新しい ESPv2 Docker イメージにサービス構成をビルドするには:
gcloud CLI がインストールされているローカルマシンにこのスクリプトをダウンロードし、次のように実行します。
chmod +x gcloud_build_image
./gcloud_build_image -s API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog \ -c CONFIG_ID -p ESP_PROJECT_IDこのスクリプトは、
gcloudコマンドを使用してサービス構成をダウンロードして、新しい ESPv2 イメージにサービス構成をビルドし、新しいイメージを次のプロジェクト コンテナ レジストリにアップロードします。このスクリプトは、出力イメージ名に ESP_VERSION で示される ESPv2 の最新リリースを自動的に使用します。出力イメージは次の場所にアップロードされます。gcr.io/ESP_PROJECT_ID/endpoints-runtime-serverless:ESP_VERSION-API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog-CONFIG_ID
ESPv2 Knative serving イメージをデプロイする
ESPv2 Knative serving サービスのイメージをクラスタにデプロイします。
新しいイメージで ESPv2 Knative serving サービスをデプロイします。
gcloud run deploy ESP_V2_SERVICE_NAME \ --image="gcr.io/ESP_PROJECT_ID/endpoints-runtime-serverless:API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog-CONFIG_ID" \ --platform gke \ --use-http2 \ --project=ESP_PROJECT_ID
ESP_PROJECT_ID には、ESPv2 サービスに使用する名前を指定します。この例では、ESP_V2_SERVICE_NAME を
espv2に設定します。CORS を有効にするなどの追加の ESPv2 起動オプションを使用するように Endpoints を構成する場合は、引数を
ESPv2_ARGS環境変数に渡すことができます。gcloud run deploy ESP_V2_SERVICE_NAME \ --image="gcr.io/ESP_PROJECT_ID/endpoints-runtime-serverless:API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog-CONFIG_ID" \ --set-env-vars=ESPv2_ARGS=--cors_preset=basic \ --platform gke --use-http2 \ --project ESP_PROJECT_ID
使用可能なオプションのリスト、複数のオプションの指定方法についての情報など、ESPv2_ARGS 環境変数の詳細と設定例については、Extensible Service Proxy V2 のフラグをご覧ください。
ESPv2 Knative serving サービスにドメイン マッピングを作成する
リクエスト時に host ヘッダーを省略できるようにするには、ESPv2 サービスのドメイン マッピングを追加します。
[カスタムドメインの管理] を選択します。
[マッピングを追加] を選択します。
プルダウンから、[サービス ドメイン マッピングを追加] を選択します。
[マッピングを追加] のポップアップの [マッピング先のサービスを選択] フィールドで、ESPv2 サービスを選択します。
[ドメイン名を入力] フィールドに、Endpoints を介して Knative serving サービスにアクセスするために使用するドメイン名を指定します。例:
API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog
ここで、API_NAME は Endpoints API の名前です。この例では、「hello-api」を使用できます。
grpc-bookstore-api.endpoints.ESP_PROJECT_ID.cloud.goog
[続行] をクリックします。マッピングの概要が表示されます。
[完了] を選択してマッピングを保存します。
API にリクエストを送信する
サンプル API にリクエストを送信するには、Python で作成された gRPC クライアントを使用できます。
gRPC ドキュメント（
api_config_anthos.yamlなど）を含むディレクトリにいることを確認します。依存関係をインストールします。
pip3 install virtualenv
virtualenv envsource env/bin/activatepip3 install -r requirements.txtサンプル API にリクエストを送信します。
python3 bookstore_client.py --host API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog --port 80
例:
python3 bookstore_client.py --host grpc-bookstore-api.endpoints.ESP_PROJECT_ID.cloud.goog --port 80
すべてが正常に機能している場合、次のような形式のレスポンスが返されます。
ListShelves: shelves { id: 1 theme: "Fiction" } shelves { id: 2 theme: "Fantasy" }[エンドポイント] > [サービス] ページで API のアクティビティ グラフを確認します。
グラフにリクエストが反映されるまでしばらくかかります。
[ログ エクスプローラ] ページで、API のリクエストログを確認します。
正常なレスポンスが返されない場合は、レスポンス エラーのトラブルシューティングをご覧ください。
これで Endpoints の API のデプロイとテストが完了しました。
HTTPS を使用するように Endpoints API を構成する
Google Cloud 上の Knative serving では、自動 TLS サポートはデフォルトで無効になっています。そのため、この例では ESPv2 を介して Endpoints API にアクセスする際に、HTTP を使用して呼び出しを行います。
HTTPS を使用してリクエストをサポートするように ESPv2 を構成できます。内部バックエンド サービスである「hello」ではなく、外部サービスである ESPv2 で HTTPS サポートを構成します。
ESPv2 で HTTPS をサポートするには、次の手順を行う必要があります。
ドメインを所有している。ドメインをお持ちでない場合は、Google または別のドメイン ベンダーからドメインを取得します。
ESPv2 サービスのドメイン マッピングを作成し、ドメイン マッピング ページの手順に沿って DNS レコードを更新する。
Google Domains からドメインを取得した場合は、そのドメインを DNS サーバーとして使用します。それ以外の場合は、Cloud DNS または任意の DNS サーバーを使用します。Google Domains のドメインを使用するのが最も簡単な方法です。
Endpoints OpenAPI 仕様:
nameフィールドを*.cloud.googではなくドメインを参照するように設定します。endpointsタグとその 2 つの子プロパティを削除します。
詳細な手順とチュートリアルについては、HTTPS 証明書と自動 TLS 証明書を有効にするをご覧ください。
API の活動を追跡する
Google Cloud コンソールで [Endpoints] > [サービス] ページに移動して、API のアクティビティ グラフを表示します。
グラフにリクエストが反映されるまでしばらくかかります。
[ログ エクスプローラ] ページで、API のリクエストログを確認します。
API のデベロッパー ポータルを作成する
Cloud Endpoints Portal を使用してデベロッパー ポータルを作成できます。デベロッパー ポータルとは、サンプル API の操作に使用できるウェブサイトです。詳細については、Cloud Endpoints Portal の概要をご覧ください。
クリーンアップ
このページで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、次の手順を行います。
このチュートリアルで使用したサービスを停止する場合は、API と API インスタンスを削除するをご覧ください。