[MSA] MSA(MicroService Architecture)란🤔❓

🏷 What is MicroServices?

하나의 Application을 다수의 독립적인 Service로 구성하는 Architecture Style 이다.

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

---

🏷 전통적 개발 방법론 및 Monolithic 소개

전통적인 개발 방법론

• 전체 기능을 단일 코드베이스로 개발했다.
• 대규모 단일 코드 베이스를 빌드/배포했다.
• 단일 통합 데이터베이스를 사용했다

➡️ Monolithic System

Monolithic System의 단점

1. 기능들 간 결합도가 일반적으로 높다.

• 작은 수정에도 전체 시스템이 전체적으로 변경되어야 한다.
• 하나의 버그에 전체 시스템이 실패할 수 있다.

2. 기능 변경 시 영향도의 파악이 어렵다.
3. 결과적으로 코드가 운영환경에 민첩하게 배포되기 어렵다.

Monolithic System의 종류

1. Single Monolithic Sytem

• 가장 일반적인 형태이다.
• 진흙처럼 응집도가 높다고 해서 큰 진흙 공 이라고도 불린다.

2. Modular Monolithic Sytem

• 각 기능별로 모듈화가 되어있는 형태이다.
• MSA(MicroService Architecture)의 좋은 대안이 될 수 있다.
• Monolithic의 가장 큰 문제인 결합도를 잘 다룬다면, 유지보수성이 높은 SW를 만들 수 있다!
• 이 장점을 취하기 위해서는 모듈간의 결합도를 자주 관리해야 한다.

3. Single Monolithic Sytem

• 분산된 형태의 Monolithic Sytem 이다.
• 분산되었지만 서비스 간 결합도는 매우 강한 상태로 항상 같이 배포된다.

Monolithic에 대한 오해😅
Monolithic의 단점만 언급했다고 해서 피해야 할 패턴은 절대 아니다!
Monolithic은 하나의 아키텍처 패턴일 뿐, 많은 상황에서 충분히 좋은 역할을 한다.
뒤이어 나올 MSA의 단점인 운영 관리의 어려움이 Monolithic에서는 운영 관리가 쉽다는 장점으로 작용한다!

즉, Monolithic 과 MSA 는 Trade-Off 가 존재하므로 적절한 선택이 필요하다!

---

🏷 MSA(Microservice Architecture) 장/단점

MSA(Microservice Architecture) 는 Monolithic이 가지는 단점들을 보완해준다.

• 작은 서비스 단위로 확장이 가능하다. ➡️ 일부의 장애가 시스템 전체 장애로 이어지지 않는다.
• 서비스 단위로 자율적인 배포가 가능하다. ➡️ 빠르게 변화하는 비즈니스 환경에 민첩하게 대응이 가능하다

MSA 장점

1. 빠른 Delivery
각 서비스는 독립적으로 개발되고 느슨하게 결합된다.
서비스 크기 또한 작기 때문에 코드 수정에 대한 영향 범위가 상대적으로 작아진다.
이는 곧 빠른 영향도 파악/빌드/테스트 즉 빠른 Delivery로 이어지게 된다.

2. 탄력적이고 선택적인 확장
MSA는 작은 서비스 단위로 확장이 가능하다.
반면 Monolithic은 확장을 하기 위해서는 전체 Scale-Out이 필요하므로 비효율적이다.

3. Polygot Architecture 지원
조직의 표준 기술을 만들고 모든 조직에 강제적으로 적용하는 전통적 개발 환경과 달리,
MSA는 특정 Task에 가장 적절한 기술을 선택해 적용할 수 있다.

4. 실험과 혁신 가능
최근 비즈니스 상황에서는 기술의 혁신이 필수적이다.
Monolith 환경 에서는 단순한 기술 실험도 어려운 반면, MSA는 새로운 기술들을 쉽게 실험 해 볼 수 있다.

5. 대체 가능성
각 서비스는 작고 서비스 간 결합도가 낮기 때문에 언어 및 프레임워크를 완전히 새롭게 개발할 수 있다.

6. 기술 부채 경감
SW 또한 나이를 먹고 관리하지 않으면 기술 부채가 쌓이게 된다.
MSA는 서비스 크기가 작아 품질 관리에 용이하고, 품질 향상을 위한 코드 개선 시 받는 영향도 작다.

MSA 단점

1. 컴퓨팅 자원의 사용이 Monolithic보다 비효율적이다.
내부 호출을 하는 Monolithic보다 성능이 느리고, jvm 등 중복적인 자원 사용으로 메모리가 낭비된다.

2. 운영 관리가 어렵다.
작은 서비스 여러개로 이루어져있는 만큼 운영해야 할 대상 또한 늘어나면서 관리가 어려워지고, 모니터링 대상 또한 증가하게 된다.

