베리타스 i3 기술자료

VERITAS i3 for Oracle, 기능 분석

i3의 App 튜닝 기능을 꼼꼼히 확인하라!

황규순 │한국비지네스써비스

데이터베이스 성능 관리 솔루션 여기서 성능이라는 개념은 어느 특정 사이트에만 적용되는 그 무언가가 아닌 모든 사이트의 기본이란 사실은 인식하고 있을 것이다. 그래서 일까 몇 년 사이 새로운 데이터베이스 성능 관리 솔루션이 마구 쏟아져 나왔으며, 그 과정에서 전문 튜너들도 많이 생겨났다. 그만큼 DBA에게 백업과 복구는 기본으로 자리 잡은 셈이다.

주변에서 “좋은 DBA의 필수 사항은 무엇이라고 생각하나요”라고 질문하면, 자연스럽게 튜닝을 잘 할 수 있는 DBA라고 말한다. 튜닝은 사람이 하는 작업이다. 그러나 튜닝을 하기 위한 자료 수집 작업이나 튜닝 과정에서 분석을 위해 필요한 기능을 제공하는 작업은 사람이 할 수 있는 것이 아니다. 물론 사람이 할 수도 있지만 그런 작업을 하기 위해 투입되는 인력의 리소스와 그에 따른 비용 산출, 그리고 안정성을 고려한다면 결론은 뜻밖에도 간단하다. 바로 자사의 시스템 성능 향상을 목적으로 가장 적합한 데이터베이스 성능 관리 솔루션을 도입해 제대로 활용하는 것 아닐까

필자가 말하고자 하는 것은 결코 베리타스 i3 for Oracle(이하 i3)을 추천한다는 말이 아니다. 각 솔루션의 기능을 제대로 살펴보고 구입할 때란 것이다. 언제까지 ‘숫자 3’을 고집할 것인가

DB 성능관리 솔루션 구입시 점검 포인트

우선 i3의 기능을 살펴보기 전 데이터베이스 성능 관리 솔루션이 해야 할 역할이 무엇인가를 명확히 정의하고 진행하는 것이 여러분의 판단을 도울 것이라 생각한다. 그 역할이 명확해지면, 솔루션이 갖춰야 할 기능 역시 뚜렷해지지 않겠는가.

왜 이런 기능이 있는 걸까

데이터베이스 성능 관리 솔루션을 구매하는 이유는 무엇인가 바로 시스템의 성능 향상을 꾀하기 위해서다. 그럼 시스템의 성능 향상을 위해서는 어떻게 해야 할까

우선 애플리케이션이 시스템의 CPU, I/O 등의 자원을 어떻게 사용하고 있는지에 대해 이해하면서 접근할 필요가 있다. 그리고 접근 방식은 거의 사전에 또는 자동으로 결정되는 경우가 많기 때문에 개개의 처리 성능이 단순하게 처리 로직의 문제가 있는지 검사해 튜닝을 실시해야 한다. 개별 프로세스나 처리시 응답시간을 튜닝하는 것은 당연히 이뤄져야 한다. 하지만 어떠한 경우에는 데이터 볼륨, 이용 거점, 이용 형태 등이 I/O에 비해 빈번하게 변화하기도 한다. 이에 대응하지 못한 애플리케이션은 바로 수명이 다할 뿐만 아니라 개발 이상으로 번잡한 유지보수를 요구하는 경우도 있으므로 유연성을 고려한 객체 튜닝이 중요하다.

유연성 있는 객체 튜닝을 위해서는 시스템 운영 중에 실시간 기록(Real-time Trace)을 통해 가능한 한 정확하게 튜닝 포인트(애플리케이션 이름, SQL 문장 등)를 찾아내야 한다. 그리고 단위 사용자 중심의 애플리케이션 성능저하 원인 및 전체적인 애플리케이션 통합 분석으로 정확한 튜닝을 지원해야 한다.

나아가 SQL 문장 등 특정 애플리케이션의 성능 향상을 위해 애플리케이션 수정시 타 애플리케이션과의 상호 영향 관계를 분석해 튜닝을 실시하는 것이 효과적이다. 더욱이 사용자가 성능개선 효과를 직관적으로 경험할 수 있도록 해야 하며, 관리자 측면에서도 운영 관리가 용이해야 한다. 이점은 보다 실질적인 차원에서 매우 중요한 포인트가 된다.

