마이크로서비스는 소프트웨어 개발 아키텍처 패턴 중 하나로, 하나의 애플리케이션을 작은 단위로 쪼개어 각각이 독립적으로 배포, 운영, 확장될 수 있도록 만드는 것. 이러한 단위를 마이크로서비스라고 부르며, 각각의 마이크로서비스는 명확한 비즈니스 기능을 제공하도록 설계

📖 1. 마이크로서비스 기원? 2. 마이크로서비스 특징과 장점 3. 마이크로서비스 단점

마이크로서비스 기원

처음 모든 웹서비스는 Monolithic 구조로 개발을 해왔다 Monolithic 구조는 빠르게 구축할 수 있는 장점이 있으며 또한 하나의 단일체(Monolithic) 구조이기 때문에 관리가 수월하며, 테스트 및 배포가 간편하고, 서비스 장애 발생 시 장애 파악이 용이하다 하지만 단일체(Monolithic) 구조의 접근방식은 점차 서비스가 확장되고 규모가 커지면서 몇 가지 한계가 나타난다.

1. 대부분의 개발자는 전체 시스템의 구조를알지 못하기 때문에 재활용 가능한 모듈을 방치한 채 중복된 개발로 코드를 계속적으로 추가하게 되며, 이로 인해 사용하지 않는 코드는 계속 증가하고, 파악하기 힘든 모듈 간의 연계성으로 시스템은 점점 더 복잡해진다. 이로 인해 개발자는 버그 수정 및 새로운 기능구현에 어려움을 겪을 수 있으며, 수정을 하더라도 본인의 의도치 않은 또 다른 버그를 만들어낼 가능성이 존재한다.
2. 어플리케이션의 빌드 및 배포시간, 서버의 기동에 많은 시간이 소요된다. 단일 어플리케이션 중 일부 프로그램만 수정하려고 해도 관련 없는 기능들까지 단일 애플리케이션이 빌드 되어 다시 배포되어야 한다. 또한 변경 배포에 따른 영향도를 파악하기 위해 직접적으로관련 없는 많은 사람의 노력과 시간을 할애해야 하며, 서비스의 연속성을위해 2중화, 3중화 되어 있는 장비에 순차적으로 배포하고 재기동하는 시간이 수십 분에서 수 시간 정도 소요
3. 어느 한 기능에서 장애 발생 시 전체 시스템에 영향을 줄 수 있다. 잘못된 코드를 배포하거나 트래픽 증가로 인하여 서비스 성능에 문제가 있을 때, 서비스 전체의 장애로 확대되는 경우가 발생할 수 있다
4. 프로젝트 팀 간의 경계에는 방치되는 영역이 존재할 수 있으며, 이것은 프로젝트의 리스크로 작용 할 수 있다. 모놀리스 형태의 프로젝트에서는 일반적으로 아키텍처팀, 공통팀, 프론트 개발팀, 백엔드 개발팀, 디자인팀, 기획팀 등으로 구성된다. 이들 사이의 경계에는 애매한 업무영역이 존재하게 되는데 이 업무를 어느 팀에서 맡을 것인가의 문제로 각팀 간의 감정싸움이 일어날 수 있으며, 이로 인해 무의미한 시간이 소요된다.
5. 대부분의 프로젝트는 개발팀과 운영팀이 다르다. 실제 개발팀에서는 프로젝트 종료 후 운영팀에 업무를 인계하게 되는데 버그 및 기능 수정사항 발생 시 실제 개발에 참여하지 않은 운영팀 개발자가 업무를 진행하는데 어려움이 발생할 수 있다.

그래서 생겨난 SOA(Service Oriented Architecture)

SOA란 기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 지니는 기능 단위로 묶고, 표준화된 호출 인터페이스를 통해서 서비스(소프트웨어 컴포넌트) 단위로 재조합한 후, 이 서비스들을 다시 서로 조합(Orchestration)하여 애플리케이션을 만들어내는 소프트웨어 아키텍쳐 즉, 애플리케이션의 개발의 측면보다 서비스를 조합하거나 분리하는 데 중점을 두는 방식

SOA는 조직의 기민성(시장의 빠른 대처)과 기존 자산을 이용할 수 있다는 점으로 인한 비용절감 효과, 프로세스 중심의 아키텍처 등의 여러 장점으로 많은 기업의 관심을 받아왔다.

