Microservice Architecture

해당 포스팅은 Amazon ECS/ECR을 활용하여 마이크로서비스 구성하기 - 김기완 (AWS 솔루션즈아키텍트) 를 보고 작성되었습니다.

MSA란?

• Microservice architectural란? 하나의 어플리케이션 또는 하나의 서비스를 작은 microservice로 독립된 운영될 수 있도록 하는 것. 반대로는 Monolithic이 있다. 소리소문 없이 끊임없는 기능을 업데이트하는 것.
• 각기별로 분산 환경의 서로의 서비스를 개발하고 나중에는 그 작은 단위의 서비스들이 하나로 뭉쳐 큰 서비스가 되는 것. 라이브러리를 사용하는 것이 아닌, 서비스를 사용하는 것.

MSA의 장점

• 빠른 개발 속도 : 개발 언어 선택의 자유로움, 서비스 팀의 역량만으로도 충분히 가능하다
• 빠른 배포 속도와 병렬 배포 : 각 마이크로서비스간의 독립된 배포 파이프라인(CI/CD) A 서비스 배포를 위해 B 서비스 배포를 기다리지 않아도 됨
• DevOps팀과 통합된 운영이 가능함 → 이에 따른 서비스의 Ownership을 갖게됨(하나의 서비스에 대해서 잘 아는 팀이 빠르게 서비스 배포 및 개선이 가능하다)
• 확장성 및 가용성 : 해당 서비스 단에서 즉, 마이크로서비스 특성에 맞는 확장성과 가용성의 설계가 가능하다. WAS안에 모든 비즈니스 요건을 다 넣고 그에 맞게끔 서비스를 늘려갈 수 있다는 점. 크게 늘려갈 서비스와 작게 끝날 서비스를 분류하여 서비스를 개발 할 수 있음.
• 비즈니스 도메인과 밀접하게 연결 : Lean Cycle → 빠르게 비즈니스 요건을 수용해가는 것.

MSA가 가져가야할 공통 구성 요소

👉🏽 MSA로 가면서 수많은 서비스들이 생겨가고, 그에따른 이 서비스들을 관리할 것들이 필요함.

• 모든 서비스들에 적용되는 공통 요소들
  1. 서비스 등록 및 제거
  2. 서비스 검색 및 가용성 관리
  3. 서비스 메타데이터 관리
  4. 서비스 버전 관리
  5. 서비스 별 Cache 관리
• 빠르고 효율적인 배포 환경 관리
• 자동화된 관리 및 모니터링

MSA의 고려사항

• 다른 서비스들과는 무관하게 스케일 업/다운이 가능해야한다. 즉, Elastic 해야한다.
• 단위 리소스의 장애를 견디어야 한다.
• 통일된 API 인터페이스를 가져가야 한다.
• 작게 유지되어야한다.
• 다른 서비스들과는 독립적이어야 한다.

MSA 순서

Client → Gateway(Microservices API) → Discovery → Business Domain → Data Store

여기에 추가적으로 DevOps Pipeline을 추가한다면,

Version Control / Repository / CI, CD

Client : 서비스를 사용하는 고객

Gateway : 여기서부터 API를 고객이 사용함

Discovery : 어떤 Microservices가 있는지 CRUD 하는 부분

Business Domain : Microservices가 운영되기 위한 Infrastructure인 computing 자원이 필요함 (DNS, route 53 등)

Data Store : 각각의 Microservice가 사용하는 데이터 공간이 필요함

Version Control : 각각의 Microservices의 버전 관리 하는 곳

Repository : 소스 코드를 저장하는 곳

CI/CD : 소스코드와 이미지들을 배포하고 유지하는 곳