코딩관계론

주식 종목 자동 완성 기능 개선 및 Elasticsearch 활용기존에는 RDB(Relational Database) 기반으로 주식 종목 자동 완성 기능을 구현했으나, 이 방식에서는 오타 교정 기능이 기본적으로 제공되지 않기 때문에, 추가적인 비즈니스 로직을 개발해야 하는 부담이 있었다. 이에 따라 **Elasticsearch(이하 ES)**의 Fuzzy 검색 기능을 활용하여 보다 효율적인 자동 완성 시스템을 구축하기로 결정했다.또한, 향후 나스닥(NASDAQ) 종목까지 지원하게 될 경우, 대규모 데이터 처리를 위한 역색인(Inverted Index) 기반의 검색 시스템이 필수적이므로, 확장성을 고려하여 ES를 도입했다.1. 검색어 자동 완성 기능 벤치마킹우선, 주요 검색 시스템들이 자동 완성을 어떻게 ..

기존에는 뉴스 문서의 빠른 검색과 다양한 기능 제공을 위해 데이터베이스(DB)를 사용했으나, 성능과 확장성 측면에서 한계를 느껴 엘라스틱서치(Elasticsearch)를 도입하기로 했습니다.기본적으로 텍스트 검색은 대부분의 DB가 지원하며, 개발자가 직접 구현할 수도 있지만, 효율적이고 빠른 검색을 위해 전문 검색 엔진을 사용하는 것이 더 효과적입니다.1. 엘라스틱서치(Elasticsearch)란?엘라스틱서치는 검색과 분석을 위해 설계된 분산형 RESTful 검색 엔진입니다.Lucene 기반: 내부적으로 Apache Lucene 라이브러리를 사용해 텍스트를 색인하고 검색합니다. 강력한 전문 검색 기능을 제공합니다.분산 처리: 대규모 데이터를 효율적으로 처리하기 위해 여러 노드에 데이터를 샤딩(shardi..

시스템 구조 및 배경이전 시스템 설계에서는 뉴스 데이터를 처리하는 서버가 단일 인스턴스로 구성되어 있었습니다. 이 때문에 Java의 ConcurrentHashMap을 이용한 간단한 동시성 처리 방식만으로도 어느 정도 운영이 가능했습니다. 그러나 파이썬에서 GPT API를 호출하는 결과와 자바에서 GPT API를 호출하는 결과에 차이가 생기면서, 추가적인 처리 로직을 자바 서버 쪽에서 담당해야 했습니다. 이 변화로 인해 단일 서버가 감당할 수 있는 동시성 처리의 한계가 명확히 드러났습니다. 아래 글은 서버 스케일아웃(확장) 작업 중 발생한 여러 문제를 해결해 나가는 과정(트러블슈팅)에 대해 정리한 내용입니다. 기존 단일 서버 환경에서 처리하던 뉴스를 대규모로 확장하고, 각 단계별로 분산 처리를 도입하면서 ..

아래의 빨간색 버튼은 사용자가 특정 주식 정보를 갱신하기 위한 버튼입니다. 해당 버튼을 클릭하면 뉴스 업데이트가 진행되며, 서버에 정보 갱신 요청이 전달됩니다. 서버는 요청을 비동기적으로 처리하기 때문에 즉시 응답을 프론트엔드에 전송하고, 프론트엔드는 폴링(polling) 방식을 통해 갱신 완료 여부를 지속적으로 확인합니다.단순한 API임에도 불구하고, 실행 시간이 점차 증가하면서 DB 커넥션 문제(아래 이미지 참조)가 발생했습니다. 요약하면, 주식 정보 조회 시 DB 커넥션을 획득하는 과정에서 문제가 발생한 것으로 보입니다. 그러나 DB 커넥션에 문제가 있다면 다른 요청들도 영향을 받아야 하는데, 실제로는 정상적으로 조회되고 있어 의문이 생겼습니다. 이 동작방식의 간단한 요약도를 보면 주식의 정보 조회..

지금까지 에드센스 가입을 두 번이나 신청했지만 모두 거절당했다. 처음에는 사이트가 충분히 개발되지 않아서 거절된 줄 알았는데, 알고 보니 뉴스 링크 때문에 수익화가 승인되지 않은 것이었다.이 문제를 해결하기 위해 GPT를 활용해 원인을 분석해봤다. 결과적으로 두 가지 문제점을 발견했는데, 첫째는 트래픽 부족이었고, 둘째는 페이지에 포함된 외부 링크가 너무 많다는 것이었다. 여러 뉴스 중에서 필요한 내용만 선별해서 링크를 올린 것이었는데, 이렇게 많은 외부 링크가 에드센스의 정책에 문제가 될 것이라고는 예상하지 못했다. 앞으로는 화면을 재구성하고, 외부 뉴스 링크 대신 핵심 내용을 요약하거나 독창적인 내용으로 재구성하여 게시할 계획이다.이를 구체적으로 실현하기 위한 방안은 다음과 같다.0. Adfit 먼저..

앞서 사용했던 기술들을 바탕으로, 어디에서도 확인할 수 없는 기능이었던 시장의 테마를 실시간으로 추적해주는 ‘테마 맵’을 개발했다. 처음엔 단순히 시세 변동을 시각화하는 수준이었는데, 점차 발전시키면서 시장에서 주목받는 테마별 흐름을 한눈에 파악할 수 있도록 만들었다. 그 결과, 사용자들이 조금씩 접속하기 시작했고, 긍정적인 피드백도 늘어나는 추세다. 오랫동안 준비한 프로젝트라 그런지, 직접 만든 서비스에 사람들이 관심을 보이니 정말 기분이 좋다. 그런데 아직 해결해야 할 과제도 있다. 현재 테마 맵은 20분 전 가격 데이터를 기준으로 하고 있는데, 이 시간 차이가 생각보다 커서 실시간성에 대한 아쉬움을 느끼는 사용자들도 있다. 어떻게 하면 더 빠르고 정확한 데이터를 반영할 수 있을지 고민 중이다. ..

대규모 데이터 배치 작업 후, 검색 쿼리 성능이 현저히 저하되는 문제가 발생했습니다. 특히 특정 쿼리 수행 시간이 약 4초에 달했습니다. 1. 쿼리 실행 계획 분석성능 저하 원인을 분석하기 위해 MongoDB의 쿼리 실행 계획을 확인했습니다.db.news.find({'stockCode': '437730', 'isRelated': true}).explain("executionStats")결과:stage: COLLSCAN → 전체 컬렉션을 풀 스캔했습니다.totalDocsExamined: 102,457 → 약 10만 건의 문서를 모두 검사했습니다.nReturned: 8 → 최종 반환된 문서 수는 8건입니다.executionTimeMillis: 3,374ms → 쿼리 한 번에 3초 이상 소요됐습니다.결국, 인..

1. 문제 상황현재 뉴스 패치 시스템은 AWS SQS(메시지 큐)를 통해 3개의 Lambda 함수가 뉴스 데이터를 처리하고 있습니다.그런데 뉴스 분석 과정에서 하나의 파티션에서 모든 작업을 처리하다 보니, 컨슈머 랙(Consumer Lag)이 급격히 증가하는 문제가 발생했습니다.해결 시도가장 먼저 고려한 방법은 파티션을 늘리는 것이었습니다. 하지만 동시성이 증가하면 자연스럽게 동일 데이터 접근 충돌 문제가 발생할 가능성이 커지므로, 이를 해결할 방법도 함께 고민해야 했습니다.3. 동시성 이슈 해결 방법 검토파티션을 늘린다면 여러 개의 Lambda가 동시에 같은 데이터에 접근할 가능성이 증가합니다. 이를 해결하기 위해 여러 가지 방법을 검토했습니다.1) 분산 락 사용Redis나 Zookeeper를 이용한 ..

