마이크로서비스란?

해당 내용은 마이크로서비스 아키텍쳐 구축 책의 내용을 일부분을 정리한 포스트입니다.

들어가기

제가 근무하는 회사에서는 여전히 모놀리틱으로 구축되어 있고, 아직도 기억이 생생합니다. 근무중인 회사에서 인턴 당시, 어떤 팀장님께서 저를 시험하듯이 이런 질문을 했던적이 있었습니다.

"마이크로서비스의 반대가 무엇인지 아는가?" 

모놀리틱이라고 대답해서 칭찬을 받았었는데, 지금 생각해보면- 조금 기분이 언짢은 질문이라는 생각이 든다.

지금의 회사에 근무한지 2년이 지난 시점에 단, 한번도 MSA를 접해본 적도 없고, 이해하기 위한 노력이 필요하지 않았습니다. 그러나, 점차 서비스 개발 양상이 MSA로 번지고 있고, 이제는 커다란 줄기를 형성하고 있다고 생각했습니다.

그래서 주변에 추천을 받아 마이크로서비스 아키텍쳐 구축

읽어보면서 마이크로서비스란 무엇인지 이해하기 위한 노력을 하려고 합니다.

그 중의 처음 마이크로 서비스란 무엇인지에 대해서 살펴보고, 장점에 대해서 이해하는 내용을 적어내려가볼까 합니다.

마이크로서비스란?

작고 자율적으로 협업하는 서비스

더 자세하게는 작고, 한 가지 일을 잘하는 데 주력하는 서비스

"모놀리식 시스템에서 우리는 코드를 더 응집하고, 추상화 또는 모듈화하면서 앞에서 언급한 위협에 대항한다. 응집력, 즉 관련된 코드들을 함께 그룹화하려는 힘은 마이크로서비스의 중요한 개념이다. 로버트 C 마틴은 단일 책임 원칙 에서 "같은 이유로 변경되는 것들은 한 모으고, 서로 다른 이유로 변경되는 것들은 분리하라." 

마이크로서비스는 독립적인 서비스에 대해 동일한 접근 방식을 취한다. 주어진 기능과 관련 코드들이 명확히 제자리에 있도록 하면서 서비스 경계를 비지니스 경계에 일치시킨다. 그리고 이 서비스의 명확한 경계를 지키면서 서비스가 지나치게 커지는(모든 골칫거리를 만들어내는) 것에 대한 유혹을 회피한다."

라고 책에 쓰여져 있는데,

 이 말은 즉, 서비스의 경계를 하나의 프로젝트 내에서 패키지로 나누는 것이 아닌, 명확한 경계를 지킬 수 있는 동작되는 서비스로 확장시키는 것을 말하는 것을 말합니다.

책에서는 그럼 "얼마나 작아야 작은 것인가?" 라는 질문을 많이 받는다고 합니다.

이 때 이 질문의 답변은 복합적인 종속성도 고려해야 되지만, 정답은 "충분히 작아서 더 이상 작아질 수 없는 크기" 라고 합니다. 

그럼 얼마나 작아야 작은 것이라고 판단할 수 있을까?

저자는 서비스가 작아질수록 마이크로서비스 아키텍쳐의 혜택과 단점은 더 극대화되며, 서비스를 작게 만들면 만들수록 상호의존성에 의한 문제가 줄어든다고 합니다.

마이크로서비스의 주요 혜택들

아래는 책에서 말하는 마이크로서비스의 특징에 대해서 주요 부분만 적어 보았습니다.

1. 기술 이기종성

 "다수의 협업 서비스로 구성된 시스템에서는 각 서비스가 다른 기술을 사용하도록 결정할 수 있다. 이는 결국 최소한의 공통점만을 지닌 표준화된, 만능의 접근 방식을 선택하기보다 각 작업에 적합한 도구를 선택하게 해준다."

2. 회복성

 "회복 공학(resilience engineering) 의 핵심 개념은 '격벽(bulkhead)' - 장애의 전파를 막는 용도 이다. 즉, 한 시스템의 컴포넌트에 장애가 발생하더라도 그 장애가 전파되지 않는다면 해당 문제를 격리하고 나머지 시스템을 계속 작동시킬 수 있다. 서비스의 경계야말로 명확한 격변인 셈이다. 

