[MSA] MSA 전환 - 모놀리식 vs MSA

 

 

 

 

 

≣ 목차

 

• [MSA] MSA 전환 - 모놀리식 vs MSA
• [MSA] MSA 전환 - Spring Cloud란?

 

 

 

최근에 제가 진행한 프로젝트에서는 기존의 모놀리식 애플리케이션을 MSA로 전환하는 작업을 수행했습니다. 초기에는 단일 애플리케이션으로 모든 비즈니스 로직이 통합되어 있었기 때문에 개발 속도가 느리고, 새로운 기능을 추가할 때마다 전체 시스템에 영향을 미치는 문제가 있었습니다. 이러한 문제를 해결하기 위해 MSA로의 전환을 결정하게 되었고, 이 과정에서 MSA의 장점과 단점을 실감하게 되었습니다.

 

 

MSA란 무엇인가?

최근 소프트웨어 개발 환경은 빠르게 변화하고 있으며, 기업들은 더욱 유연하고 확장 가능한 시스템을 요구하고 있습니다. 이러한 필요성에 따라 MSA(Microservices Architecture)가 주목받고 있습니다. MSA는 복잡한 애플리케이션을 독립적으로 배포 가능한 작은 서비스들로 구성하는 아키텍처 스타일입니다. 각 서비스는 특정한 비즈니스 기능을 담당하며, 서로 독립적으로 개발, 배포 및 확장할 수 있습니다. MSA는 애플리케이션을 모듈화하여 관리의 용이성을 높이고, 개발 팀이 서로 독립적으로 작업할 수 있도록 합니다.

 

 

 

MSA와 모놀리식 아키텍처 비교

Monolithic VS Microservice

 

 

항목	모놀리식 아키텍처	MSA (Microservices Architecture)
구성	모든 비즈니스 로직이 하나의 애플리케이션에 통합	여러 개의 작은 서비스로 나누어 독립적으로 운영
배포	전체 애플리케이션을 한 번에 배포	각 서비스는 독립적으로 배포
확장성	전체 시스템을 확장해야 하므로 비효율적	특정 서비스만 선택적으로 확장 가능
개발 속도	모든 팀이 동일한 코드베이스에서 작업해야 하므로 느림	각 팀이 독립적으로 개발하므로 빠른 개발이 가능
데이터 관리	단일 데이터베이스에 모든 데이터가 저장	각 서비스가 독립적인 데이터베이스를 가짐
장애 격리	하나의 서비스에 장애가 발생하면 전체 시스템에 영향	서비스 간의 독립성 덕분에 장애가 다른 서비스에 미치지 않음
기술 다양성	동일한 기술 스택을 사용	각 서비스마다 다른 기술 스택을 사용할 수 있음
복잡성	구조가 단순하지만 코드가 커질수록 복잡해짐	서비스 간의 통신 및 관리가 복잡해질 수 있음

 

 

 

왜 MSA로 전환해야 하는가?

모놀리식 아키텍처와 MSA의 비교를 통해 각각의 특성을 이해했을 때, MSA로의 전환이 왜 필요한지를 명확하게 알 수 있습니다.

저의 경우에는, 프로젝트 진행 중 신규 서비스 추가 요구사항이 발생했으나 기존의 모놀리식 구조에서는 새로운 서비스를 통합하기가 어려웠습니다. 거기에 기존 모놀리식 서비스가 버전별로 운영중에 있었습니다. 

이번에 MSA전환 프로젝트를 진행하면서 별도로 분리되어 있던 서비스를 통합하고 새로운 요구사항을 유연하게 처리할 수 있는 기반을 만들 수 있었습니다. 제가 생각하는 MSA 전환의 이점은 다음과 같습니다. 

 

• 비즈니스 요구의 변화
  • 빠르게 변화하는 비즈니스 환경에서 새로운 기능을 신속하게 구현해야 하는 필요성이 증가하고 있습니다. MSA는 각 기능을 독립적인 서비스로 분리하여, 새로운 기능이 필요한 경우 해당 서비스만 수정하거나 추가할 수 있어 개발 속도를 크게 향상시킵니다.
• 확장성 문제 해결
  • 모놀리식 아키텍처에서는 전체 애플리케이션을 확장해야 하므로 비효율적입니다. MSA로 전환하면 특정 서비스에 대한 수요가 증가할 때 해당 서비스만 독립적으로 확장할 수 있어 자원의 효율적 사용이 가능합니다.
