한빛출판네트워크

마이크로서비스는 대규모 소프트웨어 개발에 적용하기 위한 것으로 독립적으로 실행 가능하고 배치될 수 있는 작은 단위(모듈)로 기능을 분해하여 서비스 하는 아키텍처로, 클라우드 기반 환경에 적합해 매우 인기있는 아키텍처 선택지가 되었습니다. 마이크로서비스라는 작은 빌딩 블록을 활용하면 더욱 복잡한 시스템을 구축할 수 있습니다. 하나의 마이크로서비스는 재고, 주문관리, 배송만을 대표하지만 이를 한데 모으면 전체 상거래 시스템을 구성할 수도 있습니다.

마이크로서비스를 도입하고자 탐구하고 계신다면, 우선 마이크로서비스의 몇 가지 핵심 개념을 자세히 살펴보고 이해하는 것이 중요합니다.

 

1. 독립적 배포성

​

독립적 배포성은 다른 마이크로서비스를 배포하지 않고도 마이크로서비스를 변경,배포, 릴리즈할 수 있다는 개념입니다. 이러한 작업을 수행할 수 있다는 사실뿐 아니라 실제로 시스템에서 배포를 관리하는 방법이 더욱 중요하며 기본 릴리스 방식으로 채택하는 원칙입니다. 이 개념은 단순하지만 실행하는 게 쉽지만은 않습니다.

독립적 배포를 위해서는 마이크로서비스를 느슨하게 결합시켜야 합니다. 다른 서 비스를 변경하지 않고도 한 서비스를 변경할 수 있어야 하죠. 이는 서비스 간에 분명하고, 잘 정의되며, 안정적인 계약이 필요하다는 것을 의미합니다. 

독립적 배포성, 그 자체로 매우 가치가 높지만 독립적 배포에 도달하려면 그 자체로 이점이 있는 다른 요소들도 제대로 갖춰야 합니다. 따라서 독립적 배포성에 중점을 둔다면 그 결과로 많은 부수적 혜택을 얻을 것입니다. 안정적인 인터페이스를 갖고 느슨하게 결합된 서비스를 요구하는 목소리가 커지면서 마이크로서비스 경계를 찾는 방법을 가장 먼저 생각하게 되었습니다.

​

Tip. 일반적인 마이크로서비스 개념 중 하나만 선택해야 한다면 이 개념이여야합니다. 마이크로서비스의 독립적 배포 개념은 반드시 수용되어야 하죠. 다른 어떤 것을 추가로 배포하지 않고도 한 마이크로서비스의 변경 사항을 운영 환경에 배포하고 릴리스하는 습관을 들인다면 많은 이점이 따를 거에요.

 

2. 비즈니스 도메인 중심의 모델링

​

도메인 주도 설계와 같은 기술을 사용하면 소프트웨어의 동작을 더 잘 표현하는 코드를 구성할 수 있습니다. 마이크로서비스 아키텍처에서는 비즈니스 도메인을 중심으로 서비스 경계를 정의하여 새로운 기능을 더 쉽게 출시하고 사용자에게 제공할 수 있습니다. 

둘 이상의 마이크로서비스를 변경해야 하는 제품 기능을 출시하려면 비용이 많이 듭니다. 각 서비스의 작업 조율, 신규 버전 배포 순서 등을 주의 깊게 관리해야 하죠. 이는 단일 서비스(또는 모놀리스) 내부에서 동일한 변경을 수행하는 것보다 훨씬 더 많은 작업이 필요하기 때문에 가능한 한 서비스 간 변경을 적게 수행할 수 있는 방법을 선호합니다. 

 

 

 

 위 그림의 3계층 아키텍처three-tiered architecture로 대표되는 계층형 아키텍처를 자주 볼 수 있습니다. 아키텍처의 각 계층은 관련된 기술적 기능을 기반으로 하는 각 서비스 경계를 포함해 서로 다른 서비스 경계를 나타내죠.  예시에서 프레젠테이션 계층만 변경해야 한다면 상당히 효율적 일 것입니다. 하지만 경험적으로 이 유형의 아키텍처에서 기능 변경은 대개 여러 계층에 걸쳐 나타나 프레젠테이션, 애플리케이션, 데이터 계층의 변경이 필요합니다. 이러한 문제는 아키텍처가 그림의 간단한 예보다 훨씬 더 계층화되면 심각해집니다. 각 계층은 더 많은 계층으로 분할될 때가 많기 때문이죠.