반대로, 주의해야 될 점으로, 마이크로서비스 시스템이 향상된 회복력을 적절히 수용할 수 있도록 분산 시스템이 마주한 새로운 장애 요인들을 이해해야 한다. 네트워크도 머신처럼 장애가 발생할 수 있는 만큼 이것을 다루는 방법을 이해해야 하며, 소프트웨어의 최종 사용자에게 어떤 영향을 미치는지도 알아야 한다."

3. 확장성

 "하나의 큰 모놀로식 서비스에서는 항상 모든 것을 함께 확장해야 한다. 만약 전체 시스템에서 작은 한 부분만 성능이 떨어지는데, 해당 동작이 거대한 모놀리식 애플리케이션에 묶여 있다면 전체를 한 덩어리처럼 확장해야 한다. 그러나 만약 작은 서비스들로 구성되어 있다면 필요한 서비스만 확장할 수 있다."

4. 배포 용이성

 "무려 백만 줄에 달하는 모놀리식 애플리케이션에서는 한 줄만 수정하더라도 해당 변경을 릴리즈하기 위해 전체 애플리케이션을 배포해야 한다. 이는 막대한 영향을 끼치는 아주 위험한 배포가 될 수 있다. 실제로는 이러한 걱정으로 위험도가 높은 배포는 잘 안하게 된다. 그렇기 때문에 불행하게도 많은 경우의 수차례의 릴리즈를 걸친 수많은 변경 사항이 한꺼번에 반영된 버전의 애플리케이션이 운영 환경에 배포하게 된다.

 그러나, 마이크로서비스를 이용하면 하나의 서비스만 변경할 수 있고, 나머지 시스템과 독립적으로 배포할 수 있다. 코드를 더 신속히 배포할 수 있고, 문제가 발생하더라도 손쉽게 개별 서비스만 롤백함으로써 해당 문제를 격리할 수 있다. 이는 새로운 기능을 고객에게 더 신속히 전할 수 있다는 것을 의미한다."

5. 조직 부합성

 "아키텍처를 조직 구조에 맞게 더 적절히 정렬할 수 있고, 최적의 팀 크기와 생산성을 위해 하나의 코드베이스에서 일하는 인원을 최소화할 수 있다. 그리고 같은 곳에 있는 서비스 소유권을 팀 간에 디전할 수도 있다".

6. 조합성

  "분산 시스템과 서비스 지향 아키텍처의 주요 장점중 하나는 기능을 재사용할 기회가 많다는 것이다. 마이크로서비스를 통해 다양한 방법과 목적으로 우리가 제공하는 기능이 소비되도록 할 수 있다.

...

 외부에서 직접 접근할 수 있는 시스템의 접합부(seam)를 마이크로서비스로 개방한다고 생각해보자. 환경이 바뀌면 다른 방식으로 구축할 수 있다. 모놀리식 애플리케이션은 외부에서 사용할 수 있는 하나의 큰 접합부를 가지고 있다. 그 하나의 접합부를 끊어내 외부에서 접근하기 더 유용한 것을 만들려면 아마도 우리는 모든 시스템을 다 때려 부숴야 할 것이다!"

7. 대체 가능성을 위한 최적화

  각 서비스가 작은 크기로 이루어져 있다면 더 나은 구현으로 교체하는 비용을 줄일 수 있으며, 심지어 삭제도 쉽게 할 수 있다. 하루에 100줄 이상을 삭제하고도 크게 염려하지 않았던 때가 과연 얼마나 될까? 마이크로서비스는 대개 비슷한 크기로 이루어지므로 서비스를 재작성하거나 삭제하기 매우 쉽다.

 마이크로서비스 방식을 사용하는 팀은 필요한 경우 서비스를 완전히 재작성하는 것을 편하게 생각하며, 서비스가 더 이상 필요치 않으면 쉽게 제거할 수 있다. 코드베이스가 단지 몇 백 줄 규모일 때 개발자들은 자기가 쓴 코드이더라도 집작하지 않으며 교체 비용 또한 매우 작다.

 

[참고자료]

1. github.com/namhoangduc99/TargetOf2018/blob/master/Sam%20Newman-Building%20Microservices-O'Reilly%20Media%20(2015).pdf

2. www.hanbit.co.kr/media/channel/view.html?cms_code=CMS3765870634