FCM 아키텍처 건의

[hongdosan]

모아밤 프로젝트에서 필요한 요구사항은 다음과 같습니다.

방 참여자들은 루틴을 수행하지 않은 인원들에게 인증 타임 당 1회의 콕 찌르기 알림을 보낼 수 있다.
방 내의 루틴 인증 시작 타임이 된다면 방 참여자들에게 알림이 간다.
요구사항을 봤을 때, 알림 제공자 역할을 하는 별도 인스턴스를 생성해 애플리케이션 서버와 알림 서버를 분리해야 할 지, 아니면 어플리케이션 서버에 알림 기능을 추기할 지 고민이 됩니다.

아무래도 어플리케이션에 존재하는 모든 방의 모든 참여자에게 알림을 인증 타임마다 보내야 하니, 푸시 알림 시스템이 대량 요청을 처리할 것으로 예상은 됩니다. 따라서 효과적으로 작동하는 데 필요한 리소스와 용량을 확보하기 위해 위 이미지와 같이 별도 인스턴스를 사용하는 것이 유용할 수도 있을 것 같습니다. 또한 별도 인스턴스를 사용하면 푸시 알림 시스템에 대한 격리 및 제어 기능을 더 많이 제공할 수도 있을 것 같습니다.

하지만 현재의 모아밤 서비스를 본다면, 주기적인 알림 외는 콕 찌르기를 하는 경우에만 알림 요청이 발생하고, 아직 개발 시작 단계이기 때문에, 사용자가 존재하지 않습니다. 만약 개발이 끝나고 운영 단계라고 하여도 사용자가 그리 많지 않을 것 같습니다. 😢 때문에 기존 응용 프로그램과 동일한 인스턴스를 사용하기로 결정했습니다.

추가로 요구사항을 보면 "인증 타임 당 1회의 콕 찌르기 알림을 보낼 수 있다."를 충족하기 위해, Redis 저장소를 활용할 것입니다. 또한 정해진 인증타임에 푸시를 자동발송 해야하니 스케쥴러를 활용할 예정입니다. 즉, 위 이미지와 같은 아키텍처가 나오게 됩니다.

해당 아키텍처 선정 이유를 정리하면 다음과 같습니다.

• 현재 상황에선 하나의 EC2로도 충분합니다. 굳이 2개로 분리하는 것은 비용 문제가 발생합니다.
• 초기 서비스이기 때문에, 사용자가 적은 만큼 트래픽이 많이 발생하지 않습니다. 즉, 인증 타임마다 Spring Batch를 돌리기엔, 서버가 너무 무거워집니다. 오버 스펙입니다.
• 인증 타임이 됐을 때, 시간 내에 인증을 해야 해서 신속하게 푸시 메시지가 발송되도록 카프카를 적용해볼 수도 있습니다. 하지만, 위와 동일한 이유로 오버 스펙이라고 생각합니다.
• 주니어 개발자로서 아직은 현재 사용되는 기술에 대한 이해와 공부가 먼저입니다.

만약 아키텍처가 이상하거나, 반대 의견이 있으시면 댓글 부탁드리고 찬성한다면 좋아요 하나 부탁드립니다~

[parksey]

글 잘 읽었습니다.
결론부터 말씀드리면, 저도 혁준님의 의견에 동의합니다

혹시, 새로운 EC2 인스턴스가 아닌 같은 인스턴스 내에서 다른 프로세스로 돌리는 것은 어떻게 생각하시나요?
하나의 인스턴스에 하나의 프로세스에서 모든 처리를 하는것 보다 하나의 인스턴스에 두 개의 프로세스로 분리하여 처리하는게
context switch면에서는 분명한 차이가 있을 것 같습니다.

하지만, 위에서도 언급했듯 초기 서비스에서는 트래픽이 많이 발생하지 않기 때문에 유의미한 차이가 발생하지 않을 것 같고, 푸시 하는데에 트랜잭션을 거는 것도 별로 없을 것 같습니다.

그에 반해, 비동기식 요청을 경험해볼 좋은 기회가 아닐까 생각이 들어 의견 남깁니다.

[hongdosan]

답변 감사합니다!! 세연님 의견과 동일하게 저도 비동기식 처리도 지금 계속 고민 중에 있습니다! 하지만 아직 제가 FCM 기술 지식이 부족해서 어떤 식으로 해야 할 지 감이 정확하게 오지 않네요 ㅠ 해당 부분이 정해지면 공유하겠습니다 ㅎㅎ 감사합니당~

[Shin-Jae-Yoon]

안녕하세요 혁준님 ! 글 잘 읽어보았습니다.

우선, 제 의견이 틀릴 수 있다는 점에서 이 부분 고려해서 읽어주시면 감사하겠습니다 !

• 최종적인 아키텍처가 지금의 상황에서는 적절해 보입니다.
• 알림 서버를 따로 분리한다는 경우에는 아래의 사항들을 고려해야 할 것 같습니다.
  • 애플리케이션 서버와 알림 서버의 DB가 동일한지
  • 동일하지 않다면 -> 애플리케이션 서버와 알림 서버의 통신 오버헤드 발생 가능 (ex. 회원정보 수정되면 반영해줘야 함)
  • 동일하다면 -> 동시성 제어 및 일관성 유지해야함 (ex. 딱, 알림 보내는 시간에 방을 나간다면? 지금은 못나가게 해뒀지만, 기획상 변경이 된다면)
  • 새로운 ec2 인스턴스에 대한 비용 + DB도 분리한다면 그에 대한 비용
• 이전에 나눴던 이야기처럼, 완전 대량의 데이터가 아니면 배치가 아닌 스케줄러로도 우선은 충분할 것 같습니다.
• 비동기 메시징 처리 방식은 도전해보면 좋을 것 같습니다 ! 다만, kafka는 러닝커브도 높고 오버 엔지니어링일 것 같고, 자바를 사용하는 지금 JMS 혹은 RabbitMQ 관련해서는 적용해봐도 좋지않나 생각합니다 !

[hongdosan]

답변 감사합니다 재윤님~! 재윤님 말처럼 비동기처리 계속해서 고민해보겠습니다 ㅎㅎ 답변 감사합니당~

[kmebin]

저도 혁준님과 다른 분들의 의견에 동의합니다!
우선 fcm만 먼저 구현한 후에, 메시지큐 적용해도 좋을 것 같아요. 👍