3. 다양한 장애 상황 발생

4. 분산 환경에서 트랜잭션 어려움

---

🏷 MSA 주요 특징

지금부터 정리할 특징은 Martin Fowler 가 정의한 MSA의 일반적 특징이다.

MSA를 채택한 조직을 관찰/조사 후 공통적 특징을 정리한 것으로, 모든 MSA가 만족해야 하는 필수 조건은 아니라는 점에 유의하자.

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

컴포넌트를 어떻게 정의하고 어떻게 연결 하느냐는 SW 업계에서의 오랜 고민 거리로 이어지고 있다.

MSA에서는 서비스 단위를 컴포넌트로 정의하고 있다.
하나의 컴포넌트는 특정 비즈니스 기능을 담당하고, 독립적인 프로세스로 실행되며 자율적으로 배포가 가능하다.

따라서 서비스는 응집도 높게 설계되어야 하고, 서비스 간에는 명확한 인터페이스를 제공하여 협력해야 한다.

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

Conway의 법칙💡
시스템을 설계하는 조직은 그 조직의 소통 구조를 닮은 아키텍처를 만든다.
즉, 조직의 구조가 시스템의 아키텍처에 영향을 준다는 뜻이다.

하나의 비즈니스 기능을 변경하고자 하면, 다수의 팀 간의 협력을 필요로 하게 된다.
(기획팀, 디자인팀, FE개발팀, BE개발팀 등...)

그러나 비즈니스 역량에 따라 조직을 구성하게 되면 위와 같이 한 서비스를 만들 수 있는 역량을 한 팀 내에 모두 갖출 수 있다.
팀 간 결합도가 낮아지면, 전체 시스템의 결합도 또한 낮아지게 된다.

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

기존에는 개발과 운영이 분리되어, 프로젝트 개발이 끝나면 해당 소프트웨어는 운영 조직에 이관됐었다.
반면에 MSA는 한 팀에서 개발/운영을 포함한 전체 라이프사이클을 책임진다.

이는 아래와 같은 순기능을 가져온다.

1. 고객과의 접점을 늘리고 피드백을 늘려 나가므로, 팀원들은 자신들이 만드는 소프트웨어를 바라보는 시각의 전환을 경험할 수 있게 된다.

2. 단순히 기능을 개발하고 넘기는 것이 아닌, 소프트웨어가 고객에게 어떠한 가치를 어떻게 전달할 수 있을지 고민하는 계기가 된다.

3. 소프트웨어와 기업의 비즈니스 연관 관계를 인식할 수 있다.

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

특징 5. 분산된 거버넌스

지방자치제도와 유사하게, 중앙의 강력한 표준이나 절차의 준수를 강요하지 않고
스스로 효율적인 방법론과 도구, 기술을 찾아 적용하기만 하면 된다.

특징 6. 분산된 데이터 관리

MSA는 해당 서비스의 데이터를 각자 관리하므로 서비스는 서로 다른 데이터 저장 기술을 사용할 수 있다.

따라서 각 서비스는 다른 서비스의 데이터베이스에 직접 접근하지 않고, API를 통해서만 다른 서비스의 데이터에 접근하게 된다.

이렇게 되면 트랜잭션 처리가 어려워지고, 일관성 또한 즉시 적용되지 않고 시간이 지나야 적용되는 불편함이 생긴다.

특징 7. 인프라 자동화

다수의 서비스와 인스턴스가 존재하는 환경에서는 자동화가 필수이다.
따라서 자동화된 테스팅, 자동화된 CI, 자동화된 CD가 필수적으로 이루어져야 하고, 실제로 많은 역량을 쏟고 있다.

특징 8. 장애 방지 설계

어떤 환경에서든 장애는 항상 일어난다.
MSA의 특징은, 특정 서비스의 장애는 항상 일어나고 다른 서비스로 전파 된다는 것이다.

일부 서비스 장애가 전체 시스템 장애로 전파되는 것을 막는것이 장애 방지 설계의 핵심이다!

MSA는 많은 수의 서비스나 인스턴스가 존재할 수 있기 때문에 사람의 직접 눈으로 모니터링하고 파악하는 것은 현실적으로 어렵다.
따라서 서비스에 이상 동작을 최대한 신속하게 알 수 있어야 하고, 가능하면 자동으로 복구할 수 있도록 설계해야 한다.
➡️ Spring Cloud, Kubernetes를 이용하면 되는데 이는 추후에 배울 예정이다.

실제 넷플릭스에서는 일부로 장애를 직접 주입하고 유발하는 테스트를 진행한다고 한다.
ex) 카오스 멍키, 카오스 고릴라, 카오스 콩