동기화 시스템(echo system) 회고 2
동기화 시스템(echo system) 회고 1
동기화 시스템(echo system) 회고 2
동기화 시스템(echo system) 회고 3
동기화 시스템(echo system) 회고 4
동기화 시스템(echo system) 회고 5
동기화 시스템(echo system) 회고 6
echosystem을 구상하며 가장 중요하게 생각했던 점은 아래와 같습니다.
1. 각자의 서비스에 해당하는 프로세스를 직접 관리.(당연하지만, 당연하지 않았던)
2. 백오피스에서 발행하는 이벤트를 자유롭게 구독하고, 각자의 프로세스에서 필요한 형태로 데이터를 처리.
3. 장애 발생, 작업 시 타 서비스와 관계없이 대응.
이벤트 메시지 프로토콜 설계를 하며 가장 우려되는 점은 이 프로세스가 잘 동작할까에 대한 문제가 아니라, 각 팀과 서비스에서 수용해 줄까였습니다.
설득
아이디어를 제안했을 당시에 저는 입사한 지 약 5년 차였고, 연구소 내 수십 명의 선/후배 동료들을 설득해야 했습니다.
1. 각 서비스에서는 장애나 시스템 관련 작업에서 더 자유로워질 수 있다.
2. 장애 인지, 추적하기가 비교적 쉬워진다.
3. 타 서비스에 혼재하던 프로세스를 독립적으로 분리하고, 구분하게 되어 업무 이해도가 증가하며, 대응 속도가 빨라진다.
4. 리팩토링을 자유롭게 할 수 있다.(개인적으로 제일 절실한 내용)
5. 서비스 간의 영향 범위가 줄어들어 가용성과 안정성이 증가한다.
이외에도 세미나, 회의 등을 통해 직/간접적으로 왜 이런 구조로 변경해야 하는지와 그로 인해 얻어지는 각 서비스 담당자들의 장점들을 지속적으로 전달했습니다.
마침내, 각 팀장님들과 서비스 담당자분들이 바쁜 와중에도 프로세스 이관 및 컨슈머 작업 등을 기꺼이 지원해 주셨습니다. 그 양이 어느 정도였냐면, 백오피스 소스의 전체 양이(용량 기준으로) 약 40% 정도가 줄었고, 연구소 전체 담당자가 작업 대상에 포함되었으며, 1차와 2차로 나눠 약 18개월간의 작업으로 진행되었습니다.
단순히 이벤트 처리뿐만 아니라, 각 서비스에서 사용하는 기술 스택과 프로세스로 이관해서 개발해야 했고, 키만 전달되는 구조이기 때문에 이 외 부가적으로 필요한 정보를 제공할 수 있는 API까지 개발해야 했습니다. 프로세스 자체적으로 이관이 어려운 경우 개별 DB에 테이블을 생성해서 저장하는 등의 수많은 추가 작업도 있었습니다.
구현
위 그림과 같이, 기존 주요 로직 처리 이후 타 서비스 로직을 동기적으로 처리하여, 타 서비스 작업에 문제가 발생하면 백오피스의 동작들도 모두 롤백되거나, 응답 없음 등 제어할 수 없는 오류가 발생하는 문제가 있었고, 전체 처리 속도도 점차 느려지게 되었습니다.
주요 로직만 처리 후 commit까지 한 상태에서 이벤트를 전달하여 타 서비스가 처리할 수 있는 구조로 변경했습니다.
이 과정에서 검토된 대기열은 Kafka였습니다.
Kafka는 프로듀서와 컨슈머를 완전히 분리할 수 있고, 멀티 프로듀서와 멀티 컨슈머 형태는 물론 문제 발생 시 디스크에 데이터를 저장하는 등 우리가 원하는 모든 조건에 충족했습니다.
필자는 docker나 vm에라도 소규모로 구현하여 운용하는 방안을 제안했지만, 아직 echosystem 자체의 프로세스 검증이나 타 서비스의 작업이 진행되기도 전에, Kafka를 구축하고 운용하기는 오버스펙이며 시기상조라는 의견이 있었고, 사내에는 docker가 적극 도입되기도 전 이어서 넘어야 할 산이 많았습니다.
아울러 2017년 echo system 도입 당시 기존 java 프로세스 대신 springboot를 도입하고 버전을 올리는 등 지나치게 한 번에 많은 기술에 대한 학습 부담을 줄 수 있다는 우려도 있었고, 백오피스에서 발생한 이벤트 발생량의 예상 수치는 1일 기준 10만건 미만으로 대단히 적을 것으로 예상했습니다.
동기화 시스템(echo system) 회고3으로 이어집니다.