[마이크로서비스 아키텍처 : 패턴과 핵심 기술] MSA 개념과 주요 특징

< Monolithic Architecture >

 

전통적 개발 방법

• 전체 기능을 단일 코드베이스로 개발한다
• 대규모 단일 코드 베이스를 빌드/배포한다
• 단일 통합 데이터베이스를 사용한다
• Monolithic System
  • Monolithic Architecture
  • Monolith
• Monolithic System Type이 존재한다

 

 

 

Monolithic System 단점

• 스케일 아웃 시 전체 시스템을 확장해야 하므로 비효율적이다
  • 보통 일부 기능때문에 스케일 아웃을 하는 경우가 많다
  • 하지만 Monolithic의 경우 전체 시스템을 확장해야 한다
• 빌드/배포 시간이 오래걸려서 빌드/배포가 자주 하지 못한다
• 작은 수정에도 전체 시스템 빌드/배포 해야 한다
  
  • 아무리 작은 수정이더라도 전체 빌드/배포가 이뤄지기 때문에 속도가 느려 hotfix가 느리다
• 하나의 버그에 전체 시스템이 실패할 수 있다
• 일반적으로 기능들 간의 결합도가 높다
  • 다른 기능의 테이블에 직접 접근하기도 한다!
  • 기능 수정시 전혀 다른 부분에서 오류가 발생하기도 한다
• 기능 변경 시 영향도 파악이 어렵다
  • 코드 의존 관계
  • 데이터 의존 관계
• 결과적으로 코드가 운영환경에 민첩하게 배포되기 어렵다

 

 

 

Monolithic System 장점

• 상대적으로 운영하기 용이하다
  • MSA에 비해 단일 코드베이스 및 데이터베이스인 경우가 많기 때문에 관리하기가 쉽다
  • 코드 관리, 장애 관리, 로그 관리, 모니터링
• 내부 메소드 호출을 하기 때문에 성능 문제가 없다
  • MSA는 Network를 통한 Interface를 호출하기 때문에 성능이 저하된다
• 트랜잭션 관리가 용이하다
  • MSA의 경우 분리된 데이터베이스를 사용하기 때문에 트랜잭션 관리가 힘들다
  • 데이터의 일관성 부분에서는 Monolithic Syatem이 유리할 수 있다

 

 

 

Monolithic System의 종류

• Single Monolithic System
• Modular Monolith System
• Distributed Monolithic System

 

 

 

Single Monolithic System

• 가장 일반적인 형태
• 큰 진흙 공이라고도 불림 - 각각의 기능들이 진흙처럼 뭉쳐져 있다

 

 

 

Modular Monolith System

• 각 기능별로 모듈화되어 있는 형태 : package, multi-module project
• MSA의 좋은 대안이 될 수 있다

 

 

 

Modular Monolith

• Monolith의 가장 큰 문제 - 기능 간 결합도, 코드 수정 시 영향도
• 결합도를 잘 다루면 유지보수성 높은 SW가 가능하다 - Modular Monolith
• https://www.slideshare.net/arawnkr/ss-195979955

잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다

• 배포와 확장에 대한 이슈는 여전히 존재한다
• 데이터에 대한 이슈도 존재한다 - 타 기능 데이터 직접 접근에 의한 결합도
• Modular Monolith의 장점을 취하기 위해서는 모듈 간의 결합도를 자주 관리해야하 한다

 

 

 

Distributed Monolithic System

• 분산된 Monolith
• 단순히 코드베이스를 쪼갰다고 MSA가 아니다
• 쪼개진 서비스 간에 매우 강결합된 상태이다
• 항상 같이 배포되는 형태이다

 

 

 

Distruibuted Monolith

• Monolith의 단점이 모두 존재한다
  • 영향도
  • 결합도
• 분산 시스템의 단점도 존재한다
  • 네트워크를 통한 협력에 의한 성능 조회
  • 관리가 어렵다

 

 

 

Monolith에 대한 오해

• Monolith는 Legacy이다? NO
• Monolith는 피해야 할 안티 패턴이다? NO
• Monolith는 모든 상황에서 Microservice로 분할되어야 한다? NO

