끝까지 가면 다 이겨

[k8s] Kubernetes 리소스 관계를 Lens 안에서 그래프로 보는 Extension

최근에 Lens Flow라는 Lens 확장 프로그램을 만들었다.한 줄로 말하면, Lens, OpenLens, FreeLens 안에서 Kubernetes 리소스 관계를 그래프로 보여주는 도구다.왜 만들었나Kubernetes를 보다 보면 리소스 하나만 보는 경우보다, 리소스 사이의 연결을 확인해야 하는 경우가 많다.예를 들면 이런 흐름이다.Ingress가 어떤 Service로 가는지Service 뒤에 어떤 Deployment가 있는지Deployment 아래에 어떤 Pod가 있는지workload가 어떤 ConfigMap, Secret, PVC를 쓰는지Lens를 쓰면 리소스 상세를 보기 편하다. 그래도 관계를 따라가려면 Ingress, Service, Deployment, Pod 화면을 계속 오가야 한다.이 흐..

[AlgorithmHub] LeetCode와 프로그래머스 풀이를 GitHub에 자동으로 남기는 크롬 확장 프로그램

최근에 AlgorithmHub라는 Chrome 확장 프로그램을 만들었다.한 줄로 말하면, LeetCode와 프로그래머스에서 정답 제출한 코드를 GitHub 저장소에 자동으로 남겨주는 도구다.왜 만들었나코딩테스트 문제를 풀다 보면 풀이 자체보다 기록을 남기는 일이 더 귀찮을 때가 있다.문제를 푼다.정답을 맞힌다.코드를 복사한다.GitHub 저장소에 폴더를 만든다.파일명을 정한다.커밋한다.이 과정이 한두 번이면 괜찮은데, 꾸준히 풀기 시작하면 꽤 번거롭다.이미 백준 쪽에는 BaekjoonHub가 있고, LeetCode 쪽에는 LeetHub 같은 좋은 도구가 있다. 나도 비슷한 흐름으로 LeetCode와 프로그래머스를 같이 관리하고 싶었다.그래서 만든 게 AlgorithmHub다.어떤 기능이 있나기능은 단순하..

[Spring Boot] read-after-write는 왜 깨질까

read-after-write의 개념read-after-write는 "내가 방금 쓴 데이터를 바로 다시 읽었을 때 최신 값이 보여야 한다"는 기대를 의미한다.이 개념은 너무 당연해서 처음에는 별 문제처럼 안 보인다. 보통은 이렇게 생각한다.글을 작성했다저장이 끝났다다시 조회했다방금 저장한 데이터가 보여야 한다단일 DB만 쓰는 구조에서는 이 기대가 대체로 맞다. 같은 primary DB에 쓰고, 다시 같은 primary DB에서 읽기 때문이다.문제는 read replica를 붙이는 순간부터 시작된다.read replica를 붙이면 왜 문제가 생길까원인은 primary와 replica가 항상 같은 시점의 데이터를 보장하지 않기 때문이다.MySQL read replica는 보통 asynchronous repl..

[Spring Boot] @Transactional(readOnly = true)로 read-write DB 분리한 방법

read/write DB 분리가 필요한 이유read-heavy 서비스에서는 조회와 쓰기를 같은 DB에 몰아두는 순간 primary가 병목이 되기 쉽다.QnA 서비스처럼 조회가 훨씬 많은 시스템에서는 질문 목록, 질문 상세, 프로필 같은 read 요청이 write보다 훨씬 자주 들어온다. 이때 모든 트래픽을 primary 하나가 받으면 read 부하가 write 성능까지 끌어내릴 수 있다.그래서 보통 역할을 나눈다.primary → insert, update, deletereplica → select문제는 replica를 붙이는 것보다, 애플리케이션 코드에서 어떤 요청을 어디로 보낼지 깔끔하게 제어하는 방식이다.이번 구현의 핵심 아이디어트랜잭션의 readOnly 여부를 read/write 라우팅 기준으로 ..

