최근 동료에게 이런 말을 들었다.RedLock은 노드마다 시계가 어긋나면 락이 깨질 수 있다. 생각해보니 정말 일리있는 말인것 같다. RedLock은 독립적인 Redis 노드를 이용해 과반수 이상의 키를 소유했는지 여부로 판단하는데 여러 노드 간의 시계열이 어긋나면 TTL에 의해서 키가 사라지고 락이 깨질 수 있을것 같다. 실제로 찾아보니 마틴 클레프만의 위험성을 강조한 글도 찾아 볼 수 있었다.https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html How to do distributed locking — Martin Kleppmann’s blogHow to do distributed locking Published by Ma..
시작하며사실 이전 글 포스팅을 짚어보면, Block VS Reactive(WebFlux) 비교, 가상 스레드(Virtual Thread)와 `synchronized` 까지 다루었었다.사실 그 이유는 내가 그때까지는 Java를 사용했었기 때문이다...하지만, 지금은 자연스럽게 코틀린을 사용하고 있고 자연스럽게 관심은 코루틴과 가상스레드의 비교가 너무 하고 싶었다.그래서 이번 포스팅에서는 JDK 25 기준 Virtual Thread와 Coroutine 을 비교하고 실측까지 해보려고 한다.개념 정리 먼저!모두가 알고 있는 내용들이지만 Coroutine에 들어가기 전에 간단한 개념 정리부터 하려고 한다.`lanuch`/ `async` 같은 구체적인 API로 들어가기 전에, 그 밑바탕이 되는 두 가지부터 짚고 가..
트래픽 급증으로 인한 장애세일이 시작이 되자 트래픽이 확 튀었다. 어느정도 예상했던 범위이지만 특정 페이지에서 조회가 급격히 증가하면서 APM 상에서 API 응답 지연이 눈의 띄게 확인됐다. 해당 페이지는 여러 항목을 한 화면에 모아 보여주는 페이지기 때문에 Redis 캐시에서 값을 꽤 여러개 읽어와야했는데, 트래픽이 평소의 몇 배로 튀니 그 지연이 드러났다. 원인이 발생했었던 코드의 일부분을 보니 아래와 같은 Redis 조회 코드가 존재했다.```kotlinval values = keys.map { key -> redis.get(key) }``` 캐시에서 읽어야 할 키를 `하나씩, 순서대로` 조회하고 있었다. 평소 트래픽에선 키가 몇 개 안 되니 티가 안 났는데, 세일 트래픽이 몰리면서 동시에 처리..
최근 사가 패턴(Saga Pattern)으로 포인트 적립 -> 결제 흐름 같은 프로젝트를 해보면서 여러 가지 서킷, Fallback, 분산락 등을 적용하고 성능 테스트를 해보고 있다.그런데, 최근 핫한 주제인 Temporal에 대해서 여기저기서 이야기가 많이 들리는것 같다.나도 이론적인 내용만 알고 있었고 실제로 사용해본적은 없는데 보상 트랜잭션 같은걸 처리하면서 Temporal로 한번 해볼까? 라는 생각이 들어서 토이프로젝트로 하나 만들어보면서 공부한 내용을 정리하려고 한다. 이번 포스팅의 목적은"이거 결국 Temporal이 다 해주는 거 아닌가?"라는 생각이 들어서 직접 같은 문제를 Temporal로 다시 풀어봤다. 일반적인 보상 트랜잭션과 Temporal을 이용한 방법을 비교해보자! Tempo..
Lockhttps://farmer-eom.tistory.com/1 Virtual Thread 너 좋다던데?최근 보안 이슈가 많이 발생하다보니 회사에서는 외부의 공격으로 부터 페이로드 변조를 검증하는 기능을 추가하게 되었다. 페이로드 검증 기능을 추가하고 보니 피크 타임 기준으로 504 에러가farmer-eom.tistory.com이전 포스팅에서 Virtual Thread 관련된 성능 테스트를 해보고 유의사항을 정리 했었다.그 유의사항 중에서 가장 기억에 남는 포인트는 Pinning 현상이었던것 같다.사실 JVM Lock 관련되어서 공부한지 너무 오래되기도 했고, 기존에 Velog에서 Tistory로 옮겨오면서 Virtual Thread 사용 시 문제가 됐었던 Pinning 현상의 주범인 Monitor ..
최근 보안 이슈가 많이 발생하다보니 회사에서는 외부의 공격으로 부터 페이로드 변조를 검증하는 기능을 추가하게 되었다. 페이로드 검증 기능을 추가하고 보니 피크 타임 기준으로 504 에러가 급증하는게 확인됐다. 이 문제를 해결하기 위해서 Read Write 서비스 분리, WebFlux 적용, 페이로드 검증 서비스 분리 등 여러 가지 방법들을 적용하면서 문제를 해결했었다. 지금 와서 다시 생각을 해본다면 Virtual Thread를 사용 해 볼 수 있지 않을까? 라는 생각이 든다. 이 글의 포스팅 목적은 생각 난 김에 해보자. 그리고 정리해보자! 의 목적이 크다. Virtual Thread 그게 뭐야?Virtual Thread는 JVM이 직접 스케줄링하는 경량 스레드로 기존의 "요청당 스레드" 동기 프로그래..