[Kubernetes#2] MSA, 마이크로 서비스 아키텍처 (Micro Service Architecture)

요즘 대세는 MSA (Micro Service Architecture)이다.

마이크로 서비스 아키텍처(Micro Service Architecture, MSA)는 애플리케이션을 작은 서비스로 분할하고, 각각의 서비스가 독립적으로 배포될 수 있도록 구성하는 아키텍처 패턴입니다. 이 아키텍처 패턴은 각 서비스가 독립적으로 스케일링될 수 있고, 개별적으로 배포되고, 더 낮은 결합도와 높은 응집력을 갖게 하여 유지보수성과 확장성을 높이는 장점이 있습니다.

 

각각의 서비스는 자체적인 데이터 저장소와 독립적인 배포 파이프라인을 갖게 되며, 규모가 큰 애플리케이션을 여러 개의 작은 서비스로 분할하여 관리할 수 있게 됩니다. 이러한 특성 덕분에 시스템의 전체 중단 없이 필요한 부분만 업데이트 및 배포가 가능해졌습니다. 유연한 대응이 가능해 실시간으로 요구 사항을 반영할 수 있어 많은 기업들이 선택하고 있는 방법입니다.

 

특히, 넷플릭스와 테슬라 등 유명 테크 기업들의 성공 비결이 MSA로 알려지면서, MSA에 대한 관심은 식을 줄을 모르고 있습니다. OTT 뿐만 아니라 IT에서도 **“넷플릭스 당하다”**라는 말이 생겼습니다.

 

MSA (Micro Service Architecture)은 왜 등장했는가?

MSA 의 등장은 기존에 우리가 어떤 방식으로 개발을 해왔는지 알아야 합니다.

모놀리식 아키텍처 (Monolithic Architecture )

1. 전통적인 아키텍처이며 기존에 우리가 사용하던 개발 방식.
2. 서비스가 하나의 어플리케이션으로 돌아가는 구조.
3. 기존의 개발 방식을 사용해 개발하여 간단히 배포
4. 하나의 서비스 또는 어플리케이션이 하나의 거대한 아케텍쳐
5. 다양한 기능을 동작하는 서비스를 서버에서 실행하여 서비스

아직까지 많은 소프트웨어가 모놀리식으로 구현되어 있습니다. 소규모 프로젝트에서는 오히려 모놀리식 아키텍처가 훨씬 합리적입니다. 설계가 간단하며 유지보수가 용이하기 때문입니다.

모놀리식 아키텍처 (Monolithic Architecture ) 스케일 아웃

1. 기존의 어플리케이션을 그대로 복제하여 로드밸런싱 처리하는 구조
2. 불필요한 서비스까지 복제가 일어남.

모놀리식 아키텍처 (Monolithic Architecture ) 장점

1. 개발 초기에 단순한 아키텍처 구조로 인해 개발에 용이하다.
2. 개발 환경이 동일하기 때문에 어떤 서비스든지 복잡하지 않다.
3. 배포가 간단하다.
4. 로드밸런스를 통해 부하를 나눠 가지는 방식으로 진행.
5. 고가용성 서버 환경을 구성
6. End-to-End 테스트가 용이하다.

모놀리식 아키텍처 (Monolithic Architecture ) 단점(한계)

1. 프로젝트 규모가 커짐에 따라 어플리케이션 구동 시간이 늘어나고 배포 시간이 길어진다.
2. 조그마한 수정 사항이 있어도 전체를 다시 빌드하고 배포해야 한다.
3. 많은 양의 코드가 몰려 있어서 개발자가 모든 코드를 이해하기 힘들며, 유지 보수가 어렵다.
4. 일부분의 오류가 전체에 영향을 미친다.
5. 기술 스텍이 한 번 정해지면 변경하기 어렵다.
6. 전체 어플리케이션의 확장은 쉽지만, 부하 분산을 위해 각 컴포넌트를 독립적으로 확장하기 어렵다.

 

MSA (Micro Service Architecture)의 특징

마이크로 서비스는 소프트웨어 시스템을 작고 독립적인 기능 단위로 나누는 접근 방식입니다. 각 서비스는 자체적으로 독립적으로 배로, 운영 및 확장될 수 있습니다.

 

MSA (Micro Service Architecture) 구성 요소

• Microservices : 서비스의 독립적인 배포 및 스케일링이 가능한 작은 단위
• API Gateway : 클라이언트와 마이크로서비스 간의 통신을 담당하며, 요청 분배, 로드 밸런싱, 인증/인가 등의 기능을 수행합니다.
• Service Registry : 마이크로서비스들의 위치 정보를 등록하고, 검색할 수 있는 중앙 집중식 레지스트리
• Configuration Server : 마이크로서비스들의 환경 설정 정보를 관리하고, 런타임 시에 각 서비스에게 전달합니다.
• Circuit Breaker : 마이크로서비스 간의 호출에서 발생할 수 있는 장애를 대응하기 위한 검증 모듈

 

MSA (Micro Service Architecture) 장점

1. 작은 단위로 분리된 서비스 : 시스템을 작은 기능 단위로 분리하므로 더 쉽게 관리하고 유지보수할 수 있습니다.
2. 독립적인 배포와 확장성 : 각 서비스는 독립적으로 배포될 수 있습니다. 이로 인해 서비스에 대한 변경이 다른 서비스에 영향을 미치지 않습니다. 또한 개별 서비스를 확장할 수 있어서 리소스 사용을 효율적으로 관리할 수 있습니다.
3. 다양한 기술 스택 이용 : 각 서비스는 독립적으로 개발되기 때문에, 서비스마다 다른 언어, 프레임워크, 데이터베이스 등을 선택하여 사용할 수 있습니다.
4. 단일 책임 원칙 : 각 서비스는 특정 비즈니스 기능에만 집중하여, 단일 책임 원칙을 따릅니다. 이로 인해 코드베이스가 작고 관리하기 쉬워지며, 기능 추가나 변경이 더욱 간편해 집니다.
5. 분산 데이터 관리 : 각 서비스는 자체적으로 데이터를 관리하며, 데이터 베이스나 저장소가 서비스와 결합됩니다. 이로 인해 확장성을 보장합니다.
6. 경계 설정 및 통신 : 서비스 간의 통신은 주로 API를 통해 이루어지며, 내부 서비스 간의 통신은 주로 HTTP 또는 메시징 시스템을 활용합니다. 이로 인해 각 서비스는 격리되어 독립적으로 동작하면서도 협업할 수 있습니다.
7. 비즈니스 유연성 및 빠른 이행 : 비즈니스 요구 사항에 빠르게 대응할 수 있는 유연성을 제공합니다.

 

MSA (Micro Service Architecture) 단점

1. 서비스 간 호출 시 API를 사용하기 때문에 통신 비용 및 지연 시간이 증가한다.
2. 데이터가 여러 서비스에 걸쳐서 분산되므로 한 번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵다.
3. 단위 테스트는 쉽지만, 통합 테스트 및 End-to-End테스트 단위로 들어가면 여러 서비스의 API를 검증해야 하므로 시간과 비용이 많이 든다.
4. 각 서비스 별로 데이터베이스가 있으므로 트랜잭션을 구현하기 까다롭다.
5. 아키텍처가 다소 복잡하므로 개발 및 관리가 어렵고, 비용이 많이 든다.

 

언제 모놀리식 아키텍처를 사용하고, 언제 MSA 아키텍처를 사용하는가?

프로젝트 규모에 따라서 달라집니다. 초기 시작은 규모가 작은 경우가 많으므로 모놀리식 아키텍처로 사용하다가 아래 관점들을 비굥하여 이득이 된다면 MSA 아키텍처로 전환하는 것이 좋습니다.

1. 비용 : MSA 아키텍처를 도입할 경우, 모노리식 아키텍처에 비해 비용을 얼마나 절감할 수 있는가?
2. 개발 생산성 : 마이크로 서비스를 요구할 만큼 시스템 복잡도가 높은가? 또한 지나치게 높은 경우 MSA 생산성을 저해하지 않는가?
3. 운영 : 개발 팀에게 개발과 운영을 동시에 할 만큼 인프라가 준비되어 있는가? 또한 관리할 역량이 있는가?
4. 배포 : 배포를 충분히 자주 하고 있는가? 배포일이 정해져 있고 가끔 일어난다면 효율이 떨어집니다.