여기서 서비스를 비즈니스 기능 단위로(수직으로) 처음부터 끝까지 한 조각으로 만들면, 비즈니스 기능을 최대한 효율적으로 변경하도록 아키텍처를 배치할 수 있습니다. 우리는 마이크로서비스에서 기술적 기능의 높은 응집력보다 비즈니스 기능의 높은 응집력을 더 우선시하기로 결정했습니다.

 

3. 자기 상태 소유

​

마이크로서비스가 공유 데이터베이스 사용을 피해야 한다는 생각은 많은 사람을 힘들게 합니다. 한 마이크로서비스가 다른 마이크로서비스가 소유한 데이터에 액세스하려면 두 번째 마이크로 서비스에 데이터를 요청해야 합니다. 이는 마이크로서비스에 어떤 데이터를 공유하고 감출지 결정하는 능력을 제공하므로 자유롭게 변경할 수 있는 기능(내부구현)과 거의 변경하지 않는 기능(소비자가 사용하는 외부 계약)을 명확히 분리할 수 있게 합니다. 

독립적 배포성을 실현하려면 마이크로서비스에 대한 하위 호환성이 없는 변경을 제한해야 합니다. 만약 업스트림 소비자와의 호환성을 깨뜨리면 소비자들에게도 변경을 강요할 것입니다. 마이크로서비스에 대한 내부 구현 상세와 외부 계약을 명확하게 구분하면 하위 호환성이 없는 변경 을 줄이는 데 도움이 됩니다.

 

 마이크로서비스에서 내부 상태를 감추는 것은 객체 지향 프로그래밍object-oriented programming의 캡슐화encapsulation와 유사하죠. 객체 지향object-oriented (OO) 시스템에서 데이터 캡슐화는 정보 은닉의 실제 예시입니다.

​

Tip. 정말 필요한 경우가 아니라면 데이터베이스를 공유하지 말고, 공유를 회피하기 위해 할 수 있는 모든 것을 수행하세요. 데이터베이스 공유는 독립적 배포성을 달성하는 데 가장 나쁜 것 중 하나입니다.

 

필자는 서비스를 적절한 경우에 사용자 인터페이스, 비즈니스 로직, 데이터를 캡슐화하는 비즈니스 기능 단위 조각으로 간주하려고 합니다. 비즈니스와 관련된 기능을 변경하는 노력을 줄이고 싶기 때문입니다. 이러한 방식으로 데이터와 동작을 캡슐화하면 비즈니스 기능에 대한 높은 응집력을 얻을 수 있죠. 또한 서비스의 데이터베이스를 숨김으로써 결합도도 낮출 수 있습니다.

 

4. 크기

​

“마이크로서비스는 얼마나 커야 할까요?” 가장 많이 듣는 질문 중 하나입니다. 이름에 ‘마이크로micro’라는 단어가 있다는 걸 고려하면 놀라운 일은 아닙니다. 하지만 마이크로서비스가 아키텍처의 한 종류로 동작하게 만드는 요소를 알아 보면, 실제로 크기 개념은 가장 흥미롭지 않은 측면 중 하나입니다. 

크기를 어떻게 측정할까? 코드 줄 수를 세야 할까?는 결코 합리적이지 않은 생각입니다. 자바Java에서 25줄이 필요한 코드를 클로저Clojure에서는 단 10줄로 작성할 수 있다고 해서 클로저가 자바보다 좋거나 나쁘다는 말은 아닌 것 처럼요.

(...)

