고민보단 실천을

Playwright E2E 테스트 실전: flaky 테스트 줄이는 대기/selector/네트워크 전략E2E 테스트는 flaky가 많아지면 팀이 곧 무시하게 된다. Playwright 기준으로 실패율을 낮추는 규칙과 예시를 정리한다.sleep 대신 조건을 기다리기await page.goto('/login');await page.getByRole('button', { name: 'Login' }).click();await expect(page.getByText('Welcome')).toBeVisible();selector 전략: 의미에 붙기data-testid 같은 테스트용 속성을 표준으로 둔다.DOM 구조(nth-child)에 의존하는 selector는 피한다.접근성 기반 selector(getByRole..

Kafka 재시도 토픽/딜레이/ DLQ 설계: 실패를 '멈춤'이 아니라 '흐름'으로 만들기컨슈머가 실패했을 때 같은 메시지에서 계속 실패하면 파티션이 막힌다. 재시도/지연/DLQ를 설계해 실패를 흐름으로 만들어야 한다.기본 패턴main topic: 정상 처리retry topic: 일정 지연 후 재처리DLQ: 최종 실패를 모아 분석/재처리지연을 만드는 방법여러 retry 토픽(retry-5s, retry-1m...)로 단계를 둔다.컨슈머에서 sleep으로 지연하지 않는다(파티션 막힘).DLQ에 남겨야 하는 정보event_id(또는 message key)실패 reason(코드/요약) + stacktrace(또는 축약)원본 payload(또는 참조 위치)와 재처리 횟수최초 발생 시각/마지막 시각재처리(Repl..

HTTP 커넥션 풀/Keep-Alive 실전: 타임아웃, 재사용, 커넥션 누수로 장애 나는 패턴의외로 HTTP 커넥션(keep-alive/풀) 때문에 장애가 나는 경우가 많다. 풀 고갈/누수/타임아웃을 운영 관점에서 정리한다.OkHttp 설정 예시val client = OkHttpClient.Builder() .connectTimeout(300, TimeUnit.MILLISECONDS) .readTimeout(800, TimeUnit.MILLISECONDS) .callTimeout(1000, TimeUnit.MILLISECONDS) .connectionPool(ConnectionPool(50, 30, TimeUnit.SECONDS)) .build()커넥션 누수의 전형적인 원인응답 바디를 끝까지 ..

GitHub Actions 동시성 제어: concurrency + cancel-in-progress로 배포 경합 막기같은 환경에 배포가 동시에 돌면 마지막 커밋이 아닌 버전이 올라가거나 롤백이 뒤섞인다. concurrency로 경합을 막는 최소 설정을 정리한다.설정 예시concurrency: group: staging-${{ github.ref }} cancel-in-progress: true환경 단위로 그룹 나누기staging은 최신 커밋만 남기기(cancel-in-progress=true).prod는 순차 실행이 안전할 때가 많다(cancel-in-progress=false).그룹 키에 환경을 반드시 포함한다(섞여 취소되는 사고 방지).concurrency: group: prod-${{ gith..

DB 데드락 실전: 원인(락 순서) 분석과 재시도/쿼리/인덱스로 줄이는 법데드락은 대부분 락 획득 순서가 서로 다르기 때문에 생긴다. 원인 분석과 예방/완화(재시도) 전략을 정리한다.전형적인 예시-- Tx ABEGIN;UPDATE accounts SET balance = balance - 100 WHERE id = 1;UPDATE accounts SET balance = balance + 100 WHERE id = 2;COMMIT;-- Tx B (순서 반대)BEGIN;UPDATE accounts SET balance = balance - 50 WHERE id = 2;UPDATE accounts SET balance = balance + 50 WHERE id = 1;COMMIT;데드락을 줄이는 3가지 큰 ..

Contract Testing(Pact) 입문: API 변경을 '사고'가 아니라 '검증'으로 바꾸기API 변경이 무서운 이유는, 언제 깨질지 모르기 때문입니다. 계약 테스트는 그 불확실성을 줄입니다.Pact를 기준으로 소비자/제공자 테스트를 어떻게 운영하면 효과가 나는지 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 반복하지..

Transactional Outbox 패턴: DB 트랜잭션과 이벤트 발행을 안전하게 묶기목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.이 글이 필요한 사람분산 환경에서 정합성/재처리/복구가 자주 문제 되는 팀이벤트 기반/비동기 처리로 확장하려는데 운영 난이도가 걱정되는 팀장애 때 '수동 복구'가 아니라 '복구 루틴'을 만들고 싶은 팀추천 기본값(실무에서 안전한 시작점)중복/재처리는 정상 케이스로 가정(at-least-once 전제)복구 가능성을 우선: ..

Saga 패턴 실전: 오케스트레이션 vs 코레오그래피, 보상 트랜잭션 설계목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.이 글이 필요한 사람분산 환경에서 정합성/재처리/복구가 자주 문제 되는 팀이벤트 기반/비동기 처리로 확장하려는데 운영 난이도가 걱정되는 팀장애 때 '수동 복구'가 아니라 '복구 루틴'을 만들고 싶은 팀추천 기본값(실무에서 안전한 시작점)중복/재처리는 정상 케이스로 가정(at-least-once 전제)복구 가능성을 우선: 로그/백로그/리..

Kubernetes Probe 제대로 쓰기: liveness/readiness/startup 차이와 장애 사례목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.이 글이 필요한 사람배포/운영 중 5xx/타임아웃/리소스 고갈이 간헐적으로 터지는 팀Kubernetes/Nginx/Docker 같은 인프라 설정에서 원인 찾는 시간이 긴 팀장애를 '재현/측정/완화' 순서로 표준화하고 싶은 팀추천 기본값(실무에서 안전한 시작점)시간 예산(타임아웃)과 종료(드레인)를 먼..