GSP363

概要

チャレンジラボでは、シナリオと一連のタスクが提供されます。手順ガイドに沿って進める形式ではなく、コース内のラボで習得したスキルを駆使して、ご自身でタスクを完了していただきます。タスクが適切に完了したかどうかは、このページに表示される自動スコアリング システムで確認できます。

チャレンジラボは、Google Cloud の新しいコンセプトについて学習するためのものではありません。デフォルト値を変更する、エラー メッセージを読み調査を行ってミスを修正するなど、習得したスキルを応用する能力が求められます。

100% のスコアを達成するには、制限時間内に全タスクを完了する必要があります。

このラボは、「Apigee X を使用した API の開発と保護」コースのラボを完了した受講者を対象としています。準備が整ったらチャレンジを開始しましょう。

設定

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

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

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

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

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

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

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

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

チャレンジ シナリオ

あなたは全国展開する小売店 Cymbal Shops でクラウド エンジニアとして働いています。Cymbal Shops はグローバルな販売に力を入れており、翻訳サービスはグローバルなビジネスを展開するための重要なツールとして位置づけられています。あなたは、translation API の最初のバージョンを作成することになりました。

これらのタスクのスキルや知識があるという前提のため、手順ガイドは提供されません。

チャレンジ

プロジェクトの Apigee 組織に、新しい Apigee API プロキシとその他のリソースを作成します。各タスクの説明文に目を通し、必要な機能を作成してください。

保存エラー

API プロキシへの変更を保存する際に、Could not save new revision エラーが出る場合があります。保存プルダウン ボタン（）を使用し、[Save as new revision] を選択した場合は、エラー メッセージが表示され、何が無効であるかがわかります。

タスク 1. Cloud Translation API をプロキシする

Cymbal Shops は API プロキシのバックエンド サービスとして Google Cloud の Translation API を使用することにしました。

要件:

1. Google Cloud コンソールで、Cloud Translation API が API ライブラリで有効であることを確認します。
2. API プロキシのサービス アカウント apigee-proxy を作成し、[Logging] > [ログ書き込み] のロールを付与します。
3. Google Cloud コンソールのナビゲーション メニューで、[Apigee] を選択して Apigee UI を開き、API プロキシを作成します。
4. API プロキシは translate-v1 というリバース プロキシとし、ベースパスは /translate/v1 とします。
5. API プロキシのターゲットは Cloud Translation API の Basic バージョン の HTTP URL（https://translation.googleapis.com/language/translate/v2）です。
6. プロキシ ウィザードの [Common policies] ページを使用して、認証、CORS、割り当てを追加しないでください。
7. 概要ページで、設定をデフォルトのままにして API プロキシを作成します。
8. デフォルトの TargetEndpoint に認証セクションを追加します。これにより、バックエンドのリクエストごとにアクセス トークンが送信されます。GoogleAccessToken 要素を使用し、スコープを https://www.googleapis.com/auth/cloud-translation とします。

注: プロキシを編集し、[開発] タブの [ターゲット エンドポイント] セクションで、default.xml ファイルを編集します。

9. 以下の Cloud Shell スクリプトを使用して、Apigee ランタイムが完全にインストールされていることを確認します。

