1223v

고민의 시작redis의 Redlock과 원자적 연산에 대해 개념을 헷갈리는 것 같아 정리했다.  RedLockredlock은 redis를 이용한 분산 락 알고리즘이다.redis를 여러 개의 인스턴스에서 실행할 때, 동일한 키에 대해 신뢰성 높은 락을 보장하는 방법단일 redis 노드에서 SETNX (SET if Not Exists)로 락을 구현하는 방식이 신뢰성이 부족한 문제를 해결하기 위해 고안됐다.  Redlock이 필요한 이유기본적으로 redis의 SETNX 를 사용하면 단일 인스턴스에서만 락이 보장된다.하지만 단일 Redis 서버가 다운되면 락이 풀릴 수 잇는 문제가 있다.이를 해결하기 위해 여러 개의 Redis노드에 락을 분산 저장하여 가용성과 신뢰성을 높이는 것이 Redlock의 핵심 아이디어..

고민의 시작 프로젝트을 진행하면서, 다른 사람들이 구현한 기능에는 간단한 지식만으로 알고 넘어간 부분이 있었다.하지만, 팀원이 구현한 코드 일지라도 우리 서비스에 대한 문제 해결 방식을 설명하기 위해 팀원이 구현한 해결 방법은 설명할 수 있어야 한다고 생각한다.번외로 만약 내가 구현했다면 어떻게 해결할 것인가? 라는 질문이 왔을때, 명확하게 대답하지 못하는 내 자신을 보고 아는것과 본 것에 대한 명확한 구분선을 지어야 겠다고 생각했다.    왜 이 고민이 필요해?💡 Race Condition 문제에서 MYSQL의 낙관적 락과 비관적 락으로 해결 했을때 어떤 장단점이 있는가? Redis 도입 시, 관리포인트 문제를 고려하지 않을 수 없다.만약, mysql로 쿠폰 발급을 한다면 어떻게 해결할 수 있을까? ..

고민의 시작우리 프로젝트는 MYSQL RT 저장 방식 ⇒ Redis RT 저장 방식으로 변경했다.그렇다면 고려해야하는 것이 redis가 다운되었을 경우의 복구 전략이다..💡 Redis 를 도입했을때 관리 포인트가 늘게 되는데 관리포인트가 느는 부분이 바로 redis가 다운 되었을 때에 대한 대처이다,,왜 이 고민이 필요해?현재 redis를 도입하는 대부분의 프로젝트들이 로그인에서 RT를 저장하는 부분일 것이다.사용자 ⇒ 로그인 시도 ⇒ at/rt 발급 ⇒ rt redis에 저장 ⇒ at/rt 반환 ⇒ 로그인 성공보통 토큰을 사용한 로그인은 위와 같은 과정을 따르는데,사용자 ⇒ 로그인 시도 ⇒ at/rt 발급 ⇒rt redis에 저장⇒at/rt 반환 ⇒ 로그인 성공redis가 다운된다면 다음 과정마저, ..

고민의 시작저번 내용에서는 토큰인지 세션인지에 대한 문제는 다루었다.그래서 여러 부분을 고려해 토큰을 채택했다.토큰을 채택하며, 보안을 위해 AT, RT를 분리하게 되었다.💡 이부분에서 RT를 어디에 보관해야 하는가? 로 했을때, 인메모리 스토리지로 여러가지 선택지가 존재했다.   왜 이 고민이 필요해?항상 관리 포인트를 늘리면서 기술을 도입하는 행위는 늘 아쉬움이 남았다.무엇보다도 인메모리 스토리지를 도입했을 때 기술 및 관리 포인트를 늘리 면서까지 기술을 도입했을때의 압도적인 강점이 존재해야 한다.그러기 위해서는 유사한 스펙을 가진 두 기술의 각 장점과 단점을 명확히 파악하고 현재 우리 서비스에 적합한 기술을 도입하는 것이 중요하다고 판단했다.  Redis vs MemcachedRedis의 장 / ..

