[Architecture] 다양한 아키텍처들

이번 시간에는 다양한 아키텍처 패턴에 대해서 알아보는 시간을 가져보겠습니다.

 

---

Layered Architecture

소프트웨어 시스템을 여러 계층(Layer) 으로 나누어 설계하는 아키텍처 패턴입니다. 각 계층은 특정한 역할과 책임을 가지며, 상위 계층은 하위 계층의 기능을 이용하여 동작합니다. 이 아키텍처는 시스템의 복잡성을 관리하고 유지 보수를 용이하게 하기 위해 자주 사용됩니다.

 

기본 개념

레이어드 아키텍처는 시스템을 여러 개의 계층으로 분리하여 설계하는 방식입니다. 이 계층들은 일반적으로 다음과 같은 주요 기능에 따라 나누어집니다.

• Presentation Layer
• Application Layer 혹은 Service Layer
• Domain Layer 혹은 Business Logic Layer
• Data Access Layer

각 계층은 자신만의 역할을 가지며, 계층 간의 의존성은 하위 계층에서 상위 계층으로만 향해야 합니다. 즉, 상위 계층은 하위 계층의 기능을 사용할 수 있지만, 하위 계층은 상위 계층에 의존하지 않습니다.

 

각 계층의 역할

 

Presentation Layer

 

프레젠테이션 계층은 사용자 인터페이스를 담당하는 계층입니다. 사용자가 시스템과 상호작용하는 부분으로, 웹 애플리케이션의 경우 HTML, CSS, JavaScript 등을 사용하여 화면을 구성합니다.

• 역할: 사용자로부터 입력을 받아 애플리케이션 계층에 전달하고, 애플리케이션 계층으로부터 받은 결과를 사용자가 이해할 수 있는 형태로 출력합니다.
• 주요 기술: HTML, CSS, JavaScript, React, Angular 등

 

Application Layer / Service Layer

 

애플리케이션 계층은 Domain Layer 와 Presentation Layer 을 연결하는 중간 계층입니다. 이 계층은 사용자의 요청을 받아 비즈니스 로직을 실행하고, 그 결과를 프레젠테이션 계층에 전달합니다.

• 역할: 프레젠테이션 계층의 요청을 처리하여 비즈니스 로직 계층에 전달하고, 결과를 반환합니다. 여기서는 시스템의 흐름 제어나 트랜잭션 관리 등이 이루어집니다.
• 주요 기술: Spring Service, EJB(Enterprise JavaBeans), ASP.NET MVC, Django

 

Domain Layer / Business Logic Layer

 

도메인 계층은 시스템의 핵심 비즈니스 로직을 구현하는 계층입니다. 이 계층에서는 특정 비즈니스 규칙과 정책을 코드로 구현합니다.

 

• 역할: 비즈니스 규칙을 구현하고, 데이터 계층에서 데이터를 가져와 필요한 비즈니스 로직을 처리한 후 결과를 반환합니다.
• 주요 기술: POJO(Plain Old Java Object), 비즈니스 서비스 클래스, 엔터프라이즈 패턴

 

Data Access Layer

 

데이터 접근 계층은 데이터베이스와의 통신을 담당하는 계층입니다. 이 계층은 데이터베이스의 CRUD(Create, Read, Update, Delete) 작업을 추상화하여 애플리케이션이 데이터베이스의 세부 사항에 의존하지 않도록 합니다.

 

 

• 역할: 데이터베이스와의 상호작용을 관리하고, 비즈니스 로직 계층이 데이터베이스와 직접 상호작용하지 않도록 합니다.
• 주요 기술: JDBC, Hibernate, Entity Framework, JPA(Java Persistence API) 등

 

장점

 

• 모듈화: 시스템을 여러 계층으로 나누어 모듈화함으로써, 각 계층이 독립적으로 개발되고 테스트될 수 있습니다.
• 유지보수 용이: 각 계층이 독립적이기 때문에, 특정 계층의 수정이 다른 계층에 영향을 미치지 않도록 할 수 있어 유지보수가 용이합니다.
• 재사용성: 각 계층은 독립적인 모듈로 설계되므로, 동일한 계층을 다른 프로젝트나 시스템에서 재사용할 수 있습니다.
• 유연성: 시스템의 특정 계층을 교체하거나 확장하기 쉽습니다. 예를 들어, 데이터베이스를 변경할 때 데이터 접근 계층만 수정하면 됩니다.

 

