🥱2022.02.11
일일 회고 9회차
할일 및 한일
경험 및 배움
배터리 관제 시스템 백엔드 아키텍처 설계
배터리 관제 시스템 백엔드 아키텍처 설계현재 배터리 관제 시스템의 백엔드 기술 스택으로 Spring WebFlux 와 JooQ 를 사용하고 있다.
위와 같은 비동기 프레임워크와 쿼리 지향 라이브러리를 사용하는 이유는 배터리 관제 시스템 의 요구사항을 해결하기 위함이며, 요구사항은 다음과 같다.
약 30,000 대의 배터리로부터 초당 한 건의 데이터를 수신해야한다. => 30,000 TPS
배터리로부터 수신된 데이터를 기반으로 통계 및 시각화를 해야한다. => 복잡한 쿼리 필요
이처럼 대용량 트래픽을 수용하고 복잡한 쿼리를 작성하기 위한 백엔드 기술 스택을 선정하게 되었다.
이러한 기술 스택으로 백엔드를 개발하던 도중 WebFlux와 JooQ를 같이 사용하면 트랜잭션 처리가 되지 않는 것을 발견하여, 어떻게 진행할지 회의를 진행했다. 회의한 후 '트랜잭션이 중요한 도메인과 그렇지 않은 도메인을 분리하자' 라는 결과가 도출되어 백엔드 팀원 각자 아키텍처를 설계해 오기로 했다.
그래서 나는 아키텍처에 대해 고민하던 도중 배달의 민족과 같은 회사는 어떤 아키텍처를 채택해서 운영하고 있는지 궁금증이 생겨, 유튜브에 올라와 있는 '배달의 민족 마이크로서비스 여행기' 라는 영상을 보고 정리하게 되었다.
위의 영상을 통해 마이크로서비스와 CQRS를 도입하는 일련의 과정에 대해 배울 수 있었고, 굳이 대규모 시스템이 아니라면 마이크로서비스를 적용하는 것이 오버 엔지니어링이라는 것에 대해 알 수 있었다.
그 후 나는 다음과 같이 배터리 관제 시스템 의 아키텍처를 설계하였다.
위와 같이 아키텍처 설계를 마치고, 프로젝트 미팅때 발표를 진행했다. 미팅에서 여러 질문을 받았는데, 그중 하나는 Core Application이 Analytics Application에게 이벤트를 Kafka를 전송할 정도로 이벤트 수가 많은지에 대한 질문이였다.
나는 이 질문에 대해 답변을 제대로 하지 못 했다. 왜냐하면 배터리 관제 시스템의 사용자는 회사 관계자이거나 배터리를 구매한 업체측 관계자이기 때문에 Core Application에 생성/수정/삭제에 대한 요청이 적을 것으로 예측이 되어 굳이 Kafka를 사용하지 않아도 될것 같았기 때문이다.
이처럼 아키텍처를 설계할 때 많은 것을 고려해야 하는 것을 알게 되었고, 조금 더 디테일하게 고민을 해서 다시 설계를 하기로 결정했다.
개선 및 목표
오늘은 아키텍처를 설계하는데 많은 시간이 들었으며, 미팅 시간이 생각보다 길어져 할려 했던 업무 및 공부들을 거의 진행하지 못 했다. 하지만 오늘은 많은 것을 배웠기 때문에 할려 했던 것을 못한 것에 대해 자책하지는 않는다.
배터리 관제 시스템의 아키텍처를 다시 깊게 고민하여 설계해볼 것이며, 설계할 때 인증과 데이터베이스 복제 및 샤딩에 대해서도 고려할 예정이고, 왜 이렇게 설계했는지에 대한 이유도 준비할 예정이다.
Last updated