> For the complete documentation index, see [llms.txt](https://jimmyblog.gitbook.io/jimmys-blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jimmyblog.gitbook.io/jimmys-blog/jimmys-log/daily-log-2022/2022.02.11.md). # 2022.02.11 일일 회고 9회차 ## 할일 및 한일 * [x] `배터리 관제 시스템` 백엔드 아키텍처 설계 ## 경험 및 배움 ### `배터리 관제 시스템` 백엔드 아키텍처 설계 현재 배터리 관제 시스템의 백엔드 기술 스택으로 `Spring WebFlux` 와 `JooQ` 를 사용하고 있다. {% hint style="info" %} ***WebFlux? JooQ?***\ \ \- `WebFlux` : non-blocking과 reactive stream을 지원하는 reactive-stack web framework이다.\ \- 논블로킹과 함수형 프로그래밍을 지원한다.\ \ \- `JooQ(Java Object Oriented Query)` : 데이터베이스에 저장된 테이블을 기반으로 \ Java 코드를 생성하고, 코드를 통해 Type Safe한 SQL 쿼리를 작성할 수 있도록 하는 라이브러리이다.\ \ {% endhint %} 위와 같은 **비동기 프레임워크**와 **쿼리 지향 라이브러리**를 사용하는 이유는 `배터리 관제 시스템` 의 요구사항을 해결하기 위함이며, 요구사항은 다음과 같다. 1. 약 30,000 대의 배터리로부터 초당 한 건의 데이터를 수신해야한다. => **30,000 TPS** 2. 배터리로부터 수신된 데이터를 기반으로 통계 및 시각화를 해야한다. => **복잡한 쿼리 필요** 이처럼 대용량 트래픽을 수용하고 복잡한 쿼리를 작성하기 위한 백엔드 기술 스택을 선정하게 되었다. 이러한 기술 스택으로 백엔드를 개발하던 도중 WebFlux와 JooQ를 같이 사용하면 **트랜잭션 처리가 되지 않는 것**을 발견하여, 어떻게 진행할지 회의를 진행했다. 회의한 후 **'트랜잭션이 중요한 도메인과 그렇지 않은 도메인을 분리하자'** 라는 결과가 도출되어 백엔드 팀원 각자 아키텍처를 설계해 오기로 했다. 그래서 나는 아키텍처에 대해 고민하던 도중 배달의 민족과 같은 회사는 어떤 아키텍처를 채택해서 운영하고 있는지 궁금증이 생겨, 유튜브에 올라와 있는 **'배달의 민족 마이크로서비스 여행기'** 라는 영상을 보고 정리하게 되었다. {% embed url="" %} \[우아콘2020] 배달의민족 마이크서비스 여행기 {% endembed %} {% embed url="" %} 유튜브 영상을 정리한 Notion 페이지 {% endembed %} 위의 영상을 통해 **마이크로서비스와 CQRS를 도입하는 일련의 과정**에 대해 배울 수 있었고, 굳이 **대규모 시스템이 아니라면 마이크로서비스를 적용하는 것이 오버 엔지니어링**이라는 것에 대해 알 수 있었다. 그 후 나는 다음과 같이 `배터리 관제 시스템` 의 아키텍처를 설계하였다. ![배터리 관제 시스템 아키텍처](https://3387573177-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVUGmlfST1Av763oCpLBq%2Fuploads%2FUs3A6LuxDrPBRZaKY5oV%2Fimage.png?alt=media\&token=5df7aed8-d492-4c69-aa7f-d9c7be715c58) {% hint style="info" %} ***배터리 관제 시스템 구성요소***\ \ \- `BMS` : 배터리 현재 상태를 센싱해서 서버로 전송하는 디바이스\ \ \- `Edge Server` : 배터리 데이터를 전송받아 전처리 후 백엔드 서버로 전송하는 엣지 서버\ \- 대량의 BMS의 데이터 전송을 분산시킬 수 있다.\ \ \- `Kafka` : 배터리 데이터를 전달하는 메시지 큐\ \- 엣지 서버가 메시지큐에 데이터를 전송하기 때문에 비동기 처리가 가능하다.\ \- REST API 방식보다 프로토콜에 의한 오버헤드가 적다.\ \ \- `Core Application` : 모든 도메인의 생성/조회/수정/삭제를 담당한다.\ \- Analytics Application에게 필요한 데이터는 생성/수정/삭제가 발생했을 때 이벤트 기반으로\ Kafka를 통해 전달한다.\ \ \- `Analytics Application` : 대량의 배터리 상태 정보 및 통계 정보를 빠르게 응답하는 역할을 한다.\ \- 최근 배터리 상태 정보나 통계 정보를 Redis를 통해 캐시한다. {% endhint %} 위와 같이 아키텍처 설계를 마치고, 프로젝트 미팅때 발표를 진행했다. 미팅에서 여러 질문을 받았는데, 그중 하나는 Core Application이 Analytics Application에게 **이벤트를 Kafka를 전송할 정도로 이벤트 수가 많은지**에 대한 질문이였다. 나는 이 질문에 대해 답변을 제대로 하지 못 했다. 왜냐하면 배터리 관제 시스템의 사용자는 회사 관계자이거나 배터리를 구매한 업체측 관계자이기 때문에 Core Application에 생성/수정/삭제에 대한 요청이 적을 것으로 예측이 되어 굳이 Kafka를 사용하지 않아도 될것 같았기 때문이다. 이처럼 아키텍처를 설계할 때 많은 것을 고려해야 하는 것을 알게 되었고, 조금 더 디테일하게 고민을 해서 다시 설계를 하기로 결정했다. ## 개선 및 목표 * 오늘은 아키텍처를 설계하는데 많은 시간이 들었으며, 미팅 시간이 생각보다 길어져 할려 했던 업무 및 공부들을 거의 진행하지 못 했다. 하지만 오늘은 많은 것을 배웠기 때문에 할려 했던 것을 못한 것에 대해 자책하지는 않는다. * 배터리 관제 시스템의 아키텍처를 다시 깊게 고민하여 설계해볼 것이며, 설계할 때 인증과 데이터베이스 복제 및 샤딩에 대해서도 고려할 예정이고, 왜 이렇게 설계했는지에 대한 이유도 준비할 예정이다.