highlev 님의 블로그

빅데이터 분산 시스템을 구현하면서, 자연스럽게 이런 의문이 들게 되었다.지금 빅데이터 분산 서버가 제대로 동작하고 있는 게 맞나?"빅데이터 분산 서비스에서는, 뉴스가 처음 수집되는 collector부터 마지막 DBWriter까지, 여러 단계를 거쳐서 가공되어 전달된다.이 과정에서 중간에 병목현상이 없는지, 오류가 나서 유실되고 있는 정보는 없는지, CPU 과부하가 발생하고 있지는 않은지 등을 파악할 수 있는 시스템이 필요했다.그래서 우리 서비스에, 프로메테우스, 로키, 그라파나를 두어서 모니터링을 할 수 있도록 해보고자 한다.그전에 이것들이 어떤 역할을 해서 우리 서비스를 모니터링할 수 있는지 배워보자.모니터링을 하기 위해서 우리는 다시 3가지 고민을 해보아야 한다.1. 모니터링 지표를 어떻게 만들어낼까..

이번 포스팅에서는, 지난 2주일간 설계한 파이프라인대로, 우리 서비스의 주재료가 되는 뉴스가, 실제로 어떻게 저장이 되어서 가공 처리가 되어 사용자의 눈에 보이게 되는지 구현해나간 과정을 담겠다.우리 서비스에서는 카프카를 적극적으로 도입하여 파이프라인을 설계했기 때문에, 이번 포스팅에서는 카프카를 위주로 설명을 할 예정이다.전체적인 파이프라인도커 환경에서의 카프카우리 서비스는 도커 환경에서 돌아간다.FROM apache/kafka:4.3.1그렇기 때문에, 아파치에서 제공하는 공식 카프카 이미지를 이용해 컨테이너를 만들었다.외부 포트 연결우리 서비스는 단순히 뉴스를 그대로 받아서 보여주는 게 아니라, 가공처리를 하여 유의미한 데이터를 뽑아내어 사용자에게 보여주는 데에 의의를 둔다.그렇기 때문에 GPU 서버..

최근에 시작한, 전세계 뉴스를 가공하는 플랫폼인 What is the World 프로젝트에서는, 실시간으로 전세계 50개국에서 발생하는 뉴스들을 kafka에 적재를 하고, 분산 처리를 통해 NLP Worker들에게 병렬적으로 작업을 맡겨야한다. 그래서, 뉴스를 수집하고 나서 제일 처음에 발을 들이는 kafka 단계에서 어떤 식으로 뉴스를 받게 되는지에 대해서 정리해보고자 한다.1. Kafka란 무엇인가Apache Kafka는 이벤트 스트리밍 플랫폼이다. 단순히 메시지를 전달하는 데 그치지 않고, 이벤트를 디스크에 보관하고 여러 Consumer가 필요할 때 다시 읽을 수 있게 한다.Kafka의 핵심 특징은 다음과 같다.이벤트를 순차적인 로그 형태로 저장한다.여러 Broker에 데이터를 분산해 처리량과 저장..

이전 글에서는, 웹소켓이 어떻게 작용되는지 간단하게 다뤄보았따.그렇다면, 이번 글에서는 진짜 웹소켓으로 통신이 어떻게 되는지 확인해보도록 하자.우리의 노래방 서비스, ssasukae에서의 한 플로우를 떼와서, 공연 시작 -> 공연 종료까지의 정상적인 플로우에 대해 블로그 글을 쓰려고 한다.공연 플로우ssaukae에서 공연 플로우는 크게 4가지로 나뉜다.PREPARING↓PLAYING↓ANALAYZING↓FINISHEDPREPARING가창자가 정해지고, 가창자가 노래를 선정하고 있는 상태PLAYING가창자가 실제로 노래를 하고 있는 상태ANALAYZING가창자의 노래가 끝나고, 점수를 AI가 분석하고 있는 단계FINISHED노래 분석이 끝나고 점수가 나온 상태이제 본격적으로 플로우를 뜯어보자.PREPARI..

시작하며지금 진행 중인 프로젝트는 WebRTC 기반의 비대면 노래방 서비스이다.노래방 서비스에서는, 단순하게 HTTP 통신만 해서는 사용자가 온전히 서비스를 즐기기가 어렵다.누가 가창자가 되었는지, 가창자가 무슨 노래를 골랐는지, 도중에 누가 나가는지, 가창자가 템포나 음정 조절을 하는지 등등,, 실시간으로 클라이언트가 변경할 수 있는 요소가 무궁무진하다.그렇기 때문에, 지금 진행하는 프로젝트에서 웹소켓으로 클라이언트와 서버가 연결을 맺고, 양방향으로 매시지를 주고 받아야 한다. 프로젝트의 Spring WebSocket과 STOMP 구조본 프로젝트에서는 Spring WebSocket과 STOMP 프로토콜을 사용했다.STOMP메시지를 어디로 보내는지(destination), 어떤 경로를 구독할 것인지 표현..

