リリース前のチェックリスト

チームが必要なリソースにアクセスできるようにする

Google Maps APIs Premium Plan のウェルカム レターは安全な場所に保管する

重要な理由: ウェルカム レターは Google Maps APIs Premium Plan の Starter Kit で、おそらく最初に必要となるキットです。ここには、Google API Console プロジェクト ID、クライアント ID、秘密暗号化キーなどの重要な情報が含まれています。この情報は、Premium Plan の使用を開始するときに必要です。また、Premium Plan サポートチームに問い合わせるために必要な情報もすべて含まれています。この情報は、Google Maps API で技術的な問題が発生した場合に必要になります。

Google Cloud Support Portal を使用する

重要な理由: サポートポータルでは、使用状況レポート、ニュースフィード、開発者向けの役立つリソースなどの情報にアクセスできます。さらに重要なのは、開発中やリリース時に技術的な問題が発生した場合、このサポートポータルから Premium Plan サポートチームにサポートケースを提出できることです。サポートポータルには、次の URL からアクセスします。

https://google.secure.force.com/

リリース前に時間を取って、アプリケーションのメンテナンスを担当するすべての開発者がサポートポータルにアクセスできるようにします。技術的な問題に発生した場合、サポートポータルへのアクセスには 2 つのメリットがあります。まず、チームのメンバーからサポートに問い合わせることができます。反対に、サポートチームから問い合わせ元組織の適切な関係者に連絡することも可能です。たとえば、アプリケーションの停止につながる異常なトラフィックや動作が見つかったとします。このような場合、サポートチームから問題が発生した組織への連絡が必要になることがあります。サポートチームから適切な開発者に連絡を取れるかどうかが、予期せぬ結果を招くか、そのような結果に陥るのを避けるかの分かれ目になることがあります。サポートポータルへのアクセスが許可されていない場合は、以下からアクセスを申請します。

Google Cloud Support Portal アカウントを申請する

関連通知フィードを購読する

重要な理由: Maps API 全体の開発や変更に遅れないよう、よくある質問の説明に従って関連通知フィードを購読することをお勧めします。

また、Google Maps Premier API Announcements:Outages, Updates, Service Notifications(Google Maps Premier API からのお知らせ: 停止、更新、サービス通知)の RSS フィードを購読することもできます。

http://google.force.com/services/xml/MapsRSS

サポート ホットラインにいつでも連絡できるようにする

1-877-355-5787(米国内のユーザー)、+1 404-978-9282(米国外のユーザー)

重要な理由: このホットラインは、Google Cloud Support Portal へ電話連絡する手段です。サポート ホットラインの最新電話番号を検索できるように、このページにブックマークを設定してください。サポート ホットラインはサポートチームに技術的な問題を報告するために利用できますが、利用は運用環境が停止する場合、サービスを利用できない場合に限られています。優先度レベルは、以下のドキュメントで定義されています。

https://support.google.com/work/answer/184028

アプリケーションを最適化する

Google Maps APIs サービスにアクセスできるようにファイアウォールを設定する

重要な理由: Google Maps APIs サービスではさまざまなドメインを使用します。中には *google.com ドメインに属していないドメインもあります。制限が厳しいファイアウォールに保護されている場合、各 Maps API サービスが使用するドメインへのアクセスを許可することが重要です。このようなドメインへのアクセスをファイアウォールが許可しない場合、API リクエストが失敗し、アプリケーションが停止する可能性があります。Maps API によって使用されているドメインの完全なリストは、次の手順に従って、サポートポータルで検索してください。

  1. Google Cloud Support Portal にログインします。
    サポートポータルの利用は Google Maps APIs Premium Plan、以前の Google Maps APIs for Work、または Google Maps for Business ライセンスを所有するユーザーに限定されています。
  2. [Resources] タブに移動します。
  3. Google Maps APIs ファミリによって使用されるドメインのリストを選択します(直接リンクはこちらです)。
  4. アプリケーションからこのリストに示されたドメインへのアクセスを許可します。

これらのドメインに関連付けられた IP アドレスは静的なものではありません。そのため、IP アドレスでのファイアウォール制限の管理はお勧めしません。

