AWS Aurora Endpoint and WAS Connection Pool

Abstract

AWS Aurora 는 DB Cluster 로 구현된다. DB Cluster 는 Aurora 인스턴스와 Endpoint 를 포함한 일종의 그룹 개념이다. 이 DB Cluster 에는 1개의 Primary 인스턴스와 15개의 Replica 를 가질 수 있다.

각각의 구성에서 접속이 가능한 지점은 다음과 같이 3가지가 있다.

• Cluster Endpoint
• Read Replica Endpoint
• Instance Endpoint

이러한 Endpoint 와 Aurora 인스턴스 그리고 Primary, Replica 를 조합한 아키텍쳐는 다음과 같다.

Cluster Endpoint

Cluster Endpoint 는 Aurora Cluster 에서 현재 Primary 인스턴스에 접속하기 위한 Endpoint 이다. 모든 Aurora Cluster 는 반드시 하나의 Primary 인스턴스와 이를 연결하는 Cluster Endpoint 를 가진다.

Primary 인스턴스는 Insert, Update, Delete 그리고 DDL(Data Definition Language) 에 관한 모든 쓰기 연산을(write operation) 지원하며 데이터 읽기 연산인 Select 도 지원한다. Cluster Endpoint 는 read/write 를 연산을 제공하는 Primary 인스턴스 접속을 제공한다.

Cluster Endpoint 는 read/write 접속에 대한 자동 FailOver 를 제공한다. Primary 인스턴스에 문제가 발생하면 Replica 인스턴스 중 하나를 Primary 인스턴스로 선택한다. Cluster Endpoint 는 DNS 를 이용해 기존의 Primary 인스턴스의 도메인을 버리고 Replica 인스턴스로 변경한다. 이렇게 함으로써 Cluster Endpoint 도메인 주소는 변경없이 계속 유지 된다. Cluster Endpoint 에서 새로운 Primary 인스턴스로 지정된 Replica 인스턴스는 read/write 역할을 위해서 Primary 인스턴스로 승격된다.

Reader Endpoint

Reader Endpoint 는 Aurora Replica 중에 하나와 연결된다. Aurora Replica 는 읽기 연산(read operation) 만 지원하기 때문에 Reader Endpoint 는 읽기 전용 연결지점이 된다.

만일 Aurora Replica 가 한개 이상이라면 Reader Endpoint 는 Load Balancing 을 지원한다. 각각의 연결은 Round robin 방법으로 Replica 인스턴스 하나와 연결이 되어 연결에 따른 부하가 분산된다.

Instance Endpoint

Aurora DB 를 생성은 결국 Instance 를 생성하게 된다. 모든 Aurora 에 인스턴스는 Endpoint 를 가지는데 이게 Instance Endpoint 이다. 모든 Instance 는 타입과 관련없이 유일한 Instance Endpoint 를 가진다.

이 Instance Endpoint 는 도메인 이름으로 불변이며 Cluster Endpoint, Reader Endpoint 에 CNAME 으로 등록되어 이들의 연결지점으로 사용되어 진다.

WAS Connection Pool

이제 WAS 에서 AWS Aurora 접속을 위한 설정에 대해서 이야기 해보자. WAS 서버가 무엇이든 AWS Aurora 접속을 위해서는 MySQL, MariaDB Connector/j 드라이버를 사용해야 한다.

그런데, Aurora Cluster 를 구성할 경우에 Primary 인스턴스와 Replica 인스턴스로 구성하고 Endpoint 를 각각 Cluster, Reader 로 구성하게 될 것이다. 이렇게되면 WAS 에서는 이를 분산해서 접속해야 할 필요가 생긴다.

MySQL, MariaDB 는 이렇게 read/write 접속과 read only 접속을 분리해서 연결하도록 하는 기능을 제공하는데 이를 Smart Driver 라고 부른다.

한가지 먼저 짚고 넘어가자면, AWS Aurora 를 사용할 경우에는 MariaDB Connector/j 드라이버를 사용할 것을 권장하고 있는데, MariaDB Connector/j 드라이버는 Aurora 를 공식적으로 지원한다.

MariaDB Connector/j 드라이버를 이용해 Cluster Endpoint, Reader Endpoint 를 설정하는 방법은 다음과 같다. (Tomcat 기준 JNDI 설정이다)

이렇게 Cluster Endpoint, Reader Endpoint 주소를 연속해서 주면 된다. 이렇게하면 서버단에서 접속 설정은 끝이난다.

하지만, 이렇게 서버단에서의 설정만으로 접속이 분리되는 것은 아니다. Spring MVC 기준으로 말을 하자면 Transactional 의 ReadOnly 프로퍼티를 준 경우에만 Reader Endpoint 로 접속이 이루어지고 이외에는 전부 Cluster Endpoint 로 접속이 이루어진다.

Spring MVC 에서 이것을 각각 지정하기보다는 TX, AOP 설정을 통해서 한꺼번에 설정이 가능하다.

위와같이 했을 경우에 get* 으로 시작하는 메소드 이름을 가진 Service 빈에서 Read-Only 속성을 부여해 Reader Endpoint 로만 접속하도록 하게 할 수 있다.

마지막으로 고려해야할 것이 한가지 더 있는데, Connection Pool 의 경우에는 접속/해제에 대한 오버헤드를 줄이기 위해서 미리 연결을 해놓는 경우인데, 만일 Aurora FailOver 기능을 사용할 경우에 기존의 Fail된 인스턴스와 연결을 계속 유지하는 경우가 생긴다.

Replica Role 이 승격되서 새로운 Primary Role 이 되면서 Read/Write 역할을 수행하게 되는데, 이때 Cluster Endpoint 의 DNS 의 CNAME 이 변경된다. 하지만 WAS 서버의 Connection Pool 은 장애가 발생한 기존 Primary Role 인스턴스를 가지고 있게 된다.

MariaDB Connector/J 드라이버에는 이를 위해서 SOCKET_TIMEOUT 값을 두고 있다. Aurora 의 경우에는 10000ms 로 10초 동안 접속이 이루어지지 않을 경우에 Socket Timetout 으로 간주해 FailOver 로직을 수행한다.

Socket Timeout 은 JDBC 드라이버 측에서 설정을 해줘야 한다. 이는 대부분 URL 에 파라메터로 지정하는데, 다음과 같이 할 수 있다.

MariaDB connector/J 에서 connectTimeout 기본값은 0이며 socketTimeout 의 경우 Aurora 일 경우 10000ms 로 되어 있다. 이정도면 MariaDB Connector/J 를 사용하는데 있어서 별도의 설정을 해주지 않아도 될 정도다.