JDBC 동작 원리

 

Mysql Statement Cancellation tiemr 관련 에러를 찾아보다가 찾게 된글

 

JDBC 동작 원리에 대해 자세히 설명이 되어있다.

 

한번쯤 읽어보면 도움이 될듯한 글

 

원본글 http://helloworld.naver.com/helloworld/1321

 

 

NHN Business Platform 웹플랫폼개발랩 강운덕

성능 문제나 장애가 발생할 때 중요하게 살펴보는 부분(tier)은 WAS(Web Application Server)와 DBMS입니다. 대부분의 경우에 WAS를 담당하는 조직과 DBMS를 담당하는 조직이 달라, 각자 담당 분야를 중심으로 상황을 파악하려 합니다. 이때 상대적으로 관심을 못 받는 사각지대가 생기는데, 바로 WAS와 DBMS 사이입니다. Java 애플리케이션을 기준으로 말하면 DBCP와 JDBC입니다. 이 글에서는 JDBC의 타임아웃 설정을 중심으로 장애에 대응하는 방법을 설명하겠습니다.

어느 날 DDoS 공격, 그 뒤로 먹통이 된 WAS

다음과 같은 사고가 일어났다고 가정해 보자.

DDoS 공격으로 서비스 전체가 정상적으로 동작하지 않았다. L4가 정상으로 동작하지 않아 네트워크가 단절되었고, 이로 인해 WAS도 동작 불능 상태에 빠졌다. 이후 보안팀에서는 DDoS 공격을 전부 차단했고, 네트워크도 정상으로 복구되었다. 그러나 WAS는 여전히 동작 불능 상태이다.

서비스팀에서는 WAS의 ThreadDump를 통해 JDBC의 API 호출 중에 WAS가 정지해 있음을 확인했다. 10분이 지나고 20분이 지나도 WAS는 여전히 정지 상태(WAITING)였고, 서비스는 정상으로 동작하지 않았다. 그런데 30분이 지날 무렵 갑자기 Exception을 발생시키면서 서비스가 복구되었다.

QueryTimeout 값도 3초로 설정되어 있는데 왜 30분씩이나 WAS가 정지 상태에 있었으며, 30분이 지나니 왜 정상적으로 WAS가 동작했던 것일까?

정답은 JDBC의 타임아웃 과정을 이해하면 알 수 있다.

왜 JDBC 드라이버에 대해서 알아야 하는가?

JDBC는 DBMS에 접근하기 위한 표준 API이다. Sun은 4가지 타입의 드라이브를 정의하는데, NHN에서 주로 사용하는 것은 Type4 형식이다. JDBC Type4 드라이버는 Java로만 작성되어 있으며(pure java), Java 애플리케이션에서 소켓을 이용해 DBMS와 통신한다.

그림 1 JDBC Type4 드라이버의 DBMS 통신 구조

Type4 드라이버는 소켓을 통해 바이트 스트림(byte stream)을 처리하기 때문에 HttpClient 같은 네트워크 라이브러리와 근본적으로 동작이 같다. 즉, 많은 CPU자원을 소모하고, ResponseTime의 손해가 있으며, 다른 네트워크 라이브러리가 가지고 있는 장애 포인트를 동일하게 가지고 있다. HttpClient를 사용한 경험이 있다면 타임아웃 값을 제대로 설정하지 않아 장애(hang)가 발생한 상황을 겪어 보았을 것이다. Type4 드라이버 역시 SocketTimeout 값을 제대로 설정하지 않으면 동일한 장애가 발생할 수 있다.

JDBC 드라이버의 SocketTimeout 값을 어떻게 설정하면 좋을지, 그리고 무엇을 고려해야 히는지 알아보자.

WAS와 DBMS의 통신 시 타임아웃 계층

그림 2는 WAS와 DBMS와 통신 시 타임아웃 계층을 단순화한 것이다.

그림 2 타임아웃 계층

