[스프링] 아키텍쳐

아키텍쳐란?

"하나의 서비스가 어떻게 구성이 되며 어떻게 동작이 된다" 라고 표현이 되는데,

즉, 서비스의 동작 원리를 나타내는 것 입니다.

 

프로젝트를 리딩할때, 해당 프로젝트에 대한 핵심 가치를 기준으로 내린 결정들의 집합이라고도 생각해 볼 수 있다.

 

결국 소프트웨어 개발에서 중심축 (요구 분석부터 구현 테스팅까지 작업의 뼈대 ) 역할을 한다

 

아키텍쳐 설계란?

시스템에 대한 아키텍쳐를 정하는 의사 결정 과정이라고 생각하면 됩니다!

즉, 소프트웨어 아키텍쳐란 의사 결정의 집합체라고 볼 수 있다.

 

아키텍쳐 스타일

1. 클라이언트 서버형

 

• 서버 - 강력한 성능으로 자원을 관리하며 클라이언트가 요청하는 기능이나 자원을 제공
• 클라이언트 - 서버에 있는 자원의 사용을 위하여 서버에 접속함

클라이언트 서버형 ( 출처 - 소프트웨어 공학의 모든 것 277page )

 

장점

• 데이터 집중화 - 모든 데이터는 서버에 모아서 데이터의 구성과 관리를 단순화 함
• 보안 - 클라이언트의 요청을 모니터링하고 기록할 수 있음, 인증이 완료된 클라이언트만 서비스에 접근

단점

• 병목 - 서버와 통신하려는 클라이언트가 증가하면 서버의 부하가 올라가 네트워크 속도가 느려짐
• 비용 - 설치 및 관리 비용이 일반적으로 높음
• 비강인성 - 서버가 고장 나면 클라이언트는 더 이상 작동할 수 없다

 

2. 계층형

 

• 소프트웨어의 기능을 수직으로 상호 작용하는 여러 층으로 분할하는 형태
• 각 층 사이는 메시지를 교환

계층형 스타일 ( 출처 - 소프트웨어 공학의 모든 것 278page )

장점

• 추상화 - 시스템에 대하여 좋은 추상적인 뷰를 제공 -> 각 층의 역할과 책임, 관계를 잘 이해가능
• 캡슐화, 응집, 결합 - 자세한 데이터나 메소드, 자원, 구현 등이 각 층 안에 캡슐화 되어 층 사이에 가정하거나 이해해야 할 사항이 적음 -> 각 층의 응집이 높고 층 사이의 결합이 적다
• 재사용성 - 각 층의 의존도가 적어 쉽게 다른 모듈로 교환할 수 있고, 다른 시스템에 사용 가능함

단점

• 이웃 층과의 커뮤니케이션이 제한적이며, 결합력이 낮아 시스템을 계층으로 구성하기 쉽지 않음

 

 

3. 이벤트 기반 아키텍처

 

• 구성 - 이벤트 생산자(이벤트 스트림 생성)와 이벤트 소비자(이벤트 수신 대기)로 구성
• 이벤트 -> 실시간으로 전달되어 발생하는 즉시 소비자가 응답할 수 있어야 함
• 상태기반 처리가 대부분 -> 이벤트와 현재 상태에 따라 다른 처리를 함

이벤트 기반 아키텍처 스타일의 다이어그램 ( 출처 - 소프트웨어 공학의 모든 것 279page )

 

장점

• 캡슐화, 응집 - 이벤트의 생산자와 소비자가 분리되어 캡슐화
• 확장성 - 시스템에 새 소비자를 쉽게 추가할 수 있음
• 이벤트 도착 즉시 소비자가 이벤트에 응답할 수 있음
• 하위 시스템에서 이벤트 스트림을 독립적으로 확인할 수 있음

단점

• 복잡성 - 상태에 따라 복잡하고 정교한 제어가 필요함
• 테스팅 - 각 상태에 허용된 이벤트가 제한적인 것을 정확히 테스트하여야 하며, 허용되지 않은 이벤트에 대한 제어 필요

 

4. MVC(Model-View-Controller)

 

사용자 인터페이스로부터 비즈니스 로직과 데이터를 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향없이 쉽게 고칠 수 있는 아키텍처

 

 

구성요소

 

- 컨트롤러

• 어떻게 할지를 정의
• 요청을 받아 model & view를 연결

- 모델

• 무엇을 할지 정의
• 모델의 변화에 따른 적용 가능한 명령(추가,제거,수정)을 내릴 수 있음 [ 비즈니스 로직이 있다 ]

- 뷰

• 결과물을 화면을 통해서 보여준다.

MVC 스타일 ( 출처 - 소프트웨어 공학의 모든 것 281page )

 

장점

• 느슨한 결합, 확장성 - 각 컴포넌트의 결합이 약해 다른 부분에 영향을 주지 않고 수정 가능
• 다수의 다른 뷰 - 하나의 모델을 위하여 다수의 다른 뷰를 쉽게 제공할 수 있다
• 비동기 - 비동기 기술을 이용하여 애플리케이션을 빠르게 로딩할 수 있고, 개발자도 각 컴포넌트를 독립적으로 빠르게 개발 가능

단점

• 복잡도 - 컴포넌트의 분리로 인하여 메커니즘 이해를 위한 복잡도가 올라갈 수 있음
• 비효율성 - 뷰에서 데이터를 접근하여야 하는 비효율적인 부분이 있음
• 각 컴포넌트 구현을 위한 여러 가지 기술에 대한 이해가 필요함

 

5. 파이프 필터

 

