뇌피셜 주의!이 글은 이 책을 읽고 느낀 개인적인 생각을 적은 글입니다. 곧이 곧대로 믿지 말아주시고, 틀린 내용이나 의견 있으면 자유롭게 남겨주세요 :)NoSQL Distilled최근 읽은 책중에 재밌게 읽은 게 있어서 소개해 보려고 가져왔다. 크게 1부(기본 개념)와 2부(적용)로 나뉘어 있는데, 2부에서는 각 NoSQL 제품군들의 종류에 대한 간략한 소개가 들어있다. 정말 간략한 소개이기 때문에 1부만 보아도 충분할 것 같다. 그렇기에 이번 내용에도 거의 1부 내용만 소개하려고 한다. 내가 재밌게 읽었던 부분들은 다음과 같다. - NoSQL의 등장 배경과 특성  - aggregate data model의 특성- 일관성 / 분산 모델 / 맵 리듀스- 스키마 관련 이 책을 읽고나서 원래 가지고 있던 ..

문제 상품 전시(display)쪽이라 호출이 엄청 많기도 하고, 상품 보여줄 때마다 이 상품이 특정 상태의 상품인지 확인해야 하는 로직이 있다. 그 특정 상태는 PM분이 상태를 등록할 수 있도록 slack 메시지로 등록할 수 있게 만들어 둔 상태고, redis에 올려놓고 쓴다. 그런데 그 특정 상태를 체크하기 위해 매번 redis에 찌르면 redis 호출하는 횟수가 너무 많을 것 같아, client를 싱글톤 인스턴스로 만들고, 프로세스 전역에서 그 인스턴스만 쓰도록 구현을 해놓았다. class _SpecificGoodsRedisClient: def __init__(self): self._cached_specific_goods_list = [] def get_cached_spec..

엄밀히 말하면 내 업무는 아니긴 한데, 다른 분 리뷰를 봐주다가 COUNT 쿼리가 엄청 느린 케이스가 있었다. 상품에 대한 리뷰 보여주는 방법을 변경하는 실험이었다. 다른 경우에는 괜찮은데, 상품에 대해 리뷰가 많을 경우 리뷰에 대한 COUNT가 너무 느려지는 케이스가 있어 문제가 되었다. 대략 리뷰 수가 N만개가 넘어가면 느려지는 걸로 보였다. 이걸 어떻게 풀까 고민하면서 일단 1. 캐싱 2. 인덱스 3. 쿼리튜닝 정도가 생각났다. 그런데 리뷰 수가 많은 거면 인기 상품이라는 의미라 리뷰가 얼마든지 더 달릴 수 있는 거고, 리뷰 프로세스가 존재해서 특정 상태의 리뷰들만 사용자에게 노출하다 보니 캐싱하기 어려워서 어째저째 쿼리를 다시 짜는 걸로 해결했다. (기존 쿼리에선 DISTINCT 때문에 임시 테..

최근 일정에 엄청 쫒기면서 하는 프로젝트가 있다. 그러다 보니 빠르게 빠르게 뭔가를 하다 보면서 많이 타협을 보았는데, (+실험이라는 것도 컸다) 다시 생각해 보니 아쉬운 점들이 몇가지 있는 것 같아 생각을 정리해 보아야겠다. 요구사항은 꼭 분석하자이번 요구사항 중에, 이러이러한 상품들이 있고, 저러저러한 가격들이 있어요. 이런 엑셀 형태의 자료가 있었다. 가격들에는 정가, 1차 할인 가격, 2차 할인 가격이 적혀져 있었는데 너무 당연하게 가격의 크기가 정가 > 1차 할인가 > 2차 할인가 라고 생각했고, (실제로도 엑셀 상단에 있는 데이터들은 그런 꼴이었다. 스크롤을 많이 내리기 전까진) 그대로 API 설계하고, 코드도 작성했다. 그러나 웬걸, 버그가 계속해서 터졌다. 다시 보니 정가와 1차 할인가가 ..

사내에서 책 마이크로서비스 아키텍처 구축 스터디를 하고 있습니다. 이 책에서 나온 쇼피파이의 사례를 조금 더 찾아보고 사내에서 공유했는데 이때 자료를 올려봅니다 https://m.yes24.com/Goods/Detail/119319406 개요 쇼피파이는 이커머스 기업중 하나인데, 우리가 참고하기 좋은 구조겠다 싶어서 간단하게 요약도 해보고 참고 자료들도 일부 가져와 봤습니다. 각잡고 번역한 것도 아니고 영어 실력이 조악해서 틀릴 수 있으니 양해 바랍니다… 쇼피파이는 당시 직원 수가 4천 명이고, 판매자 수가 80만 명에 달하는 규모의 회사인데, Ruby on Rails로 구성되어 있습니다. (지금은 직원 수 9천명 조금 넘는 정도 되네요) (이때 당시 기록을 보니까 개발자는 한 1천명 정도 되는 규모였던..

개요 사내에서는 enum을 관리할 때 대부분 숫자코드를 사용한다. 처음에는 생쿼리를 볼때 뭘 의미하는지 몰라서 불편했는데, 순서가 있는 경우 꽤 편하다는 걸 느꼈고, 어떤 점들에서 좋은지 내 생각들을 적어보았다. (틀릴 수 있음 + 의견 환영) 쿼리를 볼때 헷갈리진 않나요? int로 관리할 때 이게 최대 단점인 것 같다. 쿼리만 봐서는 어떤 상태를 의미하는지 파악하기 어렵다. 그런데 한 편으로는 중요한 값들은 어차피 외우고 있기도 하고 (ex. order_item.processing_status=4 => 배송 완료) 애플리케이션에서 코드를 찾아보면 되니까 지금은 크게 불편한 점을 못느끼고 있다. 그리고 쿼리를 볼때 말고 칠때라면, 어차피 애플리케이션에서 어떤 값이 들어있는지 찾아봐야 한다. (ex. "배..