[Spring]아키텍처

아키텍처(Architecture)는 건축학에서 따온 용어로서 '건축 양식'이라는 뜻을 가지고 있다.

 

건물을 짓기 전에 컨셉과 구조를 정하듯이, 프로그램에서도 전체 시스템 구조, 기능 등을 정의하는 것을 말한다고 할 수 있다.

 

조금 프로그래밍 적으로 말하자면, 사용할 프레임워크(앱의 구조 결정)와 그 사용 전략을 결합하여 결정하는 것이라 할 수 있다.

 

• Architecture = Structure + Framework

아키텍처에 따라 프레임워크가 달라질 수 있으며, 그 반대도 가능하다.

 

아키텍처는 모든 사람이 볼 수 있게 가능하면 간략히, 그러나 모든 정보를 담을 수 있게 만드는 것이 중요하다.

 

계속해서 아키텍처의 종류인 시스템 아키텍처, 소프트웨어 아키텍처에 대해 알아보자.

 

1. 시스템 아키텍처(System Architecture)

 

위키백과에 의하면 시스템 아키텍처는 아래와 같은 기본 요구사항이 존재한다.

 

• 시스템 구성 및 동작 원리를 나타내고 있다.
• 시스템 구성 요소(부품)에 대해 설계 및 구현을 지원하는 수준으로 자세히 기술된다. (IEEE 1471 또는 TOGAF 등)
• 구성 요소 간의 관계 및 시스템 외부 환경과의 관계가 묘사된다.
• 요구 사양 및 시스템의 전체 수명주기를 고려한다.
• 시스템 전체(하드웨어와 소프트웨어)에 대한 논리적인 기능 체계와 그것을 실현하기 위한 구성 방식, 전체적인 최적화를 목표로 한다.

https://ko.wikipedia.org/wiki/%EC%8B%9C%EC%8A%A4%ED%85%9C_%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98

시스템 아키텍처 - 위키백과, 우리 모두의 백과사전

요구조건에 쓰여 있듯이, 시스템 아키텍처는 하드웨어와 소프트웨어를 포괄하는, 시스템의 동작 구조를 나타낸다.

 

위와 같은 요구조건에 의한 시스템 아키텍처의 목표는 아래와 같다.

 

• 시스템 구조 파악 및 다양한 시스템 구성요소의 상호 작용(역할 및 프로토콜, 인터페이스) 정의
• 다른 기종 시스템 간의 상호 운영성 확보
• 신규나 기존(Legacy)시스템의 응용 및 데이터의 연결성 확보
• 아키텍처 설계, 분석 단계의 방향성 유지 및 성능 발휘를 위한 구성
• 요소 기술별 개선점 도출 및 보완

예를 들어 채팅 서버를 구성하기 위한 시스템 아키텍처를 만든다고 해보자.

 

처음은 이렇게 만들 수 있을 것이다.

 

단순하고 직관적이지만, 시스템의 확장에 대한 부분(유저 증가 등)이 고려되지 않았다.

 

또한 웹소켓 서버가 단일로 이루어져 있어 해당 서버가 다운되면 전체 시스템이 죽는다는 리스크도 있다.

 

이를 아래와 같이 개선할 수 있을 것이다.

 

사용자의 요청을 분산시켜주는 로드밸런서와 복수의 웹소켓 서버를 두어 확장성과 안정성을 확보했다.

 

이를 전송속도 향상을 목적으로 한번 더 개선하면 아래와 같은 모양이 된다.

 

DB영역의 리액티브 시스템과, 다중 처리가 가능한 R소켓의 도입으로 속도와 안정성을 모두 개선했다.

 

2. 소프트웨어 아키텍처(Sofrware Architecture) / 애플리케이션 아키텍처(Application Architecture)

 

소프트웨어 아키텍처는 말 그대로 하드웨어를 제외한 소프트웨어의 구성을 그림으로 표현한 것이다.

 

대표적인 것으로 Java Platform Architecture가 있으며, 그 구성은 아래와 같다.

 

출처: https://docs.oracle.com/javase/1.5.0/docs/index.html

JDK 5 Documentation

아키텍처를 통해 Java가 지원하는 기술과 기능 등을 대략적으로 파악할 수 있다.

 

구체적인 소프트웨어 아키텍처의 역할은 아래와 같다.

 

• 시스템의 컴포넌트(독립적인 소프트웨어 모듈) 식별 및 속성 정의
• 컴포넌트들 사이의 커뮤니케이션 방법 및 물리적 배치 등을 포함하는 시스템 구조 표현
• 추상적인 표현을 사용하여 복잡도 관리

 

많은 종류의 소프트웨어/애플리케이션 아키텍처 중에 앞으로 중점적으로 볼 것은

 

웹 애플리케이션 아키텍처(Web Application Architecture)인데, 

 

이전 웹(Web)글에서 이에 대해 한 번 다룬 적이 있다.

 

https://gnidinger.tistory.com/438?category=992843

[네트워크]웹(WEB)

다시 불러오자면, 웹 애플리케이션의 아키텍처는 아래와 같다.

 

웹 애플리케이션의 3 티어 아키텍처

 

개발자는 개발하는 서비스나 단계에 따라 각 티어를 독립적으로 변경할 수 있다.

 

각 티어에 대한 설명은 아래와 같다.

 

• Presentation Layer - API Layer라고 불리며 클라이언트의 요청을 받아들이는 계층이다. GUI, 웹 화면 등을 포함한다.
• Application Layer - Service Layer, Business Layer, 혹은 WAS(Web Application Server)라고도 불린다. Presentation Layer에서 수집된 유저의 요청(기능의 사용)이 업무 도메인(범위, 과정)의 요구사항에 맞게 처리되며, 이 과정에서 비즈니스 로직이 사용된다.  또한 Data Access Layer의 데이터를 추가, 삭제, 수정할 수 있다.
• Data Access Layer - DB Server라고도 불리며 앱의 데이터베이스에 접근하여 데이터를 불러오거나 저장을 담당한다. Application Layer에서 유저의 요청을 처리할 때 이에 대한 작업을 지원한다. 이 단계를 통해 Application Layer의 로직은 데이터베이스에 접근해서 데이터를 회수하고 혹은 저장하는 방식을 최적화할 수 있다.

티어에 속하지 않으나 그림에는 표시된 요소는 아래와 같다.

 

• Cross-Cutting - 보안, 통신, 운영 관리 등을 위한 요소이다. 추후 학습 예정.
• Third-Party Integrations: 제3의 API 서비스를 이용하는 것. OAuth 2.0을 이용한 소셜 로그인, PG 사를 이용한 결제 기능 등.

끝으로, 지난 글에서도 사용했던 스프링의 모듈 구조에 대해 보자.

 

출처: https://docs.spring.io/spring-framework/docs/4.0.x/spring-framework-reference/html/overview.html

2. Introduction to Spring Framework

여기서 모듈(Module)이란 간단하게 목적에 맞게 기능을 그룹화 한 것이며,

 

재사용이 가능하도록 라이브러리 형태로 묶어서 제공되는 것이라 생각하면 된다.