티베로 리플레이

어플리케이션의 안정성을 보장하며 데이터베이스를 전환하겠다는 생각을 소속 회사의 동료들에게 처음 얘기했을때 그들의 반응 또한 티베로 엔지니어들과 크게 다르지 않았으며, 소속 회사와 IT 관련 협력관계를 맺고 있는 회사의 엔지니어들 또한 “의도는 좋으나 지나치게 이상적이다”, “그러한 프로젝트를 어디서도 본 적이 없다”등의 부정적인 의견을 비추었다.

어플리케이션의 안정성이 중요하다는 것은 인정 하지만 안정성의 위협을 사용자가 어느정도 감수하지 않는 이상 데이터베이스 전환은 불가능하다는 것이 주변의 공통적인 생각이었던 것이다.

이러한 상황에서 외산 데이터베이스가 수행한 모든 SQL을 티베로에 재현할 수 있는 시스템을 개발해 달라는 소속 회사의 요건을 티베로 연구소가 진지하게 생각해주길 바라는 것은 힘들다고 판단되었고, 이 부정적인 시각을 긍정의 시각으로 바꾸기 위해선 불가능해 보이는 이 요건이 가능하다는 것을 조금이라도 직접 구현하여 증명하는 수 밖에는 없다고 생각되었다.

2.1장에서는 위와 같은 배경에서 소속 회사가 구현하여 POC과정에 적용했던 SQL 자동구현 시스템을 살펴보고 2.2장, 2.3장을 통해 티베로가 정식으로 구현한 리플레이 시스템의 구조와 사용방법에 대해 자세히 알아보자

티베로 리플레이의 탄생 배경

10만 개의 SQL 중 10개의 SQL이 신규 DBMS에서 원활하게 동작하지 않았다면 0.01%에 해당하는 실패율 즉, 99.99%를 성공했으니 매우 성공적이라고 생각할 수 도 있다.

그러나 해당 10개의 SQL이 매우 중요한 업무에 사용되고 있거나 복잡한 비즈니스의 중간 역할을 하고 있다면 단 10개의 비호환 SQL만으로도 해당 시스템에 매우 치명적인 문제들을 야기할 수 있다.

따라서 모든 SQL은 실패(Fail)없이 수행되어야 하고 성능은 기존 DBMS만큼 발휘되어야 시스템의 안정성을 보장하며 DBMS를 전환할 수 있으므로 문제가 될 만한 SQL들을 모두 파악하고 조치를 취해야 하는 것이 DBMS 전환 사업의 핵심이 된다.

그렇다면 어떻게 문제가 되는 SQL들을 모두 찾을 수 있을까? 업무 담당자와 함께 기존 시스템의 모든 화면을 클릭하며 문제 여부를 검증한다는 것은 현실적으로 불가능하므로 어떤 식으로든 자동화된 방법으로 현재 외산 DBMS에 수행되는 모든 부하를 복사/저장하고 티베로에 재현하여 문제되는 SQL을 추출할 수 있어야 한다는 것이 소속 회사의 첫 번째 POC 조건이었다.

이 조건에 대해 최초 논의했을 때 티베로 엔지니어들의 반응은 차가웠다. 현재 운영되고 있는 어떤 DBMS도 다른 DBMS에 가해지는 부하를 자신의 DBMS에 재현할 수 있는 솔루션을 가지고 있지 않다는 것이다(버전 업그레이드 등을 위해 자신의 하위 버전 DBMS 부하를 상위 버전으로 재현하는 솔루션을 제공하는 제조사는 존재한다).

따라서 사용자 테스트만으로 최대한 문제되는 SQL을 찾아 해결하고 오픈한 이후 발생되는 문제들에 대해서는 빠르게 조치해 나가자는게 최초 티베로가 제시한 방법론이었지만, 그 문제의 경중에 따라 조치 전에 이미 회사에 심각한 타격을 줄 수도 있기 때문에 이는 절대로 수용할 수 없는 제안이었다.

티베로에 전환방법론이 존재하지 않는다는 사실은 아직까지는 대규모 기간계 전환사례가 없었기 때문이며 그에 따라 필요성도 느끼지 못하고 있었던 것으로 생각되었다.

1장 개요에서도 언급하였지만 신규 프로젝트 혹은 작은 업무의 전환이라면 DBMS 신뢰도만으로도 성공적인 구축이 가능하겠지만, 대규모 업무전환이라면 반드시 어플리케이션 부하 재현방법을 포함한 탄탄한 방법론이 제시되어야 하므로 소속 회사의 프로젝트를 계기로 티베로가 그 방법론을 구축할 수 있도록 그들의 생각을 변화시키는 일이 가장 시급한 일이었고(그래야 소속 회사의 전환 프로젝트를 시작할 수 있고 성공도 할 수 있었기에) 이를 위해서는 어떤 식이든 재현이 가능하고, 필요하다라는 것을 직접 보여주고 증명하는 것이 가장 빠른 길이라 생각했다.

