함부로 무시하는 MSA Inner Architecture 설계 원칙

MSA 전환 시 Inner Architecture 설계 기준과 절차, 방법

MSA Inner Architecture 설계 원칙

FACT ^{주장/현상/관념}

클라우드의 발전과 서비스 유연성 향상에 대한 요구로 MSA(Microservice Architecture)로의 전환이 빠르게 확산되고 있습니다. 즉 (1) 클라우드의 유연성과 확장성을 활용하여 애플리케이션을 개발하고 운영하기 위해 (2) 서비스 다양화와 빠른 출시가 필요해지면서 (3) 과거와 다르게 서비스를 유연하고 안정적으로 운영할 수 있는 기술과 인프라 자원의 등장으로 MSA로 전환 혹은 신규 구현을 하고자 합니다.

 

MSA 전환/전환 시 Inner Architecture 설계는 비즈니스와 시스템의 특성에 맞게 서비스를 효과적으로 분리하고, 각 서비스의 독립성과 확장성을 보장하는 데 초점을 맞춥니다. 여기서는 Inner Architecture 설계 시 고려해야 할 주요 기준과 절차, 방법을 알아보겠습니다.

---

CHECK ^{검증/실상/검토}

Legacy 시스템 vs. MSA 비교

기존 Legacy 시스템(모놀리식 아키텍처)과 MSA(마이크로서비스 아키텍처)의 개발 및 운영, 기술 스택 등을 비교하면 아래 표와 같은 특징을 알 수 있습니다.

항목	Legacy 시스템	MSA
구조	단일 계층으로 구성된 하나의 큰 덩어리. 코드베이스와 서비스가 긴밀히 결합됨[1].	여러 개의 독립적인 서비스로 분리되어 있으며, 각 서비스는 자체 기능을 가짐[3].
배포	전체 애플리케이션을 한 번에 배포해야 하며, 일부 수정 시에도 전체를 재배포해야 함[1].	각 서비스는 독립적으로 배포 및 업데이트 가능. 변경 사항이 전체 시스템에 영향을 미치지 않음[2].
확장성	전체 애플리케이션을 확장해야 하므로 비효율적[1].	필요한 서비스만 독립적으로 확장 가능. 클라우드 환경에서 높은 확장성 제공[2].
장애 대응	한 부분의 장애가 전체 시스템에 영향을 미침[1].	한 서비스의 장애가 다른 서비스에 영향을 미치지 않음. 격리된 구조로 안정성 높음[2].
개발 및 유지보수	코드베이스가 커질수록 복잡성 증가. 변경 및 유지보수가 어려움[1].	작은 단위의 서비스로 구성되어 유연성과 개발 생산성이 높음[2].
데이터 관리	단일 데이터베이스를 사용. 데이터 정합성 관리가 비교적 쉬움[3].	각 서비스는 독립적인 데이터베이스를 가짐. 데이터 일관성 유지를 위해 추가적인 전략 필요[3].
기술 스택	단일 기술 스택 사용. 기술 변경이 어려움[1].	서비스마다 다른 기술 스택 사용 가능. 기술 선택의 유연성이 높음[2].
통신 방식	내부 모듈 간의 직접적인 통신. 복잡성이 낮음[3].	서비스 간 통신은 API를 통해 이루어짐. 비동기 통신 및 메시지 큐 활용 가능[2].

 

MSA 전환/구현으로 얻을 수 있는 장점은 다음과 같습니다. (1) MSA 전환으로 유연성, 확장성, 유지보수의 용이성, 개발속도 향상 등의 이점을 얻을 수 있습니다. (2) 각 서비스가 독립적으로 운영되므로 DevOps 팀은 가동 중지 시간 없이 새 구성 요소를 원활하게 도입할 수 있습니다. (3) 결함 분리 개선, 팀 생산성 향상, 더 빠른 배포 시간, 비용 효율성 향상 등의 효과가 있습니다.

 

Inner Architecture 설계 기준

1. 서비스 정의
   • 비즈니스 도메인과 기능에 따라 서비스를 분리합니다. 예를 들어, 쇼핑몰 시스템에서는 주문, 결제, 배송 등을 별도의 서비스로 나눌 수 있습니다.
   • 서비스 간의 종속성, 배포 용이성, 장애 대응, 운영 효율성 등을 고려하여 서비스 경계를 설정합니다[1][2].
2. DB 접근 구조 설계
   • 각 마이크로서비스는 자체 데이터베이스를 가질 수 있으며, 데이터의 정합성을 보장하기 위해 API를 통해 데이터를 접근합니다.
   • 여러 서비스에 걸친 트랜잭션의 경우, 메시지 큐(Message Queue)나 보상 트랜잭션을 활용하여 비동기적으로 처리합니다[1][5].
