소프트웨어 엔지니어가 알아야 할 12가지 소프트웨어 아키텍처 스타일

해당 포스트는 Meduim 의 아티클 "12 Software Architecture Styles Software Enginners Should Know" 을 번역한 내용이다.

[ 원문 ]

 

소프트웨어 아키텍처란?

소프트웨어 아키텍처는 소프트웨어 시스템의 상위 수준 구조와 구성을 정의하는 프로세스입니다. 여기에는 올바른 구성 요소를 식별 및 선택하고, 상호작용하는 방법을 결정하고, 특정 목표를 달성하기 위해 구성하는 방법을 결정하는 작업을 포함합니다. 소프트웨어 아키텍처의 목표는 유지보수성, 확장성, 보안 안정성 및 시간이 지남에 따른 사용자와 조직의 요구사항을 충족할 수 있는 시스템을 만드는 것 입니다.

 

소프트웨어 아키텍처가 필요한 이유는 무엇인가?

견고한 아키텍처는 사용자와 이해관계자의 요구사항을 충족하는 소프트웨어를 구축하기 위한 기반을 제공합니다. 

이는 기능적인 요구사항 뿐만 아니라 성능, 보안, 신뢰성과 같은 비기능 요구사항도 충족시켜 줍니다. 잘 설계된 아키텍처를 통해 가발자는 수정 및 확장의 용이한 소프트웨어를 구축하여 변화하는 비즈니스 요구사항에 쉽게 대응할 수 있습니다.

소프트웨어 아키텍처는 복잡성 관리에도 필요합니다. 소프트웨어 시스템이 더욱 복잡해짐에 따라 다양한 구성요소가 어떻게 상호작용하는지 이해하기 어려워집니다. 잘 설계된 아키텍처는 고 수준의 뷰를 제공하여 시스템의 구조와 작동에 대해 이해하기 쉽게 만들어줍니다. 이것은 개발자가 잠재적인 문제를 식별하고 시스템을 어떻게 수정해야 하는지에 대한 정보를 얻는데 도움을 줍니다.

아키텍처를 문서화하는 방법은 4C 모델을 사용한다.

Context level

가장 높은 레벨인 Context level 에서는 사용자, 타 시스템, 규정 등 시스템의 외부환경을 묘사합니다. 이 수준의 시스템은 시스템의 목적과 외부환경과의 관계에 대한 고 수준의 뷰를 제공합니다. 이는 시스템과 사용작용할 이해관계자와 설계 및 개발에 영향을 미치는 요소를 식벼하는데 도움을 줍니다.

Containers level

다음 레벨은 Container level 로, 서버, 데이터베이스, 메시지 큐와 같은 시스템의 runtime 환경을 묘사합니다. 이 수준에서는 주요 기술의 선택과 배포를 식별하는데 도움을 줍니다. 이는 시스템을 지원할 물리적 인프라와 시스템을 배포하고 유지보수하는데 필요한 도구와 자원에 대한 이해를 제공합니다.

Components level

세번째 레벨은 Components level 로, 시스템의 주요 기능적 구성요소를 설명합니다. 이 수준에서는 시스템을 구성하는 모듈, 클래스나 함수를 식별하는데 도움을 줍니다. 이것은 시스템의 기능과 다양한 구성요소 간의 관계를 이해를 제공합니다.

Code level

마지막으로, Code level은 가장 낮은 레벨로, 실제 코드 및 이 코드가 구성요소를 어떻게 구현하는지를 설명합니다. 이 수준은 시스템이 어떻게 작동하며 다양한 구성요소가 어떻게 상호작용하는지에 대한 상세한 이해를 제공합니다. 코드와 작업할 개발자들이 코드의 구조와 작동 방식을 명확하게 이해하는데 필수적입니다.

---

C4 모델을 사용하면 소프트웨어 아키텍트는 각 수준을 설명하는 다이어그램과 문서를 작성하여 시스템 아키텍처의 전체적인 뷰를 제공할 수 있습니다. 이 접근방식은 잠재적인 문제를 식별하고 확장성, 유지 관리성 및 연동성을 확보하는데 도움이 됩니다. 이런식으로 아키텍처를 문서화함으로써 개발자와 이해관계자는 시스템에 대한 명확하고 쉽게 이해할 수 있고, 비즈니스 요구사항이 변경될 때 쉽게 대응할 수 있습니다.

