베리타스 i3 구축사례

Veritas i3 for Oracle, 한국전기안전공사 구축사례편

“자동화된 튜닝 기능을 통한 가이드라인 제공이 구입 이유다”

박덕근│한국비지네스써비스

여러분은 왜 i3 for Oracle(이하 i3)을 도입하려고 하는가 분명 골치 아픈 문제가 발생하고 있기 때문에 처방이 필요해서 일 것이다. 만약 i3의 도입을 검토하고 있던 사람이 이번 i3 구축 및 운영 사례 기사를 통해 얻고자 하는 점이라면 “그 골치 아픈 문제를 i3로 어떻게 해결했을까”일 것이다. 이번 원고에서 필자가 말하고자 하는 점이기도 하다.

골치 아픈 문제의 공통 요소는

그럼 기업에서 자사의 정보 시스템과 관련해 어떤 문제가 가장 골치 아픈 요소일까 필자가 많은 i3 구축 프로젝트에 참여했던 경험에 비춰볼 때 단 하나의 문제가 아닌 ‘총체적인 문제’란 점이 공통요소였다.

대부분 기업에서 발생되는 정보 시스템의 문제는 데이터베이스 관리 시스템(이하 데이터베이스)과 애플리케이션 성능에 관련된 부분이다. 이는 시스템 개발 단계에서의 애플리케이션 검증·개선(튜닝)·관리의 미흡으로 초래된다. 대규모 시스템에서는 애플리케이션에 대한 정확한 튜닝 포인트를 찾기가 어려운 것이 현실이다. 이 외에도 주어진 기간 내에 시스템을 구동(open)해야 하는 어려움 때문에 시스템 담당자는 하드웨어 업그레이드 또는 튜닝 전문가에 의존하려고 하지만 대부분 많은 비용을 지불하고도 근본적인 문제점을 찾지 못하는 실정이다. 또한 어떤 문제없이 시스템이 구동됐다고 해도 운영 안정화에 많은 인력·시간·비용이 소요된다는 점에서 기업은 고민하게 되고, 더구나 대규모 시스템에서는 전문가가 진단했더라도 예견하지 못한 문제점이 발생되지 않을 것이란 보장이 없다.

골치 아픈 문제에 대해 어느 정도 공감이 가는가 이런 문제에 대한 해결책으로 많은 사람들이 데이터베이스 성능관리 솔루션에 시선을 돌린다. 이 글에서는 그 중 하나인 i3가 여러분의 고민을 해결해 줄 솔루션으로 적합한지 객관적으로 판단할 수 있도록 한국전기안전공사의 i3 구축 및 운영사례를 통해 도입 배경부터 구축 후 어떤 성능 관리의 이점을 보였는지, 그리고 보완되어야 할 점은 무엇인지 살펴보도록 하겠다. 그럼 한국전기안전공사, 그 현장으로 들어가 보자.

한국전기안전공사의 시스템 상황

한국전기안전공사의 시스템 운영에 있어 가장 큰 고민은 잠재된 문제점(담당자가 확인할 수 없는)을 인지할 수 없다는 것과 안정적인 운영을 위한 담당 인력이 절대적으로 부족하다는 것이었다.

한국전기안전공사의 시스템은 데이터베이스 두 개와 WAS(Web Application Server) 두 개로 이뤄져 있었다. 두 명의 담당자가 데이터베이스, WAS 뿐만 아니라 네트워크 등의 전산시스템 자원을 관리하고 안전점검 전산 업무를 책임지고 있었으며, 때때로 외주 업체에서 개발한 프로그램을 일일이 관리·적용하고 있었다. <그림 1>은 한국전기안전공사의 시스템 구성도이다.

<그림 1> 한국전기안전공사 시스템 구성도

나보고 시스템 운영까지

<그림 1>만 언뜻 보면 시스템 자원이 충분해 별 걱정이 없어 보이지만, 자세히 들여다보면 특정한 시간대에 업무가 몰려 과도한 CPU 사용으로 인해 병목 현상이 발생하고 있었다. 특히 시스템 담당자는 개인 업무 진행에도 숨이 막힐 지경이었지만 시스템의 안정적 운영까지 책임져야 하는 상황이 더욱 목을 죄고 있었다. 이런 상황에 안정적 운영이 가능할까