단점

• 성능 문제: 각 계층 간의 통신이 많아질수록 오버헤드가 발생할 수 있습니다. 특히, 대규모 시스템에서 이로 인한 성능 저하가 발생할 수 있습니다.
• 복잡성 증가: 계층이 많아질수록 시스템의 복잡성이 증가하며, 각 계층 간의 인터페이스를 관리하는 데 시간이 많이 소요될 수 있습니다.
• 추가적인 코드: 각 계층을 분리하여 설계하기 때문에, 실제 구현에 필요한 코드가 증가할 수 있습니다. 이는 개발 시간이 늘어나는 결과를 초래할 수 있습니다.

 

---

Monolithic Architecture

 

모놀리식 아키텍처(Monolithic Architecture)는 소프트웨어 애플리케이션을 하나의 큰 단일 코드베이스로 구성하는 전통적인 아키텍처 패턴입니다. 이 아키텍처에서는 애플리케이션의 모든 기능이 하나의 코드베이스에 포함되며, 애플리케이션이 하나의 단위로 빌드되고 배포됩니다.

 

 

기본 개념

모놀리식 아키텍처는 소프트웨어 시스템이 하나의 큰 단일 애플리케이션으로 구성된다는 것을 의미합니다. 이 애플리케이션은 일반적으로 다음과 같은 주요 구성 요소를 포함합니다.

 

• 프레젠테이션 계층: 사용자 인터페이스를 담당하며, 사용자가 시스템과 상호작용하는 부분입니다.
• 비즈니스 로직 계층: 애플리케이션의 핵심 로직과 규칙을 처리하는 부분입니다.
• 데이터 접근 계층: 데이터베이스와의 상호작용을 관리하는 부분으로, 데이터의 저장, 조회, 업데이트 등을 담당합니다.

이 세 가지 주요 계층이 하나의 코드베이스에 통합되어 있으며, 개발, 테스트, 빌드, 배포가 하나의 단위로 이루어집니다.

 

특징

 

단일 코드 베이스

모놀리식 애플리케이션은 하나의 코드베이스에서 모든 기능이 통합되어 있습니다. 따라서 애플리케이션을 빌드하거나 배포할 때 전체 애플리케이션을 한 번에 처리해야 합니다.

 

단일 배포 유닛

애플리케이션이 하나의 단일 유닛으로 배포됩니다. 이로 인해 모든 기능이 포함된 하나의 실행 파일 또는 패키지가 생성됩니다.

 

모듈화 가능성

모놀리식 아키텍처에서도 코드베이스 내에서 모듈화를 통해 기능을 분리할 수 있습니다. 하지만, 이 모듈들은 여전히 하나의 애플리케이션 안에 포함되며, 독립적으로 배포될 수는 없습니다.

 

장점

 

단순성

모놀리식 아키텍처는 구조가 단순하여 이해하기 쉽고, 개발 초기 단계에서 빠르게 애플리케이션을 구축할 수 있습니다. 작은 팀에서의 개발이나 단순한 애플리케이션의 경우, 이 구조는 매우 효율적일 수 있습니다.

 

일관된 배포

모든 코드가 하나의 유닛으로 배포되기 때문에, 배포 과정이 단순합니다. 단일 애플리케이션으로 배포되는 만큼, 복잡한 배포 전략을 필요로 하지 않습니다.

 

성능

모놀리식 아키텍처에서는 애플리케이션의 모든 부분이 하나의 프로세스에서 실행되므로, 서비스 간 통신에 대한 오버헤드가 없습니다. 이로 인해 성능 측면에서 이점이 있을 수 있습니다.

 

개발 환경 설정의 용이성

모놀리식 애플리케이션은 하나의 프로젝트로 관리되므로, 개발 환경을 설정하고 유지 관리하기가 상대적으로 간단합니다.

 

 

단점

 

확장성의 한계