---

소프트웨어 엔지니어가 알아야 할 12가시 소프트웨어 아키텍처 스타을은 다음과 같습니다.

---

1. Client Server

클라이언트-서버 아키텍처는 클라이언트(사용자 또는 어플리케이션)가 서버에 요청을 보내고, 서버는 요청된 데이터나 서비스로 응답하는 모델입니다. 클라이언트와 서버는 동일한 머신에 존재할 수 도 있고, 네트워크를 통해 연결된 다른 머신에 있을수도 있습니다.

클라이언트는 통신을 시작하고 요청을 서버에 보냅니다. 반면, 서버는 클라이언트로부터 들어온 요청을 수신하고 처리한 다음 응답을 반환합니다.

클라이언트-서버 아키텍처의 장점
확장성: 클라이언트-서버 아키텍처는 여러 클라이언트가 동일한 서버에 연결하고 리소스를 공유할 수 있기 때문에 매우 확장 가능합니다.
보안: 서버는 리소스 및 데이터에 대한 접근을 제어할 수 있기 때문에, 다른 네트워크 모델보다 더 나은 보안을 제공합니다.
신뢰성: 서버는 시스템 장애상황에 대비하여 백업 및 복구 서비스를 제공할 수 있기 때문에 높은 신뢰성을 제공합니다.

2. Layering

레이어링은 복잡한 소프트웨어 시스템을 설계하는 일반적인 방법으로, 시스템을 계층으로 나누어 각 계층이 특정 기능을 책임지도록 하는것입니다. 이러한 접근 방식은 코드를 구성하고, 유지보수를 쉽게해 줍니다.

전형적인 레이어링 아키텍처는 일반적으로 세가지 주요 계층으로 구성됩니다. : 프레젠테이션, 비즈니스 로직, 데이터 액세스 계층으로 표현합니다.
프레젠테이션 레이어: 정보를 사용자에게 표시하고 입력을 수집하는 역할을 담당합니다. 이 계층은 사용자 인터페이스와 사용자와 직접 상호작용하는 다른 컴포넌트를 포함합니다. 사용자 인터페이스는 사용자가 볼수 있고 상호작용하는 요소로, 버튼, 텍스트 상자 및 메뉴와 같은 것들을 포함합니다. 또한, 이벤트 핸들러 및 유효성 검사와 같은 사용자 인터페이스와 관련된 로직도 포함됩니다.
비즈니스 로직 레이어: 이 계층은 비즈니스 규칙을 구현하는 역할을 담당합니다. 이는 데이터를 처리하고 조작하는 코드뿐만 아니라 다른 응용 프로그램 로직도 포함됩니다. 비즈니스 로직 레이어는 말그대로 마법이 일어나는 곳입니다. 소프트웨어가 계산하고, 결정하고 작업을 수행하는 곳입니다. 이 계층은 소프트웨어가 실제로 작업을 수행하는 곳입니다.
데이터 액세스 레이어: 이 레이어는 데이터베이스 혹은 다른 외부 데이터소스와 상호 작용하는 역할을 담당합니다. 이 계층에는 데이터베이스에서 데이터를 읽고 쓰는 코드가 포함됩니다. 데이터 액세스 레이어는 소프트웨어가 데이터베이스에서 데이터를 검색하고 데이터를 변경하며 변경 사항을 데이터베이스에 저장하는 곳입니다. 이 계층은, 소프트웨어가 데이터를 저장하고 검색할 수 있게 해 주기 때문에 매우 중요합니다.

3. Pipe and Filter

파이프와 필터 아키텍처는 소프트웨어 시스템이 처리 작업을 여러 독립적인 구성요소로 분리하여 데이터를 처리할 수 있는 디자인 패턴입니다. 이 아키텍처는 대량의 데이터를 처리해야 하는 시스템에 특히 유용하면, 성능, 확장성, 유지보수성을 향상시키는데 도움이 될 수 있습니다. 

