포스트

네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다

Tech Blog Review
게시 수정 작성자 August
좋아요 조회 12 분 읽는 시간
시리즈 빅테크 기술 블로그 리뷰 32편 중 8편 빅테크 기술 블로그 리뷰
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
  32. 32 Airbnb 「Avoiding double payments in a distributed payments system」 리뷰 — 네트워크와 DB 트랜잭션을 섞지 않는 세 단계, 재시도 가능 여부의 분류, 그리고 복제본을 읽으면 이중 결제가 나는 이유

원문: CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제 — NAVER D2, 김태성, 2025-04-08

한 줄 요약

네이버페이 주문 DB를 Oracle에서 사내 분산 DB(nBase-T)로 옮기고 Oracle을 복제본으로 돌리자, 복제용 UPDATE가 느려져 커넥션 풀이 말랐다. 원인은 Oracle이 같은 SQL 문장이라도 바인딩 값의 타입·길이가 다르면 별도의 child cursor를 만든다는 점이었다. 150개 컬럼짜리 UPDATE에 문자열 길이, NULL, 타임스탬프 자릿수가 제각각 들어오니 한 쿼리에 child cursor가 22,000개 넘게 생겼고, 응답이 0.003초에서 0.308초로 100배 넘게 느려졌다. 여덟 가지를 시도해 넷을 채택했고 child cursor가 99.8% 줄었다.

배경

Plasma 프로젝트로 주문 메인 DB가 nBase-T로 바뀌었고, 옛 Oracle은 CDC로 비동기 복제를 받는 쪽이 됐다. 그런데 호출량이 늘자 nBase-T → Oracle 동기화가 밀렸다. Pinpoint로 보니 Oracle의 UPDATE가 slow query가 되어 복제 서비스의 커넥션 풀을 고갈시키고 타임아웃을 냈다.

DBA와 로그를 보니 특정 Query ID 하나에 child cursor가 22,000개 이상이었다. 정상은 100개 이하다. 그 결과 라이브러리 캐시 잠금, 뮤텍스, 커서 대기가 늘어 성능이 떨어졌다.

Oracle은 쿼리를 어떻게 실행하나

이 문제를 이해하려면 parent cursor와 child cursor를 알아야 한다. 하드 파싱과 소프트 파싱의 정의는 Oracle SQL Tuning Guide에 있다.

  1. SQL이 오면 라이브러리 캐시에서 같은 문장이 있는지 찾는다.
  2. 같은 문장(parent cursor)이 있으면 그 밑의 child cursor를 본다. 없으면 하드 파싱(실행 계획을 처음부터 만드는 비싼 작업)을 한다.
  3. 바인딩 값의 타입이 맞는 child cursor가 있으면 재사용(소프트 파싱). 없으면 새 child cursor를 만든다(부분 하드 파싱).

child cursor를 만드는 것 자체는 정상이다. 문제는 각 cursor에 동시성 제어용 뮤텍스가 있고, 새 child cursor를 만들 때 잠금이 걸린다는 것이다. 그래서 같은 쿼리가 동시에 많이 들어오면 잠금 경쟁으로 대기가 길어진다. 내가 보기에 22,000개면 찾는 것도, 만드는 것도 느릴 수밖에 없다.

왜 child cursor를 재사용 못 했나

문장은 같은데 바인딩 타입이 안 맞는 세 가지 경우다. Oracle은 child cursor를 공유하지 못한 이유를 V$SQL_SHARED_CURSOR 뷰에 남기고, 이 경우의 BIND_MISMATCH 컬럼은 “The bind metadata does not match the existing child cursor”(바인드 메타데이터가 기존 child cursor와 맞지 않음)를 뜻한다(Oracle Database Reference).

케이스 1. 가변 길이 VARCHAR. Oracle은 바인딩된 문자열 길이에 따라 타입을 VARCHAR(32) → 128 → 2000 → 4000 단계로 자동 조정한다. 짧은 값이 오면 VARCHAR(32) child cursor, 긴 값이 오면 VARCHAR(2000) child cursor다. 컬럼 4개에 각각 다른 길이가 오면 최대 4⁴ = 256개 조합이다. 게다가 한 글자를 최대 4바이트(유니코드)로 계산하므로 테이블 정의가 VARCHAR(20)이라도 바인딩은 VARCHAR(128)로 잡힐 수 있다.

케이스 2. NULL 바인딩. 바인딩 시점에 Oracle은 테이블의 컬럼 타입을 보지 않고 입력값만으로 타입을 정한다. NULL이 오면 타입을 모르니 VARCHAR(32)로 잡는다. 숫자 컬럼이라도 NULL이면 VARCHAR, 값이 오면 NUMBER로 잡혀 child cursor가 둘이 된다.

케이스 3. NUMBER·TIMESTAMP의 자릿수. 소수점 이하 자릿수(scale)가 다르면 다른 타입으로 본다. 12:00:00은 TIMESTAMP(0), .123은 TIMESTAMP(3), .123456은 TIMESTAMP(6). 각각 child cursor다.

