MSA 어떻게 적용해야 할까?

현장을 돌아다니다 보면 마이크로서비스 아키텍처에 대해 다양한 질문을 받습니다. 

 

질문 중에는 기술 자료나 서적 등을 찾아보면 쉽게 답을 찾을 수 있는 것도 있지만, 아무리 찾아도 적절한 답을 찾기 어려운 질문도 많죠. 

 

국내 IT 업계의 환경이나 구현 스타일이 해외와 다르기 때문에 해외 도서나 기술 자료에서는 알맞은 답이 없기도 하고, 엔터프라이즈 시스템이나 금융권 시스템의 담당자가 볼 때 마이크로서비스 아키텍처의 사례로 종종 소개되는 B2C 업계와 본인들의 조직은 환경이나 여건이 다르기 때문에 잘 안 맞을 것이라고 여기기도 합니다. 

 

 

여기에서 다른 서적이나 기술 자료에서는 답을 찾기 어려운 질문을 소개하고 제가 생각한 답변을 제시 드리고자 합니다.

 

질문의 주제는 시스템 기획부터 구축 운영까지 다양합니다. 차기 시스템을 기획하는 시스템 책임자는 마이크로서비스 아키텍처가 적합하다면 어떤 점이 더 좋아질지 궁금할 것이고요.  

 

시스템을 개발하는 PM은 마이크로서비스 아키텍처로 시스템을 개발할 때 주요 태스크를 어떻게 정의하는지 혹은 비용을 어떻게 산정하는지 궁금할 것 입니다. 

 

그리고 아키텍트는 서비스를 얼마나 엄격하게 분리해야 하는지 궁금할 수 있죠. 

정석대로 모든 서비스를 서로 격리해야 할지 혹은 현장 상황을 고려하여 예외를 둘 수도 있는 건지 궁금해 합니다.  

 

개발자는 데이터베이스를 분리해서 시스템이 어떻게 빠르고 안정적으로 동작할 수 있는지 궁금하죠. 그리고 마이크로서비스 아키텍처로 시스템을 구축한 후에는 적절히 구축한 것인지를 확인하고 싶어하기도 합니다. 

 

그럼 지금부터 시스템 책임자, PM, 아키텍트, 개발자가 관심을 가질만한 질문을 모아서 답변을 정리 하겠습니다. 

  

<질문 1> 우리 시스템에 마이크로서비스 아키텍처가 적합할까?

 

현장에서 가장 많이 하는 질문입니다.

단순히 마이크로서비스 아키텍처를 접하고 호기심에 궁금해하는 경우도 있지만, 마이크로서비스 아키텍처를 도입하도록 지시받은 담당자가 혼란 속에서 절박하게 답을 찾아 질문하는 경우도 많아요.

 

어떤 아키텍처 스타일이 시스템에 적합하다는 것은 다른 아키텍처 스타일 보다 시스템의 중요한 비기능 요구 사항을 잘 달성할 수 있다는 의미입니다.

 

마이크로서비스 아키텍처는 업무 단위로 시스템을 개발 및 배포하여 변경 리드 타임을 개선할 수 있고, 업무 단위로 장애 영향을 차단하며, 업무 단위로 시스템을 확장할 수 있는 장점을 가집니다. 

 

이 3가지 장점으로 시스템의 비기능 요구 사항을 잘 만족시킬 수 있다면 마이크로서비스 아키텍처가 적합한 시스템이라고 볼 수 있죠.

 

3가지 장점 중 업무 단위로 변경 리드 타임을 개선하는 것은 마이크로서비스 아키텍처를 도입하는 가장 보편적인 이유입니다. 

 

대표적인 예로 딜리버리 퍼포먼스가 저하되어 있는 거대 시스템은 여러개의 독립적인 시스템처럼 분할하여 딜리버리 퍼포먼스를 회복할 수 있어요.  

 

지속적인 전달을 적용하려는 시스템도 변경 및 배포하는 단위를 작게 유지하기 위해 마이크로서비스 아키텍처를 도입할 수 있고요. 

 

그런데 딜리버리 퍼포먼스가 저하된 경우에도 시스템 담당자가 변경 리드 타임을 개선할 필요성을 느끼지 못하는 경우가 종종 있어요. 시스템의 딜리버리 퍼포먼스가 저하된 것을 인지하지 못하는 경우도 있고, 더 이상 개선할 방법이 없다고 생각하는 경우도 있죠. 

 

그래서 변경 리드 타임을 단축하라는 압박을 받더라도 근본적인 해결책을 찾지 않고 젠킨스jenkins, 앤서블ansible, 테라폼terraform과 같은 자동화 툴을 도입하는 것으로 만족하기도 한다. 

 