한국전기안전공사는 시스템의 안정적 운영과 함께 운영되고 있는 시스템의 자동화된 모니터링을 통한 문제의 사전 감지와 이에 따른 문제 해결 방법을 모색할 수밖에 없었다. 따라서 인력 부족으로 오는 부족한 시간과 노력을 줄여 줄 데이터베이스 모니터링과 튜닝 툴을 검토하게 됐다. 한국전기안전공사에서는 데이터베이스의 안정적인 운영이라도 자동화된 툴이 책임져 준다면 상당한 도움을 받을 수 있는 상황이었다.

그럼 한국전기안전공사의 데이터베이스 튜닝 툴의 『검토-도입-구축-운영』 과정을 살펴보면서, i3가 한국전기안전공사의 시스템 운영에 어떤 영향을 주었는지 확인해보자.

DB 튜닝 문제 맞죠 해결 방법은

어느 날 한국전기안전공사의 전산 담당자에게서 연락이 왔다. 데이터베이스 운영에서 특별한 문제는 없는데, 특정 시간대에 장애가 발생하고 시스템 자원인 CPU가 과도하게 소비를 한다는 것이었다. 데이터베이스 튜닝의 문제점을 의심하게 됐고 i3에 대해 문의하고 싶다고 말했다. 담당자의 고민은, 첫째 시스템 운영에서의 Waiting의 원인이 무엇이며, 둘째는 시스템, WAS, 데이터베이스 중 어떤 쪽에서의 문제점이며, 셋째는 문제의 해결 방안은 있는가가 핵심이었다. 담당자와 좀 더 자세히 이야기를 나눈 후 그의 고민은 다음의 몇 가지로 압축될 수 있었다.

세션 kill 아니면 인덱스로 해결해

한국전기안전공사의 메인 데이터베이스 서버는 썬 파이어 4800 1대, DBMS는 오라클 9.2.0.4 싱글 노드로 구성돼 있었으며, 월말 온라인 트랜잭션은 동시 1000건 정도 발생되고 있었다. 월말과 월초가 아닌 월 중의 CPU 자원 사용률은 80% 미만이나 월말과 월초의 실적 집계 작업이 수행되는 시점에는 CPU 사용률은 95% 이상이었으며, 심지어 100%를 사용하는 심각한 상황을 초래하곤 했다. 또한 데이터베이스를 관리하는 시스템 관리자 및 데이터베이스 관리자는 다른 여타 담당자와 마찬가지로 관리자 대비 관리 서버의 수가 1대 5 이상의 비율로 솔루션의 사용 없이 모니터링 및 튜닝 작업이 불가능했다.

솔루션이 없는 상황에서는 육안으로 서버 자원의 상황을 모니터링 해야 하며, 문제되는 오라클 세션을 담당자가 직접 스 한 후 세션을 종료(kill)시키거나 필요시 인덱스를 생성해 문제점을 해결하는 방법을 사용했다. 게다이 소스를 확인해 튜닝 작업을 수행하는 것도 큰 무리가 있었다. 또한 유틸리티를 통한 세션 모니터링은 하나의 세션을 맺으며 작업을 수행하는 동안 데이터베이스의 행 발생시 응답을 받기 어려울 뿐만 아니라 CPU를 과다하게 사용하는 것이 원인이 되어 어려웠다. 지금 당장은 성능의 문제가 발생되는 SQL문에 대해 인덱스를 사용해 문제를 해결했지만, 과연 영향 받는 SQL문이 있는지에 대한 영향 분석 작업 없이 계속 인덱스를 생성하는 것도 사용자로써는 우려되는 일이었다.

모니터링 툴도 사용 못할 상황

i3 도입 전 한국전기안전공사는 시스템 모니터링을 위한 툴을 사용하고 있었다. 하지만 모니터링 툴로 인해 서버 피크 타임시 리소스 사용률이 높아지는 것이 큰 고민거리였다. 이런 문제는 평상시 Lock 문제 해결이나 세션별로 사용하는 SQL 문장 확인 등에는 모니터링 툴로도 부족함을 느끼지 못했으나, 연말과 연초 등 1년 중 최고의 피크 타임시에는 모니터링 툴 자체로 인해서 병목현상이 많이 발생했다. 하지만 이런 현상은 연말과 연초가 아닌 평상시에도 발생했으나 사용자나 관리자는 의례 발생하는 문제로 가볍게 넘기곤 했으며, 실적을 평가하는 시기와 맞물리면서 문제의 심각성은 간단히 넘길 사항이 아니었기에 불거진 것이다. 특히 동시에 많은 세션이 사용되면서 하나의 세션을 연결해 작업을 수행하는 것조차 성능에 부하가 발생하는 문제가 나타나면서 모니터링 작업도 불가능한 상황이 발생했다.