그리고 광범위한 튜닝 결정을 위해서는 데이터베이스 객체들과 SQL 문장 사이의 관계를 이해하는 것이 중요하다. 우선 테이블 스페이스 차원에서 시작한다. 테이블 스페이스와 그곳에 저장된 객체를 구성하는 오라클 파일을 살펴보고 데이터베이스 객체들의 논리적 저장 관계를 검토하는 방법이 필요하다.

또한 각 객체에 대한 조합(associate) 또는 그것과 관련된 모든 다른 객체나 그 객체가 속하는 사용자를 보고 조합을 참고해 튜닝 해야 한다. 각각의 객체(테이블 스페이스, 사용자, 테이블 등)에 접근하는 SQL 문장을 관련시켜 볼 수 있으며, 데이터베이스 객체와 SQL 문장 사이의 관련성을 비교해 정보를 분석하는 것도 필요하다. 데이터베이스 성능 관리 솔루션이 어떤 기능을 갖고 있어야 할 지 최대한 짧고 명확하게 정리해 보려고 노력했다. 감이 오는가

DB 성능 관리 솔루션의 필수 요건

앞의 내용을 토대로 데이터베이스 성능 관리 솔루션이 갖춰야 할 사항을 10가지 정도로 정리해 보면 다음과 같다.

<고객의 특별한 요구를 충족시키는 포괄적인 핵심 기능성>

• 다양한 시스템 환경을 조정하기 위한 멀티 플랫폼의 지원
• 업무 운영상 필요한 애플리케이션 및 모듈 인식 지원
• 최소 오버헤드(낮은 CPU 자원 사용)를 통한 정보 수집
• 24시간 7일(365일)의 성능 데이터를 수집하기 위한 성능 모니터링
• 문제 있는 SQL 문장 검색(특정 자원을 과하게 쓰거나, 병목현상의 원인이 되는 SQL)
• 데이터 또는 고객 수의 증가에 의한 문제의 원인을 결정할 수 있는 기능
• 다양한 사용 형태에 따라 사용자에 의한 테이블과 인덱스의 문제를 분석 대해 튜닝 할 수 있도록 여러 오라클 데이터베이스 버전의 지원
• 최선의 시스템 선택과 사이징을 위해 자원 소비 정도와 과거 자원 소비 경향에 대한 분석을 할 수 있는 기능

i3 for Oracle 기능 대탐험

그럼 본격적으로 i3가 어떤 기능을 갖춘 솔루션인지 살펴보도록 하자. 유닉스 혹은 윈도우 NT 시스템, 오라클 RDBMS, 일반 애플리케이션 및 ERP 애플리케이션 환경에서는 다수의 사용자가 늘어나는 대량의 데이터를 사용할 때 발생 가능한 병목(Bottleneck) 상황을 분석하고 튜닝 해야만 한다.

그래야 문제 발생시 정확한 원인 분석을 통해 미연에 방지할 수 있는 방안을 마련할 수 있기 때문이다. 이러한 일련의 성능 개선 활동은 운영 환경 하에서 지속적으로 유지되어야 한다. 다음의 i3 기능 설명과 관련해 매뉴얼 식으로 나열하기보다 해당 기능이 왜 필요한가를 고객 입장에서 덧붙여 필요성을 쉽게 이해할 수 있도록 설명해 나가겠다.

그럼 본격적으로 i3가 어떤 기능을 갖춘 솔루션인지 살펴보도록 하자. 유닉스 혹은 윈도우 NT 시스템, 오라클 RDBMS, 일반 애플리케이션 및 ERP 애플리케이션 환경에서는 다수의 사용자가 늘어나는 대량의 데이터를 사용할 때 발생 가능한 병목(Bottleneck) 상황을 분석하고 튜닝 해야만 한다. 그래야 문제 발생시 정확한 원인 분석을 통해 미연에 방지할 수 있는 방안을 마련할 수 있기 때문이다. 이러한 일련의 성능 개선 활동은 운영 환경 하에서 지속적으로 유지되어야 한다. 다음의 i3 기능 설명과 관련해 매뉴얼 식으로 나열하기보다 해당 기능이 왜 필요한가를 고객 입장에서 덧붙여 필요성을 쉽게 이해할 수 있도록 설명해 나가겠다.

모니터링 할 때만 장애가 발생할까