파이프와 필터 아키텍처는 데이터가 일련의 처리단계를 통해 흐르는 파이프라인 개념에 기반합니다. 각 처리 단계는 특정 작업을 수행하는 독립적인 구성요소 또는 필터로 구현됩니다. 각 처리 단계는 입력 데이터를 받아 데이터에 대한 작업을 수행하고 출력 데이터를 생성합니다. 그 후 출력 데이터는 파이프라인의 다음 필터로 전달됩니다.

파이프라인 내의 필터는 서로 독립적이므로 각각 개발, 테스트 및 배포할 수 있습니다. 이로써 파이프라인에 새로운 필터를 추가하거나 기존 필터를 수정하는 작업이 나머지 시스템에 영향을 미치지 않게 만들어줍니다.

장점

확장성:  파이프라인에 더 많은 필터를 추가함으로써 수평 확장이 가능하며, 시스템이 더 많은 데이터를 처리할 수 있게 합니다.
성능: 데이터 처리를 여러 필터간에 병렬화함으로써 성능을 최적화 할 수 있습니다.
유지보수성: 모듈화와 관심사항의 분리를 장려하여 시스템 유지보수를 용이하게 합니다.

4. Master-Slave

마스터-슬레이브 아키텍처는 분산 시스템에서 사용되는 디자인 패턴으로, 하나의 노트(마스터)가 하나 이상의 노드(슬레이브)를 제어하여 특정 작업을 수행합니다. 마스터 노드는 작업 부하를 슬레이브 노드에 분배하고 그들의 활동을 조정하는 역할을 맡습니다. 슬레이브 노드는 마스터 노드와 동일한 수준의 제어권을 갖지 않으며, 마스터에 의해 할당된 작업만 수행합니다.

장점

가장 중요한 장점 중 하나는 작업 부하를 여러 노드에 효율적으로 분배할 수 있다는 것입니다. 이것은 한 노드에 가해지는 부하를 줄이고 시스템이 대규모 데이터와 트래픽을 처리할 수 있도록 도와줍니다.
또 다른 장점은 장애 허용성을 제공한다는 것입니다. 슬레이브 노드 중 하나가 실패하면 마스터 노드는 그 작업 부하를 다른 슬레이브 노드로 재분배할 수 있습니다. 이것은 하나 이상의 노드가 실패해도 시스템이 계속 동작할수 있도록 보장합니다.

5. MicroKernel

마이크로 커널 아키텍처는 개발자가 더 모듈화되고 유연한 시스템을 구축할 수 있도록 하는 소프트웨어 디자인 패턴입니다. 이 패턴은 핵심 시스템 기능을 추가 기능과 분리하여 별도의 모듀에서 구현합니다. 시스템의 핵심 기능은 마이크로 커널에서 구현되면, 이것은 시스템을 실행하는데 필요한 가장 기본적인 서비스만 제공하는 최소한의 핵심 시스템입니다. 이것은 프러그 앤 플레이(Plug and Play) 개념입니다

예:
예를 들어 전자 상거래 웹사이트의 경우, 마이크로 커널은 사용자 인증, 세션관리, 결제 처리와 같은 필수 서비스를 제공할 것입니다. 제품 추천, 사용자 리뷰, 소셜 미디어 통합과 같은 추가 기능은 별도의 모듈에서 구현될 것입니다.
웹사이트에 로열티 프로그램과 같은 새로운 기능을 추가하려면, 코어시스템 기능에 영향을 주지 않고 별도의 모듀로 추가할 수 있습니다. 이러한 모듈화는 코어시스템에 영향을 주지 않으면서 새로운 기능을 추가하거나 기존 기능을 제거하기 쉽게 만들어 줍니다.
게다가, 웹사이트가 다양한 사용자의 요구를 충족하기 위해 시스템을 사용자별로 지정하고 싶다면, 각 사용자가 필요한 모듈을 선택할 수 있습니다. 예를 들어, 전자 제품을 자주 구매하는 사용자에게 전자 제품을 추천하는 모듈을 제공할 수 있습니다. 또한, 화장품을 자주 구매하는 사용자에게는 화장품 제품을 추천하는 모듈을 제공할 수 있습니다.
마지막으로, 웹사이트가 더 많은 사용자나 하드웨어 변경에 대응하기 위해 시스템을 확장하고 싶다면 필요에 따라 모듈을 쉽게 추가하거나 제거할 수 있습니다. 이런 확장성은 사용자 요구사항의 변화나 기반이 되는 하드웨어의 변화에 시스템을 적응시키기 더 쉽게 만듭니다.