그 당시 한국전기안전공사의 전산 담당자는 “한국전기안전공사의 안전점검 시스템은 월말과 월초의 리소스 부족으로 인한 문제가 심각해 우선 툴 자체가 리소스를 적게 사용해야 한다”며, “튜닝이 익숙하지 않은 만큼 관리자 수에 비해 관리하는 시스템이 많은 경우라도 사용자가 솔루션의 도움으로 손쉽게 성능 관리 및 튜닝 작업이 가능해야 한다”고 강조했다.

i3 for Oracle을 통한 문제 발견

한국전기안전공사 데이터베이스의 문제점을 정확히 찾기 위해 i3를 설치한 후 진단해 본 결과 원인은 더욱 구체적으로 발견됐다.

첫째, 불필요한 자원의 사용으로 필요 이상의 과도한 CPU 사용, 둘째는 과도한 싱글 컬럼 인덱스 구성으로 인한 미사용 인덱스 발견, 셋째는 인덱스 부재로 Table Full Scan 발생으로 인한 과도한 I/O 발생, 마지막으로 불필요한 조인으로 인한 과도한 CPU 자원 사용 및 성능 저하로 요약됐다. 하지만 이것은 한국전기안전공사 시스템에서 발생하는 문제점 일 뿐 결코 한국전기안전공사에서 구입하고자 하는 솔루션의 기대치는 더 높았다.

한국전기안전공사가 요구하는 DB 튜닝 툴의 기능

한국전기안전공사 경영정보시스템 팀은 i3 도입을 위한 검토 작업에 들어갔다. 한국전기안전공사의 요구사항은 리소스를 적게 사용하는 자료 수집 방법과 쉬운 분석 방법 및 사용자도 손쉽게 튜닝 작업을 진행할 수 있는 다양한 기능 제공이 필요하다는 것이었다. 또한 24시간 계속적인 모니터링 및 시간대별·일자별 등 다양한 방법의 분석과 프로그램별로 SQL 문장의 변경내역을 확인, 그리고 실행계획의 히스토리를 확인하고자 하는 것이 핵심 요구사항이었다. DB 담당자의 튜닝 소프트웨어의 필수 요건을 보면 <표 1>과 같이 요약해 볼 수 있다.

<표 1> 한국전기안전공사 DB 담당자의 성능관리 솔루션의 필수 요건

i3 for Oracle을 선정한 이유

i3는 애플리케이션에 대한 수집된 통계정보를 이용해 원인 발견·분석·개선·적용 테스트를 실시해 성능을 개선할 수 있도록 제공하는 데이터베이스 성능관리 솔루션이다. 한국전기안전공사에서 i3를 선정한 이유는 무엇일까

<그림 2> i3 제품 구성도

한국전기안전공사 담당자는 i3를 선택한 이유에 대해 “가격 면에서는 여타의 툴에 비해 높은 편이지만 리소스를 적게 사용하며, SmartTune과 같은 자동화된 튜닝 기능으로 툴을 통한 손쉬운 가이드라인 제공이 가능한 점이 눈길을 끌었다”고 말한다. 또한 그는 “초보자도 쉽게 튜닝 기능을 사용할 수 있는 구성이 제품 선택에 큰 역할을 했으며, 여타 툴의 경우 특정 SQL문이 어느 프로그램에서 수행됐는지 연계 분석이 불가능하고 수집된 데이터를 일자 별, 시간대 별로 재분류하는 기능이 없었다”고 말한다. 특히 시스템 문제 발생 요소보다 제품 구입의 기대치가 더 높았음에도 i3가 이를 해결할 수 있는 기능을 갖추고 있는 점이 가장 큰 강점이라고 강조했다. i3의 필수 기능별 세부 사항을 <표 2>에 정리했다.

<표 2> i3의 필수 기능별 세부 사항

i3를 통한 한국전기안전공사의 튜닝 작업

한국전기안전공사에서 i3를 통해 SQL의 튜닝이 우선적으로 필요했다. 툴을 통해 문제가 되는(CPU 과다 사용, I/O waiting 문제 요소) 부분을 우선적으로 모니터링을 했다. 수없이 많이 수행되는 SQL문들 중에 튜닝 대상이 되는 SQL을 찾아 튜닝을 진행했다. 튜닝한 후 비교 과정을 통해 SQL문의 성능 향상을 확인할 수 있었다.