i3는 히스토리 정보를 기반으로 사용자가 문제 발생 시점과 원인을 쉽게 발견할 수 있다. 사용자가 365일 24시간 내내 모니터링을 할 수는 없기에 더욱 필요한 기능이다. 특히 장애는 사용자가 모니터링 하는 때에만 발생하는 것이 아니다. 사용자가 퇴근한 이후 시간, 즉 특정 배치 작업이 수행되는 동안 장애는 발생할 수 있으며, 장애가 발생한 시점의 데이터가 존재하지 않아 원인을 찾을 수 없는 경우도 발생한다. 이를 위해 히스토리 정보는 반드시 저장되어 사용자가 원하는 시점의 데이터를 손쉽게 검출해 분석이 가능해야 한다.

일반적으로 금융권 및 통신사의 경우 야간의 배치작업은 특별한 의미를 갖고 있다. 하루 동안의 데이터를 야간의 일 배치로 수행하는 경우가 많은데, 이 경우 야간의 배치작업이 아침 출근시간까지 수행될 경우 장애로 처리가 된다. 매일 매일의 일 배치 작업을 위해 DBA가 밤새도록 작업 수행 여부를 지켜보고 있다는 것은 하루하루가 곤욕일 것이다. 실제 밤새도록 발생한 장애의 원인이 성능에 의한 문제였던 경우가 상당히 많다. 그 결과 고객들은 온라인 중에 발생한 장애의 원인을 히스토리 정보로 확인하는 것보다 DBA가 퇴근한 이후, 히스토리 정보와 문제가 발생한 원인을 분석해 향후 발생할 문제점이 없는지 살펴보는 것에 대해 더 큰 안도감을 느낀다.

<그림 1> i3 for Oracle의 일별 자원소비율 비교

문제 SQL 발생시 해당 애플리케이션 분석과 튜닝

데이터베이스에서 성능 문제가 발생하는 경우 80% 이상은 악성 SQL문이 수행되면서 과도한 CPU 사용이나 I/O가 발생돼 성능 저하로 이어진 경우이다. 이런 경우 문제가 발생된 SQL문을 실시간으로 확인해 실행계획을 살펴보고 문제가 되는 요소를 찾을 수 있어야 하며, 그 문제에 대한 해결책 또한 즉시 발견 가능해야 한다.

현재 데이터베이스 성능에 이상이 있다면 일반적으로 수행 중인 SQL문이 악성 SQL문인 경우가 많다. 이 경우 실시간으로 수행 중인 세션을 모니터링 하고 SQL문을 찾아서 왜 문제가 발생한 것인지, 문제가 발생한 SQL문의 실행계획은 어떻게 수립되고 있는지 등 하나의 스크립트 내지는 모니터링을 통해 확인하는 것은 쉽지 않다. 따라서 i3에서 제공되는 모든 일련의 작업이 한 화면에서 이뤄져 원인 분석에서 해결 방안까지 제공 받는 기능은 고객들에게 좋은 해결책이 될 것이다.

다수 사용자에 의해 향후 발생될 문제 진단

일반적으로 튜닝은 현시점의 데이터와 사용자를 중심으로 수행된다. 앞으로 늘어날 데이터 및 사용자까지 고려해 튜닝을 진행하는 것은 쉽지 않다. 그러나 대용량 데이터를 지향하는 요즘, 현 시점의 데이터를 중심으로 튜닝 작업을 진행하는 것은 향후 발하는 것과 같다.

i3를 활용할 경우 하루 동안 수행되는 수행횟수와 자원소비율을 비교해 일주일 동안의 트렌드를 분석하고 더 나아가 한 달동안의 트렌드를 분석한다면 데이터 및 사용자의 증가 추이를 분석할 수 있다. 이 데이터를 기반으로 현재의 데이터는 데이터의 양이 작아 풀 스캔이 성능에 용이할 수 있으나 데이터의 증가에 의해 어느 임계치에 도달할 경우 인덱스를 통한 스캔이 성능에 도움이 될 것이라는 SQL문 튜닝에 대한 계획이 수립될 수 있다.

별도의 클라이언트 설치가 필요 없는 웹 GUI 제공

i3는 별도의 클라이언트 프로그램 설치가 필요 없이 하나의 웹 화면을 통해 접속 사용자는 사용자 지정으로 권한을 설정할 수 있으며, 해당 권한을 통해 여러 개의 인스턴스 중 특정 인스턴스에만 접근해 확인할 수 있다.