• 팀의 독립성 향상
  • MSA는 각 서비스가 독립적으로 운영되기 때문에, 팀이 특정 서비스에 집중할 수 있습니다. 이를 통해 팀 간의 의존성이 줄어들고, 개발과 배포 주기가 단축됩니다.
• 장애 격리와 안정성
  • 모놀리식 구조에서는 하나의 서비스에 장애가 발생하면 전체 시스템에 영향을 미칠 수 있습니다. MSA는 서비스 간의 독립성을 보장하여, 한 서비스의 장애가 다른 서비스에 영향을 미치지 않도록 돕습니다. 이는 시스템의 전체적인 안정성을 높이는 데 기여합니다.
• 기술 스택의 다양성
  • MSA는 각 서비스가 독립적으로 개발되므로, 다양한 기술 스택을 사용할 수 있는 유연성을 제공합니다. 팀은 각 서비스에 가장 적합한 기술을 선택할 수 있으며, 이를 통해 기술적 혁신을 촉진할 수 있습니다.
• 지속적인 배포와 CI/CD 지원
  • MSA는 각 서비스가 독립적으로 배포될 수 있도록 설계되어 있어, CI/CD 파이프라인을 통해 지속적으로 업데이트하고 배포할 수 있습니다. 이는 개발 프로세스를 더욱 효율적으로 만들어 줍니다.

 

 

 

모놀리식 프로젝트를 MSA로 전환 과정

 

제가 어떤 방식으로 기존 모놀리식 프로젝트를 MSA로 전환하였는지 그 과정에 대해 간략하게 기록해보려고 합니다.

 

1. 서비스 식별 및 도메인 분리
먼저, 기존에 사용중이던 기능에 대해 전수조사를 진행하였습니다. 이후 비즈니스 기능을 분석하여 각 기능을 독립적인 서비스로 분리했습니다. 이를 통해 각 서비스가 명확한 책임을 가질 수 있도록 했습니다. 

 

 

MSA로 전환 과정 1) 도메인 분리 및 서비스식별

 

 

 

2. API 설계
각 서비스 간의 통신을 위한 RESTful API를 설계했습니다. API Gateway를 통해 클라이언트 요청을 적절한 서비스로 라우팅하여, 서비스 간의 의존성을 줄였습니다.

 

 

3. 데이터베이스 분리
기존의 단일 데이터베이스에서 각 서비스가 독립적인 데이터베이스를 가지도록 변경했습니다. 이를 통해 데이터 관리를 분리하고, 서비스 간의 결합도를 낮출 수 있었습니다.

 

 

MSA로 전환 과정 3) 데이터베이스 분리

 

 

4. CI/CD 구축
서비스가 독립적으로 배포될 수 있도록 CI/CD 파이프라인을 구축했습니다. Jenkins와 Docker를 활용하여 각 서비스의 빌드 및 배포를 자동화했습니다.

 

 

MSA로 전환 과정 4) CI/CD구축

 

 

 

5. 데이터 이전

기존의 모놀리식 데이터베이스에서 각 마이크로서비스에 맞는 데이터베이스로 나누는 작업을 수행하고, 기존 서비스 운영중이던 DB에서 새로운 데이터베이스로 데이터를 옮기는 작업을 진행했습니다. 이 과정에서 데이터가 제대로 이동되었는지 충분한 테스트 진행이 필요합니다. 

 

---

 

이러한 전환 과정을 통해 애플리케이션의 유연성과 확장성을 크게 향상시킬 수 있었습니다. 또한, 각 서비스가 독립적으로 관리되므로, 새로운 기능을 추가하거나 수정하는 과정이 이전보다 훨씬 간편해졌습니다.

기존 운영중이던 서비스들까지  이처럼 MSA로의 전환은 초기에는 도전적일 수 있지만 장기적으로는 개발 효율성과 시스템 안정성을 높이는 데 큰 도움이 됩니다. 앞으로도 지속적으로 MSA의 장점을 살리며, 더 나은 아키텍처를 구축해 나갈 계획입니다.

이후에는 MSA 구축 각 단계에서의 경험과 배운 점들을 과정에 대해 자세히 소개하겠습니다.