지난주에는 PG 결제로 확정된 주문을 OrderConfirmed 이벤트로 Kafka에 보내고, commerce-streamer가 받아 상품 구매 활동으로 저장하게 만들었습니다. 같은 이벤트가 두 번 와도 구매 활동이 늘지 않도록 consumer 쪽 중복 방지도 꼼꼼히 넣었고요. 그런데 잠시만요.주문 확정 commit 뒤, 이벤트를 보내기 직전에 서버가 죽으면 이벤트 자체가 없다.consumer가 아무리 중복을 잘 막아도, 애초에 도착하지 않은 이벤트는 찾아낼 방법이 없습니다. 주문은 CONFIRMED, 결제도 SUCCESS, 재고도 빠졌는데 구매 활동만 비어 있는 주문이 조용히 생깁니다.이번 주는 그 빈틈을 Transactional Outbox로 막고, 더 나아가 6주차 코드로 실제로 이벤트를 잃어버린 ..
잃어버린 이벤트결제가 끝나 확정된 주문을 이벤트로 Kafka에 보내고, 다른 앱이 그 이벤트를 받아 "이 상품이 몇 개 팔렸다"는 구매 활동을 저장하도록 했습니다.이때 주문 확정이 DB에 commit된 뒤에 이벤트를 보내는데, Kafka가 이벤트를 잃어버리면 다시 보낼 방법이 없습니다.해당 주문 기록은 영영 사라지게 되겠죠.. 결국 producer가 받는 'broker에게 전송 완료' 라는 확인 메세지(ack)가 해당 이벤트가 존재했다는 유일한 기록이 되겠네요. 그래서 acks를 가장 강한 all로 둬봤습니다. (찾아보니 kafka-clients 3.0부터는 기본값이 이미 all이더라고요) 이후 내구성을 테스트해보기 위해 broker 3대로 장애를 직접 만들어 봤습니다. 어라? 근데 결과가 예상과 달랐습..
결제 시 타임아웃 발생 -> 실패?지난 글 마지막에 "트랜잭션 안에 외부 결제 API 같은 호출이 들어가면 더 그렇겠죠?"라고 적었는데요. 이번 과제가 딱 그 외부 결제였습니다.포인트로 하던 결제를 PG 결제로 바꾸는 것이 목적입니다. 주문을 확정하면 PG에 "이 카드로 2,000원 결제해 주세요" 하고 요청을 보내는 거죠.지난 글에서 배운 대로 PG 호출은 트랜잭션 밖으로 뺐습니다.재고를 잡고 결제 시도를 기록하는 트랜잭션을 먼저 끝내고, PG를 부른 다음, 결과를 반영하는 트랜잭션을 따로 엽니다. 락을 쥔 채 외부 응답을 기다리지 않기 위해서입니다.TX A (재고 확보 · 결제 시도 기록) → commit → PG 결제 요청 (트랜잭션 밖)TX B (결과 반영) → commit그런데 요청을 보냈더니..
사건의 시작, 시키지도 않은 일이 일어났다상품 목록 API를 최적화하고 있었습니다. 요청은 대략 이런 모양입니다.GET /api/v1/products?brandId=101&sort=likes_desc&page=1&size=20→ "브랜드 101의 상품을, 좋아요 많은 순으로, 20개 보여 줘"조건은 이렇습니다.상품(product)과 좋아요 수(product_like_count)는 서로 다른 테이블에 있습니다.브랜드 101은 상품이 약 1.8만 개인 큰 브랜드입니다.해당 API의 전체 건수 조회가 느린 것을 확인하고 상품 테이블에 인덱스를 하나 추가했습니다.CREATE INDEX idx_product_brand_deleted ON product (brand_id, deleted_at);성능 개선을 노린 건..
이번 과제는 "경쟁 상태에서도 재고 불변식 지키기", 트랜잭션과 락을 다루는 과제였습니다.이번 멘토링에서 가장 기억에 남는 문장이 하나 있었습니다. "낙관적 락이랑 비관적 락, 시간 차이가 별로 안 나더라고요." 물론 상황과 설정에 따라 다르겠지만, 이론으로만 공부했을 때 제가 알던 건 이랬습니다.비관적 락: 재시도는 필요 없지만, 락을 기다리는 시간이 생긴다.낙관적 락: 락을 기다리지 않고 병렬로 수행되지만, 버전 체크에서 충돌이 나면 처음부터 다시 해야 한다.그래서 막연히 '비관적 락이 더 오래 걸린다'고 이해하고 있었습니다. 지금 와서 생각해 보면, 그 오래 걸린다는 게 단순히 락을 기다리는 시간이 아니라 커넥션 풀이 고갈돼서 다른 요청까지 대기한다는 의미였을지도 모르겠네요. 아무튼 그래서, 이번 ..
이번 과제에서는 실제 구현에 들어가기 전에 도메인 설계에 시간을 많이 썼습니다.상품, 좋아요, 포인트, 주문을 만들면서 "이 규칙은 누가 지켜야 하는가"를 계속 고민했는데, 그중 가장 오래 헷갈렸던 주제 하나를 정리해 보려고 합니다.바로 0입니다. 아무것도 없다는 뜻의 숫자지만, 이번 과제에서 가장 많은 고민을 안겨 준 숫자이기도 합니다. 1. 같은 0인데 결과가 다르다포인트와 재고를 구현하고 나니 다음과 같은 표가 나왔습니다.요청결과충전한 적 없는 사용자의 잔액 조회0원, 정상0원 충전거절 (400 INVALID_CHARGE_AMOUNT)재고 5개인 상품에서 0개 차감거절합계 0원 주문 확정 (0원 결제)성공잔액 0원은 괜찮은데 충전 0원은 안 되고, 재고 0개 차감은 안 되는데 0원 결제는 됩니다.처..
"번개런/정기런 모임 장소 1km 이내에서 출석 버튼을 누르면 출석이 가능하다." 사이드 프로젝트 아지트에서 받은 요구사항 한 줄이다.읽으면 다 이해한 것 같고 바로 구현할 수 있을 것 같다. 실제로 그때 바로 구현했다면 출석 API는 하루 만에 나왔을 것이다.문제는 그 하루 동안 내가 기획자 대신 결정했을 사항들이다. 막혔던 질문들당시 실제로 막혔던 질문은 다음과 같다. (이 외에도 여러 질문들이 있었는데, 해당 글에서는 세 개의 질문으로만 상정하겠다)1. 일정 시작 앞뒤 한 시간 안에 출석할 수 있다고 했는데, 59분까지인가 60분까지인가.2. 일정을 만든 팀원이 시작 한 시간 전에 크루를 탈퇴하면 그 일정은 어떻게 되는가. 이미 출석한 크루원과 아직 하지 않은 크루원은 각각 어떻게 되는가.3. 이미..
버퍼 풀 Buffer Pool디스크에 저장된 테이블과 인덱스 데이터를 캐싱하기 위해 할당한 메모리 영역.디스크(HDD/SSD)의 IO 속도는 메모리(RAM)에 비해 압도적으로 느리다. 모든 요청마다 디스크에 접근하면 성능이 매우 안좋아지므로 메모리에 올려서 최대한 메모리 안에서 처리하기 위해 쓰인다.왜 느릴까?RAM: 구조가 매우 단순, 전기식. CPU와 가까운 곳에 위치. 주소를 알면 즉시 접근 가능디스크: 물리적인 움직임/로직이 복잡함. 메인보드 상 CPU와 떨어져 있음. 데이터를 바이트 단위가 아닌 블록, 페이지 단위로 저장하므로 한 데이터 읽을 때마다 블록/페이지 전체 읽어와야 함.데이터를 페이지(16KB)로 쪼개서 사용하고, LRU (least recently used) 알고리즘을 사용한다.최근..
이틀 내내 삽질을 정말 많이 해서.. (하루는 환경변수 주입이 안 돼서 하루종일 환경변수 구글링만 함ㅜㅜ)기록용으로 현재 빌드 성공한 스크립트 및 설정을 적어두려고 한다. 환경변수 설정 할 때 '이 빌드는 매개변수가 있습니다' 설정에서 파라미터를 등록하라는 글이 있어서 따라해봤었는데, 결과적으로 잘 되지 않았다. 그래서 일단 젠킨스 자체에 시크릿 키를 등록해두고 해당 키들을 환경변수로 적용하는 방법을 사용했다.추후 더 좋은 방법이 있으면 적용할 생각이다. pipelinepipeline { agent any environment { IMAGE_NAME = "cogroom/cogroom-server-develop" CONTAINER_NAME = "cogroom" ..
CI CD를 위한 도커파일, 젠킨스 스크립트 작성 후 item을 실행시켜보니, 정상적으로 모든 stage가 작동하고 배포 완료 로그가 뜨는데도 서버 실행이 되지 않았다.이에 docker log를 확인하려고 했더니 Unable to access jarfile /app.jar 에러가 발생했다.jar 파일을 찾지 못해서 발생한 오류라고 한다. 가장 먼저 도커 상황을 확인했다.docker ps -a | grep cogroom-app잘 작동하고 있다. stage console output 을 확인했다.build가 잘 되었다고 뜬다. 구글링을 더 해본 후 답을 찾았다.Dockerfile에서 설정해둔 ENTRYPOINT의 jar 파일 경로를 읽어들이지 못해서 발생한 오류였다.Dockerfile의 ENTRYPOINT ..