1. 문제 정의: 테마 관련 뉴스 판별 필요성주식 시장에는 AI, 2차전지, 신재생에너지, 원전 등 다양한 테마가 존재합니다. 하지만 테마 키워드로 뉴스를 크롤링하면 실제 투자에 유용하지 않은 정보성 없는 뉴스들이 포함되는 문제가 발생합니다.예를 들어, "원자력발전소" 키워드로 크롤링할 경우:원전 설비나 정책이 아닌 단순 지역 축제 소식 등 무가치한 정보가 포함될 수 있습니다.따라서 테마와 관련 있는 뉴스만 정확히 필터링하는 로직이 필수적입니다.초기 시도했던 접근 방법간단한 규칙 기반 필터링사전 정의된 키워드로 뉴스를 걸러냄문제점: 키워드 변형이나 문맥 차이로 중요한 뉴스를 놓치거나 무관한 뉴스가 필터링되지 않는 문제 발생모델 파인튜닝테마 관련 여부 데이터셋으로 모델 튜닝문제점: 높은 튜닝 비용과 유지보..

1. 문제 정의처음 뉴스 데이터를 크롤링할 때, 하나의 고정 IP로 많은 요청을 보내면서 IP 제한이 걸려 원하는 데이터를 안정적으로 수집하지 못했습니다.2. 시도된 해결 방법2.1 프록시 서버 사용배경: IP 제한 회피를 위한 프록시 서버 활용문제점:비용 부담: 안정적인 프록시 IP는 고비용신뢰성 문제: 불안정한 연결로 인한 데이터 수집 불안정2.2 네이버 API 활용장점: 네이버 공식 API를 통한 안정적인 데이터 수집단점:날짜 제한: 특정 날짜 이후 뉴스는 제공되지 않음API 호출 제한: 호출 횟수 제한으로 완전한 데이터 확보 어려움초기에는 네이버 API를 사용했으나, 장기적으로 데이터 부족 현상이 심각했습니다.3. 서버리스 기반 크롤링 아키텍처 도입기존 방식의 한계를 극복하기 위해 AWS 서버리스..

