2015년 12월 버전 APNs 변경 사항 정리

Apple과 google 에서 제공하는 푸시 서비스는 모바일 게임 운영 중 공지 및 광고, 이벤트 홍보 등 다양한 용도로 활용되는 기능이다. 푸시는 가장 널리 퍼진 모바일 디바이스 플랫폼인 ios/android 모두에서 사용할 수 있으며, 게임이 실행중이지 않더라도 메시지를 전송할 수 있다. 또한 전화번호 등의 개인정보를 수집,관리하지 않고도 게임 유저들에게 필요한 정보를 알릴 수 있다. 반면, 메시지 전송을 위해서는 전적으로 Google/Apple 에서 제공하는 플랫폼을 사용할 수 밖에 없어 이를 위한 구현 및 관리, 업데이트가 필요하다는 단점도 있다.

2016년,(정확히는 2015년 연말경부터) Google 과 Apple 모두 새로운 푸시 서비스를 공개하였다. Google은 기존의 gcm 대신 firebase 와 통합된 푸시 서비스인 FCM을, Apple 은 새로운 프로토콜, 새로운 인증 방식을 적용한 푸시 서비스를 선보였다. 양쪽 모두 새로운 기능들을 많이 선보였지만, 테스트용 대시보드나 퍼널 분석 등 사용성 위주의 변경사항이 대부분인 FCM과는 달리 APNs는 연결 인증 방식 및 전송 프로토콜 등 기능 외 적인 부분에서도 많은 부분에서 변화가 있었다. 그 결과 기존 방식으로 APNs 에 메시지 전송 요청을 전송하는 어플리케이션 서버를 마이그레이션하기 위해서는 요청 전송 부분을 새로 만들어야만 한다.( 반면 Google은 https://developers.google.com/cloud-messaging/faq 에서 확인 가능한 것처럼 기존 프로토콜을 그대로 사용 가능하기에, 신규 기능을 사용하지 않는다면 url 교체 작업 정도면 충분하다. )

새로운 APNs의 변경점 중, 어플리케이션 서버 개발 및 운영과 관련하여 눈에 띄는 것들은 다음과 같다.

전송 가능한 메세지 최대 크기 증가

최대 전송 가능 메세지 크기가 2KB 에서 4KB 로 변경되었다. I18N 지원이나 추가 데이터 전송 등의 이유로 메세지 크기가 점점 커지는 경향이 있었는데 이러한 부분을 고려한 변경점으로 보인다.

토큰 기반 인증 지원

기존에는 APNs에 푸시 요청을 전송하려면 반드시 TLS 인증서 기반의 인증이 필요했다. 이러한 방식을 사용하기 위해서는 항상 인증서 갱신 주기를 신경 써야 하며, 개발(sandbox, development)환경/ 제품(production)환경에 사용되는 인증서를 구분해야 하는 등 신경 써야 할 것들이 많았다.

새로운 APNs에서는 인증서 기반의 인증을 사용하지 않고도 푸시를 전송할 수 있는 방법을 제공한다. 전송 요청 시마다 토큰을 같이 전달하는 방식이며, JWT( https://jwt.io/ ) 방식의 토큰을 사용한다. 토큰 생성에 필요한 key 는 애플 개발자 계정 페이지에서 얻을 수 있다.

기존의 인증서를 이용한 인증 역시 지원하므로 둘 중 하나를 선택해서 사용하면 된다.

이 인증 방식을 사용하면, 개발환경/제품환경에 관계 없이 푸시 전송을 요청할 수 있다. 또한 토큰 자체는 유효기간이 있지만, 토큰 생성에 사용되는 key는 유효기간이 없기 때문에 토큰 생성 기능을 한 번 구현해두면 갱신 등을 걱정할 필요 없이 계속 사용할 수 있다는 장점이 있다.

1
▲토큰 생성에 사용되는 key는 만료 기한이 없다.

제품(production) 인증서로 개발환경(sandbox, development) 대상 푸시 전송 가능

위에서도 언급했지만, 기존에는 제품 환경을 대상으로 푸시를 전송하는 경우와 개발 환경을 대상으로 전송하는 경우에는 별도의 인증서를 사용해야만 했다. 새로운 APNs에서는 제품 환경의 인증서를 이용하여 제품 환경과 개발 환경 모두에 푸시 전송 요청을 보낼 수 있다.

2
▲제품(production) 인증서로 개발 환경과 제품 환경 모두에 푸시를 보낼 수 있다.

전송 요청 프로토콜 변경

기존에 APNs에 전송 요청을 보낼 때는 tcp 로 전용 프로토콜을 통해 요청해야만 했다. 새로운 APNs는 HTTP/2 기반의 프로토콜을 사용한다.

HTTP/2 에 익숙하지 않으신 분들을 위해 간략히 설명하자면, HTTP/2 는 HTTP 1.1 과 비슷한 기능성을 지원하면서도 서버측에서의 응답 시간을 줄이는 것을 주된 목적으로 설계된 프로토콜이다. HTTP method 등 HTTP의 기본 기능은 최대한 바꾸지 않으면서 요청 생성/처리와 관련된 부분을 변경하였다. 예를 들면, 헤더에 인덱싱 개념을 도입하여 요청 자체의 크기를 줄이고 멀티플렉싱을 개념을 도입, 기존 HTTP 1.1 의 반응 속도를 떨어뜨리는 요인 중 하나였던 head-of-line-blocking 문제를 해결했다. head-of-line-blocking 문제란, 작업 시간이 오래 걸리는 작업이 진행 중이면 이미 처리가 끝났거나, 더 빨리 끝낼 수 있는 다른 작업들을 처리할 수 없는 상황을 말한다.

3

위의 그림에서, A의 요청에 대한 응답인 A’ 의 크기가 크거나 처리가 오래 걸리는 경우를 생각해 보자. 반대로 B’의 크기가 매우 작거나 빨리 처리할 수 있다면, 서버는 B’ 를 먼저 전송하고 클라이언트는 그에 대한 처리를 먼저 시작하는 편이 최적화에 도움이 된다. 하지만 HTTP 1.1 은 서버 측에서 요청을 받은 순서에 따라 응답을 보내야 한다고 규정하고 있으므로, 서버는 B’를 A’보다 나중에 보내야만 없다. 즉 B’ 는 A’에 의해 blocking 된 것이다.

반면 HTTP/2 에서는 여러 개의 요청을 별개의 스트림으로 나눠서 전송할 수 있다. 다른 스트림상의 요청은 위에서 언급한 전송 순서에 영향을 주지 않으므로 요청 A,B를 서로 다른 스트림을 이용해서 요청하면 서버에서는 먼저 처리가 끝난 B’를 먼저 전송할 수 있기에 B’는 A’에 의해 blocking 되지 않는다.

새로운 APNs에서는 이 멀티플렉싱 기능을 이용, 하나의 연결에서 다수의 요청을 동시에 전송할 수 있도록 지원하고 있다. 즉 여러 개의 디바이스를 대상으로 푸시 전송 요청을 날리려면 디바이스의 개수만큼 HTTP /2 요청을 보내야 한다. 위에서 설명한 토큰 인증을 사용할 경우, 요청 시마다 생성된 토큰을 포함하여 전송하여야 한다.

기존 방식과 비교했을 때 장점은, 우선 오류 발생 시 오류가 발생한 요청만 실패한다는 점이다. 기존 APNs의 경우, 다수의 전송 요청을 보낼 때 오류가 발생하면 해당 요청에 대한 오류 정보를 전송 후 바로 APNs측에서 연결을 종료했으며, 오류가 발생한 요청 이후의 모든 요청은 무시되었다. 따라서 오류 처리 시, 전송 요청이 어디까지 받아들여졌는지를 확인, 나머지 요청을 모두 재 전송하는 로직을 반드시 구현해야 했다. 반면 새로운 APNs에서는 문제가 있는 요청만 실패하며, 나머지는 모두 정상적으로 처리된다. 따라서 오류가 발생한 메세지에 대한 재전송만 신경 쓰면 된다.

두 번째 장점은 오류에 대한 좀 더 상세한 정보를 얻을 수 있다는 점이다. 기존 APNs에서는 요청 메세지 내의 형식 문제 등으로 오류가 발생한 경우 오류 코드 하나만을 반환하였는데, 오류 코드의 총 수가 10개 남짓으로 지나치게 단순하여 오류 원인을 파악하기 어려웠다. 새로운 APNs는 HTTP error code 및 error string을 동시에 제공, 오류 원인을 알아내기 쉬워졌다.

이 글을 작성하는 시점에, 새로운 APNs는 서비스 된 지 1년 이상이 지났다. 또한 Apple이 레거시 지원을 중요하게 여기는 회사는 아니기에, 신규 프로젝트 개발 시에는 물론이고 기존 방식의 APNs를 사용하여 서비스를 제공하고 있는 경우에도 새로운 APNs 사용을 고려할 필요가 있다. 변경점 중에는 프로토콜 외에 기능적인 변경도 있으며 푸시 서비스 운영에 영향을 줄 수 있는 변경들도 있기에 기존에 운영중인 프로젝트에 사용되는 푸시 기능도 마이그레이션하는 것을 권하고 싶다 .

아이펀팩토리 아이펀 디플로이 테크니컬 디렉터 민영기

답글 남기기

댓글을 게시하려면 다음의 방법 중 하나를 사용하여 로그인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중