MSA 최소 설계 (운영 적용)

하게 된 이유

책 내용 그대로 따라하기엔 업무에서 바로 적용을 할 수가 없었다. 

이벤트 처리기와 저장소, (여기에 정리하지 않은) DTO 기반 API 구현과 중복 이벤트에 대한 처리 등등 

필요는 하지만 당장 그정도의 환경을 동시에 적용을 할 수 없고, 주변 사람들을 설득할 수도 없었다. 

당장 쓰고 있는 환경을 기반으로 바로 적용할 수 있도록 최소화 시킬 필요가 있었다. 

 

구성도

서버 환경을 네 개의 구간으로 나눴다. 

• API Gateway
  • 클라이언트 App에서 Restful API로 붙는 외부 Endpoint이다. 실질적인 서비스 로직을 가지지 않고, Micro Server Container로 필요한 요청들을 호출한다. 
• Micro Service Server List(초록색 구간)
  • 복수의 Micro Service Server Container들로 구성되어있다.
  • API Gateway를 통해 전달된 클라이언트의 요청을 처리, 반환한다. 
  • 각 Container들은 아래 구성들을 별도로 보유한다. 
    • API Server : 사용자의 요청을 바로 처리해줄 실질적인 서비스 로직이 위치하는 서버. API Gateway로부터 요청된 필요 데이터를 처리/반환한다. 
    • On-memory DB : 성능 향상을 위한 휘발성 데이터 저장소. 캐싱이 필요하지 않다면 없어도 무방하다. 
    • RDB : 해당 Container 내부에서만 사용하는 비휘발성 데이터 저장소. main DB로 활용할 수 있다면 RDB가 아니어도 상관없다.  
•  Micro Service Scheduled Batch List(파란색 구간)
  • 복수의 Micro Service Batch Container들로 구성되어있다. 
  • Micro Service Server의 요청에 대한 비동기 처리를 진행한다. 
  • 각 Container들은 아래 구성들을 별도로 보유한다. 
    
    • Service Batch : 사용자의 요청 혹은 서비스를 위한 데이터 처리를 바로 진행하지 않아도 되는 서비스 로직이 위치하는 서버. 
    • Event Queue : Container간 처리 요청 Event를 Queue에 등록한다. 비동기 처리를 위한 구성이기 때문에 Restful API를 통한 직접 호출이 발생할 필요가 없다. 
    • Event DB : Event Queue를 통해 전달된 요청의 진행 상태(Event 시작~종료), 결과를 저장한다. 
• 구독형 서버
  • 클라이언트와 서버간 상시 연결되어 상호 전달이 가능한 서버
    • 위 구성도에서는 서버로부터 데이터를 수신받기 위한 역할을 가지고 있다. 
  • 아래 구성들을 별도로 보유한다. 
    • Queue : Micro Service Batch에서 클라이언트에게 전달하고 싶은 데이터를 등록할 공간이다. 
    • Event Transfer Batch : Queue에 들어온 요청을 추출하여 클라이언트에게 전달할 Subscribe Server에 전달한다.
    • Subscribe Server : 클라이언트와 서버가 직접 연결하게 되는 구간이다. Websocket이나 MQTT 등을 통한 연결이 이루어진다. 

적용 경험

위 구성은 책 내용을 기반으로 일부를 간소화한 구조이지만, 실제 업무에서 적용시키기는 훨씬 나았다. 

안써본 기술과 프레임워크 적용을 위한 윗 사람들 설득이 필요없고, 이미 사용하고 있는 환경으로 손쉽게 적용이 가능했다. API Gateway는 개발 공수가 커서 못만들었지만, Micro Service Server/Batch의 운영 개발/적용까지 완료했다. 

* 이런 작은 구성 적용하려고 설득했던 걸 생각하면 진짜 일하기 힘들다

운영까지 하면서 얻은 장단점을 나열해보자면

• 장점 
  • 대기능 별 서버와 DB를 분리 개발하여 타 기능에 영향을 주지 않고 개발할 수 있다. 
  • 각 서버의 역할에 따른 성능 개선을 진행할 수 있다. 
  • 서비스 로직이 각 서버에 귀속되어, 소스코드가 엉키는 일이 발생하지 않는다. 
    • 회원 정보과 회원에게 귀속된 상품에 정보를 한 서버에서 관리하다보면 중복된 코드와 쿼리가 발생하고, 서비스 로직 간 호출이 거미줄처럼 엉킨 상황에서 쉽게 로직을 바꿀 수 없는 상황이 생가보다 쉽게 발생한다. 
    • 물론 DDD 기반 개발이 잘 이루어졌다면 예방할 수 있겠지만, 서버 구성 상 물리적으로 분리된 것이 더 안전하다. 
• 단점 
  • 관리를 잘못하면 Server Container가 마구잡이로 늘어날 수 있다. (비용은 덤)
  • 하나의 API 개발이 Gateway + N개의 서버 개발로 작업이 늘어날 수 있다. 
  • Queue에 등록되는 Event의 실패 처리에 대한 안전 규칙이 필요하다. 

등이 있다. 

하지만 단점의 경우 살짝 귀찮아지는 정도지만, 장점에선 안전한 개발과 더 쉬운 성능 개선이 보장되어 적용을 하지 않을 이유가 없었다.

또한 Container 별 요청 성공/실패 확률을 체크해봤을 때, 한 달 기준 성공률 100%를 찍은 서버도 있었다. 의심이 되서 로직과 구성에 대한 검증을 진행해봤지만, 단순화된 로직과 구조를 통한 안정화된 서버로 인한 성공률인 것을 확인했다.

아마도 반박이 나올 사항 

위 구조는 흔히 Admin, CMS와 같은 관리자를 위한 구성이 아니다. 최종 서비스 사용자를 위한 클라이언트와 서버 간의 통신을 위한 구조이기 때문에, "저러면 관리자 페이지에서 join을 걸어서 결과를 조회할 수 없어!" 라는 주장에 대하여 긍정할 수 밖에 없다. 

하지만 관리자 페이지에서 join걸자고 유저 사용성을 위한 안정된 구조를 쓰지 않는 것은 말이 안된다. 그리고 join을 쓰지 않고도 소프트웨어 기획과 설계 단계에서 충분히 해결 할 수 있다고 생각한다. 

하지만

새로운 운영 경험과 관리를 통한 결과를 내놓았지만, 생각보다 고비가 빨리 왔다. 일부 구성원들(상급자 포함)이 귀찮다고 적용을 반대하는 의견을 조금씩 내놓고 있다. 

생각의 차이인지, 그냥 귀찮음의 차이인지 모르겠다. 나라고 편해서 한게 아닌데...