오라클 접속 기술(CTF, TAF, TAC) 소개

개요

오라클 데이터베이스 서버에는 다양한 접속 방식이 제공됩니다. 이는 모두 애플리케이션에서 고려해야 할 접속 기술들입니다. 간단히 정리해보겠습니다.

오라클 클라이언트의 접속 방식 2가지

오라클 데이터베이스 서버 설치 파일 뿐만 아니라 오라클 데이터베이스 클라이언트 설치 파일도 제공하고 있습니다. 오라클 클라이언트를 설치하면 C, C++, Java, .Net, Node.js, Python, PHP, R, Erlang, Perl, Ruby, Rust, Go, Julia 등 다양한 개발 언어 환경을 지원합니다.

특히, Java 개발 환경에서 사용 가능한 JDBC 접속 방식에 대해 정리해보려고 합니다. Java 애플리케이션이 오라클 데이터베이스에 접속할 때는 JDBC 드라이버를 사용합니다. 여기서 OCI 드라이버와 Thin 드라이버 두 가지가 있습니다.

• OCI 드라이버(Oracle Call Interface): 오라클 클라이언트 설치가 필요하며(Native 라이브러리를 사용), 오라클 클라이언트에서 관리 중인 TNS 정보를 이용하여 접속합니다. (Oracle Client + JDBC.jar 파일이 모두 필요합니다) 오라클 데이터베이스에 접속하는 정보가 외부 파일로 저장되어 있기 때문에, 애플리케이션 관리자나 데이터베이스 관리자가 접속 정보를 관리할 수 있습니다. 상대적으로 Thin 드라이버에 비해 더 빠른 성능을 제공한다고 알려져 있습니다.

• Thin 드라이버: 오라클 클라이언트를 설치하지 않아도 순수한 자바를 통해 접속이 가능합니다. (JDBC.jar 파일만 필요합니다) 접속 정보는 소스나 구성 파일에서 Connection String으로 관리됩니다. 접속 정보가 소스 코드 내에 있기 때문에 애플리케이션 담당자가 접속 정보를 관리합니다.

각 개발자나 데이터베이스 관리자의 역할과 책임에 따라 접속 정보를 관리하겠지만, 데이터베이스 장애 시 애플리케이션 가용성을 유지하는 관점에서 보면 데이터베이스 관리자의 역할이 더 크다고 생각됩니다. 여기서 중요한 점은 책임의 범위를 명확히 해야 한다는 것입니다.

클라이언트 접속 기술 및 동작 방식

데이터베이스 장애로부터 애플리케이션의 가용성을 확보하기 위해 데이터베이스를 RAC(Real Application Cluster)로 구성합니다.

먼저 데이터베이스와 인스턴스의 개념을 이해하는 것이 좋습니다. 데이터베이스는 물리적으로 저장된 데이터 파일들의 묶음을 의미하고, 인스턴스는 애플리케이션이 접속해서 데이터베이스의 데이터에 > 접근하기 위해 실행되는 서버입니다.

따라서 RAC 환경은 하나의 데이터베이스에 여러 개의 서버가 각각의 인스턴스를 실행하는 환경을 의미합니다. 그러므로 인스턴스가 많아질수록 가용성이 높아지는 효과를 얻을 수 있습니다. (인스턴스 간 데이터 정합성을 유지하는 메커니즘이 핵심 기술입니다. 대부분의 데이터베이스 엔진들은 오라클만큼 성숙한 기술을 제공하지 못하는 것 같습니다.)

여러 개의 인스턴스가 서비스되면 애플리케이션은 그 중 하나의 인스턴스에 접속하여 SQL을 실행합니다. SQL 수행 중에 해당 인스턴스가 장애로 중지된다면 어떻게 될까요? 일반적인 환경에서는 당연히 세션이 중지되는 현상이 발생하고, 결과적으로 애플리케이션이 담당한 업무에 영향을 미칠 수 있는 구조가 됩니다. 이러한 장애 상황에서 애플리케이션의 가용성을 높이기 위해 아래와 같은 3가지 접속 기술을 제공합니다.

• CTF(Connection Timeout Failover)
  • RAC 환경에서 여러 개의 인스턴스가 운영됩니다. 하나의 인스턴스에서 장애가 발생하면 나머지 인스턴스로 접속해야 합니다. CTF 방식을 사용하면 애플리케이션에서는 인스턴스 장애 시 자동으로 다시 연결(retry)해주는 로직이 필요합니다.
  • 인스턴스 장애 시 해당 인스턴스에 접속한 세션이 끊기지만, 재시도할 때는 가용한 다른 인스턴스로 접속해주는 기능이 CTF입니다. 따라서 접속 정보에 모든 가용한 인스턴스 목록을 적어놔야 합니다.
• TAF(Transparent Application Failover)
  • 인스턴스가 장애가 발생하면 기본적으로 해당 인스턴스에 접속한 세션이 끊기고 해당 세션에서 처리 중인 트랜잭션은 롤백됩니다.
  • TAF를 사용하면 세션은 끊기지 않고 다른 인스턴스로 자동으로 세션이 failover됩니다. 실행 중인 트랜잭션은 자동으로 롤백되지만 트랜잭션이 없이 단순히 SELECT 중인 경우 세션이 Failover된 후에도 계속 처리됩니다.
