DevYGwan

저희는 실시간 공장 기기들의 데이터를 취급하고 있습니다. 데이터는 1초, 10초 등 특정 주기로 한번씩 올라옵니다. 기기 한개를 기준으로 1초에 한번씩 데이터들이 올라온다고 가정하면, 하루동안 24시간 × 60분 × 60초 = 86,400 개의 데이터가 올라옵니다. 물론 사용자는 기기 한개가 아니라 기기 여러개를 관리하고 있을 것이고, 1초, 5초, 10초 등등 특정 주기로 올라오는 데이터가 많아지면 이 데이터는 기하급수적으로 늘어날 것입니다. 저희는 이러한 대용량 데이터를 관리하고 있는데, 이번에 구현해야 할 기능은 특정 범위에 해당하는 데이터를 추출하는 기능입니다. 추출은 csv로 추출합니다. 원래는 csv을 추출할 때, csv을 생성하는 라이브러리(OpenCSV 등)을 써서 단순히 데이터를 조회하고..

저희는 공장의 여러 기기에서 실시간으로 사용자 데이터를 가져와 관리하는 B2B 서비스를 개발하고 있습니다. 그래서 특별히 장애가 발생하지 않는 한 특정 사용자(공장)의 기기 데이터가 한번에 다 올라오지 않는 경우는 거의 없습니다. 물론, 그 공장이 전체 소등을 한다던가 하지 않는 이상은 말이죠... 그러다보니 특별한 일 없이, 특정 공장의 모든 기기에서 데이터가 만약 올라오지 않는다면 이는 큰 장애로 이어졌을 가능성이 높아 빠르게 처리해야되죠. (일단, 고객보다 먼저 알아서 빠르게 처리할 수 있어야 합니다.) 이를 처리하기 위해 저희는 15분 주기마다 사용자의 기기 데이터들을 조회해서 올라온 데이터가 하나도 없는지 조회하여 없다면 알림을 보내는 로직을 구현해 사용하고 있습니다. 이를 구현하기 위해서 Sp..

저희는 이번에 보고서 생성 로직을 구현했습니다. 저희의 보고서 생성 과정은 대용량 데이터를 조회하고, 이를 LLM 기반으로 분석하여 결과를 도출하는 일련의 절차로 구성됩니다. 이 과정은 DB, FE 서버, BE 서버 등 여러 인프라 자원을 동시에 많이 사용하는 작업입니다. 따라서 다수의 요청이 동시에 발생할 경우, 서버에 과부하가 걸리지 않도록 동시 처리량을 제어할 필요가 있었습니다. 또한, 보고서 생성은 처리 시간이 길고 도중에 실패할 가능성도 존재하기 때문에, 작업이 실패했을 경우 자동 재시작이 가능해야 했으며, 각 요청의 성공 및 실패 여부를 명확히 보장할 수 있는 메커니즘이 필요했습니다. 따라서 정리하자면, 이러한 요구사항을 충족하기 위해 저희가 고려한 사항은 다음과 같습니다.보고서 생성에 많은 ..

저희는 Sentry을 통해 알림 시스템을 연동해서 사용하고 있습니다. 서버에서 로직 상 문제가 발생하거나 에러를 발생하면, Slack과 연동된 Sentry 알림을 통해 바로 알림을 확인할 수 있습니다. 때는, 퇴근하려던 무렵... 갑자기 Sentry에 아래와 같은 알람이 떴습니다. OutOfMemory Error... 갑작스럽게 OOM 에러가 발생해, 전체 서비스가 중단된 문제였습니다. 언제봐도 OOM은 무섭네요... OOM 에러가 발생해 서버를 확인해보니, 서버가 죽어서 아무런 요청 처리도 할 수 없는 상태가 되어 있었습니다. 다행히 저희는 공장 데이터를 관리하고 있는데, 공장의 실시간 데이터는 이러한 서버 장애를 대비하기 위해 서버와 상관 없이 계속 DB에 수집되고 있기 때문에 데이터 유실 문제는..

저희는 현재 프론트엔드 2개 & 서버 한개로 이루어 진 서비스를 운영 중입니다. 일반 로그인과 소셜 로그인을 둘 다 사용하고 있고 이를 효율적으로 사용하기 위해 Firebase Authenticaion Server을 사용하고 있습니다. 저희가 원래 Firebase을 사용한 이유는Google에서 제공하는 Firebase을 기반으로 한 인증 서버기 때문에 안전하다.여러 소셜 로그인을 쉽게 제공할 수 있다.별도의 서버를 구축할 필요 없이 Google이 관리하는 인프라를 활용 할 수 있어 편하다.등의 장점이 있습니다. 저희는 현재 이 인증 서버에서 전반적인 사용자 인증(아이디, 패스워드), 토큰 발급 & 검증 등의 작업을 위임하고 있습니다. 자체적인 UI 제공 및 프론트 & 백엔드와의 연동 라이브러리가 잘 구축..