코딩관계론

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만 원으로..

주식 테마 트리맵 서비스 성능 개선 과정이 글은 주식 테마 트리맵 서비스를 구현하면서 겪은 문제와 해결 과정을 다룹니다. 특히 트리맵 생성의 성능 이슈, 실시간 시세 갱신 구조, 네트워크 호출 최적화 및 캐싱 전략을 통해 아키텍처를 개선한 과정을 공유합니다.1. 트리맵(TreeMap)과 실시간 시세 갱신트리맵이 필요한 이유주식 서비스에서 시장 정보를 한눈에 파악할 수 있는 트리맵 기능은 필수적이며, 빠른 데이터 갱신이 중요합니다.초기 시세 갱신 방식의 문제점처음에는 개별 종목의 시세를 서버에서 하나씩 요청하고 DB에 저장하여, 과도한 네트워크 통신과 DB 트랜잭션으로 인해 성능 저하가 발생했습니다.개선된 요청 방식과 비동기 처리개별 요청을 시장(코스피, 코스닥) 단위의 일괄 요청으로 변경했으나, 서버 스..

배경 문제토스 증권 뉴스 페이지에서는 주가 상승 이유를 설명하는 다양한 뉴스를 제공하지만, 정보의 정확성과 관련성 부족으로 인해 투자자가 신뢰할 수 없는 경우가 많습니다.특히, 뉴스 내용이 주식과 직접적인 연관이 없거나 모호한 이유로 주가 상승을 설명하는 경우가 많아 투자자들은 추가적으로 네이버 등 외부 소스에서 정보를 확인해야 하는 불편함을 겪고 있습니다.이 과정에서 과거 뉴스까지 검색해야 할 경우 시간이 과도하게 소요되는 문제도 발생합니다. 초기 접근 방식초기에는 OpenAI가 권장하는 프롬프트 엔지니어링 방식을 통해 GPT 모델을 활용하려 했습니다.다만, 뉴스 데이터는 맥락이 복잡하고 비슷한 내용이 많아 단순 프롬프트로는 원하는 성능을 충분히 얻을 수 없었습니다.참고자료에서 제공된 사례와 권장 사항..

서버 특정 시간대 오류 분석 및 해결 과정문제 상황Search 서버가 특정 시간대에 주기적으로 중단되는 현상이 발생했습니다. 초기에는 빈번하게 발생했지만 시간이 지나며 발생 빈도가 줄어들었습니다. 최근 데이터베이스 마이그레이션 이후 다시 동일한 문제가 발생하여, 원인 분석 및 해결을 진행했습니다.초기 의심로컬 테스트와 AWS 환경 차이로컬 테스트에서는 문제없이 작동했으나, AWS 환경에서 업로드 후 문제가 발생.AWS 환경 문제를 의심하여 top 명령어로 리소스 사용량 로그를 추적했지만 특이점이 발견되지 않았습니다.오류 빈도의 감소시간이 지나며 오류 발생 빈도가 줄어들었기에 급한 일 처리 후 원인 분석을 유보했었습니다.상세 원인 분석데이터베이스 마이그레이션 후 오류가 재발하여 다시 분석에 돌입했습니다.문..

문제 정의오리엔트정공과 같은 특정 주식의 상승 이유를 설명하는 뉴스를 제공할 때,같은 주제의 뉴스가 반복적으로 노출되어 사용자들이 피로감을 느끼는 문제가 발생했습니다.특히, 2024-12-09일 주가 상승 이유는 **"탄핵", "이재명"**이라는 공통된 주제로 요약될 수 있음에도 불구하고, 중복된 뉴스가 다수 표시되어 불편함을 초래했습니다.따라서 이러한 주식들을 필터링할 수 있는 방법이 필요합니다. 첫 번째 시도: 키워드 기반 클러스터링처음에는 GPT에게 뉴스를 분석하여 핵심 키워드를 추출하도록 했습니다.각 뉴스에서 얻은 키워드 리스트를 바탕으로 공통된 키워드를 가진 뉴스를 묶어주는 방식을 고려했으나, 단순한 키워드 비교로는 한계가 있었습니다.한계 사례다음과 같은 뉴스 목록이 있다고 가정합니다.뉴스 1:..

최근에 네이버 금융 테마 페이지를 크롤링하는 작업을 진행했는데, 한 페이지를 크롤링하는 데 약 1분 정도가 소요되었습니다. 한두 페이지를 크롤링하는 것이라면 감내할 수 있는 시간이지만, 해당 작업은 주로 새벽 시간대에 실행되었기 때문에 사용자 트래픽이 적은 상황에서도 처리 시간이 길었습니다. 하지만 크롤링해야 할 페이지 수가 N개로 증가할수록, 전체 크롤링 시간은 선형적으로 증가하는 문제가 있었습니다. 이를 해결하기 위해 비동기 요청, 병렬 처리, 경량 스레드 등의 다양한 최적화 방법을 고민하게 되었고, 그 과정에서 얻게 된 경험과 성과를 공유하고자 합니다. 여담이지만, 개인적으로 작업이 완료되지 않으면 잠을 못 자는 성격이라, 성능을 최대한 단축하는 것이 필요하다고 판단했습니다.첫 번째 시도: @Asy..

의도Transactional Outbox Pattern의 주요 의도는 데이터 일관성과 메시지 전송의 신뢰성을 동시에 보장하는 것입니다. 일반적으로, 메시지 브로커에 메시지를 전송하는 과정에서 데이터베이스 트랜잭션 실패가 발생하면 메시지 전송의 일관성이 깨질 수 있습니다. 이를 방지하기 위해 Transactional Outbox Pattern은 데이터베이스 내에 outbox 테이블을 별도로 생성하고, 트랜잭션 내에서 메시지를 기록함으로써 트랜잭션이 성공할 때만 메시지가 발행되도록 설계합니다. 이 패턴은 메시지 브로커(Kafka 등)로의 전송 보장을 목표로 하며, 메시지가 적어도 한 번 이상(at-least once) 전송되었는지 확인할 수 있는 구조를 제공합니다. 트랜잭션 내에서 데이터베이스와 메시지 전송..

시스템 구조결제 승인 구조는 포트와 어댑터 패턴을 사용하여 설계되었습니다. 이 패턴을 사용한 이유는 여러 결제 시스템을 유연하고 확장 가능하게 처리하기 위해서입니다. 예를 들어, Toss Payment 서비스를 사용하다가 PayPal이나 Stripe와 같은 다른 결제 서비스를 추가하거나 교체할 경우, 비즈니스 로직은 변경할 필요가 없으며, PaymentExecutor에 새로운 어댑터를 구현하는 것만으로 충분합니다. 이를 통해 유지보수가 용이하고 확장성이 뛰어난 구조를 유지할 수 있으며, 의존성 역전 원칙에 따라 비즈니스 로직이 구체적인 결제 시스템에 종속되지 않도록 설계되었습니다. 노락색 박스는 모두 인터페이스, 검은색 박스는 구현체를 의미하며 초록색 박스 안에 있는 값들은 클래스 변수입니다똑똑한 Ret..