마이크로서비스 개념 적용, 역량 모델

• 이 글에서 다루는 내용
• 마이크로서비스 개발할 때 고려해야 할 설계 방안들의 장단점
• 엔터프라이즈 수준의 개발 시 마주치게 되는 난관

1.  마이크로서비스의 단위는 어떻게 되는가?
• 배포 단위의 크기 : 배포 규모가 너무 커지면 배포 자동화와 서비스 구동 시간에 좋지 않은 영향을 미침
• 분리하기에 적합한 기능 찾기 : 일반적인 예약 시스템에서는 50%이상이 검색이다. 이런 검색을 분리시키면 유연성, 자원 절약 등의 효과
• polyglot architecture : 마이크로서비스의 주요 특징 중 하나로, 여러 언어를 사용할 수 있는 것. 즉, 예약 서비스는 트랜젝션 통합이 필요할 것이기 때문에 MySQL을 쓰고, 검색 서비스는 트랜잭션 통합이 필요없기 때문에 NoSQL을 사용할 수 있다.
• 선택적 확장 : 모든 서비스가 동일한 수준의 확장성을 가질 필요는 없다. 예를 들어, 예약 서비스에 비해 검색 서비스는 더 빠른 처리 속도를 필요로 하므로, 검색 서비스는 ElasticSearch나 인메모리를 사용하게 하는 편이 좋다.
• 결합과 응집 : 너무 많은 정보 교환, 동기적 요청-응답 사용, 순환 의존 관계는 시스템을 망가뜨릴 수 있다.
2. 통신 방식 설계
• 동기 방식 통신 
• 장점
• 요청 / 응답 방식에는 공유되는 상태나 객체가 없어 관리에 드는 노력이 적음
• 고가용성 관점에서 보면 많은 인스턴스가 트래픽을 나눠가질 수 있음
• 일관성 유지 가능
• 단점
• 호출하는 스레드가 응답을 기다려야 하는 동기 방식은 시스템 확장성에 걸림돌
• 비동기 방식 통신
• 장점
• 서비스의 결합도가 낮아짐
• 단점
• 외부의 메시징 서버에 의존해야 함  ( 일반적으로 영속성을 사용하게 되므로 더 높은 수준의 I/O 처리와 튜닝 필요 )
• 동기 / 비동기 선택의 기준
• (현실) 동기로 다 개발해놓고 필요하다고 판단될 때 비동기 방식으로 리팩토링 하는 방법
3. 마이크로서비스 오케스트레이션
• 서비스 지향 아키텍처에서 사용하는 방식
• 오케스트레이션 방식 : 오케스트레이션이 중앙 두뇌 역할을 한다. 서비스들을 조립하고 처리한다.
• 연출 방식 : 중앙 두뇌없이 메시지(이벤트)를 통해 독립적으로 서로 다른 로직을 적용한다.
• 마이크로서비스는 자율적임 ( 필요한 컴포넌트가 서비스 내에 존재해야 함 - db, 내부 상태 관리 등 )
• 마이크로서비스에서는 연출 방식이 더 적절함
• Example : 예약 서비스 호출 시 고객 정보가 필요한 경우 ( 예약 microservice / 고객 microservice 나눠져 있는 상태 )
• 합친다면? 또 다른 일체형 어플리케이션이 되어버림
• 비동기 방식? 예약 서비스에서는 고객정보가 있어야 진행되므로 굳이 비동기로 구현할 필요가 없음
• 조립하는 서비스를 만들까? 팀간 조율이 어렵고, 자율성을 잃게 됨
• 고객 정보의 복사본을 예약 마이크로서비스에 둘까? 지금은 좋아보이지만, 결국에는 예약 서비스에서 또 다른 고객 서비스를 필요로 할 경우 똑같이 문제 발생 => 철저한 분석이 선행되어야지, 복잡도 부작용을 막을 수 있음
4. 마이크로 서비스당 적절한 endpoint의 수? 가상머신 하나에 적절한 마이크로서비스의 수?
• 적절한 endpoint의 수는 없다. 하나가 될 수도 있으며 여러개가 될 수도 있다. 예를 들어, 멤버십 포인트 마이크로서비스에서 누적,상환 기능당 마이크로 서비스를 만들어 버리면, 잘게 나뉘어진 서비스 때문에 데이터에 접근하는데에 문제가 발생한다.
• 컨텍스트를 적절하게 나누는 것이 중요
• 가상머신 : 마이크로서비스를 1:1로 가져가면 비용이 많이 발생할 것이다. 왜냐하면 코어당 라이센스 비용을 부과하기 때문이다.
• 가상 머신이 두개의 서비스를 운영하기에 용량이 부족한가? 다른 서비스의 자원 요구사항(jdk 버전)이 충돌하지 않는가?
  => No라면 일단은 하나의 가상머신에 여러개 서비스를 실행