• MSA로 전환된다고 하더라도 위처럼 깔끔하게 나뉘지는 않는다
• Monolith는 하나의 아키텍처 패턴일 뿐이다
• 많은 상황에서 충분히 좋은 역할을 한다
• 관리 용이성, 트랜잭션, 성능 등 많은 장점이 있다
• 따라서  Monolith와 MSA는 Trade-off가 존재하기 때문에 적절한 선택이 필요한다

---

< Microservices 장단점 >

 

Revisit

• Microservice Architecture 정의
• Microservice Architecture 단점

 

 

Microservice Architecture 란?

• 애플리케이션을 자율적인 다수의 서비스로 분리하여 개발한다
• 각자 별도의 프로세스에서 실행된다
• HTTP API 같은 가벼운 매커니즘으로 통신하는 작은 애플리케이션이다
• 작은 서비스들은 각자의 비즈니스 기능을 담당한다
• 완전 자동화 된 절차에 따라 독립적으로 배포된다
• 각 서비스는 서로 다른 프로그래밍 언어나 서로 다른 데이터 저장 기술을 사용할 수 있다

 

 

 

Monolithic System 단점

• 스케일 아웃 시 전체 시스템을 확장해야 하는 비효율
• 빌드/배포 시간이 오래 걸림
• 작은 수정에도 전체 시스템을 빌드/베포 해야 함
• 하나의 버그에도 전체 시스템이 실패할 수 있음
• 기능 간 결합도가 높아 영향도 파악이 어렵다
• 결과적으로 코드가 운영환경에 민첩하게 배포되기 어렵다

 

 

 

MSA가 Monolithic의 문제를 해결!

• MSA는 작은 서비스 단위로 확장이 가능하다
  • 트래픽이 몰리는 서비스만 선택하여 확장이 가능하다
• 일부의 장애가 시스템 전체 장애로 이어지지 않는다
  • 물론 MSA도 일부 장애로 시스템 전체 장애가 발생할 수는 있다
  • 하지만 설계를 통해 이에 대한 예방이 가능하다
• 서비스 단위로 자율적으로 배포가 가능하다
  • Monolithic에 비해 서비스가 작기 때문에 각 서비스마다 효율적인 배포 가능
• 결과적으로 빠르게 변화하는 비즈니스 환경에 민첩하게 대응이 가능하다
  • 우리가 작성한 코드가 빠르게 서비스에 반영이 가능해진다

 

 

 

왜 지금 MSA인가? - 비즈니스 측면

• 비즈니스 환경은 점점 빠르게 급변하여 경쟁이 심해지고 있다
• 비즈니스가 IT 기술에 의존하는 케이스가 많다
• 결과적으로 많은 기업들이 민첩한 IT 기술 없이 비즈니스의 빠른 변화와 성장이 어려워졌다

 

 

 

왜 지금 MSA인가? - 기술적 측면

• Cloud의 발전
  • MSA는 전체적인 시스템 토폴로지(topology)가 복잡해지기 때문에 전통적인 인프라 환경에서 운영하기 어렵다
  • Cloud 환경은 탄력적이고 확장성 높게 운영이 가능하여 MSA의 발전에 큰 도움이 되었다
• NoSQL의 안정화와 급부상
  • MSA의 서비스들은 각각의 목적에 맞는 서로 다른 저장기술을 사용할 수 있다
  • NoSQL이 발전되고 안정화되면서 선택할 수 있는 데이터베이스의 폭이 넓어졌다
• Docker, Kubernetes & Ecosystem
  • 이들의 발전으로 대용량의 MSA 서비스를 쉽게 배포/실행할 수 있게 되었다
• Netflix OSS
  • MSA를 적용하기 위해 넘어야 하는 많은 허들을 OSS를 통해 쉽게 해결이 가능하다
• 많은 기업들의 쌓여가는 사례 및 Best Practice

 

 

 

MSA의 장점

1. 빠른 Delivery
2. 탄력적이고 선택적인 확장
3. Polyglot Architecture 지원
4. 실험과 혁신 가능
5. 대체 가능성
6. 기술 부채의 경감

 

 

 

1. 빠른 Delivery

• 각 서비스는 독립적으로 개발되고 느슨하게 결합된다
• 각각의 서비스는 작기 때문에 코드 수정에 대한 영향 범위가 상대적으로 작다
  • 빠른 영향도 파악, 빠른 빌드, 빠른 테스트
