[이론][배포금지] Monolithic service 와 Microsevice 의 장단점

참고 

http://www.slideshare.net/saltynut/building-micro-service-architecture

AS-IS Monolithic service

문제점

• 코드가 너무 커져서 유지보수하기 어려움
• 시스템 분리가 어려움
• DB 분리가 어려움
• 연계시스템 변경시 대응이 어려움
• 연계시스템 장애시 연쇄 장애가 발생함
• 사소한 수정에도 전체 배포 및 QA를 거쳐야 함
• 새로운 서비스 추가시 기존 로직/데이터가 변경되면 문제를 예측할 수 없음

Microservice 아키텍처의 배경

• Domain Driven Design
• Continuous Delivery
• On-demand Virtualization
• Elastic, Scalable, Resilience
• Polyglot Programming
• Infrastructure Automation
• Agile Development
• Reusability
• Self-government Team

Microservice?

• 작고(small)
• API로 다른 서비스와 연계하며(communicate with APIs)
• 자율적이며(autonomous)
• 한 가지 일을 잘하는데 초점을 맞춘 서비스(focused on doing one thing well)

장점

• Technology Heterogeneity
• Resilience
• Scaling
• Ease of Deployment
• Organizational Alignment
• Composability
• Replaceability

단점

• Complexity
• Multiple Database & Transaction Management
• Complicated Test
• Require Automation for Deploy/Operation
• Hard to develop features span multiple services

SOA(Service Oriented Architecture) 와 비교

비슷하지만 다름

SOA는 개념 상 잘못되지 않아지만 방식이 잘못됨

 - SOAP Protocol

 - WS-*

 - Vendor-Driven

 - ESB가 모든 걸 다 해결해줄 거라는 잘못된 믿음

그럼 MSA(Microservice Architecture)는?

• Vendor Driven -> Service Company Driven
• 오픈테크놀러지 기반
• SOAP/XML vs. REST/JSON
• 스펙 먼저가 아닌 현실에서 검증된 Practice 들의 모음
• Agile 개념과 결합
• Cloud 환경의 활용

모댈링/구현 Tip

• API를 먼저 정의하라
• API를 REST API Maturity Level 2 이상이 되도록 강제화하라.
• API 문서를 유지하라(ex: Swagger)
• ORM을 활용하라
• DB에 너무 의존하지 마라
• 도메인 내부에서만 의미있는 값을 외부에 노출하는 것을 지양하라
• 마이크로서비스가 별다른 설정 없이 바로 기동가능하게 하라(ex: Java의 경우 Spring Boot + Embedded WAS 활용)

MSA를 선택하는 이유

• Frontend/Backend 분리 -> 회사의 Engineer Tech Tree와 동기화
• 코드 양이 커지고, 중복 코드가 발생 -> 코드의 양을 줄여서 누구나 쉽게 파악하도록
• 팀 전체의 Project -> Working Group 별 Product
• 시스템 간 연계 증대 -> API 기반의 Contract 관리를 강제화
• 새로운 기술에 대한 도입 욕구 -> Microservice 단위로 구현에 자율성 부여(Polyglot)
• 재사용성 향상 및 지속적인 발전 -> Microservice 단위의 재사용, 자유로운 리팩토링
• 회사 인프라의 뒷바침 -> On-Premise Cloud, CI와 연계된 배포 자동화(Jarvis), 향후 Docker와 같은 컨테이너 기술과 연계