코딩관계론

아래는 오리엔트정공을 검색하면 왜 상승했는지를 보여주는 뉴스들이다. 다만 여기서 중요한 점은 2024-12-09일의 상승 이유는 탄핵, 이재명 관련해서 올랐던 것으로 요약될 수 있지만, 모든 뉴스를 분석해서 관련있다고 생각되는 뉴스들을 모두 화면에 보여주니깐 중복된 내용이 많아 사용자들이 피포감을 느낄 수 있다. 따라서 이러한 주식들을 필터링할 수 있는 방법이 필요하다.  ## 방법들 설명처음 생각한 방법은 아래와 같다.뉴스 타이틀들의 편집 거리를 비교해서 비슷한 내용인지 판단할 수 있을 것이다. 하지만 얼마의 거리로 해야 같다고 할 수 있는지 알 수 없고, 내용은 같지만 제목이 완전히 달라지는 경우가 있다. 예를들면   두 번쨰 방법은 예정된 이벤트 일자가 같은 경우에는 같은 뉴스로 판단될 수 있을 ..

최근에 네이버 금융 테마 페이지를 크롤링하는 작업을 진행했는데, 한 페이지를 크롤링하는 데 약 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는 결제 프로..

규모 추정하루에 100만 건의 트랜잭션을 처리해야 하는 상황입니다. 이를 초 단위로 나누면, 1초에 약 12건(TPS, Transactions Per Second)을 처리해야 하는 수준입니다. 이러한 요구사항을 고려할 때, 시스템 설계 시 성능보다는 안정성에 중점을 두는 것이 중요합니다.시스템 선택 고려 사항이 결제 시스템의 경우 성능적 요구사항이 상대적으로 낮기 때문에, 안정성을 최우선으로 고려해야 합니다. 이를 위해 동기식 통신보다는 비동기식 통신을 사용하는 것이 더 적합합니다. 그 이유는 다음과 같습니다:장애 격리: 동기식 통신을 사용할 경우, 결제 서비스 제공사(PSP)에서 장애가 발생하면, 우리의 서버까지도 장애 영향을 받을 수 있어, 장애 격리가 어렵습니다.확장성: 트래픽이 급격히 증가할 때,..

최근 프로젝트에서 Redis를 사용하는 분산 시스템에서 동시성 이슈가 발생하는 것을 확인했습니다. 단일 worker 환경에서는 동시성 문제를 크게 신경 쓰지 않아도 되었지만, 시스템을 scale-out 하면서 여러 가지 동시성 문제가 발생하게 되었습니다. 예를 들어, 아래와 같은 코드가 있을 때 단일 Thread로 동작한다면 동시성 이슈가 발생할 수 있을까요?RScoredSortedSetAsync scoredSortedSet = client.getScoredSortedSet(key);RFuture scoreFuture = scoredSortedSet.firstScoreAsync();RFuture nameFuture = scoredSortedSet.pollFirstAsync();  정답은 "발생할 수 없다..

문제 이해하기간단하게 생각하면 두 저울의 합을 같게 맞추는 문제로 한 저울에서 다른 저울로 값을 옮겨가다 보면 같게 맞춰진다. 문제 해결 방법 설명하기1. 큐1에 있는 원소들의 합과 큐2에 있는 원소들의 합을 비교2. 더 큰 값의 큐에서 더 작은 큐쪽으로 원소를 이동하면 됨3. 문제 예시의 3번 조건을 보면 항상 같을 똑같이 만들 수 있는 것이 보장되지 않기 때문에 최대 경우의 수가 넘어가면 -1을 반환해야 함코드from collections import dequedef solution(q1, q2): t1_sum = sum(q1) t2_sum = sum(q2) q1 = deque(q1) q2 = deque(q2) answer = 0 max_try = len(q1)..

먼저 성능 개선을 하기 전에 목표를 정해야 합니다. 이 이벤트가 열리게 되면 1,00,000명의 사용자가 초당 5번의 질의를 이어가게 된다. 똑똑한 사용자들이 시스템의 허점을 노리고 쿠폰을 받거나 말거나 쿼리를 넣는 것이다. 또한 이 서비스는 10분간만 유요한 서비스다. 따라서 초당 QPS는 8,400을 감당할 수 있어야 합니다. (QPS와 TPS가 동일하다고 가정함) 최근에 DDD를 공부하면서 타임딜을 리펙토링 하고 성능 테스트를 진행해 보았습니다. 하지만 웬걸 성능이 아래와 같이 TPS가 2? 가 나오는 상황이 발생했습니다. 2000도 아니고 2가 나오는 숫자가 너무 기괴했습니다. 바로 프로메테우스를 보니 DB의 커넥션 풀이 10개인데 사용자의 요청이 몰리면서 10개가 전부 활성화되고, 71개가 커낵..

서론서비스에 많은 트래픽이 발생하지 않는 경우, 사용자의 요청에 따라 DB에 데이터를 저장하고 불러오는 방식은 큰 문제가 되지 않습니다. 그러나 트래픽이 증가하면 DB에서 데이터를 읽고 수정한 후 다시 저장하는 과정에서 성능 저하가 발생할 수 있습니다. 따라서, 많은 트래픽을 처리해야 하는 시스템에서는 데이터를 중간 서버에 임시로 저장한 후, 일정 주기로 DB에 영속화하는 방식으로 성능을 최적화하는 것이 일반적입니다. 저는 Redis의 Keyspace Notifications 기능을 활용하여 이 방법을 구현했습니다. 이제 이 기능의 동작 원리와 사용법을 설명하고, 이를 사용해 구현하는 과정에서 발생한 문제와 그 해결 과정을 공유하겠습니다. 동작 방식Redis의 Keyspace Notifications 구..

이전의 V3는 정말 모든 것을 만족했지만, 데이터가 지속적으로 확장된다면 결국 디비와 레디스의 용량은 한계에 도달하게 된다. 따라서 우리는 scalue-out 방법인 샤딩을 도입해서 이러한 문제를 방지해야 합니다. 검색어 추천 서비스의 경우에는 두 개의 저장소를 사용하고 있기 때문에 두 개의 저장소(Redis, Mongo)에 샤딩을 진행해야 합니다. 먼저 샤딩을 어떤 방식의 샤딩이 있는지 알아보고, 그에 맞는 적적한 샤딩 키 설계를 진행해야 합니다. 샤딩 키 설계가 잘못되면 한 서버로 데이터가 몰리게 되면서 샤딩 효과를 볼 수 없게 됩니다. 샤딩 방식에는 크게 모듈러 샤딩과 레인지 샤딩이 있습니다. 이제부터 각각의 장단점을 한번 살펴보겠습니다. 먼저 모듈러 방식은 아래 그림과 같습니다. 모듈러 방식으로 ..