Architcecture의 필요성
80년대 초, 큰 규모의 시스템을 설계할 때 직면할 수 있는 공통 문제를 해결하기 위해서 아키텍처나 패턴의 필요성이 대두되었습니다. 가장 처음 등장한 용어는 소프트웨어 아키텍처(Software Architecture)이고, 그 후로 모놀리식 아키텍처, SOA, MSA등 아키텍처 용어들이 탄생 했습니다. 그 중 MSA와 가장 대조 되는 것이 모놀리식 아키텍처(Monolithic Architecture) 입니다.
모놀리식 아키텍처(Monilithic Architecture)
웹 개발을 예로들면, 웹 프로그램을 개발하기 위해서 모듈별로 개발을 하고, 개발이 완료된 웹 어플리케이션을 하나의 결과물로 패키징 하여 배포되는 형태를 말합니다. 이런 어플리케이션을 모놀리식 어플리케이션이라 하며, 웹의 경우 WAR 파일로 빌드되어, WAS에 배포하는 형태를 말합니다.
- 장점
모놀리식 아키텍처의 가장 큰 장점은 심플함(Simple)입니다. 개발, 빌드, 배포, 테스트가 용이하며 빌드된 WAR 파일을 WAS에 올리기만 하면됩니다.
- 단점
지속적인 통합(continuous integration;CI)과 지속적인 배포(continuous delivery;CD)가 어렵고, 모든 모듈이 하나의 프로세스에서 동작하기 때문에, 하나의 모듈이 수정이 되어, 서버를 내렸다 올리게 될 경우 다른 모듈도 그 동안 작동이 불가능한 상태가 됩니다. 또한 확장이슈, 광범위한 운영 로드맵 등 여러 불만이 생기기 마련입니다.
마이크로서비스 아키텍처(MSA)
마이크로서비스(microservice)는 애플리케이션을 느슨히 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다. 마이크로서비스 아키텍처에서 서비스들은 섬세하고 프로토콜은 가벼운 편이다. 애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선시키고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄련적으로 만들어 준다. 규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 한다. 또, 지속적인 리팩토링을 통해 개개의 서비스 아키텍처가 하나로 병합될 수 있게 허용한다. 마이크로서비스 기반 아키텍처는 지속적 배포와 전개를 가능케 한다.
위키피디아에 정의되어 있는 마이크로서비스의 내용입니다. 마이크로서비스를 간략하게 나타내면 한 가지 일만 수행하는 작은 어플리케이션을 말합니다.즉, 쉽게 교체될 수 있고 독립적으로 개발되고 전개될 수 있는 작은 컴포넌트를 의미합니다.
마이크로서비스 아키텍처는 모든 기능을 수행하는 어플리케이션을 구축하는 모놀리식 아키텍처가 가지는 문제를 해결합니다. 마이크로서비스 아키텍처의 가장 기본적인 철학은 “한가지만 아주 잘 처리하자”이며, 단일 책임 원칙(Single Responsibility Principle; SRP)을 중시합니다. 즉, 큰 문제(task, service)들을 작은 문제로 분해하여 해결하는 것이며, 작게 나뉘어진 서비스가 서로에게 영향을 미치지 않고 독립적으로 역할을 수행하게 만드는 것입니다. 따라서 특정 서비스에 에러가 발생해도 다른 서비스에게 영향을 미치지 않게되며, 서비스가 실패할 경우 롤백 매커니즘을 두어, 이전 버전으로 쉽게 되돌릴 수 있어야합니다.
따라서 비지니스 업무를 얼마나 알맞게 잘 나눠서 해결했는지가 중요합니다.마이크로서비스 아키텍처의 장점은, 작게 분해된 서비스들이 같은 언어로 개발될 필요가 없다는 것입니다. 각각의 서비스들은 결합도가 낮게 분리되어있으며, 자신의 역할(비지니스 목적)에 맞게 동작하기 때문입니다. 이렇게 서로에게 영향을 미치지 않기 위해서, 분산 데이터베이스를 둬야 합니다. 즉, 각 모듈(서비스)별로 자신하고만 상호작용을하고 다른 모듈의 DB에는 데이터를 읽거나 수정할 수 없게끔 만드는 것입니다.
마이크로서비스 아키텍처는 지속적인 통합(continuous integration;CI)과 지속적인 배포(continuous delivery;CD)와 , 자동화된 테스트 가 필수 입니다.
위 그림은 마이크로서비스 아키텍처의 장점 중 하나인 확장성 을 나타낸 그림입니다. 확장을 위한 마이크로서비스의 방법은 Y축은 같은 마이크로서비스를 여러개로 분리하며, X축은 같은 마이크로서비스를 여러개로 복제하며, Z축은 데이터를 나눠서 저장Data partitioning합니다. 어플리케이션의 확장이 쉽기 때문에 개발자의 생산성과 속도가 크게 증가하며, 오래된 기술을 최신 기술로 쉽게 교체할 수 있습니다.
마이크로서비스 아키텍처는 각각의 서비스가 오직 자신과 상호작용하는 DB를 가지기 때문에, 서비스마다 DB의 종류도 다르게 가져갈 수 있습니다. 단점은 서비스가 동작하면서 여러 데이터에 영향을 미치기 때문에 각 서비스별로 중복되는 데이터도 생기고, 한 쪽에서 업데이트가 되었는데 다른 쪽에서는 업데이트가 되지 않을 수도 있습니다. 이러한 중복과 정합성 문제가 있지만 결합도를 낮추기 위해서 각각의 DB 를 사용합니다.
모놀리식과 마이크로서비스의 공통점
사용자가 몰려(Traffic) 서비스를 안정적으로 유지하기 위해서 모놀리식과 마이크로서비스의 경우 어플리케이션을 실행하는 서버를 추가함으로써 수평적으로 확장합니다.
클라이언트에서 요청이 들어오면 중간에 로드밸런서(Load Balencer)를 두어서 스케일 아웃(Scale-out)방식으로 서버를 추가하여 확장하게 됩니다.
- 스케일 아웃(Scale-out) : 여러대의 Server로 나누어 일을 처리하는 방법
- 스케일 업(Scale-up) : Server가 더 빠르게 동작하게 하기 위해 하드웨어 성능을 올리는 방법
- 로드 밸런서(Load Balancer) : 스케일 아웃의 장점 중 하나로, 여러 대의 Server에게 균등하게 Traffic을 분산시켜주는 역할을 담당
모놀리식과 마이크로서비스의 차이점
모놀리식 아키텍처의 경우 회사가 성장하고 새로운 기능을 어플리케이션에 추가하는 일이 발생하면서 크게 3가지 이슈가 생기며 다음과 같습니다.
- 운영업무량이 증가(어플리케이션 운영 및 유지보수)
- 새로운 기능 추가에 따른 코드 라인 수와 복잡도 증가
- 불가피하게 어플리케이션을 확장(수직, 수평)
불가피하게 어플리케이션을 확장하기 위해서 로드밸런서를 두어 서버를 추가해서 트래픽 이슈를 해결하는데, 문제는 모놀리식 아키텍처의 경우 모든 서비스(모듈)가 하나의 어플리케이션으로 배포되기 때문에, 예를 들어 특정한 서비스(이벤트, 행사 참여 등)에만 트래픽이 발생해도 서버를 추가할 때 모든 기능이 담겨져있는 어플리케이션 사본 을 운영하는 서버를 추가하여 수평확장을 하며, 수직확장을 위해서 각 호스트 서버의 자원(CPU, RAM)을 늘려 확장하게 됩니다. 이렇게 되면 기존 코드의 무결성을 체크하기 위해서 많은 테스트를 거쳐야 하며 기술적 부채가 늘어나게 됩니다. 이러한 형태를 띄고 있는 어플리케이션을 모놀리스(Monolith)라고 합니다.
반면, 마이크로서비스의 경우 각 기능마다 서버와 DB가 존재하기 때문에, 특정한 서비스에 몰리게 되면 해당 서비스에 대한 수직, 수평확장을 실시하면 되며, 다른 서비스에 대한 무결성을 지킬 수 있습니다. 따라서 기술적 부채의 감소, 개발자 생산성 및 속도 향상, 테스트 효율성 증가, 확장성 증가와 같은 많은 이점들이 있습니다.
모놀리식을 마이크로서비스로 분리하는 방법
모놀리식을 마이크로서비스로 분리하는 방법의 첫 번째 단계는 독립적인 서비스로 만들어져야 하는 컴포넌트를 찾아 식별하는 것입니다. 모놀리스의 전체적인 주요 기능을 정확하게 파악한 후에 작고 독립적인 컴포넌트로 분리해야 합니다. 마이크로서비스는 가능한 한 단순해야 하며, 그렇지 않으면 커다란 모놀리스를 작은 모놀리스로 분리하는 과정밖에 되지 않습니다.
두 번째 단계는 마이크로서비스로 분리하고 나서는 회사의 조직구조도 개선이 되야 합니다.조직구조 개선 중 한 가지 방법은 마이크로서비스마다 한 팀씩 지정하는 방법이 있습니다. 팀의 규모는 마이크로서비스의 복잡도와 업무량에 따라 결정해야 합니다. 다른 방법은 한 팀에 여러개의 마이크로서비스를 할당해서 해당 서비스를 동시에 개발하는 방법이 있습니다. 이 방법은 팀이 특정 제품이나 사업 분야를 중심으로 조직된 경우에 가장 효과가 좋습니다.
세 번째 단계는 마이크로서비스 생태계를 구축해야합니다. 마이크로서비스 개발을 위한 안정적인 인프라를 구축해서 개발 팀에게 제공해야 합니다.
마이크로서비스와 서비스지향아키텍처(SOA)
서비스 지향 아키텍처(Service Oriented Architecture; SOA)란 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해 가는 방법론이다. 업무 처리 변화를 시스템에 빠르게 반영하고자 하는 수요에 대응하기 위해 2004년부터 IT 업계에서 주목을 하고 있다.
SOA는 문제 영역을 서비스로 나누고, SOAP 기반 통신을 사용하며, 사용자는 ESB(Enterprise Service Bus)를 통해서 메세지를 전송합니다. 하지만 SOA 실패에는 ESB가 큰 역할을 했습니다. ESB에 장애가 발생하면 서비스 작동이 잘 안될 수 있으며, 서로 통신할 수 도 없습니다.
SOA 의 인기에 힘입어 벤더들이 파는 다양한 솔루션과 장비들로 인해 SOA 를 구성하는 것이 어려워지고, 인기가 식어감에 따라 SOA 는 더 이상 발전하지 못했습니다. 하지만 마이크로서비스는 중앙집중적인 ESB 대신 RESTful 기반으로 통신하기 때문에, 무거운 미들웨어 통신 채널이 필요 없습니다. 또한 경량화된 메시징을 이용해서 각 서비스 중심으로 처리합니다.
SOA는 가능한 공유가 중요하다는 원칙을 믿기 때문에, 여러 서비스간 리소스 공유를 촉진 시켜, 서비스간의 결합을 증가시키기 때문에, 마이크로 서비스 아키텍처와 대조되며, SOA는 일반적으로 서비스끼리 DB를 공유하지만 마이크로서비스는 서비스마다 각각 DB를 가진다는 점에서 차이점이 있습니다.
마이크로서비스의 단점
마이크로서비스는 작은 서비스단위로 개발하기 때문에, 배포가 어렵고 서비스간 통신방법이 필요하며, 서비스를 나눠서 데이터 중복이 발생할 수 있고 정합성을 보장하기 어렵습니다. 마이크로 서비스 응용 프로그램 테스트도 훨씬 더 복잡합니다. 예를 들어 Spring Boot와 같은 최신 프레임 워크를 사용하면 모 놀리 식 웹 응용 프로그램을 시작하고 REST API를 테스트하는 테스트 클래스를 작성하는 것이 쉽지 않습니다.
결론
마이크로서비스를 적용하기 위해서는 개발자들의 능력과, 회사의 전체적인 분위기도 중요한 것 같습니다. 특히 정부 사업을 따와서 진행하는 웹 개발의 경우, 최신 기술을 적용하기에 어려움이 있으며 회사의 임원진 혹은 개발자 팀원, 팀장들의 성격, 특징등 현재에 안주하고 머무르는 특징을 지니고 있다면, 마이크로서비스 아키텍처가 도입되기 힘들 것입니다. 또한 회사의 규모 등 여러 요소들이 있을 수 있습니다. 마이크로서비스 아키텍처가 무조건 좋다라는것이 아니라, 개발 되어야 하는 프로젝트, 비지니스 업무를 분석해서 마이크로서비스로 개발되어야 회사에 이익을 더 주고, 개발자들의 업무, 유지보수 향상에도 기여할 수 있을때 마이크로서비스 아키텍처를 채택하는 방법이 좋다고 생각합니다.