1. 문제 상황매일 밤, 주식 Insight를 갱신하기 위해서는 여러 단계를 거쳐야 합니다:뉴스 데이터 크롤링외부 API 호출 (주식 정보 등)DB 적재 및 분석/가공매일 밤, 주식 Insight를 갱신하기 위해 여러 단계를 거치는 과정에서 우리는 다음과 같은 기술적 도전에 직면했습니다:뉴스 데이터 크롤링외부 API 호출 (주식 정보 등)DB 적재 및 분석/가공초기에는 동기적 HTTP 요청으로 직관적으로 처리했지만, 더 큰 규모와 빠른 처리가 요구되면서 새로운 아키텍처를 모색해야 했습니다.초창기에는 순차적(동기) HTTP 요청으로 처리했습니다. 이 경우,“동시에 큰 트래픽이 발생하지 않는다”는 장점“각 단계별로 순차성을 보장한다”는 직관적 이해도그러나 처리 시간이 오래 걸린다는 치명적인 단점이 있었습니다..

하루에도 수많은 주식들이 갑자기 급등하거나 급락하고, 이에 따른 방대한 양의 뉴스가 쏟아져 나옵니다. 예를 들어, 하루에 급등하는 종목이 100개라면, 해당 종목과 관련된 뉴스가 10개일지 100개일지 예측할 수 없는 상황입니다.처음에는 이 모든 뉴스를 탐색하고 분석하여 각 주식의 상승 이유를 도출하는 방식으로 접근했습니다. 하지만 시간이 지날수록 비용 부담이 커지기 시작했고, 결국 비용 최적화 방안을 모색해야 했습니다.정보 분석의 비용 구조뉴스 한 개를 분석할 때 다음과 같은 단계가 필요합니다.뉴스가 주어진 주식 종목의 상승 이유를 설명하는지 확인해당 뉴스의 테마 추출추출된 테마 이름을 통합테마의 백그라운드 생성주식 인사이트 생성이 과정을 한 번 거칠 때마다 비용이 발생하며, 이 방식으로 10만 원으로..