튜닝에서 가장 어렵고 시간이 많이 걸리는 부분은 튜닝의 대상이 되는 SQL문을 선정하는 것이다. i3에서는 자체 부하 없이 데이터베이스에서 수행되는 모든 SQL을 저장한다. 이 저장된 SQL들을 활용해 한국전기안전공사의 데이터베이스 안정화 작업을 진행하게 됐던 것이다. <그림 3-1>, <그림 3-2>. <그림 3-3>에서 i3 for Oracle을 활용해 튜닝 대상 SQL을 선정하는 과정을 확인할 수 있다.

<그림 3-1> 자원 소비가 많은 데이터베이스 찾기

<그림 3-2> 튜닝 대상 데이터베이스에서 튜닝 대상 시점 및 SQL 찾기

<그림 3-3> 튜닝 대상 SQL 소스 및 실행계획 확인

문제의 원인은 단연 SQL

튜닝을 하기 위해서는 가장 중요한 부분이 데이터베이스에서 수행되는 모든 정보의 수집이다(성능 정보 수집). i3 자체 엔진이 데이터베이스에 설치되는 시점부터 데이터베이스에서 수행되는 모든 정보(프로그램, SQL, 세션, 모듈, 연계된 기능)는 자동 수집이 된다. 특히 메모리 다이렉트 액세스 기법을 사용해 정보를 수집하므로 정확하고 다양한 정보를 수집해도 툴 자체가 데이터베이스에 주는 부하는 거의 없다.

i3를 설치한 시점부터 저장된 성능 정보를 활용해 튜닝 준비를 마무리 했다. i3의 장기간 데이터를 저장하는 기능을 활용해서 실시간으로 데이터베이스에서 일어나는 문제점을 파악하고, 특정(문제가 되는 시점) 기간 동안에 문제가 됐던 요소들을 선별할 수 있으므로 담당자가 모니터링을 하지 못한 시점의 문제점도 확인할 수 있다. 이런 과정을 통해서 운영 데이터베이스에서 문제가 되었던 시점(튜닝 대상 지점 선정)을 결정할 수 있었다.

문제가 되는 기간에 데이터베이스에서 가장 많은 영향을 끼쳤던 부분은 단연 SQL이었다. 우선 튜닝 대상 시점에 수행된 모든 SQL을 확인할 수 있었다. 한국전기안전공사의 경우 CPU 사용량이 상대적으로 많아 CPU를 많이 점유한 SQL문을 기준으로 소트(sort)해 튜닝 대상 SQL문을 찾았다. 상위 10개의 SQL문이 집중적으로 CPU를 점유했으며, 이 상위 10개의 SQL을 집중 튜닝 대상 SQL문으로 결정했다. 튜닝 대상 SQL문을 수행한 프로그램, 수행한 유저, 수행된 시스템 등의 연계 관계를 조사해 실제 튜닝을 하기 위한 사전 준비는 모두 완료했다(튜닝 대상 SQL 선정).

i3의 자동화된 튜닝 기능(StmarTune)을 활용해 튜닝 대상이 되는 SQL 보다 더 우수한 SQL문을 확인해 보고, 인덱스 유무를 확인해 적절한 인덱스가 있는지 적절한 인덱스를 참조하고 있는지를 판단했다. 이러한 튜닝 방법(statement 튜닝, 오브젝트 튜닝)들을 적절히 활용해 좀 더 나은 SQL로 수정이 가능했다(튜닝 기법을 활용한 SQL 튜닝). 튜닝 후 i3의 시뮬레이션 기능을 활용해 튜닝 전, 후 SQL의 성능 비교를 했다(튜닝 전후 비교). 운영 시스템에 바로 적용을 하기 전 충분한 시뮬레이할 수 있었다.

튜닝 된 SQL을 운영시스템에 적용시킨 후 특정 기간 동안 튜닝 된 SQL의 자원소비율(CPU 점유율)을 확인해 봄으로써 튜닝 후의 효과에 대해서 검증이 가능했다(검증). 한국전기안전공사에서 i3를 통한 이러한 튜닝을 반복적으로 함으로써 문제가 되는 튜닝 대상 SQL을 차츰 줄여 나갈 수 있었다.

<그림 4-1> 성능 정보 수집

<그림 4-2> 튜닝 대상 지점 선정

<그림 4-3> 튜닝 대상 SQL 선정

<그림 4-4> 튜닝 기법을 활용한 SQL 튜닝

<그림 4-5> 튜닝 전과 후의 비교

운영 중의 i3 활용

