올리브영 재고 시스템 분석튜터님에게 발표한 내용을 기반으로 글을 작성하려고 한다. 위 그림은 레거시 서버에서의 올리브영이 겪고 있는 문제이다. 레거시 모놀리딕 서버에 여러 서버가 접근하여 재고를 파악하기 때문에 트래픽이 몰리는 피크 시간대에 DB에 부담이 전해질 수 있는 상황이다. 이를 해결하기 위한 올리브영의 기존의 시도는 무엇이 있을까? 배치 + 캐시 캐시처리를 통해 RDB까지 접근하지 않아도 인메모리방식으로 빠르게 데이터를 조회할 수 있도록 하고, 쓰기 처리는 배치작업을 통해 일정량을 묶어 주기적으로 처리할 수 있는 방식을 사용한 것으로 보았다.이 방식에서도 분명 한계점은 존재한다. Caching처리는 TTL이 존재하기에 만료시간에는 DB에 다시 접근해야 할 수 있고 DB와 캐시의 정합성또한 고려해..

Redis 특징Key-Value 방식으로 저장된다.컬렉션을 지원해서 다양한 타입으로 저장 가능하다.Pub/Sub 기능을 지원한다. 이 방식은 채팅이나 이벤트 소싱 방식에서 사용할 수 있다.디스크 저장이 가능하다. 메모리에 데이터를 저장하여 휘발성메모리라고 하지만 AOF/RDB 방식을 사용해서 영구적인 저장이 가능하다. 하지만 성능적인 측면에서 저하된다거나 중간에 데이터가 유실될 수도 있다는 단점이 있다.복제가 가능하다. Master/Slave 구조를 지원한다. 또한 샤딩을 사용해서 수평적인 확장이 가능하다.메모리를 통해 데이터를 조회하기 때문에 빠른 속도로 데이터를 처리한다.Redis의 타입 정리Redis 기본 개념, 자료구조Redis는 가장 자주 기본적으로 사용하는 구조는 다음과 같다. 각 타입의 특성..

오늘 한 일과외 준비Redis 완강ElasticSearch 문서 정리작업 내용과외 준비오랜만에 숨고에서 요청 받은 과외를 진행한다. 내용은 스프링에 대한 기본 과외였다. 내가 정리한 항목은 스프링이 어떻게 작동하는지, 디스패처 서블릿의 작동 원리, 스프링의 3대 특징 DI/IoC, AOP, PSA, 그리고 스프링에서 사용할 수 있는 다양한 프레임워크들이다.그에 대한 내용 정리는 아래 노션 페이지에 정리 해뒀다!스프링 기본 과외 Redis 완강레디스는 이전이 정리를 한 번 해뒀기에 다시 정리하기보다 기존의 내용들을 수정하는 것이 더 좋다고 판단했다. 아래 기록들을 차례대로 훑어보면서 하나씩 틀린내용이나 추가해야 할 기록들을 확인하려고 한다.레디스 기본 개념 및 자료 구조레디스 문서 정리 Search Wit..

Redis를 사용해서 검색어 자동 기능검색을 구현하려고 할때 두 가지 방법으로 구현이 가능하다. 단, 조건은 중간 단어 검색이 아닌 첫 글자를 기준으로 검색했을때를 기준으로 선정한 방법이다.검색 엔진, 추천 시스템, 그리고 실시간 키워드 자동완성 기능은 사용자 경험(UX)을 크게 향상시킨다. 이러한 기능을 구현하기 위해 주로 사용되는 두 가지 접근법은 Trie 알고리즘과 Redis ZSET이다.이 글에서는 Trie와 Redis ZSET을 비교하고, 키워드 자동완성 기능에 어떤 방법이 더 효율적인지 살펴본다.1. Trie 알고리즘이란?Trie는 접두사 트리(Prefix Tree)라고 불리며, 문자열의 공통 접두사를 공유하는 자료구조다.Trie의 주요 특징접두사 검색에 최적화: 입력된 문자열의 접두사를 기준..

[공부 주제]오늘 공부해 볼 내용은 컴퓨터의 전반적인 부품이다. 위 내용들에 대해 모두 다룰 것이지만 내가 사용하는 캐시처리에 대해서 조금 더 집중적으로 알아 보려고 한다.Redis를 사용하는 방법이 왜 Inmemory인지 그리고 왜 그게 RDB보다 더 빠른지 이번 기회에 확실하게 개념을 다잡고자 한다.   [주제1] CPU명령어를 이해하고 처리하는 동작을 수행하는 CPU는 아래 기능을 수행한다.명칭약어/fullName역할산술논리연산장치ALU / Arithmetic and Logic Unit사칙 연산, 논리 연산과 같은 우리 뇌에서 처리하는 역할이다. 실질적인 연산은 여기서 수행된다.제어장치CU / Control Unit명령어를 해석해서 제어 신호(전기 신호)로 내보낸다. CPU가 메모리를 향해 제어 신..

수많은 우여곡절 끝에 배포된 서버에 채팅 기능을 적용하게 되었다!간단히 말하자면 원래 담당했던 백엔드 팀원이 던져놓은 빅 똥을 치우게 되었다.내 프로젝트의 스택은 아래와 같다.Java 17 / Spring 3.x / JPA / Redis / Spring Security / JWT / OAuth / Websocket / MySQL / Firebase그리고 처음 팀원이 던져놨던 채팅 구현을 위한 기능은 Kafka + Socket.io 였다. 내가 알기로 Kafka는 MSA구조에서 그룹으로 묶어 메세지를 전달하는 메세지 큐 방식에 적합한 절대 가볍지 않은 스펙의 프레임워크였으며, Socket.io 또한 Spring으로 만든 프로젝트가 아닌 별도로 서버가 생성되는 과정을 요구하는 방식이였으나 팀원을 믿고 기다렸..