[U.O.S] U.O.S Notification 구현 방법에 대한 토론

[ByteAurora]

U.O.S Notifiation

목적

• 현재 U.O.S에서는 매장과 고객간의 연결을 위해 소켓 통신과 FCM(Firebase Cloid Messaging)을 사용하고 있습니다. 최근 FCM대신 MQTT(Messaging Queue Telemetry Transport)를 이용해서 Notification을 구현하자는 이야기가 있었습니다. 때문에 각 방법의 장단점에 대해서 이야기하고 현재 방식(FCM)으로 진행할지, 아니면 새로운 방식(MQTT)으로 진행할지에 대해서 결정하고자 합니다.

기존 구현 방식

• 현재 Pos로부터 Mobile App까지 Notification이 오는 과정은 다음과 같습니다.

  상품 주문 접수 완료 -> Mobile에서 Service로 FCM Notification 수신 대기 -> 상품준비 완료 시 Pos에서 FCM Notification 전송

FCM(Firebase Cloud Messaging)

장점

• Google이 지원하고 있어 Android Notification 통신에 대한 부분에서 안정성이 있으며 트래픽에 상관없이 무료로 사용 가능.

• Notification 서버를 직접 구축할 필요 없이 FCM에 연결하면 바로 사용할 수 있기 때문에 개발 속도와 편이성이 좋음.

단점

• Notification 서버로 FCM을 사용하기 때문에 데이터가 FCM을 통할 수 밖에 없으므로 데이터에 대한 보안성(여기서 보안성이란 타 기업에게 정보가 노출되는 것을 말함)이 강조될 경우 자체 Notificatoin 서버를 구축하는 것이 유리함.

MQTT(Messaging Queue Telemetry Transport)를 이용한 자체 Notification 서버 구축

장점

• Notification을 서버에서 직접 구현함으로써 데이터가 FCM과 같이 외부 서버를 거치지 않아 보안성을 높일 수 있고 FCM에서 제공하지 않는 기능을 직접 만들어서 추가 가능함.

단점

• 자체 Notification 서버 구축에 많은 시간이 필요하고 여러 예외에 대한 처리도 직접 구현해주어야 함.

• Mobile과 Notification 서버 간에 이루어지는 통신 안정성이 FCM을 활용하는 것보다 떨어질 수 있음.

아래 링크에서 Firebase와 MQTT에 대한 개발자들의 의견을 확인할 수 있습니다

• Google Cloud Messaging vs MQTT
• Is Firebase a valid replacement for MQTT?

*각 구현 방법에 대한 의견을 Comment에 작성해주시기 바랍니다.

*각 기능에 대한 추가적인 정보 및 장단점이 있을 경우 본 이슈를 업데이트 해주시기 바랍니다.

[ByteAurora]

우리와 같은 소규모 프로젝트에서는 시간과 편이성이 중요하다고 생각합니다. 이러한 부분에서 보았을 때 기존의 방식대로 FCM을 사용하는 것이 좋을 것 같다고 생각합니다. 추가적으로 U.O.S에서 Notification시 보내는 데이터에는 매장명과 주문번호 밖에 없기 때문에 데이터의 보안 부분에서는 걱정할 필요가 없다고 생각됩니다.

[UDADDY]

FCM비용은 개인이 사용하기에 귀찮을 것 같습니다.

[ByteAurora]

FCM비용은 개인이 사용하기에 귀찮을 것 같습니다.

FCM은 비용이 들지 않습니다. 위 FCM 장점 부분과 FCM 설명 링크에 들어가시면 FCM이 트래픽 용량에 상관없이 무료인 것을 확인하실 수 있습니다. FCM은 기존 GCM(Google Cloud Messaging)의 최신버전이라고 생각하시면 됩니다.

추가적으로 FCM은 U.O.S 파트너(자영업자 등)가 관리하는 것이 아닌 U.O.S를 서비스로 배포하고자 하는 사람이 프로젝트를 만들어 관리하는 것입니다. 배포자가 FCM 프로젝트를 만들고 해당 프로젝트에 자신이 배포할 앱의 SHA-256과 같은 디지털 서명 키 등록, 배포할 POS기 프로그램에 FCM 프로젝트의 api키만 등록하면 FCM을 사용할 수 있는 구조입니다.

