DevYGwan

저희는 기본적으로 IoT 데이터의 경우 대용량 데이터이기 때문에 NoSQL 기반의 데이터베이스 인 ScyllaDB을 사용하여 데이터를 관리했습니다. 그러다보니 기본적인 데이터 (유저 데이터, 장비 Meta 데이터 등)도 ScyllaDB을 사용해서 개발을 진행했습니다. 하지만 NoSQL이다보니, 정형화 된 데이터와 트랜잭션 처리가 RDB보다 효율적이지 못해 이번에 추가적인 "승인" 도메인을 개발하면서 RDB을 반영하기로 결정했습니다. RDB을 반영하면서 고민한 사항은 크게 3가지 입니다.어떤 RDB을 사용할까?DB 서버가 다른데, 다른 서버 간의 트랜잭션을 관리 할 일이 있을까?백엔드 서버는 어떻게 처리할까? 하나로 가져갈까 DB 별로 분리해서 가져갈까? 이렇게 3가지를 고민했습니다. 고민하고 내린 결과는..

기본적으로 서버에서 IoT 기기들과 통신할 때, MQTT 프로토콜을 사용해서 통신합니다. 이 때 서버와 IoT 기기들끼리 1 : 1 통신을 하는 것이 아닌 중간 중개자인 MQTT Broker에 PUB / SUB 방식으로 통신을 진행합니다. 예를 들어, 서버가 특정 IoT 기기에게 메세지(신호)를 보내고 싶다면, IoT 기기가 구독하고 있는 토픽에 보낼 메세지를 추가하여 MQTT Broker에 Publish 합니다. 그러면, 해당 토픽을 구독하고 있는 IoT 기기가 해당 토픽을 Subscribe 한 후 메세지를 받습니다. 기본적으로 이러한 형식으로 서로 통신합니다. 결국, MQTT Pub-Sub 기반 IoT 제어 및 응답 흐름은,서버는 IoT 기기가 구독하는 특정 토픽에 요청 메시지를 담아 MQTT Bro..

저희 회사는 IoT 디바이스 간의 통신을 MQTT 프로토콜을 사용해서 처리하고 있습니다. 이 때 사용하는 MQTT Broker는 AWS IoT을 사용하고 있습니다. 이번에 처리할 내용이, 저희가 개발하고 있는 Backend 서버에 이 AWS IoT와의 연동을 처리해야 합니다. 그래서 연동을 처리하는 과정에서 생긴 문제와, AWS IoT Core가 어떤건지, 왜 사용했는지 정리하려고 합니다. MQTT BrokerMQTT Broker는 MQTT 프로토콜을 기반으로 하는 메시지 브로커로, 클라이언트 간의 메시지를 중계하는 서버 역할을 합니다. MQTT Broker에는 여러 종류가 있습니다. 크게 클라우드 기반과 오픈소스 기반의 MQTT Broker를 기준으로 정리하자면,클라우드 기반 MQTT BrokerAWS..

이번에는, JWT에 대해서 공부한 것을 공유해보려고 합니다. 기본적으로 JWT는 Json Web Token의 약자로, 데이터를 외부와 주고 받을 때 인증과 권한 부여을 위해 주로 사용합니다. 이번에 JWT Token을 가지고 이를 포함한 QR Code을 생성하여 처리하는 로직을 구현했는데, 이를 구현하면서 단순히 라이브러리를 통해 JWT을 생성하고, 인증하는 과정을 넘어서 JWT의 목적과, 암호화 기법에 대해 공부하게 되어 이를 공유해보도록 하겠습니다.공유에 앞서, 간단하게 JWT을 한번 정리해보도록 하겠습니다. ※  JWT란JWT(Json Web Token)의 약자로, Json 기반의 토큰을 의미한다.JWT는 클라이언트-서버 통신에서 효율적이고 간단한 인증 수단이다.JWT는 크게 세가지 부분으로 나뉘며..

회사에서 IoT 간의 데이터 통신 시스템을 구축할 필요성이 있다고 해 서버에 적용할 필요가 있었습니다. 현재 IoT 데이터는 MQTT라는 프로토콜을 통해 MQTT Broker(AWS IoT)와 연결되어 통신하고 있으며, 이번에 백엔드 서버까지 해당 브로커에 연결되어 IoT 기기와 통신 시스템 구축이 필요하다고 했고 이 파트를 제가 담당하게 되었습니다. MQTT에 대한 기본적인 이해가 잘 되어야 어떤식으로 환경 및 설정을 처리할지 윤곽이 잡히기 때문에 이번 기회에 한번도 경험하지 못한 MQTT 프로토콜이 뭔지 정리하면서, 백엔드 내부 Config 로직까지 정리해보려고 합니다. ※  MQTT란MQTT(Message Queue Telemetry Transport)는 기계 간 통신에 사용되는 표준 기반 메세지 ..

2024년에는 참 많은 일이 있었습니다. 2월에 대학교를 졸업하고 운좋게 3월에 바로 취업에 성공해 새로운 회사와 새로운 좋은 사람들을 만났습니다. 그렇게 3월부터 ~ 10월까지 회사에 다니다가 첫 직장을 퇴사하고 11월에 새로운 도전을 하기 위해 새로운 회사에 취직하여 현재까지 일을 하고 있습니다. 생각해보면, 2024년은 많은 도전을 한 해 였던 것 같습니다. 그래서 이제부터 매 년간 회고록을 작성해보려고 합니다. 시간이 지나도 생각나는 일들이 많겠지만, 그 때 당시의 기분은 지금이 아니면 무뎌지고 생생해지지 않을 것 같을 것 같아서 역시 글로 작성하는게 더 기억에 오래 남을 것 같기 때문입니다. 저의 2024년은 초반 취업을 준비하던 때, 첫 회사인 티맥스를 다닐 때, 티맥스에 퇴사하고 컨포트랩이라..

회사에서 프로젝트를 진행하면서, 프로젝트 초기에 DB 관련 DDL 관리가 힘들다는 것을 느꼈습니다. 프로젝트 초기다보니 DDL 수정이 자주 발생하고, 환경 별로 DB 서버를 다르게 하다보니 DB의 변경사항이 발생했을 때, DB 동기화 작업을 매번 하는 것이 번거로워 개발 생산성 저하로 이어지는 문제가 발생했습니다. 그러다보니 자체적으로 초기에는 DB 환경을 하나로 만들어 개발하는 전략으로 진행했습니다... 하지만 이는 환경 별로 종속성이 생겨 협업에 취약하고 서비스 배포 이후에 큰 문제를 야기할 수 있습니다. 따라서 이러한 문제를 해결하기 위해 방법을 찾아보던 중 Flyway라는 DB 형상관리 툴을 알게 되었습니다. 따라서 이를 적용하려고 겪은 시행착오 경험과 결론적으로 Flyway 공식 레포에 기여를 ..