기록

이번에 프록시에 대해 정리하면서, 단순한 개념 설명을 넘어서서 실무에서 Proxy와 ProxySelector를 어떻게 선택하고 적용할지에 대한 전략까지 정리해봤습니다.Java/Kotlin 기반의 Spring 프로젝트에서 HTTP 요청을 외부 프록시 서버를 거쳐야 하는 환경이라면 필수적으로 알아야 하는 내용입니다.Proxy vs ProxySelector 실무 기준 비교 분석개발 경력 5년 차인 제 입장에서 이 둘의 차이는 단순한 API 수준의 차이가 아닙니다. 프록시를 어떻게, 얼마나 유연하게 적용할 수 있는가에 대한 아키텍처적 결정 요소라고 생각합니다.Proxy – 단순하고 명시적인 설정 방식java.net.Proxy는 개별 요청에 대해 직접 프록시를 지정할 수 있습니다. 테스트나 제한된 상황에서 매우 ..

이번에 팀 프로젝트에서 외부 공공 API를 연동하면서 Spring 6에서 새롭게 도입된 RestClient를 사용해볼 일이 있었다.기존에 쓰던 RestTemplate이나 WebClient랑 비교해도 꽤 직관적이고 깔끔해서 앞으로 메인으로 써볼 만하겠다는 생각이 들었는데, 프록시 환경에서 설정하는 과정에서 몇 가지 삽질이 있었다.이 글에서는 RestClient의 기본 설정부터, 프록시(proxy) 환경에서 어떻게 세팅하는지에 대해 내가 겪은 내용과 함께 정리해본다.RestClient에 대해 간단히 정리하면Spring 6부터 등장한 RestClient는 기존의 RestTemplate보다 더 직관적이고 builder 기반으로 작성할 수 있는 HTTP 클라이언트다.내부적으로는 HttpComponentsClien..

최근에 TDD를 다시 보게 되면서, 혼자 끄적이던 생각과 고민이 조금씩 정리가 되었습니다.사실 처음에는 TDD를 그냥 '테스트 코드 먼저 작성하는 방식' 정도로만 알고 있었는데요,이번에 프로젝트를 진행하면서 "테스트가 코드의 방향을 결정할 수도 있다"는 걸 체감하게 되었습니다.TDD는 단순히 테스트를 먼저 짜는 게 아니더라구요보통은 기능을 먼저 구현하고 테스트 코드를 나중에 붙이는 경우가 많잖아요? 그런데 TDD는 반대입니다.테스트 코드를 먼저 작성하고, 그 테스트를 통과할 수 있는 최소한의 코드를 작성한 뒤, 마지막에 리팩토링을 진행합니다.이게 단순히 순서만 바뀌는 게 아니라, "어떻게 코드를 짤 것인가" 자체가 달라집니다. 단계 설명Red실패하는 테스트를 먼저 작성합니다Green테스트를 통과시키기 위..

k6 사용법 & 실무 활용 방법 정리최근 서비스 성능 테스트를 진행할 일이 있어서 k6라는 도구를 사용하게 됐는데, 생각보다 사용법이 굉장히 직관적이고 깔끔해서 정리해두면 좋을 것 같아서 글로 남겨본다.특히 Web API나 REST 기반 서비스라면 JMeter보다 훨씬 간단하게 부하 테스트를 해볼 수 있어서 입문자나 실무 개발자에게 추천할 만한 도구다.k6 설치 방법로컬 기준 (Mac / Homebrew)brew install k6그 외 윈도우나 리눅스는 아래 공식 사이트 참고하면 바로 설치 가능하다.https://k6.io/docs/getting-started/installation/k6 기본 예제 스크립트k6는 JavaScript 기반으로 스크립트를 작성하게 되어 있다. 기본적인 GET 요청 부하 테..

