출시 전 검사 목록

Google Cloud Console에서 클라이언트 ID를 관리할 수 있는 위치

프리미엄 플랜 클라이언트 ID 관리 기능은 지원 포털에서 지도의 사용자 인증 정보 페이지에서 서비스 계정 섹션에 있는 Cloud Console로 이전됩니다.

사용자 인증 정보 페이지의 새 클라이언트 ID 영역

참고: Google Maps Platform 프리미엄 플랜은 신규 가입이 불가능하며 신규 고객에게 제공되지 않습니다.

개발팀에 필수 리소스 액세스 권한이 있는지 확인

Google Maps Platform 프리미엄 플랜 환영 메일을 안전하게 보관

중요한 이유: 시작 메일은 Google Maps Platform 프리미엄 플랜 스타터 키트이며, 응급 키트가 될 수도 있습니다. 시작 메일에는 프리미엄 플랜을 사용하는 데 필요한 Google Cloud Console 프로젝트 ID, 클라이언트 ID와 암호화 키 등의 중요한 정보가 포함되어 있습니다. 또한 Google Maps API에 기술적 문제가 발생하는 경우 프리미엄 플랜 지원팀에 문의하는 데 필요한 모든 정보도 포함되어 있습니다.

Google Cloud Console 사용

중요한 이유: Google Cloud Console에서는 사용량 보고서, 뉴스 피드 및 개발자 리소스와 같은 정보에 액세스할 수 있습니다. 또한 Cloud Console에서는 개발 또는 출시 시에 기술적 문제가 발생하면 프리미엄 플랜 지원팀에 지원 기록을 제출할 수도 있습니다.

출시 전에 애플리케이션 유지 관리를 책임지는 모든 개발자에게 Cloud Console에 대한 액세스 권한을 제공하세요. 기술적 문제가 발생했을 때 Cloud Console에 액세스하면 개발팀 구성원이 지원팀에 문의하고, 지원팀이 조직 내의 적절한 이해관계자에게 연락할 수 있습니다. 예를 들어 지원팀이 애플리케이션에 장애를 일으킬 수 있는 비정상적인 트래픽이나 동작을 감지하면 여러분의 조직에 연락해야 할 수도 있습니다. 지원팀이 적절한 개발자에게 연락할 수 있는지에 따라 예상치 못한 시스템 중단이 발생하기도 하고 예방되기도 합니다.

알림 이메일 그룹 구독

중요한 이유: Maps API에서 개발과 변경사항에 대한 최신 정보를 얻으려면 다음 이메일 그룹 중 하나 이상을 구독해야 합니다.

  • google-maps-platform-notifications - Google Maps Platform API 및 웹 서비스의 기술 업데이트, 중단 알림, 플랫폼 기능 공지사항이 제공됩니다(매월 메시지 3~5개).
  • google-maps-js-api-v3-notify - Google Maps JavaScript API 신규 릴리스가 제공됩니다(매년 메시지 최대 4개).

관련 알림 피드 구독

중요한 이유: Maps API에서 개발과 변경사항에 대한 최신 정보를 얻으려면 FAQ에서 설명하는 방법을 따라 관련 알람 피드를 구독해야 합니다.

Google Maps Premier API 알림: 서비스 중단, 업데이트, 서비스 알림에 대한 다음 RSS 피드를 구독할 수도 있습니다.

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

지원 핫라인 준비

미국 고객의 경우: 1-877-355-5787, 미국 외 고객의 경우: +1 404-978-9282

중요한 이유: 핫라인을 이용하면 지원팀에 전화를 걸 수 있습니다. 각 국가의 번호는 Cloud Console에서 PIN과 함께 확인할 수 있습니다. 지원 핫라인을 사용하여 지원팀에 기술적 문제를 보고할 수 있지만 프로덕션 중단, 서비스 사용 중단 사례만 가능합니다. Google의 우선순위 수준은 다음 문서에 정의되어 있습니다.

애플리케이션 최적화

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와 사용 사례에 따라 요청을 허용하도록 방화벽을 구성합니다.

올바른 SSL 호스트 이름으로 API 로드

중요한 이유: SSL을 통해 Maps API를 로드하는 애플리케이션은 기존 호스트 이름인 https://maps-api-ssl.google.com이 아닌 https://maps.googleapis.com에서 로드해야 합니다.

Maps JavaScript API와 함께 사용하도록 SSL 도메인 승인

