User Connectivity: 프로덕션 2년 — 배운 교훈과 새로운 패턴

Source: Dev.to

Introduction

이 글은 이전에 올린 User Connectivity: A Real‑time Web Solution for Online and Offline User Status에 대한 후속 글입니다. 사용자 연결 솔루션을 프로덕션에 배포한 지 거의 2년이 지났습니다. 실험으로 시작했던 것이 이제는 아키텍처의 핵심이 되었습니다.

최근 몇몇 API 프로세스 때문에 복잡한 데이터베이스 데드락 문제가 발생했습니다. 문제를 분석한 결과, 이벤트‑드리븐 아키텍처를 적용할 기회를 발견했습니다. 특정 작업을 분리해 비동기적으로 처리함으로써 데드락을 완전히 없앨 수 있었습니다.

Event Distributor의 목표는 간단합니다: Redis 만료 이벤트를 듣는 하나의 중앙 서비스만 존재한다는 것.

Event Distributor Benefits

• Traceability – 모든 이벤트가 하나의 지점을 통과하므로 문제 추적이 쉬워집니다.
• Logging – 수신된 모든 이벤트는 상태와 함께 Azure Cosmos DB에 기록됩니다.
• Scalability – 워커 함수는 큐 깊이에 따라 독립적으로 확장될 수 있습니다.
• Reliability – 단일, 잘 모니터링되는 리스너가 이벤트 누락 위험을 줄여줍니다.

2년간 이 아키텍처를 운영하면서 Azure 서비스를 활용한 유사 솔루션을 구현하려는 사람들에게 두 가지 중요한 관찰을 공유합니다.

Critical Observations

1. Use Premium Plan for Redis Listeners

왜?
Consumption 플랜은 콜드 스타트 지연과 제한된 연결 수명을 가집니다. Function App이 유휴 상태가 되면 잠자기 모드에 들어가 Redis 이벤트를 놓칠 수 있습니다. Premium 플랜을 사용하면 Function App이 항상 켜져 있고 장기 연결을 유지하므로 콜드 스타트도 없고 이벤트도 놓치지 않습니다. Premium으로 전환한 이후로 하나도 놓친 이벤트가 없습니다.

원래 사용자 연결 솔루션이 Consumption 플랜에서 어떻게 동작했는지 궁금할 수 있습니다.
동작은 했지만 이벤트 누락 위험이 더 높았습니다.

2. Azure Managed Redis Limitation

중대한 제한 사항이 있습니다: Azure Managed Redis 서버는 만료 이벤트를 안정적으로 전송하도록 완전히 구성할 수 없습니다. 기본 서버가 재시작되거나 순환될 때 구성 정보가 사라져 만료 이벤트 전송이 중단됩니다.

이 문제를 Microsoft에 보고했으며, 현재 백로그에 올라가 있지만 오늘 기준으로 해결책은 없습니다. 아키텍처가 Redis 키 만료 이벤트에 의존한다면 Azure Managed Redis로 마이그레이션하기 전에 이 제한을 인지해야 합니다.

Takeaways

• Redis 리스너에는 Premium 플랜을 사용해 콜드 스타트와 이벤트 누락을 방지하세요.
• 만료 이벤트에 의존한다면 Azure Managed Redis 사용에 주의하세요. 서버 재시작 시 구성 손실이 발생할 수 있습니다.

이 글이 다른 사람들이 이 아키텍처를 활용하는 데 도움이 되길 바랍니다.