상위 레벨의 타임아웃은 하위 레벨의 타임아웃에 의존성을 가지고 있다. 하위 레벨의 타임아웃이 정상으로 동작해야 상위 레벨의 타임아웃도 정상으로 동작한다. 예를 들어, JDBC Driver SocketTimeout이 정상으로 동작하지 않으면, 그보다 상위 레벨의 타임아웃인 StatementTimeout과 TransactionTimeout도 정상으로 동작하지 않는다.

"StatementTimeout을 설정했는데도 네트워크 장애가 발생했을 때, StatementTimeout이 동작하지 않아 애플리케이션이 장애 상황에서 회복되지 않았어요"란 문의를 많이 받았다. StatementTimeout은 네트워크 연결 장애에 대한 타임아웃을 담당하는 것이 아니다. StatementTimeout은 Statement 한 개의 수행 시간을 제한하는 기능만 담당한다. 네트워크 장애에 대비하는 타임아웃은 JDBC Driver SoecketTimeout이 처리해야 한다.

JDBC Driver SocketTimeout은 OS의 SocketTimeout 설정에 영향을 받는다. JDBC Driver SocketTimeout을 설정하지 않아도 네트워크 장애 발생 이후 30분이 지나면 JDBC Connection Hang이 복구되는 것은 OS의 SocketTimeout 설정때문이다.

그림 2에서 DBCP Connection Pool이 타임아웃 계층과 분리되어 왼쪽에 있는 것을 볼 수 있다. DBCP는 Connection을 생성하고 관리하는 일을 하며, 타임아웃 처리에는 관여하지 않는다. DBCP 내부에서 Connection을 생성하거나 Connection 유효성을 확인하려 Validation Query를 보낼 때에는 SocketTimeout이 영향을 주지만 애플리케이션에 직접적인 영향을 주지는 않는다.

단, 애플리케이션 로직에서 DBCP에 getConnection() 메서드를 호출할 때 Connection을 애플리케이션이 얻을 때까지의 타임아웃을 지정할 수 있다. 하지만 이것은 JDBC의 ConnectTimeout과는 무관하다.

그림 3 각 레벨 별 타임아웃

TransactionTimeout이란?

TransactionTimeout은 프레임워크(Spring, EJB Container)나 애플리케이션 레벨에서 유효한 타임아웃이다.

TransactionTimeout은 생소한 개념일 수 있다. 간단히 설명하면 "StatementTimeout x N(Statement 수행 수) + α(가비지 컬렉션 및 기타)"라고 할 수 있다. 전체 Statement 수행 시간을 허용할 수 있는 최대 시간 이내로 제한하려 할 때 TransactionTimeout을 사용한다.

가령 Statement 한 개를 수행할 때 0.1초가 필요하다면, 몇 개 안 되는 Statement를 수행할 때에는 문제가 없다. 그러나 Statement 10만 개를 수행할 때에는 일만 초(약 7시간)가 필요하다. TransactionTimeout은 이런 경우에 사용할 수 있다.

실 구현체로 EJB CMT(Container Managed Transaction)가 가장 대표적인 예이다. EJB CMT는 제작사마다 구현 방식과 동작 과정이 다르다. NHN에서는 EJB Container를 사용하지 않으므로, 가장 익숙한 예는 Spring의 TransactionTimeout이 될 수 있겠다. Spring에서는 다음과 같이 XML을 이용하여 설정하거나, Java 코드에서 @Transactional을 이용하여 타임아웃을 설정할 수 있다.

?

1 2 3

<tx:attributes> <tx:method name="…" timeout="3"> </tx:method></tx:attributes>

Spring에서 제공하는 TransactionTimeout은 매우 단순하다. 해당 Transaction의 시작 시간과 경과 시간을 기록하면서, 특정 이벤트 발생 시 경과 시간을 확인하여 타임아웃 이상일 경우 예외(Exception)를 발생하도록 하고 있다.

