[NHN FORWARD 2021] Java에서 MySQL 비동기 쿼리 사용하기

NHN Cloud·nhn-forward-2021 ·2021년·

#mysql#java#performance-testing#async-io#jasync-sql#completable-future

AI 요약

게임 서버 GameAnvil의 database 대기 병목을 줄이려 Java에서 MySQL 쿼리를 비동기로 전환한 R&D와 벤치마크를 공유한다. 동기 쿼리가 여유 CPU를 두고도 logic을 멈춰 TPS를 낮추는 문제에서 출발한다.

핵심 포인트

Connection·thread pool을 늘리는 동기식 해법은 두 pool 크기를 맞춰야 하고 물리 자원 한계로 무한 확장이 안 돼, 쿼리를 보낸 뒤 다른 일을 하고 필요할 때 결과를 받는 비동기 처리를 근본 대안으로 검토
공식 X DevAPI는 session 1개에선 정상이나 10개에선 약 87%로 성능이 떨어지고, 소스 추적 결과 message callback과 dispatcher loop가 같은 dispatchingThreadMonitor에 매번 lock을 걸어 경합하는 code path를 원인으로 지목
Netty 기반 jasync-SQL은 NoSQL 기능·최신 인증은 없지만 session 증가에도 lock 문제 없이 동작하고 검증된 레퍼런스가 많아, 기능보다 실제 workload의 안정성·throughput을 우선해 선택
23대 VM·최대 4만 동접 테스트에서 2만4천 구간 jasync-SQL이 MyBatis 대비 약 2배 TPS를 기록하고, stored procedure로 트랜잭션을 묶어 비동기 API의 여러 round trip을 성능 감소 약 10% 수준으로 제한

왜 읽나DB 대기가 병목인 고동접 Java 서버에서 비동기 드라이버를 도입하며 드라이버별 lock 특성과 트랜잭션 round trip 함정을 실측으로 판단하려는 개발자에게.

챕터별 상세

010:10 – 4:44

동기 query 대기와 pool의 한계

Game server가 동기 query 결과를 기다리는 동안 여유 CPU가 있어도 logic을 멈춰 database 병목이 전체 TPS를 낮춘다. Connection pool은 연결 생성 시간을 줄이고 thread pool은 blocking 작업을 위임하지만, 두 pool 크기를 맞춰야 하고 물리 자원 때문에 무한히 늘릴 수 없다. Query를 보낸 뒤 다른 일을 하고 필요한 때 result를 받는 비동기 처리를 근본 대안으로 검토한다.

MySQL을 기본 guide로 쓰는 GameAnvil에 맞춰 공식 X DevAPI와 Kotlin·Netty 기반 jasync-SQL을 후보로 좁힌다. 두 방식 모두 CompletableFuture를 돌려주지만 API로 transaction을 열면 START TRANSACTION·query·COMMIT 또는 ROLLBACK round trip 동안 connection이 묶여 비동기의 성능 장점을 잃는다. 기능·인증·version 호환성과 transaction 처리까지 비교하는 R&D 기준을 세운다.

X DevAPI는 X Protocol과 executeAsync, JSON Document Store를 제공해 기대를 모았지만 session 한 개에서는 정상이고 열 개에서는 약 87%로 성능이 떨어진다. Source code를 따라가며 message callback과 dispatcher loop가 같은 dispatchingThreadMonitor에 매번 lock을 거는 것을 발견한다. Session이 늘면 여러 thread가 이 lock을 놓고 경합하므로 API 이름과 달리 충분히 비동기적으로 확장되지 않는 원인을 추정한다.

jasync-SQL은 connection pool에서 비동기 query를 실행해 CompletableFuture를 반환하는 고성능 driver이며 PostgreSQL과 R2DBC 생태계에서도 쓰인다. X DevAPI의 NoSQL 기능은 없고 이전 인증 방식만 지원하지만, Java·Spring 환경에서 검증된 reference가 많고 session 증가 시 lock 문제 없이 동작한다. 두 후보의 기능보다 실제 workload의 안정성과 throughput을 우선해 jasync-SQL을 선택한다.

CompletableFuture chain으로 결과를 가공하면 blocking 회피를 위한 thread 위임 code가 사라져 가독성과 생산성이 높아진다. 23대 VM에서 1만2천~4만 동접을 재현해 MyBatis·Hibernate·X DevAPI·jasync-SQL을 비교한 결과, 2만4천 명 구간에서 jasync-SQL이 MyBatis의 약 2배 TPS를 기록한다. Stored procedure 안에서 transaction을 묶으면 비동기 API의 여러 round trip을 줄이면서 성능 감소를 약 10% 수준으로 제한할 수 있다.