마이크로서비스 구축

마이크로서비스 아키텍처는 서로 연결된 미세한 도메인별 작업을 수행하는 여러 컴포넌트로 구성된 애플리케이션을 구축하는 방식을 제공한다. 

이 아키텍처는 애플리케이션 전체를 한 덩어리로 디플로이하는 monolithic 한 애플리케이션을 만드는 전통적인 기법과 상반된 기법이다. 

마이크로서비스는 각 부분을 물리적으로 분리함으로써 개발과 테스트, 배포, 갱신이 더 쉬운 모듈화된 개발을 돕는다. 

 

마이크로서비스 아키텍처의 아이디어는 monolithic 애플리케이션을 느슨하게 결합된 경량 서비스들의 집합으로 바꾸는 것이다. 

각 서비스는 구체적인 작업을 수행하며, 잘 정의된 프로토콜을 사용해 다른 서비스와 통신한다. 

 

* monolithic 애플리케이션의 단점

- 애플리케이션 크기가 커짐에 따라 몇 가지 문제가 발생한다.

- 코드 기반을 변경하면 그 변경이 새 기능을 구현해 추가하는 것이든 기존 코드의 버그를 변경하는 것이든 관계없이 전체 애플리케이션을 갱신하고 다시 디플로이해야 하며, 기능을 추가함에 따라 전체 애플리케이션을 시작하는 데 걸리는 시간이 길어지고 새로운 버그가 생길 여지가 있다. 

- 모놀리식 구조는 애플리케이션의 규모 확장을 방해하기도 한다. 

- 모놀리식 접근 방법을 택하면 전체 애플리케이션의 규모를 한꺼번에 확장시켜야 하는데, 어떤 특정 모듈이나 기능의 규모를 확장시키는 것보다 분명 더 어려운 일이다. 

- 모든 백엔드 모듈이 한 프로세스로 실행되기 때문에 애플리케이션이 메모리 누출이나 다른 종류의 버그에 대해 더 취약해진다. 

 

이런 문제를 해결하기 위해 서비스 기반 아키텍처 (Service Oriented Architecture, SOA)가 제안됐다.

SOA는 모놀리식 애플리케이션을 별도로 개발하고 갱신하며 대부분 독립적으로 디플로이될 수 있는 완결성 있는 서비스들의 집합으로 분해한다. SOA와 마이크로서비스는 거의 동의어처럼 쓰인다. 

 

마이크로서비스 아키텍처를 보면, 원래 설계의 모듈이 HTTP 같은 네트워크 기반 프로토콜을 사용하는, 같은 기능의 서비스로 대치됐다는 사실을 알 수 있다. 

이제 각각의 서비스를 좀 더 독집적으로 개발, 갱신, 설정할 수 있다. 

그리고 심지어 각 서비스는 서로 다른 DBMS를 통해 관리되는 데이터베이스를 사용할 수도 있다. 

 

마이크로서비스의 개념이 엄밀하게 정의돼 있지는 않지만, 실용적인 마이크로서비스는 몇 가지 공통적인 원칙을 바탕으로 구현한다. 

- 각 마이크로서비스는 전자 상거래 예제의 상품 카탈로그 관리, 사용자 쇼핑 카트 관리 등과 같이 어떤 도메인의 구체적인 작업을 수행한다. 

- 마이크로서비스는 잘 정의된 프로토콜을 사용해 서로 통신하며, 이 프로토콜은 각 서비스의 API를 구성한다. 가장 일반적인 경우는 HTTP와 XML이나 JSON 형식을 엮어서 복잡한 데이터를 전송하거나 RPC(원격 프로시저 호출) 기반의 프로토콜을 사용하는 것이다. 

- 마이크로서비스들은 서로 독립적으로 버전을 부여하고, 디플로이되며, 갱신된다.