결과적으로 크기의 개념은 상황에 크게 좌우됩니다. 마이크로서비스 전환에 막 착수해서10개 이하의 마이크로서비스를 가진 회사와 수년 동안 마이크로서비스를 늘 수행하고 현재는 수백 개의 마이크로서비스를 보유한 회사에 크기에 대한 생각을 물으면 답변이 서로 다른 것처럼 말이죠.

크기에 대한 걱정은 접어두라고 얘기하고 싶습니다.

처음 시작할 때는 두 가지 핵심 사항에 집중 하는 것이 훨씬 더 중요합니다. 

첫째, 얼마나 많은 마이크로서비스를 처리할 수 있는가? 

둘째, 모든 것이 끔찍하게 결합돼 엉망인 상황을 피하면서

마이크로서비스 경계를 최대한 활용하려면 어떻게 경계를 정의해야 하는가?

이러한 주제야말로 마이크로서비스로 향하는 여정을 시작할 때 집중해야 하는 훨씬 더 중요한 것들입니다.

 

5. 유연성

​

마이크로서비스는 비용이 들기 때문에 그 비용이 선택하려는 옵션의 가치에 견줘 적당한지 따져봐야 합니다. 그 결과로 얻는 유연성은 조직성, 기술성, 규모, 견고함 등 여러 측면에서 놀라울 정도로 매력적일 수 있습니다. 

미래가 어떻게 될지 모르므로 필자는 앞으로 직면할 모든 문제를 해결하는 데 유용할 아키텍처를 원합니다. 선택의 폭을 넓히는 것과 이와 같은 아키텍처에 대한 비용 부담 사이에서 균형을 찾는 것은 매우 절묘한 일이죠.

마이크로서비스 채택은 ‘스위치를 켜는 것’이 아니라 ‘다이얼을 돌리는 것’과 같다고 생각해야 합니다. 다이얼을 높은 쪽으로 돌리고 더 많은 마이크로서비스를 사용할수록 유연성은 높아지지만 그만큼 고충도 늘어나게 되죠. 이러한 이유로 필자는 점진적인 마이크로서비스 채택을 강력히 지지합니다. 다이얼을 조금씩 돌려 소리를 키우듯, 점진적으로 적용하면 수행 영향도를 더 잘 판단하고 필요한 경우 중지할 수도 있으니까요.

 

6. 아키텍처와 조직의 정렬

​

과거 IT 조직은 핵심 역량을 기준으로 사람들을 그룹화했습니다. 예를 들어, 데이터베이스 관리자끼리 한 팀에, 자바 개발자끼리 한 팀으로 구성했죠. 또한 프론트엔드 개발자(최근 자바스크립트와 네이티브 모바일 애플리케이션 개발 같은 색다른 기술을 알고 있는)로 구성된 별도의 팀도 있었죠. 우리는 핵심 역랑을 기반으로 사람들을 그룹화하므로 이러한 팀들에 맞춰진 IT 자산을 만들어냈습니다. 

이 현상은 3계층 아키텍처가 널리 일반화된 이유를 설명합니다. 이 아키텍처가 나쁜 것이 아니라 일련의 힘, 즉 친숙함을 중심으로 사람들을 그룹화하는 전통적인 방식과 같은 힘에 최적화된 것 뿐입니다. 하지만 이제 그 힘이 달라졌습니다. 소프트웨어에 대한 우리의 바람이 바뀌었죠. 이제 핸드 오프와 사일로silo를 줄이기 위해 사람들을 다양한 기술을 갖춘 팀poly-skilled team으로 묶습니다. 또한 그 어느 때보다 훨씬 더 빨리 소프트웨어를 출시하길 원합니다. 이런 변화는 팀을 구성하는 방식 을 다양하게 선택할 수 있도록 했으며, 결국 시스템을 분해하는 방식으로 팀을 구성할 수 있게 되었습니다.

 

---

 

위 콘텐츠는  『마이크로서비스 아키텍처 구축 (전면 개정판)』 내용 중 일부를 편집하여 작성되었습니다.  

 

 

『마이크로서비스 아키텍처 구축 (전면 개정판)』