한국전기안전공사 담당자에 따르면 “i3를 이용한 SQL 문장 튜닝에서 효과를 볼 수 있는 것 중 하나가 사용조한다. 이는 기존의 CPU 사용률이 줄어들었음을 보여주는 것으로, 기존의 I/O 발생 대비 I/O 리소스 자원 사용률이 줄어들었다는 의미다. 한국전기안전공사는 항상 사용자의 작업량을 입력하는 Insert 작업과 작업자의 정보 및 의뢰 정보를 조회하는 업무가 공존하고 있어 CPU 자원 사용률은 업무 시간 동안 항상 70% 이상을 유지하고 있었다. 그러던 것이 i3 솔루션의 적용 후 작업량은 기존에 비해 30% 가량 증가(업무 증가)한 반면 문제가 되었던 CPU 사용률은 70%대를 유지하고 있으므로, 그 만큼 시스템은 더 안정적으로 운영됐다.

DB 관리자 입장에서 본 i3

i3는 데이터베이스 관리자의 경우 시스템 운영에 더 필요한 솔루션이라고 강조하는 사례가 많다. “i3 도입 전에는 SQL 튜닝 업무를 하기 위해 여러 스크립트를 수행하거나 관리 툴인 A를 사용했으나 스크립트는 다소 번거롭고 다른 툴은 자원 사용이 많다”란 의견부터, “데이터베이스 관리자로써 좋았던 것은 항상 모니터링 작업이 필요 없이 다른 업무 중에도 문제가 발생했을 경우 원인을 손쉽게 파악하고 판단을 하는데 많은 도움을 받을 수 있다”, 그리고 “성능에 문제가 발생했을 경우 단순 인덱스 생성의 작업만을 통한 성능 개선이 아닌 영향 분석을 통해 다른 SQL문과의 연계 분석 작업을 통한 인덱스 생성 등을 고려해 도움을 받고 있다”까지 구체적으로 i3 기능을 통해 어떤 문제가 해결될 수 있는지가 언급됐다. 다음은 i3를 통해 데이터베이스 운영시 활용할 수 있는 부분에 대해 정리해봤다.

무엇보다 한국전기안전공사의 경우 i3를 사용한 후 명확하지 않은 문제의 원인을 발견했다는 점, 튜닝을 통한 불필요한 CPU 자원 감소로 시스템의 병목현상을 제거했다는 점, 그리고 지속적인 튜닝으로 인한 향후 문제 발생 소지를 없앴다는 점 등을 자동으로 해결해 나가고 있다.

<그림 5> i3를 활용한 데이터베이스 운영

<그림 6-1> 문제된 웹의 성능 정보 및 메쏘드 안의 SQL 정보 확인

<그림 6-2> 해당 URL 정보 확인

<그림 6-3> 연계된 SQL 확인

i3의 보완할 점은 무엇일까

일반적으로 i3를 도입하는데 있어 제품 소개, 제품 설치 후 시스템 진단 및 튜닝, 향후 문제 요소(튜닝 대상 요소) 확인 및 필요성 인지, 제품 도입이란 과정을 거친다. 한국전기안전공사도 제품을 도입하기 전 i3 구축을 통해 현 시스템의 진단, 튜닝, 검증의 과정을 거쳤으며, 이런 세 가지 과정에 만족해 제품 도입이 가능했다. 하지만 한국전기안전공사에서는 i3의 보완할 점에 대해 몇 가지를 지적하고 있다.

첫째는 write 기능 부재다. write(session kill 및 insert 등) 기능이 전혀 없어 관리나 조치가 필요할 경우 다른 유틸이나 관리 콘솔을 따로 사용해야 하는 불편함이 있다는 것이다. 둘째는 커스터마하는 제품에 대한 수정 작업은 전혀 할 수가 없어 결국 담당자는 불편하지만 제품의 기능에 맞춰서 작업을 해야 한다. 마지막으로 지적한 것은 모니터링 화면의 단순화 부분이다. 역동적으로 모니터링 화면이 움직이지 않아 직접적으로 시스템의 현 상황을 확인하기에는 단조로움이 있다는 점이다.

시스템의 안정적인 운영을 위해서는 실시간 모니터링, 문제 발생시 빠른 대처, 장애 조치 후 재 발생 방지 등의 작업을 지속적으로 해야 한다. 하지만 국내의 많은 시스템 관리는 현실적으로(인력 부족, 예산 부족) 그렇게 이뤄지지 못하고 있는 실정이다. 데이터베이스에 툴을 적용시킴으로써 현실적으로 불가능한 요소들을 많이 해결할 수 있다. 여러분의 데이터베이스 튜닝 파트너가 가져야 할 능력은 앞에서 많이 언급을 했다. 파트너의 능력, 데이터베이스와의 조화, 비용 등을 고려해 판단하길 바란다.