본 단계는 외산 DBMS에서 수행되는 SQL을 어플리케이션 수정 없이 티베로에서도 원활히 수행될 수 있도록 구현하는 단계로써 총 4가지 과정이 반복 수행된다.

1) 외산 DB 수행 SQL 수집

첫 번째로 티베로에서 검증할 외산 DBMS에서 수행되고 있는 SQL을 수집하는 과정이 수행되며, 이를 위해 다음의 두 가지 사항을 먼저 확정해야 한다.

가. 적절한 목표 수집 시점을 정해야 한다

소속 회사는 다음의 사항을 고려하여 1단계 환경 구축이 완료된 이후 가장 가까운 월요일 오전 7시부터 오후 7시까지 총 12시간을 리플레이 로그 수집 시점으로 선택하였다.

고려 사항 1 : 평일 서비스되는 업무들이 요일별 큰 차이 없이 매일 유사한 패턴을 가지고 있으므로 평일 중 하루 수행되는 SQL들을 재현 대상으로 선택

고려 사항 2 : 주말 전체 백업/평일 아카이브 로그 백업 정책을 가지고 있으므로 복구가 용이한 시점(아카이브 로그를 조금만 적용하면 되므로)을 선택

나. 리플레이 안정성을 확인해야 한다

리플레이 수행으로 인한 운영 와스서버 성능 저하가 없어야 하며 수집되는 로그의 양이 지나치게 크지 않음을 확인해야 한다.

리플레이는 와스서버 JDBC 설정을 변경하여 수행하므로 비정상 동작한다면 운영 와스서버에 문제가 생겨 해당 와스서버에 운영되고 있는 전체 서비스에 장애가 발생할 수 있다.

따라서 리플레이 수집 대상 와스서버 중 1개만 먼저 리플레이 수집을 동작하여 와스서버 부하량 및 로그 수집량에 문제가 없는 것을 충분히 확인하고 전체 업무에 적용해야 한다.

참고로 소속 회사에서 수행 시 와스서버 CPU 부하 등은 전혀 발생하지 않았으며 1일 약 300만 회의 SQL 수집 시 약 7.8G의 로그량을 기록하였다.

위와 같은 목표 수집 시점 및 리플레이 안정성이 확인되었다면 정해진 일정에 외산 DBMS에서 수행된 SQL을 수집한다.

참고할 사항은 소속 회사에서 적용한 리플레이 제품은 로그 수집 시 마다 와스서버 설정을 변경하고 재기동했어야 하므로 새벽 시간 업무에 영향이 없는 시점에 인프라 담당자와 협의하여 수집을 진행하였다

(물론 와스서버 이중화가 되어있기는 하지만 다수의 와스서버 설정 변경을 진행하는 과정에서 예상치 못한 장애가 발생할 수 있으므로 프로젝트 오픈 시점까지 총 세 번의 로그 수집은 모두 새벽 시간을 통해 진행하였다).

2) 티베로 재현(Replay Play)

로그 수집이 완료되었다면 이제 티베로에 해당 로그를 재현해야 한다. 그리고 이를 위해서는 사전에 로그 수집 시작 시점인 월요일 오전 7시의 데이터로 티베로 마이그레이션이 완료되어 있어야 한다.

따라서 소속 회사는 그림 3-4와 같은 일정으로 티베로 수집 ~ 재현을 진행하였다.

• 1. 리플레이 로그 수집 : 월요일 07시부터 21시까지
• 2. 외산 DBMS Recovery : 월요일 07시 Target으로 리커버리 - 리플레이 수집과 동시에 진행(1일 소요)
• 3. 티베로 마이그레이션 : 화요일 - 금요일 진행 - 외산 DBMS Recovery가 완료된 이후 진행
• 4. 티베로 재현 : 차주 월요일 수행

* 티베로 재현을 위한 준비 과정에 최소 일주일이 필요하다는 점을 고려하여 일정계획을 수립해야 한다(1회 로그 수집을 완료하고 그림 3-3과 같은 스토리지 추가 구성을 완료했다면 수집된 로그를 반복 수행하는 데는 별도의 준비 과정이 불필요하다).

참고로 소속 회사는 총 3회 로그 수집을 진행하였으며 수집 된 로그는 평균 6~7회 반복 재현(Play) 테스트를 실시하였다.

• [그림 3-4] 티베로 리플레이 수집-재현 소요 시간
• 

3) SQL 분석 및 개선

티베로 재현까지 완료되었다면 이제 재현결과를 분석하여 비호환 SQL들을 찾아내고 문제점을 분석하여 티베로 연구소에 개선을 요청하는 과정^주1)을 수행해야 한다.

이를 위해서는 티베로에 재현된 SQL들의 수행결과 정보 및 해당 SQL이 수행될 때의 티베로 데이터베이스의 시스템 정보, 성능 정보 등을 상세하게 파악해야 하는데 소속 회사 프로젝트에 투입된 리플레이는 이러한 기능이 없는 초기 버전이었으므로 본회가 보유한 3rd Party 솔루션을 통해 자체적으로 해결하였다.

