---

1. 마이크로서비스를 왜 쓰는가?

• 소프트웨어가 점차 커지고 복잡해지면 더 나은 관리 방법과 시스템의 복잡성을 줄일 방법이 필요하다.
• 사업 규모가 커지면서 여러 팀의 협업이 가능하도록 세분화할 수 있는 좋은 방법도 필요하다.
• 고객의 요구가 증가하면 소프트웨어 기능도 마찬가지로 커지면서 동시에 내결함성과 최대 사용량을 감당할 수 있는 확장성도 가져야 한다.

마이크로서비스로 구성된 분산 애플리케이션으로 위와 같은 문제들을 해결할 수 있지만, 기존의 모놀리스 앱보다 어렵고 복잡하며 시간이 많이 소요되는 설계 방식이다.

1.1 마이크로서비스란 무엇인가

정의: 마이크로서비스는 개별적으로 배포 일정을 갖고 업데이트 운영이 가능한 작고 독립적인 소프트웨어 프로세스다.

• 하나의 마이크로서비스는 외부 인터넷이나 다른 서비스를 연결할 수 있고, 데이터베이스 또는 파일 저장소를 포함할 수 있다.
• 마이크로서비스 하나는 많은 기능을 갖지 않는다. 잘 설계된 시스템이라면 단순한 서비스들로 구분이 가능하다.
• 이 서비스들끼리 서로 협업해서 커다른 앱과 같은 기능을 제공한다.

1.2 마이크로서비스 앱이란 무엇인가

정의: 마이크로서비스 앱은 프로젝트의 주요 기능들을 수행하기 위해 서로 협업하는 작은 서비스들로 구성된 분산 프로그램이다.

• 전형적인 마이크로서비스 앱은 사용자가 시스템과 상화작용이 가능하도록 외부에서 접근을 허용하는 하나 이상의 서비스를 갖고 있다.
• 단위 서비스는 자신만의 데이터베이스를 갖는다.
• 작은 단위로 독립적 배포 일정을 갖는다.
• 단위 서비스는 서로 느슨하게 연결되며, 삭제 가능하다. 어떤 서비스를 없애거나 재시작해도 전체적인 서비스에 영향을 주지 않는다.

1.3 모놀리스의 문제점

정의: 모놀리스는 전체적인 앱이 단일 프로세스로 동작하는 경우를 말한다.

• 전체 앱이 단일 배포작업으로 망가질 수 잇다.
• 배포가 위험한 작업이므로 신중하게 배포할 수 밖에 없다.
• 오직 한 가지 방법으로 확장이 가능하다.
• 언젠가는 코드의 양은 방대해지고 담당자는 바뀌게 된다. 이 상황에서 모놀리스 앱의 코드를 변경하는 것은 위험한 작업이다.

1.4 어떤 경우에 어떤 방식을 선택해야 할까?

모놀리스

• 자신의 앱이 작고 간단하게 남을 수 있고, 특별한 기능 향상도 필요 없다면 모놀리스로 제작하는 것이 답이다.
• 사업적 아이디어를 일단 검증해보고 싶다면, 모놀리스로 만들어보자.

마이크로서비스

• 여러 해에 걸쳐서 지속적으로 개선해 나갈 앱의 경우에는 마이크로서비스로 제작하는게 좋다.
• 유연성과 확장성, 보안을 위해 준수할 정책이 처음부터 필요한 앱들도 마찬가지다.

1.5 왜 마이크로서비스를 많이 사용할까?

• 클라우드와 가상화, 가상 인프라 관리 자동화 도구의 힘을 얻어 위와 같은 분산 시스템의 구축 비용이 훨씬 줄었다.
  • 분산 시스템의 구성 요소들을 가능한 한 작게 만들었고, 이를 우리는 마이크로서비스라 부르고 있다.

1.6 마이크로 서비스의 장점

• 단위 서비스는 잠재적으로 자신만의 프로세서, 메모리와 같은 자원을 가질 수 있다.
• 세밀한 제어가 가능함
• 배포 위험의 최소화
  • 마이크로서비스는 일련의 개발 과정 속도가 빠르므로 배포 위험을 줄이는 데 도움이 된다.
• 자신이 이미 보유한 기술 선택
  • 마이크로서비스는 수행할 작업을 위한 올바른 개발도구를 선택할 수 있게 만드므로, 특정 기술이나 도구에 의해 생기는 제약이 없다.

