Intro

시스템(인프라)이 뒷받침되지 않는다면
우리는 일직선 고속도로를 두고도 돌부리 고갯길로 돌아가야 한다.

TL;DR

지금 이 상황은 그냥 솔루션 구멍이야
EAI를 사용하면 될 걸 한참을 돌아서 가고 있다고!!

EAI를 사용하면

• 애플리케이션들끼리 FeigntClient 등으로 통신할 수고를 던다.
• 호출할 애플리케이션 서버에서 오류가 생겨도 사용하는 우리 애플리케이션은 영향을 받지 않는다.
• 데이터를 가져오는 방식이 단순해진다.

Problem

회의 도중에 타 시스템에서 view를 통해서 데이터를 가져오는 방식에서 csv로 파일을 내려서 가져오는 방식으로 인프라팀이 요청했다는 안건이 있었는데,
그 때 EAI를 시니어가 대안으로 잠깐 언급했었다.

시스템들끼리 서로 데이터를 주고받는 방식이 너무 꼬여 있다.
아래 그림의 AS-IS가 딱 이 프로젝트 상황임.

출처 https://velog.io/@ryuhyewon/EAI란-무엇인가

EAI가 주는 이점

EAI를 사용하면 우리가 타 시스템들과 직접 API로 통신하지 않고 EAI를 바라보면 된다.

변경 감지 및 자동 데이터 업데이트

예를 들어 A,B,C 시스템이 있다고 했을 때, A 시스템에 변경이 일어나면 EAI는 자동으로 변경을 감지해서 EAI 데이터를 갱신한다. A 시스템을 사용하는 B,C 시스템은 영향없이 기존처럼 EAI에서 데이터를 가져다 쓰면 된다.
B가 A,C 2개 시스템을 쓴다고 해도 복잡도는 크게 늘어나지 않는다. 만약 이게 Feign이었다면 별도의 인터페이스를 파서 또 통신을 하겠지.

복잡한 구조에 API 통신이 최선의 방법인가?

사실 모놀리식 아키텍처라면 통 DB 하나니까 모든 데이터를 거기서 그냥 가져오면 된다.
하지만 현재 프로젝트처럼 회사 시스템들끼리 DB가 나뉘고 또 스키마만 특정 pub** 기준으로 나뉘어서 가뜩이나 복잡한데 데이터를 CRUD하기 위해서 개별로 API 인터페이스를 생성해서 정녕 이렇게 해야 했을까?

프로세스의 단순화

딱 봐도 EAI를 사용하는 쪽이 프로세스가 훨씬 단순해졌다.
우리는 타 시스템들의 데이터를 가져와서 대시보드를 구성하기 위해서 원시 데이터를 직접 다 Spring Batch로 가지고 와서 이를 가공하고 또 3차 테이블에 맞게 평균/집계를 구해서 3차테이블에 넣어주는 것까지 해야 했는데,
EAI 있으면 그냥 가져와서 집계/평균 구해서 넣어주면 그만이었다. 원시데이터 다 가져오려고 고생할 필요도 없고, 또 인프라 제약으로 VIEW를 회사들끼리 협의하고 하는 과정이 생략되었을 것이다.

영향도 축소와 오류 감소

만약에 예상치 못한 이유로 A 애플리케이션 서버가 죽었다면?
실제로 우리 시스템은 A 애플리케이션 서버가 모종의 이유로 죽으면 해당 기능은 데이터베이스 관계없이 그냥 오류를 표시해야 했다. 그저 순수 조회임에도 불구하고.

모종의 이유는 인프라팀의 점검이라든지, 아니면 예상치 못하게 POD가 죽었다든지, 내부적으로 오류가 있었다든지 등이 있겠지만, 화면상으로 오류여서 이슈로 올라오면 ArgoCd로 확인하고 정정한 적이 많았다.
EAI를 썼었다면 타 애플리케이션의 오류 혹은 timeout 같은 케이스가 우리 시스템에 영향을 미치지 않았을 것이다.

Warn

EAI랑 MSA는 좀 다른 개념이다. 둘을 연관지어서 생각하지는 말기.

Outro

이번 프로젝트는 대규모에 비해 개발에 필요한 솔루션 도입들이 다 누락되었다.
나름 POD를 구성해서 MSA 기반으로 간다는 흐름이었는데, 정작 개발에 필요한 솔루션들이 누락되었다는 것은 개발에 큰 어려움이었다.