Intro

아키텍처란 무엇인가?

<아래는 위키백과의 내용이다.>

• 시스템 구성 및 동작 원리를 나타내고 있다.
• 시스템 구성 요소(부품)에 대해 설계 및 구현을 지원하는 수준으로 자세히 기술된다. (IEEE 1471 또는 TOGAF 등)
• 구성 요소 간의 관계 및 시스템 외부 환경과의 관계가 묘사된다.
• 요구 사양 및 시스템의 전체 수명주기를 고려한다.
• 시스템 전체(하드웨어와 소프트웨어를 포괄한 것)에 대한 논리적인 기능 체계와 그것을 실현하기 위한 구성 방식이며, 시스템의 전체적인 최적화를 목표로 한다.

위의 내용을 보면 무엇이 떠오르는가? 다양하다면, 위의 정의는 이미 실패한 것이나 마찬가지거나, 단순하게 정의할 수 있는 게 아니라는 것을 의미한다.

실제로, 나도 모놀리식 아키텍처와 마이크로 서비스 아키텍처를 대립적으로 분석하기 위해 해당 용어를 썼다.

즉, 해당 글은 모놀리식 아키텍처의 장단점. 마이크로 서비스 아키텍처의 장단점을 다루고자 한다.

다만, 이 주요한 주제에 관해서는 지속적인 발전과 변화가 있기 때문에 내가 기록한 것은 언제든 수정될 수 있으며 정답이 아닐 수 있으며 단순한 참고자료에 지나지 않는다.

왜 이런 문제를 가지고 왔는가?

우선 나는, 금융도메인에 관심이 있다. 경영학과를 졸업한 영향도 있겠지만 금융에 관한 지식에 흥미가 적은 사람은 없으리라 생각한다.
그렇다면 금융에 관한 개발 도메인을 어떻게 학습하는게 좋을까?
관련한 기술 컨퍼런스를 참조하는게 가장 좋을 것이다.
그래서, 토스의 2023 컨퍼런스를 확인했고 굉장히 흥미가 돋는 여러가지 주제 중에 한 가지를 꼽자면, 은행 최초 코어뱅킹 MSA 전환기 (feat. 지금 이자 받기)이 영상이 나에게는 가장 크게 와 닿았다.

컴공 선배 중에서도 MSA경험을 쌓아 보는 것의 중요성을 언급해 주신 것도 있고, 모놀리식의 한계를 극복하기 위해 MSA를 도입했습니다!와 같은 영상을 보고

여러 블로그를 조금 살펴보기만 해도, 모놀리식에 관해서는 스파게티 코드 등의 용어가 붙고, 언제 문제가 생길지 알 수 없다. 라는 표현이 자주 사용되는 것을 심심찮게 보게 됩니다.

MSA가 이점이 많아 보이는 건 사실이고 , 저 역시 그렇게 생각했지만 스터디원이 MSA를 도입하지 않고 모놀리식을 유지하는 이유와 MSA의 단점을 생각해 보면 좋은 학습이 될 거 같다고 얘기해줬고, 이에 관한 학습을 진행합니다.

결론부터 말씀드리면,

두 아키텍처 모두 좋은 방식입니다. 각각의 장단점이 뚜렷하며, 이는 회사가 어떠한 방향성을 가지고 나아가냐에 따라서 다르게 선택할 수 있을 것입니다.

이렇게 생각하게 된 이유는 개발자의 최대 SNS라고 불리는 Stack-Over-flow는 모놀리식을 사용합니다.
관련 글

관련글의 내용을 통해서도 알 수 있지만 모놀리식으로도 충분히 월 40억건의 데이터를 처리할 수 있으며 이 정도 트래픽을 처리할 수 있다면, MSA의 이점으로 자주 언급되는 트래픽에 대한 문제를 해결하기에는 충분해 보입니다.

그렇다면 현재 왜 MSA가 각광을 받고 있고 모놀리식은 단점이 많은 것처럼 언급이 될까요?

(이미지출처)

MSA의 큰 장점은 위의 두 가지의 나누어진 이미지를 통해 이해할 수 있지만, 위의 형태처럼 서비스를 각각의 모듈로 나눌 수 있고 이를 통해 분산처리가 가능하다는 것입니다.

반면, Monolithic의 경우는 하나의 거대한 서비스를 가지기 때문에 어떤 특정 서비스에 부하가 크게 발생하게 되면 문제가 생길 수 있다는게 일반적으로 알려진 특징입니다.
그럼, 각각의 장단점을 살펴 보죠.

