일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- next-stock
- 쿠키
- spring event
- gRPC
- 완전탐색
- ipo 매매자동화
- 누적합
- BFS
- 트랜잭샨
- 디버깅
- 프로그래머스
- docker
- AWS
- 크롤링
- 검색어 추천
- JPA
- 카카오
- 추천 검색 기능
- 객체지향패러다임
- 레디스 동시성
- 깊게 생각해보기
- 결제서비스
- 아키텍쳐 개선
- 셀러리
- 백준
- 구현
- 이분탐색
- 몽고 인덱스
- piplining
- jwt 표준
- Today
- Total
목록전체 글 (180)
코딩관계론

1. 문제 정의처음 뉴스 데이터를 크롤링할 때, 하나의 고정된 IP로 다수의 요청을 보냈더니 IP 제한에 걸려 원하는 데이터를 안정적으로 수집하지 못하는 상황에 직면했습니다. 이를 해결하기 위해 처음에는 두 가지 방법을 시도했습니다.2. 시도된 해결 방법2.1 프록시 서버 사용시도 배경: 크롤링 트래픽을 분산하기 위해 프록시 서버 IP를 활용하려 했습니다.문제점:비용 부담: 신뢰할 만한 프록시 IP 제공 서비스는 가격이 비쌌습니다.신뢰성 문제: 불안정한 프록시로 인해 데이터 수집의 안정성이 낮아졌습니다.2.2 네이버 API 활용장점: 네이버에서 제공하는 공식 API를 사용하면 안정적으로 데이터를 수집할 수 있었습니다.단점:날짜 제한: 특정 날짜 이후의 뉴스 데이터는 제공되지 않아 완전한 데이터 수집이 불..

1. 문제 상황매일 밤, 주식 Insight를 갱신하기 위해서는 여러 단계를 거쳐야 합니다:뉴스 데이터 크롤링외부 API 호출 (주식 정보 등)DB 적재 및 분석/가공매일 밤, 주식 Insight를 갱신하기 위해 여러 단계를 거치는 과정에서 우리는 다음과 같은 기술적 도전에 직면했습니다:뉴스 데이터 크롤링외부 API 호출 (주식 정보 등)DB 적재 및 분석/가공초기에는 동기적 HTTP 요청으로 직관적으로 처리했지만, 더 큰 규모와 빠른 처리가 요구되면서 새로운 아키텍처를 모색해야 했습니다.초창기에는 순차적(동기) HTTP 요청으로 처리했습니다. 이 경우,“동시에 큰 트래픽이 발생하지 않는다”는 장점“각 단계별로 순차성을 보장한다”는 직관적 이해도그러나 처리 시간이 오래 걸린다는 치명적인 단점이 있었습니다..
하루에도 수많은 주식들이 갑자기 급등하거나 급락하고, 이에 따른 방대한 양의 뉴스가 쏟아져 나옵니다. 예를 들어, 하루에 급등하는 종목이 100개라면, 해당 종목과 관련된 뉴스가 10개일지 100개일지 예측할 수 없는 상황입니다.처음에는 이 모든 뉴스를 탐색하고 분석하여 각 주식의 상승 이유를 도출하는 방식으로 접근했습니다. 하지만 시간이 지날수록 비용 부담이 커지기 시작했고, 결국 비용 최적화 방안을 모색해야 했습니다.정보 분석의 비용 구조뉴스 한 개를 분석할 때 다음과 같은 단계가 필요합니다.뉴스가 주어진 주식 종목의 상승 이유를 설명하는지 확인해당 뉴스의 테마 추출추출된 테마 이름을 통합테마의 백그라운드 생성주식 인사이트 생성이 과정을 한 번 거칠 때마다 비용이 발생하며, 이 방식으로 10만 원으로..

아래 글은 주식 테마 트리맵 서비스를 구현하면서 겪은 문제와 해결 과정을 정리한 내용입니다. 트리맵 생성 과정에서 발생했던 성능 이슈, 실시간 시세 갱신 구조, 그리고 네트워크 호출 최적화와 캐싱 방안까지, 전체적인 아키텍처 개선 과정을 공유합니다.1. 트리맵(TreeMap)과 실시간 시세 갱신트리맵이 필요한 이유주식 관련 서비스라면, 시장 정보를 한눈에 파악할 수 있는 트리맵(TreeMap) 기능은 필수적입니다. 특히, 테마별 시장 상황을 보여주는 트리맵이라면 데이터 갱신 주기와 속도가 무엇보다 중요합니다.최초 시세 갱신 방식처음에는 시세를 요청하는 서버(Python)와 트리맵을 생성하는 서버를 분리하여, 트리맵 서버가 일정 시간마다 이벤트를 발행해 시세 업데이트를 받는 구조였습니다. 그러나 약 2,0..

배경 문제토스 증권 뉴스 페이지에서는 주가 상승 이유를 설명하는 다양한 뉴스를 제공하지만, 정보의 정확성과 관련성 부족으로 인해 투자자가 신뢰할 수 없는 경우가 많습니다.특히, 뉴스 내용이 주식과 직접적인 연관이 없거나 모호한 이유로 주가 상승을 설명하는 경우가 많아 투자자들은 추가적으로 네이버 등 외부 소스에서 정보를 확인해야 하는 불편함을 겪고 있습니다.이 과정에서 과거 뉴스까지 검색해야 할 경우 시간이 과도하게 소요되는 문제도 발생합니다. 초기 접근 방식초기에는 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..

서론이 글에서는 쿠팡의 결제 서비스에서 Checkout 프로세스를 어떻게 처리하고 있는지 분석하고, 특히 Checkout ID의 보안 및 관리에 대해 논의하고자 합니다. Checkout ID는 결제 프로세스의 핵심 요소로, 올바르게 관리되지 않으면 보안 취약점이 발생할 수 있습니다. 따라서 이 글에서는 Checkout ID의 생성, 저장, 그리고 만료 처리 방법에 대해 심도 있게 다루고자 합니다. Checkout Response 분석이 Response에서 주목할 부분은 checkoutId와 checkoutUrl입니다. 이들이 외부에 노출되거나 변조될 경우, 결제 과정에 보안 문제가 발생할 수 있습니다. 따라서 쿠팡에서는 어떻게 이러한 문제를 해결했는지에 대해서 알아보겠습니다.https://checkout..

비즈니스 규칙쿠폰 할인 적용: 사용자는 결제 시 쿠폰을 사용할 수 있으며, 적용된 금액은 100원 단위로 절삭됩니다.다중 쿠폰 사용: 여러 장의 쿠폰을 한 번의 결제에서 적용할 수 있습니다. 하지만 최종 결제 금액은 최소 100원 이상이어야 합니다.회원 등급 승격: 결제가 완료되면 해당 회원의 등급이 VIP로 승격됩니다.서비스 FLOWCheckout Service2024.09.03 - [개발] - 결제서비스 - Checkout 서비스 구현 [#50] 결제서비스 - Checkout 서비스 구현 [#50]서론이 글에서는 쿠팡의 결제 서비스에서 Checkout 프로세스를 어떻게 처리하고 있는지 분석하고, 특히 Checkout ID의 보안 및 관리에 대해 논의하고자 합니다. Checkout ID는 결제 프로..