EAI 시스템에서 동적 배포(Dynamic Deployment)

✅ EAI 동적 배포를 위한 추천 아키텍처

💡 핵심 개념

“하나의 거대한 EAI 플랫폼”이 아닌, **작은 모듈(EAI Unit)**들이 상황에 따라 독립적으로 배포/확장/재시작/격리될 수 있어야 함.

---

🧱 추천 아키텍처 구성도

[External Systems]
     │
     ▼
[API Gateway / Ingress]
     │
     ▼
[Routing Service (Dynamic Dispatcher)]
     │        ┌──────────────────────────────┐
     │        │ EAI Unit 1 (SAP Adapter)     │ ◀─┐
     │        │ EAI Unit 2 (Oracle Adapter)  │ ◀─┼──▶ Pod 형태로 개별 배포
     │        │ EAI Unit 3 (Webhook Engine)  │ ◀─┘
     ▼
[Kafka / Redis / SQS] (Event Backbone)
     │
     ▼
[Logging / Retry Queue / Dead-letter]
     │
     ▼
[Monitoring + Dynamic Orchestrator (optional)]

---

🧩 구성 요소 설명

 

컴포넌트	설명
API Gateway	외부 요청의 인증, 버전 분리, 트래픽 제어
Routing Service	요청 내용을 보고 적절한 EAI Unit으로 라우팅
EAI Unit (Adapter)	SAP, Oracle, HTTP 등 시스템별 연동 로직 담당. 독립 배포 가능
Kafka/Redis	동기/비동기 메시지 처리용 중앙 백본
DLQ / Retry Manager	장애 시 재시도, 실패 로깅 등 처리
Orchestrator	(옵션) 단일 서비스에 모든 연동 기능을 배치하지 않고 단계별 기능 정의 + 동적 호출

 

---

⚙️ 기술 스택 예시 (Spring 기반)

 

기능	기술
EAI Unit	Spring Boot (REST, WebFlux), OpenAPI 기반
동적 라우팅	Spring Cloud Gateway, Istio, Envoy
동적 배포	Kubernetes + Helm + ArgoCD
메시징	Kafka, Redis Streams
모듈 정의	OpenAPI spec 기반 각 EAI 모듈 생성
구성 관리	Consul, Spring Config Server

 

---

🌟 동적 배포 전략 (실제 적용 방식)

전략예시

모듈별 JAR 또는 컨테이너화	eai-sap-adapter.jar, eai-fx-adapter.jar 등으로 나눔
Helm 또는 GitOps로 배포	새 연동 모듈 추가 시 eai-hrms-adapter만 배포 가능
EAI Dispatcher의 동적 등록 구조	새 모듈이 뜨면 /register-adapter 호출로 등록
CI/CD 연동	GitHub Action → Docker → K8s Helm Chart 배포 자동화
각 Adapter는 Stateless + Retry 내장	재처리나 지연 전송은 Kafka 또는 Redis Queue로

 

---

✅ 장점 요약

항목설명

유연성	모듈 단위 배포 가능 (1개 장애 시 전체 영향 없음)
확장성	EAI 모듈 개수 제한 없이 동적 등록
장애 격리	장애 발생 시 해당 adapter만 교체/확장 가능
운영 편의성	API / 메타 기반 라우팅 + 로깅/모니터링 통합

 

---

🚨 유의할 점

• 이벤트 백본(Kafka/Redis)은 반드시 HA로 구성
• EAI Unit은 Stateless 구조로 설계 (Session 없음)
• Config Server 기반으로 동적 환경변수 주입 고려
• API 보안 정책 (JWT/OAuth) 공통 필터로 처리