모놀리식 아키텍처는 특정 기능만 확장하기 어려워 전체 애플리케이션을 확장해야 합니다. 이는 리소스 낭비를 초래할 수 있으며, 특히 대규모 트래픽을 처리해야 하는 상황에서 비효율적입니다.

 

개발 속도 저하

애플리케이션이 커질수록 코드베이스가 복잡해져, 변경 작업이 어려워지고, 개발 속도가 느려질 수 있습니다. 작은 변경 사항도 전체 애플리케이션을 빌드하고 배포해야 하므로 개발 주기가 길어질 수 있습니다.

 

유지보수 어려움

하나의 애플리케이션에 모든 기능이 포함되어 있기 때문에, 유지보수 시 문제가 발생하면 애플리케이션 전체에 영향을 미칠 수 있습니다. 또한, 한 팀이 전체 애플리케이션을 모두 이해해야 하므로, 복잡한 시스템에서는 유지보수가 어렵습니다.

 

기술적 제한

모놀리식 아키텍처에서는 애플리케이션 전체가 하나의 기술 스택을 사용해야 하므로, 새로운 기술을 도입하거나 특정 기능에 맞는 최적의 기술을 선택하는 데 제한이 있습니다.

 

배포의 위험성

애플리케이션이 하나의 단위로 배포되기 때문에, 배포 중에 오류가 발생하면 전체 시스템이 중단될 수 있습니다. 이는 서비스의 가용성에 심각한 영향을 미칠 수 있습니다.

 

다른 아키텍처와의 비교

 

• 마이크로서비스 아키텍처(Microservices Architecture): 마이크로서비스 아키텍처는 애플리케이션을 여러 개의 작은 독립적인 서비스로 분리하여 각각 독립적으로 배포하고 관리할 수 있도록 설계합니다. 모놀리식 아키텍처에 비해 확장성, 유지보수성, 기술적 유연성이 뛰어납니다. 그러나, 서비스 간 통신의 복잡성과 배포의 복잡성을 고려해야 합니다.
• 서비스 지향 아키텍처(SOA): SOA는 모놀리식 아키텍처와 유사하지만, 보다 큰 범위에서 비즈니스 기능을 서비스로 분리하여 관리합니다. 이 패턴은 대규모 기업 환경에서 모놀리식 애플리케이션의 단점을 극복하기 위해 사용될 수 있습니다.

---

Service-Oriented Architecture

SOA(Service-Oriented Architecture, 서비스 지향 아키텍처)는 기업의 IT 시스템을 유연하고 확장 가능하게 설계하기 위한 아키텍처 패턴 중 하나입니다. SOA의 핵심 아이디어는 소프트웨어 시스템을 독립적인 서비스로 분리하고, 이들 서비스를 서로 결합하여 비즈니스 프로세스를 구현하는 것입니다.

 

기본 개념

SOA는 독립적인 기능 단위를 서비스로 정의합니다. 이 서비스들은 서로 독립적으로 개발되고 배포될 수 있으며, 명확하게 정의된 인터페이스를 통해 다른 서비스와 통신합니다. 서비스는 재사용 가능하고, 표준화된 프로토콜을 사용하여 서로 상호작용합니다.

 

특징

• 재사용 가능성: 한 번 개발된 서비스는 다양한 비즈니스 프로세스에서 재사용될 수 있습니다. 예를 들어, 결제 서비스는 여러 애플리케이션에서 사용할 수 있습니다.
• 인터페이스 중심: 서비스는 표준화된 인터페이스를 통해서만 접근이 가능하며, 인터페이스는 서비스의 구현 방식과는 무관하게 정의됩니다. 주로 WSDL(Web Services Description Language)과 같은 기술이 사용됩니다.
• 프로토콜 독립성: SOA는 다양한 프로토콜을 지원할 수 있지만, 일반적으로는 SOAP(Simple Object Access Protocol) 또는 REST(Representational State Transfer)와 같은 웹 서비스 프로토콜이 사용됩니다.
• 비즈니스 중심: 서비스는 주로 비즈니스 기능에 따라 정의되며, 기술보다는 비즈니스 요구에 의해 설계됩니다.

 

구성 요소

SOA는 다음과 같은 주요 구성 요소로 이루어집니다

 

