본 글은 찰스 페발의 블로그의 글을 번역한 것이다.

굳이 마이크로 서비스가 필요하지 않는 상황에서도 “마법의 키워드”와 같이 마이크로 서비스를 꼭! 해야 한다는 상황에서 정말 그래야 하는지 고민해 볼 필요가 있다.

마이크로 서비스란?

마이크로 서비스에는 많은 정의가 있다. 일반적으로는 아래와 같이 요약된다.

• 마이크로 서비스는 구성 요소 설계 및 배치 아키텍처에 적용 되는 패턴이다.
• 서비스를 작게 유지하고 기능별로 그룹화 한다.
• 관심사를 분리하여 구현한다.
• 서로 자율적으로 분리되어 있어야 한다.
• 독립적 배포 및 버전을 조정하여 확장할 수 있어야 한다.

마이크로 서비스 패턴의 일반적인 구현은 다음과 같다.

주요 문제는 적용 가능한 패턴의 폭이 상당히 넓다는 것이다. 그렇기 때문에 마이크로 서비스를 선택하는 것이 최상의 옵션이 아닐 수 있다는 관점을 보려 한다.

마이크로 서비스를 구현하는 데에 있어서 절충점이 존재한다.

마이크로 서비스의 과제

1. 마이크로 서비스는 올바르게 설계 하기가 어렵다.

2. 기술적 복잡성이 포함되어 있다.

몇 가지 고려 사항은 다음과 같다.

• API 수가 증가한다.
• Network bottleneck이 증가한다.
• 여러 서비스간 트랜잭션 관리가 어렵다.
• 분산 환경에서의 디버깅은 어렵다.

비즈니스 기능외에 기술적으로 고려해야 할 항목들이다.

3. 조직이 변경되어야 한다.

Conway의 법칙에 따라 Front/back end 개발자, 데이터 플랫폼 엔지니어, QA, 제품 관리자 및 운영팀이 단일팀으로 혼합되어 있다.

4. 프로세스와 관행의 변화가 필요하다.

마이크로 서비스 아키텍처의 성공 여부는 조직 및 프로세스에 따라 달라지며 이런 부분들을 기존 방식에서 변경하기란 어려운 요소입니다.

5. 모든 전문 분야에 팀의 스킬셋을 확장

분산 시스템, 코드 기반의 인프라, 다양한 유형의 데이터베이스, 단위 테스트, Front-end 구성, 프로덕션 릴리즈, 릴리즈 계획, 제품 테스트등을 팀내에서 이해하고 소화해야 한다.

마이크로 서비스에 심각하게 의문을 제기해야 할 때

1. 응용 프로그램이 너무 작은 경우

현재 시점에 만들어야 할 어플리케이션이 너무 작은 경우에는 ROI 임계 값에 접근할때 마이크로 서비스 전환을 고려 해야 한다.

2. 도메인이 불분명하거나 불확실한 경우

3. 조직은 변경할 수 없다.

Conway의 법칙은 서비스를 계층화 된 아키텍처로 구성하는 것이 합리적이라는 의미이다.

아래의 그림은 각 서비스 별로 혼합팀이 구성되어 있기에, 업무 협업에 큰 문제가 없어 보인다.

아래의 그림에서는 각 팀간 업무 우선순위가 다르기에 팀 간 종속성이 서로 충돌되거나 업무 지연이 발생할 것이다.

4. 마이크로 서비스의 개념 및 설계에 대한 경험과 이해가 부족한 경우

우리는 대부분 새로운 것을 배우는 것을 좋아하지만, 이런 상황은 실수에 대한 시간과 에너지가 필요하다.

5. 성숙되지 않은 스킬을 적용

일반적으로 사람들은 자신이 아는 것으로 대체하려는 습성이 있다. 자신이 알거나 가장 짧은 길을 가면서 복잡성을 피할 것이다.

성숙되지 않은 기술로 도배하면 각 구성요소간 연관된 부분, 복잡성을 이해하기도 어려울 것이다.

운영 및 디버깅의 복잡성으로 인해 효율성이 저하될 가능성도 있다.

하고 싶은 말

구축하려는 서비스에 명확한 도메인이 있고, 각 영역별 혼합된 형태의 팀을 구성할 수 있고, 팀내의 구성원이 기술에 대해 자신감이 있거나 경험이 있을 경우에는 마이크로 서비스로 갈 수 있는 가능성이 높다고 생각한다.

그렇지 않은 경우에는 역효과를 낳을 수 있다는 점을 명심해야 한다. K8S와 같은 컨테이너 플랫폼은 마이크로 서비스 아키텍처 혹은 마이크로 서비스 아키텍처 없이도 사용이 가능하다.

마이크로 서비스는 복잡한 분산 시스템 환경에서는 확실히 적합한 옵션이다. 하지만, 이것이 유일한 것은 아니기에 앞서서 언급한 것들을 고려하여 합리적인 선택을 해야 한다.