몇 년 전 성능 관리 솔루션은 DBA의 전유물로 통한 적이 있었다. 그러나 성능이 개발 초기 단계부터 도입되는 현재 시점에서는 어느 특정인들의 모니터링을 위한 솔루션이 아닌 개발자를 통해 초기부터 튜닝된 사항을 반영하겠다는 고객사들도 많이 늘어났다. 이 경우 일반적인 방법은 클라이언트를 여러 개 구워서 흩어져 있는 개발자 및 관련 사용자들에게 설치를 요구하는 예가 많다. 이런 설치 작업은 설치하는 엔지니어들도, 설치를 하려는 관련 사용자들도 참으로 귀찮은 일이 아닐 수 없다. 클라이언트를 설치하며 셋팅하는 작업의 시간 및 노력() 정도를 줄여주며, 사용자들마다 인스턴스를 지정해 관리가 가능하도록 하는 것 또한 세심한 배려이다.

피크 타임 발생시 정확한 문제 원인 분석

모든 사이트들마다 그 사이트의 업무와 연관돼 있는 ‘피크 타임’이라는 것이 존재한다. 하루 동안의 성능 추이를 통해 해당 시스템의 업무를 짐작할 수 있을 뿐만 아니라, 어느 시점이 피크 타임이라는 것을 짐작할 수 있다. 예를 들어 MIS 시스템인 경우 출근 시간대인 오전 8시부터 10시까지가 업무 피크 타임이며, 증권사 사이트의 경우 장이 시작되는 시점인 오전 9시부터 9시 30분, 장이 마감되는 시간인 오후 3시부터 3시 30분까지가 피크 타임으로, 이때 성능 문제가 가장 많이 발생된다. 이처럼 해당 시스템의 업무 성향에 따라 피크 타임은 달라진다. 이런 업무 성향을 파악해 정확한 문제의 원인을 파악하고 분석할 필요가 있다.

일반적으로 성능의 문제가 발생하는 경우는 다른 시간대와 동일한 SQL문이 수행되더라도 동시에 여러 트랜잭션이 몰려서 수행되는 경우가 대부분이다. 이 경우 사이트에서는 피크 타임으로 분리되며, 0.1초라도 줄이기 위한 튜닝 작업을 수행한다. 결국 튜닝이란 평상시 시간을 위한 작업이 아닌 피크 타임의 수행시간을 줄이기으로 수행되는 트랜잭션이 발생하는 이벤트를 분석한다. 예를 들어 SQL문 튜닝 작업이 어느 정도 수행됐음에도 I/O를 줄이는 방법을 찾는다. 빈번하게 수공하는 베리타스 파일 시스템이나 볼륨 매니/O를 줄이는 방법도 고려하게 된다.

오브젝트 튜닝

인덱스는 우리가 책에서 특정 항목을 찾고자 할 경우 머리글을 나타내는 것과 같은 것으로, 필요한 항목을 쉽고 빠르게 찾도록 도와주는 것과 같다. 이런 인덱스가 존재하지 않을 경우 CPU와 I/O 자원 사용률이 증가하는 성능 저하 문제는 당연한 현상이다.

인덱스가 존재하거나 기존의 인덱스를 변경하는 작업에 대한 결정은 단순히 생성하거나 변경하는 것만으로 해결되는 것이 아니다. 이는 현재 수행되는 SQL문에는 약이 될 수 있으나, 기존의 인덱스를 사용하거나 참조하는 SQL문에 있어서는 오히려 독이 되는 경우가 있다. 이런 이유에서 인덱스를 생성하거나 변경하기 전 반드시 영향 분석 작업이 병행돼야만 하며, 영향 분석 작업 후 변경 여부에 대한 판단을 내려야 한다. i3는 영향 분석 작업 수행이 용이해 성능 저하의 악영향 발생 가능성을 차단시켜 준다.

일례로 몇 년 전 사이트를 지원하는 과정에서 문제가 발생됐다. 그 사이트는 많은 사용자를 보유한 금융권 사이트로써 오픈된 지 얼마 되지 않았다. 현재 사이트 오픈 기념으로 특정 이벤트를 진행하고 있는 과정에서 전혀 예상치 못한 문제가 발생했다. 적절한 인덱스가 존재하지 않아 수십만 건에 달하는 특정 테이블이 풀테이블 스캔으로 발생하고 있었다. 그 결과 시스템은 과도한 CPU와 I/O, LATCH 등의 문제가 발생했으며, 사용자는 해당 테이블에 적절한 인덱스가 부재하다는 사실을 알고 즉시 해당 테이블의 접근을 막고 인덱스를 생성했다. 그 결과 해당 SQL문은 풀테이블 스캔은 피할 수 있었으나, 그와 연관된 SQL문은 오히려 성능 저하의 원인이 됐다. 연관된 SQL문이 기존의 사용하던 인덱스를 피하고 좀 전에 생성한 인덱스를 사용하게 됐다. 오히려 튜닝이 독이 되는 순간이었다. 결국 그 사이트는 공지를 띄워 업무를 중지하고 관련된 모든 SQL문을 검토해 인덱스를 재조정하는 작업을 수행하게 됐다. 이처럼 인덱스 변경에 따른 영향 분석은 절대로 성능 관리에서 간과해서는 안 되는 중요한 기능이다.