하지만 SOA를 도입한 기업에서 많은 비용을 투자했지만 IT시스템은 예전과 크게 달라진 바가 없으며, 오히려 비용은 더 많이 들고 프로젝트 기간은 더 오래 소요되며, 많은 취약점을 지닌 시스템이라는 것이다. 결과적으로 SOA는 약속된 이익을 제공하지 못했다 또한 기업들이 SOA를 도입하려는 근본적인 이유는 ‘서비스’ 관점에 있는데, IT업체들은 여전히 ‘기술’과 ‘아키텍처’만의 접근 방식을 논했기 때문이라는 견해도 있다

Monolithic Architecture → Service Oriented Architecture → Micro Service Architecture

서비스 구조는 위와 같이 진화했으며 이는 MSA(Micro Service Architecture)로 이어진다.

마이크로서비스 특징과 장점

이름에서도 알 수 있듯이 ‘작은 서비스’를 지향

작은 서비스들이 모여 비즈니스 단위를 이루며 작게 분할된 서비스는 독립적인 팀 조직으로 연결된다. 예를 들면 기존 모놀리스 방식에서는 서고관리라는 하나의 대메뉴 안에 포함되었던 서브 기능들이 서고배치, 반출반입, 정수점검 등 각기 독립적으로 모듈화 되며, 이 서비스들은 각각의 독립적인 팀 조직이기도 한 것이다. 이렇게 규모가 작은 서비스는 더 이상 기능이 필요가 없어지거나 시간이 지나 레거시 시스템으로 바뀔 때 타 서비스로의 교체 및 삭제가 수월하며, 개발 및 운영자는 유지보수가 수월하다.

각 서비스는 REST API를 통해 통신하며, 클라이언트(Web UI)는 API Gateway를 통해 각 서비스들의 데이터를 전달받아 화면에 출력한다. 각각의 마이크로서비스들은 자체 데이터베이스를 보유하며 크기는 작지만 각각의 서비스는 하나의 애플리케이션형태로 작은 모놀리스 형태와 유사한 구조를 갖는다. 하나의 큰 대형 애플리케이션을 작은 서비스로 분리한 형태의 구조

강력하고 효율적인 모듈화 개념을 제공한다. 기존 모놀리스 환경에서는 관련 없는 기능들 간의 의존성으로 한 가지 기능에 대한 개선작업이라 하더라도 다른 여러 기능에 발생 가능한 영향도를 체크해야만 했다. 반면 마이크로서비스는 분산 통신을 통해서만 다른 마이크로서비스를 호출할 수 있기 때문에 마이크로서비스 사이의 의도하지 않은 의존성이 발생할 가능성이 적다. 또한 특정 서비스에 장애발생 시 모듈(서비스)간의 독립성으로 인해 해당 서비스에만 제한적으로 영향을 미친다.

다른 서비스와의 의존성이 적다. 하나의 서비스는 기능적으로 응집되며, 단 한 가지 목적에 집중된 서비스이므로 코드는 단순 명확해지고, 오류발생 확률도 최소화된다. 기존 모놀리스 시스템에서는 타 기능과의 의존성으로 추가 개발이 힘들고, 배포 시에도 전체시스템을 대상으로 해야만 했다. 그러나 마이크로서비스에서는 변경이 필요한 서비스만 독립적으로 기능 개선이 가능하며, 필요한 서비스만 배포가 가능하다. 또한 부하가 집중되는 특정 기능 때문에 전체 애플리케이션을 대상으로 스케일 아웃(Scaleout)할 필요가 없으며 각 서비스의 특성에 맞게 자원을 할당할 수 있어 효율적인 자원 활용이 가능하다.

각 마이크로서비스는 서로 다른 기술로 구현할 수 있는 유연성을 제공한다. 마이크로서비스는 자유롭게 언어 선택이 가능하며 다양한 플랫폼에서 구현 가능하다. 예

마이크로서비스는 네트워크를 통해 통신한다. 이를 위해 마이크로서비스는 REST나 메시징(messaging) 같은 느슨한 결합(Loosely Coupled)을 지원하는 프로토콜을 사용

마이크로서비스 단점

마이크로서비스는 분산 시스템(distributes system)이라는 것이다. 마이크로서비스 사이의 호출은 네트워크를 통해 이루어지기 때문에 마이크로서비스가 많으면 많을수록 지연 시간에 영향을 주며, 응답시간은 빠르지않다. (단순히 통신 속도를 개선하기 위한 개발이 추가되어야 하며, 네트워크 최적화가 반드시 선결되어야 한다는 뜻)