Spring에는 Transaction Synchronization방식이라고 하여 Connection을 ThreadLocal에저장해 두고 사용한다. ThreadLocal에 Connection 저장 시 Transaction의 시작 시간과 타임아웃 시간을 같이 기록하고, Proxy Connection을 사용하여 Statement를 생성하는 작업을 시도할 경우 경과 시간을 체크하여 예외를 발생시키도록 구현되어있다.

EJB CMT 구현 방식 또한 크게 다르지 않다. 만약 TransactionTimeout이 매우 중요하고 사용하는 컨테이너나 프레임워크에서 이런 기능을 제공하지 않는다면 직접 구현해서 사용해도 별 무리가 없을 정도로 매우 단순한 구조이다. TransactionTimeout에 대한 표준 API는 없다.

수행 시간이 200ms인 Statement가 5개 이하이고 기타 부수적인 비즈니스 로직 처리 시간이나 프레임워크 동작 시간이 100ms일 경우, TrasactionTimeout시간은 1100ms((200 x 5)+100) 이상으로 설정해야 한다.

StatementTimeout 이란?

Statement 하나가 얼마나 오래 수행되어도 괜찮은지에 대한 한계 값이다. JDBC API인 Statement에 타임아웃 값을 설정하며, 이 값을 바탕으로 JDBC 드라이버가 StatementTimeout을 처리한다. JDBC API인 java.sql.Statement.setQueryTimeout(int timeout) 메서드로 설정한다.

요즘 개발 환경에서는 개발자가 직접 StatementTimeout을 Java 코드로 설정하는 경우는 드물며, 프레임워크를 이용하여 해결하는 경우가 많다. iBatis를 예로 들어 설명하자면 "sql-map-config.xml" 파일의 sqlMapConfig/settings에 @defaultStatementTimeout 값으로 기본값을 설정할 수 있다. 또한 "sql-map.xml" 파일의 statement, select, insert, update 구문마다 @timeout 값으로 개별적으로 설정할 수 있다.

StatementTimeout 시간은 애플리케이션 특성에 따라 지정하기 때문에 이에 대한 설정 권장 값은 없다.

JDBC 드라이버의 StatementTimeout 동작 방식

StatementTimeout의 동작방식은 DBMS나 드라이버별로 다르다.

Oracle과 Microsoft SQL Server의 동작 방식이 서로 비슷하고, MySQL과 CUBRID의 동작 방식이 서로 비슷하다.

Oracle JDBC Statement의 QueryTimeout

그림 4 Oracle JDBC Statement의 QueryTimeout 동작 과정

Oracle JDBC Statement의 QueryTimeout은 다음과 같은 과정으로 동작한다.

Connection.createStatement() 메서드를 호출하여 Statement를 생성한다.

Statement.executeQuery() 메서드를 호출한다.

Statement는 자신의 Connection을 사용하여 Oracle DBMS로 쿼리를 전송한다.

Statement는 타임아웃 처리를 위해 OracleTimeoutPollingThread(classloader별로 1개 존재)에 Statement를 등록한다.

타임아웃이 발생한다.

OracleTimeoutPollingThread는 OracleStatement.cancel() 메서드를 호출한다.

Connection을 통해 취소(cancel) 메시지를 전송하여 수행중인 쿼리를 취소한다

jTDS(Microsoft SQL Server) Statement의 QueryTimeout

그림 5 jTDS(Micsofot SQL Server) Statement의 QueryTimeout의 동작 과정

jTDS(Microsoft SQL Server) Statement의 QueryTimeout은 다음과 같은 과정으로 동작한다.

Connection.createStatement() 메서드를 호출하여 Statement를 생성한다.

Statement.executeQuery() 메서드를 호출한다.

Statement는 내부 Connection을 사용하여 Microsoft SQL DBMS로 쿼리를 전송한다.

Statement는 타임아웃 처리를 위해 TimerThread에 Statement를 등록한다.

타임아웃이 발생한다.

TimerThread는 JtdsStatement 객체 내부의 TdsCore.cancel() 메서드를 호출한다.

