[ 아키텍처 ] 파이프-필터 아키텍처

파이프-필터 아키텍처(Pipes and Filters Architecture)

 

 

파이프-필터 아키텍처는 일련의 파이프를 따라 흐르며 여러 단계의 필터를 통과해 원하는 환경에 도달하는 데이터로 묘사할 수 있다.

• 파이프 는 필터를 연결하며, 일반적으로 분산 대기열이나 메시지 브로커에 해당한다.
• 필터는 각 단계에서 데이터를 처리하는 고립된 소프트웨어 컴포넌트 에 해당하며, 수신 데이터에 대해 하나의 작업만을 수행하고, 나머지 파이프라인과 무관하게 동작한다.

 

 

• 데이터 소스: 데이터의 출처를 말한다.
  • 사용자로부터 네트워크 요청을 수신하는 백엔드 서비스가 될 수도 있다.
  • 센서 또는 종단 장치에서 데이터 샘플을 수신하는 서비스형 함수 요소 같은 경량 서비스가 될 수 있다.
• 데이터 싱크: 모든 처리 단계(필터)를 통과한 후에 데이터가 도달하는 최종 목적지 를 말한다.
  • 내부 데이터베이스 또는 분산 파일 시스템 혹은 내부 시스템을 구독(리스닝)하는 외부 서비스를 이야기 할 수 있다.

주의: 데이터 전체가 반드시 파이프를 통해 흘러야 하는 것은 아니다.

 

---

파이프-필터 사용 이유

 

 

파이프-필터 패턴은 각 처리 컴포넌트에 필요한 만큼 인스턴수 수를 쉽게 늘리면서 다른 경량 처리 유닛에 대해서는 비용을 절감 할 수 있으며, 여러 대의 컴퓨터에서 독립된 태스크를 병렬로 실행하여 처리량을 높일 수 있다는 것이다.

 

모놀리식 접근 방식을 적용할 경우 발생할 수 있는 문제점들

 

1. 서로 다른 처리 컴포넌트 간의 강한 결합이 발생한다.
2. 각각의 컴포넌트들은 하나의 애플리케이션의 일부이므로 모두 같은 언어로 구현되어야 한다.
3. 각 처리 태스크를 효율적으로 처리할 수 없다.(각 태스트가 필요로 하는 최적의 하드웨어 적용이 불가능하다.)
4. 컴포넌트 별로 요구하는 하드웨어 수준이 다를 수 있다. 특정 컴포넌트(태스크)는 머신 러닝에 특화된 하드웨어가 필요할 수 있으며, 다른 컴포넌트는 CPU 코어가 많이 필요하거나 많은 메모리가 필요 할 수 있다.
5. 성능 및 인프라 비용 측면에서 비효율적이다.
6. 독립적으로 배포된 컴포넌트로 애플리케이션을 분리하면, 각 작업 환경에 따른 최적의 환경을 구축할 수 있다. 각 컴포넌트에 적합한 언어로 개발이 가능하며, 필요로 하는 하드웨어 사양에 최적화 할 수 있다. 뿐만아니라, 각 처리에 필요한 컴포넌트 인스턴스만을 확장하여, 전체를 확장하는 비용보다 더 적은 비용으로 처리량을 높일 수 있다.

 

---

주요 고려사항

 

파이프-필터 아키텍처를 유지하기위해서는 상당한 수준의 오버헤드와 복잡도가 증가하게 되어, 이를 적용하기 이전에 다음 사항을 고려해보는 것이 좋다.

 

파이프-필터 아키텍처를 통해 얻는 이점과 오버헤드 사이의 균형은 어떠한가?

세분화된 필터일수록 오버헤드와 복잡도 는 증가하기 때문에, 파이프-필터 아키텍처를 적용경우의 이점의 균형 을 잘 따져보아야한다.

• 필터의 모듈화와 분리를 통해 유지보수 측면에서의 장점이 존재하나, 지나치게 세분화 될 경우 코드베이스가 복잡해지고, 오히려 유지보수성이 떨어질 수있다.

모든 필터는 Stateless 인가?

기본적으로 모든 필터는 분리되어있기 때문에 상태를 갖을 수 없다. 이는 각각의 필터가 독립적으로 동작하며 상태를 공유하지 않음을 의미한다. 이와 관련하여, 각 필터는 태스크를 수행하기 위해 충분한 정보를 주고 받을 수 있어야 한다.

 

파이프라인 내 모든 작업은 단일 트랜잭션이 필요한가?

만약 단일 트랜잭션으로 수행해야할 경우, 이 패턴은 좋은 선택지가 될 수 없다.

• 분산 트랜잭션을 수행하는 것은 매우 어렵고 비효율적이다.
• 중단(실패)과 재개가 자주 발생한다면, 더 비효율적(비적합)이다.

이러한 단일 트랜잭션 필요성은 파이프-필터 아키텍처가 적합한지를 결정하는 중요한 기준 중 하나이다.