모든 클라이언트의 요청은 API Gateway를 통해서 처리된다. 따라서 클라이언트는 API Gateway로 요청하고, API Gateway는 받은 요청을 필요한 마이크로서비스에 요청하여 결과 값을 받아 다시 클라이언트로 보내게된다. 그러나 이런 호출이 단순하게만 이뤄지지 않는다는 점에서 문제

마이크로서비스 간의 리팩토링(Refactoring)[코드의 동작이나 의도는 유지하면서 코드의 구조, 재사용성, 가독성을 수정하여 전체 디자인을 개선하는 방법]은 어려움이 따른다. 하나의 마이크로서비스는 그 크기가 작으므로 리팩토링이 간단하다. 그러나 마이크로서비스 사이에서는 상황이 다르다. 한 마이크로서비스에서 다른 마이크로서비스로 기능을 이전하는 것은 매우 복잡한 작업이며, 심지어 마이크로서비스간에는 기술 및 프로그래밍 언어도 다를 수 있다. 이에 따라 리팩토링의 경우, 기능은 새로운 마이크로서비스로 이동되어야 하며, 어떤 경우에는 반드시 다른 마이크로서비스의 기술로 새로 구현되어야 하며그 이후에 해당 마이크로서비스로 이전되어야 한다

마이크로서비스간의 통신은 네트워크를 통해 이루어지기 때문에 신뢰할 수 없다. 장애가 발생할 가능성을 염두한 시나리오를 준비해야 하며, 준비된 시나리오에 따라 장애를 신속하게 감지하고 대응할 수 있어야 한다. 예를 들어 RestTemplate으로 통신하는 서버가 통신장애로 응답하지 못하는 상황이 발생하면 이를 타임아웃 기능을 적용하여 경로를 변경

MSA와 같은 분산시스템에서 모니터링 시스템 구축의 어려움 모놀리스 시스템에서는 장애가 발생한 경우분석을 시작할 수 있는명확한 출발점이 있다. 또한 시스템의 로그를 분석하여 각종 에러에 대응 할 수 있다. 하지만 MSA에서는 상호의존성이 있으므로 때로는 매우 어려운 작업이 될 수 있다.

마이크로서비스는 일반적으로 경량급 JSON, REST API를 통해 서로 통신하는데 경량급 API는 더 유연하고 확장하기 쉽지만, 모니터링이 필요한 새로운 인터페이스를 추가했을 때 문제를 일으키거나 버그를 유발하기도 한다

팀의 크기가 상한을 결정한다. 마이크로서비스는 결코 여러 팀의 작업이 필요할 만큼 커져서는 안된다.

마틴 파울러는 “기술적인 숙련도가 부족한 팀은 항상 낮은 수준의 제품만 만들며, 이러한 팀이 마이크로서비스를 적용했을 때의 결과는 더 안 좋을 수 있다.”고 말한다. IT 컨설턴트 조대협도 “충분한 능력을 가지지 못한팀이 MSA로 시스템을 개발할 경우에는 많은 시행착오를 겪을 수 있다”고 경고

마이크로서비스 아키텍처 구축 시 고려사항

수잔 파울러(Susan Fowler)는 인포큐와의 인터뷰에서 “대부분의 중소기업은 마이크로서비스 아키텍처를 채택하는 게 반드시 도움이 되지는 않을 것이며, 대부분의 회사는 기존 시스템을 마이크로서비스로 전환하지 않아야 한다.”는 자신의 견해를 전했다. 그녀에 따르면 마이크로서비스가 정말 잘 작동하는 몇 가지 사례는 시스템이 다소 복잡하지만 많은 기능 간에 매우 명확한 경계 구분이 가능한 시스템이거나, 응용 프로그램이 더 이상 확장성이 없는 한계 지점에 도달하고, 그 한계로 인해 심각한 성능 및 안정성 문제가 발생하여 응용 프로그램 및 개발자의 생산 속도가 더는 효율적이지 않을 때 이다.

즉 마이크로서비스는 복잡한 시스템에서만 유용

단지 신기술이라는 이유로 마이크로서비스를 도입하는 것은 매우 위험한 시도일 수 있다. 복잡한 애플리케이션을 소규모의 간단한 서비스로 분해해도 서비스를 실행하고 관리하는데 필요한 아키텍처는 몇 가지 큰 문제에 직면할 수 있다.