필터 사이에 데이터를 이동시키며 단계적으로 처리하는 구조

 

데이터의 흐름(입,출력)과 필터 구성 요소(데이터의 변환 수행)로 구성되어 있음

 

예시 > 컴파일러

파이프 필터 아키텍처 ( 출처 - 소프트웨어 공학의 모든 것 281page )

 

위 그림에서 데이터는 파이프필터를 통하여 단방향으로 흐르게 된다.

 

장점

• 단순성 - 시스템을 일련의 입력, 출력, 변환으로 쉽게 볼 수 있음
• 재사용 - 다른 응용프로그램에서 필터를 쉽게 재사용 할 수 있고 교체를 할 수도 있음
• 병렬성 - 병렬 처리로 구현하기 쉬운 아키텍처를 제공함

단점

• 자원의 낭비 - 시간과 공간을 낭비할 수 있음
• 오류 조건을 쉽게 처리할 수 있는 방법이 없음 -> 오류는 별도 출력 스트림으로 처리해야 함

 

6. 데이터 중심 아키텍처

 

공유된 자료가 중요한 시스템에서 채택하는 스타일

 

공유 데이터 저장소, 공유 데이터 접근자(공유 데이터 추가, 삭제, 수정 가능)로 구성

 

( 각 접근자는 서로에 대해 모름 )

 

접근자 간의 통신은 공유 데이터에 대한 업데이트를 통하여 간접적으로 수행된다.

 

데이터 중심 아키텍처 ( 출처 - 소프트웨어 공학의 모든 것 282page )

 

데이터 중심 아키텍처의 유형

 

- 블랙보드

• 공유 데이터에는 제어 스레드가 포함됨
• 공유 데이터 저장소는 옵서버 디자인 패턴을 사용하여 공유 데이터 변경시 클라이언트에게 알림

- 리파지토리(repository)

• 클라이언트는 공유 데이터를 질의하여 변경 사항을 발견함

장점

• 낮은 결합 - 접근자 간의 통신은 공유 데이터 저장소를 통해 이루어짐 -> 다른 접근자에 영향 X -> 접근자 사이에 느슨한 결합을 유지
• 확장성 - 각 접근자의 수정, 확장이 용이함

단점

• 단일 장애지점 - 공유 데이터의 장애로 전체가 장애를 일으킬 수 있는 단일 장애 지점이 있음

 

7. Peer-to-Peer 스타일

 

각 컴포넌트는 동등하여 서비스를 요청하는 클라이언트가 될 수도 있고, 서비스를 제공하는 서버 역할을 할 수도 있음

 

시스템은 동일한 수신, 전송 데이터 양을 가지므로 대칭적인 시스템이 된다

Peer-to-Peer 스타일 ( 출처 - 소프트웨어 공학의 모든 것 284page )

 

블록체인 기술이 Peer-to-Peer 아키텍처를 기반으로 하고 있음

>> 보안을 해결하기 위해 각 노드가 상대 노드들을 감시하고 일관성을 유지함

 

장점

• 전담하는 애플리케이션이나 서버가 없음
• 규모 확장성과 신뢰성이 개선됨
• 컴포넌트에 고장이 있어도 전체 시스템은 가동 됨 ( 단일 장애지점X )

단점

• 보안에 취약할 수 있음
• 중앙에서 제어할 수 없음
• 공유된 자원으로 성능이 떨어질 수 있음

 

- 아키텍처 스타일의 비교

 

스타일	장점	단점
클라이언트 서버	- 클라이언트가 요청하는 서비스를 종합적으로 모델링하기 좋음	- 서비스 요청이 서버에서 별도의 스레드로 처리됨 - 프로세스 사이의 커뮤니케이션이 오버헤드가 될 수 있음 (클라이언트들이 다른 표현을 요구하기 때문)
계층형	- 하위층이 여러 상위층에 의하여 사용됨 - 각 층을 정확히 정의하면 각 층이 표준화 될 수 있음 - 다른 층에 영향을 주지 않고 수정을 층 안에 국한시킬 수 있음	- 광범위하게 적용하기 어려움 (이웃 층과의 커뮤니케이션이 제한적) - 특정한 층이 상황에 따라 통과될 수도 있음
이벤트 기반	- 이벤트 생산자, 소비자 연결을 쉽게 하고 추가할 수 있음 - 분산 응용에 효과적으로 적용 가능	- 상태에 따른 복잡하고 정교한 제어가 필요함 - 큰 규모에 적용하기 어려움
MVC	- 동일 모델에 여러 가지 뷰를 런타임에 쉽게 연결하고 끊을 수 있음	- 복잡도가 증가하고 이로 인하여 사용자 액션을 위하여 불필요한 수정이 증가될 수 있음
파이프필터	- 병렬처리를 가능하게 함 - 쉽게 필터를 추가할 수 있고, 시스템이 확장될 수 있음	- 느린 필터에 의하여 시스템의 성능이 제한적이다 - 필터를 이동하면서 자료의 변환 오버헤드가 발생할 수 있음
데이터 중심	- 새로운 응용을 쉽게 추가 - 데이터 공간의 확장이 용이함	- 모든 부분이 영향을 받아 중심 데이터의 구조를 변경하는 것이 쉽지 않다
Peer-to-Peer	- 중앙집중을 피할 수 있음 - 노드 하나의 고장으로 시스템이 멈추지 않음 - 자원과 컴퓨팅 파워의 확장성이 뛰어남	- 서비스의 품질을 보장하기 어려움 - 보안을 보장하기 어려움 - 성능이 노드의 수에 좌우됨