注: Google Maps APIs サービスは、着信トラフィックと発信トラフィックにポート 80(http) と 443(https) を使用します。これらのサービスは、GET、POST、PUT、DELETE、HEAD の各リクエストも必要とします。API とユースケースに応じて、これらのポート経由のトラフィックを許可し、リクエストを許可するよう、ファイアウォールを設定します。

正しい SSL ホスト名で API を読み込む

重要な理由: Maps API を SSL 経由で読み込むアプリケーションは、以前のホスト名(https://maps-api-ssl.google.com)ではなく、https://maps.googleapis.com から読み込む必要があります。

Google Maps JavaScript API を使用するために SSL ドメインを承認する

重要な理由: Google Maps JavaScript API を SSL ドメインで使用する場合、明示的にHTTPS ドメインを承認して、リクエストが拒否されないようにすることが重要です。http://yourdomain.com を承認しても、同じドメインで SSL を使用する https://yourdomain.com は自動的には有効にならないことに注意してください。Google Cloud Support Portal で承認済みのドメインのリストを確認するには、左側のナビゲーション メニューから [Maps: Manage Client ID] リンクを選択します。SSL ドメインでのクライアント側 API の使用に関連するエラーのトラブルシューティングを行うには、まずページの要素が HTTP 経由で読み込まれるかどうかをチェックします。承認に関するトラブルシューティングのガイドもご覧ください。

API の適切なバージョンの選択

重要な理由: アプリケーションを開発する前に、どのバージョンの API のサポートが終了しているかを把握することが重要です。サポート対象のバージョンの API を対象に開発を進めておけば、サポートを終了したバージョンが利用できなくなった後の工程にかかる開発時間とコストを削減できます。

特に、Google Maps JavaScript API で使用される API のバージョニング スキームを理解し、環境内で不適切なバージョンの API を誤って使用しないことも重要です。

たとえば、開発環境やテスト環境では、試験運用版の API を使用するのが適していても、本番環境では試験運用版を使用しないことを強くお勧めします。SLA は安定したバージョンの API のみに適用されるため、本番環境では安定したバージョンのみを使用してください。

Google Maps JavaScript API のバージョンに関するガイドをご覧ください。

クライアント側とサーバー側との設計の選択

重要な理由: クライアント側のアプローチとサーバー側のアプローチのどちらを選択するかによって、アーキテクチャが決まります。そのため、アプリケーションの安定性と拡張性にとってはこの選択が極めて重要になります。全般的に見て、レコードの処理前後はオフラインにする(アプリケーションの外部で処理する)場合は、サーバー側のアプローチを使用します。これに対して、アプリケーションの中でユーザーと対話する(ユーザーが送信するリクエストをリアルタイムで処理する)部分にはクライアント側のアプローチを使用します。

クライアント側のアプローチを使用すべき状況で代わりにサーバー側のアプローチを採用すると、割り当て超過を引き起こし、アプリケーションが機能しなくなります。サーバー側の呼び出しを使用するアプリケーションを設計またはリリースする前に、Geocoding Strategies ドキュメントを確認することを強くお勧めします。

割り当ての使用状況の最適化

重要な理由: アプリケーションが割り当てを消費する方法(Maps APIs Credits)を理解すると、支払う費用を削減できます。たとえば、Google Maps JavaScript API を使用している場合、アプリケーションはマップロードごとに Maps APIs Credits を消費します。Premium Plan使用レートと使用制限に関するガイドをご覧ください。

ウェブサービスの割り当て使用状況の管理

重要な理由: デフォルトでは、共有ウェブサービスの割り当ては、1 日あたり 100,000 回の無料リクエストに設定されています。API ごとに細分化された割り当ての詳細については、使用制限に関するガイドをご覧ください。プロジェクトで利用できる割り当て量を確認するには、サポートケースを提出します。

サービスをリリースする前に、割り当て関連のさまざまなエラー(例: OVER_QUERY_LIMITUser Rate Limit Exceeded)を理解し、割り当て超過になった場合にこのようなエラーに対応できるよう、アプリケーションに適切なロジックを設定しておくことが重要です。まずは、使用制限に関するよくある質問をご確認ください。各 API から返されるステータスコードの情報は、該当する API のデベロッパー ガイドをご確認ください。たとえば、Google Maps Directions API のステータスコードに関するガイドを確認します。これらの概念を理解してから実装すると、アプリケーションが許容割り当てを超えたり、Google によってブロックされたり、機能を停止する可能性が大幅に減少します。

アプリでロードテストを実行する

重要な理由: アプリケーションのロードテストを使用して、Maps API の割り当てを超過することなく、大量のリクエストを処理できることを確認します。

実際の Google サービスに対してロードテストを行うと、アプリケーションに許容されている割り当てを超過し、Google によってブロックされることになります。Google Maps APIs は非常に大量のリクエストにサービスを提供できます。2012 年には、「サンタを追いかけよう」で 1 秒あたり 1,600,000 回のリクエストにサービスを提供しました。したがって、Google サービスに対してロードテストを実行する必要はありません。代わりにアプリケーションのロードテストを行って、アプリケーションが Maps API の割り当てを超過することなく、大量のリクエストを処理できることを確認します。たとえば、Google Maps Geocoding API の割り当てが 20 QPS(1 秒あたりのクエリ数)だとします。この場合、アプリケーションのロードテストを行って、アプリケーションが 20 QPS を超えて Google Maps Geocoding API に送信することなく、600 QPS を処理できることを確認します。

これを安全に実現するには、ロードテストをモック(疑似) API に対して実行します。モック API とは、Google Maps APIs を必要としないで、大量のリクエストを受け入れて有効なレスポンスを返すサービスです。したがって、Google Maps APIs によってブロックされる危険を伴わずに、アプリケーションのロードテストを実行できます。

小さな Google App Engine アプリケーションとして実装されるモック API の例を確認してください。このモック API を独自の App Engine アプリケーションにアップロードし(https://appengine.google.com/ で登録後)、アプリケーションから maps.googleapis.com にではなく、この API にリクエストを送信できます。

デフォルト(無償版)の App Engine の割り当ては、通常、アプリケーションのロードテストを十分に実行できるよう、Maps API ウェブサービスの割り当てをはるかに超えています。アプリケーションでレスポンスの圧縮を有効にする適切な User-Agent ヘッダーを設定していることを確認してください。この設定は、帯域幅を効果的に使用するために重要です。特に、書式なしテキスト(JSON/XML)のレスポンスを大量に処理する App Engine アプリケーションでは重要です。App Engine アプリケーションに多くの割り当てが必要な場合、課金を有効にすることも可能ですが、めったに必要になることはありません。

アプリケーションのライセンスを標準ライセンスからプレミアム ライセンスに移行する

API のリクエストにクライアント ID または API キーを含める

重要な理由: アプリケーションで行える最も重要なことの 1 つは、API のリクエストにクライアント ID(gme-yourclientid) または API キー(AIzaSyBdVl-cTICSwYKrZ95SuvNw7dbMuDt1KG0 のような形式)を含めることです。クライアント ID または API キーによって、リクエストが Google Maps APIs Premium Plan のリクエストであることが特定されます。

Premium Plan 固有の機能のメリットを得るためには、アプリケーションにクライアント ID または API キーを含める必要があります。テクニカル サポートを受けるため、およびアプリケーションが SLA の対象になるようにするためにも、クライアント ID または API キーを含めることが必要になります。

ほとんどの API では、クライアント ID または API キーのどちらを使用するかを選択できます。クライアント ID は、組織のプライマリ連絡先宛てに届くウェルカム レターに記載されています。 Google API Console では、API キーなどのキーを独自に生成できます。

詳細については、認証と承認に関するガイドをご覧ください。

API のリクエストに API キーまたはクライアント ID の一方は含めても両方は含めない

重要な理由: Google Maps JavaScript API を正しく読み込むためには、つまり、他の Google Maps API にリクエストを送信するには、クライアント ID または API キーの一方を含める必要がありますが、両方は含めません。クライアント ID を選択する場合、すべての key パラメータを削除する必要があります。クライアント ID とキーの両方をリクエストに含めると、そのリクエストは失敗します。

API ごとに Premium Plan リクエストの形式を正しく設定する方法の詳細については、認証と承認に関するガイドをご覧ください。

クライアント ID の使用時は、Google Maps JavaScript API で使用するドメインを承認する

重要な理由: 未承認のサイトではクライアント ID を使用できないため、Google Maps JavaScript API では、クライアント ID を使用するすべてのサイトのすべてのドメインでサポートチームを承認する必要があります(クライアント ID ではなく API キーを使用する場合、URL 登録は必要ありません)。クライアント ID の使用が承認された URL と、クライアント ID を使おうとしているサイトが一致しない場合、サイトはそのクライアント ID で API を使用できません。ドメインはいつでも承認できます。リリース前に必ずすべてのサイトのドメインを承認するようにしてください。

Google Cloud Support Portal で承認済みのドメインのリストを確認するには、左側のナビゲーション メニューから [Maps: Manage Client ID] リンクを選択します。

承認の問題については、ケースを提出する前に、承認のトラブルシューティングに関するガイドを確認することをお勧めします。

クライアント ID の使用時は、秘密暗号化キーで生成した署名を使ってウェブサービス リクエストに署名する

重要な理由: 秘密暗号化キーは、リクエストが信頼されるソースから発行されたことを Google に伝えるデジタル署名を生成するために使用します。ウェブサービス API では、認証にクライアント ID を使用している場合、デジタル署名をリクエストに追加することが求められます。これにより、リクエストの上位にセキュリティのレイヤが追加され、クライアント ID に関連付けられた割り当てが適切に保護されます。暗号化キー(例: vNIXE0xscrmjlyV-12Nj_BvUPaw=)は、組織のプライマリ連絡先宛てに届くウェルカム レターに記載されています。

注: 暗号化キーは、署名の生成に使用されます。署名自体がリクエストに追加されることはありません。暗号化キーは ATM の暗証番号に似ています。アカウントにアクセスするための認証手段として使用されるため、信頼できないソースへの公開や提示は避けてください。適切に署名されていない Premium Plan ウェブサービス リクエストは、サーバーによって拒否されるため、リリース前にアプリケーションがリクエストに適切に署名することが重要です。認証と承認に関するガイドをご覧ください。

アプリケーションの使用状況を追跡する

重要な理由: Premium Plan のユーザーは、作成したリクエスト、消費されたクレジット、返されたエラーなど、アプリケーションの使用状況に関する詳細なレポートにアクセスできます。レポートに関するガイドをご覧ください。

channel パラメータは省略可能なパラメータです。このパラメータを使ってアプリケーションごとに個別のチャンネルを割り当て、クライアント ID でアプリケーションの使用状況を追跡できます。channel パラメータをクライアント ID に登録する必要はありません。channel パラメータを API リクエストに追加するだけで、実装してから 1~2 日後にサポートポータルの使用状況レポートに、チャンネルごとの使用状況の結果の表示が始まります。チャンネルの実装先と使用状況の集計方法はユーザーが決めます。アプリケーションの使用状況を追跡するためにアプリケーションで channel パラメータを統合するかどうかは、リリース前に判断してください。

channel パラメータは次の形式を使用する必要があります。

  • ASCII 英数字の文字列にする必要があります。
  • ピリオド(.)、アンダースコア(_)、およびハイフン(-)の各文字を使用できます。
  • channel パラメータでは大文字と小文字は区別されません。大文字、大文字と小文字の混在、小文字の channel パラメータは同じ文字の小文字に統一されます。たとえば、CUSTOMER チャンネルの使用状況は customer チャンネルの使用状況と組み合わされます。

クライアント ID ごとに最大 2,000 個の個別チャンネルを実装できます。

channel パラメータを使用するには、クライアント ID を渡すために使用する client パラメータと一緒にリクエスト URL に含めます。

channel パラメータはアプリケーションごとに静的に割り当てる値にする必要があることに注意してください。パラメータを動的に生成したり、個人ユーザーを追跡するために使用してはいけません。