• TAC(Transparent Application Continuity) :
  • 2c부터 AC(Application Continuity)라는 개념이 나왔습니다. 인스턴스 장애 시 트랜잭션 자체를 보상하는 로직이 자동으로 시행됩니다. 장애 발생시 자동으로 다른 인스턴스에 접속하여 실패한 트랜잭션을 다시 실행(replay)해주는 로직이 JDBC 내부에서 알아서 자동으로 실행됩니다. 따라서 세션이 끊기지 않고 트랜잭션 유실이 발생하지 않아 애플리케이션에서 인스턴스 장애 자체가 인지되지 않습니다. (인스턴스가 장애나도 애플리케이션에서 인지가 되지 않는 고 가용성을 유지하고 있나요?)
  • 18c부턴 TAC(Transparent Application Continuity)로 발전하게 됩니다. AC를 사용하기 위해서는 애플리케이션 트랜잭션 처리를 위해 트랜잭션 boundary를 명확하게 선언해야하는 코드 변경 작업이 필요했습니다. TAC에서는 JDBC Driver에서 자동으로 트랜잭션 Boundary를 묵시적으로 처리하도록 되어 있어 AC보다 코드 변경 작업이 적어집니다. (AC, TAC는 트랜잭션 Boundary 개념이 중요하고 애플리케이션에서 AC, TAC가 정상적으로 동작하도록 설계하는 게 중요한 요소입니다.)

어떤 방식으로 접속하고 있나요? 아마 대부분 CTF 방식을 사용하고 있을 것으로 생각됩니다. 좀 더 높은 고가용성을 유지하기 위해서는 접속 방식만 변경해도 더 나은 운영 환경을 만들 수 있습니다.

OCI, Thin 드라이버 선택 기준은?

각 드라이버별로 지원하는 기능이 약간씩 다릅니다. 그러므로 선택 기준에 따라 바뀔 수 있습니다.

드라이버별 특징

• OCI 드라이버
  • OCI 드라이버를 사용하기 위해서는 오라클 클라이언트 소프트웨어가 필요합니다. 따라서 먼저 지원되는 OS 환경을 확인해야 합니다.
  • TNS 접속 정보를 외부 파일로 관리합니다.
  • 오라클 클라이언트를 통한 접속으로 CTF, TAF, TAC를 모두 지원합니다.
• Thin 드라이버
  • 오라클 클라이언트 소프트웨어가 필요하지 않고, 필요한 JDBC.jar 파일만 사용하면 됩니다.
  • 접속 정보는 Connection String에서 모두 기술해야 합니다. 소스 코드 안에서 접속 정보가 관리되며 설정이 쉽습니다. 또한 OS와 독립적으로 관리할 수 있습니다.
  • CTF와 TAC만 지원되며, TAF는 지원되지 않습니다.

드라이버 선택 기준

기본적으로 애플리케이션의 가용성 레벨과 데이터베이스 환경 변화를 고려하여 접속 드라이버를 선택할 수 있습니다. 물론 이외에도 운영 관점에서 여러 가지 기준이 있을 수 있습니다.

• 애플리케이션 가용성을 어느 수준에서 관리할 것인가요?
  • 가용성 수준은 CTF –> TAF –> TAC 순으로 높아집니다.
  • TAC를 구성하기 위해서는 애플리케이션 코드 레벨에서의 가이드가 필요합니다.
• 인프라 구성변경에 따라 접속 정보를 어떻게 관리할 것인가요?
  • OCI 드라이버를 사용할 경우 서버에서 TNS정보를 변경하고, Thin 드라이버를 사용할 경우 Configure에서 접속정보를 수정해야합니다.
  • 인프라 구성 변경예시
    • 데이터베이스가 새로운 환경으로 마이그레이션되거나, 새로운 서버로 이전된다면 IP 주소가 변경될 수 있습니다. 이 경우 어떻게 변경 관리해야 할까요?
    • 데이터베이스 구성이 변경된다면 어떻게 접속 정보를 관리할까요? (예: RAC 환경에서 인스턴스 추가)
    • 새로운 재해 복구 환경이 구성되면 어떻게 접속 정보를 관리할까요? (예: Standby 환경이 구성되면?)

마무리

오라클 데이터베이스의 접속 방법과 동작 원리를 간단히 살펴보았습니다. 사실 데이터베이스 관리자가 애플리케이션 담당자에게 접속 방식을 가이드하기 위해서는 많은 테스트가 필요합니다. 그리고 데이터베이스 설치 혹은 변경후에 가용성에 대해 검증하는 프로세스가 추가적으로 필요합니다.

운영환경이 녹녹치 않아서 여력도 부족한것도 현실입니다.

그래도 처음부터 고려되지 않았다면 지금부터라도 애플리케이션 관점에서 고민하고 내가 관리하는 데이터베이스가 안정적으로 운영될수 있는 기반을 마련하는것이 필요합니다. 그 기반의 시작점은 접속방식에 대한 이해한것 같습니다.

최소한 TAF이상의 가용성은 유지하는것은 어떨까요?