시간과 공간 그리고 진실의 방

문제 상황 요약

FCM 이 deprecated 되면서 2024년 6월 4일부로 완전히 종료되었다고 하지만 최종적으로 Firebase 내에서는 9월 4일날 완전히 공식 Support 가 종료된 것을 확인함.

결론 = 푸시 데이터 알림이 작동하지 않는다.

따라서 예전에 사용하던 FCM 에 대한 부분을 드러내고 FCM HTTP v1 을 강제적으로 사용해야 할 수 밖에 없는 상황에 놓으게 된다

중간 삽질

Firebase 에서 Cloud Function 이나 Google Cloud Console 에서 이것 저것을 실어서 product 를  가동중인 사용자라면 모를까 일반적인 사용자라면 해당하는 방법으로 가동되지 않는다. 따라서 Firebase 내에서 비공개 키 (private key) 에 관련된 json 파일을 받아서 importing 해야하고, 이 부부을 통해서 OAuth2 token 을 따다가 Credential token으로 넣어줘야 작동한다.

즉, 앱에서 푸시 알림을 보내려면 2가지의 토큰이 준비되어야 하는데

1. 앱 내에서 사용자마다 사용하는 push Token. 이 경우는 Firebase 에서 getInstance 에 의하여 토큰을 제공해주고, 해당 부분은 repository 에 정상적으로 저장되는 부분을 확인했다.

2. Bearer 로 Firebase와 연동해서 Oauth2 에 대한 토큰을 딴 뒤에 해당 부분을 통하여 키 인증을 해준다.

그럼에도 불구하고 아래와 같은 상황이 발생하는데

[Admin][2024-10-06 13:04:22][DEBUG][FcmPushModule.java][sendPushMsg(370)] : Send : {"message":{"notification":{"title":"아이리스(경기용인)님이 새 댓글을 남겼습니다.","body":"#가우라"},"token":"ePk90xxfSTKDpaKZQPC22_:APA91bF_4nVQWJgeX50szAta-VD6R1mXrKH552DIVPXQUuosdwSINXjd8PgIBd2_zpIKE4yjpSV5adUIqo50h0uhN_T-63_S2poVVQB9eFRivxZdiADLj0RqFxfnjZ1ycwZJefxKbQVl","android":{"notification":{"click_action":".MainActivity","sound":"default"}}},"validate_only":false}, topic null
[Admin][2024-10-06 13:04:22][DEBUG][FcmPushModule.java][sendPushMsg(390)] : Sending 'POST' request to URL : https://fcm.googleapis.com/v1/projects/moyamo-plus/messages:send
[Admin][2024-10-06 13:04:22][DEBUG][FcmPushModule.java][sendPushMsg(391)] : Post parameters : "{\"message\":{\"notification\":{\"title\":\"아이리스(경기용인)님이 새 댓글을 남겼습니다.\",\"body\":\"#가우라\"},\"token\":\"ePk90xxfSTKDpaKZQPC22_:APA91bF_4nVQWJgeX50szAta-VD6R1mXrKH552DIVPXQUuosdwSINXjd8PgIBd2_zpIKE4yjpSV5adUIqo50h0uhN_T-63_S2poVVQB9eFRivxZdiADLj0RqFxfnjZ1ycwZJefxKbQVl\",\"android\":{\"notification\":{\"click_action\":\".MainActivity\",\"sound\":\"default\"}}},\"validate_only\":false}"
[Admin][2024-10-06 13:04:22][ERROR][FcmPushModule.java][sendPushMsg(399)] : ChatPushModule
java.io.IOException: Server returned HTTP response code: 400 for URL: https://fcm.googleapis.com/v1/projects/moyamo-plus/messages:send
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1902)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1500)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:268)
        at net.infobank.moyamo.push.module.FcmPushModule.responseBodyLog(FcmPushModule.java:259)
        at net.infobank.moyamo.push.module.FcmPushModule.sendPushMsg(FcmPushModule.java:392)
        at net.infobank.moyamo.service.PushNotificationServiceImpl.lambda$sendRequest$0(PushNotificationServiceImpl.java:194)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:750)

대략 요약하자니 여러 부분에 있어서 Payload 구성이 잘못된 것이냐 아니냐에 대한 판단 1과 파라미터에 대한 판단 2가 이루어지는데, 코드를 뜯어보면서 본 결과로는 다음과 같다.

1. Android 에 실리는 Notification 에 대한 부분에서 data 에 대한 부분을 보낼 필요가 없을 경우에 맘대로 보내게 되면 신나게 에러를 뱉게 된다. 따라서 data : null 로 보내기 보다는, 실험한다고 해서 data : null로 보내지 말 것