중요한 이유 Maps JavaScript API를 SSL 도메인과 함께 사용할 때는 HTTPS 도메인을 명시적으로 승인하여 요청이 거절되지 않게 해야 합니다. http://yourdomain.com을 승인해도 SSL에 해당하는 https://yourdomain.com이 자동으로 사용 설정되지는 않습니다. Cloud Console에서 클라이언트 ID 섹션으로 스크롤하여 승인된 도메인 목록을 확인하세요. 클라이언트 측 API를 SSL 도메인과 함께 사용하는 것과 관련된 오류를 해결하려면 페이지의 요소가 HTTP를 통해 로드되는지 확인하세요. 승인 문제해결 가이드를 참고하세요.

적절한 API 버전 선택

중요한 이유: 애플리케이션을 개발하기 전에 지원 중단되는 API 버전을 알고 있어야 합니다. 지원이 중단되지 않는 API 버전을 개발하면 개발 시간을 절약하고 지원이 중단된 버전을 사용할 수 없게 될 때 비용을 줄일 수 있습니다.

특히 Maps JavaScript API에서 사용하는 버전 관리 구성표를 이해하고 개발자의 환경에서 부적절한 API 버전을 잘못 사용하지 않도록 해야 합니다.

예를 들어 개발이나 테스트 환경에서는 API의 시험용 버전을 사용하는 것이 적절할 수 있으나 프로덕션 환경에서는 시험용 버전을 사용하지 않아야 합니다. Google의 SLA는 안정적인 API 버전에만 적용되므로 프로덕션 환경에서는 안정적인 버전만 사용해야 합니다.

Maps JavaScript API 버전 가이드를 참고하세요.

클라이언트측 디자인과 서버측 디자인 선택

중요한 이유: 클라이언트 측과 서버측 디자인 중 무엇을 선택하는 것은 아키텍처와 관련된 결정이며, 애플리케이션의 안정성과 확장성에 매우 중요합니다. 일반적으로 서버측 디자인은 기록을 오프라인으로 사전/사후에 처리할 때 사용해야 합니다(애플리케이션 외부에 있음). 반면 클라이언트측 디자인은 사용자와 상호작용하는 부분에 사용해야 합니다(사용자가 제출한 요청을 실시간으로 처리).

클라이언트측 디자인을 사용해야 할 곳에 서버측 디자인을 배포하는 것은 할당량 초과 때문에 애플리케이션에서 장애가 발생하는 주요 원인입니다. 서버측 호출을 사용하는 애플리케이션을 디자인하거나 출시하기 전에 지오코딩 전략을 참고하시기 바랍니다.

사용 할당량 최적화

중요한 이유: 애플리케이션에서 Maps API 크레딧이라는 이름의 할당량을 사용하는 방식을 이해하면 비용을 줄일 수 있습니다. 예를 들어 Maps JavaScript API를 사용하는 경우 애플리케이션은 지도 로드를 할 때마다 Maps API 크레딧을 사용합니다. 프리미엄 플랜 사용 요금 및 한도 가이드를 참고하세요.

웹 서비스 할당량 사용 관리

중요한 이유: 기본적으로 공유 웹 서비스 할당량은 일일 무료 요청 100,000건으로 설정됩니다. API별 할당량 분석에 대한 자세한 내용은 사용량 한도 문서를 참고하세요. Cloud Console에서 할당량을 확인하거나 할당량 문제가 있는 경우 지원 기록을 제출하세요.

서비스를 출시하기 전에 다양한 할당량 관련 오류(예:OVER_QUERY_LIMIT ,User Rate Limit Exceeded)를 이해하고, 할당량을 초과했을 때 이러한 오류에 대응할 수 있도록 애플리케이션에 적절한 로직을 설정해야 합니다. 먼저 사용량 한도 FAQ를 읽어보세요. 각 API에서 반환하는 상태 코드에 대한 자세한 내용은 해당 API의 개발자 가이드를 참고하세요. 예를 들어 Directions API 상태 코드 가이드를 참고하세요. 이러한 개념을 이해하고 구현하면 허용된 할당량을 초과하여 애플리케이션이 Google에서 차단되거나 장애를 일으킬 가능성이 현저히 줄어듭니다.

앱에서 부하 테스트 수행

중요한 이유: 애플리케이션의 부하 테스트를 사용하여 Maps API 할당량을 초과하지 않고 대량의 요청을 처리할 수 있는지 확인합니다.

