Azure 아키텍처, Claim-Check Pattern

메시지가 너무 큰가요?

은근 이러한 니즈가 실제 프로젝트에서 흔하게 일어난다. 내가 진행하고 있는 프로젝트 또한 마찬가지다. 작년 가을이나 겨울 즈음에 이러한 니즈가 있었고, 그때는 Claim-Check pattern에 대해 정확하게 몰라서, 개발자분들과 더듬더듬 이렇게 비슷한 구조로 해결을 했었다. 하지만, 내가 조금 더 정확하게 이 패턴을 알았다면 확실히 지금보다 훨씬 깔끔한 구조를 가져올 수 있지 않을까 아쉽다.

모던한 아키텍처에서는 메시지 큐를 즐겨 사용한다. 이러한 메시지 큐에는 대부분 사이즈의 제한이 있다. 예를 들면 내가 프로젝트에서 즐겨 사용하는 방법인, Event Hubs를 Kafka 형태로 사용하는데, Event Hubs의 메시지 사이즈의 제한은 1 MB 이다.

우리가 메시지 큐를 사용하는 용도를 정말 다양하게 활용할 수 있는 점을 미루어 봤을 때, 1 MB 이상 메시지를 처리하고 싶을 땐 어떻게 해야할까?

how to!?

Concept

먼저 기본적인 방법을 보자면 아래와 같다.

(출처: https://learn.microsoft.com/en-us/azure/architecture/patterns/_images/claim-check.png?wt.mc_id=AZ-MVP-5003065)

1. client에서 요청을한다.
2. 가장 앞단에서 받아주는 app이, 전송 받은 파일이나 긴 메시지를 바로 topic이나 queue에 태워서 보내는 것이 아닌, 다른 곳에 저장해놓고, 혹은 처음부터 저장을 그쪽으로 하고 주소나 이름만 뒤쪽으로 던져 준다.
3. topic이나 queue를 subscribing 하고 있는 서비스들은, 메시지 안에 있는 주소 값을 이용하여 데이터에 접근하여 필요한 작업을 한다.

이와 같은 Claim-Check pattern을 사용하면 아래와 같은 장점을 가져갈 수 있다.

1. 파일의 크기와 상관없이 메시지 서비스를 사용할 수 있다.
2. 앞단의 app과 뒷단의 app 사이에 큰 파일을 주고 받는 시간을 줄일 수 있다.
3. 서비스 내에서 파일 및 큰 메시지 전송 실패에 대한 대비책 및 위험도를 줄일 수 있다.

사실 메시지 서비스에서 큰 용량을 지원안하거나 타입을 지원 하지 않아 사용하는 경우도 많지만, 3번의 목적을 위해서 이러한 패턴을 가져가는 경우도 많다.

좋은 방법이지만 몇 가지 requirements가 있다.

1. 중간에 메시지 서비스 같은 아이들이 들어가기에, 전체적인 흐름 자체가 우선 loosely coupled가 된다. 마치 이전에 썼던, Asynchronous Request-Reply pattern과 같은 느낌이기에, 뒷단에서 완성된 결과를 유저가 바로 알게 하기 위해선 retry 이후, redirection이 필요하다.
2. 파일을 직접 뒷단으로 주는게 아니기에, 다른 저장소가 필요하다.

실제 환경에서는?

현재 내가 진행하고 있는 프로젝트에서는, 아주 큰 텍스트 메시지가 왔다 갔다 하고 있다. 위의 Claim-Check pattern 또한 어느정도 적용이 되어있는데, 아래와 같다.

대략적인 flow는 순서는 아래와 같다.

1. traffic이 여차저차해서 istio를 거쳐 app_1으로 간다.
2. app_1에서 부피가 큰 payload 일체를 PostrgreSQL에 저장한다.
3. app_1에서 PostgreSQL에 payload를 key값과 같이 저장하게 되는데, 해당 key 값을 Event Hubs에 메시지로 보낸다.
4. Consumer 역할을 하는 app_2는 Event Hubs를 subscribing 하며 읽어온 key 값을 이용해 PostgresSQL에서 payload 읽어와 처리한다.

범용적인 아키텍처는 어떻게 생겼을까?

아래와 같이 실제 처리해야될 파일 또는 메시지를 다른 곳에 저장하고 저장한 위치를 메시지 서비스를 통해 전달한다는 포인트가 중요한 것 같다. 대략적으로 올만한 서비스들을 나열해 보자면 다음과 같은 그림이 되지 않을까 싶다.

모든 서비스를 나열한 것은 아니지만 위와 같은 그림처럼 다양한 저장소와 다양한 메시지 서비스가 사용 될 수 있을 것 같다.

조금 더 자세히 설명하자면, AKS 앞에는 다양한 Load Balancer 및 보안장비들이 붙을 것이며, 이러한 구조는 AKS 뿐만아니라 GKS, EKS 또는 온프레미스 Kubernetes 클러스터에도 적용이 가능하다. 더 나아가, Kubernetes 뿐만 아니라 VM, Azure Functions, Web App 등 다양한 서비스들 또한 활용이 가능하다.

중요한 포인트는 처음 서버 역할을 하는 곳이 데이터를 바로 뒤에 있는 다른 서비스에 직접 주지 않고 저장소를 통해서 주소 또는 식별자 정도만 전달하는 것이다.

마치며

Claim-Check Pattern에 대해 알아 보았다. 파일 또는 일반적인 메시지보다 큰 payload를 가진 트래픽에 대하여 대응할 수 있는 대중적인 pattern 중 하나이다. 잘 활용하여 더 나은 서비스를 구축해보자!!

Claim-Check Pattern은 여러 방면으로 활용 가능성이 높은 패턴이다. 서비스 간의 부담도 덜어줄 수 있을 뿐만 아니라, loosely coupled architecture에서 일반적인 메시지보다 훨씬 큰 대상들에 대한 좋은 답안이 될 수 있다.