그러므로 변경 리드 타임을 개선하기 위해서는 담당 시스템의 딜리버리 퍼포먼스 수준을 인지하고 이를 개선할 수 있는 방법을 이해할 수 있어야 한다.

 

또한 업무 단위로 장애를 차단하거나 확장하는 것도 마이크로서비스 아키텍처를 도입하는 이유가 된다. 하지만 모놀리식 아키텍처도 이 점을 상당 부분 달성할 수 있으므로 차이점을 잘 구별할 필요가 있다. 

 

<질문 2> MSA는 엔터프라이즈 시스템에도 어울릴까?

 

엔터프라이즈 시스템 담당자는 엔터프라이즈 시스템과 마이크로서비스를 먼저 도입한 B2C 온라인 비즈니스 시스템은 근본적으로 차이가 있기 때문에 마이크로서비스 아키텍처가 어울리지 않는다고 생각합니다. 

 

먼저 엔터프라이즈 시스템의 특징 4가지를 살펴보겠습니다.

 

• 첫째, 엔터프라이즈 시스템은 모든 것을 계획하여 진행한다. 기업의 목표에 맞춰 시스템을 기획하고, 가용 범위 내에서 예산을 정하고, 세부 요구 사항을 정의한 후에 프로젝트 팀을 꾸려서 단기간에 집중적으로 개발한다. 그렇기 때문에 시장의 피드백을 기준으로 빠르게 따라가기보다는 잘 정의된 기능을 신속하게 구현하는 게 중요하므로 마이크로서비스 아키텍처를 사용해서 비즈니스 민첩성을 개선할 필요가 없다고 생각한다.
  
• 둘째, 직접적으로 경쟁 관계인 시스템이 없다. 기업 내부에서만 시스템을 사용하므로 다른 기업의 시스템과 동시에 사용하는 사용자가 없고, 또 동시에 사용하더라도 기업의 비즈니스 특성에 맞게 최적화되어 있어 다른 기업 시스템과 기능이나 변경 리드 타임을 일대일로 비교하기 어렵다. 따라서 획일적으로 변경 리드 타임이 느리다거나 개선이 필요하다고 말하기 어렵다. 
  
• 셋째, 대상 사용자가 정해져 있고 상대적으로 사용 인원이 적다. 사용자가 기업의 임직원으로 한정되므로 사용자의 니즈 파악이 용이하고, 이를 바탕으로 개선안을 구체화할 수 있다. 기업과 시스템의 상황에 맞춰 요구 사항의 우선 순위를 정하거나 기각할 수도 있다. 시스템이 조금 불편하더라도 B2C 비즈니스처럼 사용자가 떠나가지도 않는다. 그렇기 때문에 사용자의 피드백을 빠르게 반영하기 위해 시스템을 복잡하게 만들어야 한다는 점에 공감하지 못하기도 한다. 그리고 B2C 시스템은 사용자가 수백만 명에서 수억 명에 달하지만 기업 시스템의 사용자는 수만 명을 넘기 어렵다. 따라서 시스템의 트래픽이 증가하고 감소하는 폭이 상대적으로 작기 때문에 자유롭게 확장 축소가 가능한 기능을 필요로 하지 않는다. 
  
• 넷째, 도메인이 다양하게 세분화되고, 도메인에 따라 시스템이 만들어진다. B2C 비즈니스 시스템의 경우 비교적 적은 도메인에 많은 기능이 밀집되어 있지만, 기업 시스템은 전통적인 분류에 따라 이미 여러 개의 시스템으로 나뉘어 규모가 매우 큰 시스템이 많지 않다. 굴지의 글로벌 기업이라 해도 개발/운영 인원이 50명 넘는 시스템이 많지 않다. 따라서 많은 인원이 함께 개발하고 배포하면서 발생하는 어려움은 많지 않다.

 

이처럼 엔터프라이즈 시스템은 기능 요구 사항과 딜리버리 일정을 자체적으로 정하고 직접 비교하는 경쟁 시스템이 없기 때문에 B2C 비즈니스 시스템보다는 변경 리드 타임이 중요하지 않아 마이크로서비스 아키텍처가 적합하지 않다고 생각할 수 있습니다.

 

하지만 실제로는 그렇지 않아요. 

 

내부에서는 항상 변경 리드 타임을 중요시하고 시스템의 중요 지표로써 관리하고 있고요. 

또한 기업의 내부 시스템을 비교해보면 유독 변경 리드 타임이 저하된 시스템을 찾을 수 있습니다.

 

동일한 프로세스와 개발 문화를 갖고 있지만 매주 1회 이상 배포하는 시스템이 있는가 하면, 월 1~2회 배포하는 시스템도 있죠. 

 