• 각 서비스들은 네트워크를 통한 Interface로 느슨히 결합된다
  • 서비스 간 자율적인 배포가 가능하다
• 상대적으로 Monolithic 서비스에 비해 고객들에게 서비스를 빠르게 Delivery 할 수 있다

 

 

 

2. 탄력적이고 선택적인 확장

• 작은 서비스 단위로 확장이 가능하다
• Monolith는 전체 Scale Out이 필요하다 -> 비효율
• 각 서비스는 코드베이스가 작아 확장 비용이 상대적으로 저렴하다

 

 

 

3. Polyglot Architecture 지원

• 전통적 개발 환경은 조직의 표준 기술을 만들고 모든 조직에 강제한다
• MSA에서는 특정 Task에 가장 적절한 기술을 선택하여 적용이 가능하다
• 각 서비스는 자신만의 고유한 언어/Framework, 방법론까지 선택이 가능해진다

 

 

 

4. 실험과 혁신 가능

• 최근 비즈니스 상황에서는 기술의 혁신이 필수적이다
• Monolith 환경에서는 단순한 기술 실험도 어렵다
  • DB/Framework 변경은 물론 언어의 버전 업도 어려운 작업이다
  • 영향도와 비용의 문제
• 마이크로서비스는 새로운 기술들을 쉽게 실험해볼 수 있다
  • 작은 코드 베이스
  • 서비스 간 느슨한 결합

 

 

 

5. 대체 가능성

• 언어/프레임워크를 완전히 새롭게 개발이 가능하다
• 또는 오픈소스/커머셜 솔루션으로 대체가 가능하다
• 각 서비스는 작고 서비스 간에 느슨하게 연결되어 있기 때문에 가능하다
• 따라서 보다 진화적인 서비스 설계가 가능해진다
• 적절한 서비스의 크기는 완전히 새로 개발되는 데 2주라고 한다 (정답은 없음)

 

 

 

6. 기술 부채 경감

• SW는 나이를 먹고 관리하지 않으면 기술 부채가 쌓인다
• Monolith는 강한 결합도 때문에 코드 수정이 어렵다
• 서비스 크기가 작아서 품질 관리에 용이히다
• 품질 향상을 위한 코드 개선 시 영향도가 작다
  • 지속적인 개선 작업이 가능해진다
  • 이는 조직의 문화로 자리잡을 수 있다

 

 

 

MSA의 단점

• 컴퓨팅 자원의 사용이 Monolith보다 비효율적이다
• 성능 - 내부 호출(Monolith)보다 느리다
  • MSA는 네트워크로 데이터를 주고받기 때문에 성능이 보다 저하될 수 있다
  • JSON 형식으로 주고받다 보면 오버헤드가 발생할 수도 있다
• 메모리 - JVM, 톰캣 등 중복적인 자원 사용이 발생한다
• 전반적으로 운영 관리 측면에서 어렵다
• 모니터링 대상이 증가한다
• 배포 대상 서비스 증가 및 기술의 다변화
• 다양하고 복잡한 장애 상황 발생
• 단위 테스트 컴포턴트 테스트 난이도 증가
• DB 트랜잭션 처리가 어렵다
  • 서비스 간 Polyglot Data Store 사용하기 때문에 데이터 레벨에서 트랜잭션이 어려워진다
• 분산 환경에서 트랜잭션이 어렵다

---

< Microservices 특징 >

 

MSA의 특징

https://martinfowler.com/articles/microservices.html

Microservices

• 위는 Martin Fowler가 정리한 MSA의 일반적인 특징이다
  • MSA를 채택한 조직을 관찰/조사 후 공통적 특징을 정리하였다
  • 모든 MSA가 만족해야 하는 필수 조건은 아니다

 

다음은 정리된 8개의 MSA 특징이다

1. 서비스를 통한 컴포넌트화
2. 비즈니스 역량에 따른 조직 구성
3. 프로젝트보다 제품에 집중
4. 똑똑한 End Point, 단순한 Pipe
5. 분산된 거버넌스
6. 분산된 데이터 관리
7. 인프라 자동화
8. 장애 방지 설계

 

 

1. 서비스를 통한 컴포넌트화