[Redis] 캐시 쇄도 현상은 왜 발생할까

TL;DR캐시 쇄도 현상은 캐시가 만료되는 순간 같은 요청이 한꺼번에 원본 저장소로 몰리는 문제다.Redis를 붙였더라도 재생성 동시성 제어가 없으면 DB나 외부 API가 먼저 버티지 못할 수 있다.실무에서는 보통 TTL 분산, 분산 락, 논리적 만료를 조합해서 대응한다.먼저 이 상황부터 떠올리면 쉽다인기 게시글 상세 조회 결과를 Redis에 넣어 둔다.평소에는 Redis가 값을 바로 반환하니 DB까지 가지 않는다.그런데 TTL이 끝나는 순간 같은 게시글을 보는 요청이 한꺼번에 들어온다.그러면 여러 요청이 동시에 DB를 조회하면서 같은 작업을 중복 수행한다.이게 바로 캐시 쇄도 현상 (Cache Stampede) 이다.캐시 쇄도 현상의 개념캐시 쇄도 현상은 많은 요청이 공통으로 참조하던 캐시 키가 만료되..

[Redis] 대기열 시스템 설계 : Redis로 줄 세우고 Kafka로 처리하기

TL;DR대기열 시스템의 앞단은 처리량보다 순번 조회, 중복 방지, 사용자 제어가 더 중요하다.이 역할에는 Kafka 같은 MQ보다 Redis Sorted Set 이 훨씬 잘 맞는다.보통은 앞단은 Redis로 줄 세우고, 뒷단은 Kafka로 처리량을 감당하는 구조로 나눈다.왜 이 이야기가 중요한가대규모 이벤트에서는 순간적으로 수십만 명이 몰릴 수 있다.대표적으로 아래 같은 상황이다.콘서트 티켓팅한정판 상품 판매선착순 쿠폰 이벤트이때 필요한 것은 단순히 요청을 많이 받는 구조가 아니다.서버를 보호하면서도, 사용자 입장에서는 지금 내가 몇 번째인지 보이고, 중복 요청은 막고, 필요하면 특정 사용자를 대기열에서 제거할 수 있어야 한다.이 관점에서 보면 대기열의 앞단은 MQ보다 Redis가 더 자연스럽다.대기열..

[Python] ABC

파이썬 ABC (Abstract Base Class)의 개념ABC (Abstract Base Class)는 파이썬에서 추상 클래스를 정의하기 위한 메커니즘이다. 추상 클래스는 직접 인스턴스화할 수 없고, 반드시 상속받아 구현해야 하는 클래스를 의미한다.abc 모듈의 ABC 클래스를 상속하거나 ABCMeta 메타클래스를 사용해서 만들 수 있다. ABC의 핵심 특징인스턴스화 불가: 추상 클래스 자체는 객체를 만들 수 없다강제 구현: 자식 클래스가 반드시 특정 메서드를 구현하도록 강제한다인터페이스 역할: 클래스가 가져야 할 메서드 시그니처를 정의한다 ABC가 필요한 이유파이썬은 덕 타이핑 (Duck Typing) 언어다. "오리처럼 걷고 오리처럼 운다면 오리다"라는 철학으로, 타입보다는 행동(메서드)에 초점을..

[Spring WebFlux] MVC와 WebFlux의 Exception 클래스

개요Spring MVC와 WebFlux는 각각 다른 방식으로 요청을 처리하기 때문에 예외 클래스에서도 차이점이 존재한다.기본적인 차이MVC는 spring-boot-starter-web 라이브러리를 사용하고 WebFlux는 spring-boot-starter-webflux를 사용하여 서로 다른 동작 방식을 갖는다.MVCServlet 기반 동기 방식으로 동작org.springframework.web.servlet 패키지의 예외 클래스 사용 가능WebFluxReactive Streams 기반 비동기 방식으로 동작org.springframework.web.reactive 패키지의 예외 클래스 사용 -> 이러한 차이로 인해, 예외 클래스에 차이가 발생하게 된다공통으로 사용되는 예외MVC와 WebFlux는 spri..