배포를 적게 하는 시스템일수록 많은 사람이 담당하는 규모가 큰 시스템인 경우가 있고, 초기에는 자주 배포했지만 시간이 흐르면서 어쩔 수 없이 배포 횟 수를 줄여 온 경우가 있겠습니다.

 

규모가 큰 기업이라면 마이크로서비스 아키텍처를 도입하여 변경 리드 타임을 단축할 수 있는 시스템을 어렵지 않게 찾을 수 있습니다. 

 

최근에는 엔터프라이즈 시스템도 클라우드 인프라로 전환하는 사례가 늘어나고, 애플리케이션 현대화에도 큰 관심을 보이고 있습니다.

 

이에 따라 퍼블릭 클라우드 플랫폼을 사용하거나 자체 클라우드 플랫폼을 구축하는 경우가 많아졌고 마이크로서비스 아키텍처를 도입하는 사례도 점차 늘어나고 있지요.

 

얼마 후에는 이런 질문이 없어질 수도 있겠습니다. 

  

<질문 3> MSA 프로젝트 일정은 어떻게 수립해야 할까?

프로젝트의 PM은 마이크로서비스 아키텍처를 적용하여 제안서를 작성하거나 프로젝트를 착수할 때 주요 일정을 어떻게 잡아야 하는지 궁금해합니다. 

 

마이크로서비스 아키텍처를 적용한다고 해서 프로젝트의 진행 방식이 크게 바뀌지 않지만, 일부 태스크에는 차이점이 있어요. 

 

 

위 그림은 마이크로서비스 아키텍처 도입으로 달라지는 태스크 간의 관계를 보여줍니다. 

 

신규 태스크는 도입 목표를 정하고 서비스 목록을 정하는 것이고요. 

 

도입 목표와 서비스 목록은 다른 태스크의 입력값이 되므로 가장 먼저 정의해야 합니다. 그리고 개발팀 구성, 소프트웨어 미들웨어 설계, 하드웨어 인프라 설계, PoC(Proof of Concept) 등은 기존에도 존재하는 태스크인데 마이크로서비스 아키텍처에 맞춰 부분적으로 변경됩니다.

다음으로 각 태스크에 대해 더 알아보겠습니다. 

 

도입 목표 및 서비스 선정 

마이크로서비스 아키텍처를 도입할 때는 목표를 명확하게 정의하고 서비스를 선정해야 합니다. 마이크로서비스 아키텍처를 도입하는 목표는 서비스 선정을 포함하여 시스템의 전반적인 방향을 제시해야해요. 

 

그런 다음 시스템을 구성하는 서비스 목록을 선정하고 서비스 간의 관계를 도출해야 좋습니다. 

서비스 목록과 서비스 간의 관계는 개발팀을 구성하거나 소프트웨어 미들웨어와 하드웨어 인프라를 설계할 때의 기준이 되므로 가능한 한 초기에 정해야 합니다. 

 

이후에도 서비스 경계를 바꾸거나 합칠 수 있으므로 초기에 결정하는 것에 너무 부담을 가질 필요는 없어요.

 

개발팀 구성

개발팀은 앞서 선정한 서비스를 전담할 수 있도록 구성합니다. 하나의 개발팀이 여러 개의 서비스를 담당할 수도 있지만 하나의 서비스는 하나의 개발팀이 담당하는 것을 원칙으로 하는 것이 좋죠. 

 

개발팀이 구성되면 각 서비스의 기능을 상세화하고 개발합니다. 

참고로 시스템 개발을 아웃소싱하는 경우 프로젝트 개발팀과 시스템 운영팀이 이원화되는 경우가 많은데, 모든 기준은 운영팀이라는 것을 염두에 두어야 합니다.

 

마이크로서비스 아키텍처는 독립적인 개발팀이 주체적으로 기술 스택이나 표준을 정하는 경우가 많은데 이는 시스템 운영 중에 각 서비스가 진화해가는 배경속에서 행해집니다. 

 

간혹 이를 프로젝트 팀의 권리로 착각하고 운영팀이 감당할 수 없는 기술 스택을 선정하려는 경우를 볼 수 있어요. 하지만 마이크로서비스 아키텍처는 운영 중의 개발 생산성을 높이는 것입니다. 

 

프로젝트 팀이 시스템을 개발하고 오픈 이후에는 운영팀에 인계하고 철수한다면 운영팀의 의견을 반영하는 것이 맞아요. 같은 이유로 운영팀이 프로젝트에 많이 참여하는 것이 좋습니다.

 