<그림 2> What-If를 통한 영향 분석

비효율적인 SQL문에 대한 대체 SQL문 제시 및 인덱스 권고

앞서 언급한 대로 튜닝 작업은 사람이 해야 하는 작업이다. 자신이 담당하고 있는 데이터베이스에서 수행되고 있는 SQL문에 대해서는 외부에서 튜닝 작업을 수행하는 컨설턴트보다 더 낫다는 것을 잊지 말자. 그러나 일반적으로 사용자들의 인식은 튜닝은 아무나 하는 작업이 아니라는 인식이 강하다. 튜닝은 특정한 전문가만이 하는 작업으로 인식해 엄청난 비용을 부담하는 경우가 많다. 모든 고객들은 튜닝 기술에 목말라 한다. 하지만 문제가 되는 SQL문에 대해 어떻게 튜닝을 해야 할지 몰라 고민하며 포기하는 경우가 비일비재하다. 이때 대체 SQL문을 제시 받는다던지 인덱스를 권고 받는다면 어떨까 i3의 대체 SQL문제시 및 인덱스 권고 기능은 어딘가에 믿을 만한 조언자를 옆에 두고 길을 가는 것과 같은 것이다.

SmartTune을 통한 데이터베이스 분석 정보 제공

오라클 튜닝이란 참 어렵다. 게다가 경우의 수도 참 많다. 하지만 버전이 향상될수록 지능적으로 변하고 있는 것은 누구나 공감할 것이다. i3 솔루션을 지원하는 과정에서 필자는 오라클이 아닌 다른 데이터베이스도 많이 접하게 됐다. 현재 우리나라 데이터베이스 시장에 오라아닌 다른 데이터베이스를 사용하는 고객사도 참 많다. 뿐만 아니라 사이트 규MS-SQL을 병행해 사용하는 사이트도 많다. 예전 필자는 DB2 엔지니어를 만나 얘기를 나눈 적이 있다. DB2가 오라클에 비해 사용자가 적은 이유가 무엇이라고 생각하느냐는과 다른 점은 데이터베이스 변경 작업이 불가해(예를 들어 데이터베이스 엔진 튜닝, SQL 튜닝 등) 틈새시장이 적어 관련된 솔루션이 적고 그에 따라 고객들에게 인지도 또한 적어지고 있다”는 것이다. 이처럼 오라클은 사용자들에게 해당 시스템의 최적을 위해 커스터마이징이라는 것을 가능하도록 한다.

i3의 SmartTune은 오라클 이벤트를 히스토리 정보로 저장해 문제점을 발견하고 분석해 문제점을 제시한다. 또한 실QL문 리스트와 오히려 성능이 저하된 SQL문 리스트를 비교, 향후 발생될 수 있는 성능 문제를 미리 감지하고 해결할 수 있도록 제공한다.

예를 들어 과도한 I/O가 발생할 경우 문제점을 지적하고 그 문제점을 지적하게 된 통계정보를 수행횟수와 대비해 평균값을 1시간 단위 및 일별 단위로 제공한다. 또한 지식 정보를 통한 해결책을 제시해 어떻게 하면 이런 문제를 줄일 수 있을지 다양한 경우를 통해 제공한다.

미사용 오브젝트 관리 및 특정 접근 방법의 SQL문 추출 기능