• 서비스 제공자: 서비스를 실제로 제공하는 역할을 합니다. 서비스 제공자는 서비스의 인터페이스와 구현체를 제공합니다.
• 서비스 소비자: 서비스를 호출하여 사용하는 역할을 합니다. 소비자는 서비스의 인터페이스를 통해 필요한 비즈니스 로직을 호출합니다.
• 서비스 레지스트리: 서비스의 메타데이터를 저장하고 관리하는 중앙 저장소입니다. 소비자는 이 레지스트리를 통해 서비스의 위치와 인터페이스 정보를 검색할 수 있습니다.

 

장점

 

• 유연성: 비즈니스 요구사항 변화에 따라 쉽게 서비스를 추가하거나 변경할 수 있습니다.
• 확장성: 시스템의 일부만 수정하면 되기 때문에, 시스템 전체에 영향을 미치지 않고도 기능을 확장할 수 있습니다.
• 재사용성: 서비스는 다양한 애플리케이션에서 재사용될 수 있어 개발 비용과 시간을 절감할 수 있습니다.
• 이식성: 서비스는 플랫폼에 독립적이기 때문에, 서로 다른 시스템 간에도 통신이 가능합니다.

 

단점

 

• 복잡성: SOA를 구현하기 위해서는 서비스의 설계, 배포, 관리 등 많은 부분에서 높은 수준의 기술이 요구됩니다.
• 성능: 서비스 간 통신이 네트워크를 통해 이루어지기 때문에, 잘못 설계된 SOA는 성능 문제를 야기할 수 있습니다.
• 거버넌스 필요성: 여러 서비스가 함께 작동하기 때문에, 서비스의 변경이나 버전 관리를 철저히 하지 않으면 시스템의 일관성을 유지하기 어렵습니다.

 

연관 기술들

 

• SOAP: XML 기반의 메시징 프로토콜로, SOA에서 가장 많이 사용되는 통신 방법 중 하나입니다.
• REST: 경량화된 웹 서비스 통신 방식으로, HTTP를 기반으로 하여 간단한 CRUD(생성, 읽기, 업데이트, 삭제) 작업을 수행할 수 있습니다.
• WSDL: 웹 서비스의 인터페이스와 서비스 위치를 기술하는 XML 문서입니다.
• UDDI: 웹 서비스의 레지스트리 표준으로, 서비스의 검색과 관리를 지원합니다.

 

MSA 와의 차이점

 

• 서비스 크기: SOA의 서비스는 비교적 크고 포괄적일 수 있는 반면, 마이크로서비스는 작은 단위의 서비스로 나뉩니다.
• 통신 방식: SOA는 종종 ESB(Enterprise Service Bus)를 사용하여 서비스 간의 통신을 중앙 집중화하는 반면, 마이크로서비스는 서비스 간 직접적인 통신을 선호합니다.
• 배포: SOA는 서비스가 동일한 환경에서 배포되는 경우가 많지만, 마이크로서비스는 각 서비스가 독립적으로 배포될 수 있습니다.

---

Microservices Architecture

마이크로서비스 아키텍처(MSA, Microservices Architecture)는 애플리케이션을 독립적으로 배포, 운영, 확장할 수 있는 작은 서비스들로 나누어 개발하는 소프트웨어 아키텍처 패턴입니다. 각 마이크로서비스는 고유의 비즈니스 기능을 담당하며, 독립적으로 개발되고 배포될 수 있습니다. 이 아키텍처는 복잡한 애플리케이션을 유연하고 확장 가능하게 만들기 위해 널리 사용됩니다.

 

기본 개념

MSA는 애플리케이션을 여러 개의 작은 독립적인 서비스로 나누어 설계합니다. 각 서비스는 특정 비즈니스 기능을 수행하며, 독립적으로 배포 및 운영될 수 있습니다.