특히 아키텍처만이 아니고 프로세스나 개발 문화도 함께 변경하는 경우에는 운영팀이 조기에 참여하여 익숙해질 수 있는 시간이 필요하죠.

 

소프트웨어 미들웨어 설계

도입 목표와 서비스 목록은 소프트웨어 미들웨어를 설계하는 기준이 됩니다. 자유로운 스케일 인/아웃이 필요하거나 서비스의 개수가 많은 경우에는 API 게이트웨이나 서비스 레지스트리/디스커버리를 제공하는 미들웨어 또는 인프라를 구축해야 합니다. 

 

반대로 고정된 인프라에서 특별히 확장성에대한 요건이 없고 서비스 수가 적다면, 별도의 API 게이트웨이 없이 웹 서버의 설정으로 정적인 라우팅 기능을 제공하는 것으로도 충분할 수 있습니다.  

 

그리고 서비스 간에 인터페이스가 많다면 이벤트 통신을 위한 메시지 큐(message queue)를 추가하거나 서비스 매시(service mesh)와 같은 클라이언트 사이드 라우팅 기술이 필요할 수도 있어요.

 

추가적으로 필요한 미들웨어가 확인되면 각 미들웨어를 설계하고 구축하는 세부 태스크를 정의해야 합니다. 

 

하드웨어 인프라 설계

서비스와 미들웨어 구성이 결정되면 필요한 하드웨어 구성과 용량을 결정할 수 있습니다. 이에 따라 필요한 컴퓨팅 자원과 네트워크 자원을 설계하고 구축하는 태스크를 계획해야 합니다. 퍼블릭 클라우드와 같이 필요에 따라 하드웨어를 증설할 수 있는 환경이라면 복잡한 인프라 사이징 없이 최소 구성으로 시작할 수 있으므로 편리합니다. 

 

그리고 API 게이트웨이나 서비스 레지스트리/디스커버리 등을 직접 구축하는 대신 관련 요소가 잘 갖춰진 클라우드 플랫폼을 선택할 수도 있습니다.

 

PoC

검증이 필요한 새로운 기술 요소가 있다면 PoC를 수행할 수 있다. 개발팀이 SPA, RESTAPI 같은 API 중심의 아키텍처가 처음이거나 다른 서비스에 저장된 사용자, 기준 정보 등을 API로 조회하는 것이 낯설다면 먼저 PoC를 수행하여 동작하는 샘플을 확보하는 것이 좋습니다. 

 

그리고 공통 기능을 제공하는 서비스는 정식으로 미리 개발을 시작하는 것이 좋아요. 

 

SI 프로젝트처럼 특정 시점에 대규모의 개발자가 투입되는 경우는 실제로 동작하는 시스템이 있으면 개발자가 이해하는 데에 큰 도움이 되기 때문입니다.  

 

그리고 스케일 아웃이나 장애 격리가 시스템의 중요한 목표라면 사전에 PoC를 수행하는 것이 좋습니다. 의외로 생각하는 것과 다르게 동작하는 경우가 많으므로 유사한 구축 경험이 없다면 가능한 한 빨리 PoC를 실행하는 것이 나중에 구조 변경을 최소화할 수 있어요.

 

다음으로 개발 프로젝트를 실행할 때 각 태스크가 수행되는 시점을 알아 보겠습니다. 

 

위 그림은 프로젝트를 기획하고 실행하는 프로세스에서 태스크의 수행 시점을 보여 줍니다. 시스템 개발은 기간이 길고 큰 비용이 투입되기 때문에 프로젝트 기획 단계에서 실행 계획을 꼼꼼하게 수립해야해요. 

 

프로젝트의 비용과 일정은 마이크로서비스 아키텍처의 도입 목표, 서비스 목록, 소프트웨어 미들웨어, 하드웨어 인프라의 고수준(high level) 아키텍처에 영향을 받으므로 프로젝트 기획 단계에서 상당 부분 확정해야 합니다. 

 

프로젝트 중에도 소프트웨어 미들웨어와 하드웨어 인프라 설계를 수행하지만 이는 기획 단계에서 정의한 아키텍처를 구체화하는 작업인 경우가 많습니다.

 

마이크로서비스 아키텍처 도입에 대한 의문점을 해소하는데 조금이라도 도움이 되셨기를 바랍니다. 다음에는 4번째 질문 <프로젝트 비용을 산정하는 법>과 5번째 질문 <서비스는 분리하고 데이터베이스만 열어주면 안 될까?>를 정리 하겠습니다. 

  

---

 

위 내용은 <마이크로서비스 아키텍처 구축 가이드: 성공적인 마이크로서비스 아키텍처 적용을 위한 체크포인트와 전략>을 재구성하여 작성 되었습니다.