3. API 설계
   • 서비스 내 API는 논리적인 컴포넌트 레이어를 기반으로 설계합니다.
   • RESTful API 또는 GraphQL 등을 활용하여 서비스 간 통신을 효율적으로 관리합니다[1][6].
4. 트랜잭션 처리
   • 가능한 한 하나의 마이크로서비스에서 트랜잭션을 완결성 있게 처리하도록 설계합니다.
   • 데이터 복제는 허용하되, 정합성 원칙에 따라 무결성을 보장합니다[5].

 

Inner Architecture 설계 절차

1. 비즈니스 도메인 분석
   • 비즈니스 요구사항과 도메인을 분석하여 서비스 경계를 정의합니다.
   • 도메인 주도 설계(DDD)의 Bounded Context 개념을 활용할 수 있습니다[5].
2. 서비스 분리 및 정의
   • 기능별로 서비스를 분리하고, 각 서비스의 책임 범위를 명확히 합니다.
   • 서비스 간의 의존성을 최소화하여 독립성을 확보합니다[1][2].
3. 데이터 모델링
   • 각 서비스의 데이터베이스를 독립적으로 설계하고, 데이터의 일관성을 유지하기 위한 전략을 수립합니다.
   • 이벤트 소싱(Event Sourcing)이나 CQRS(Command Query Responsibility Segregation) 패턴을 고려할 수 있습니다[5].
4. API 및 통신 프로토콜 설계
   • 서비스 간 통신을 위한 API를 설계하고, 비동기 통신을 위한 메시지 큐를 활용합니다.
   • REST, gRPC, AMQP 등의 프로토콜을 선택하여 통신을 최적화합니다[6].
5. 테스트 및 검증
   • 각 서비스의 독립적인 테스트 환경을 구성하고, 서비스 간 통합 테스트를 수행합니다.
   • CI/CD 파이프라인을 통해 지속적인 통합과 배포를 자동화합니다[1][6].

 

Inner Architecture 설계 방법

1. 도메인 주도 설계(DDD)
   • 비즈니스 도메인을 중심으로 서비스를 설계하며, Bounded Context를 활용하여 서비스 경계를 명확히 합니다[5].
2. 이벤트 기반 아키텍처
   • 이벤트 소싱과 메시지 큐를 활용하여 서비스 간의 느슨한 결합을 달성합니다.
   • 비동기 통신을 통해 시스템의 확장성과 유연성을 높입니다[1][5].
3. CQRS 패턴
   • 명령(Command)과 조회(Query)를 분리하여 데이터의 일관성과 성능을 최적화합니다[5].
4. CI/CD 자동화
   • 지속적인 통합(CI)과 지속적인 배포(CD)를 통해 빠른 개발과 배포 주기를 지원합니다[1][6].

---

WRAP-UP ^{결어/종합/대안}

Legacy 시스템(Monolithic Architecture)은 단순한 구조와 쉬운 관리가 장점이지만, 확장성과 유연성이 부족합니다. 반면, MSA(Micro Service Architecture)는 높은 확장성과 유연성을 제공하지만, 분산 시스템의 복잡성과 데이터 관리의 어려움이 존재합니다. 그럼에도 불구하고 클라우드의 발전과 서비스 유연성 향상에 대한 요구로 MSA로의 전환이 이루어지고 있습니다.

MSA의 Inner Architecture 설계는 비즈니스와 시스템의 특성에 따라 유연하게 적용되어야 하며, 표준화된 방법보다는 각 조직의 필요에 맞춰 최적화된 설계가 중요합니다.

 

2025.03.12.

AUDITORIS

 

 

Citations: Monolithic System vs MSA
[1] https://www.purestorage.com/kr/knowledge/legacy-apps-vs-modern-apps.html
[2] https://velog.io/@momona/msa01
[3] https://happy-jjang-a.tistory.com/311
[4] https://www.mendix.com/ko/blog/killing-your-companys-legacy-applications-the-right-way/
[5] https://ws-pace.tistory.com/225
[6] https://www.samsungsds.com/kr/insights/msa.html
[7] https://www.ibm.com/kr-ko/think/topics/legacy-application-modernization
[8] https://hahahoho5915.tistory.com/71

 

Citations: 설계 기준 및 절차
[1] https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-2-MSA-Outer-Architecure
[2] https://qgqg264.tistory.com/156
[3] https://jeongjin984.github.io/posts/Software-Engineering-MSA/
[4] https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3API-Gateway-nvk2kf0zbj
[5] https://www.lgcns.com/blog/cns-tech/36171/
[6] https://velog.io/@hwang95/MSA-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3-%EA%B5%AC%EC%84%B1-%EC%9A%94%EC%86%8C
[7] https://www.samsungsds.com/kr/insights/1239180_4627.html
[8] https://wiki.tistory.com/entry/msa-overview
[9] https://may9noy.tistory.com/1111