• 독립적인 서비스: 각 마이크로서비스는 다른 서비스와 독립적으로 배포 및 운영될 수 있으며, 서비스 간의 의존성을 최소화합니다.
• 독립적인 데이터 관리: 각 마이크로서비스는 자체적인 데이터베이스를 가지고 있으며, 다른 서비스의 데이터에 직접 접근하지 않습니다. 서비스 간의 데이터 공유는 API를 통해 이루어집니다.
• 다양한 기술 스택: 마이크로서비스는 독립적이기 때문에 각 서비스에서 가장 적합한 기술 스택을 사용할 수 있습니다. 예를 들어, 한 서비스는 Java로, 다른 서비스는 Python으로 구현될 수 있습니다.

 

특징

독립적인 배포

마이크로서비스는 개별적으로 배포할 수 있기 때문에, 특정 서비스의 업데이트나 확장 작업이 다른 서비스에 영향을 미치지 않습니다.

 

확장성

각 서비스는 독립적으로 확장될 수 있습니다. 트래픽이 많은 서비스만 별도로 확장하여 리소스를 효율적으로 사용할 수 있습니다.

 

장애 격리

MSA에서는 하나의 서비스에 문제가 발생하더라도, 다른 서비스에 영향이 최소화됩니다. 이는 전체 시스템의 안정성을 높여줍니다.

 

자율적인 팀

각 마이크로서비스는 독립적으로 개발될 수 있기 때문에, 조직의 팀들도 자율적으로 운영될 수 있습니다. 각 팀은 특정 서비스에 전념하며, 그 서비스의 라이프사이클을 관리합니다.

 

 

장점

 

• 유연성: 각 마이크로서비스는 독립적으로 개발되고 배포될 수 있으므로, 새로운 기능을 빠르게 추가하고 기존 기능을 수정할 수 있습니다.
• 확장성: 서비스별로 독립적인 확장이 가능하여, 자원 효율성을 극대화할 수 있습니다.
• 장애 격리: 하나의 서비스에 장애가 발생하더라도 다른 서비스에 영향을 최소화할 수 있습니다.
• 다양한 기술 사용: 각 서비스가 독립적이므로, 각 서비스의 요구에 맞는 최적의 기술을 사용할 수 있습니다.
• 효율적인 유지보수: 코드베이스가 분리되어 있으므로, 유지보수 작업이 더 쉽고 명확합니다.

 

단점

 

• 복잡성 증가: 많은 서비스가 존재하므로, 서비스 간의 통신, 배포, 모니터링 등에서 복잡성이 증가할 수 있습니다.
• 서비스 간 통신의 비용: 서비스 간의 통신이 네트워크를 통해 이루어지기 때문에, 통신 비용과 지연(latency)이 발생할 수 있습니다.
• 데이터 일관성 문제: 각 서비스가 독립된 데이터베이스를 사용하기 때문에, 데이터 일관성을 유지하는 데 어려움이 있을 수 있습니다.
• 배포 및 운영의 복잡성: 여러 서비스가 독립적으로 배포되기 때문에, 운영 환경에서의 복잡성이 높아질 수 있습니다.

 

MSA 에서 서비스 간 통신

MSA의 핵심은 독립적인 서비스 간의 상호작용입니다. 서비스 간의 통신은 매우 중요하며, 이를 효과적으로 설계하는 것이 성공적인 MSA 구현의 핵심입니다.

 

동기식 통신(Synchronous Communication)

동기식 통신은 서비스 간의 호출이 완료될 때까지 호출한 서비스가 기다리는 형태입니다. 가장 일반적인 동기식 통신 방법은 HTTP/REST와 gRPC입니다.

• HTTP/REST: 가장 널리 사용되는 방식으로, RESTful API를 통해 서비스를 호출합니다. HTTP는 이해하기 쉽고 구현이 간단하지만, 성능이 중요한 경우에는 오버헤드가 발생할 수 있습니다.
• gRPC: Google이 개발한 고성능 원격 프로시저 호출(RPC) 프레임워크로, 프로토콜 버퍼(Protocol Buffers)를 사용하여 직렬화 성능을 향상시킵니다. gRPC는 REST보다 효율적이고, 다중 언어 지원이 뛰어나지만, 상대적으로 복잡합니다.

장점

• 실시간 응답이 필요할 때 적합합니다.
• 구현이 비교적 간단합니다.

단점