6. DDD (Domain Driven Design)

DDD는 프로젝트 도메인 또는 프로젝트의 문제를 강조하는 소프트웨어 아키텍처에 대한 사고 방식입니다. 이는 개발자들이 기술적 구현뿐만 아니라 소프트웨어의 비즈니스 로직에 중점을 두도록 하는것을 의미합니다.

실제로, 이는 개발자들이 작업중인 도메인을 이해하고 이를 더 작고 관리하기 쉬운 부분으로 나누는 것으로 시작합니다. 이를 기반으로 도메인 모델을 만드어야 하는데, 이 모델은 도메인 내의 다양한 엔터니와 그들이 어떻게 상호 작용하는지를 나타냅니다.

도메인 모델이 생성되면, 개발자들은 이를 사용하여 소프트웨어의 나머지 아키텍처를 만들 수 있습니다. 여기에는 특정 언어 및 컨텍스트를 생성하거나, 여러 관련 엔티티의 컬렉션으로 다루어지는 집합체인 어그리케이트를 생성하는 것도 포함됩니다.

7. Component Based

소프트웨어 공학에서 컴포넌트 기반 아키텍처(CBA)는 재사용 가능한 컴포넌트 요소의 사용을 강조하는 설계 및 개발 접근 방식입니다. CBA 는 복잡한 시스템을 더 작고 관리하기 쉬운 구성 요소로 나눔으로써 소프트웨어 개발을 더 효율적으로 만들 수 있습니다.

컴포넌트란 무엇인가?

컴포넌트는 다른 시스템에서 재사용 될 수 있는 모듈화된 독립적인 소프트웨어 단위를 의미합니다. 컴포넌트는 일반적으로 명확한 인터페이스를 갖고 있으며, 이 인터페이스는 다른 컴포넌트가 어떻게 상호작용할 수 있는지를 정의합니다. 인터페이스에는 컴포넌트의 입,출력 및 동작에 관한 정보가 포함됩니다.
컴포넌트는 사용자 인터페이스, 데이터 액세스 컴포넌트, 비즈니스 로직 컴포넌트와 같은 기능에 따라 다양한 유형으로 분류될 수 있습니다. 각 유형의 컴포넌트는 소프트웨어 시스템에서 특정 역할을 하며 다른 컴포넌트와 인터페이스를 통해 상호 작용할 수 있습니다.

8. SOA

SOA는 모듈화되고 재사용 가능한 서비스를 만들고, 다른 서비스와 쉽게 통합하여 더 큰 시스템을 만들기 위한 아키텍처 스타일을 목표로 합니다. 이 접근방식에서 서비스는 인터페이스를 통해 기능을 노출하며, 다른 서비스나 응용 프로그램이 이 인터페이스를 통해 액세스 할 수 있습니다.

SOA의 핵심은 소프트웨어를 더 작은 조각이나 모듈로 분해하여 다른 응용 프로그램에서 재사용할 수 있는 것을 기반으로 소프트웨어를 구축하는 것입니다. 이 모듈화된 접근방식은 개발자가 특정 기능의 조각을 만들고 그것을 통합하여 더 큰 시스템을 만들 수 있도록 하는 것에 중점을 둡니다.

SOA의 핵심 구성 요소