모놀리식(Monolithic) 장단점

장점

• 빠른 개발: 모든 코드와 리소스가 하나의 코드 베이스에 있으므로, 복잡한 분산 시스템을 처리할 필요가 없다.
• 쉬운 테스트와 디버깅: 독립적으로 실행되는 서비스가 없으므로, 통합 테스트가 더 쉽고 디버깅도 간단.
• 쉬운 배포: 하나의 애플리케이션을 서버에 배포 가능
• 쉬운 네트워크 관리: 각 서비스 간의 복잡한 인터페이스나 네트워크 통신을 관리할 필요가 없음.

단점

• 부족한 유연성: 각 구성요소는 독립적으로 확장되거나 수정될 수 없으므로, 특정 기능이 부하를 받을 때 전체 시스템 확장이 필요.
• 장애의 전파: 한 부분에서 문제가 발생하면 전체 시스템에 영향을 줄 수 있음.
• 기술 스택의 제한: 모든 구성요소가 하나의 애플리케이션에 포함되므로, 특정 기술 또는 언어를 사용하는 것이 어려움.

마이크로서비스 아키텍처(Microservice Architecture, MSA) 장단점

장점

• 확장성: 각 서비스는 독립적으로 확장될 수 있으므로, 특정 서비스에 부하가 발생하면 해당 서비스만 확장 가능.
• 유연성: 서비스는 독립적으로 개발되고 배포될 수 있으므로, 새로운 기술을 채택하거나 기존 서비스를 수정하는 것이 쉬움.
• 장애 격리: 한 서비스에서 문제가 발생하더라도, 다른 서비스에는 영향을 미치지 않음.

단점

• 복잡성: 서비스 간의 통신, 데이터 일관성 유지, 분산 시스템 관리 등의 복잡한 문제를 관리해야함.
• 테스트와 디버깅의 어려움: 분산 시스템의 복잡성 때문에 테스트와 디버깅이 어려울 수 있음.
• 배포 및 운영의 어려움: 각 서비스가 독립적으로 배포되고 운영되므로, 복잡한 배포 및 모니터링 전략이 필요.

장단점을 통해서 보자면 각각을 사용하는 이유와 선택하는 이유가 분명하다.

높은 확장성을 가지기를 희망하고 이에 관한 개발 인력을 충분히 둘 수 있으며 이를 전반적으로 관리할 수 있는 역량이 있다면 MSA를 채택하고 이를 이용해 적극적으로 서비스를 개발하고 새로운 기술을 도입할 수 있을 것이다.

반면에, 적은 개발 인력 또는 적은 자본을 가지고 최적의 개발을 하고, 더 핵심 기능 하나에 집중하는 경우라면 이러한 확장성을 고려하지 않아도 된다.

오히려 어떻게 더 적은 자원을 효율적으로 활용할 수 있을지의 최적화를 고민하고 알고리즘을 발전시키며 자신의 서비스를 효율적으로 거듭나게 만들어 나가는 방법을 모색하게 되는 것이다.

이러한 핵심적인 요소에 중점을 둔 모놀리식 개발의 성공적인 사례가 StackOPverFlow지 않을까 싶다.

• 코드베이스의 일관성: 모든 개발자가 동일한 코드베이스를 사용하므로, 코드의 일관성을 유지하는 것이 더 쉽다.
• 배포의 단순성: 하나의 애플리케이션만 관리하면 되므로, 배포 프로세스가 단순하고 예측 가능하다.
• 성능 최적화: 모든 코드가 하나의 애플리케이션에 있으므로, 성능 최적화를 위한 변경이 더 쉽다.

결론

MSA를 못해야 한다는 건 아니다. 오히려 MSA가 실질적으로는 더 어렵다. 더 일이 많고 그걸 통해서 다양하게 상호작용하는 것에 대해 익히게 된다면 모놀리식의 사용은 더 없이 쉬울 것이다.

다만, 모놀리식에서 MSA로 전환한다는 것에 관해서는 신중할 필요가 있으며 미래에 MSA로 확장한 서비스라 할지라도 핵심적인 기능으로 살아남게 된다면 다시 모놀리식으로 일원화 시키는 방식에 대해서도 고민해 봄으로써 회사에 더 좋은 방향에 관해 끊임 없이 고민하고 언제든지 전환할 수 있는 열린 시각의 개발자가 될 수 있도록 하자 :)