[ByteAurora]

본 링크에서는 MQTT는 발행/구독 구조이므로 다대다 기능에서 유용하다고 설명하고 있습니다. 현재 우리의 Notification은 1 대 1 구조로 이루어져 있고 FCM에도 발행/구독 기능이 포함되어 있기 때문에 FCM을 쓰는 것이 더 유리하지 않을까 생각됩니다.

[ByteAurora]

현재 구조는 FCM 프로젝트를 서비스 배포자가 만들어서 해당 서비스를 사용하는 모든 일반고객/업자들이 동일한 FCM 프로젝트를 사용하게 됩니다. Firebase 공식문서에서는 FCM에 아래와 같은 제한을 두고 있다고 합니다.

XMPP 서버 제한

• FCM XMPP 서버에 연결할 수 있는 속도를 프로젝트당 1분에 400개의 연결로 제한합니다. 메시지 전송에 문제가 생겨서는 안 되지만 시스템의 안정성을 확보하는 것이 중요합니다.
• 프로젝트마다 FCM에서 동시 연결 2,500개를 허용합니다.

단일 기기에 대한 최대 메시지 속도

• 단일 기기에 전송할 수 있는 최대 메시지 수는 분당 240개, 시간당 5,000개입니다. 이렇게 기준이 높은 것은 사용자가 채팅에서 빠르게 상호작용할 때와 같이 단기간의 트래픽 급증을 허용하기 위해서입니다. 이 한도는 전송 로직 오류로 인해 의도치 않게 기기의 배터리가 방전되는 것을 방지합니다.

업스트림 메시지 한도

• 업스트림 대상 서버에 과부하가 걸리지 않도록 업스트림 메시지를 프로젝트당 1,500,000/분으로 제한합니다.
• 악성 앱 동작으로 인한 배터리 방전을 방지하기 위해 기기당 업스트림 메시지를 1,000/분으로 제한합니다.

주제 메시지 한도

• 주제 구독 추가/삭제 속도는 프로젝트당 3,000QPS로 제한됩니다.

우선 위 제한 중 '단일 기기에 대한 최대 메시지 속도' 부분은 제외해도 됩니다. U.O.S에서 Mobile App은 한 주문에 대해서 한 개의 Notification이 발생합니다. 따라서 분단 240개 이상의 주문을 한 개의 Mobile App에서 주문할 가능성은 거의 없기 때문입니다.

가장 고려해야할 부분은 'XMPP 서버 제한' 입니다. 해당 부분에서 말하는 400개의 연결이라는 것이 분당 400개의 Notification 전송 횟수가 넘었을 경우 최초 Notification 전송 후 1분이 지난 시점에서 다시 400개를 전송할 수 있는 의미라면, U.O.S에 대해서 적용하기 어려울 수 있습니다. 각 매장별로 분당 2~3개씩 Notification을 전송한다고 할 때 서비스 이용 매장이 200개 이상이라면 문제가 생길 수 있는 부분입니다. 해당 부분에 대해서는 Firebase에 문의를 넣어둔 상태이고 만약 위의 내용이 맞을 경우에는 MQTT를 사용하는 것이 더 맞을 것이라고 생각됩니다.

[ByteAurora]

위의 내용에서 Firebase Cloud Messaging의 다양한 장점에 대해서 말씀드렸지만, 프로젝트가 FCM에 의존성이 생기게 됩니다. 즉, 구글의 FCM 서버측에 문제가 생길 경우 서비스를 이용할 수 없게 되는 경우가 생길 수 있습니다. 이러한 문제를 피하기 위해서는 FCM을 사용하지 않고 자체 Notification 서버를 구현해야 합니다. 따라서 현재 전체적인 기능이 마무리되는 동안에는 FCM 사용을 유지하고 추후 MQTT로 변경하는 것이 좋을 것 같습니다..