ConnectionJDBC을 통해 취소 메시지를 전송하여 수행중인 쿼리를 취소한다.

MySQL JDBC Statement의 QueryTimeout(5.0.8 버전)

그림 6 MySQL JDBC Statement의 QueryTimeout의 동작 과정(5.0.8 버전)

MySQL JDBC Statement(5.0.8 버전)의 QueryTimeout은 다음과 같은 과정으로 동작한다.

Connection.createStatement() 메서드를 호출하여 Statement를 생성한다.

Statement.executeQuery() 메서드를 호출한다.

Statement는 내부 Connection을 사용하여 MySQL DBMS로 쿼리를 전송한다.

Statement는 타임아웃 처리를 위해 새로운 타임아웃 처리용 스레드를 생성한다. 5.1.x 버전에서는 Connection에 한 개의 스레드가 할당되는 것으로 변경되었다.

스레드에 타임아웃 처리를 등록한다.

타임아웃이 발생한다.

타임아웃 처리 스레드가 Statement와 동일한 설정의 Connection을 생성한다.

생성된 Connection을 사용하여 취소 쿼리(KILL QUERY "connectionId")를 전송한다.

CUBRID JDBC Statement의 QueryTimeout

그림 7 CUBRID JDBC Statement의 QueryTimeout의 동작 과정

CUBRID JDBC Statement의 QueryTimeout은 다음과 같은 과정으로 동작한다.

Connection.createStatement() 메서드를 호출하여 Statement를 생성한다.

Statement.executeQuery() 메서드를 호출한다.

Statement는 내부 Connection을 사용하여 CUBRID DBMS로 쿼리를 전송한다.

Statement는 타임아웃 처리를 위해 새로운 타임아웃용 스레드를 생성한다.

스레드에 타임아웃 처리를 등록한다.

타임아웃이 발생한다.

타임아웃 처리 스레드가 Statement와 동일한 설정의 Connection을 생성한다.

생성된 Connection을 사용하여 취소 메시지를 전송한다.

JDBC 드라이버의 SocketTimeout 이란?

JDBC Driver Type4는 소켓을 사용하여 DBMS에 연결하는 방식이고, 애플리케이션과 DBMS 사이의 ConnectTimeout 처리는 DBMS에서 하지 않는다.

JDBC 드라이버의 SocketTimeout 값은 DBMS가 비정상으로 종료되었거나 네트워크 장애(기기 장애 등)가 발생했을 때 필요한 값이다. TCP/IP의 구조상 소켓에는 네트워크의 장애를 감지할 수 있는 방법이 없다. 그렇기 때문에 애플리케이션은 DBMS와의 연결 끊김을 알 수 없다. 이럴 때 SocketTimeout이 설정되어 있지 않다면 애플리케이션은 DBMS로부터의 결과를 무한정 기다릴 수도 있다(이러한 Connection을 Dead Connection이라고 부르기도 한다).

이러한 상태를 방지하기 위해 소켓에 타임아웃을 설정해야 한다. SocketTimeout은 JDBC 드라이버에서 설정할 수 있다. SocketTimeout을 설정하면 네트워크 장애 발생 시 무한 대기 상황을 방지하여 장애 시간을 단축할 수 있다.

단, SocketTimeout 값을 Statement의 수행 시간 제한을 위해 사용하는 것은 바람직하지 않다. 그러므로 SocketTimeout 값은 StatementTimeout 값보다는 크게 설정해야 한다. SocketTimeout값이 StatementTimeout보다 작으면, SocketTimeout이 먼저 동작하므로 StatementTimeout 값은 의미가 없게 되어 동작하지 않는다.

SocketTimeout에는 아래 두 가지 옵션이 있고, 드라이버별로 설정 방법이 다르다.

• Socket Connect 시 타임아웃(connectTimeout): Socket.connect(SocketAddress endpoint, int timeout) 메서드를 위한 제한 시간
• Socket Read/Write의 타임아웃(socketTimeout): Socket.setSoTimeout(int timeout) 메서드를 위한 제한 시간

