[Project] 아키텍처 결정

프로젝트를 진행하기 전 프로젝트에 적합한 소프트웨어 아키텍처를 선택하기 위한 고민을 해봤다.

애플리케이션의 아키텍처 스타일에 대한 선택은 애플리케이션의 목표와 비즈니스 요구 사항에 따라 달라진다.

모놀리식 아키텍처

전체 애플리케이션을 단일 코드로 작성해서 단일 데이터베이스에 연결한다.

장점

모든 코드가 단일 코드 베이스에 있기 때문에 애플리케이션을 로컬에서 실행할 경우 단일 애플리케이션만 실행하면 된다.

단일 프로젝트로 배포하면 되므로 간편하다.

모든 코드가 단일 애플리케이션에 있기 때문에 디버깅하기가 쉽다.

단점

애플리케이션이 크고 복잡해지만 유지 보수하기가 어렵다.

서비스를 확장하기 위해서는 전체 애플리케이션을 확장해야 한다.

모든 팀이 동일한 프로젝트에서 작업하므로 코드 병합에 대한 충돌 가능성이 높다

한 번 기술로 선택해서 구현하면, 다른 기술로 변경하는 것이 어렵다.

마이크로서비스 아키텍처

애플리케이션을 작은 서비스로 분할하고, 각 서비스가 서로 독립적이다.

장점

특정 마이크로서비스만 확장할 수 있으므로, 독립적인 확장이 가능하다.

여러 소규모 서비스로 분할하면 하나의 서비스가 영향을 받아도 전체 애플리케이션에 영향을 최소화 한다.

각 서비스 별로 데이터베이스를 소유할 수 있다.

각 서비스마다 적합한 기술 스택을 사용할 수 있다.

단점

디버깅을 하나거나 테스트를 하기 위해 여러 마이크로서비스를 실행해야할 경우가 있다.

마이크로서비스간의 통신이 오히려 애플리케이션의 복잡성을 증가시킨다.

프로젝트에 적합한 선택은 무엇일까?

다음과 같은 질문을 통해 현재 상황을 분석해보자.

애플리케이션이 크고 복잡해질 가능성이 높은가??

개인 프로젝트인 점, 그리고 계획한 플로우가 크게 복잡하지 않은 점. 추가적인 요구사항이 발생하더라도 마이크로서비스로 구분해야할 정도로 크고 복잡해질 가능성이 높다고 하기엔 어렵다.

팀이 도메인에 대해 잘 알고 있는가?

예매 도메인을 처음 구현해보기 때문에, 잘 모른다.

가용성과 확장성을 갖춰야 하는가?

많은 요청을 수용할 수 있어야하기 대문에 장애 상황을 해결하고 서비스를 지속할 수 있도록 높은 가용성을 갖춰야 한다.

그리고 많은 요청에 따라 쉽고 빠르게 규모를 늘릴 수 있어야 한다.

마이크로서비스에 대한 경험이 있는가?

없다.

 

따라서 마이크로서비스를 선택하는 것보다 모놀리식 아키텍처를 선택하는 것이 적절하다고 판단된다.

먼저 모놀리식으로 개발을 진행한다. 다만 프로세스 내부의 코드를 모듈로 분해하는 모듈식 모놀리스 아키텍처를 통해 추후 프로젝트의 확장에 따라 마이크로서비스로 전환이 가능하도록 프로젝트를 진행한다.

애플리케이션이 성장함에 따라 확장성이나 배포 속도 문제로 인해 계층화된 모놀리식 아키텍처가 더 이상 요구 사항을 충족하지 못한다고 판단될 수 있다. 이때 복잡성이 증가하는 대신 유연성과 확장성이 뛰어난 마이크로서비스 아키텍처로 리팩토링하는 것을 고려할 수 있다.

 

선택 - Layered Architecture

각 구성 요소들이 ‘관심사의 분리’를 달성하기 위해 책임을 가진 계층으로 분리하는 아키텍처

모듈식 모놀리식 아키텍처의 한 유형으로 간주할 수 있다. 배포 가능한 단일 단위라는 의미에서 '모놀리식'이지만, 코드를 논리적으로 서로 분리된 계층으로 구성하기 때문에 '모듈식'이다.

관심사 분리를 하는 이유

하나의 계층에 관심사가 여러 개 존재한다면 해당 계층의 응집도가 떨어지고 결합도가 떨어진다.

각 계층들을 관심사 기준으로 분리해서 계층의 응집도를 높이고 결합도를 낮춘다.

높은 응집도와 낮은 결합도를 통해 재사용성과 유지보수성을 높일 수 있다.

Layered Architecture의 의존성

한 계층에서 자신의 책임 외의 행위는 하위 계층에 의존하는 구조여야 한다.

하위 계층은 상위 계층에 대한 지식이나 정보가 없어야 한다. 단지 간접적으로 넘어온 데이터를 비즈니스 로직을 처리하도록 한다.

프로젝트 관점에서 이점

• 복잡한 아키텍처에 대한 경험이 적은 개발자의 경우 계층화된 설계를 이해하고 구현하기가 더 쉽다.
• 한 계층의 변경 사항이 다른 계층에 영향을 미치지 않기 때문에 새로운 기능을 추가하거나 버그를 수정하는 작업을 신속하게 수행할 수 있다.
• 각 레이어를 독립적으로 테스트할 수 있어 단위 테스트가 더욱 관리하기 쉬워진다. + 레이어 간의 상호작용을 테스트해서 올바르게 통신하는지 확인할 수 있다.

프로젝트 관점에서 단점

모놀리식 아키텍처의 단점을 가진다.

애플리케이션이 분산되도록 설계되지 않았기 때문에 특정 서비스에 대한 수요가 높아지면 해당 서비스만 확장하는 것이 어려움. 코드베이스가 커지면 변경 작업이 더 느려지고 위험해질 수 있다. 그리고 애플리케이션의 크기와 복잡성이 증가하여 배포에 더 많은 시간이 소요될 수 있다.