Redis 란 무엇인가?Remote Dictionary Server의 약자대용량 처리 관련 기술   Redis의 특징디스크가 아닌 메모리 기반(In-Memory data structure)의 데이터 저장소NoSQL 과 Cache 솔루션이며 메모리 기반으로 구성명시적으로 삭제, Expire를 설정하지 않으면 데이터는 삭제되지 않는다.(영구적 보존)여러대의 서버 구성이 가능데이터베이스, Cache 등으로 사용될 수 있는 기술메모리 위에서 동작하는 Key/Value 저장소인 Redis는 NoSQL DBMS로 분류Memcached와 같은 인메모리 솔루션으로 분리성능은 서버에 따라 따르나 초당 2~10만회 수행 가능성능은 Memcached가 갖고 있는 좋은 점을 기반으로 만들어졌기 때문에 Memcached보다 우..

고민의 시작레디베리 점주의 주문접수 창이다.우리는 기본적으로 준 실시간성으로 데이터를 가져가기 위해서 폴링으로 데이터를 가져가고 있었다.그런데 어느날 학교 축제 주점의 결제 시스템으로 도입되게 되었고, 폴링에 따른 사용자도 늘어남에 따라서 CPU 사용량도 점점 올라가고 있는 상황이었다.또한, 축제가 끝난 뒤 기존으로 돌아와도 커피 스마트오더 특성상 점심시간 때, 혹은 2~3시에 주문이 피크였고, 그 이후에는 주문 수 적거나 아예 안들어오는 경우도 존재했다.💡 1. 주문이 없는 중에도 polling으로 계속 서버에 요청을 날리고 있음. 2. 사장님이 늘기 시작하면 polling에 따른 CPU 사용량과 네트워크 대역폭이 늘어남해결 가능한 방법론해당 글에서는 실시간 서버 푸시 요청, 응답에 대한 방법론 이야..

(ver.스프링부트 3.x , 스프링 시큐리티 6) 문제 인식Spring Security를 통해 세션방식 로그인 개발 진행 중,  로그인 시도 시 정상적으로 인증정보를 바인딩하고 있으나, 페이지 이동 시 인증정보가 없어지는 것을 발견했습니다.이에 해결과정과 코드를 공유하고자 합니다. 기존 코드의 문제점은 다음으로 추측했었습니다.SecurityContextPersistenceFilter란?  SecurityContextPersistenceFilter  SecurityContextPersistenceFilter는 Spring Security에서 매우 중요한 필터 중 하나로, HTTP 요청이 들어올 때 SecurityContext를 세션에서 복원하고, 요청이 완료되면 SecurityContext를 세션에 저장..

문제 인식통번역 플랫폼 개발 진행 중, 음원과 녹음 동시 작업 실행 시, 녹음의 품질이 저하되는 것을 발견했습니다.이에 해결과정과 코드를 공유하고자 합니다. 기존 코드의 문제점은 다음으로 추측했었습니다.   문제점 종합1. recorderDestination와 audioContext가 컴포넌트가 리렌더링될 때마다 새로 생성됨audioContext와 recorderDestination이 컴포넌트가 리렌더링될 때마다 새로 생성됩니다. React 컴포넌트는 상태 변화로 인해 여러 번 리렌더링될 수 있는데, 이때마다 새로운 AudioContext와 MediaStreamDestination이 생성되어 기존의 오디오 스트림이 무효화되거나 상태를 유지하지 못할 수 있습니다. 2. 비동기 처리 문제navigator.m..

고민의 시작 🌟🌟🌟보통 대학생 프로젝트를 진행하면, 개발 - 기획 - 디자인 - 마케팅의 영역이 명확하게 분리되어 있지 않고, 기한에 맞춰 데드라인 개발을 하는 경우가 많을거다. 그래서, 규모가 작은 프로젝트는 테스트를 작성하지 않고 진행하는 경우가 많고 이로 인해 모든 서비스가 의존하고 절차지향적 코드가 되며, 이후 유지보수가 힘들어지는 코드가 된다.또한, 모든 비즈니스 로직에서 발생하는 에러들이 서버를 돌리고 QA과정에서 발견되며, 이를 수정할 때 역시 단위별로 테스트할 수 있는 것이 아닌 유기적으로 연결되어있는 코드를 하나씩 따라가 보며 수정해야한다….필자는 이러한 문제를 서비스가 완성되고 리펙토링하면서 이것이 과연 객체지향적이라 할 수 있는가? 라는 의문이 들게 되었고, 테스트 코드를 작성해..