목록Study (31)
DevYGwan
저희는 실시간으로 공장에 있는 기기들의 데이터를 수집하고 있습니다. 그러다보니 실시간으로 들어오는 데이터들을 유실 없이 저장해야 합니다. 그래서 저희는 실시간 데이터를 효율적으로 처리하기 위해 아래와 같은 아키텍처를 구현하고 있습니다.간단하게 순서를 설명드리자면,1. 공장 기기 → MQTT Broker공장의 각 기기에서 MQTT 프로토콜로 메시지를 발행하며, 이 메시지들은 모두 MQTT Broker로 전달됩니다. 2. MQTT Broker → Kafka Connect → KafkaMQTT Broker에 들어온 메시지 중 Kafka에서 처리해야 하는 특정 토픽들은 Kafka Connect의 MQTT Source Connector를 통해 Kafka로 전달됩니다. 3. Kafka → Spark Streamin..
공장 같은 곳에 Onprem 서버를 구축할 때 보면 상당히 고려해야 할 점이 많습니다. 대부분 고객들이 Onprem 환경을 원하는 이유는 기기 데이터를 외부에 노출시키고 싶지 않기 때문입니다. 따라서 대부분 환경이 인터넷 연결이 안되어있는 내부망을 사용합니다. 그러다보니 인터넷이 안돼 인터넷이 필요한 작업들은 할 수가 없습니다. 또한, 공장 기기들 때문인지 LTE 라우터를 통해 인터넷 연결을 잠시 하려고 해도 인터넷이 생각보다 잘 되지 않았습니다. 실제로 k8s내의 clickhouse 이미지를 pull 받아 파드 하나를 띄우려했는데... 이미지 pull만 30분이 넘게 걸렸습니다. 그 뒤로는 limit이 걸렸는지 그 이후에 인터넷 연결이 매우 느려진 현상을 확인할 수 있었습니다. ※ 그때 당시 문제 ..
저희는 실시간 공장 기기들의 데이터를 취급하고 있습니다. 데이터는 1초, 10초 등 특정 주기로 한번씩 올라옵니다. 기기 한개를 기준으로 1초에 한번씩 데이터들이 올라온다고 가정하면, 하루동안 24시간 × 60분 × 60초 = 86,400 개의 데이터가 올라옵니다. 물론 사용자는 기기 한개가 아니라 기기 여러개를 관리하고 있을 것이고, 1초, 5초, 10초 등등 특정 주기로 올라오는 데이터가 많아지면 이 데이터는 기하급수적으로 늘어날 것입니다. 저희는 이러한 대용량 데이터를 관리하고 있는데, 이번에 구현해야 할 기능은 특정 범위에 해당하는 데이터를 추출하는 기능입니다. 추출은 csv로 추출합니다. 원래는 csv을 추출할 때, csv을 생성하는 라이브러리(OpenCSV 등)을 써서 단순히 데이터를 조회하고..
저희는 현재 프론트엔드 2개 & 서버 한개로 이루어 진 서비스를 운영 중입니다. 일반 로그인과 소셜 로그인을 둘 다 사용하고 있고 이를 효율적으로 사용하기 위해 Firebase Authenticaion Server을 사용하고 있습니다. 저희가 원래 Firebase을 사용한 이유는Google에서 제공하는 Firebase을 기반으로 한 인증 서버기 때문에 안전하다.여러 소셜 로그인을 쉽게 제공할 수 있다.별도의 서버를 구축할 필요 없이 Google이 관리하는 인프라를 활용 할 수 있어 편하다.등의 장점이 있습니다. 저희는 현재 이 인증 서버에서 전반적인 사용자 인증(아이디, 패스워드), 토큰 발급 & 검증 등의 작업을 위임하고 있습니다. 자체적인 UI 제공 및 프론트 & 백엔드와의 연동 라이브러리가 잘 구축..
저희는 기본적으로 IoT 데이터의 경우 대용량 데이터이기 때문에 NoSQL 기반의 데이터베이스 인 ScyllaDB을 사용하여 데이터를 관리했습니다. 그러다보니 기본적인 데이터 (유저 데이터, 장비 Meta 데이터 등)도 ScyllaDB을 사용해서 개발을 진행했습니다. 하지만 NoSQL이다보니, 정형화 된 데이터와 트랜잭션 처리가 RDB보다 효율적이지 못해 이번에 추가적인 "승인" 도메인을 개발하면서 RDB을 반영하기로 결정했습니다. RDB을 반영하면서 고민한 사항은 크게 3가지 입니다.어떤 RDB을 사용할까?DB 서버가 다른데, 다른 서버 간의 트랜잭션을 관리 할 일이 있을까?백엔드 서버는 어떻게 처리할까? 하나로 가져갈까 DB 별로 분리해서 가져갈까? 이렇게 3가지를 고민했습니다. 고민하고 내린 결과는..