🥱2022.02.11

일일 회고 9회차

할일 및 한일

• 배터리 관제 시스템 백엔드 아키텍처 설계

경험 및 배움

배터리 관제 시스템 백엔드 아키텍처 설계

현재 배터리 관제 시스템의 백엔드 기술 스택으로 Spring WebFlux 와 JooQ 를 사용하고 있다.

WebFlux? JooQ? - WebFlux : non-blocking과 reactive stream을 지원하는 reactive-stack web framework이다. - 논블로킹과 함수형 프로그래밍을 지원한다. - JooQ(Java Object Oriented Query) : 데이터베이스에 저장된 테이블을 기반으로 Java 코드를 생성하고, 코드를 통해 Type Safe한 SQL 쿼리를 작성할 수 있도록 하는 라이브러리이다. https://docs.spring.io/spring-framework/docs/5.2.6.RELEASE/spring-framework-reference/web-reactive.html#webflux-new-framework

https://www.jooq.org/

위와 같은 비동기 프레임워크와 쿼리 지향 라이브러리를 사용하는 이유는 배터리 관제 시스템 의 요구사항을 해결하기 위함이며, 요구사항은 다음과 같다.

1. 약 30,000 대의 배터리로부터 초당 한 건의 데이터를 수신해야한다. => 30,000 TPS

2. 배터리로부터 수신된 데이터를 기반으로 통계 및 시각화를 해야한다. => 복잡한 쿼리 필요

이처럼 대용량 트래픽을 수용하고 복잡한 쿼리를 작성하기 위한 백엔드 기술 스택을 선정하게 되었다.

이러한 기술 스택으로 백엔드를 개발하던 도중 WebFlux와 JooQ를 같이 사용하면 트랜잭션 처리가 되지 않는 것을 발견하여, 어떻게 진행할지 회의를 진행했다. 회의한 후 '트랜잭션이 중요한 도메인과 그렇지 않은 도메인을 분리하자' 라는 결과가 도출되어 백엔드 팀원 각자 아키텍처를 설계해 오기로 했다.

그래서 나는 아키텍처에 대해 고민하던 도중 배달의 민족과 같은 회사는 어떤 아키텍처를 채택해서 운영하고 있는지 궁금증이 생겨, 유튜브에 올라와 있는 '배달의 민족 마이크로서비스 여행기' 라는 영상을 보고 정리하게 되었다.

[우아콘2020] 배달의민족 마이크서비스 여행기

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.Notion

유튜브 영상을 정리한 Notion 페이지

위의 영상을 통해 마이크로서비스와 CQRS를 도입하는 일련의 과정에 대해 배울 수 있었고, 굳이 대규모 시스템이 아니라면 마이크로서비스를 적용하는 것이 오버 엔지니어링이라는 것에 대해 알 수 있었다.

그 후 나는 다음과 같이 배터리 관제 시스템 의 아키텍처를 설계하였다.

배터리 관제 시스템 아키텍처

배터리 관제 시스템 구성요소 - BMS : 배터리 현재 상태를 센싱해서 서버로 전송하는 디바이스 - Edge Server : 배터리 데이터를 전송받아 전처리 후 백엔드 서버로 전송하는 엣지 서버 - 대량의 BMS의 데이터 전송을 분산시킬 수 있다. - Kafka : 배터리 데이터를 전달하는 메시지 큐 - 엣지 서버가 메시지큐에 데이터를 전송하기 때문에 비동기 처리가 가능하다. - REST API 방식보다 프로토콜에 의한 오버헤드가 적다. - Core Application : 모든 도메인의 생성/조회/수정/삭제를 담당한다. - Analytics Application에게 필요한 데이터는 생성/수정/삭제가 발생했을 때 이벤트 기반으로 Kafka를 통해 전달한다. - Analytics Application : 대량의 배터리 상태 정보 및 통계 정보를 빠르게 응답하는 역할을 한다. - 최근 배터리 상태 정보나 통계 정보를 Redis를 통해 캐시한다.

위와 같이 아키텍처 설계를 마치고, 프로젝트 미팅때 발표를 진행했다. 미팅에서 여러 질문을 받았는데, 그중 하나는 Core Application이 Analytics Application에게 이벤트를 Kafka를 전송할 정도로 이벤트 수가 많은지에 대한 질문이였다.

나는 이 질문에 대해 답변을 제대로 하지 못 했다. 왜냐하면 배터리 관제 시스템의 사용자는 회사 관계자이거나 배터리를 구매한 업체측 관계자이기 때문에 Core Application에 생성/수정/삭제에 대한 요청이 적을 것으로 예측이 되어 굳이 Kafka를 사용하지 않아도 될것 같았기 때문이다.

이처럼 아키텍처를 설계할 때 많은 것을 고려해야 하는 것을 알게 되었고, 조금 더 디테일하게 고민을 해서 다시 설계를 하기로 결정했다.

개선 및 목표

• 오늘은 아키텍처를 설계하는데 많은 시간이 들었으며, 미팅 시간이 생각보다 길어져 할려 했던 업무 및 공부들을 거의 진행하지 못 했다. 하지만 오늘은 많은 것을 배웠기 때문에 할려 했던 것을 못한 것에 대해 자책하지는 않는다.

• 배터리 관제 시스템의 아키텍처를 다시 깊게 고민하여 설계해볼 것이며, 설계할 때 인증과 데이터베이스 복제 및 샤딩에 대해서도 고려할 예정이고, 왜 이렇게 설계했는지에 대한 이유도 준비할 예정이다.