Service Provider: 서비스 제공자는 서비스를 생성하고 외부에 노출하는 역할을 합니다. 이러한 서비스는 다른 서비스, 응용 프로그램 또는 최종 사용자가 사용할 수 있습니다. 예를 들어, 결제 처리 서비스 제공자는 결제 처리를 다루는 다른 프로그램이 사용할 수 있는 서비스를 생성하고 노출할 수 있습니다.
Service Registry: 다른 서비스 또는 어플리케이션에서 액세스 할 수 있는 사용 가능한 서비스의 디렉토리입니다. 서비스 레지스트리는 서비스에 관한 정보를 제공하며, 서비스의 이름, 위치 및 인터페이스와 같은 정보가 포함됩니다. 예를 들어, 어떤 응용 프로그램이 결제를 처리해야 한다면, 서비스 레지스트리를 사용하여 결제 처리 서비스를 찾고 해당 인터페이스에 액세스 할 수 있습니다.
Service Requestor: 서비스 제공자가 노출한 서비스를 사용하는 역할을 합니다. 이를 위해 적절한 서비스를 찾기 위해 서비스 레지스트리를 사용하고 해당 인터페이스를 호출하는 방식으로 수행됩니다. 예를 들어, 어떤 어플리케이션은 서비스 레지스트리를 사용하여 결제 처리 서비스를 찾은 다음 해당 인터페이스를 사용하여 결제를 처리할 수 있습니다. 

9. Monolithic

모노리식 아키텍처는 수십년 동안 사용된 소프트웨어 디자인 패턴입니다. 이것은 어플리케이션을 개별 작은 구성요소로 분리하는 대신 하나의 일관된 단위로 구조화하는 방법입니다.

이 아키텍처는 전체 어플리케이션이 단일 독립되 단위로 구축됩니다. 모든 코드와 종속성은 함께 패키지된 어플리케이션은 단일 서버에 배포 및 실행될 수 있습니다.

이것은 어플리케이션을 개발하고 배포하기 쉽게 만들며, 모든 것이 한 곳에 있기 때문에 더 많은 서버를 추가하여 수평 확장하는 것을 쉽게 만들어 줍니다.

모노리식 아키텍처의 장점

모노리식 아키텍처의 가장 큰 장점 중 하나는 단순함입니다. 모든 것이 하나의 단위에 포함되어 있기 때문에 걱정할 부분이 적습니다. 이로써 어플리케이션을 개발, 테스트 및 배포하기가 더 쉬워집니다.
또 다른 장점은 유지보수 및 디버깅 하는 것이 더 쉽다는 것입니다. 모든 것이 한 곳에 있기 때문에 문제를 찾아 수정하는 것이 쉬워집니다.

모노리식 아키텍처의 단점

모노리식 아키텍처의 가장 큰 단점 중 하나는 어플리케이션을 수직 확장하는 것이 어려울 수 있다는 것입니다. 모든 것이 하나의 서버에서 실행되므로 어플리케이션이 처리할 수 있는 트래픽의 한계가 있습니다.
또 다른 단점은 새로운 기술과 언어를 도입하기가 어려울 수 있다는 것입니다. 모든 것이 함께 패키징되어 있기 때문에 전체 어플리케이션을 변경하지 않고 개별 컴포넌트만 업데이트 하기 어려울 수 있습니다.

10. Microservice

마이크로서비스 아키텍처는 어플리케이션을 네트워크를 통해 통신하는 작은 독립저긴 서비스 집합으로 구조화하는 소프트웨어 아키텍처 스타일입니다. 각 서비스는 특정 비즈니스 구현에 중점을 두며, 시스템의 다른 서비스와 독립적으로 개발, 배포 및 확장할 수 있습니다.

MSA의 사상은 크고, 단일화된 어플리케이션을 더 작고 관리하기 쉬운 서비스로 분해하는 것입니다. 이 접근방식은 개선된 확장성, 증가된 유연성 및 새로운 기능의 신속한 적용과 같은 여러 장점을 가져옵니다. MSA 에서는 각 서비스를 독립적으로 확장할 수 있어 트래픽 급증이나 수요 변화를 처리하기 더 수월합니다. 개발자는 시스템의 다른 부분에 영향을 미치자 않고 서비스를 수정하거나 새로 추가할 수 있으므로 개발 프로세스가 가속화 됩니다.

마이크로서비스 아키텍처의 도전과제

