TIL
-
2025.05.29 높은 부하와 재고TIL 2025. 5. 29. 23:51
우리 회사는 재고와 트래픽이 만날 일이 없다.고객이 주문할 때 재고를 확인하지 않기 때문이다. 이건 비즈니스 모델과도 연관이 있는데, 각설하겠다. 만약 우리의 시스템에서 주문 시 재고를 봐야 한다면 어떻게 해야 할까?또 부하가 높아진다면 어떤 설계를 해야 할까? 이런 생각에서 토이 프로젝트를 구상하고 있다. 아래는 간단한 DB 스키마이다. 실제 재고는 단순히 숫자로만 관리되지 않고 유통기한, 수량, 구매처 등등이 함께 관리되어야 한다.근데 이게 앞에 글에서도 말했지만 사용자에게 노출될 필요는 없다.사용자는 구매가능한 재고만 알고 있으면 된다.또 구매가능한 재고는 실제 물리 재고와 일치할 필요가 없다.사용자가 아직 입고되지 않은 재고를 팔 수도 있는 것이기 때문이다.그래서 물리 재고(stock)와 판매 재..
-
2025.05.10 재고 트랙픽과 캐시 4TIL 2025. 5. 10. 14:04
이전에 재고를 레디스에서 관리함으로써 사용자에게 빠른 응답을 줄 수 있었습니다.DB의 데이터가 재고 자원의 원천이기에 비동기로 최종적 일관성을 맞춰줍니다. 최근 고민하던 구조를 복기하면서, 놓치고 있던 문제점들을 발견했습니다.상품 재고는 단순히 product_id 단위로만 관리되지 않고, 유통기한, 창고 위치, 구매처 등 여러 메타 정보로 구분된 정보로 관리됩니다.상품하나에 여러 개의 서로 다른 유통기한, 위치 재고가 존재할 수 있습니다.유저는 이를 몰라도 요청할 수 있습니다. 그래야만 하고요.위의 다이어그램으로는 유저의 요청은 수용할 수 있습니다. 하지만 어드민은 상품의 재고 중 일부를 폐기할 수 있습니다.어드민의 요청은 유저의 요청처럼 선입선출로 재고 차감이 이뤄지는 것이 아닌 상품 id, 유통기한..
-
2025.05.10 몽상의 종말TIL 2025. 5. 10. 12:57
몽상(Daydreaming)의 종말 | GeekNews스마트폰은 심심함과 지루함을 없애주는 기계이지만, 그로 인해 창의성과 공감 능력이 손상되고 있음틈새 시간(interstitial time) 은 원래 명상, 몽상, 관찰 등 인간적인 활동이 일어나던 순간이었news.hada.io 끊임없이 정보를 얻는다. 웹 서핑, 유튜브 매체가 뭐가 되었든 끊임없이 들어온다. 음악도 그중 하나다. 요즘 손에서 놔버리는 시간이 필요하다고 느낀다.또 AI가 발전하다 보니 고민하는 시간보다 AI에 물어보는 게 빠르다고 느낀다. 그러다 보니 혼자 고민하고 끙끙거리며 결과물을 만들어 내던 즐거움이 사라졌다.아웃풋이 중요한지 내가 즐거워 지속 가능한 상태로 만드는 게 중요한지 모호해져 버렸다.
-
2025.05.06 캐시 업데이트TIL 2025. 5. 6. 23:39
핫 키 캐시 만료캐시는 언제 업데이트할 것인가?초기 데이터는 웜업으로 올려놓는다 칩시다.모든 데이터를 올려놓지는 않을 테니 나머지 데이터들은 DB먼저 조회 후 캐시에 세팅될 것입니다.일부 만료된 데이터를 세팅할 때 많은 트래픽이 몰리면 어떻게 해야 할까요?기본적인 DB조회 후 세팅 전략을 사용하면 위와 같은 문제가 발생할 수 있습니다.단순히 중복 세팅되어도 괜찮지 않나?라고 생각할 수 있지만 A-4가 계산된 값이라면 이는 로스트 업데이트가 되어버립니다.이를 방지하기 위해서는 캐시 미스가 발생했을 때 분산락을 잡아서 해결할 수도 있습니다. 더 간단한 해결책으로는 만료시간이 없도록 하는 것이지요. 혹은 만료 시간을 백그라운드에서 계속 늘려주는 방법도 있을 수 있습니다.혹은 SETNX를 통해 처음 값만 입력되..
-
2025.05.05 재고 트래픽과 캐시 3TIL 2025. 5. 5. 17:18
궁금한 점이 생겼습니다.캐시를 이용할 때 빈틈이 있습니다.캐시와 DB 두 곳을 재고 데이터의 스토어로 사용할 때입니다. 그간 예제로 사용했던, 캐시 업데이트 후 이벤트 발행입니다. 여태 이야기되었던 여기서의 문제와 자체적으로 내린 답은 아래와 같습니다.레디스가 먼저 장애가 난다면장애가 캐시 업데이트 이후: 슬레이브까지 복제가 되었나? replicas-write, min_replicas_to_write 등의 설정으로 유실 완화는 시키겠지만, 유실된 데이터 파악을 위해 주문 번호등을 로깅, 알림해야합니다.장애가 업데이트 이전: 이건 업데이트가 되지 않았으니 슬레이브를 마스터로 띄워서 가용성을 챙기자카프카 메시지 발행이 실패한다면?메시지는 eventually consistency이기 때문에 프로듀서 DLT에..
-
2025.05.04 재고 트래픽과 캐시 2TIL 2025. 5. 3. 22:55
트래픽에 대해서 생각을 하다가 몇 가지 궁금한 점이 생겼습니다. 1. 레디스 센티넬로 고가용성을 높였을 때, 슬레이브에 복제 전에 마스터가 죽을 경우는?2. 레디스와 카프카 메시지 발행의 트랜잭션은 어떻게 해야 할까?3. 레디스 캐시를 사용할 때, 캐시 업데이트는 언제 해야 할까? 어제 그린 마인드맵 아래쪽에 더 몇 가지를 추가했습니다. 1. 레디스 센티넬로 고가용성을 높였을 때, 슬레이브에 복제 전에 마스터가 죽을 경우는?레디스에서 이런 상황을 막기 위해 설정들이 존재하더군요.min_replicas_to_write: 이 설정은 마스터가 쓰기 전, 슬레이브 레디스가 실행 중인지 확인하는 설정입니다. 슬레이브가 설정 값 보다 적게 살아있다면 쓰기를 하지 않는 것이지요.min_replicas_max_l..
-
2025.05.03 재고 시스템 일관성과 트래픽TIL 2025. 5. 3. 16:43
재고 서비스가 있을 때 트래픽이 몰릴 경우 해야 할 일을 마인드맵?으로 그려봤습니다.재고의 일관성도 지키고 싶고 트래픽도 원활히 허용하고 싶다면 뭘 해야 할까요.일관성을 지키기 위해서는 결국 직렬화를 해야 한다. 그에 사용되는 방법이 락인 것이고. DB의 락을 사용하면 응답 속도 지연과 커넥션 부족으로 이어질 수 있습니다. 그래서 락은 최소한의 시간과 로우를 잡는 것이 현명합니다. 많은 트래픽이 몰릴 때는 이것만으로는 부족할 수 있습니다. 그럼 그 트래픽과 시스템 성격에 따라서 해결법이 나눠질 수 있을 거 같습니다. 1. 데이터 핫스팟일부 데이터 수정이 잦다면 대기열을 사용할 수도 있습니다. 예로 티켓팅 서비스가 대기열을 많이 사용하죠.근데 일반적인 이커머스에서는 대기열을 사용해 사용자 경험을 저하시키지..
-
2025.04.29 좋아요 정렬TIL 2025. 4. 29. 23:58
Case 1'좋아요'를 구현할 때 어찌해야 하는가를 다루고 있습니다. 정렬을 제외했을 때는..데이터가 많지 않다면 post_like 매핑 테이블을 만들어서 group by sum을 통해서 값을 얻을 수 있습니다.데이터가 많아지면 버퍼에 없을 가능성이 커지므로 디스크 IO가 증가하게 될 것입니다.또 group by이기 때문에 임시 테이블을 사용하게 되고, 데이터가 많으면 디스크 스필이 이뤄지게 되고 더 느려지게 됩니다.그럼 그때 성능 최적화를 하면 됩니다. Case 2성능 최적화 방법으로는 뭐가 있을까요?음..캐시 생각하기 전에 게시물당 좋아요를 카운팅 하는 테이블을 둡시다.게시글에 칼럼에 카운팅을 두지 않으므로서 게시물의 데이터 경합에서 벗어날 수 있습니다. 좋아요 카운팅 경합이 더 많겠지요? post_..