라이브 Google 서비스에 대해 부하 테스트를 실행하면 애플리케이션이 허용된 할당량을 초과하여 Google에서 애플리케이션을 차단합니다. Google Maps Platform은 대용량을 제공할 수 있습니다. 2012년 Santa Tracker는 초당 1,600,000개 요청을 처리했습니다. 따라서 Google 서비스에 대한 부하 테스트는 수행하지 않아도 됩니다. 대신 애플리케이션 부하 테스트로 Maps API에서 제공하는 할당량을 초과하지 않고 대량의 요청을 처리할 수 있는지 확인해야 합니다. 예: Geocoding API의 할당량이 20 QPS(초당 쿼리)라면 애플리케이션 부하 테스트로 Geocoding API에 20 QPS 이상을 전송하지 않고 600 QPS를 처리할 수 있는지 확인해야 합니다.

이 작업을 안전하게 하려면 가상(가짜) API를 상대로 부하 테스트를 수행해야 합니다. 가상 API는 Google Maps Platform을 동원하지 않고도 대량의 요청을 흡수하여 유효한 응답을 보내는 서비스입니다. 따라서 Google Maps Platform에서 차단당할 염려 없이 애플리케이션 부하를 테스트할 수 있습니다.

작은 Google App Engine 애플리케이션으로 구현된 가상 API 예시를 참고하세요. (appengine.google.com)에 등록한 후 자체 App Engine 애플리케이션에 이 예시를 업로드하면 maps.googleapis.com이 아닌 자체 애플리케이션에서 요청을 전송하게 할 수 있습니다.

대부분의 경우 기본(무료) 할당량으로도 Maps API 웹 서비스에서 제공하는 할당량 이상으로 애플리케이션 부하를 테스트할 수 있습니다. 애플리케이션에서 올바른User-Agent 헤더를 설정하여 응답 압축을 사용 설정했는지 확인하세요. 일반 텍스트(JSON/XML) 응답을 지원하는 App Engine 애플리케이션에서 대단히 중요한 문제인 대역폭의 효율적인 사용을 보장하려면 반드시 필요합니다. App Engine 애플리케이션에 더 많은 할당량이 필요하다면 결제를 사용 설정하면 됩니다. 그러나 이런 경우는 매우 드뭅니다.

표준에서 프리미엄 라이선스로 애플리케이션 마이그레이션

API 요청에 클라이언트 ID 또는 API 키 포함

중요한 이유: 애플리케이션에서 할 수 있는 가장 중요한 일은 API 요청에 클라이언트 ID(gme-yourclientid) 또는 API 키(AIzaSyBdVl-cTICSwYKrZ95SuvNw7dbMuDt1KG0와 유사)를 포함하는 것입니다. 클라이언트 ID 또는 API 키는 요청을 Google Maps Platform 프리미엄 플랜 요청으로 식별합니다.

프리미엄 플랜에서 제공하는 기능을 사용하려면 애플리케이션에 클라이언트 ID 또는 API 키를 포함해야 합니다. 기술 지원을 받고 애플리케이션이 SLA를 준수하는지 확인하기 위해서도 애플리케이션에 클라이언트 ID 또는 API 키를 포함해야 합니다.

대부분의 API에서는 클라이언트 ID 또는 API 키 중에서 어느 것을 사용할지 선택할 수 있습니다. 클라이언트 ID는 조직의 기본 담당자에게 발급된 환영 메일에 포함되어 있습니다. Google Cloud Console에서 자체 API 키 또는 키를 생성할 수 있습니다.

자세한 내용은 인증 및 승인 가이드를 참고하세요.

API 키 또는 클라이언트 ID 중 하나만 API 요청에 포함

중요한 이유: Maps JavaScript API를 올바르게 로드하거나 다른 Google Maps API에 요청을 보내려면 클라이언트 ID 또는 API 키 중 하나만 포함해야 합니다. 클라이언트 ID를 사용하기로 했다면 모든 key 매개변수를 제거해야 합니다. 요청에 클라이언트 ID와 키가 모두 포함되어 있다면 요청이 실패합니다.

API별로 프리미엄 플랜 요청의 형식을 올바르게 지정하는 자세한 방법은 인증 및 승인 가이드를 참고하세요.

클라이언트 ID를 사용할 때는 Maps JavaScript API와 함께 사용하도록 도메인을 승인해야 합니다.