문제 정의출발 노드와 도착 노드가 정해져있다.단방향 그래프에서 출발 노드 -> 도착노드를 가면서 그 사이에 방문하게 되는 노드들이 있을 것이고, 도착 노드 -> 출발 노드까지 가면서 방문하는 노드들이 있을 것이다.이때, 출발지 -> 도착지로 가면서 만나면서도, 도착지 -> 출발지로 가면서도 만나게 되는 노드들을 구해라문제 해결 접근특정 정점이 출발지 -> 도착지 가는 중에서 있으려면, 4가지 조건이 필요하다출발지에서 해당 정점까지 갈 수 있어야함해당 정점에서 도착지까지 갈 수 있어야함도착지에서 해당 정점까지 갈 수 있어야함해당 정점에서 출발지까지 갈 수 있어야함그렇게 하기 위해서는, 역방향 그래프를 두어서, 도착지 -> 해당 정점까지 갈 수 있는지를 판단해야한다.코드import java.util.*;im..

"실시간" 서비스는 주변에 이미 많이 널려있다.실시간을 구현하기 위해서, http 통신만 있으면 될까?결론은 "안된다." 이다.일반적인 HTTP 통신은 기본적으로 다음과 같은 응답 구조를 가진다.클라이언트 -> 요청 -> 서버 -> 응답 -> 클라이언트서버에 새로운 데이터가 생겼더라도, 클라이언트가 요청하지 않으면 이를 바로 전달하기 어렵기 때문에,주기적으로 클라이언트에서 데이터 요청을 보내야하는 불상사가 생기게 된다.서버야 너 뭐해?서버야 너 뭐해?서버야 너 뭐해?서버야 너 뭐해?이처럼 일정한 간격으로 요청을 보내는 방식이 폴링이라고 한다.요청을 보내는 텀이 그리 짧지 않으면 상관없겠지만, 텀이 짧아지면 짧아질 수록 서버의 정신은 나가게 된다.서버의 정신 건강을 위해서라도, 웹소켓을 도입해서 이 문제를..

1. 인덱스란?전공책을 읽을 때, 책의 첫페이지부터 끝까지 정독을 할 수도 있겠지만, 내가 궁금한 부분에 대해서만 읽고 싶을 수도 있다.그런 상황에서, 목차가 없다면 해당 부분이 어디있는지 찾기 위해서 1페이지부터 끝까지 순차적으로 찾아야한다.이런 문제를 막기 위해서, 목차를 두어 내가 찾고자하는 부분이 몇 페이지에 있는지 정리해놓으면, 난 목차를 보고 바로 해당 페이지로 이동할 수 있다.이렇게, 테이블 안에서 목차 기능을 담당하는 것이 인덱스이다.인덱스의 특징컬럼의 정렬목차를 둔다고 해도, 목차의 양 자체가 많아지면, "인덱스 설명에 대한 목차정보가 어디있는 거야?"와 같이 목차값을 찾는 거부터가 오래 걸릴 수 있다.목차값을 빠르게 찾기 위해, DBMS의 인덱스도, 컬럼의 값을 주어진 순서로 미리 정렬..

개발 일지 (AI 일정 자동 배치)AI 일정 자동 배치 도입우리 서비스는 이동 약자를 위한 여행 플래너이기 때문에, 여행 일정을 짜는 것도 고려를 해야한다.그리고 처음에 관광지들을 일정에다가 보관하고 나면, 사용자가 일정 안에서 관광지들을 날짜별로 순서를 정해서 여행 코스를 커스터마이징할 수 있다.사용자가 직접 일정을 관리하는 것도 가능하지만, 사용자 입장에서는 알아서 일정을 동선에 효율적으로 짜주는 기능도 있으면 매우 유용하게 사용할 수 있는 기능이라고 판단했다.AI 일정 자동 배치에 고려해야할 점그렇다면 AI에게 일정 자동 배치를 맡길 때 어떤 것들을 고려해야할까?관광지를 주어진 날짜 중 어떤 날짜에 배치해야할까각 날짜 안에서, 동선은 어떤 것을 기준으로 구성해야할까AI가 내놓은 결과를 진짜로 믿을만..

개발 일지 (Pagenation 도입하기)Page 기능 도입의 이유우리 서비스에서는, 관광지 목록을 조회하는 기능이 있다.만약에 관광지가 총 6만개라고 쳤을 때, 모든 관광지를 다 조회한다고 가정해보자.Page가 없다면 이 6만개가 다 response로 내려온다.근데 사용자 입장에서 이 6만개가 바로 필요할까?어차피 6만개를 전부다 보지 않을 텐데, 사용자가 볼 수 있는 일부만 보여주면 되지 않을까?이러한 고민에서 나온 것이 바로 Page 처리이다.Page를 도입하면 달라지는 구조Page를 도입하면, 프론트에서 요청하는 구조가 달라지게 된다.GET /api/attractions?keyword=전주&page=0&size=20이러한 형태로, 프론트에서는 가져올 페이지의 번호, 그리고 가져올 개수를 추가로 요..