데이터베이스를 관리하는 DBA에게 미사용 오브젝트 추출 및 풀테이블 스캔이 발생하는 SQL문을 추출하는 작업을 지원하는 것은 참 매력적인 기능 중 하나이다. DBA라면 한번쯤 미사용 오브젝트를 제거하고 싶은 충동을 느낀다. 스페이스 관리뿐만 아니라 성능 향상에도 큰 도움이 되기 때문이다. 그러나 미사용 오브젝트에 대한 판단은 쉽게 서지 않는다. 사용하지 않을 것이라는 심증은 있지만 물증은 존재하지 않아, 만일 자신이 이 인덱스를 제거해 오히려 참조하는 SQL문이 생겨 성능에 문제를 일으키진 않을지 그 누구도 확신할 수 없기 때문이다. 이를 위해 i3는 실행계획을 저장해 저장된 실행계획을 기반으로 미사용 인덱스 및 특정 접근 방법의 SQL문을 추출해 내는 작업을 수행한다. 실행계획은 언제든지 변경이 가능하다. 데이터 증가에 따라 혹은 새로운 인덱스 추가에 따라 옵티마이저는 필요시 실행계획을 변경한다. SQL문별 실행계획은 변경된 히스토리를 기반으로 3개의 SQL문을 저장한다. 이 데이터를 기반으로 미사용 오브젝트 추출 및 특정 접근 방법에 따른 SQL문 추출을 이용한다면 최적화된 성능을 유지할 수 있다.

SmartLink 이용한 멀티 티어 환경의 연계 분석

멀티 티어 환경에서 발생하는 성능 문제를 데이터베이스 관점에서만 접근해야 할까 이 문제는 모든 DBA 뿐만 아니라 IT 환이라면 누구나 공감할 것이다. 여기에서 장애란 여러 가지 의미가 있다. 원하는 만큼의 성능이 나오지 않아 서비스가 느려지는 것도 장애의 하나로 볼 수 있으며, 서비스가 이뤄지지 않은 것 또한 장애라고 말할 수 있다.

일반적으로 장애가 발생할 경우 제일 먼저 하는 작업 중 하나는 자신이 맡고 있는 서비스가 문제가 아니라는 것을 입증하는 것이다. 그 결과 증거 자료가 불충분한 업무 담당자는 장애에 대해 소서는 성능의 문제가 대부분 데이터를 처리하는 데이터베이스에 몰려 있었지만 현재의 3-Tier 이상의 환경에서는 성능 문제의 원인에 대해 아무도 확신할 수 없는 경우가 대부분이다.

좀 더 눈을 넓혀 앞단의 WAS, WEB을 통한 연계 분석이 수행되어야만 문제의 명확한 원인을 파악할 수 있으며, 앞서 수행한 문제점을 서로 미루기에 급급한 핑퐁 작업이 줄어들 것이다.

<그림 3> VERITAS i3의 Insight를 통한 연계분석

모니터링 및 리포트 솔루션

i3 for Oracle 솔루션과 더불어 하나의 패키지로 사용되고 있는 솔루션인 Inform Alerts와 Inform Foresight는 모니터링과 리포트를 제공하는 기능을 포함하고 있는 솔루션이다.

우리나라에서 모니터링과 리포트 제공은 필수 기능으로 통한다. 실시간 발생하고 있는 현상을 시각적으로 표현하는 기능 및 현재 발생한 상황 및 앞으로 발생할 문제점에 대해 미리 감지하고 분석해 리포트를 추출하는 기능은 성능 관리 솔루션에서 문제점을 분석해 제공하는 기능만큼이나 중요한 하나의 포지션으로 자리잡고 있다.

i3 for Inform Alerts

i3 for Inform Alerts는 지속적이고 자동적인 모니터링을 통해 애플리케이션의 상황을 즉각적문제를 느끼기 이전에 발생 가능한 부분에 대해 조치 이력상황에 근거한 기준치 또는 설정된 기준치와할 때 미리 지정된 전자메일, 메시지, 경고음 등을 통해 알려주거나 i3의 다른 모듈들을 통해 성능문제에 대한 보다 많은 정보를 수집하는 등의 조치를 취하게 한다.

i3 for Inform Alerts는 모든 발생된 경고에 대한 이력을 저장함으로써 시스템의 성능에 대한 최신의 정보를 계속 관리한다. 또한 모니터링을 통해 성능 관련 문제점들이 실제로 시스템에 영향을 미치기 이전에 이를 인지하고 해결하게 해준다.

