1. MSA를 사용하는 이유

금일부터 카카오 x 구름 부트캠프 1회차 프로젝트 회고록을 작성하려고 한다.
아직 개발에 완전히 익숙하지 않기 때문에 글을 작성하며 배운 내용을 복습해 보일 예정이다.

 

프로젝트 주제는 다음과 같다.

• 협업을 통한 실시간 버그 해결 프로젝트는 실제 시장에서 사용되는 소프트웨어를 클론 코딩하여 디버깅과 최적화를 수행하는 것을 목표로 합니다.
• 이 프로젝트를 통해 학생들은 백엔드 시스템에서 발생하는 버그와 성능 문제를 발견하고 해결하는 방법을 학습하며, 배포 및 유지보수 과정을 포함한 소프트웨어 개발 전 과정을 경험합니다.
• 팀 협업을 기반으로 문제를 해결하며, 에러 보고서와 해설지를 작성해 서로의 작업을 평가하고 개선합니다.

우리는 깃허브에서 적합한 프로젝트를 찾았고, piggyMetrics라는 프로젝트를 최적화하기로 하였다.

"piggyMetrics"는 MSA 기반 프로젝트로, 각 서비스별로의 의존성이 낮고, Spring Cloud를 이용하여 서로의 서비스에 의존하도록 하는 프로젝트이다.

사실 지금까지는 Monolithic 아키텍쳐만 구현해 왔기 때문에 MSA를 다루는 것은 나에게 첫 도전이었다.

하지만 주저하지 않고 뛰어들어 보기로 했다.

---

프로젝트의 성능을 최적화하고 유지보수 하기위해서는 프로젝트의 구성 방식에 대해 이해할 필요가 있다.
그리하여 우선 MSA에 대해 알고 가기로 하였다.

MSA란?

MSA(MicroServices Architecture)는 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크이다.
완전히 독립적으로 배포가 가능한 것이 큰 특징이며, 다른 기술 스택에 대해 개방적이다.

1️⃣ MSA를 사용하는 이유?

백엔드 개발자가 초기에 작업하기 쉬운 아키텍쳐는 당연 모놀리틱 아키텍처일 것이다.
통일된 기술스택과 하나의 프로젝트만 관리하면 되므로 시스템 전체를 이해하기가 쉽기 때문이다.

또한 환경 설정이나 배포 과정이 단순하여 배포 환경에 적응하기 쉽다는 장점도 존재한다.

그럼에도 불구하고 MSA를 사용하는 이유는 무엇일까?

그 이유는 다음과 같다.

 

1. 독립적 배포 및 확장성
   • 여러 개의 독립적인 마이크로서비스로 구성되어 있기 때문에 특정 서비스에 대한 요구 사항이 증가할 때 해당 서비스만 확장할 수 있다. 이를 통해 매번 전체 애플리케이션을 재배포하지 않아도 되는 부담을 줄일 수 있다.
2. 업무 효율성 증가
   • 각 마이크로서비스는 독립적으로 개발 및 배포가 진행되기 때문에 팀별로 다른 언어와 프레임워크, 기술 스택을 활용할 수 있다.
   • 기술적 다양성을 보여주며, 여러 팀이 병렬적으로 기능 개발을 진행할 수 있다.
3. 장기적 유지보수의 용이함
   • 서비스가 커질수록 수정이 어려워지기 마련이다.
     하지만 MSA는 각 기능이 모듈화되어 있기 때문에 특정 서비스의 변경 사항이 다른 서비스에 영향을 거의 주지 않는 

2️⃣ MSA 장단점

위에서 MSA를 사용하는 이유를 알았으니 사용했을 때의 장점과 단점을 알아보자.

먼저 장점은 다음과 같다.

1. 확장성
   • 서비스 단위로 확장하거나 축소하여 자원을 효율적으로 활용할 수 있기 때문에 유연한 확장성을 보장한다.
2. 독립적 배포
   • 각 서비스는 개별적으로 개발 및 배포가 가능하기에 부분적인 배포 시 시스템 중단 없이 이루어질 수 있다.
3. 팀 단위 자율성
   • 각 서비스마다 별로의 리포지토리와 파이프라인을 구성할 수 있기에 책임 분배가 명확히 이루어지며,
     팀이 독립적으로 운영할 수 있다.
4. 장기적 유지보수 용이
   • 코드베이스가 집중되어 있기에 유지보수에 용이하다.

단점 또한 존재한다.

1. 분산 시스템
   • 서비스가 많아질수록 네트워크 통신이 많아지고, 각 서비스마다 의존성을 관리해주어야 하기 때문에 복잡도가 증가한다.
   • 모니터링이나 로깅 또한 복잡해진다.
2. 운영 오버헤드
   
   • 각 서비스마다 CI/CD 파이프라인, 모니터링, 로깅, 테스트 환경 등의 요소들이 필요하기에 운영 비용과 관리 부담이 커진다.

3️⃣ vs. Other Architecture

현재 가장 용이하게 사용되는 아키텍쳐에는 크게 3가지가 있다.

Monolithic Architecture, MicroServices Architecture, Service Oriented Architecture

각 아키텍쳐를 MSA와 비교하여 알아보자!

 

1. vs Monolithic Architecture

전통적 아키텍쳐로 하나의 프로젝트에 모든 서비스를 구현한다.

MSA를 모놀리틱 아키텍처와 비교했을 때 특징은 다음과 같다!

• 초기 구현과 배포가 비교적 어렵다.
• 서비스별로 배포하기에 빌드 및 배포 시간이 단축되며,
  사소한 변경 사항에도 다른 서비스에 영향을 미치지 않고 기능을 변경할 수 있다!
• 즉, 유연하고 확장성이 좋지만 운영과 관리의 복잡도가 높다!

2. vs Service-Oriented Architecture

서비스 지향 아키텍쳐로 서비스를 모듈식 단위로 모아 애플리케이션을 구축하는 아키텍처이다.

SOA에 대해 추가적인 설명을 하자면 서비스가 독립적인 것은 MSA와 마찬가지이나 DB나 인프라를 공유하여 사용한다.

기술 선택이 제한적이며, 동일한 플랫폼이나 기술 스택을 사용하는 경향이 종종 나타난다.

MSA를 SAO와 비교했을 때 특징은 다음과 같다!

• 크고 통합적인 시스템을 지향하는 SOA와 달리 빠르게 변화하는 요구사항에 대응하고 유연성을 극대화할 수 있다!
• 독립적인 작은 마이크로서비스로 구성되어 단일 책임 원칙에 충실하다.
• 독립적이기에 서로 다른 언어, 프레임워크를 사용할 수 있다.
• 느슨한 결합을 유지하며 의존성을 최소화한다.
• 분산 데이터베이스 구조를 선호한다.
• 결론은 경량화와 민첩성 측면에서는 빠른 개발과 배포가 가능하지만,
  서비스 간 통신이나 분산 시스템 관리가 복잡하다.