Micro Service - Githubissues

0. Monolithic 구조

하나의 서버에 서비스할 모든 application source ( UI, 비즈니스 로직, DB 로직)가 존재하는 구조
- 아키텍처 구조가 심플하여 관리가 용이
- 트랜잭션 관리가 쉬움
- 복잡도가 낮은 경우, 애플리케이션 설계 및 테스트가 용이
점점 많은 기능이 요구되고 복잡한 비즈니스 서비스들이 추가되면서 문제 발생
- 특정 서비스 장애시 전체적인 장애가 발생할 수 있다.
  - Memory Segmentation fault, Out of Memory Error
- 여러 모듈간 의존성이 복잡해지는 경우, 모듈 수정시 다른 모든 서비스에 영향을 주어 장애 발생 가능
- 배포/재배포 시 시간이 오래걸릴 수 있고 Auto Scaling에 제약이 발생할 수 있다. ( ex. 단일 데이터베이스 사용에 따른 확장 제한 )

독립적으로 실행 및 배치가 가능한 작은 단위로 나누어 서비스를 제공
- 서비스별로 배포/재배포가 자유로움
- 서비스 별로 확장이 용이
- 수많은 서비스의 모니터링이 어려워짐
- 서비스 별로 자체 데이터 저장소를 가지고 있어 데이터베이스 트랜잭션 관리가 어려움
- 애플리케이션 테스트가 어렵다.
서비스와 서비스의 통신은 HTTP, REST API, Message Queue 사용 & API Gateway
- 서비스간 호출시 REST API 사용으로 인한 통신비용, Latency가 증가한다.

수많은 서비스들을 REST API 통신 방법으로 데이터를 연계
- 많은 인프라 ( 서버/WEB/WAS/네트워크 ) 구성과 각 서비스를 쉽게 연동할 수 있는 기능 필요
- 부하/장애 발생시 Auto Scale 및 자동 페일오버에 대한 고려 필수
  2-1. 물리/가상 서버 구성 : Process
가상 서버 Node에 여러개의 서비스를 Process로 실행하는 구조
- 서비스는 각각 다른 Port로 설정하거나 내부 가상 IP를 설정하여 서비스 제공
- Process를 증가시키다가 서버 임계치에 도달하면 Node를 추가
하드웨어를 효율적으로 사용할 수 있고 기존 서비스 노드에 추가하는 경우 빠르게 서비스 배포가 가능
특정 서비스 장애가 발생하면 전체 서비스 장애를 유발시킬 수 있는 단점
서비스별로 다른 OS Library버전이 필요하거나 특정 디렉토리를 같이 사용해야하는 경우 서비스를 분리해야할 수 있음
2-2. 물리/가상 서버 구성 : VM
서비스별로 VM Image를 생성한 후, 필요할 때마다 서비스를 VM으로 배포하는 방식
- 서비스 별로 간섭이 없기 때문에 장애 상황에 유연하게 대처 가능
Process방식보다 부팅시간이 길고 VM 구성에 인한 오버헤드가 존재
- VM 자원을 최대로 활용할 수 없음