export INSTANCE_NAME=eval-instance; export ENV_NAME=eval; export PREV_INSTANCE_STATE=; echo "waiting for runtime instance ${INSTANCE_NAME} to be active"; while : ; do export INSTANCE_STATE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}" | jq "select(.state != null) | .state" --raw-output); [[ "${INSTANCE_STATE}" == "${PREV_INSTANCE_STATE}" ]] || (echo; echo "INSTANCE_STATE=${INSTANCE_STATE}"); export PREV_INSTANCE_STATE=${INSTANCE_STATE}; [[ "${INSTANCE_STATE}" != "ACTIVE" ]] || break; echo -n "."; sleep 5; done; echo; echo "instance created, waiting for environment ${ENV_NAME} to be attached to instance"; while : ; do export ATTACHMENT_DONE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}/attachments" | jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output); [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break; echo -n "."; sleep 5; done; echo "***ORG IS READY TO USE***";

スクリプトが ORG IS READY TO USE を返したら、次の手順に進むことができます。

注: ランタイムのインストールを待っている場合は、先に読み進めて、タスク 2 の開発プランを立てることができます。

10. 以下のサービス アカウントを使用して、eval 環境に translate-v1 プロキシを保存してデプロイします。

apigee-proxy@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

11. API プロキシをテストします。

Apigee 組織内の eval 環境は、eval.example.com というホスト名で呼び出すことができます。この DNS エントリは内部ネットワークでのみ利用可能なため、作成された VM を使用する必要があります。

12. Cloud Shell で、apigeex-test-vm への SSH 接続を開きます。

TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

13. 承認するよう求められた場合は、[承認] をクリックします。gcloud コマンドで尋ねられる各質問について、Enter または Return キーを押して、デフォルトの入力を指定します。

14. タスク 1 が成功したら、以下の curl コマンドでテキストが翻訳されるはずです。

curl -i -k -X POST "https://eval.example.com/translate/v1" -H "Content-Type: application/json" -d '{ "q": "Translate this text!", "target": "es" }'

レスポンスは次のようになります。

{ "data": { "translations": [ { "translatedText": "¡Traduce este texto!", "detectedSourceLanguage": "en" } ] } } 注: API プロキシが完全にデプロイされるまでの数分間は、502 エラー レスポンスが表示されることがあります。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Translation API をプロキシする

注: 緑のチェックマークが表示されていない場合は、右上のスコアボックスをクリックし、関連するステップの [進行状況を確認] をクリックします。ポップアップ ボックスでアドバイスが表示されます。

タスク 2. API リクエストと API レスポンスを変更する

Cymbal Shops は Translation API が提供するインターフェースとは異なる API を作りたいと考えています。修正すべき Translation API 呼び出しは 2 つあります。

最初の呼び出しで、有効な言語のリストを取得します。

Cloud Translation API リクエスト:

REQUEST: POST https://translation.googleapis.com/language/translate/v2/languages Authorization: Bearer ACCESSTOKEN Content-Type: application/json { "target": "en" }

Cloud Translation API レスポンス:

Content-Type: application/json { "data": { "languages": [ { "language": "af", "name": "Afrikaans" }, { "language": "sq", "name": "Albanian" }, ... ] } }

translate-v1 リクエスト:

GET https://eval.example.com/translate/v1/languages

translate-v1 レスポンス:

Content-Type: application/json [{"language": "af","name": "Afrikaans"},{"language": "sq","name": "Albanian"}, ... ]

API プロキシは、GET を POST に置き換え、data と languages のレスポンスのフィールドを削除し、プロパティ セットからターゲット言語のコードを得る必要があります。アクセス トークンは、タスク 1 の [認証] セクションで自動的に追加されました。

2 回目の呼び出しで、テキストを指定された言語に翻訳します。

Cloud Translate API リクエスト:

POST https://translation.googleapis.com/language/translate/v2 Authorization: Bearer ACCESSTOKEN Content-Type: application/json { "q": "Hello world!", "target": "de" }

Cloud Translate API レスポンス:

Content-Type: application/json { "data": { "translations": [ { "translatedText": "Hallo Welt!", "detectedSourceLanguage": "en" } ] } }

translate-v1 リクエスト:

POST https://eval.example.com/translate/v1?lang=de Content-Type: application/json { "text": "Hello world!" }

translate-v1 レスポンス:

Content-Type: application/json { "translated": "Hallo Welt!" }

API プロキシは lang クエリ パラメータからターゲット言語を取得し、受信テキストと翻訳テキストのフィールド名を変更する必要があります。lang クエリ パラメータはオプションで translate-v1 リクエストから省略することができ、その場合、ターゲット言語はプロパティ セットのプロパティから取得されます。

注: Translation API では、「q」フィールドに単一の文字列または文字列の配列のいずれかを指定できます。作成している API では単一の文字列のみに対応する必要があります。

要件:

1. API プロキシ内に、language.properties という名前のプロパティ セットを作成します。このプロパティ セットには、es の値をもつ output と、en の値をもつ caller の 2 つのプロパティが必要です。caller プロパティは、言語のリスティング時にターゲット言語（name フィールドに使用される言語）を指定するために使用します。output では lang クエリ パラメータが提供されない場合に使用されるデフォルトのターゲット言語を指定します。

2. プロキシ エンドポイントで、POST / リソース用のパスと動詞の条件付きフローを作成します。そのフローの名前を translate とします。

3. プロキシ エンドポイントで、/languages リソース用のパス（動詞なし）の条件付きフローを作成します。そのフローの名前を getLanguages とします（動詞は含みません。リクエストの動詞を GET（プロキシへの入力用）から POST（バックエンドで必要）に変更することになります。条件に動詞を含めると、request.verb が GET と等しくなくなるため、フロー内のレスポンス ポリシーは実行されません）。

4. translate 条件付きフローで使用するバックエンド リクエストを作成するには、AM-BuildTranslateRequest という名前の AssignMessage ポリシーを作成します。

ポリシーの内容は以下のとおりです。

• AssignVariable とテンプレートによって、のちにログに記録されたメッセージで使用する変数を作成します。text という名前の変数は jsonPath メッセージ テンプレート関数を使用して、リクエストから text フィールドを抽出する必要があります。

• language という名前の変数は、firstnonnull メッセージ テンプレート関数を使用して作成する必要があります。この変数には、lang クエリ パラメータ値がある場合はその値を含める必要があり lang クエリ パラメータが指定されていない場合は、ターゲット言語の言語プロパティ セットの output プロパティを含める必要があります。

• バックエンド サービスが必要とする JSON ペイロードを設定するには Set セクションを使用します。作成した両変数は、ペイロードで使用されます。

• [AssignTo] 要素では既存のリクエスト メッセージを使用する必要があります。

  AssignMessage ポリシーの AssignVariable セクションは、以下のようになります

  <AssignVariable> <Name>...</Name> <Template>...</Template> <AssignVariable>

5. Translation API レスポンスを使用して呼び出し元へのレスポンスを作成するには、translate 条件付きフローの下に AM-BuildTranslateResponse という名前の AssignMessage ポリシーを作成します。

ポリシーの内容は以下のとおりです。

• AssignVariable と jsonPath テンプレートによって、translated という名前の変数を作成し、Translation API レスポンスから translatedText フィールドを抽出します。ヒント: このフィールドを抽出する JSONPath 式は、$.data.translations[0].translatedText です。

• createNew を true に設定します

• 新しい JSON ペイロードは translated 変数を使用します。

  AssignMessage ポリシーの AssignVariable セクションは、以下のようになります

  <AssignVariable> <Name>...</Name> <Template>...</Template> <AssignVariable>

6. getLanguages 条件付きフローで使用されるバックエンド リクエストを作成するには、AM-BuildLanguagesRequest という名前の AssignMessage ポリシーを作成します。

ポリシーの内容は以下のとおりです。

• バックエンド リクエストの正しい動詞とペイロードを設定するには、Set を使用します。

• バックエンド ペイロードの target パラメータフィールドには、language プロパティ セットの caller プロパティを使用する必要があります。

• createNew を true に設定します

• コンテンツ タイプが application/json になるようにバックエンド リクエスト ペイロードを設定します。

  AssignMessage ポリシーの AssignVariable セクションは、以下のようになります

  <AssignVariable> <Name>...</Name> <Set> ... </Set> </AssignVariable>

7. 呼び出し元へのレスポンスを作成するには、getLanguages 条件付きフローの下に JS-BuildLanguagesResponse という名前の JavaScript ポリシーを作成します。JavaScript コードでは、次の手順に従う必要があります。

• context.getVariable を使用して response.content 変数を取得します。
• JSON.parse を使用して response.content JSON をオブジェクトに変換します。
• JSON.stringify を使用して、オブジェクトの data.languages フィールドを JSON に変換します。
• context.setVariable を使用して response.content をステップ 3 の JSON に置き換えます。

JavaScript コードは次のようになります。

var payload = ...; var payloadObj = JSON.parse(...); var newPayload = JSON.stringify(...); context.setVariable(...); 注: 正しい条件付きフローの下で目的のポリシーを作成して、それぞれの .xml ファイルで目的のポリシー構成を編集してください。

8. API をテストします。apigeex-test-vm 仮想マシンから、以下の curl コマンドを使用して、上記の例をテストします。

• 言語リスト:

  curl -i -k -X GET "https://eval.example.com/translate/v1/languages"

• 指定した言語（ドイツ語）に翻訳:

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type: application/json" -d '{ "text": "Hello world!" }'

• デフォルトの言語（スペイン語）に翻訳:

  curl -i -k -X POST "https://eval.example.com/translate/v1" -H "Content-Type: application/json" -d '{ "text": "Hello world!" }'

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 API リクエストと API レスポンスを変更する

注: 緑のチェックマークが表示されていない場合は、右上のスコアボックスをクリックし、関連するステップの [進行状況を確認] をクリックします。ポップアップ ボックスでアドバイスが表示されます。

タスク 3. API キー検証と割り当ての適用を追加する

この API へのアクセスは承認されたアプリケーションに限定する必要があるため、VerifyAPI キーポリシーと、リクエスト数を制限する割り当てポリシーを追加します。

要件:

1. 名前と表示名を translate-product とする API プロダクトを作成します。この API プロダクトは公開アクセスが有効であり、アクセス リクエストを自動的に承認する必要があります。また、この API プロダクトは評価環境で利用できる必要があります。

2. translate-product API プロダクトにオペレーションを追加します。このオペレーションは translate-v1 プロキシへのアクセスを許可し、/ を含むすべてのリクエストへのアクセスを許可する / のパスを使用する必要があります。許可されているメソッドは GET と POST です1 分間に 10 件のリクエストとするオペレーション割り当て設定を追加します。

3. メール joe@example.com でデベロッパーを作成します。そして、あなた自身の氏名とユーザー名を選びます。

4. translate-app という名前のアプリを作成し、translate-product API プロダクトを有効にします。また、このアプリを joe@example.com デベロッパーと関連付ける必要があります。

5. プロキシ エンドポイントの preflow に VA-VerifyKey という名前の VerifyAPIKey ポリシーを追加します。API キーはリクエストごとに必要であり、Key ヘッダーを使用して送信する必要があります。

6. プロキシ エンドポイントの preflow に Q-EnforceQuota という名前の割り当てポリシーを追加します。

ポリシーには以下の手順を含めます。

• ある種類の calendar を使用します。calendar の種類には StartTime 要素が必要です
• UseQuotaConfigInAPIProduct を指定して、API プロダクトから割り当てを使用します。API プロダクトで割り当て設定が指定されていない場合は、デフォルトの割り当てである 1 時間ごとに 5 件のリクエストを使用します。
• Distributed と Synchronous を true に設定し、 AsynchronousConfiguration 要素を削除します

これらの変更が行われると、有効な API キーが Key ヘッダーに指定されていない場合、リクエストはエラーを返します。

7. apigeex-test-vm 仮想マシンから、以下の curl コマンドを使用して API キーの機能をテストします。

• 失敗（API キーなし）:

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type: application/json" -d '{ "text": "Hello world!" }'

• 失敗（無効な API キー）:

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type: application/json" -H "Key: ABC123" -d '{ "text": "Hello world!" }'

• 成功（有効な API キー KEY=<前のステップでデベロッパー アプリを設定するときに指定した値> に KEY 変数が設定されている場合）:

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type: application/json" -H "Key: $KEY" -d '{ "text": "Hello world!" }'

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 API キー検証と割り当ての適用を追加する

注: 緑のチェックマークが表示されていない場合は、右上のスコアボックスをクリックし、関連するステップの [進行状況を確認] をクリックします。ポップアップ ボックスでアドバイスが表示されます。

タスク 4. メッセージ ロギングを追加する

翻訳サービスの利用状況を把握するため、MessageLogging ポリシーにより、翻訳された各メッセージがログに記録されます。

要件:

1. ML-LogTranslation という名前の MessageLogging ポリシーを translate 条件付きフローに追加します。このポリシーは AM-BuildTranslateResponse ステップの後に実行する必要があります。

注: ログは翻訳オペレーションのためにのみ作成されるため、このポリシー を PostClientFlow には追加しないでください。

2. ポリシーは Cloud Logging にログを記録する必要があります。このポリシー ドキュメントを使用してください。

• LogName の値は以下のようにします。

  projects/{organization.name}/logs/translate

• ログに記録されたメッセージは contentType を text/plain とし、メッセージ コンテンツは以下のようにする必要があります

  {language}|{text}|{translated}

このメッセージは AM-BuildTranslateRequest ポリシーと AM-BuildTranslateResponse ポリシーで作成された language、text、translated 変数が必要です。

3. Google Cloud コンソールの Logging ページでログに記録されたメッセージを検証します。logName : "translate" クエリを使用して、翻訳されたログのみを表示します。

4. MessageLogging ポリシーが正常に追加されたら、次の curl コマンドを使用します。

curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type: application/json" -H "Key: $KEY" -d '{ "text": "Hello world!" }'

• その curl コマンドで次の内容のログ メッセージが作成されるはずです。

  de|Hello world!|Hallo Welt!

注: ログに記録されたメッセージがログに表示されるまで、少し遅延があります。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 メッセージ ロギングを追加する

注: 緑のチェックマークが表示されていない場合は、右上のスコアボックスをクリックし、関連するステップの [進行状況を確認] をクリックします。ポップアップ ボックスでアドバイスが表示されます。

タスク 5. バックエンド エラー メッセージを書き換える

Translation API に送信された target パラメータが無効な場合、400 Bad Request というエラー メッセージが返されます。

{ "error": { "code": 400, "message": "Invalid Value", "errors": [ { "message": "Invalid Value", "domain": "global", "reason": "invalid" } ] } }

このエラー メッセージは送信者を混乱させるので、エラー メッセージを書き換えます。

要件:

1. デフォルトのターゲット エンドポイントに FaultRules セクションを追加します。バックエンドが 400 レスポンスを返すと、ターゲット エンドポイントで一致するフォールト ルールが自動的に評価されます。

注: 左側の UI ナビゲーション メニューは FaultRules セクションの追加には使用できません。そのセクションは、ターゲット エンドポイントの XML 構成で追加する必要があります。

2. FaultRules セクションに FaultRule を追加します。この FaultRule の条件は、fault.name が ErrorResponseCode である場合に FaultRule を実行するよう設定する必要があります。

3. AM-BuildErrorResponse という名前の AssignMessage ポリシーを作成し、FaultRule に設定します。以下のポリシー構成を使用します。

<AssignMessage name="AM-BuildErrorResponse"> <Set> <Payload contentType="application/json">{ "error": "Invalid request. Verify the lang query parameter." }</Payload> </Set> </AssignMessage>

ポリシーが設定されると、ターゲット エンドポイントの FaultRules セクションは次のようになります。

<FaultRules> <FaultRule name="..."> <Step> <Name>...</Name> </Step> <Condition>...</Condition> </FaultRule> </FaultRules> 注: ターゲット エンドポイント XML を手動で編集する必要があります（ProxyEndpoint ではなく TargetEndpoint であることを確認してください）。

4. API をテストします。

• このような有効なリクエストは、引き続き機能する必要があります。

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type: application/json" -H "Key: $KEY" -d '{ "text": "Hello world!" }'

• このような無効な言語クエリ パラメータでは、書き換えられたエラー メッセージを返す必要があります。

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=invalid" -H "Content-Type: application/json" -H "Key: $KEY" -d '{ "text": "Hello world!" }'

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 バックエンド エラー メッセージを書き換える

注: 緑のチェックマークが表示されていない場合は、右上のスコアボックスをクリックし、関連するステップの [進行状況を確認] をクリックします。ポップアップ ボックスでアドバイスが表示されます。

お疲れさまでした

このチャレンジラボのコースでは、Apigee X を使用した API の開発と保護に関する知識を確認しました。

次のスキルバッジを獲得する

このセルフペース ラボは、「Apigee X を使用した API の開発と保護」クエストの一部です。このクエストを完了すると成果が認められて上のようなバッジが贈られます。獲得したバッジを履歴書やソーシャル プラットフォームに記載し、#GoogleCloudBadge を使用して成果を公表しましょう。

このスキルバッジ クエストは Google Cloud の API デベロッパー向け学習プログラムの一部です。「Deploy and Manage Apigee X」クエストに登録し、学習を続けてください。

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

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

マニュアルの最終更新日: 2024 年 7 月 10 日

ラボの最終テスト日: 2024 年 7 月 10 日

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