[Spring WebFlux] Spring WebFlux

Spring WebFluxSpring WebFlux는 기본적으로 Project Reactor 기반으로 동작하며, 서블릿 기반의 Spring MVC와 대비되는 리액티브 기반의 웹 스택이다.Spring MVC와 배타적으로 동작하지만 WebClient, annotation 등 일부 기능은 상호 운용이 가능단, 내부적으로 Blocking API가 포함되면 성능이 현저하게 낮아질 수 있다.기존 MVC 어노테이션 기반 방식기존의 Spring MVC에서 사용하던 @Controller, @RestController, @RequestMapping 등의 어노테이션을 그대로 활용할 수 있다. Functional Endpoints 방식기존 MVC 방식과 다르게 람다 스타일의 Routing 및 Handling 방식을 사용할 수..

[Spring WebFlux] WebClient

Spring WebClientSpring 5.0부터 RestTemplate가 향후 deprecated될 예정이고, 대안으로 WebClient가 등장해 사용을 권고하고 있다.기존의 동기 API를 제공할 뿐 아니라 Non-Blocking 및 비동기 접근 방식을 지원해서 효율적인 통신이 가능하다.요청을 나타내고 전송하게 하는 Builder 방식의 인터페이스를 사용한다.내부적으로 Netty를 사용하고 있기 때문에 event loop 방식으로 동작하고, Reactive Type인 Mono, Flux를 return하는 HTTP client이다.WebClient의 특징Non-Blocking I/OReactive Streams back pressureFunctional StyleSynchronous and asynch..

[Spring WebFlux] Reactive Streams

Reactive Streams리액티브 스트림은 JVM 환경에서 리액티브 프로그래밍의 표준 API 사양으로 비동기 데이터 스트림과 논블로킹 백프레셔에 대한 사양을 제공한다 스트리밍 처리요청이 오면 모든 데이터를 메모리로 가져와야 하는 전통적인 데이터 처리 방식과 다르게 스트리밍 처리 방식을 사용하면 메모리에 다 올릴 필요가 없기 때문에 크기가 작은 시스템 메모리로도 많은 양의 데이터를 처리할 수 있다.입력 데이터에 대한 파이프라인을 만들어서 데이터가 들어오는 대로 구독하고, 처리한 뒤 발행까지 한 번에 연결하여 처리한다. 비동기 방식리액티브 스트림은 비동기 방식으로 동작하여, 동기적인 처리 방식보다 효율적이며 논블로킹 방식으로 자원을 활용할 수 있다. 백프레셔백프레셔는 소비자가 처리할 수 있는 만큼만 데이..

[Spring WebFlux] Reactive Programming과 Design Pattern

리액티브 프로그래밍데이터 또는 이벤트의 변경이 발생하면 이에 반응해 처리하는 프로그래밍 기법비동기 프로그래밍을 처리하는 새로운 접근 방식데이터의 통지, 완료, 에러에 대한 처리를 Observer Pattern에서 영감을 받아 설계되었고, 데이터의 손쉬운 비동기 처리를 위해 함수형 언어의 접근 방식을 사용하는 특징이 있다. 기존 비동기 프로그래밍의 문제점과 리액티브 프로그래밍의 장점- 기존의 비동기 프로그래밍은 콜백 (Callback) 기반의 비동기 처리 방식을 사용했지만, 콜백이 많아져서 발생하는 Callback Hell로 인해 코드의 복잡도가 늘어나고 가독성과 유지보수성이 떨어지는 문제가 발생한다.→ 리액티브 프로그래밍을 적용하면 Callback Hell 없이 비동기 기반의 non-blocking과 E..