마이크로서비스 아키텍처의 장점에도 불구하고 추가 복잡성이 발생합니다. 가장 큰 도전은 서비스 간 통신을 관리하는 것입니다. 서비스는 서로를 찾아서 효과적으로 통신할 수 있어야 하며, 이는 대규모 확장 시 어려움이 발생할 수 있습니다. 로드밸런싱과 장애 허용도 MSA에서는 더 복잡합니다.
또 다른 과제는 각 서비스가 자체 데이터 저장소를 갖도록 하는 것입니다. 모노리식 어플리케이션에서는 단일 데이터베이스에 모든 데이터를 저장합니다. MSA 에서는 각 서비스가 다른 서비스에 영향을 미치지 않도록 자체 데이터 저장소를 가져야 합니다. 이로 인해 데이터 관리와 동기화에서 복잡성이 증가할 수 있습니다.

Best Practices for Microservice Architecture
 
마이크로서비스 기반 시스템의 성공을 보장하기 위해, 개발자들은 마이크로 서비스를 설계하고 구현하는 데 최선의 방법을 따라야 합니다. 이러한 최선의 방법 중 일부는 다음과 같습니다.
1. 느슨하게 결합되고 높은 응집도를 갖도록 서비스를 설계하고, 명확한 경계와 정의된 인터페이스를 갖도록 합니다.
2. Docker와 같은 컨테이너 기술을 사용하여 각 서비스를 별도의 컨터이너로 패키징하고 배포하도록 합니다. 이로써 필요한 경우 개별 서비스를 쉽게 확장하고 배포할 수 있습니다.
3. 시스템이 원활하게 실행되고 문제를 신속하게 감지하고 해결하기 위한 효과적인 모니터링 및 관리 도구를 구현하도록 합니다.
4. Istio와 같은 서비스 메시를 사용하여 서비스 간 통신과 로드밸런싱을 관리하도록 합니다.
5. 지속적인 통합 및 배포 (CI / CD) 파이프라인을 구현하여 마이크로서비스의 테스트 및 배포를 자동화하도록 합니다.

11. Event Driven

이벤트 주도 아키텍처(EDA)는 서로 다른 컴포넌트나 서비스간의 신속하고 효율적인 통신을 가능하게 하는 소프트웨어 시스템을 설계하는 접근 방식입니다. 이 패러다임에서 서로 다른 소프트웨어 컴포넌트는 직접적인 요청 또는 응답 대신 이벤트를 사용하여 서로 통신합니다.

EDA에서 이벤트는 사용자 인터페이스나 백엔드 서비스와 같은 소프트웨어 시스템의 다양한 구성 요소에 의해 생성됩니다. 이러한 이벤트는 다른 시스템의 컴포넌트에 브로드캐스트 되며, 필요한 대로 구독하고 그에 따라 동작할 수 있습니다.

예를 들어, 간단한 전자 상거래 어플리케이션을 고려해 봅시다. 새 주문이 발생할 때 주문 처리 서비스는 "주문 생성" 이벤트를 생성하고, 이 이벤트는 재고 관리, 배송 및 청구와 같은 다른 서비스에 브로드캐스트 됩니다. 각 서비스는 이 이벤트를 처리하고 해당 시스템을 업데이트 할 수 있습니다.

EDA 의 이점

EDA의 주요 이점 중 하나는 소프트웨어 시스템의 서로 다른 컴포넌트를 분리하는 것입니다. 서로 다른 컴포넌트가 직접적인 요청 대신 이벤트를 통해 통신할 때, 서로에 대한 의존성이 줄어듭니다. 이로써 시스템의 개별 컴포넌트를 변경하거나 업데이트 하는 것이 나머지 시스템에 영향을 미치지 않도록 만들어 줍니다.
EDA의 또다른 이점은 확장성입니다. 이벤트가 시스템의 여러 컴포넌트에 브로드캐스트 되므로 대량의 데이터와 트랜잭션을 병렬로 처리할 수 있습니다, 이로써 높은 트래픽과 수요 급증을 처리하기 더 쉬워집니다.

EDA 의 도전과제

