1. Introduction to Microservices

2017-01-27

Introduction to Microservices

어플리케이션이 소스양도 많고, 기능도 많고, 너무 복잡해진다.
한 개발자가 이해해야되는 범위가 너무 크다.
타 업무간 소스 직접 참조, DB Join등.. dependency가 높아진다.
일부만 수정하려고 할때 혹은 버그를 수정하려고 할때,
소스는 이해하기 어렵고, 새로운 기능을 어디에 넣어야 할지도 판단하기 어렵고,
다른 모듈에 영향을 줄 수도 있고(테스트는 또 언제해..ㅎㄷㄷ)
심지어 전체 서비스를 재배포, 재시작해야됨.
그런데.. 서버 기동시간이 너무 오래걸림.
만약 CPU를 많이 쓰는 모듈이랑 Memory를 많이 쓰는 모듈이 같이 있을때..
Scale out 어떻게?? 하드웨어 자원 낭비..
특정 모듈의 문제(bug, memory leak..)가 전체 시스템에 영향을 줌
새로운 기술, 언어, 프레임워크 등을 적용하기 어려움 -> 시간이 지나면 개발자 고용이 어려움..
이런 상황에서.. agile한 development, deployment, delivery가 가능할 까..??
차세대가 답일까??

fig

MSA는 쉽게 말해서 Scale Cube에서 Y축 확장을 의미한다.
서비스는 비지니스 로직을 가지고 자신의 hexagonal architecture를 갖는 작은 어플리케이션이다.
각 서비스는 자신의 기능을 API를 통해 노출하거나 Web UI를 제공한다.
Agile 한 어플리케이션의 개발, 배포를 위해 서비스로 잘 나누는 것이 목적이다.
각 서비스는 db schema를 공유하기 보다는 자신의 schema or database를 갖는다.
심지어 다른 종류의 database 를 사용 할 수도 있다.(polyglot persistence)
이는 중복 데이타를 가질 수 도 있지만, 서비스간 느슨한 결합(loose coupling)을 보장한다.
다른 서비스의 데이터에 대한 CRUD는 그 서비스의 API를 통해서 한다.

거대한 Monolithic 어플리케이션을 서비스들로 나눈다.
각 서비스는 API를 통해서 boundary를 잘 나눌 수 있고, 이를 통해 잘 모듈화 할 수 있다.
이를 통해 더 빠르게 개발할 수 있고, 소스를 이해하거나 유지보수하기 쉬워진다.
한 서비스 개발팀은 자신의 서비스에만 집중해서 독립적으로 개발을 한다.
개발자는 API 계약만 잘 유지 한다면, 내부적으로는 의미있는 기술을 자유롭게 사용 할 수 있다.
각 서비스를 독립적으로 배포할 수 있다. 빠르게 테스트하고 배포 할 수 있다.
각 서비스 별로 독립적으로 확장(scale out)될 수 있다.
그리고 각 서비스에 맞는 리소스 자원을 선택하여 하드웨어를 구성할 수 있다.

there are no silver bullets

Microservices라는 이름때문에 service의 크기(size)가 너무 강조된다.
서비스가 작으면 좋지만, 그게 최종 목적이 되면 안된다. Line of Code는 중요하지 않은데..
Microservices 어플리케이션은 분산시스템(distributed system)에서 동작하기 때문에 매우 복잡하다.
서비스간 통신을 위해 여러 통신방법을 선택, 구현해야 될 뿐만 아니라, 서비스 실패를 고려한 개발을 해야된다.
그냥 method 호출하던 방식에 비해 매우 복잡하다.
MSA는 partitioned database architecture 를 갖기 때문에, 비지니스 트랜젝션을 보장하기 어렵다.
분산 트랜젝션을 사용하는 것은 일반적이지 않고 eventual consistency 를 사용하게 될 것이다.
테스트 하기 너무 복잡하다.
서비스간 dependency가 존재한 다면, 변경에 주의를 기울여야 한다.
배포하는 것이 복잡하다. 각 서비스나 database의 host,port를 설정하기 어렵다. 너무 많고 자주 바뀌기 때문에..
service discovery 메카니즘이 필요하고, 매우 높은 수준의 자동화가 필요하다.