1. 마이크로서비스 아키텍처
1.1. 마이크로서비스 아키텍처의 개념
마이크로서비스 아키텍처(microservice architecture)는 마이크로서비스가 실행 될 수 있는 아키텍처를 뜻합니다. 마이크로서비스, 즉 아주 작은 단위로 동작하는 서비스가 구동되도록 시스템 및 소프트웨어의 구성과 구성 요소간의 관계를 정의한 아키텍처입니다.
마이크로서비스 아키텍처의 구성 요소는 서비스와 이를 실행할 수 있게하는 여러 기술적 환경입니다. 마이크로서비스 아키텍처를 다시 한번 정리해보면, 아주 작은 단위의 서비스들을 실행할 수 있도록 구성하기 위한 서비스 중심의 아키텍처입니다.
1.2. 모놀리스 아키텍처와의 차이점
모놀리스 아키텍처 구조에서는 하나의 애플리케이션에 데이터가 연결된 구성이 일반적으로 되어있고, 애플리케이션의 크기가 클 경우 변경과 배포가 쉽지 않은 구조를 띄고 있습니다.
이에반해, 마이크로서비스 아키텍처는 서비스와 데이터가 분할되어 작은 서비스들이 여러 독립된 형태로 서비스를 제공하여 필요에 따라 서로 참고하여 사용됩니다.
즉, 모놀리스 아키텍처와의 차이점은 하나의 애플리케이션 형태가 아닌 분할된 다수의 서비스라는점입니다. 애플리케이션 기능뿐만 아니라 데이터까지 분리하여 격리된 독립된 환경으로 구성되는것이 가장 큰 차이점이 됩니다.
단일 애플리케이션 형태인 모놀리스 아키텍처로 구성된 시스템에서는 클라이언트 요청에 대한 처리 반응 속도가 아주 중요한 요소인데, 데이터 조회에 대한 부하나 이를 처리하는 애플리케이션이 문제가 생긴다면 시스템이 동작하지 않는 결과를 초래합니다.
이것들을 대응하기 위해서는 로드밸런서, 2중화,3중화, 백업 및 복구방안이 아주 중요한 아키텍처 결정 사항이고 환경 구성을 위하여 많은 시스템 리소스(resource)를 투자합니다.
온프로미스 아키텍처
시스템이 받을 부하를 사전에 분석예측하는 하드웨어 스케일업 과정과 애플리케이션의 빠른 대응과 데이터 조회의 성닝 개선을 위한 튜닝(tuning) 활동등이 아키텍트의 주요한 관심사였습니다.
마이크로서비스 아키텍처
서비스의 수평적 확장에 유연성과 탄력성을 높여 성능적 이슈에 대해서 유연하게 대처할 수 있는 구조를 가집니다. 당연히 단일 애플리케이션 구조에서 보다 많은 서비스를 관리하는 문제로 서비스들을 관리하고 제어하기 위한 에코시스템(eco-system)들의 역할이 아주 중요하고, 자동화 시각화가 잘 고려되지않으면 오히려 운영 측면의 위험성은 증가하게 됩니다.
1.3. 서비스 지향 아키텍처
대규모 시스템 환경에서 업무처리 단위를 각가의 서비스로 반영하여 데이터 중심이 아닌 전체 시스템을 서비스 중심으로 설계하는 아키텍처 스타일입니다.
마이크로 서비스가 주목받기 이전부터 기업환경에서 중복되는 프로세스나 업무들을 하나의 서비스단위로 개발하여 각 서비스는 호출 가능한 상태로 개발하자는 노력이 계속되어 왔습니다.
서비스 지향 아키텍처의 특징
- 서비스 계약
서비스와 서비스소비자와의 계약을 뜻합니다.
서비스는 약속한 기능을 수행해야하고 서비스 소비자는 서비스를 사용하기 위한 계약 규칙을 준수해야합니다. 서비스계약은 때에 따라서는 서비스 자체에 문제가 발생할 수도 있고, 서비스가 개선될 수도 있습니다. 버전1 -> 버전2로 기능업그레이드가 가능할 수 있습니다.
- 서비스의 가용성
서비스지향 아키텍처에서 서비스들의 가용성을 보장하기 위한 소프트웨어 방법으로 타임아웃 기능 구현을 제안합니다.
일정 시간동안 서비스 요청에 대한 반응이 없으면 기존 요청경로를 차단하고, 다른 경로로 요청 경로를 변경하는 기능을 가동하여 서비스가 정상적으로 수행되도록 합니다.
정상적으로 동작하던 서비스가 문제가 발생하여 서비스 요청에 대한 응답 지연이 발생하면 정상적인 다른 서비스로 요청 경로를 변경하는 기능이 작동합니다.
즉, 서비스 가용성을 유지하기 위한 방법을 서비스 라우팅이라고 하며 라우팅 기능을 L4/L7은 하드 웨어 장비를 이용하여 구현할 수도 있고, 서킷 브레이커(circuit breaker) 같은 소프트웨어 기능으로 구현할 수 있습니다.
- 보안
하나의 서비스가 다른 서비스를 호출할 경우 별도의 인증 및 권한 확인 없이 바로 호출할 수 있는 구조가 되면 자칫 보안상 문제가 될 수 있습니다. 권한에 관한 제어권을 서비스 자체에 넘기게 되면 이러한 문제는 다소해결 될 수 있습니다.
- 트랜잭션(transaction)
서비스가 분할되고 서비스에서 발생하는 트랜잭션들에 대한 일관성 유지입니다. 일반적으로 서비스 지향 아키텍처에서는 성능상의 문제로 데이터베이스 읽기 전용 데이터 저장소와 데이터베이스 쓰기, 데이터 저장소를 분리 구성하도록 권고합니다. 하지만, 쓰인 데이터를 읽기 위해서는 데이터의 이동이 필요하고 이 부분에서 데이터의 일관성과 실시간 동기화 이슈가 발생학세 됩니다.
BASE(Basically Available Soft State Eventual Consistency)트랜잭션
basically available의 대표적인 기술 메커니즘은 Optional Locking, Queue이고 soft state는 외부전달 데이터로 인해 상태가 갱신되는것 입니다.
즉, 두 개의 노드가 있으면 한쪽에서 전달된 데이터로 인해 다른 한쪽 노드가 갱신된다는 사앙이며 eventual consistency는 두 노드의 데이터가 일시적으로 불일치한 시점이 있고, 일관성이 없는 상태이지만 결국에는 두 노드의 데이터가 같아진다는 개념이 됩니다.
- 서비스 관리
서비스들의 수가 많아지면 이들간의 관계를 관리해야합니다. 상황에 따라서 서비스가 동적으로 증가하여 과부하나 오류 상황에서도 지속적으로 가능한 서비스가 가능하도록 관리됩니다.
특정 서비스의 오류가 발생하면 자연스럽게 다른 정상적인 서비스로 요청 흐름의 변경도 가능하고 실시간으로 관리되고 시각화하여 모니터링이 진행되어야합니다.
1.4. SOA와 마이크로서비스 아키텍처는 무엇이 다를까요?
비즈니스 변화 대응을 위한 서비스 중심의 아키텍처라는 점에서는 공통점이 있지만 서비스 상대적 크기와 관심사, 오너십(ownership) 기술구조에서 차이가 있습니다.
비즈니스 -> SOA, 마이크로서비스 아키텍처
SOA와 마이크로 서비스 아키텍처의 공통점은 소프트웨어를 설계할 때 서비스 중심의 설계를 지향하는것이며 기능 중심의 모듈 재사용보다는 상위 수준의 서비스 수준에 재사용성에 초점을 맞추게됩니다. 다만 SOA는 비즈니스측면에서의 서비스 재사용성을 강조하는 반면에 마이크로서비스는 한가지 작은 서비스에 집중하기를 강조합니다.
SOA는 되도록 많은 서비스의 공유를 위해 ESB(Enterprise Service Bus)라는 서비스 채널을 이용하여 서비스를 공유하고 재사용하는데 초점을 맞춘다면, 마이크로서비스는 되도록 서비스를 공유하지않고 독립되어 실행하는것을 지향합니다. 즉, 시스템의 탄력성을 높입니다.
SOA 마이크로서비스 차이점
- 서비스 상대적 크기와 관심사의 차이점
마이크로서비스아키텍처는 서비스는 작고 한가지 일에 집중하는 반면, SOA서비스는 비즈니스에 집중합니다.
CRM(Customer Relationship Management) 통합 구축 프젝트에서는 고객정보 관리라는 큰 서비스가 있으면 마이크로서비스 관점에서는 고객빌링관리 등의 업무를 더 세분화 시킵니다.
예를 들면, 청구 조회,등록,수정,삭제 서비스, 신용 정보 조회, 등록, 수정, 삭제 등 더 작게 세분화 시킬 수 있습니다.
- 서비스 오너십 측면에서 마이크로서비스는 하나의 작은 팀에서 관리합니다.
서비스의 개발에서 운영까지 오너십과 권한을 가지는 독립된 단위의 서비스이며 조직 구성과도 관련이 있는 부분입니다. 마이크로서비스는 하나의 독립된 팀에서 개발하고 관리하고 반면의 SOA의 서비스는 비즈니스 프로세스의 흐름과 관련된 서비스를 공유하기 위해서 중앙의 인프라 미들웨어에 탑재하고 필요에 따라 연결 및 조합하여 새로운 서비스를 만들어내게 됩니다.
이 과정에서 업무팀, 공통 기능 개발팀, 개발팀의 상호협업이 반드시 필요하게 됩니다.
- 서비스 공유 정도의 차이
마이크로서비스는 서비스 공유의 최소화를 지향하는 반면에 SOA는 되도록 많은 서비스의 공유를 지향합니다.
마이크로 서비스 아키텍처는 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응하기 위한 민첩성에 초점을 두지만, SOA는 재사용을 높여 비용을 절감하고 품질을 높이는데 초점을 두게 됩니다.
- 기술 방식의 차이
SOA가 공통 서비스를 ESB라는 공통된 채널에 모아 사업 측면에서 공통 서비스 형식으로 서비스를 제공하였다면 마이크로 서비스는 각각의 독립된 서비스가 필요에 따라 노출된 REST API(Application Programming Interface)를 사용합니다.
SOA는 흩어져 있던 같은 역할을 하는 서비스들을 통합하여 ESB에 담아서 필요할때마다 사용할 수 있는 기술 구조이고 마이크로 서비스 아키텍처는 흩어져있는 서비스들의 통합없이 각각의 서비스가 노출한 RESTful API정보를 보고 필요할때 호출하여 사용하는것 입니다. 결국 SOA는 통합과 공유 마이크로 서비스 아키텍처는 분산과 독립이라는 개념으로 구분할 수 있습니다.
서비스 메커니즘
SOA는 통합된 서비스들을 UDDI(Universal Description Discovery and Integration)라는 서비스 저장소에 등록하고 WSDL(Web Service Description Langauge)라는 서비스 저장소에 등록하고 WSDL에는 UDDI에 공유한 서비스의 명세가 담겨있고, 이 명세를 참고하여 서비스를 사용하는 클라이언트는 'stub’이라는 클래스를 생성하여 서버와 SOAP(Simple Object Access Protocol)을 이용하여 통신하게 됩니다. 만약 WSDL의 명세가 바뀌면 이를 참조하는 모든 클라이언트 프로그램들을 바꿔야하고 변경이나 장애에 대한 결합도가 아주 높아지게 됩니다.
이해 반해, 마이크로 서비스 아키텍처는 클라이언트에서 서비스 제공자가 노출해놓은 RESTful API를 보고 호출하여 받는 결과값만 활용하므로 구현이 쉽고, 서비스 제공자가 제공하는 서비스의 인터페이스에 대한 변경 영향은 발생하지 않습니다. 서비스 제공자가 제공하는 결과값이 다소 바뀔 수 있어도 그로 인한 영향도는 SOA만큼이나 결합도가 높지 않습니다. 마이크로 서비스 아키텍처와 SOA는 아키텍처의 기술 구조와 다른 아키텍처 스타일이지만, 비즈니스에 민첩한 대응을 위한 아키텍처구조와 아키텍처의 모습이 서비스를 지향해야하고 이를 민첩하게 반응하기 위하여 기술 메커니즘에서는 같은 사상을 가지게 됩니다.
마이크로서비스 아키텍처와 SOA 특징 비교
| 구분 | 마이크로서비스 아키텍처 | SOA |
|---|---|---|
| 사상 | 서비스지향 | 서비스 지향 |
| 서비스 오너십 | 조직(팀)단위 자율성 부여 | 조직간 협업 |
| 서비스 크기 | SOA 대비 작음 | 마이크로서비스아키텍처 대비 큼 |
| 서비스 공유 정보 | 서비스간 독립 | 서비스 공유 |
| 서비스 공유 방식 | API | 서비스공유를 위한 미들웨어 |
| 서비스 통신 방식 | RESTful API | SOAP, WSDL, UDDI, ESB |