비용이 줄고 배포가 편리해짐에 따라 서비스의 방향이 마이크로 수준으로 변하게 됐고, 이러한 변화 자체가 주는 장점이 있다.

• 전반적인 시스템의 테스트는 여전히 어려울 수 있지만, 개별 기능들은 예상한 대로 동작하는지쉽게 검증할 수 있다.
• 마이크로서비스는 점진적으로 새로운 기술 스택으로 전환할 수 있는 구조로 만들어준다.

1.7 마이크로서비스의 단점

• 마이크로서비스는 더 어렵다.
• 사람들은 복잡한 것을 두려워한다.

1.8 마이크로서비스 앱의 설계

• 미래에 필요한 검증을 위해 지나치게 미리 설계하지 말자. 자신의 앱을 위한 단순한 설계부터 시작하자.
• 최대한 단순하게 유지하기 위해서 개발 과정에 지속적인 리팩토링을 적용하자.
• 좋은 설계가 자연스럽게 완성되도록 하자.

마이크로서비스와 관련된 원칙

• 단일 책임 원칙
• 느슨한 연결
• 강한 응집력
  • 하나의 마이크로서비스가 2개 이상의 문제를 해결하거나, 책임지는 범위가 위의 경우보다 더 크다면 강한 응집력을 갖지 못했다는 뜻이다.

1.9 요약

• 마이크로서비스는 개별적으로 동작이 가능한 작고 독립적인 프로세스이다.

2. 개발 원칙

• 단계적 반복
  • 조금식 완성해 나가는 과정은 결국 잘 동작하는 긴 코드를 만든다.
  • 각각의 작업은 반드시 동작 가능하고 테스트된 코드를 생상해야 하는 것이 가장 중요하다.
• 항상 동작하게 유지
• 단순함으로부터 출발

2.1 Domain-Driven Design & MSA

• Bounded Context와 Ubiquitous Language
  • 어떤 단위로 마이크로서비스를 쪼개면 좋은가?
• Context Mapping
  • 서비스를 어떻게 결합할 것인가?
• Domain Events
  • 어떤 비즈니스 이벤트에 의하여 마이크로 서비스들이 상호 반응하는가?

2.2 어느 굵기로 쪼갤 것인가?

• Monolith
• Mini
  • 구현이 용이한 단위
    • 점진적 MSA 전환이 용이한 단위
• Business capability
  • 비즈니스적 성과 측정과 피버팅이 용이한 단위
    • 팀단위와 연결하기 좋은
• Bounded context
  • 커뮤니케이션이 원활한 단위
    • Separation of Concerns 이 좋은
• Aggregate
  • 최소 사이즈, ACID가 준수 되어야 하는 원자적 단위
    • 유연성이 높은

2.3 Event Storming: DDD를 쉽게 하는 방법

• 이벤트 스토밍은 시스템에서 발생하는 이벤트를 중심 (Event-First)으로 분석하는 기법으로 특히 Non-blocking, Event-drien 한 MSA기반 시스템을 분석에서 개발까지 필요한 도메인에 대한 탁월하게 빠른 이해를 도모하는데 유리하다.
• 기존의 유즈케이스나 클래스 다이어그래밍 방식은 고객 인터뷰나 엔티티 구조를 인지하는 방식과 다르게 별다른 사전 훈련된 지식과 도구 없이 진행할 수 있다.
• 진행과정은 참여자 워크숍 방식의 방법론으로 결과는 스티키 노트를 벽에 붙힌 것으로 결과가 남으며, 오랜지색 스티키 노트들의 연결로 비즈니스 프로세스가 도출되며 이들을 이후 BPMN과 UML 등으로 정재하여 전환할 수 있다.

2.4 마이크로서비스의 서열과 역학관계

• 1순위: Core Domain
  • 버릴 수 없는. 이 기능이 제공되지 않으면 회사가 망하는
    • 예) 쇼핑몰 시스템에서 주문, 카탈로그 서비스 등
• 2순위: Supportive Domain
  • 기업의 핵심 경쟁력이 아닌, 직접 운영해도 좋지만 상황에 따라 아웃소싱 가능한
  • 시스템 리소스가 모자라면 외부 서비스를 빌려쓰는 것을 고려할만한
    • 예) 재고관리, 배송, 회원관리 서비스 등
• 3순위: General Domain
  • SaaS등을 사용하는게 더 저렴한, 기업 경쟁력과는 완전 무관한
    • 예) 결재, 빌링 서비스 등