모니터링 솔루션을 제공하면서 느끼는 부분 중 하나는 지원하는 고객의 연령대에 따른 차이점이다. 나이가 많은 고객은 메인 프레임에서 경험한 모니터링 솔루션을 염두에 두고 검은 색 바탕화면에 하얀색 글자와 같은 대비가 뚜렷한 화면을 요구하지만 젊은 고객들은 파스텔 톤깝게도 Inform Alerts는 후자에 가깝다. 너무 정적이어서 고객들에게 미안한 감정이 들던 적도 몇 번 있다. 최근 SMS 솔루션이 보편화돼 운영되고 있는 만큼 필자는 두 솔루션을 연계해 제공하는 것을 강조한다. 그 이유는 SMS 솔루션이 제공하는 모니터링보다 훨씬 다양하고 풍부한 기능을 제공해 더욱 최적화된 성능을 유지할 수 있기 때문이다. 예를 들어 다음과 같은 항목은 오직 Inform Alerts에서만 가능한 기능으로 SMS와 연계할 경우 많은 도움이 된다.

앞의 항목 외에 약 40가지의 매트릭스를 제공해 모니터링이 가능하다.

<그림 4> i3 for Inform Alerts 기능을 통한 성능 문제 발견

i3 for Inform Foresight

i3 솔루션에서 제공되는 장기간의 데이터를 기반으로 다양한 보고서를 제공한다. 앞에서 언급했던 미사용 오브젝트에 대한 리포트 및 사용자 지정의 서비스 레벨에 따른 리포트 자동 생성, 과거의 기록된 데이터를 기반으로 시스템 용량 추이 분석, 기본으로 제공되는 리포트가 아닌 사용자가 직접 커스터마이징 해 생성하는 보고서 등 다양한 유형의 보고서를 그래프를 통해 PDF로 추출해 제공한다.

<그림 5> i3 for Inform Foresight를 통한 리포트

SLA와 i3 for Oracle

최근의 IT 환경은 기업의 비즈니스에 전례 없는 유연성을 제공하기도 하지만, 반면에 그 구조의 복잡성으로 인해 IT 담당자들이 애플리케이션 성능을 측정하거나 성능 문제가 발노력, 비용을 투입해야만 하는 문제점을 초래하고 있다.

최종 사용자들이 기대하는 수준의 서비스를 제공하기 위해 기업들은 갈수록 복잡해지고 대형화되는 정보 시스템의 모든 구성 요소를 고려해 성능 저하를 유발시키는 원인이 무엇인지 정확하게 파악해야 하며, 실제 웹 서비스에 영향을 미치기 이전에 성능 상의 문제 원인을 제거해야만 한다. 또한 이를 통해 전산 운영환경을 7×24 동안 최적의 상태로 유지관리해 사용자들에게 항상 양질의 서비스를 제공할 수 있어야 한다. 따라서 성능 관리 분야도 변화를 모색해야 하는 시점인 것이다.

최근 성능 관리 분야에서도 SLA(Service Level Agreement) 도입에 대한 논의가 활발히 제기되고 있으능 SLA란 일반적인 개념의 SLA와는 다소 차이가 있다. 성능 SLA는 정보 시스템의 응답 시간에 대한 서비스 목표 규약으로써 정보 시스템의 성능 수준을 약정한 수준으로 유지하겠다는 IT 조직과 현업 조직과의 협약이라고 볼 수 있다.

따라서 성능 SLA를 구축할 경우 기업 내 각 부서와 팀별 분석할 수 있어 정보 시스템 서비스 수준을 크게 향상시키는데 기여함과 동시에 향후 운영 계획에 대한 적합한 전략을 수립할 수 있게 된다. 또한 데이터베이스 서버, 애플리케이션 서버, 웹 서과 성능 개선이 어느 정도의 수준인지 등을 분석할 수 있다.

Baseline을 통한 지속적인 성능 관리

IT 관리자들은 i3를 이용, 퍼포먼스 웨어하우스(Performance Warehouse)에 축적된 데이터를 근간으로 이상적인 서비스를 제공한 특정 일자 혹은 특정 기간(주, 월)동안의 데이터를 기준으로 성능 베이스라인(Baseline)을 직접 설정할해 성능 추이를 분석할 수 있다.

또한 IT 구성 요소별로 설T 관리자들은 운영 시스템에서 제공하는 서비스가 원활하지 못한 시점의 성능 관련 데이터를 웹 서버, 애플리케이션 서버, 데이터베이스 서버, 네트워크 등으로 구분해 처리 소요 시간을 측정할 수 있다. 따라서 IT 담당자는 성능 상에 악영향을 끼치는 병목현상 요소들이 어느 부분에서 발생되는지 확인해 신속하게 대처할 수 있다.

SLA을 통한 사용자 중심의 서비스 수준 관리