EDA는 많은 장점을 가지고 있지만 몇가지 도전과제도 존재합니다. 주요 과제 중 하나는 이벤트 주도 시스템의 복잡성을 관리하는 것입니다. 이벤트는 다양한 컴포넌트에서 생성하고 사용될 수 있기 때문에 발생하는 문제를 추적하고 디버그하는 것이 어려울 수 있습니다.
또 다른 도전 과제는 이벤트가 올바른 순서로 처리되도록 하는 것입니다. 이벤트가 비동기적으로 생성 및 처리될 수 있기 때문에 이벤트가 순서대로 처리되지 않을 가능성이 있습니다. 이로 인해 데이터 불일치나 잘못된 계산과 같은 문제가 발생할 수 있습니다.

12. Stream Based

소프트웨어 개발이 더 복잡해지고 더 큰 확장성을 요구함에 따라 전통적인 아키텍처는 점점 효과적이지 않아지고 있습니다. 스트림 기반 아키텍처는 대규모 데이터를 실시간으로 처리할 수 있는 시스템을 개발할 수 있게 해주는 유망한 대안으로 떠오르고 있습니다.

스트림 기반 아키텍처의 핵심은 이벤트 주도 프로그래밍의 원칙에 기반하고 있습니다. 스트림 기반 시스템은 데이터를 일괄 처리하는 대신 데이터가 실시간으로 생성됨에 따라 데이터를 처리합니다. 이로써 개발자는 데이터 변경에 미미한 대기 시간으로 응답할 수 있는 시스템을 구축할 수 있습니다.

Stream-Based 아키텍처의 장점

스트림 기반 아키텍처의 주요 장점 중 하나는 확장성입니다. 데이터가 실시간으로 처리되기 때문에 스트림 기반 시스템은 복잡한 일괄처리 파이프라인이 필요하지 않고 대규모 데이터를 처리할 수 있습니다. 이로써 초당 수백만 건의 이벤트를 처리할 수 있는 시스템을 구축할 수 있으며, 센서 데이터 처리, 금융 거래 및 온라인 광고와 같은 사용 사례에 이상적입니다.
또 다른 장점은 유연성입니다. 데이터가 실시간으로 처리되기 때문에 데이터 변경에 미미한 대기 시간으로 응답할 수 있는 시스템을 구축할 수 있습니다. 이로써 비즈니스 요구사항의 변화에 적응할 수 있는 복잡한 이벤트 주도 시스템을 구축할 수 있습니다. 예를 들어 전자 상거래 플랫폼에서 스트림 기반 아키텍처를 사용하여 사용자 활동을 실시간으로 추척하고 사용자의 브라우징 및 구매 이력을 기반으로 개인화 된 추천 및 프로모션을 제공할 수 있습니다.
뿐만 아니라, 상당한 비용 절감 효과를 제공합니다. 전통적인 일괄처리 파이프라인은 비싼 하드웨어와 데이터 처리를 관리하기 위한 복잡한 소프트웨어 인프라가 필요합니다. 반면 스트림 기반 시스템은 저렴한 상용 하드웨어에서 구축할 수 있으므로 확장성과 유지보수가 쉬워집니다.
마지막으로 내결함성이 뛰어납니다. 데이터가 실시간으로 처리되기 때문에 수동 개입 없이 오류에서 자동으로 복구할 수 있는 시스템을 구축할 수 있습니다. 이로써 신뢰성 높은 대규모 시스템을 운영할 수 있어 데이터 손실 또는 시스템 다운타임의 위험을 줄일 수 있습니다.

결론

요약하면, 소프트웨어 아키텍처는 사용자와 이해 관계자의 요구사항을 충족하는 성공적인 소프트웨어 시스템을 구축하기 위해 중요합니다. 이것은 소프트웨어 시스템을 설계하고 개발하기 위한 청사진을 제공하며, 시스템이 기능적, 비기능적 요구사항을 충족하도록 보장하며, 적응성을 촉진하고 복잡성을 관리하는데 도움이 됩니다. 따라서 소프트웨어 개발 프로젝트의 초기에 견고한 아키텍처를 설계하기 위해 시간과 리소스를 투자하는 것이 중요합니다.