| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- prometheus
- kafka
- webflux
- 성능 최적화
- jvm
- Kubernetes
- docker
- 데이터베이스
- CloudNative
- 동시성제어
- netty
- redis
- Java
- mysql
- GitOps
- 트랜잭션
- SpringBoot
- RDBMS
- grafana
- DevOps
- monitoring
- NIO
- 백엔드개발
- 백엔드
- Kotlin
- JPA
- 성능최적화
- selector
- spring boot
- helm
- Today
- Total
목록SpringBoot (11)
유성
최근 Claude Code의 압도적인 성능을 경험하며, 이제 테스트는 더 이상 노동이 아닌 전략적 설계의 영역이 되었음을 확신했다.이 글에서는 테스트 코드에 대한 관점과 견해에 대해서 설명하고자 한다. 1. 거장들이 말하는 AI시대의 테스팅 철학우선 개발계의 유명한 분들의 생각을 먼저 보고 우리가 나아갈 좌표를 설정해보겠다.Kent Beck "TDD는 설계 도구이지, 검증 도구가 아니다"TDD의 창시자 Kent Beck은 AI가 코드를 짜주는 시대에도 TDD가 유효하다고 말한다.다만, 이제는 우리가 직접 Red 단계를 구현하는 것이 아니라, AI에게 "이런 제약 조건을 만족하는 테스트를 짜줘" 라고 지시하는 '의도의 설계' 단계가 Red를 대신하게 된다고 한다. 필자가 생각하기에도 코드는 초기 뼈대가 중..
[클라우드 네이티브] 3편: 고가용성 모니터링(메트릭) 아키텍처 설계 전략지난 1, 2편에서는 로그 수집의 핵심인 ELK 스택을 고가용성 환경으로 구축하는 방법을 살펴보았다.로그가 서비스에서 발생하는 "기록"을 추적한다면, 이번에 다룰 메트릭(Metric)은 시스템의 "상태youseong.tistory.com이전 글에서는 모니터링 구조 설계에 대한 이론적 배경을 살펴보았다.이번 실전 편에서는 ArgoCD와 Helm을 통해 실제 메트릭 모니터링 시스템을 구축하는 과정을 공유한다. 모든 인프라는 코드로 관리되며, 복잡한 설치 과정을 Helm 차트로 추상화하여 관리 효율을 높인다. 먼저, 실습에 사용할 인프라 구축 코드를 로컬 환경으로 가져오자.# 실습 코드 클론 및 체크아웃git clone https://g..
앞서 한차례 트랜잭션 범위에 대해서 글을 쓴 적이 있다.https://youseong.tistory.com/71 예외 발생 시 롤백 방지하기: Spring에서 독립적인 트랜잭션 설정 방법프로젝트에서 repository.save() 메서드를 사용했음에도 불구하고 데이터가 커밋되지 않는 문제를 겪은 적이 있습니다. 이 글에서는 문제의 원인과 해결 방법을 공유합니다. 트랜잭션 처리 방식문youseong.tistory.com 이번 글에서는 @Transactional 의 파라미터들을 뜯어보며 어떤 기능들이 있는지 확인해 본다.단순히 "붙이면 된다"를 넘어 이를 어떻게 활용할 수 있는지 하나하나씩 뜯어보자.(트랜잭션 의존성: spirng-tx:7.0.3) 1. 어떤 트랜잭션 매니저를 쓸 것인가? (Value, Tr..
이 글에서는 단순한 코드 전송을 넘어, 복잡한 환경에서 어떻게 안정적이고 효율적인 CI/CD 파이프라인을 구축했는지 그 설계 과정을 공유한다. 1. CI/CD란 무엇인가?: 규모에 따른 변칙적 대응CI/CD는 배포 파이프라인으로, 프로젝트의 규모와 팀의 운영 성격에 따라 매우 유연한 구조를 가진다.필자는 이를 크게 두 가지 배포전략으로 구분한다.작고 빠른 배포: main 브랜치에 코드가 병합되는 즉시 빌드부터 실서버 배포까지 자동화되는 방식이다. 빠른 피드백이 중요한 초기 프로젝트에 적합하다.큰고 신중한 배포: 병합 시 빌드와 검증은 자동으로 수행되며, 실제 배포는 관리자의 수동 트리거를 통해 결정하는 방식이다. 안정성이 최우선인 대규모 시스템에서 주로 채택한다. 이 두 방식 모두 자동화된 파이프라인을 ..
서버 운영 중에는 서버가 요청을 처리할 수 있는 여력이 있음에도, 의도적으로 요청을 차단해야 하는 순간이 있다.이는 특정 서비스의 문제가 전체 시스템으로 번지는 '장애 전파'를 막가 위한 필수적인 선택이다. 1. 왜 요청을 차단해야 할까? (장애 전파의 위험성)다음과 같은 서비스 구조를 가정해보자.A 서비스: 사용자 요청을 직접 받는 게이트웨이 역할 (리소스 풍부)B 서비스: 비즈니스 로직 처리 및 DB와 연결된 서비스DB: 현재 리소스 과부하 상태정상적인 요청 흐름: 사용자 -> A 서비스 -> B 서비스 -> DB 장애 발생 시나리오:DB 부하 발생: DB응답이 느려진다.B 서비스 병목: B 서비스는 DB응답을 기다리다 설정된 타임아웃(Timeout)에 걸리거나, 커넥션 풀이 고갈된다.A 서비스 장애..
R2DBC와 Mono를 사용하면서 기본적인 CRUD를 만들어보며 경험했던 것들 중 경험한 것들에 대해서 설명한다.아마 새롭게 Webflux를 도입하면 비슷한 문제들과 새로운 경험을 할 수 있을것이다.1. WebFlux, 왜 쓰는 걸까?전통적인 Spring MVC는 Thread-per-request 모델로, 요청이 오면 스레드 하나를 할당하고, DB응답이 올 때까지 그 스레드는 아무것도 못 하고 기다린다. 반면 WebFlux는 적은 수의 스레드로 수많은 요청을 처리하는 이벤트 루프 방식이다. 기다리는 시간 동안 스레드가 다른 일을 할 수 있게 해주는 것이 핵심이다. 이번 글에서는 가장 기초적인 R2DBC를 활용한 비동기 CRUD를 살펴보자. 2. 의존성 설정 (R2DBC)WebFlux를 쓰면서 가장 복잡한..