Apple Maps Server API소개

♪ 잔잔한 힙합 연주 음악 ♪ ♪ 모두 안녕하세요 제 이름은 Ankur Soni입니다 이곳 Apple의 Maps Services 팀 엔지니어링 매니저입니다 오늘 우리가 살펴볼 건 지도 개발자 환경에 나올 흥미진진한 신규 기능들입니다 그럼 시작해보죠 지도 앱은 전 세계 Apple 고객들에게 다양한 최종 사용자 체험을 제공합니다 우린 개발자들에게 권한을 부여해서 그들의 앱과 웹 사이트에 멋진 지리적 위치 체험을 만들 게 합니다 MapKit와 MapKit JS 제품들로요 그런데 Apple Maps 개발자 제품은 예전부터 고객 중심 성향이 강했습니다 우린 여러분의 멋진 피드백을 주의해서 경청해왔습니다 여러분은 성능이나 힘을 양보하지 않고 MapKit에 있는 자신의 데이터를 늘릴 방법을 원하셨습니다 따라서 우리 환경의 개선을 위해 Apple Maps Server API를 도입하게 되어 기쁩니다 우린 네 가지의 신규 API를 도입합니다 지오코딩 리버스 지오코딩, 검색 도착 예정 시간, 즉 ETA입니다 이 API들은 다양한 이용 사례를 처리하는 데 도움이 되는 동시에 지도를 여러분의 애플리케이션에 통합시켜줍니다 Geocoding API로 여러분은 주소를 지리적 좌표 즉, 위도 및 경도로 변환할 수 있습니다 마찬가지로 Reverse Geocoding으로 그 반대를 할 수 있습니다 지리적 좌표에서 주소로 가는 거죠 Search API로는 사용자들에게 검색 문자열을 입력할 능력을 부여해서 기업, 관심 장소 등과 같은 장소들을 발견하게 할 수 있습니다 여러분은 자기 데이터의 일부를 덮어씌워서 사용자에게 제시하고 싶을 수 있습니다 ETA API로 여러분은 고객들이 여러분의 사업체가 그들에게서 얼마나 멀리 있는지 감을 잡게 하거나 가장 가까운 지점을 찾는 계산을 하게 할 수 있습니다 그 가능성은 무한합니다 세 가지 중요한 이유로 여러분은 서버 API를 반길 겁니다 여러분은 이제 MapKit MapKit JS, 그리고 새로 나온 Apple Maps Server API를 활용해서 매끄러운 체험을 전달할 수 있어요 이는 여러분의 애플리케이션 아키텍처를 단순화해서 완전한 Apple Maps 스택을 여러분에게 제공합니다 이는 여러분의 삶을 훨씬 편하게 해줄 겁니다 저한테는 확실히 도움이 됐어요 그런데 전 편향되긴 했죠 다음 장점은 네트워크 호출의 감소입니다 많은 경우 우리는 다음과 같은 상황에 처하는데 iPhone, iPad 같은 우리 고객들의 기기와 웹 사이트 등등에서 반복적이고 불필요한 요청을 하는 상황입니다 서로 다른 사용자 기기에서 돌아가는 앱에서 여러분이 동일한 주소를 여러 번 반복해서 찾아보고 있을 수도 있죠 이는 많은 네트워크 호출과 대역폭 낭비를 유발합니다 이런 흔한 작동을 서버에 위임하고 서버 API를 써서 벡 엔드에서 한 번만 하면 애플리케이션의 대역폭 소모를 줄일 수 있을 겁니다 이것의 긍정적 부수 효과는 이제 여러분의 애플리케이션도 전력 효율적이란 겁니다 Apple Maps Server API를 써서 일부 프로세싱이 이제 서버로 위임됐으니까요 이제 이 API 중 일부를 활용해보도록 하죠 우리가 여러분의 점포 위치 탐지기 애플리케이션을 위한 이 연락처 카드를 구축한다고 가정해보죠 여기에 세 군데의 점포가 있는데 그들의 주소와 고객 위치에서의 거리가 보입니다 이 사례에서는 고객이 자신의 위치를 제공했다고 가정하겠습니다 일단은 이 연락처 카드 중 하나를 구축하는 일에 집중해봅시다 이 주소들이 만화책 가게의 위치를 저장하고 알려주는 서버에 있다고 가정하겠습니다 이걸 구축하는 방법은 많지만 잠시 동안 이 신규 서버 API가 없다고 가정해보죠 기본적인 아키텍처는 어떤 모습일까요? 클라이언트 애플리케이션은 이 데이터를 어떻게 얻을까요? 이 도표에서 우리 애플리케이션은 서버에 호출해서 점포 주소 목록을 얻습니다 백 엔드 서버는 여러분의 클라이언트 기기에 점포 주소 목록을 돌려줍니다 이 사례에서는 서버 API가 없으니 이제 클라이언트 애플리케이션은 그 주소에 다양한 동작을 해야 연락처 카드를 구축할 수 있습니다 하나의 작업을 하기 위해 클라이언트는 다양한 백 엔드 서비스에 다수의 호출을 해야 할 수도 있습니다 여기에서는 클라이언트 앱이 Apple Maps Server에 직접 호출하는 걸 볼 수 있습니다 MapKit와 MapKit JS 둘 중 하나를 사용해서요 클라이언트와 백 엔드 사이의 이런 과한 주고받기는 애플리케이션의 성능과 스케일에 불리한 영향을 미칠 수 있습니다 일반적으로 지연 시간이 긴 무선 통신망 상에서 이런 방식으로 개별 요청을 사용하는 건 비효율적이고 연결의 단절이나 불완전한 요청이란 결과로 이어질 수 있습니다 각각의 요청은 병행해서 이뤄질 수 있지만 애플리케이션은 요청별로 데이터를 보내고 기다리고 처리해야 하는데 그걸 모두 별도의 연결에서 해서 실패할 가능성이 높아집니다 마지막으로 클라이언트에서의 모든 반응을 여러분이 합쳐야 합니다 그리고 이런 호출들이 일어나는 동안 여러분은 사용자에게 스피너를 보여주고 있습니다 게다가 클라이언트 기기는 이런 추가 호출들에 대해 더 많은 대역폭과 전력을 사용합니다 그건 좋은 사용자 체험이 아니죠 이제 Apple Maps Server API에 접근권이 있는 모델 아키텍처를 살펴보도록 하죠 여러분은 백 엔드 서버를 클라이언트와 서비스 사이의 과한 주고받기를 줄이기 위한 관문으로 쓰기 시작해도 됩니다 이전과 마찬가지로 여기에서 여러분의 클라이언트에서 표시할 점포의 목록을 우리가 요청합니다 다음으로 우린 서버에서 지오코딩을 해달라고 요청합니다 그리고 우린 Apple Maps Server에 있는 API별 반응을 수신합니다 만화책 서버는 각 서비스의 반응을 취합하고 그 반응을 애플리케이션으로 보냅니다 이 패턴은 애플리케이션이 백 엔드 서비스에 하는 요청의 수를 줄여줄 수 있고 지연 시간이 긴 네트워크 상에서의 애플리케이션 성능을 향상시켜줍니다 요약하자면 여러분의 클라이언트는 서버에 한 번의 호출을 해서 점포들의 목록을 얻습니다 그런 다음 여러분의 서버는 힘든 일을 해서 적절한 API 호출을 하고 사용자에게 제일 잘 어울리는 반응을 구성해줍니다 그럼 이제 사례 연구 예로 돌아가보죠 우린 Geocoding과 ETA API를 사용해서 점포까지의 거리를 얻을 겁니다 우린 Geocode API를 사용해서 점포 주소의 위도와 경로를 찾아내고 이를 나중에 ETA 계산에 사용할 겁니다 이 사례에서 먼저 우린 만화책 가게의 주소를 갖고 URL 인코딩을 하겠습니다 다음으로는 Geocode API를 써서 이 URL 인코딩된 주소를 쿼리 파라미터로 전달하겠습니다 지금은 인증 세부 사항을 건너뛰고 슬라이드 몇 장을 넘긴 다음 돌아오겠습니다 반응에서는 돌려받은 주소에 대한 위도와 경도를 볼 수 있습니다 우린 동일한 과정을 반복해서 고객 주소의 위도와 경도를 찾아낼 겁니다 이는 나중에 ETA 계산에 사용될 겁니다 보시다시피 이 반응에는 필드가 더 많이 있습니다 아래 리소스 섹션에 상세한 문서의 링크를 넣겠습니다 이제 우린 Geocode API에서 얻은 데이터로 ETA API에 출발지와 도착지를 정할 수 있습니다 앞에서 말씀드렸듯이 우리에겐 출발지 위도, 경도와 도착지 위도, 경도가 있습니다 필요하면 최대 열 군데의 도착지를 명시할 수 있습니다 우린 그걸 ETA API에 넣어줍니다 출발지와 도착지의 쿼리 파라미터로요 그것들은 URL 인코딩이 되어 있죠 API에 대한 반응은 ETA의 목록입니다 제공된 각 도착지에 하나씩이죠 이 경우에는 우리가 도착지를 한 곳만 제공했으니 하나만 있습니다 이 사례에서 우린 점포까지의 거리를 계산하기 위한 distanceMeters에 관심이 있습니다 이걸로 우리에겐 필요한 요소들이 다 있어요 점포 주소와 사용자가 점포에 도착하기까지의 거리입니다 여러분은 영업 시간 같은 자신만의 점포 정보로 이 데이터를 보강하거나 덮어씌우기로 할 수도 있습니다 이런 식으로 여러분은 다양한 서버 API를 활용해서 자신의 애플리케이션을 구축할 수 있습니다 다른 API의 경우 이 발표 아래 링크에 있는 문서를 참고해주세요 설명한 적이 없는 결정적인 요소는 인증입니다 모든 Apple Maps Server API는 인증됩니다 여러분이 MapKit JS를 사용한다면 절반은 이미 해놓은 것과 같죠 Apple Maps Server API는 인증에 있어서 MapKit JS와 동일한 메커니즘을 씁니다 먼저 여러분은 개발자 계정에서 개인 키를 다운받습니다 그런 다음 이 키를 사용해서 JWT 형식의 Maps 인증 토큰을 생성합니다 생성 방법에 관한 자세한 내용을 담은 문서 링크는 아래에 있습니다 그리고 토큰 API를 사용해서 이 Maps 인증 토큰을 교환하여 Maps 접근 토큰을 얻을 수 있습니다 우린 백 엔드에서 Maps 인증 토큰을 인증한 다음 Maps 접근 토큰을 되돌려 보냅니다 이건 JWT 형식이고 모든 API의 상호 작용에 사용됩니다 이 접근 토큰은 30분마다 새로 고침이 되어야 합니다 여기 강조된 과정을 반복하는 방식으로요 이제 인증 흐름이 어떤 모습인지 살펴봤으니 다음은 토큰 API를 사용해서 접근 토큰을 가져오는 방법에 관한 간단한 사례입니다 우린 여기에서 토큰 API를 사용합니다 Maps 인증 토큰을 헤더로 전달하고요 여러분은 Maps 접근 토큰을 돌려받는데 그걸 API에 접근하는 데 사용할 수 있습니다 그건 JWT 형식이고, 거기엔 만료와 발행 시기 등과 같은 표준 필드들이 있습니다 편의를 위해 expiresInSeconds 필드는 토큰의 유효 기간을 보여줍니다 이 경우에는 30분입니다 명심해야 할 건 Maps 인증 토큰은 Maps 접근 토큰과는 다르다는 겁니다 Maps 인증 토큰은 교환해서 30분 동안 지속되는 Maps 접근 토큰을 얻어 서버 API에 접근하는 겁니다 Maps 접근 토큰이 있는 API 상호 작용은 어떤 모습인지 잠시 살펴보겠습니다 우린 Maps 접근 토큰을 서버 API 호출과 함께 전달합니다 그건 API 호출에 헤더로 추가됩니다 슬라이드 몇 장 전에 봤던 것처럼요 Apple Maps Server는 Maps 접근 토큰을 인가합니다 일단 인가가 성공하면 Apple Maps Server는 API 반응으로 대응합니다 이제 API와 인증을 다뤘으니 사용량 제한을 설명하겠습니다 엄청난 권력에는 엄청난 책임이 따릅니다 그러니 여러분의 할당량을 현명하게 사용하세요 가능한 API 호출 수에 일일 한도가 있습니다 그건 큽니다 하루 동안 총 서비스 호출의 할당량은 25,000회입니다 명심하세요, MapKit JS와 서버 API를 통한 서비스 호출은 동일한 할당량을 사용합니다 할당량이 더 필요하면 우리한테 연락해주세요 그럼 그 많은 걸 어떻게 알고 있냐고요? Maps 개발자 대시보드에서 사용량 통계를 볼 수 있습니다 MapKit JS 사용하시는 분 있나요? 그분들에게 이건 아주 낯익어 보일 겁니다 서버 API 사용량은 Services 범주로 분류되는데 그게 여기 강조되어 있는 게 보입니다 일일 할당량이 초과되면... 서버 API 호출이 25,000회를 초과한다는 건데요 우린 신규 서비스 호출을 거부하기 시작하고 HTTP 상태 429로 대응합니다 그건 요청이 너무 많다는 뜻이죠 그런 경우에는 반드시 앱 체험이 적절히 조절해서 저하되도록 해야 합니다 드물겠지만 여러분의 서비스가 요청하는 횟수가 특이하게 많으면 그건 코드나 인프라의 오류 때문일 수도 있습니다 HTTP 상태 429를 받는 것도 가능하고요 HTTP 429를 받으면 요청하는 걸 그냥 반복 루프 상태가 되지 않게 하는 게 중요합니다 그보다 좋은 접근법은 시도들 사이의 지연 시간을 늘리고 재시도하는 겁니다 이런 접근법을 지수 백오프라 합니다 그럼 오늘 우리가 배운 건 뭘까요? 우린 네 가지 서버 API를 새로 공개합니다 이 API는 지오코딩 리버스 지오코딩 검색, ETA입니다 이 API들을 MapKit 및 MapKit JS와 함께 사용하면 Apple Maps 스택을 사용해서 앱을 더 잘 구축하는 데 도움이 될 겁니다 불필요하고 반복적인 호출을 최적화할 수 있습니다 Apple Maps Server API를 사용해서 그 작업들을 백 엔드 서버에 위임해서요 이 API들에 대한 일일 할당량은 25,000회이고 MapKit JS 서비스 사용량과 함께 씁니다 여기까지 여러분을 위한 신규 Apple Maps Server API였습니다 여기에서 언급했던 다른 세션들과 상세한 문서는 아래 링크에서 꼭 확인하세요 여러분이 그걸 활용하는 모습을 보기를 많이 기대합니다 감사합니다 ♪