2. Firebase 쪽에서 제공해주는 부분에 의해서 clickAction 과 click_action, validateOnly 와 validate_only  버전으로 두 개의 property 가 정상적으로 똑같이 Response 를 보내주고 있으나 references 에 있는 대로 validate_only 를 사용하는 것이 나을 것 같아 그렇게 사용하기로 했다.

그럼에도 불구하고 나오는 Bad Request 400 덕에 본능적으로 싸한 부분을 느끼고 여러 부분을 검토하다가

Firebase SDK 가 Google Cloud Messaging API 에 대한 role 을 가지고 있지 않을 것 같기에 확인하는 목적용으로 아래와 같이 role을 수정해주었다.

Service Account 를 확인한 뒤에 Google Cloud Console에서 "IAM & Admin." 을 찾아낸다

이후 아직 log에서 Bad Request 가 확인되지 않았기 때문에 Log 가 뜨면 또 확인해줘야한다 ^^...

여하튼 Issue Tracking 의 단계는 아래와 같았다.

• Invalid FCM Token: Ensure the token "eK-yrDlcTrqwDKeBpRdldR:APA91bHjBPJfZuuGWQpQh0uAW2nf_2S-f5OF4nocBrgV9IRada4L609ftVKr8ocTChCaE5Bb6rTzH9LJcrL11ovOoLI9OPFhoFNWGWZMQW9B6Qmtio0wl4ZFrLGi3Om1kUu_wdoX_HFc" is valid and not expired or malformed.
• Missing Permissions: Ensure your Firebase Cloud Messaging (FCM) API key and server credentials are correctly set up in your project.
• Incorrect URL: Double-check that the request is being sent to the correct FCM endpoint (https://fcm.googleapis.com/v1/projects/{project_id}/messages:send).

첫번째로 확인사살한 부분은 FCM Token 에 대한 부분이고 이 부분은 당연히 작동했다. 

그 이후에 Missing Permission을 잡았고, Incorrect URL 에 대한 부분은 당연히 문제가 없는 부분인데 이래도 문제가 있으면 진짜 음..

FCM HTTP v1

Def

HTTP request

POST https://fcm.googleapis.com/v1/{parent=projects/*}/messages:send

The URL uses gRPC Transcoding syntax.

Path parameters

Request body

The request body contains data with the following structure:

Response body

If successful, the response body contains an instance of Message.

Authorization scopes

Requires one of the following OAuth scopes:

• https://www.googleapis.com/auth/firebase.messaging
• https://www.googleapis.com/auth/cloud-platform

For more information, see the Authentication Overview.

Test - Try this method in right side bar

https://firebase.google.com/docs/reference/fcm/rest/v1/projects.messages/send?_gl=1*zoh55r*_up*MQ..*_ga*MTU1Nzk1ODEwNS4xNzI3NzE1NjM0*_ga_CW55HF8NVT*MTcyNzcxNTYzNC4xLjAuMTcyNzcxNTYzNC4wLjAuMA..&apix_params=%7B%22parent%22%3A%22projects%2Fmoyamo-plus%22%2C%22resource%22%3A%7B%22message%22%3A%7B%22token%22%3A%22fG1sB-i_TRWsI1W9vjL0ql%3AAPA91bFq8CvJ14HqaWDBDO7b4qNwk3avS4_RP849X-s801cIjXgRgfTHLULLpojpXI9tACW1hDmZEkINjXJpU6oh4y4YTIEm3k7LvYQO8Z0zOrkYEAIY1E3bbPtB77y3YhjALR0JF8XL%22%2C%22notification%22%3A%7B%22title%22%3A%22fasdfadsfadsf%22%2C%22body%22%3A%22adfadfadsfadsf%22%7D%7D%2C%22validateOnly%22%3Afalse%7D%7D

FCM ports and your firewall

If your organization has a firewall to restrict traffic to or from the Internet, you need to configure it to allow mobile devices to connect with FCM in order for devices on your network to receive messages. FCM typically uses port 5228, but it sometimes uses 443, 5229, and 5230.

For devices connecting on your network, FCM doesn't provide specific IPs because our IP range changes too frequently and your firewall rules could get out of date, impacting your users' experience. Ideally, allowlist ports 5228-5230 & 443 with no IP restrictions. However, if you must have an IP restriction, you should allowlist all of the IP addresses listed in goog.json. This large list is updated regularly, and you are recommended to update your rules on a monthly basis. Problems caused by firewall IP restrictions are often intermittent and difficult to diagnose.

We do offer a set of domain names that can be allowlisted instead of IP addresses. Those hostnames are listed below. If we start using additional hostnames, we will update the list here. Using domain names for your firewall rule may or may not be functional in your firewall device.

TCP ports to open:

• 5228
• 5229
• 5230
• 443

Hostnames to open:

• mtalk.google.com
• mtalk4.google.com
• mtalk-staging.google.com
• mtalk-dev.google.com
• alt1-mtalk.google.com
• alt2-mtalk.google.com
• alt3-mtalk.google.com
• alt4-mtalk.google.com
• alt5-mtalk.google.com
• alt6-mtalk.google.com
• alt7-mtalk.google.com
• alt8-mtalk.google.com
• android.apis.google.com
• device-provisioning.googleapis.com
• firebaseinstallations.googleapis.com

Network Address Translation and/or Stateful Packet Inspection firewalls:

If your network implements Network Address Translation (NAT) or Stateful Packet Inspection (SPI), implement a 30 minute or larger timeout for our connections over ports 5228-5230. This enables us to provide reliable connectivity while reducing the battery consumption of your users' mobile devices.

In normally, Do not define especially hostname without ports. 

Context

You have applied the Database per Service pattern. Each service has its own database. Some business transactions, however, span multiple service so you need a mechanism to implement transactions that span services. For example, let’s imagine that you are building an e-commerce store where customers have a credit limit. The application must ensure that a new order will not exceed the customer’s credit limit. Since Orders and Customers are in different databases owned by different services the application cannot simply use a local ACID transaction.

Problem

How to implement transactions that span services?

Forces

• 2PC is not an option

Solution

Implement each business transaction that spans multiple services as a saga. A saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.

There are two ways of coordination sagas:

• Choreography - each local transaction publishes domain events that trigger local transactions in other services
• Orchestration - an orchestrator (object) tells the participants what local transactions to execute

Example: Choreography-based saga

An e-commerce application that uses this approach would create an order using a choreography-based saga that consists of the following steps:

1. The Order Service receives the POST /orders request and creates an Order in a PENDING state
2. It then emits an Order Created event
3. The Customer Service’s event handler attempts to reserve credit
4. It then emits an event indicating the outcome
5. The OrderService’s event handler either approves or rejects the Order

Take a tour of an example saga

Example: Orchestration-based saga

An e-commerce application that uses this approach would create an order using an orchestration-based saga that consists of the following steps:

1. The Order Service receives the POST /orders request and creates the Create Order saga orchestrator
2. The saga orchestrator creates an Order in the PENDING state
3. It then sends a Reserve Credit command to the Customer Service
4. The Customer Service attempts to reserve credit
5. It then sends back a reply message indicating the outcome
6. The saga orchestrator either approves or rejects the Order

Take a tour of an example saga

Resulting context

This pattern has the following benefits:

• It enables an application to maintain data consistency across multiple services without using distributed transactions

This solution has the following drawbacks:

• Lack of automatic rollback - a developer must design compensating transactions that explicitly undo changes made earlier in a saga rather than relying on the automatic rollback feature of ACID transactions
• Lack of isolation (the “I” in ACID) - the lack of isolation means that there’s risk that the concurrent execution of multiple sagas and transactions can use data anomalies. consequently, a saga developer must typical use countermeasures, which are design techniques that implement isolation. Moreover, careful analysis is needed to select and correctly implement the countermeasures. See Chapter 4/section 4.3 of my book Microservices Patterns for more information.

There are also the following issues to address:

• In order to be reliable, a service must atomically update its database and publish a message/event. It cannot use the traditional mechanism of a distributed transaction that spans the database and the message broker. Instead, it must use one of the patterns listed below.
• A client that initiates the saga, which an asynchronous flow, using a synchronous request (e.g. HTTP POST /orders) needs to be able to determine its outcome. There are several options, each with different trade-offs:
  • The service sends back a response once the saga completes, e.g. once it receives an OrderApproved or OrderRejected event.
  • The service sends back a response (e.g. containing the orderID) after initiating the saga and the client periodically polls (e.g. GET /orders/{orderID}) to determine the outcome
  • The service sends back a response (e.g. containing the orderID) after initiating the saga, and then sends an event (e.g. websocket, web hook, etc) to the client once the saga completes.

Related patterns

• The Database per Service pattern creates the need for this pattern
• The following patterns are ways to atomically update state and publish messages/events:
  • Event sourcing
  • Transactional Outbox
• A choreography-based saga can publish events using Aggregates and Domain Events
• The Command-side replica is an alternative pattern, which can replace saga step that query data

Learn more

• My book Microservices patterns describes this pattern in a lot more detail. The book’s example application implements orchestration-based sagas using the Eventuate Tram Sagas framework
• Take a look at my self-paced, online bootcamp that teaches you how to use the Saga, API Composition, and CQRS patterns to design operations that span multiple services.
• Read these articles about the Saga pattern
• My presentations on sagas and asynchronous microservices.

Example code

The following examples implement the customers and orders example in different ways:

• Choreography-based saga where the services publish domain events using the Eventuate Tram framework
• Orchestration-based saga where the Order Service uses a saga orchestrator implemented using the Eventuate Tram Sagas framework
• Choreography and event sourcing-based saga where the services publish domain events using the Eventuate event sourcing framework