출처
https://velog.io/@whattsup_kim/애플리케이션-아키텍처란
https://www.redhat.com/ko/topics/cloud-native-apps/what-is-an-application-architecture
📌 소프트웨어 구성도란?
🔍 정의
- 소프트웨어 시스템의 구조와 구성요소 간의 관계를 시각적으로 표현하는 도구
- 소프트웨어 시스템의 설계, 개발 및 유지 보수를 이해하고 관리하는 데 도움
- 시스템의 다양한 레이어, 컴포넌트, 모듈, 인터페이스 등을 포함.
🔍 구성요소
- 레이어(Layer):
- 소프트웨어 시스템을 구성하는 다양한 레이어를 표시
- 사용자 인터페이스(UI), 비즈니스 로직(Business Logic), 데이터 엑세스(Data Access), 등의 레이어 포함
- 컴포넌트(Components):
- 소프트웨어의 구성 요소
- 각 컴포넌트는 특정 기능을 수행하거나 특정 역할을 담당함.
- 로그인 모듈, 결제 처리 모듈, 이메일 서비스 모듈 등이 될 수 있음.
- 모듈(Modules):
- 소프트웨어의 구성 요소를 더 잘게 쪼갠 것
- 각 모듈은 독립적으로 개발, 테스트 할 수 있는 단위로 구성됨.
- 인터페이스(Interfaces):
- 컴포넌트 또는 시스템 간의 상호작용을 나타냄.
- 이는 API, 웹 서비스, 메시지 큐 등과 같은 인터페이스를 의미할 수 있음.
- 데이터 플로우(Data flows):
- 소프트웨어 내에서 데이터의 이동 경로를 보여줌.
- 데이터의 생성, 처리, 저장 및 전달과 같은 과정을 시각적으로 표현해줌.
- 라이브러리 및 프레임워크(Libraries and Frameworks):
- 소프트웨어 개발에 사용되는 외부 라이브러리나 프레임 워크 등을 표시할 수 있음.
📌 그래서 시스템 구성도(System Architecture)와의 차이점은?
🔍 지피티의 답
그렇다고 한다.
그렇다면 이쯤에서 다시 시스템 구성도란 뭘까에 대해 알아보자
🔍 시스템 구성도란?
- 시스템의 전체 구조도를 시각적으로 표현하는 도구
- 시스템의 다양한 구성 요소와 이들 간의 상호작용을 보여줌으로써 시스템의 설계와 이해를 돕는다.
- 시스템의 구성도는 일반적으로 하위 시스템, 모듈, 서비스, 데이터 흐름 등을 포함.
🔍 어플리케이션 아키텍처??
시스템 구성도는 아마 많은 사람들이 만들어봤고, 예시작을 봤을 것이다.
여러 시스템들의 아이콘들이 모여있는 이미지를 떠올릴텐데
출처: https://techblog.lotteon.com/뉴온이들의-첫-msa-서비스-도전기-d336186a7e31
이런 느낌이지 않을까 싶다.
그에 반해 소프트웨어 구성도는 뭘까.. 하고 예시작을 찾아봤는데
출처: https://techblog.lotteon.com/뉴온이들의-첫-msa-서비스-도전기-d336186a7e31
아니 이것 그 잡채가 아닌가!!!!!!!!..... SW구성도라고 했을땐 자료도 얼마 안나왔는데 어플리케이션 아키텍처라 검색하니 정말 수많은 정보가 쏟아져 나왔다.
어도비의 어플리케이션 아키텍처,,,, 내가 원했던게 이런거임 ㅜㅜ
🔍 그래서 어플리케이션 아키텍처란 또또 뭔데??
애플리케이션 아키텍처는 애플리케이션을 설계하고 구축하는 데 사용하는 패턴과 기술을 설명합니다.
🔍 어플리케이션 아키텍처의 종류
N-tier 아키텍쳐
- 레이어는 책임을 구분하고 종속성을 관리하는 방법
- 레이어마다 특정 책임이 있음
- 상위 레이어는 하위 레이어의 서비스를 사용할 수 있지만 하위 레이어는 상위 레이어의 서비스를 사용할 수 없음 - N계층 아키텍처는 폐쇄형 레이어 아키텍처 또는 개방형 레이어 아키텍처를 사용할 수 있다.
- 폐쇄형 : 자신과 맞닿아있는 하위 레이어로만 접속이 가능
- 개방형 : 하위에 있는 모든 레이어로 접속이 가능 - MSA가 많이 사용되고 있는 요즘 모노로틱한 특성 때문에 지양되는 중
Web-Queue-Worker 아키텍처
- 애플리케이션의 웹 프론트엔드는 HTTP 요청을 처리하고 백엔드 작업자(worker)는 CPU 집약적인 작업이나 장기 실행 작업을 수행한다. 이때, 프론트엔드는 비동기 메시지 큐(Queue)를 통해 작업자(worker)와 통신한다.
현재 내가 사용하려는 아키텍처와 거리가 있기 때문에 이정도로만 넘어가겠다
자세한건 여기로..!
마이크로 서비스 아키텍처
- 모든 요소를 하나의 애플리케이션에 구축하는 전통적인 모놀리식 접근 방식 대신, 마이크로 서비스는 작고, 독립적이며, 느슨하게 결합되어 있다.
- 각 서비스는 소규모의 집중 개발 팀에서 구축할 수 있으며, 개별 서비스를 배포할 때 팀 간의 조정이 거의 필요 없으므로 업데이트를 자주 수행할 수 있다(서비스를 독립적으로 배포할 수 있음).
- 서비스가 잘 정의된 API를 사용하여 서로 통신하며, 각 서비스의 내부 구현 세부 정보는 다른 서비스에서 볼 수 없다.
- 다중저장소 프로그래밍을 지원한다(모든 서비스가 동일한 기술 스택을 공유할 필요가 없음).
- 마이크로 서비스는 빠른 릴리스, 빠른 개발, 빠른 혁신, 복원력이 있는 아키텍처이다. 하지만 마이크로 서비스 아키텍처는 N-tier 아키텍처 또는 Web-Queue-Worker 보다 빌드 및 관리 방법이 좀 더 복잡함.
- 성숙한 개발 및 DevOps 문화가 필요함
- 관리/오케스트레이션, API 게이트웨이와 같은 요소가 추가적으로 필요
📌 끝맺음
사실 그래서 결국 내가 만드려던건 어플리케이션 아키텍처였고..! 교수님은 SW 아키텍처라고 하셨고..! 그래서 정확히 뭐가 뭐다! 라고는 말 못하겠다.
하지만 내 생각에는 어플리케이션 아키텍쳐와 SW 아키텍쳐는 굉장히 유사한 것 같다.
만약에 내가 SW 아키텍처를 만드려고 한다면 어플리케이션 아키텍처의 종류 중에서 내가 빌드하려는 시스템과 유사한 아키텍처를 골라 만들면 될듯
.jpeg)