MSA : 패턴과 핵심 기술

MSA ( Microservice Architecture )

하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐를 의미함 

 

 

기존의 전통적 개발 방식에서는 전체 단일 코드 베이스로 개발했했고, 단일 코드 베이스를 빌드/배포함

 

모놀로틱 아키텍쳐		전통적인 시스템 개발 스타일로, 하나의 애플리케이션 내에 모든 로직이 들어가 있는 구조로 구성되어 있다. 이렇게 구성된 애플리케이션의 소스 코드는 하나의 프로젝트로 구성되어 있으며, 단일 패키지로 배포되게 된다. 빌드 및 배포 시간, 서버의 기동 시간이 오래 걸린다. 부분적 스케일 아웃이 어렵다. 안정성이 떨어진다. 간단한 기능 추가가 어려움 작은 수정 부분을 위해서 통합 테스트를 수행해야 한다. 부분적 장애가 전체 서비스의 장애로 이어진다
서비스 지향 아키텍쳐 SOA		서비스 지향 아키텍처(Service Oriented Architecture: SOA)는 대규모 시스템을 구축할 때의 개념으로 업무상의 일 처리에 해당하는 소프트웨어 기능을 비즈니스적인 용도로 분류하고 기능 단위로 묶어서 하나의 표준 Interface를 통해 각각을 "서비스"로 조합하는 것을 의미한다. 즉, 비즈니스적으로 구분된 서비스들을 느슨하게 연결하며, 각 컴포넌트를 독립적으로 운영하여 조립이 가능하게끔 하며, 각각의 비지니스 로직을 재사용할 수 있도록 한다.
MSA		하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리하고, 각각의 서비스들이 API를 통해 서로 통신할 수 있도록 설계하는 패턴을 말한다

 

 

MSA의 장단점 

 

장점

• 상대적으로 운영하기 용이하다
  • 코드 관리, 장애 관리, 로그 관리, 모니터링
• 내부 메소드 호출로 성능 문제가 없다.
  • MSA는 network를 통한 Interface호출 
• 트랜잭션 관리가 용이해진다.
  • MSA는 DB를 따로 관리하므로 데이터 일관성이 지켜지기 어려움 

 

단점

• 스케일 아웃 시 ( 트래픽 몰림 ) 전체 시스템을 확장해야 해서 비 효율적이다.
• 빌드/ 배포 테스트 시간이 매우 오래 걸림 
• 작은 수정에도 전체 시스템을 빌드/배포해야 한다. ( bug fix가 느려짐 ) 
• 하나의 버그에 전체 시스템이 실패될 수 있다.
• 기능들 간의 결합도가 일반적으로 높다
  • 다른 기능의 테이블이 직접 접근해서 수정을 하기도 함
• 기능 변경 시 영향도 파악이 어렵다
  • 코드-데이터 의존 관계
• 코드가 운영환경에 민첩하게 배포되기 어렵다. ( 코드 베이스가 너무 크고, 결합도가 강해서 영향도 파악이 어려움 )

 

 

 

MSA를 통해 얻을 수 있는 베네핏 

1. 빠르게 변화하는 비지니스 환경에 민첩한 대응이 가능함
2. 작은 서비스 단위로 확장이 가능하므로 확장성이 높음
3. 일부의 장애가 시스템의 전체 장애로 이루어지지 않음
4. 서비스 단위로 자율적인 배포가 가능해짐
5. 서비스마다 적절한 기술을 도입하여 Polyglot을 적용하는것이 가능함 

 

 

 

Monology System

[1] Single Monolithic System

- 가장 일반적인 형태 ( 큰 진흙공[강한 결합도] )

 

Monolith의 큰 문제점

• 기능 간 결합도
• 코드 수정 

 

[2] Modular Monolith System 

- 각 기능별로 모듈화가 되어있는 형태  ( 패키지, 멀티 모듈 프로젝트 ) 

- MSA의 좋은 대안 

 

Modular Monolith 문제점

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

 

 

Distributed Monolithic System

..