리플레이가 정식 제품으로 선보일 시점에서는 별도의 3rd Party 솔루션 도움 없이 자체 분석이가능할 것으로 생각되지만, 일부분은 여전히 전환 대상 고객사에서 직접 분석하여 그 성능을 증명해야할 것이므로 소속 회사의 분석 사례를 보는 것이 도움이 될 것이라고 믿고 자세히 본 단계를 안내하려고 한다.

먼저 분석을 위한 3rd Party 솔루션^주2)의 동작 방식 및 그에 따른 분석 목표를 살펴보자.

| 주1 | 소속 회사는 1. 실패하는 쿼리가 없고(티베로 최초 재현 시 0.3% 실패) 2. 기준 시간(0.2초) 이상 소요되는 SQL의 비율(티베로 최초 재현 시 17.7%)을 외산 DBMS와 유사한 수준(2.3%)으로 개선하는 것을 목표로 해당 과정을 진행하였다. 개선의 목표는 전환을 수행하는 회사의 업무 특성에 따라 다양하게 설정 할 수 있을 것이라고 생각된다.

| 주2 | 소속 회사는 기존에 사용 중인 DB 감사 솔루션(웨어벨리 샤크라)과 DB 모니터링 솔루션(엑셈 맥스게이지)을 활용하여 분석하기로 결정하고 가장 먼저 두 제품이 티베로에서도 원활하게 동작할 수 있도록 개선하는 작업을 POC 종료 후 프로젝트 환경 구축 단계까지 진행)하였다. 티베로는 외산 DBMS에 비해 역사가 짧기 때문에 3rd Party 연동 제품의 종류가 부족하고 연동이 되더라도 품질이 다소 떨어질 수밖에 없다. 그러나 해당 3rd Party 솔루션이 국산 제품이고 양사 연구소의 긴밀한 협조만 이루어진다면 수개월 이내에 품질 개선을 이뤄낼 수 있으므로 꼭 사용해야 하는 제품일 경우 사전에 이러한 품질 검증 및 개선 작업을 반드시 수행하여야 한다(소속 회사가 사용 중인 두 제품 모두 위와 같은 개선 작업을 거쳐 현재 훌륭한 연동 품질을 보여주고 있다).

• [그림 3-5] 티베로 리플레이 분석에 활용한 3rd Party 솔루션의 구성 및 사용 목적 요약
• 

구성 참고 사항 : 맥스게이지 서버는 티베로 DB와 AGENT간 네트워크를 통해 정보를 수신한다. 따라서 티베로의 서비스 네트워크와 정보 전송 네트워크를 분리하여 데이터베이스 응답에 간섭이 없도록 하는 것이 바람직하다.

맥스게이지 사용 목적 : 맥스게이지는 수신된 정보를 저장하여 보고서 형태로 제공하므로 빠른 분석이 가능하다. 따라서 패치 버전의 안정성을 빠르게 확인하여 상세 분석을 진행할지 연구소에 추가 패치를 요구할지 결정하는 용도로 사용하였다.

샤크라 사용 목적 : 샤크라 서버를 통해 추출한 정보는 용량이 매우 크고 분석에 적합한 형태로 변경하는 과정을 거쳐야 했으므로 맥스게이지에 비해 많은 분석 시간이 소요되었다. 그러나 수행된 모든 SQL의 정보를 보유하고 있어 해당 패치 버전의 상세 성능을 분석하는 목적으로 사용되었다.

첫 번째로 엑셈사의 맥스게이지는 티베로 DB가 설치된 OS에 전용 Agent가 설치되어 멕스게이지 서버와 통신하며 실시간으로 티베로의 각종 시스템 통계 정보(CPU부하량, Logical Read, Physical Read, Redo Entry 등등) 및 세션별 SQL 수행 정보 등을 전송^주3) 한다.

또한 해당 정보들을 시간 단위로 맥스게이지 전용 서버에 차곡차곡 저장하기 때문에 리플레이를 수행한 하루 동안의 티베로 성능 정보를 전용 UI 화면을 통해 빠르고 쉽게 확인할 수 있다. 따라서 소속 회사는 다음과 같은 분석목표로 맥스게이지를 사용하였다.

| 주3 | 티베로의 정보를 Access 할 때는 티베로가 제공한 API를 통해 메모리를 직접 바라보기 때문에 데이터베이스 리소스는 전혀 사용하지 않는다.

가. 리플레이를 재현하는 동안 CPU 100%에 가까운 과도한 부하를 주는 비호환 SQL의 탐색 및 제거

> 위와 같은 SQL들로 인해 서버 부하가 심하다면 나머지 SQL들은 리플레이 재현이 불가능하므로 해당 SQL이 수행된 세션은 빠르게 kill하고 나머지 테스트를 진행하였다.