i3는 IT 관리자가 각각의 구성 요소별(네트워크, 오라클, 웹, SAP, 턱시도, J2EE)로 소요되는 예상 처리 시간을 미리 정의한 후, 서비스 수준 관리가 가능하도록 3가지 상황(Normal, Alert, Critical)에 대해 SLA에 위배되는 사항들을 점검할 수 있게 해준다. 담당자가 미리 정의해 놓은 SLA에 위배되는 트랜잭션을 노란색과 붉은색으로 도식화해 보여줌으로써 직관적인 판단을 가능하게 하는 것이다.

서비스 수준 관리의 대상 항목 선정 기준은 기업들에 따라 다소 차이가 있을 수는 있으나, 안정적인 시스템의 운영과 사용자들에게 양질의 서비스를 항상 제공하겠다는 최종 목표는 동일하다. 중요한 것은 SLA의 임계치 설정시 기업 내의 운영 중인 시스템 환경과 애플리한 지표를 수립해야 한다는 점이다.

데이터베이스 SLA

전반적인 서비스 응답 속도에 가장 큰 영향을 미치는 구성 요소 가운데 하나가 오라클 인스턴스 최적화와 DB 애플리케이션의 처리 속도 개선이라고 할 수 있다. 오라클 인스턴스의 효율성을 검증하기 위해 i3 for Insight는 애플리케이션 처리에 소모되는 자원을 4가지로 분해해 측정한다. 드릴 다운 방식으로 수행된 프로그램 정보, 오라클 클라이언트, SQL 문장에 대한 상세한 정보를 통해 문제 원인을 쉽게 규명할 수 있다. 또한 i3와 연계해 문제를 야기시킨 SQL 문장은 어떤 것이며, 오라클 관점에서의 대기 시간이 얼마나 발생됐는지에 대한 정량적인 수치를 바탕으로 데이터베이스 애플리케이션 성능을 빠르고 쉽게 개선시킬 수 있다.

i3 기능을 제대로 파악하고 구매하길

지금까지 i3 for Oracle 제품이 어떤 기능을 제공하는지에 대해 살펴봤다. 앞서 언급된 기능만이 제품의 모든 기능을 나타내는 것은 아니지만 가장 유용하며 고객들이 선호하는 기능을 중심으로 정리했다.

현재 i3는 베리타스 볼륨 매니저파일시스템과 연동해 논리적인 정보만을 제공하는 것이 아닌 시스템 정보부터 폭넓고 심도있는 데이터까지 제공하고자 한다. 또한 글로벌한 제품으로 오라클 버전 업그레이드에 따른 지원이 여타 솔루션에 비해 빠른 편이기도 하다.

그러나 아직 i3가 가야할 길은 멀고 험하다. 현재 성능 관리 시장은 과도기를 넘어선 상태이다. 그에 따라 고객들의 요구사항 또한 다양하다. 그 다양한 요구사항 중 지원하는 엔지니어로써 안타깝게 느껴지는 항목을 정리하면 다음과 같다.

메뉴의 한글화 지원 및 커스터마이징의 불가능

가까운 나라인 중국과 일본은 해당 언어를 지원하는 솔루션을 사용하고 있지만, 아직 i3의 한글화 버전은 지원되고 있지 못하다. 이 사항이 때로는 제품의 버그로 발생되는 경우도 있다. 모든 외산 솔루션이 그렇듯 한글화 작업이 순탄치만은 않겠지만 한글화 지원을 통해 고객들에게 좀 더 친밀하게 다가설 수 있길 바란다. 또한 사용자들이 원하는 기능이 엔지니어로써도 굉장히 좋은 기능임에도 불구하고 외산 솔루션의 특징상 커스터마이징이 불가능한 경우가 많이 있다. 이 경우 차기 버전에 지원이 가능하도록 본사에 요청하는 경우가 있는데, 반영되기가 쉽지 않은 상황이다.

뉴스그룹 및 support 페이지의 활성화

현재 i3 제품군의 버그 및 버그 픽스에 대한 자세한 사항은 뉴스 그룹 및 다양한 support 페이지를 통해 지원되고 있다(http://support.veritas.com). 그러나 아직 사용자들이 접근해 활용하기에는 데이터가 부족하다. 다양한 케이스에 대한 지원 및 매뉴얼, 데이터 지원 등의 풍부한 자료를 지원하는 엔지니어만의 창구가 아닌 고객들의 의견을 손쉽게 주고받을 수 있는 커뮤니티로 활성화됐으면 하는 바람이다.

기획ㆍ진행 | 기묘 컨텐츠 제작팀(heyjude@gimyo.com)