CUBRID, MySQL, jTDS (Microsoft SQL Server), Oracle JDBC 소스를 모두 확인해 본 결과 네 개의 드라이버에서는 위의 두 가지 API를 사용함을 확인할 수 있었다. JDBC 드라이버별 SocketTimeout의 설정 방법은 아래와 같다. connectTimeout와 socketTimeout의 기본 값인 0은 타임아웃을 발생하지 않도록 하는 것이다.

표 1 SocektTimeout 설정 방법

JDBC 드라이버	connectTimeout	기본값	단위	적용 방법
	socketTimeout	기본값	단위
MySQL Driver	connectTimeout	0	ms	DriverURL에 옵션 명시 형식 jdbc:mysql://[host:port],[host:port].../[database] [?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]... 예 jdbc:mysql://xxx.xx.xxx.xxx:3306/database?connectTimeout=60000&socketTimeout=60000
	socketTimeout	0	ms
jTDS(MS-SQL Server) Driver	loginTimeout	0	sec	DriverURL에 옵션명시 형식 jdbc:jtds:<server_type>://<server>[:<port>][/<database>][;<property>=<value>[;...]] 예 jdbc:jtds:sqlserver://server:port/database;loginTimeout=60;socketTimeout=60
	socketTimeout	0	sec
Oracle Thin Driver	oracle.net.CONNECT_TIMEOUT	0	ms	DriverURL로 설정할 수 없고, OracleDatasource.setConnectionProperties() API를 통해 Properties 객체로 전달해야 한다. DBCP사용 시 다음 API를 사용한다. BasicDatasource.setConnectionProperties() BasicDatasource.addConnectionProperties()
	oracle.jdbc.ReadTimeout	0	ms
Cubrid Thin Driver	별도 설정 없음	5,000	ms	DriverURL로 설정할 수 없으며, 5초 후 타임아웃이 발생한다. URL에 althost 옵션 지정으로 타입아웃 시 지정된 호스트로 연결 가능 C API로는 URL에 login_time 옵션을 ms단위로 명시 가능
	별도 설정 없음	5,000	ms	DriverURL로 설정할 수 없으며, 5초 후 타임아웃이 발생한다. URL에 althost 옵션 지정으로 timeout 시 지정된 호스트로 연결 가능

DBCP의 별도 API를 직접 사용하지 않고, Properties로 설정하는 방법도 있다. Properties 설정 시 키는 "connectionProperties", 값은 "[propertyName=property;]*" 형식의 문자열을 전달한다. 다음 예는 iBatis에서 XML을 통한 Properties 설정을 예로 들었다.

?

1 2 3 4 5 6

<transactionmanager type="JDBC"> <datasource type="com.nhncorp.lucy.db.DbcpDSFactory"> .... <property name="connectionProperties" value="oracle.net.CONNECT_TIMEOUT=6000;oracle.jdbc.ReadTimeout=6000"> </property></datasource> </transactionmanager>

OS 레벨 SocketTimeout 설정

SocketTimeout이나 ConnectTimeout을 설정하지 않으면 네트워크 장애가 발생해도 애플리케이션이 대부분 이를 감지할 수 없다. 따라서 연결이 되거나 데이터를 읽을 수 있을 때까지 애플리케이션이 무한정 기다리게 된다. 그러나 서비스에서 발생한 실재 장애 상황에서는 30분 후에 애플리케이션(WAS)이 재연결을 시도하여 문제가 해결되는 경우가 많다. OS에서도 SocketTimeout 시간을 설정할 수 있기 때문이다.

이 기사의 처음에 예로 든 리눅스 서버에서는 SocketTimeout을 30분으로 설정해 두고 있었다. 해당 설정 값을 통해 OS 레벨에서 네트워크 연결 끊김을 확인하는 것이다. 문제가 발생한 리눅스 서버의 KeepAlive 체크 수행 주기가 30분이므로 SocketTimeout 설정을 0으로 해도 네트워크 장애로 인한 DBMS 연결 장애 지속 시간이 30분을 넘지 않는 것이다. Linux 서버에서 KeepAlive 체크 수행 주기는 tcp_keepalive_time로 조정할 수 있다.

