.NET 기술을 활용한 Worker 서비스 개발기 -1-
오래 전부터 Web Service가 아닌 Worker Service 같은 부류를 만들기 위한 작업을 어떤 식으로 진행했는지 그 과정에서 어떤 생각을 했는지 좀 정리 해보고, 최근에는 어떻게 발전했는지 소회를 남기려고 한다.
크게 아래와 같은 형태의 시리즈가 될 것 같다.
- Message Broker 를 활용한 Pub-Sub 개념
- .NET Framework - Windows Service Worker 개발
- .NET Core 3.1 로 변환 하면서 Hosting 활용한 통합 worker 구조로 변경
- .NET5 변환 하면서 DI 및 여러 설정 문제로 반대 개념으로 만들기
- .NET6 변환 하면서 git sub module 사용으로 worker 의 ci/cd 분기
Worker
Worker 서비스라 함은 보통 console 프로그램 또는 실행(exe) 프로그램 을 생각하게 되는데, 좀 더 머리 속에 남게 말한다면
- linux os 의 daemon 형태로 항상 실행되어 있어야 하는 형태
- windows os 의 service 에 등록되어진 형태처럼 동작하는 형태
가 기준점처럼 생각된다 (물론 진정으로 위 의미가 아니긴 하다)
Worker 는 작업자를 말하는 것이고, 이 단어는 어떤 것들이 와도 무수히 많은 파생을 만들어낼 수 가 있는 내용이다. 중요한 요소로
- Queue의 메시지를 가져와서 작업을 처리 하며
- 백그라운드로 처리를 할 수 있고
- 기존 시스템과의 접점이 없게 되는게 장점이다
Message Broker
Web 서비스를 만들다보면, 특정 작업(Job) 에 대하여 후 처리(Post-process)를 해야하고, 그 과정에서 생긴 pipeline 은 기본적으로 Message Broker (middleware) 를 사용한 개념이 일반적이다.
Cloud 기술이 생기고, Serverless 기술이 발전하면서 AWS Lambda 나 Azure Function 기능들을 활용해 후처리(Post-Processing)를 하는 과정이 생겼지만, 전통적인 Post-Process 방식은 역시 메시지 브로커(Message Broker)를 활용한 Pub-Sub 구조의 처리이다
Message Broker(메시지 브로커)는 Producer(생산자) 로부터 전달받은 메시지를 Consumer(소비자)로 전달해주는 Middleware(중간 역할)이며, 응용 소프트웨어 간에 메시지를 교환할 수 있게 한다. 이 때 메시지가 적재되는 공간을 Message Queue(메세지 큐)라고 하며 메시지의 그룹을 Topic(토픽)이라고 한다.
흔히들 이러한 구조를 Producer/Consumer Pattern 이라고도 한다. 또 다른 말로 Pulibsh (송신) /Subscribe (수신) (pub/sub) Pattern 이라고도 한다.
메시지 브로커는 대표적으로 AWS SQS, Apache Kafka, Apache ActiveMQ, RabbitMQ, Celery 등이 있다. 모두 Message Broker 의 역할을 하는 제품 이다.
References
Contributors to Wikimedia projects
