해당 글에서는 시스템을 구축할 때 설계를 하는 소프트웨어 아키텍처의 10가지 패턴에 대해 알아보고 활용되는 예시에 대해 확인해 봅니다.
1) 소프트웨어 아키텍처 패턴(Software Architect Pattern)
💡 소프트웨어 아키텍처 패턴
- 소프트웨어 설계에서 공통적으로 발생하는 문제를 효과적으로 해결하기 위한 템플릿 또는 가이드라인을 의미합니다.
- 시스템의 전체 구조와 그 구조의 주요 요소들과 그 요소들 간의 관계에서 발생하는 패턴들을 주로 정의합니다. - 이를 통해서 재사용 가능한 설계를 제공하며 개발자들은 시스템을 더 효과적으로 설계하고 이해하는데 도움을 줍니다.
소프트웨어 아키텍처 종류
설명
사용예시
계층 패턴
시스템을 기능별로 분리하여 개발, 테스트, 유지 보수를 용이하게 하는 패턴
웹 애플리케이션의 웹 서버 구성
클라이언트-서버 패턴
클라이언트가 서버에게 서비스를 요청하고, 서버가 그 요청을 처리하여 결과를 반환하는 패턴
웹 서버와 브라우저의 상호작용
마스터-슬레이브 패턴
작업을 제어하는 마스터와 그 작업을 수행하는 슬레이브로 구성되는 패턴
Redis 복제(Replication) 방식
파이프-필터 패턴
데이터 스트림을 필터(처리 단위)로 전달하며 처리하는 패턴
UNIX 쉘의 파이프라인 명령, 컴파일러
브로커 패턴
분산 컴포넌트 간의 통신을 중개하는 브로커 역할을 하는 패턴
RabbitMQ, Apache ActiveMQ, Apache Kafka
피어 투 피어 패턴
모든 노드가 동등한 위치에서 직접 데이터를 교환하는 패턴
WebRTC, 파일 공유 네트워크, 멀티미디어 프로토콜
이벤트-버스 패턴
시스템의 서로 다른 컴포넌트들이 이벤트를 통해 통신하는 패턴
알림 서비스(FCM Message), 안드로이드 개발
MVC 패턴
사용자 인터페이스를 구성할 때 모델, 뷰, 컨트롤러의 3가지 구성 요소를 기반으로하는 패턴
웹 애플리케이션 개발
블랙보드 패턴
여러 서브시스템이 공유 정보를 통해 문제를 해결하는 패턴
차량 식별 및 추적 시스템
인터프리터 패턴
문법 규칙을 클래스 구조로 표현하여 문장을 해석하는 패턴
정규 표현식
[ 더 알아보기 ]
💡 아키텍처 패턴도 있지만 디자인 패턴도 있던데 그건 뭘까?
- 아키텍처 패턴은 시스템의 전체 구조와 그 구조의 주요 요소들과 그 요소들 간의 관계에 대한 패턴을 의미합니다. - 반면에 디자인 패턴은 소프트웨어 설계의 특정 부분인 클래스와 객체 등 ‘코드 레벨’에서 발생하는 문제를 해결하는데 초점을 두었습니다. 그렇기에 세부적인 설계 문제에 대한 해결책을 제시합니다.
💡 [참고] 디자인 패턴의 종류
2) 계층 패턴 (Layered Pattern)
💡 계층 패턴 (Layered Pattern)
- 소프트웨어 시스템을 기능별로 서로 다른 ‘계층(Layer)’로 분리하여 관리하며 이를 통해 계층화된(Layered) 상태에서 서로 간의 상호작용을 하는 패턴을 의미합니다.
- 각 계층은 '특정 책임’을 갖고 있으며 계층 간에는 명확한 종속성이 정의되어 있습니다. 이를 통해서 ‘관심사의 분리’하여 코드의 복잡성을 줄이고 재사용성을 높이는 것을 목표로 둡니다.
1. N-Tier Architecture
💡 N-Tier Architecture
- 애플리케이션 내에서 두 개 이상의 독립적인 계층으로 분리(계층화)되어 수행되도록 설계한 패턴을 의미합니다.
- ‘N’의 의미는 표현 계층, 비즈니스 계층, 데이터 액세스 계층 외에 보안 계층, 메시지 큐 계층 등 더 많은 계층을 추가할 수 있습니다. - 이러한 각 계층은 독립적인 역할을 수행하며, 이는 각 층이 서로 다른 플랫폼이나 기술에 의해 구현될 수 있다는 것을 의미합니다. - 또한 이러한 구조는 코드의 재사용성을 증가시키고, 모듈성을 높여 개발과 유지보수를 쉽게 만듭니다. 또한, 각 층의 분리는 보안, 성능, 확장성에 대한 더 세밀한 제어를 가능하게 합니다.
계층 (Layer)
설명
표현 계층 (Presentation Layer)
사용자 인터페이스와 관련된 처리를 담당하는 계층입니다. 사용자가 보거나 조작할 수 있는 화면을 준비하고 출력합니다.
응용 계층 (Application Layer)
사용자의 요청에 따라 적절한 비즈니스의 계층의 메서드를 호출하는 계층입니다. 비즈니스 로직과 관련되지 않은 개발 처리를 수행합니다.
비즈니스 계층 (Business Layer)
응용 계층으로 부터 전달받은 데이터를 기반으로 비즈니스 로직을 처리하는 계층입니다.
데이터 액세스 계층 (Data Access Layer)
데이터베이스에 접근하여 데이터를 저장하거나 검색 처리를 수행하여 응답받은 데이터와 관련된 재 가공 및 조작 처리를 수행하는 계층입니다.
💡 N 계층별 데이터 처리 흐름
1. 2계층 아키텍처 : 표현 계층, 데이터 액세스 계층
- ‘표현 계층’에서 사용자 인터페이스와 관련된 처리를 담당하여 사용자의 동작에 대한 처리에 대한 요청을 하면 ‘데이터 액세스 계층’으로 전달하면 이를 통해 데이터베이스에 접근하여 데이터를 저장하거나 검색하는 처리를 수행하여 이를 응답해 줍니다.
2. 3계층 아키텍처 : 표현 계층, 비즈니스 계층, 데이터 액세스 계층
- ‘표현 계층’에서 사용자 인터페이스와 관련된 처리를 담당하여 사용자의 동작에 대한 처리에 대한 요청을 하면 ‘비즈니스 계층’에서 이에 대한 비즈니스 로직에 대한 처리를 수행하고 ‘데이터 액세스 계층’에서 데이터베이스에 접근하여 데이터를 저장하거나 검색하는 처리를 수행하여 이를 응답해 줍니다
3. 4계층 아키텍처 : 표현 계층, 응용 계층, 비즈니스 계층, 데이터 액세스 계층
- ‘표현 계층’에서 사용자 인터페이스와 관련된 처리를 담당하여 사용자의 동작에 대한 처리에 대한 요청을 하면 ‘응용 계층’에서 이에 대한 요청에 대한 적절한 비즈니스 계층으로 메서드를 호출하고 ‘비즈니스 계층’에서 이에 대한 비즈니스 로직에 대한 처리를 수행하고 ‘데이터 액세스 계층’에서 데이터베이스에 접근하여 데이터를 저장하거나 검색하는 처리를 수행하여 이를 응답해 줍니다
2. 계층 패턴 사용 사례: Spring Boot의 4-Tier Architecture
💡 계층 패턴 사용 사례: Spring Boot 4-Tier Architecture
- Spring Boot에서 각각의 관심사에 맞게 계층을 분리한 4-Tier입니다. 이를 통해 각각 계층에서 기능에 맞는 처리를 수행합니다.
💡Spring Boot 서버 데이터 처리 수행과정
1. 표현 계층 (Presentation Layer)
- Spring Boot에서 Thymeleaf, JSP와 같은 템플릿으로 화면을 표현해 주거나 Node.js 서버로 구축한 React, Vue 활용하여 사용자에게 화면을 보여줍니다.
2. 응용 계층 (Application Layer) - Spring Boot에서는 Controller로 클라이언트의 요청에 따른 엔드포인트를 제공하며 비즈니스 계층의 메서드를 호출하는 계층으로 사용됩니다.
3. 비즈니스 계층 (Business Layer) - Spring Boot에서는 Service(인터페이스), ServiceImpl(인터페이스 구현체)를 의미하며 응용 계층에서 호출되어 비즈니스 로직을 처리하는 계층으로 사용됩니다.
4. 데이터 액세스 계층 (Data Access Layer) - Spring Boot에서는 Mapper와 Database를 의미합니다. 비즈니스 계층에 따른 호출에 따라서 데이터베이스에 접근하여 데이터를 저장하거나 불러옵니다.
💡 클라이언트-서버 패턴 (Client-Server Pattern) - 네트워크에서 정보를 교환하는 두 주체, 즉 '클라이언트'와 '서버'를 중심으로 구성됩니다. 이 패턴은 네트워크에서 가장 많이 사용되는 패턴 중 하나입니다.
- 클라이언트-서버 패턴에서는 일반적으로 2계층으로 구조가 나뉩니다. 하지만 더 복잡한 시스템에서는 중간에 다양한 서비스를 제공하는 여러 서버 계층이 추가되어 다 계층 클라이언트-서버 아키텍처를 형성하기도 합니다.
패턴 분류
설명
클라이언트(Client)
사용자(User)의 요청을 서버로 전송하는 역할을 수행합니다. 클라이언트는 웹 브라우저나 애플리케이션이 이러한 역할을 수행합니다.
서버(Server)
클라이언트의 요청을 처리하고 처리된 결과를 응답으로 반환하는 역할을 의미합니다. 서버는 웹 서버, 데이터베이스 서버 등이 이러한 역할을 수행합니다.
1. 클라이언트-서버 사용 사례 : 웹 서버와 클라이언트(브라우저, 모바일) 상호작용
💡 클라이언트-서버 사용 사례 : 웹 서버와 클라이언트(브라우저, 모바일) 상호작용
- 사용자는 클라이언트에 해당되는 웹 브라우저, 애플리케이션을 통해서 동작을 수행 서버(Server)로 데이터 처리에 대한 요청(request)을 수행하면 서버에서는 이를 처리하고 응답(response)을 해주는 구조입니다.
[더 알아보기] 💡 TCP/IP (Transmission Control Protocol :TCP) / Internet Protocol :IP) 통신
- TCP는 데이터의 전송을 담당하며, 패킷의 순서를 제어하고 오류를 검출하고 수정합니다. 이는 데이터가 정확하게 전송되도록 보장합니다. - IP는 데이터 패킷을 올바른 위치로 전달하는 역할을 합니다. 이는 각 패킷이 올바르게 주소 지정되고 경로를 통해 전달되도록 합니다. 따라서 TCP/IP는 인터넷에서 데이터를 안전하고 효율적으로 전송하는 데 필요한 규칙과 절차를 제공합니다.
4) 마스터-슬레이브 패턴 (Master-Slave Pattern)
💡 마스터-슬레이브 패턴 (Master-Slave Pattern)
- 하나의 ‘마스터 노드(Master Node)’와 하나 이상의 ‘슬레이브 노드(Slave Node)’로 구성되어 있는 패턴을 의미합니다. 이 패턴은 주로 병렬 처리를 필요로 하는 작업에 사용되며 효율적으로 대용량의 데이터를 처리하는데 이용이 됩니다.
- ‘마스터 노드(Master Node)’는 처리하는 작업을 슬레이브 노드로 분배하고 ‘슬레이브 노드(Slave Node)’는 분배된 작업을 받아서 처리를 합니다. 이렇게 분배된 작업을 각 슬레이브 노드가 독립적으로 처리하므로 작업의 처리시간을 크게 단축시킬 수 있습니다. - 마스터-슬레이브 패턴의 주요 장점은 확장성입니다. 슬레이브 노드를 추가함으로써 시스템의 처리 능력을 쉽게 증가시킬 수 있습니다. 또한, 노드 간에 작업을 분배하므로 시스템의 부하를 분산시킬 수 있습니다. - 그러나 이 패턴에는 단점도 있습니다. 예를 들어, 마스터 노드가 고장 나면 전체 시스템이 중단될 수 있습니다. 따라서 이런 문제를 방지하기 위해, 일반적으로 마스터 노드의 고가용성을 보장하는 방법이 필요합니다.
1. 마스터-슬레이브 패턴의 사용사례 : Redis의 복제(Replication) 방식
💡 Redis 복제(Replication) 방식
- 마스터-슬레이브 패턴을 사용하는 Redis의 복제(Replication)는 ‘마스터 노드(Master Node)’를 기준으로 복제(Replication)를 통해서 ‘슬레이브 노드(Slave Node)’를 구성합니다.
- 해당 복제를 하는 이유는 ‘데이터의 안정성과 가용성’을 보장하기 위한 목적입니다. Redis에서 마스터 노드가 실패를 하는 경우 복제된 슬레이브 노드에서 주 서버의 역할을 수행할 수 있습니다. 또한 데이터 분산을 통해 ‘읽기 요청에 대한 부하를 분산’시키는데도 사용됩니다.
- Master node와 Slave node의 동기화 시점은 ‘복제(Replication)’가 수행된 이후 마스터 노드에서 새로운 명령(데이터 변경을 일으키는 명령)을 수행하면 슬레이브 노드에서 데이터를 최신 상태로 유지합니다.
1. 데이터 쓰기 작업 : App에서는 Master Node에 데이터를 Write 합니다. 2. 데이터 읽기 작업 : App에서는 Slave Node에서 데이터를 Read 합니다.
- 데이터를 받아서 각 단계(필터)를 처리하고 각 단계는 출력(파이프)이라는 연결 고리로 이루어지는 일련의 컴포넌트나 단계를 거치는 패턴을 의미합니다.
- 각 단계는 필터라고 불리며, 필터는 데이터에 특정 연산을 수행하고 그 결과를 다음 필터로 전달합니다. 이러한 방식은 데이터의 연속적인 변환을 가능하게 하며, 복잡한 데이터 처리 작업을 단순하고 재사용 가능한 컴포넌트로 분리할 수 있게 합니다. - 파이프-필터 패턴의 장점은 각 필터가 독립적으로 작동하며, 서로 다른 필터들 사이에 데이터를 쉽게 전달할 수 있다는 점입니다. 이 패턴은 유닉스 셸 스크립팅, 데이터 파이프라인, 스트림 처리 등 다양한 상황에서 활용될 수 있습니다.
구분
설명
데이터 소스(DataSource)
원본 데이터가 저장, 생성되는 장소
파이프(Pipe)
데이터를 한 장소에서 다른 장소로 전송하는 구조
필터(Filter)
특정 조건을 충족하는 데이터만을 선택하거나 변형하는 기능
데이터 싱크(DataSink)
데이터가 파이프를 거쳐 필터를 수행하여 최종적으로 전달, 저장되는 장소
💡 파이프 필터 패턴 수행과정
- 원본 데이터인 Data Source는 Pipe를 통해서 데이터가 전달이 됩니다. 이 데이터는 한 번에 전달되는 것이 아닌 Filter 과정을 거치며 특정 조건에 충족하는 데이터만 정제되어 전달이 됩니다. - 이를 통해 최종적으로 Data Sink로 최종 전달이 됩니다.
1. 파이프-필터 패턴 사용사례: 쉘 스크립트
💡 파이프-필터 패턴 사용사례: 쉘 스크립트
- 'ls -l | wc -l'은 두 개의 명령어를 파이프라인으로 연결한 것입니다.
- 'ls -l' 명령어는 현재 디렉터리의 파일과 디렉터리 목록을 자세하게 출력하고 그 출력을 'wc -l' 명령어로 전달합니다. - 'wc -l'은 텍스트 스트림의 라인 수를 세는 명령어이므로 이 명령어 조합은 현재 디렉터리의 파일과 디렉터리 개수를 세는 데 사용됩니다.
[ 더 알아보기 ] 💡 쉘 스크립트(Shell Script)
- 유닉스 또는 리눅스 기반 시스템에서 작업을 자동화하기 위해 사용되는 스크립트 언어입니다. 이를 통해 사용자는 여러 명령어를 한 번에 실행할 수 있습니다. 쉘 스크립트는 일반적으로 텍스트 파일에 저장되며, 이 파일은 쉘에 의해 실행할 수 있습니다. - 쉘 스크립트는 반복적인 작업을 자동화하는 데 유용하며, 시스템 관리 작업, 프로그램 설치, 백업 등에 주로 사용됩니다. 또한, 쉘 스크립트는 조건문, 반복문 등의 프로그래밍 요소를 포함할 수 있어, 복잡한 작업을 수행하는 데도 사용될 수 있습니다.
6) 브로커 패턴(Broker Pattern)
💡 브로커 패턴 (Broker Pattern)
- 분산 시스템의 환경에서 컴포넌트 간의 통신을 담당하는 패턴 중 하나로 클라이언트-서버 패턴의 확장이며 클라이언트와 서버 사이의 통신을 중재하고 조정하는 ‘중개인 역할’을 수행하는 브로커 컴포넌트가 도입된 패턴을 의미합니다.
- 브로커 패턴은 발행자/구독자(publisher/subscriber) 패턴이라고도 합니다. - 발행(publishe) 과정에서 메시지라는 형태로 메시지(특정 정보 또는 이벤트)를 전송하고 구독(subscribe) 과정에서 메시지(특정 정보 또는 이벤트)를 받기 위해 등록하는 행위를 수행합니다. - 이렇게 되면 발행자와 구독자는 서로 독립적으로 동작할 수 있게 되며 브로커(broker)는 이들 사이에서 메시지를 전송하는 역할을 수행하며 서로 다른 시스템 간의 통신을 단순하게 하는데 도움이 됩니다
💡 브로커 패턴 처리 과정 - 브로커는 클라이언트와 서버 중간에 ‘중재하고 조정’하는 역할을 수행합니다. 클라이언트의 요청이 오면 브로커는 이를 받고 각각 서버의 특성에 맞게 중재하여 이를 처리합니다.
1. 클라이언트는 브로커에게 데이터나 이벤트를 전달합니다. : Publisher
2. 클라이언트는 브로커에게 특정 데이터나 이벤트를 수신하겠다는 의사를 표시합니다 : Subscriber
3. 전달된 데이터나 이벤트는 브로커에 의해 관리되고 각각의 서버 특성에 맞는 서버로 연결을 합니다.
4. 서버의 처리가 완료되면 브로커를 처리된 정보가 전달됩니다.
5. 브로커는 서버에서 처리된 결과 값을 클라이언트로 반환해 줍니다.
1. 브로커 패턴의 사용사례: RabbitMQ의 브로커 패턴(Broker Pattern)
💡 RabbitMQ 분산 처리 과정 1. PRODUCER → BROKER(RabbitMQ) : 메시지 생성 및 송신 - Publish 과정 수행 - 생산자(Producer)는 RabbitMQ에게 메시지를 보냅니다
2. BROKER(RabbitMQ) → EXCHANGS : 메시지 라우팅 - RabbitMQ에서는 메시지를 받아들이고 EXCHANGS를 통해서 라우팅 알고리즘을 사용하여 메시지를 적절한 큐에 전달합니다.
3. Binding : Exchange와 Queue의 연결 - Exchange와 Queue사이의 관계를 설정하여 연결을 할 때 어떻게 올바른 대상으로 전달이 될지(라우팅)에 대한 규칙을 정합니다.
4. Queue : 메시지 저장 - 바인딩된 Queue에서는 메시지를 저장하며 생산자와 소비자 간의 안정적인 비동기 통신을 처리하도록 돕습니다.
5. BROKER(RabbitMQ) → CONSUMER : 메시지 전송 - Subscribe 과정 수행 - RabbitMQ는 큐에 있는 메시지를 소비자에게 전달합니다.
6. CONSUMER → BROKER(RabbitMQ) : 완료 신호 전달 - 소비자는 메시지를 처리하고 완료되면 RabbitMQ에게 완료 신호를 보냅니다.
7. BROKER(RabbitMQ) → PRODUCER : 완료 응답 - 전송 완료에 대한 신호를 생산자에게 전달합니다.
8. BROKER(RabbitMQ) : 메시지 제거 - RabbitMQ는 완료된 메시지를 큐에서 제거합니다
