Electron, React, gRPC로 Cross Platform Application 설계하기

QueryPie 개발기 #6: QueryPie 아키텍처 구성

Brant Hwang
QueryPie
9 min readFeb 17, 2019

--

눈에 보이는 하나의 제품을 만들기 위해서는 수 많은 부분에서 보이지 않는 손길이 필요합니다. 특히 소프트웨어를 개발하는 데 있어서는 무엇을 만들 것인지도 중요하지만 어떻게 구현할지가 더 중요한 요소가 되곤 합니다.

앞선 두 개의 포스팅(#1 맘에 쏙 드는 Database IDE를 찾아서, #2 QueryPie 새롭게 제안하는 SQL IDE)에서 언급한 것처럼 QueryPie는 Mac, Windows, Linux의 3가지 운영체제에서 동작하는 데이터베이스 IDE입니다. 그리고 QueryPie Protocol로 데이터베이스 보안 솔루션을 지원할 뿐 아니라 추후에는 웹에서 누구나 데이터를 분석하고 시각화 할 수 있는 B.I(Business Intelligence)까지 가능한 통합 데이터 플랫폼을 계획하고 있습니다.

이렇게 다양한 기능을 하나의 솔루션으로 지원할 계획이었기 때문에 개발을 시작하기에 앞서 소프트웨어의 구성과 설계가 매우 중요했습니다.

사용자 PC/Laptop에 설치하여 사용하는 애플리케이션의 경우 다중 운영체제 컴파일과 런타임을 지원하는 프로그래밍 언어가 필수적이었고, 더해서 편리하면서 뛰어난 UI/UX를 제공하기 위해 UI Framework 또한 매우 중요한 요소였습니다.

그래서 저를 포함한 개발팀 모두는 회사 내 보유하고 있는 기술역량 및 경험 그리고 위에서 언급한 중장기 제품 로드맵등을 종합적으로 고려했고, 이 글은 QueryPie가 어떤 기술을 기반으로 개발되고 있는지에 대한 이야기를 다루고 있습니다.

1. QueryPie UI (Front-end) : Electron, TypeScript, React

Electron

Electron은 Mac, Windows, Linux 에서 동작하는 데스크탑 애플리케이션 개발이 가능한 프레임워크 입니다. 오픈소스이며 비즈니스 로직을 JavaScript(또는 TypeScript)로 개발하며 UI/UX영역은 높은 확장성과 뛰어난 시각적 구현이 가능한 HTML/CSS로 개발합니다. 게다가 NodeJS와 NPM 생태계를 그대로 쓸 수 있기 때문에 다양한 라이브러리를 통해 개발 확장성을 확보할 수 있다는 장점이 있습니다.

또한 이미 많은 사용자를 보유하고 있는 VSCode, Skype, Slack, Atom 등의 제품은 Electron의 완성도와 안정성을 담보해주기도 합니다.

2. QueryPie Engine (Back-end) : OpenJDK & Java & JDBC

OpenJDK 기반의 Java와 JDBC 라이브러리

Front-end를 Electron으로 결정했기 때문에 NodeJS를 기반으로 한 Back-end도 고려했지만 (1) Node의 Database Connectivity Library가 JDBC만큼 성숙되지 않았다는 점과 (2) 동시 SQL 실행, Data Export/Import등의 핵심적인 기능을 안정적으로 구현하기 위해서는 Java Eco System이 적합하다는 점을 고려하여 애플리케이션 Back-end 영역은 OpenJDK 기반의 Java와 JDBC 라이브러리를 활용하기로 했습니다.

3. Communication between Processors : gRPC

다음으로 Front-end와 Back-end는 별도의 프로세서로 분리 실행되기 때문에 두 프로세서 간의 안정적인 통신이 필요합니다. 일반적인 웹 애플리케이션에서는 HTTP/Web Socket을 통해 통신을 하지만, QueryPie는 사용자 로컬 머신에서 동작하고 애플리케이션 특성 상 빠른 응답과 안정적인 통신이 필수적이기 때문에 TCP/IP기반의 RPC Framework인 gRPC를 선택했습니다.

grpc에 대한 이미지 검색결과
gRPC Workflow (https://www.slideshare.net/shijucv/building-high-performance-apis-in-go-using-grpc-and-protocol-buffers)

gRPC는 구글에서 오픈소스로 공개한 RPC Framework로 구글 Protocol Buffer기반 Binary Protocol을 통해 데이터를 전달합니다. Protocol Buffer는 구조화된 데이터를 직렬화하는 방식 중 하나로, Proto라는 IDL(Interface Description Language)을 정의하면 다양한 언어로 직렬화 가능한 모델을 자동 생성해주기 때문에 상호 간에 어떤 데이터를 주고 받을지에 대해서 별도의 문서 없이도 쉽게 이해할 수 있습니다.

Google Protocol Buffer (https://blog.grijjy.com/2017/04/25/binary-serialization-with-google-protocol-buffers/)

4. Overall Architecture

Electron, Java, JDBC, gRPC를 통해 QueryPie의 전체적인 아키텍처를 다음과 같이 구성했습니다.

QueryPie Overall Architecture

5. Engine Exception Handler: Error Tracking

제품 개발단계에서 아무리 높은 테스트 커버리지와 꼼꼼한 Q/A를 했다하더라도 제품을 사용하는 고객의 하드웨어,OS,OS Patch 등 모든 환경을 완벽하게 테스트하는데는 현실적인 어려움이 따릅니다. 따라서 발생하는 에러를 빠르게 감지하고 재현하여 해결하는게 무엇보다 중요합니다.

Engine 개발에 있어 가장 신경 쓴 부분 중 하나는 제품에서 에러가 발생하면 회사 내부 환경에서 100% 재현하거나 빠르게 파악할 수 있도록 Engine 전역에서 발생하는 에러를 정확하고 상세하게 기록하는 부분입니다.

Engine에서 발생하는 모든 에러에 대해 사용자의 어떤 행동이 영향을 미쳤는지, 당시 상황은 어땠는지를 상세하게 추적하기 위해 gRPC Interceptor, SLF4J MDC, Logback Custom Appender를 이용했습니다.

앞서 아키텍처에서 설명한 것처럼 사용자의 행동이나 요청을 처리하기 위해 QueryPie Middleware는 gRPC를 통해 필요한 데이터를 Engine에 요청합니다. 이 때 Middleware가 어떤 gRPC Endpoint를 호출했는지를 추적하기 위해 gRPC Interceptor에서 API Request 정보를 항상 MDC에 기록하도록 해두었고, 이 정보는 에러가 발생하면 Logback Appender에서 로그를 기록할 때 꺼내오도록 되어 있습니다.

Engine 에러 발생 과정 추적

또한 모든 에러 로그를 빠짐없이 추적하기 위해 ROOT Appender에 QueryPieLogAppender를 추가하여 SLFJ4를 통해 찍히는 모든 log.error()에 대해 기록하도록 되어 있습니다. 이 에러 로그 정보는 사용자의 동의를 통해 서버로 전송되고, 서버에서는 해당 로그 데이터를 기반으로 빠르게 에러를 발견 및 재현하여 문제점을 해결하게 됩니다.

6. Application Performance Monitoring: Skywalking

마지막으로 애플리케이션의 성능 측정이 남았습니다. 이 부분은 개발 과정에서부터 애플리케이션의 성능 측정을 시작하면 개발이 완료된 후에 한번에 추적하는 것보다 훨씬 수월하기 때문에 미리 구상해두었습니다. 또한 QueryPie에 있는 기능 중에 개발할 때는 잘 느끼지 못했지만 실제 테스트를 해보면 응답이 느리거나 혹은 기대했던 것보다 훨씬 긴 작업이 될 수 있는 가능성이 있는 것들이 있어서 개발 과정에서부터 APM 동작을 고려하는 것이 필요했습니다.

우선 모든 개발자가 로컬에서 APM이 연동된 Engine을 띄우면 정확한 메트릭을 파악할 수 없을것 같아, Remote 서버에 Engine을 구동시키고 해당 Engine은 APM과 함께 실행되도록 구성했습니다.

QueryPie Remote Engine

위의 그림과 같이 Git Push가 발생하면 Jenkins는 자동으로 Engine을 빌드한 후 리모트 서버에 배포하고 재시작 합니다. 따라서 Front-end와 Middleware 개발자는 로컬에 Engine을 실행할 필요 없이 Remote Engine에 접속해서 개발을 진행할 수 있으며, 개발되는 과정에서 테스트 및 실행했던 기록이 모두 APM 데이터베이스에 기록됩니다. 여기에서는 여러 APM 중 간단한 설치와 깔끔한 UI, 토폴로지 맵, gRPC 지원 및 실행시간 추적이 가능한 Sky Walking이라는 Apache Incubation Project를 사용했습니다.

Sky Walking 내 EndPoint 별 Response Time을 알려주는 기능
토폴로지 맵을 통해 어떤 곳으로 요청이 많이 전달되는지 분석 가능

이렇게 APM 적용을 통해 병목구간을 개발단계에서 분석해서 빠르게 찾고 이를 개선할 수 있는 효과적인 방법들을 지속적으로 고민하고 있습니다. 그리고 이런 과정들을 통해 제품이 사용자에게 전달되었을 때 높은 품질과 뛰어난 성능으로 동작할 수 있기를 기대하고 있습니다.

마치며

QueryPie는 뛰어난 여러 엔지니어들이 적합한 기술로 주춧돌을 세우고 어떻게 사용성을 높일지, 또 기존 사용자가 불편해하던 문제점을 어떻게 해결할 수 있을지를 매일 매일 고민하며 살을 붙여가고 있습니다. 어느덧 꽤 많은 핵심 기능들이 자리를 잡았고, 사내에서는 쓸 수 있을만큼의 제품 기능이 완성되었습니다. 세계 최고의 데이터베이스 도구가 되기위해 QueryPie는 오늘도 개발되고 또 개발되고 있습니다. 조금만 기다리세요!

📑영어(English Version)- https://medium.com/p/c13a429b5346/

--

--