모놀리식 지옥에 빠지다

FTGO 애플리케이션 아키텍처

FTGO 모놀로식 애플리케이션

• 코어가 비즈니스 로직으로 구성된 육각형 아키텍처이다
• 비즈니스 로직은 각자가 도메인 객체 컬렉션인 모듈로 구성되며, 외부 시스템과 연계하는 어댑터가 여러 개 달려 있다.
• RestApi/ WebUI 처럼 비즈니스 요청을 호출하여 처리하는 인바운드 어댑터가 있고, 그 밖에 비즈니스 로직에서 DB/서드 파트 서비스를 호출하게 해주는 아웃바운드 어댑터가 있다.
• 논리적으로 모듈화한 아키텍처이지만 애플리케이션은 War 파일 하나로 패키징한다.

모놀로식 아키텍처 장점

• 개발이 간단하다:
• 애플리케이션을 쉽게 변경할 수 있다.
• 테스트하기 쉽다.
• 배포하기 쉽다.
• 확장하기 쉽다.

하지만 시간이 지날수록 개발, 테스트, 배포, 확장하기가 점점 어려워진다.. 왜??

모놀리식 지옥의 일상

왜 FTGO 애플리케이션이 서비스 규모가 커질수록 모놀리식 지옥에 빠진 걸까?

• 너무 복잡해서 개발자가 주눅이 든다
  • 애플리케이션이 너무 복잡해 버그를 고치고 새 기능을 정확하게 구현하기가 갈수록 어려워진다.
• 개발이 더디다
  • 애플리케이션이 너무 커져 IDE의 실행 속도도 느려지고 빌드 시간도 오래 걸린다.
  • 코드를 고치고 빌드/실행 후 테스트까지의 시간이 너무 낭비되어 생산성을 떨어트린다.
• 커밋부터 배포에 이르는 길고 험난한 여정
  • 프로덕션에 배포하는 일이 매우 힘들다.
    • 여러 개발자가 같은 코드베이스에 소스 커밋을 하다 보니 종종 릴리스 할 수 없을 때가 있다.
  • 테스트 시간이 너무 길어 변경분을 프로덕션에 반영하는 데 시간도 많이 걸린다.
• 확장하기 어렵다.
  • 모듈마다 리소스 요건이 서로 맞지 않아 확장하기 어렵다.
• 모놀리스는 확실하게 전달하기 어렵다.
  • 신뢰성이 부족하다.(덩치가 커 테스트가 힘들고 결국 버그로 이어진다.)
  • 전체 모듈이 같은 프로세스로 실행되어 결함 격리가 되지 않고 어떤 모듈에 버그 하나만 있어도 메모리 누수가 발생해 전체 애플리케이션 인스턴스가 내려가는 일도 많다
• 갈수록 한물간 기술 스택에 발목이 붙잡히다.
  • 아키텍처로 인해 한물간 기술 스택을 쓸 수 밖에 없으며, 새로운 프레임워크, 언어를 받아들이기 힘들다.
  • 전체 애플리케이션을 재작성하는 것은 리스크와 비용이 너무 높다.
  • 새 버전의 프레임워크와 호환되지 않는 버전을 사용하는 모듈이 있고, 결국 이전 기술스택을 유지하는 수밖에 없다.