최근 Java 8에서 Java 21로 업그레이드하면서 JVM 내부 구조나 GC 동작 방식에 많은 변화가 있었다.버전 업그레이드를 진행하면서 단순히 버전 숫자만 올라간 것이 아니라, 메모리 관리 방식, GC 동작 원리, 그리고 이에 따른 서비스 성능에도 다양한 영향을 미치게 되었다.이번 글에서는 Java 8과 Java 21을 기준으로 GC와 JVM 메모리 구조의 변화, 그리고 이러한 변화가 실무에 어떤 영향을 주는지 정리해본다.Java 8 vs Java 21 핵심 변화 정리항목 Java 8 Java 21 변화 포인트기본 GCParallel GCG1 GC안정성 중심으로 변경추가 GC없음ZGC, Shenandoah초저지연 GC 등장PermGen 영역존재삭제, Metaspace로 통합OutOfMemory 리스크..

이번에 Kubernetes Canary 배포를 하면서 제일 크게 배운 내용 중 하나가 바로 이거였다."카나리 파드만 있고, 스테이블 파드가 하나도 없으면 왜 API 호출이 안되는가?"처음에 진짜 의문이었다. 헤더에 X-Canary: true 붙이면 Canary Ingress로 가니까 Stable 파드 없어도 되는거 아닌가? 이렇게 생각했는데... 현실은 전혀 아니었다.결론부터 말하면NGINX Ingress 구조 상 Canary Ingress는 "보조"일 뿐이고 "메인"은 항상 Stable Ingress다.Stable Ingress → 기본 처리 대상Canary Ingress → 조건 맞을 때 일부 트래픽만 처리 (override)Stable Ingress가 없는 상태에서는 Canary Ingress만 있..

최근에 Kubernetes에서 새로운 버전을 배포하면서 canary 트래픽 테스트를 해봤다.기존 파드를 유지한 채로, 새로운 버전의 파드를 하나만 띄우고 인그레스에서 일부 트래픽만 넘기는 구조를 목표로 했는데, 생각보다 시행착오가 많았다. 아래는 그 과정에서 겪었던 실수들과 해결했던 방법들을 정리한 내용이다.1. Deployment의 selector와 labels가 안 맞을 때처음엔 아래와 같이 새로운 Deployment를 구성했다.spec: selector: matchLabels: app: example-app-v2 version: canary template: metadata: labels: app: example-app version..

이번에 Kubernetes에서 Canary 배포를 적용하면서 여러 가지 개념과 동작 원리에 대해 스스로 정리할 수 있는 기회가 있었다. 처음엔 단순히 Ingress에 canary-weight만 붙이면 되는 줄 알았는데, 막상 해보니까 생각보다 훨씬 깊은 구조와 동작 흐름이 숨어 있었다.1. Ingress는 어떻게 트래픽을 나누는가?처음엔 궁금했다. Ingress 리소스에 연결된 Service는 하나인데, 어떻게 요청이 Canary와 Stable로 나뉘지? 알고 보니 Ingress 리소스는 여러 개를 만들 수 있고, 동일한 host와 path를 가진 Ingress가 두 개 있을 때, 그중 하나에 nginx.ingress.kubernetes.io/canary: "true"와 같은 annotation을 붙이면..

회사에서 서비스를 쿠버네티스에 띄워두고 있다 보니, 간단한 부하 테스트를 해보고 싶었다. 마침 팀원한테 이런 조언을 들었다.“E2E 테스트의 request body 참고해서 부하 테스트 해보시면 좋을 것 같아요. 매트릭스 APM 연동도 하시고, 기존 운세DA랑 같은 리소스를 할당한 파드에서 시스템 리소스 사용률도 같이 확인해보시면 좋을 것 같습니다.”처음 들으면 뭔가 말이 어려운데, 하나씩 정리해보면 생각보다 단순하다.💡 요약E2E 테스트에서 쓰는 request body를 부하 테스트에도 활용하자.APM 연동해서 시스템 내부에서 뭐가 느려지는지도 같이 보자.실제 서비스랑 동일한 리소스가 설정된 파드에서 테스트를 돌려서, CPU나 메모리 사용량 변화를 보자.k6로 부하 테스트 하기부하 테스트 도구는 여러..