Google Cloud コンソールでのクライアント ID の管理場所
プレミアム プランのクライアント ID 管理機能は、Cloud コンソール で Google Maps Platform の [認証情報] ページの下部にある [クライアント ID] セクションにあります。
URL 承認やクライアント ID 署名シークレットの管理など、クライアント ID に関するその他のタスクには、別の [クライアント ID] ページからアクセスできます。このページには、[クライアント ID] セクションの右端にある 編集アイコンをクリックすることでアクセスできます。
注: 現在、Google Maps Platform プレミアム プランは、新規お申し込みまたは新規お客様のご利用を受け付けていません。
チームが必要なリソースにアクセスできるようにする
Google Cloud コンソールを使用する
重要な理由: Google Cloud コンソールでは、使用状況レポート、ニュース フィード、デベロッパー向けリソースなどの情報にアクセスできます。さらに重要なのは、開発中やリリース時に技術的な問題が発生した場合、Cloud コンソールから Google Maps Platform のサポートチームにサポートケースを提出できることです。
リリース前に、アプリケーションのメンテナンスを担当するすべてのデベロッパーが Cloud コンソールにアクセスできるようにします。Cloud コンソールにアクセスすると、技術的な問題が発生した際に、チームのメンバーからサポートに問い合わせることができるようになるだけでなく、サポートチームから問い合わせ元組織の適切な関係者に連絡することも可能になります。たとえば、アプリケーションの停止につながる異常なトラフィックや動作が見つかったとします。このような場合、サポートチームから問題が発生した組織への連絡が必要になることがあります。サポートチームから適切なデベロッパーに連絡を取れるかどうかによって、アプリケーションの停止という予期せぬ結果を招くか、停止を避けることができるかの分かれ目になることがあります。
通知メールの配信登録を行う
重要な理由: Maps API 全体の開発と変更に関する最新情報を確実に把握できるよう、以下の通知メールの配信登録を行うことをおすすめします。
- google-maps-platform-notifications: Google Maps Platform API とウェブサービスに関する技術的な最新情報、サービス停止に関する通知、プラットフォームの機能に関するお知らせ(毎月 3〜5 件)を提供しています。
- google-maps-js-api-v3-notify: Google Maps JavaScript API の新しいリリース(年間最大 4 件のメッセージ)を提供しています。
アプリケーションを最適化する
Google Maps Platform サービスにアクセスできるようにファイアウォールを設定する
重要な理由: Google Maps Platform サービスではさまざまなドメインを使用します。中には *google.com
ドメインに属していないドメインもあります。制限が厳しいファイアウォールに保護されている場合、各 Maps API サービスが使用するドメインへのアクセスを許可することが重要です。このようなドメインへのアクセスをファイアウォールが許可しない場合、API リクエストが失敗し、アプリケーションが停止する可能性があります。詳しくは、Maps API によって使用されるドメインの完全なリストをご確認ください。
これらのドメインに関連付けられた IP アドレスは静的なものではありません。そのため、IP アドレスでのファイアウォール制限の管理はおすすめしません。
注: Google Maps Platform サービスは、着信トラフィックと発信トラフィックにポート 80(http) と 443(https) を使用します。これらのサービスは、GET、POST、PUT、DELETE、HEAD の各リクエストも必要とします。API とユースケースに応じて、これらのポート経由のトラフィックを許可し、リクエストを許可するよう、ファイアウォールを設定します。
Maps JavaScript API で使用する SSL ドメインを承認する
重要な理由: Maps JavaScript API を SSL ドメインで使用する場合は、明示的に HTTPS ドメインを承認して、リクエストが拒否されないようにすることが大切です。なお、http://yourdomain.com
を承認しても、SSL の同等の機能の https://yourdomain.com
が自動的に有効になるわけではありません。[クライアント ID] セクションまでスクロールして、Cloud コンソールで承認済みドメインのリストを確認します。SSL ドメインでのクライアント側 API の使用に関連するエラーのトラブルシューティングを行うには、ページの要素が HTTP 経由で読み込まれるかどうかをチェックします。詳しくは、承認のトラブルシューティングのガイドをご覧ください。
API の適切なバージョンを選択する
重要な理由: アプリケーションを開発する前に、すでに非推奨となっている API のバージョンを確認することが大切です。サポート対象のバージョンの API を対象に開発を進めておけば、サポートを終了したバージョンが利用できなくなった後の工程にかかる開発時間とコストを削減できます。
特に、Maps JavaScript API で使用される API のバージョニング スキームを理解し、環境内で不適切なバージョンの API を誤って使用しないことも重要です。
たとえば、開発環境やテスト環境では、試験運用版の API を使用するのが適していても、本番環境では試験運用版を使用しないことを強くおすすめします。SLA は安定したバージョンの API のみに適用されるため、本番環境では安定したバージョンのみを使用してください。
詳しくは、Maps JavaScript API のバージョンに関するガイドをご覧ください。
クライアント側とサーバー側との設計の選択
重要な理由: クライアント側のアプローチとサーバー側のアプローチのどちらを選択するかによって、アーキテクチャが決まります。そのため、アプリケーションの安定性と拡張性にとってはこの選択が極めて重要になります。全般的に見て、レコードの処理前後はオフラインにする(アプリケーションの外部で処理する)場合は、サーバー側のアプローチを使用します。これに対して、アプリケーションの中でユーザーと対話する(ユーザーが送信するリクエストをリアルタイムで処理する)部分にはクライアント側のアプローチを使用します。
クライアント側のアプローチを使用すべき状況で代わりにサーバー側のアプローチを採用すると、割り当て超過を引き起こし、アプリケーションが機能しなくなります。サーバー側の呼び出しを使用するアプリケーションを設計またはリリースする前に、ジオコーディング戦略に関するドキュメントを確認することを強くおすすめします。
割り当ての使用状況を最適化する
重要な理由: アプリケーションが割り当てを消費する方法(Maps API クレジット)を理解すると、支払う費用を削減できます。たとえば、Maps JavaScript API を使用している場合、アプリケーションは地図の読み込みごとに Maps API クレジットを消費します。プレミアム プランの使用レートと使用制限に関するガイドをご覧ください。
ウェブサービスの割り当て使用状況を管理する
サービスをリリースする前に、割り当て関連のさまざまなエラー(例: OVER_QUERY_LIMIT
、User Rate Limit
Exceeded
)を理解し、割り当て超過になった場合にこのようなエラーに対応できるよう、アプリケーションに適切なロジックを設定しておくことが重要です。まずは、使用制限に関するよくある質問をご確認ください。各 API から返されるステータスコードの情報は、該当する API のデベロッパー ガイドをご確認ください。たとえば、Directions API のステータス コードに関するガイドがあります。これらの概念を理解してから実装すると、アプリケーションが許容割り当てを超えたり、Google によってブロックされたり、機能が停止したりする可能性が大幅に減少します。
アプリでロードテストを実行する
重要な理由: アプリケーションのロードテストを使用すると、Maps API の割り当てを超えずに大量のリクエストを処理できるようになります。
Google Maps Platform では大量のトラフィックを処理できますが、実際の Google サービスに対してテストを行うと、アプリケーションに許容されている割り当てを超過し、Google によってブロックされる場合があります。また、負荷テストによって発生した使用料金についても、お客様の負担になります。
代わりにアプリケーションの負荷テストを行って、アプリケーションが Maps API の割り当てを超過したり、Google によってブロックされたりすることなく、大量のリクエストを処理できることを確認します。これを安全に実現するには、負荷テストをモック(疑似)API に対して実施します。モック API とは、Google Maps Platform を関与させずに、大量のリクエストを受け入れて有効なレスポンスを返すことができるサービスです。例: Geocoding API の割り当てが 3,000 QPM(1 分あたりのクエリ数)の場合、アプリケーションのロードテストでは、Geocoding API に 3,000 QPM を送信しなくても、90,000 QPM など、はるかに大量のリクエストを処理できるかをチェックする必要があります。
重要な負荷テストを行う場合は、Google サポートにお問い合わせのうえ、テストを予定していることお知らせください。