아키텍처(Architecture)

개요

프로젝트를 구성함에 있어 아키텍처는 필수 요소이며 개발에는 다양한 아키텍처가 활용된다.

이번 팀 프로젝트를 진행함에 있어 기존에 사용하던 모놀리식 아키텍처가 아닌 유사 헥사고날 아키텍처 구조를 사용해 프로젝트를 구성하게 되어 적응에 어려움을 겪었고, 왜 이런 어려운 구조를 사용해야 하는지 간단하게 배워보려고 한다.

 

Architecture 란?

영어 단어로 '건축학'이라는 뜻으로 내용을 풀어서 살펴보면 다음과 같다.

• 시스템 구성 및 동작 원리를 나타내는 것
• 구성 요소 간의 관계 및 시스템 외부 환경과의 관계를 묘사하는 것
• 시스템 구성 요소에 대한 설계 및 구현을 지원하는 수준을 기술하는 것
• 요구 사양 및 시스템 수명 주기를 고려하는 것
• 시스템의 전체적인 최적화를 목표로 하는 것

소프트웨어 기능의 고도화 그래프

 

좋지 않은 디자인을 가진 소프트웨어는 시간이 지날수록 기능을 추가하는 것이 어렵고 이후에도 지속적으로 어려워 지는데, 반면 좋은 디자인을 가진 소프트웨어는 기능을 추가하기 수월한대 이는 소프트웨어가 잘 컴포넌트화 되어 있기 때문입니다.

• 소프트웨어 아키텍처가 중요한 이유는 확장성이다.
• 복잡성은 시스템이 가진 고유의 특성이고 아키텍처는 복잡성을 대응하기 위한 고유의 방식이다.

 

모놀리식 아키텍처? MSA?

모놀리식 애플리케이션은 하나의 통합된 유닛으로 만들어지고, MSA(마이크로서비스 아키텍처)는 독립적으로 배포할 수 있는 소규모 서비스의 모음이다.

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

모놀리식 아키텍처 장, 단점

• 장점
  • 실행 파일 또는 디렉토리가 하나여서 배포가 쉽다.
  • 하나의 코드 베이스로 애플리케이션을 구축해 개발이 더 쉽다.
  • 중앙 집중식 코드 베이스 및 리포지토리에서는 대부분 하나의 API 만으로 MSA의 여러 API가 수행하는 것과 동일한 기능을 수행할 수 있다.
  • 하나의 중앙 집중식 장치이므로 분산된 애플리케이션보다 end-to-end 테스트를 더 빠르게 수행할 수 있다.
  • 모든 코드가 한 곳에 있으므로 요청을 따라가서 문제를 찾기 쉽다.
• 단점
  
  • 대규모 애플리케이션에서는 개발이 복잡해지고 속도가 느려진다.
  • 개별 컴포넌트를 확장할 수 없다.
  • 모듈에 오류가 있으면 애플리케이션 전체의 가용성에 영향을 준다.
  • 모놀리식의 경우 이미 사용한 기술로 제한된다.
  • 애플리케이션을 약간 변경하는 경우에도 전체를 다시 배포해야 한다.

마이크로 서비스 아키텍처 장, 단점

• 장점
  • 기능별로 마이크로서비스를 개발하고, 작업 할당을 서비스 단위로 하면 개발자가 해당 부분을 온전히 이해할 수 있다.
  • 새로 추가되거나 수정사항이 있는 마이크로서비스만 빠르게 빌드, 배포가 가능하다.
  • 해당 기능에 맞는 기술, 언어 등을 선택하여 사용할 수 있다.
  • 일부분의 오류가 있으면 해당 기능에만 오류가 발생하고 그 부분만 빠르게 고쳐서 정상화가 가능하다.
• 단점
  • 무엇보다 관리가 힘들다. 작은 여러 서비스들이 분산되어 있기 때문에 모니터링이 힘들다.
  • 서로를 호출하여 전체 서비스가 이루어지기 때문에 무조건 다른 서비스를 호출하는 코드가 추가되는데 이부분이 모놀리식 아키텍쳐의 개발보다 까다롭다.
  • 통신관련 오류가 잦을 수 있다. 마이크로 서비스들끼리 계속하여 통신을 하다보니 모놀리식 아키텍쳐에 비해 통신관련 오류가 잦다.
  • 테스트가 불편하다. End-to-End 테스트를 위해 UI, Gateway 등등 여러개의 마이크로 서비스를 구동시켜야 한다.

MSA 구조를 사용하는 것이 추후 확장성 측면에서 더 좋다는 것을 알게 되었지만, 프로젝트에 적용된 구조에 따라 개발을 하는 것은 어려움이 많다.

 

프로젝트 아키텍처 구조

 

실제로 프로젝트에 사용된 아키텍처 구조도이다.

구조도만 봤을 때는 구현하는 것이 쉬워 보이지만 실제 프로젝트 디렉토리를 확인했을 때는 기존의 방식과 다르게 매우 복잡했고 아키텍처 방식을 따라 기능을 구현하는 것에 앞서 구조를 파악하는 데도 애를 먹었다.

 

프로젝트 적용 이유

추후 MSA, Kafka, Redis 등을 배워 실제로 프로젝트에 적용해 보기 전에 유사한 아키텍처 구조로 애플리케이션을 개발해 보는 것으로 경험을 쌓고, 이해를 높이기 위함

 

개발을 하면서 느낀 힘든 점

아직 기능 개발이 다 끝나지 않았지만 클린 아키텍처와 유사 헥사고날 아키텍처를 따르기 위해 사용하면 안 되는 안티패턴이나 따라야 하는 방식 등이 기존과 달라서 코드 한 줄을 적을 때도 정보를 찾고 해당 아키텍처를 구성한 팀원에게 물어보면서 진행해서 기능 개발 속도가 잘 붙지 않았다.

 

추후 해결 또는 보충해야 될 점

아직 제대로 아키텍처와 MSA에 대해 배우지도 않았고, 클린 아키텍처에 대한 것도 모르기 때문에 그저 만들어 진 코드를 보고 수정하는 것에 가깝다.

 

MSA 같은 아키텍처와 클린 아키텍처, 객체지향에 더 깊게 공부해서 추후 MSA가 적용되는 프로젝트를 진행할 때는 온전히 내 것으로 만들 수 있어야 될 거 같다.

 

학습 내용 출처
Architecture : https://www.osckorea.com/post/bigaebaljado-swibge-ihaehaneun-akitegceoyi-gaenyeom

모놀리식 아키텍처, MSA의 장단점
https://velog.io/@ragnarok_code/%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9D-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-vs-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4