네트워크 장애로 인해 애플리케이션이 대기 상태로 빠지는 경우는 대부분 애플리케이션이 Socket.read() 메서드를 호출하고 있을 때이다. 그러나 네트워크 구성이나 장애 유형에 따라 매우 드물게 Socket.write() 메서드를 실행하는 도중 대기 상태에 빠지는 경우가 있다.

애플리케이션에서 Socket.write() 메서드를 호출하면 OS 커널 버퍼에 데이터를 기록한 후 바로 제어권을 애플리케이션에 반환한다. 즉 커널 버퍼에 값을 제대로만 기록하면 Socket.write() 메서드 실행은 언제나 성공한다. 그러나 특수한 네트워크 장애로 OS 커널 버퍼가 가득차면 Socket.write() 메서드도 대기 상황에 빠질 수 있다. 이 경우 OS는 일정 시간 동안 패킷 재전송을 시도하다고 한계 값에 도달하면 에러를 발생시킨다. 이 기사에서 예로 든 서버에서는 해당 값이 대략 15분으로 설정되어 있었다. 이 값은 Linux 서버의 tcp_retries2로 조절할 수 있다.

마치며

JDBC 내부의 동작 설명은 이것으로 마무리한다. 올바른 타임아웃 설정으로 장애를 줄이는 데 도움이 되었으면 하는 바람이다. 추가적인 문의나 JDBC에 관련한 좋은 정보가 있다면 개발자센터 블로그나 이 기사의 댓글로 글을 남겨 주기를 부탁한다.

마지막으로 자주 문의가 들어온 내용을 정리해 보았다.

• Q Statement.setQueryTimeout() 메서드로 QueryTimeout을 설정했는데도 네트워크 장애 발생 시 기대하는 대로 동작하지 않습니다.
  A QueryTimeout은 정상적으로 소켓 연결을 맺고 있을 때에만 유효합니다. 그렇기 때문에 네트워크 장애의 예외 상황을 처리할 수 없습니다. 네트워크 장애 상황을 대비하려면 JDBC 드라이버에 있는 SocketTimeout을 설정해야 합니다.
• Q TransactionTimeout, StatementTimeout, JDBC 드라이버 SocketTimeout은 DBCP 설정 값과 어떤 관계가 있나요?
  A DBCP에서 Connection을 JDBC로부터 얻어올 때 DBCP의 waitTimeout 값만큼 대기할 수 있습니다. 그 외의 DBCP 설정 값은 DBCP 단독으로 동작합니다.
• Q JDBC SocketTimeout을 설정하면 DBCP에서 유휴 상태(idle)로 오래 유지된 Connection이 닫히지 않나요?
  A 아니요, 닫히지 않습니다. Socket 옵션은 실제 데이터를 쓰거나 읽을 때 적용되기 때문에, DBCP 안에서 유휴 상태인 Connecton에 영향을 끼치지 않습니다. DBCP 내부에서 부족한 Connection 생성, 오래된 유휴 Connection 제거, Validation Check 시 영향을 줄 수 있지만 네트워크에 문제가 발생하지 않는 한 특이 사항은 일어나지 않습니다.
• Q SocketTimeout시간은 얼마나 길게 설정해야 하나요?
  A 본문에서 말한 것처럼 StatementTimeout보다는 충분히 크게 잡아야 하며, 권장 값은 없습니다. JDBC 드라이버의 SocketTimeout 값이 영향을 주는 시점은 네트워크 장애가 발생한 이후입니다. 해당 값을 정밀하게 설정한다고 해서 장애가 발생하지 않는 것이 아니며, 경우에 따라(네트워크 장애가 곧 복구되었을 경우) 장애 시간을 줄일 수 있을 뿐입니다.