• 네트워크 지연에 취약하며, 전체 요청 체인의 한 서비스가 느려지면 전체 시스템에 영향을 줄 수 있습니다.
• 높은 가용성을 유지하기 위해 서비스 간의 결합도가 높아질 수 있습니다.

 

비동기식 통신(Asynchronous Communication)

비동기식 통신은 요청이 비동기적으로 처리되며, 호출된 서비스가 응답을 즉시 주지 않아도 됩니다. 주로 메시지 브로커를 통해 큐 기반으로 이루어집니다.

• 메시지 브로커: Apache Kafka, RabbitMQ, Amazon SQS와 같은 메시지 브로커를 사용하여 서비스 간의 메시지를 큐(queue)에 넣고, 수신 서비스가 메시지를 처리합니다. 이는 서비스 간의 강한 결합을 피하고, 느슨한 결합을 가능하게 합니다.

장점

• 서비스 간 결합을 느슨하게 유지할 수 있어 유연성이 높습니다.
• 비동기 메시징은 부하가 높은 상황에서도 안정적인 성능을 유지할 수 있습니다.
• 일시적인 네트워크 장애에도 메시지가 유실되지 않도록 보장할 수 있습니다.

단점

• 메시지 전달 지연으로 인해 실시간 응답이 어려울 수 있습니다.
• 시스템의 복잡성이 증가하며, 메시지 순서 보장과 같은 문제를 처리해야 할 수도 있습니다.

 

서비스 간 통신 패턴

 

• API 게이트웨이 패턴: 서비스 간의 통신을 중앙화된 API 게이트웨이를 통해 관리합니다. API 게이트웨이는 모든 요청을 받아 적절한 서비스로 전달하며, 로드 밸런싱, 인증, 라우팅 등을 처리합니다.
• 사가 패턴(Saga Pattern): 복잡한 비즈니스 트랜잭션을 다루기 위해 사가 패턴을 사용합니다. 사가는 각 서비스가 개별적인 로컬 트랜잭션을 수행하고, 다음 단계로 이어지는 이벤트를 발생시켜 전체 트랜잭션을 완성합니다. 실패 시 보상 트랜잭션을 통해 롤백합니다.
• Circuit Breaker 패턴: 서비스 간의 통신에서 하나의 서비스가 실패하면, 다른 서비스에 영향을 줄 수 있습니다. 이를 방지하기 위해 Circuit Breaker 패턴을 사용하여 특정 서비스의 요청이 실패하면, 일정 기간 동안 해당 서비스로의 요청을 차단합니다.

---

Event-Driven Architecture

EDA(Event-Driven Architecture, 이벤트 주도 아키텍처)는 소프트웨어 설계 패턴 중 하나로, 시스템 내의 다양한 컴포넌트들이 이벤트에 반응하여 동작하는 방식으로 설계된 아키텍처입니다. EDA는 비동기적이고 분산된 시스템에서 특히 유용하며, 변화에 빠르게 대응할 수 있는 유연한 구조를 제공합니다.

 

기본 개념

EDA는 시스템의 구성 요소들이 이벤트를 생성하고, 이 이벤트에 반응하는 방식으로 동작하는 아키텍처입니다. 이벤트는 시스템 내에서 발생하는 중요한 상태 변화나 동작을 나타내며, 이러한 이벤트에 대해 시스템의 다른 부분이 적절히 반응하여 행동을 취합니다.

 

• 이벤트: 이벤트는 특정 시점에 시스템에서 발생하는 상태 변화나 활동을 나타냅니다. 예를 들어, 사용자가 웹 애플리케이션에서 버튼을 클릭하면 "버튼 클릭"이라는 이벤트가 발생할 수 있습니다.
• 이벤트 발생자(Event Producer): 이벤트 발생자는 시스템 내에서 이벤트를 생성하고 발행하는 역할을 하는 컴포넌트입니다. 예를 들어, 사용자 인터페이스, 센서, 애플리케이션 로직 등이 이벤트 발생자의 역할을 할 수 있습니다.
• 이벤트 소비자(Event Consumer): 이벤트 소비자는 이벤트를 수신하고 그에 반응하는 컴포넌트입니다. 이벤트 소비자는 이벤트에 따라 특정 작업을 수행하거나, 다른 시스템과 상호작용할 수 있습니다.
• 이벤트 브로커(Event Broker): 이벤트 브로커는 이벤트 발생자와 이벤트 소비자 간의 통신을 중개하는 역할을 합니다. 이벤트 브로커는 이벤트의 발행, 구독, 라우팅 등을 관리하여 시스템의 유연성을 높입니다. Apache Kafka, RabbitMQ, Amazon SNS 등이 이벤트 브로커로 사용될 수 있습니다.