• 컴포넌트를 어떻게 정의하고 어떻게 연결하느냐는 SW 업계에서의 오랜 고민거리이다
• MSA에서는 서비스 단위를 컴포넌트로 정의하였다
  • 하나의 서비스가 응집도 높게 특정 비즈니스 기능을 담당한다
  • 독립적인 프로세스로 실행한다
  • 자율적으로 배포가 가능하다
• 서비스는 응집도 높게 설계되어야 한다
• 서비스 간에는 명확한 인터페이스를 제공하여 협력한다

 

 

 

2. 비즈니스 역량에 따른 조직 구성

• Conway의 법칙 : 시스템을 설계하는 조직은 그 조직의 소통 구조를 닮은 아키텍처를 만든다
• 조직의 구조가 시스템의 아키텍처에 영향을 준다
• 전통적인 개발 방법에서는 단일 비즈니스 영역 기능의 변경이 다수의 팀 간의 협업을 필요로 한다

 

• MSA를 사용하는 경우, 비즈니스 역량에 따른 조직을 구성한다

• 서비스를 만들 수 있는 역량을 팀 내부에서 모두 갖추고 있다
• 팀의 규모는 정답은 없지만 3~9명, 아마존의 Two Pizza 팀 정도이다
• 팀 간 loosely coupled -> 전체 시스템도 loosely coupled : Conway의 법칙

 

 

 

3. 프로젝트보다 제품에 집중

아마존의 철칙(?)

• 기존에는 개발과 운영이 분리되어 있다
• 따라서 프로젝트 개발이 끝나면, 소프트웨어는 운영 조직에 이관한다
• MSA에서는 팀이 개발/운영을 포함한 전체 라이프사이클을 책임진다
• 팀원들이 자신들이 만드는 SW를 바라보는 시각이 전환된다
  • 직접 운영까지 하기 때문에 고객과의 접점을 늘리고 피드백을 늘려나간다
• 단순히 기능의 집합을 개발하여 넘기는 것이 아닌, SW가 어떻게 고객에게 가치를 전달할 수 있을지를 고민하는 계기가 된다
• SW와 기업의 비즈니스와의 연관 관계를 인식한다

 

 

 

4. 똑똑한 End Point, 단순한 Pipe

• 도메인 로직은 각 서비스 내에 응집도를 높게 유지한다
• 각 서비스 간의 연결은 HTTP API, MQ 등을 사용한다 - No ESB

 

 

 

5. 분산된 거버넌스

• 중앙에 강력한 표준이나 절차의 준수를 강요하지 않는다
• 스스로 효율적인 방법론과 도구, 기술을 찾아 적용한다
• 각 서비스에 가장 적합한 기술을 적용한다
• 지방자치제도와 유사하다!

 

 

6. 분산된 데이터 관리

• Monolithic은 일반적으로 단일 통합 데이터베이스를 사용한다
  • 트랜잭션 처리에 용이하다
  • 서로 다른 기능이 테이블을 직접 접근하기도 한다
• MSA는 해당 서비스의 데이터를 각자 관리한다
• 서비스는 서로 다른 데이터 저장 기술이 사용 가능하다 - Polyglot Persistence
• 각 서비스는 API를 통해서만 다른 서비스의 데이터에 접근이 가능하다
• 트랜재견 처리가 어렵고, 결과적 일관성의 적용 (시간이 지나야 일관성이 맞춰짐)

 

 

 

7. 인프라 자동화

• 다수의 서비스와 인스턴스가 존재하는 환경에서는 자동화가 필수이다
• 자동화된 테스팅
• 자동화된 Continuous Intergration
• 자동화된 Continuous Deployment

 

 

8. 장애 방지 설계

• 특정 서비스의 장애는 항상 일어나고 다른 서비스로 전파된다
• 일부 서비스 장애가 전체 시스템 장애로 전파되는 것을 막는 것이 핵심이다
• 모니터링을 자동화하여 서비스의 이상 동작을 최대한 신속하게 파악해야 한다
• 가능하면 자동으로 복구할 수 있도록 설계해야 한다
• 장애 발생이 고객에게 미치는 영향을 파악하는 것도 중요하다
• Netflix의 장애 유발 테스트
  • 카오스 멍키
  • 카오스 고릴라
  • 카오스 콩
• Circuit Breaker 패턴
  • 회로 차단 패턴
  • 일부 서비스의 장애가 전체 시스템 장애로 전파되지 않도록 막는다