과연 어떤 방법이 있을까?

• [그림 2-1] 3-Tier 구조에서의 웹서비스 흐름
• 

[그림 2-1]의 일반적인 3-Tier 구조 웹서비스 인프라 환경을 살펴보자. 웹서버가 제공한 화면에서 사용자가 특정 조건을 선택한 후 검색 버튼 등을 통해 데이터를 불러오기 위한 이벤트를 발생시키면 1) 가장 먼저 웹서버에 HTTP REQUEST가 도착 한다.

해당 HTTP REQUEST에는 사용자가 발생시킨 이벤트에 해당하는 데이터를 불러오기 위한 각종 정보(메뉴명, 검색 조건 등)들이 해당 웹 페이지에 정의된 포맷으로 담겨 있는데 웹서버는 이 정보들을 활용하여 직접 처리할 것은 웹서버 내에서 처리하고 2) 추가적으로 필요한 REQUEST를 정해진 규칙에 따라 와스서버에 전송하게 된다.

3) 와스서버는 수신한 REQUEST에 해당하는 SQL들을 최종적으로 DB에 전송하게 되고 DB는 해당 SQL의 실행결과를 다시 와스서버에 전송하고, 와스 서버는 웹서버에, 웹서버는 사용자에 해당 정보를 차례차례 전송한다. 이 흐름을 자세히 살펴보면 부하 재현이 가능한 두 가지 가능성이 있다.

그렇다면 어떻게 저장하고 어떻게 전송할 수 있을까? 그리고 단기간에 일부라도 재현을 성공하기 위해선 어떤 가능성을 택해야 현명할까?

2번 방법의 경우는 SQL+Bind 변수 정보를 저장할 수 있다고 하더라도 이를 재현하기 위해선 와스서버가 DBMS와 통신하기 위해 맺고 있는 JDBC와 같은 전용 인터페이스를 먼저 구현해야 하므로 단기간에 성공하기는 어렵다고 판단하였다.

그러나 1번의 경우는 개발용 웹서버 혹은 와스서버를 활용하여 티베로 DB와 연동시키고 파일로 저장한 부하를 해당 서버로 전송하는 간단한 프로그램만 있다면 쉽게 재현이 가능하다고 판단하여 1번 방법에 집중하기로 했다.

먼저 저장은 네트워크 스위치에서 웹서버(혹은 와스서버)와 연결된 포트를 복제(Mirroring)하는 방식을 택하기로 했다.

그림 2-2의 ①번과 같이 원하는 스위치에 복제 설정(Mirroring)을 하고 노트북을 복제 Port에 연결한 다음 해당 노트북의 NIC(Network Interface Card)를 Wireshark와 같은 패킷 모니터링 툴을 통해 저장하면 쉽게 저장이 가능하다.

• [그림 2-2] 네트워크 캡쳐 & 파일 저장 Config 및 구성도

• ① 내부망 Switch Mirroring Config monitor session 1 source interface Gi0/1 - 2 rx monitor session 1 destination interface Gi0/10 웹서버와 와스서버가 통신하는 내부망 Switch의 Gi0/1, Gi0/2 번 Port를 Gi0/10으로 Mirroring (웹서버가 와스서버에 전송하는 packet은 네트워크 port 입장에선 수신이므로 rx 설정) ② Mirroring Packet을 파일로 저장 Mirroring Destination Port인 Gi0/10에 노트북을 연결한 후 Wireshark를 통해 packet을 File로 저장 * 캡처옵션1: 파일 분리 저장 (파일 한개 용량이 지나치게 커지지 않게 하기 위해) - 예시참고

  * 캡처옵션2: 패킷 필터(와스서버 request가 없는 패킷을 제외하기 위해) - 예시참고 (port 1111 or port 1112 or ..... ) 웹서버와 와스가 실제 연동하는 PORT만 캡처 and(ip[2:2]-((ip[0]&0x0f)<<2)-((tcp[12]&0xf0)>>2)!=96) DATA가 96인 PACKET은 제외 (와스서버 request가 없는 PUSH ACK) and(ip[2:2]-((ip[0]&0x0f)<<2)-((tcp[12]&0xf0)>>2)!=0) 실제 DATA가 0인 PACKET은 제외 필터옵션은 패킷을 실제로 수신하며 최대한 의미있는 것들만 저장될 수 있도록 소속 회사 상황에 맞도록 조정하도록 한다.

• [그림 2-3] 실제 Capture 내용
• 

이제 저장된 파일을 읽어 표준 포맷을 만들고 웹서버(혹은 와스서버)에 전송할 수있는 프로그램만 구현한다면 부하 재현이 가능하다. 프로그램의 상세 요건은 다음과 같다.

• 1. txt 형태로 저장된 파일을 순차적으로 Open한다.
• 2. 패킷의 헤더 54byte는 제거하고 데이터 부분만 STRING 형식으로 저장한다
• 3. java의 HttpURLConnection 등을 활용하여 앞에서 저장한 STRING을 POST DATA에 세팅하여 티베로와 연동된 테스트용 웹서버에 HTTP REQUEST를 전송한다.