• 나중에는 AWS 람다같은 것을 사용하면, 개발자는 마이크로서비스가 어느 가상머신에서 실행되는지 용량 걱정도 하지 않아도 된다.
5.  데이터 공유?
• 고객 등록 / 고객 분류 마이크로 서비스가 있다면 고객 데이터를 공유함 => 고객 데이터 저장소 마이크로서비스를 새로 만드는게 좋음
6. 트랜잭션 경계 설정
• 트랜잭션의 경계는 다른 두개로 확장되지 않게 해야하며, 로컬 트랜잭션을 이용하는 것이 적절하다.
7. Infrastructure 역량
• 마이크로서비스 개발시 자동화된 CI/CD가 없으면 재앙 -> 운영 오버헤드가 나타남
• 자동으로 애플리케이션을 배포하고, 컨테이너를 프로비저닝하고, 인스턴스를 자동으로 갈아끼우고, 부하에 따라 컨테이너를 조정해야 함

• 마이크로서비스 역량 모델 ( capability model )
1. Infrastrcture CApabilities : 성공적인 배포와 마이크로서비스 관리에 필요한 역량
• Containers / VM : 대규모의 물리적인 장비를 직접 관리하는 것은 비용 효율적이지도 않으며, 관리 오버헤드가 있음 => Docker를 공부하자
• Cluster Control & Provisioning : Docker container 수가 많아지면 관리하기 어려워짐 -> 가용한 자원을 서비스들에게 적절히 분배해주는게 필요함 => Kubernetes, Rancer 공부하자
• Application Lifecycle Management : Docker container가 새로 시작 될 때, spring application을 시작시켜줌, 자동으로 장애를 감지하여 가용성을 보장. => Cluster control software와 함께 수행됨, Marathon 공부하자.
2. Process & Governance Capabilities 
• Microservice Documentation : REST API 문서화를 해놔야 서비스 파악하기 쉬움 => Swagger 공부하자
• DevOps, DevOps Tools : 자동화, 종합 테스팅, 성능 테스팅 등등 => Jenkins, (Test 도구는 조사해야함... ) 공부하자
• Microservices Repository : Nexus, Docker Registry(Harbor) 공부하자
• Reference Architecture & Libraries : ?
3. Supporting Capabilites : 마이크로서비스 구현을 지원하는 것들
• 테스팅 도구 : 넷플릭스는 붕괴 저항성 테스트를 위해 Simian Army를 사용함.
• 서비스 환경 설정 : 12요소 애플리케이션에서 살펴봤던 것 처럼 서비스 환경설정 정보는 모두 외부화해야 한다.
• 모니터링 및 대시보드
• 의존관계와 CI 관리
• 서비스 레지스트리
• 중앙 집중형 로그 관리
4. Core Capabilites 
• Storage Capabilites : 마이크로서비스의 상태나 데이터를 적절한 비즈니스 범위에 따라 저장해야 함. => Mysql, Hadoop, ElasticSearch / Hazelcast(in-memory)공부하자
• Business Capabilites Definitions : 비즈니스 로직이 구현되는 곳 => Java 공부나 해 
• Service Endpoints & Communication Protocols : 외부에서 사용할 수 있는 API를 정의해야함. 동기방식은 REST/ JSON, 비동기방식은 RabbitMQ를 이용하는 Spring cloud Stream 공부하자
• API Gateway : Proxy 역할을 담당할 수도 있고, service endpoint를 조합하는 역할을 함으로써 뒷단에 있는 서비스를 간접화 한다. 실시간 로드 밸런싱 제공도 가능함 => Zuul 공부하자
• User Interface : ?