테스트로 재현했다. 같은 UPDATE를 다섯 번 실행하면서 col_1 길이를 늘리고(32→128→2000), col_3 타임스탬프 자릿수를 바꾸고(0→9), NULL이던 col_2에 숫자를 넣으니 child cursor가 정확히 1, 2, 3, 4, 5개로 늘었다. 상품 주문 테이블은 컬럼이 매우 많아 조합이 수십만 개까지 나올 수 있었다.

여덟 가지 시도

번호시도결과
1pstm.setNull()로 NULL 바인딩 타입 고정이것만으로는 부족
2SQL에서 CAST로 VARCHAR(4000) 강제효과 없음. 드라이버가 길이를 다시 계산
3pstm.setObject(scale)로 타입·자릿수 지정VARCHAR는 효과 없음, NUMBER에는 일부 가능성
4UPDATE 대상 필드 150개 → 100개줄었지만 정상(10~100)까지는 아님
5호출마다 랜덤 주석으로 parent cursor 분산뮤텍스 경쟁은 줄었으나 전체 cursor는 늘어 캐시 eviction 증가
6세션 이벤트 10503으로 VARCHAR 바인딩을 4000으로 고정고정은 되지만 평소 성능 저하 우려, 풀 전체에 영향
7큰 UPDATE를 둘로 분리(256 → 32 조합)줄었지만 DBA 비권장이라 미채택
8TIMESTAMP를 밀리초로 truncate 후 바인딩확연한 개선

8번이 흥미롭다. 원문에 따르면 nBase-T는 TIMESTAMP를 밀리초 단위로 만들기 때문에 복제 과정에서 자릿수 차이가 생겼다. 그래서 복제 시 DATE 타입 필드를 기존 Oracle 저장 방식과 같게 truncate해서 넣었고, 확연한 개선이 있었다. 케이스 3의 원인을 복제 쪽에서 없앤 셈이다.

최종 선택과 결과

채택은 1, 3, 4, 8이다. 원문이 밝힌 기준은 이렇다. 5·6·7은 뮤텍스 경쟁을 완화할 뿐 BIND_MISMATCH의 원인을 없애지 못한다. child cursor가 계속 생기면 장기적으로 DB 부하가 된다. 그래서 cursor가 계속 생기는 케이스 2(NULL, 1번으로 대응)와 케이스 3(자릿수, 3번과 8번으로 대응)을 없애는 데 집중했다. 3번은 원문도 효과가 확실하지 않다고 적었다. 케이스 1(VARCHAR 길이)은 완전히 못 잡았지만, 2·3이 잡히면 재사용이 어느 정도 되므로 알려진 이슈로 남겼다.

결과는 쿼리 성능이 안정되면서 child cursor가 99.8% 줄었다는 것이다.

왜 어려웠나

원문은 어려웠던 이유를 두 가지로 짚는다. 애플리케이션에서는 평소 감지가 안 되고 DB 수준 분석이 필요하다. 그리고 쿼리 튜닝만으로는 안 되고 서비스 단계(이 글에서는 드라이버 바인딩과 복제 로직)의 개선이 같이 필요하다. 나는 둘 다 정확하다고 읽는다. 원문은 또 상품 주문 테이블은 컬럼이 많아 문제가 드러났을 뿐, 이미 전환된 다른 테이블에서도 비슷한 현상이 있었을 가능성이 높고 이번 최적화로 같이 해결되었을 것이라고 적는다.

또 하나. 원문은 점진적 전환의 10% 트래픽 단계에서 문제를 일찍 발견해 큰 장애로 이어지지 않았다고 적는다. 내가 보기에 100% 단계였다면 장애였을 것이다.

읽고 남는 질문

  • 케이스 1을 근본적으로 잡는 방법이 없는지. 드라이버가 길이를 다시 계산한다면, 애초에 복제 측에서 컬럼 정의 길이에 맞춰 패딩하거나 setObject에 명시적 길이를 주는 확장 API가 있는지 궁금하다.
  • 시도 6(세션 이벤트)의 “평소 성능 저하 우려”가 실측인지 우려인지 구분이 안 된다. 복제 전용 풀이라면 풀 전체 영향도 감수할 만하지 않았을까.
  • 22,000개라는 수치는 문제 시점의 것이고, 99.8% 감소 후 절대 수가 얼마인지(정상 범위 100 이하에 들어갔는지)가 적혀 있지 않다.

한 줄로 가져가기

Oracle에 바인드 변수를 쓴다고 실행 계획이 재사용되는 것이 아니다. 값의 타입·길이·자릿수까지 같아야 하고, NULL과 타임스탬프 정밀도는 그것을 조용히 깨뜨린다.

참고한 자료외부 출처 3

외부 출처

TechBlog, Naver
Tech Blog Review Naver Oracle JDBC CDC Performance Cursor Bind Variable
Kafka와 메시징 데이터베이스 내부와 트랜잭션 Spring과 JVM 백엔드 장애 대응과 관측
이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

변경이력

2번 수정

  1. docs(posts): separate the sections of every post with a thematic break
  2. docs(techblog): cite sources and ease reading in naver-oracle-child-cursor-explosion

댓글

아직 댓글이 없습니다