> 해당 SQL들은 대부분 외산 DBMS에서도 수행 시간이 상당히 오래 걸리는 무거운 것들이었으며 소속 회사의 경우 약 10개 정도의 SQL이 발견되어 외산 DBMS와 티베로 모두 개선이 되도록 SQL을 수정/반영하고 다시 리플레이 로그를 수집/재현하여 이상이 없음을 확인하였다.

나. 성능 패치 버전 효과 및 안정성의 빠른 확인(해당 패치 버전으로 상세 분석을 진행할지 여부 결정)

> 리플레이를 통한 비호환 SQL 분석 이후 연구소로 부터 개선 패치를 수령하여 적용하면 해당 패치버전의 효과 및 안정성을 확인하기 위해 다시 한 번 동일한 수집로그로 리플레이를 재현하게 되는데 이때 맥스게이지에서 일별로 수집한 티베로 성능 정보를 서로 비교하면 실제로 개선이 있었는지, 부작용은 없는지 등을 빠르게 확인할 수 있다.

이제 그림 3-6, 3-7, 3-8을 통해 위 목표들을 어떻게 분석 가능한지 확인해보자

• [그림 3-6] 맥스게이지 실시간 View
• 

리플레이 재현 수행 중 티베로의 운영 상태 및 수행 SQL 세션 상황을 실시간 확인이 가능하므로 비정상 SQL 발생 시 나머지 테스트에 방해되지 않도록 쉽게 발견하고 kill할 수 있다.

• [그림 3-7] 맥스게이지 성능 정보 저장 View
• 

리플레이 재현을 했던 시간 동안의 계정별 각종 시스템 통계 정보, 성능 정보 등을 확인할 수 있다. 이를 통해 패치별 효과 및 안정성을 빠르게 확인할 수 있다.

• [그림 3-8] 맥스게이지 Top SQL View
• 

리플레이 재현을 했던 시간 동안의 Top SQL을 다양한 기준으로 확인할 수 있다. 이를 통해 패치별 문제가 되었던 대표적인 SQL들의 빠른 확인이 가능하다. 특히 기존 패치에 문제없던 SQL들 수행 시간이 높다면 패치의 부작용으로 판단하고 샤크라 를 통한 추가적인 분석을 하지 않고 연구소에 현상을 빠르게 리포트하여 짧은 시간 안에 개선된 패치를 다시 받을 수 있었다.

두 번째로 웨어벨리사의 샤크라는 티베로의 서비스 네트워크 포트를 다른 포트로 복제(mirroring)^주4)하여 해당 패킷에서 송수신되는 모든 SQL 정보를 정해진 양식으로 저장한다.

샤크라는 위와 같은 동작 방식으로 인하여 맥스게이지처럼 실시간 정보를 보여준다거나 상세 시스템 통계 정보를 수신하는 것은 불가능하지만 네트워크를 통해 송수신되는 모든 SQL 및 바인드 변수를 포함한 많은 관련 정보를 저장할 수 있다는 강력한 장점을 가지고 있다. 따라서 소속 회사는 다음과 같은 분석 목표로 샤크라를 사용하였다.

| 주4 | 네트워크 스위치에서 포트 복제에 의한 부하는 거의 없으므로 맥스게이지와 마찬가지로 데이터베이스 성능에는 전혀 간섭이 없다.

가. 외산 DBMS의 SQL 수행시간(Elapsed Time) 구간별 수행횟수를 파악

> 파악한 외산 DBMS의 수행 정보를 티베로 재현의 목표 지점으로 선정(예 : 외산 DBMS SQL 0.2초 이하 수행율 = 98% ← 티베로의 목표 수치)

나. 성능 패치 버전의 개선 효과 상세 확인

> 맥스게이지를 통해 안정성이 검증된 패치 버전에 대하여 샤크라를 통해 상세 SQL 수행 시간(Elapsed Time) 구간별 수행 횟수를 파악하여 성능 개선 효과 확인

다. 비호환 SQL의 분석

> SQL 실패(Fail), 성능저하 SQL들의 분석을 위한 상세 정보(SQL, 바인드 변수, 수행 시간 등) 확인

4) 패치 적용

본 과정은 비호환 SQL 분석 및 개선 과정에서 요청했던 이슈 사항 처리가 티맥스 연구소에서 완료되어 패치가 제공되었을 때 적용하는 단계이다.

티베로에 패치 적용이 완료되면 해당 패치의 효과 및 안정성을 반드시 검증해야 하므로 이미 수집된 로그를 통해 [2단계>3단계>4단계]로 다시 한 번 리플레이를 진행하게 된다.

결국 만족할 만한 품질의 패치가 적용될 때까지 2~4 단계를 계속 반복하게 되는데 소속 회사는 3개월 동안 이러한 리플레이 반복 수행을 약 10회 진행하며 만족할 만한 수준으로 품질을 개선할 수 있었다

(이러한 반복 수행에 필요한 시간을 단축하고 정해진 시간 동안 최대한 품질을 높이기 위해선 그림 3-3을 통해 안내했던 티베로 리플레이 수행을 위한 스토리지 추가 구성이 반드시 필요하다).