구성 요소

 

• 이벤트(Event): 시스템 내에서 발생하는 상태 변화나 동작을 나타내는 메시지 또는 신호입니다.
• 이벤트 발생자(Event Producer): 이벤트를 생성하고 발행하는 시스템의 컴포넌트입니다.
• 이벤트 소비자(Event Consumer): 이벤트를 수신하고 그에 따라 동작하는 컴포넌트입니다.
• 이벤트 브로커(Event Broker): 이벤트 발생자와 이벤트 소비자 간의 통신을 중개하는 시스템입니다.

특징

• 비동기성: EDA의 주요 특징 중 하나는 비동기적으로 동작한다는 점입니다. 이벤트가 발생하면 이벤트 소비자가 이를 수신하고 처리하는 동안, 이벤트 발생자는 다음 작업을 계속 진행할 수 있습니다. 이는 시스템의 응답성을 높이고, 트래픽이 많은 환경에서도 효율적으로 동작할 수 있게 합니다.
• 느슨한 결합: EDA에서는 이벤트 발생자와 소비자가 느슨하게 결합되어 있습니다. 즉, 이벤트 발생자는 특정 이벤트 소비자에 대해 알 필요가 없으며, 이벤트 브로커가 이들 간의 통신을 중개합니다. 이는 시스템의 유연성을 높이고, 새로운 소비자를 추가하거나 기존 소비자를 제거하는 작업이 쉬워집니다.
• 확장성: EDA는 시스템의 확장성을 극대화합니다. 새로운 이벤트 소비자를 쉽게 추가할 수 있으며, 이벤트 브로커의 성능을 조정하여 시스템 전체의 확장성을 조절할 수 있습니다.
• 이벤트 스트리밍: EDA에서는 이벤트 스트리밍을 통해 실시간 데이터를 처리할 수 있습니다. 이는 특히 금융, IoT, 실시간 분석 등 데이터 흐름이 중요한 분야에서 강력한 장점이 됩니다.

장점

 

• 유연성: 시스템의 구성 요소가 느슨하게 결합되어 있으므로, 새로운 기능을 추가하거나 변경할 때 시스템 전체에 미치는 영향을 최소화할 수 있습니다.
• 확장성: 비동기적 처리 덕분에 시스템의 확장성이 뛰어납니다. 트래픽 증가에 대응하기 위해 개별 컴포넌트나 브로커를 독립적으로 확장할 수 있습니다.
• 복원력: 이벤트 브로커를 사용하면 이벤트가 안전하게 저장되고 전달되므로, 시스템 장애에도 데이터 손실 없이 복구할 수 있습니다.
• 실시간 처리: 이벤트 스트리밍을 통해 실시간으로 데이터를 처리할 수 있어, 즉각적인 응답이 필요한 상황에서 효과적입니다.

단점

 

• 복잡성: EDA는 시스템의 설계와 구현이 복잡할 수 있습니다. 이벤트 흐름을 관리하고, 장애 시 복구 메커니즘을 설계하는 데 많은 노력이 필요합니다.
• 디버깅의 어려움: 비동기적 특성으로 인해 이벤트가 발생한 원인을 추적하고 디버깅하는 것이 어렵습니다. 로그 관리와 모니터링이 필수적입니다.
• 일관성 유지의 어려움: 분산된 시스템에서 데이터 일관성을 유지하는 것이 어려울 수 있습니다. 이를 위해서는 이벤트 소싱이나 CQRS(Command Query Responsibility Segregation) 패턴 등을 고려해야 합니다.
• 지연 가능성: 이벤트 처리 지연이 발생할 수 있으며, 이로 인해 실시간 응답이 필요한 시스템에서는 문제가 될 수 있습니다.