중요한 이유: 권한이 없는 사이트가 클라이언트 ID를 사용하는 일을 방지하고자, Maps JavaScript API를 사용할 때는 클라이언트 ID를 사용할 모든 사이트에 대해 지원팀에서 모든 도메인을 승인해야 합니다. (클라이언트 ID가 아닌 API 키를 사용한다면 URL 등록은 하지 않아도 됩니다.) 클라이언트 ID를 사용하도록 승인된 URL과 클라이언트 ID를 사용하려고 시도하는 사이트가 일치하지 않으면 해당 사이트는 클라이언트 ID로 API를 사용하지 못합니다. 언제든지 도메인을 승인할 수 있습니다. 출시 전에 모든 사이트의 도메인을 승인했는지 확인하세요.

Cloud Console에서 사용자 인증 정보 페이지로 이동한 다음 클라이언트 ID 섹션으로 스크롤하여 승인된 도메인 목록을 확인할 수 있습니다.

승인 문제의 경우에는 케이스를 제출하기 전에 승인 문제 해결 가이드를 살펴보시기 바랍니다.

클라이언트 ID를 사용하는 경우 개인 암호화 키로 생성한 서명으로 웹 서비스 요청에 서명

중요한 이유: 비공개 암호화 키는 서명을 생성하는 데 사용하며, Google에 요청의 출처가 신뢰하는 소스임을 알려줍니다. Google의 Web Service API에서는 클라이언트 ID를 인증에 사용하면 요청에 디지털 서명을 추가해야 합니다. 그러면 요청의 보안이 한층 강화되어 클라이언트 ID와 관련된 할당량을 지키는 데 도움이 됩니다. 암호화 키(예: vNIXE0xscrmjlyV-12Nj_BvUPaw=)는 조직의 기본 담당자에게 발급된 환영 메일에 포함되어 있습니다.

참고: 암호화 키는 서명을 생성하는 데 사용합니다. 암호화 키를 요청에 서명으로 추가하진 마세요. 암호화 키는 ATM 핀 번호와 유사합니다. 이 키는 계정에 액세스하기 위한 인증 수단으로 사용되며 공개적으로 공유하거나 신뢰할 수 없는 소스에 표시되어서는 안 됩니다. 올바르게 서명되지 않은 프리미엄 플랜 웹 서비스 요청은 Google 서버에서 거부되므로 출시 전에 애플리케이션에서 요청을 적절하게 서명해야 합니다. 인증 및 승인 가이드를 참고하세요.

애플리케이션 사용량 추적

중요한 이유: 프리미엄 플랜 고객은 전송한 요청, 사용한 크레딧, 반환된 오류 등을 포함하는 애플리케이션 사용에 대한 자세한 보고서에 액세스할 수 있습니다. 보고서 가이드를 참고하세요.

channel 매개변수는 선택적 매개변수로, 각 애플리케이션에 별개의 채널을 할당하여 클라이언트 ID로 사용량을 추적합니다. channel 매개변수는 클라이언트 ID에 등록하지 않아도 됩니다. API 요청에 channel 매개변수를 추가하면 구현 후 1~2일이 지나야 채널당 사용 결과가 지원 포털 사용량에 나타납니다. 채널을 구현하는 장소는 사용자가 결정하며, 그에 따라 사용량 집계 방법도 달라집니다. 애플리케이션 사용량을 추적할 channel 매개변수를 애플리케이션에 통합하려면 출시 전에 결정하세요.

channel 매개변수는 다음 형식을 사용해야 합니다.

  • ASCII 영숫자 문자열이어야 합니다.
  • 마침표(.), 밑줄(_), 하이픈 (-)이 허용됩니다.
  • channel 매개변수는 대소문자를 구분하지 않습니다. 대문자, 대/소문자 혼합, 소문자 channel 매개변수는 소문자 매개변수에 통합됩니다. 예를 들어 CUSTOMER 채널의 사용량은 customer 채널의 사용량과 통합됩니다.

클라이언트 ID당 최대 2,000개 채널을 구현할 수 있습니다.

channel 매개변수를 사용하려면 클라이언트 ID를 전달하는 데 사용하는 client 매개변수와 함께 요청 URL에 포함하세요.

channel 매개변수는 애플리케이션별로 정적으로 할당된 값이어야 합니다. 이 값은 동적으로 생성되어 개별 사용자를 추적하는 데 사용해야 합니다.