위와 같은 요건을 만족시키는 프로그램은 SI 개발 경험이 풍부한 소속 회사의 인프라 총괄 담당자 1명과 티베로 본회 POC 담당 엔지니어 1명이 약 2주간 작업하여 구현할 수 있었다(약 200 lines의 java로 구성되어 있는 소스코드 전체를 부록에 공개하니 필요한 독자는 각 환경에 알맞게 수정하여 사용해보기 바란다).

그리고 해당 프로그램을 통해 캡처한 파일을 시간 단위로 읽어 들이며(crontab을 통해 수행) 1개 업무에 대해 약 41만회의 외산 DB로 수행된 SQL을 티베로로 재현한 결과 1) SQL Fail율 : 약 2.1% 2) 성능저하 : 약 23% 의 두 가지 결과를 도출할 수 있었다.

사실 이 방법은 캡처 파일 저장 시 필터 과정에서 상당수 데이터의 누락이 존재할 수 있고 저장된 파일을 시간 단위로 순차적으로 수행했기 때문에 트랜잭션을 정확히 재현했다고 볼 수는 없으며 PROFRAME(개발 프레임워크)에서 정의한 형식의 POST REQUEST에만 적용될 수 있는 등 여러 가지 한계점이 분명히 존재한다.

그러나 수동 테스트로는 정해진 시간 안에 도저히 수행할 수 없는 41만회의 SQL을 재현했고 Fail, 성능저하 등의 어플리케이션 호환성을 비교적 정확히 파악할 수 있었기 때문에 소속 회사의 POC 용도로 충분한 데이터를 추출할 수 있었으며 POC를 고려하는 여러 회사들에게도 자사 환경에 알맞게 조금의 수정 노력을 더하면 여전히 활용가치가 높다고 생각한다.

그리고 무엇보다 타 벤더의 DBMS 부하를 재현할 방법은 도저히 없을 것이고 DBMS 제품의 신뢰도만으로도 전환이 충분히 가능할 것이라는 티맥스의 생각을 변화시켜 고객사의 어플리케이션 안정화를 고려한 전환방법론이 반드시 필요하다는 것을 인지하도록 한 것이 가장 큰 의의라고 할 수 있다.

• [그림 2-4] 부하재현 구성도
• 

• [참고 2-1] Runner Program
• 1. SQL 성공률 : 97.9% (Fail 2.1%)
• 가. 성공횟수 : 412,971건
• 나. 실패횟수 : 8,873건
• 다. 총 6개의 실패 패턴을 찾아 일부는 패치, 일부는 APP 쿼리를 변경
• 2. SQL 수행 성능:약 23%의 CPU 성능 부하 발생
• [그림 2-5] 소속 회사 POC 상세결과
• 

한 회사의 DBA로서 1장에서 언급한 데이터베이스 변경으로 인한 어플리케이션 안정성 위협을 절대로 감수할 수 없다고 수년간 굳게 믿고 있었으나 위 POC 결과를 통해(그리고 해당 POC와 함께 준비한 여러 가지 사항(그림 2-6 참고)들로 인해) 몇몇 사항만 티맥스가 보완한다면 상당 수준의 안정성을 유지하며 전환이 가능할 것 같다는 희망이 보이기 시작했다.

• [그림 2-6] 티베로 DBMS 전환을 위한 소속 회사 준비 사항
• 

물론 완벽한 전환방법론이 존재한다 하더라도 DBMS 전환은 DBA를 포함 DB를 사용하는 모든 IT 소속 부서원에게 또 회사에도 매우 위험한 일임은 분명하지만 위험이 큰 만큼 위험 뒤에 감추어져 있는 이득(외산 DBMS Lock in 탈출, 비용절감, 지식상승, Object Reorg 효과, Tuning 등)도 매우 컸으므로 ‘안 된다’에서 ‘해보자’는 마음으로(적어도 방법론이 있으므로) 모두를 설득시킬 수 있었다.

그리고 티맥스는 소속 회사가 요구한 사항을 3개월 만에 전환 프로젝트에 적용할 만한 훌륭한 수준으로 개발하여 실제 전환 업무를 2016년 4월부터 시작할 수 있었다. 2.2장부터는 소속 회사의 요구 사항을 만족한 티베로 리플레이 제품의 구조 및 동작 그리고 실제 업무에 적용했을 때의 결과 등에 대해서 본격적으로 알아보자.

전환 프로젝트 시작 전 소속 회사의 요구 사항

1. 외산 DBMS에서 수행되는 소속 회사의 모든 업무 SQL들을 캡처하여 티베로에서 재현할 수 있는 방법론을 제시할 것

2. 재현된 SQL 중 호환이 안되는 것은 티베로 엔진을 수정하여 호환이 되도록 할 것(SQL 수정은 엔진에서 도저히 수용되지 않을 경우만 가능)