DBMS 1

DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!

데이타헤븐 Intuvision 구축사례

DBMS 1
Oracle 가이드
솔루션 백서 가이드
데이타헤븐 Intuvision 구축사례
작성자
dataonair
작성일
2021-02-17 16:40
조회
784

데이타헤븐 IntuVision 구축사례

DataHeaven IntuVision for Oracle, 삼성의료원·LG생활건강 활용사례

“사전 장애 요건 분석으로 DB 관리 업무 경량화”

이승훈│DBCORE 기술지원 팀장

데이터베이스와 애플리케이션 시스템 간의 연계가 점차 긴밀해지고 있다. DBA들은 이전보다 더 많은 원인을 알 수 없는 장애에 시달리며, 새로운 솔루션 구축 시에도 기존 애플리케이션 시스템과의 연계가 중요한 고민 대상이 되고 있다. 365일 무중단 의료 서비스를 지향하는 마산의 삼성의료원과 대고객 서비스 중심의 LG생활건강 사례를 통해 데이타헤븐 IntuVision이 제공하는 맞춤형 서비스와 기존 시스템과의 결합, 장애 요건 분석을 통한 사전 대응 방안 마련 방법론을 설명하고자 한다.

기업들이 오라클 DBMS 기반의 정보시스템 구축 프로젝트를 수행하면서 가장 고민하는 부분 중 하나가 “어떻게 하면 기존 인프라를 효율적으로 활용하면서 새로운 요구 조건을 반영할 수 있을까”라는 것이다. 이는 기업의 프로젝트 추진 목적을 잘 반영하고 수년간 가동 중인 기존 업무 시스템과 원활히 결합될 수 있는 솔루션을 선정하는 과정으로 귀결된다.

이때 관리자가 간과하지 말아야 할 부분은 현장의 실무자들로부터 아이디어와 검증을 받는 과정이다. 흔히 프로젝트시 현업의 요구 조사를 진행하지만, 조사에만 그치는 경우가 대부분이다. 업무를 수행할 최종 사용자의 요구가 잘 반영되는 솔루션을 기반으로 시스템을 구현한다면, 사용자의 생산성은 당연히 증가될 것이며 최종적으론 성공적인 프로젝트를 진행하는 원동력이 될 수 있을 것이다.

시스템 관리를 위한 시스템 진단 및 감시 기능의 구현도 마찬가지다. 값 비싼 전문 툴, OS의 단순한 명령어인 vmstat, 오라클의 Dictionary 조회 등 구현할 수 있는 방법은 다양하지만, OS 자원 이력과 DB 모니터링 및 성능분석 방법 등 필수 요소를 포함한 통합된 툴을 선정하긴 쉽지 않다.

특히 다양한 기업정보를 중단 없이 서비스하고 다량의 관련 시스템을 모두 담당하는 시스템 관리자 입장에서 시스템 별로, 서비스 유형에 따라, 핵심 관리항목과 성능을 좌우하는 지표가 다르다면 많은 고민을 하게 될 것이다. 따라서 각종 관리 항목을 툴을 사용해 실시간으로 취합, 원하는 내용 위주로 시스템 관리자나 기타 관련자가 볼 수 있도록 서비스 받을 수 있어야 한다.

삼성의료원 ‘OPS 기반의 무중단 의료 서비스’

이러한 상황에 현명하게 대응할 수 있는 방법과 시스템 운영에 대한 개선 방법 등을 IntuVision을 통해 해결했던 삼성의료원과 LG생활건강의 사례를 통해 데이터베이스 시스템의 모니터링 및 성능분석 솔루션의 중요성을 살펴보도록 하자.

환자들의 진료 이력 정보를 365일 중단 없이 서비스하는 것을 목표로 하는 삼성의료원은 OCS(처방전달시스템 ; Order Communication System)와 MIS(경영정보시스템), PACS(의료영상저장전송시스템; Picture Archiving Communication System) 등 주요 시스템을 오라클 OPS(Oracle Parallel Services) 기반 하에 구축, 지난 3년간 중단 없이 운영을 해 왔다. 이 시스템은 클라이언트/서버(4GL : 델파이와 비주얼 베이직 툴 기반) 환경에 미들웨어인 턱시도(Tuxedo)를 기반으로 운영되고 있다.

그러나 최근 원인을 알 수 없는 장애와 성능 저하 문제를 겪게 되면서 운영 환경의 개선을 위해 시스템 진단과 분석을 위한 전문 툴을 도입하기로 결정했다.

당시 삼성의료원의 시스템 운영 상황은 다음과 같은 특성이 있었다.

  • OPS 시스템 관리 인력의 교체에 따른 OPS 관련 이벤트 분석 능력 약화
  • 오라클 서버의 업그레이드 어려움
  • 지속적인 서비스 추가에 따른 OS 자원 고갈 현상
  • OPS 기반의 주요 시스템과 부속 시스템 간의 상이한 관리 요소
  • 다량의 이기종 시스템을 관리하기엔 부족한 관리 인력 보유
  • 테스트 환경 없이 OLTP 성 애플리케이션이 실시간 변경, 추가되는 운영 환경
  • 다량의 애플리케이션 구축에 따른 소스 및 성능 이력관리 어려움

삼성의료원 오라클 시스템 구조 <그림1> 삼성의료원 오라클 시스템 구조

이에 따라 삼성의료원이 요구한 솔루션의 기능 조건은 다음과 같다.

  • OPS 환경에서의 강력한 감시 기능과 OS 정보와 DB 정보 간의 연계
  • 오라클 DB 로그와 OS 로그에 대한 실시간 DB 변경 이력을 함께 볼 수 있는 구조
  • Bad-SQL를 필터링해 개발자나 애플리케이션 관리자에게 실시간 전송할 수 있는 기능
  • 중장기 트렌드 분석을 통한 애플리케이션과 SQL의 시간대에 따른 성능 분석과 서비스의 사용 빈도 예측
  • 로깅을 위한 어떠한 정보도 서버에 저장하지 않는다(I/O의 최종 액션을 DB나 OS 같은 운영 환경에 저장하는 것을 원하지 않았다)

기능도, SQL 쿼리도, 화면도 “맞춤형으로 OK"

삼성의료원은 IntuVision 도입 후 가장 인상적인 점에 대해 사용 용이성과 친밀감을 꼽는다. 삼성의료원은 IntuVision 설치 후 즉각 시뮬레이션 교육과 Help 기능을 이용, 자체 교육을 실시했으며, 이 과정을 통해 사용법은 물론 오라클 기술 팁과 대표적인 오라클 이벤트 등을 숙지할 수 있었다. 또한 IntuVision의 Customized Function을 이용해 UI 화면까지 현장의 관리자 기호에 맞게 변경했으며, 자주 이용하던 DB 정보 SQL 쿼리를 IntuVision의 MyMonitor 기능을 이용해 모듈화 했다. IntuVision의 이같은 특징 및 기능들은 사용자들의 제품 활용도와 친밀감을 높이는데 중요한 역할을 한다.

고객이 만든 다양한 IntuVision의 UI 화면 <그림2> 고객이 만든 다양한 IntuVision의 UI 화면

배치 잡 속도 저하 원인을 찾아라!

삼성의료원에서 발생한 이벤트와 이를 IntuVision을 통해 해결한 사례들을 살펴보겠다.

IntuVision을 통한 로깅(Logging)과 실시간 감시 및 분석활동을 시작한지 얼마 지나지 않은 시점에 전반적으로 애플리케이션이 느려지는 상황이 발생했다. 오라클 배치 잡(Batch Job) 수행이 끝날 시점이 훨씬 지났는데도, 작업이 계속돼 다음 잡을 수행할 수가 없었던 것이다. 이에 DB 관리자는 매뉴얼을 활용, 오라클 Alert.log와 애플리케이션 로그, OS 등 행 처리시 DeadLock 발생 가능성 측면을 조사했다. 그러나 특별한 이상을 찾을 수가 없었다.

그러던 중 IntuVision 모니터링 화면 내의 'Transaction' 메뉴에서 잔여시간이 30M으로 표시된 것으로 보고서야, 문제점을 발견할 수 있었다. 누군가 롤백(Rollback) 작업을 시행, 오라클 리소스를 사용하고 있기 때문에 전반적인 성능이 떨어졌던 것이다. 이에 롤백 작업이 끝나는 30분 뒤에 배치 잡을 수행하는 것으로 모든 DB 운영 스케줄링을 수정하고 로그 애널라이저(LogAnalyzer)를 통해 어떤 프로그램에서 수행된 SQL인지를 검색, 동일한 문제의 재발 방지를 위한 프로세스를 구축했다.

메모리 부족 현상, SGA 통계치 분석으로 해결

특정 애플리케이션과 오라클 Alert log에서 ORA-4031이 발생하는 문제가 생긴 적도 있다. ORA-4031이란 쉐어드 풀(shared pool)이라는 오라클 SGA 영역의 조각화로, 애플리케이션이 요구하는 일정 크기의 연속된 메모리 영역을 확보할 수 없을 때 발생되며 통상적으론 애플리케이션이 Static SQL이 아닌 Literal SQL을 사용하는 데서 오는 영향이 크다. 삼성의료원의 경우도 데이터 입력시 Literal SQL을 주로 사용함에 따라 DB(SGA)의 메모리 부족현상이 발생, 장애로 이어진 것이다.

삼성의료원은 IntuVision의 알람 기능을 통해 임계치를 설정, 실시간 장애전조를 감지하고 로그 애널라이저를 이용해 SGA 통계치 정보 중 쉐어드 풀과 라이브러리 캐시 래치 손실률(library cache latch miss ratio)을 장시간 분석해 가장 영향이 많은 프로그램과 모듈, SQL 패턴 분석을 수행했다. 이 결과에 따라 개선 대상 SQL을 선정, 현재 사용중인 프로그램에서 Literal SQL로 인한 SGA 영역의 부족 현상이 감지될 경우 메모리 영역을 확보하기 위한 쉐어드 풀 플러쉬를 시행하도록 했으며, IntuVision의 로그 애널라이저 기능과 리포팅 기능을 이용해 애플리케이션의 변경에 따른 SGA 변동 상황을 상호 비교함으로써 문제를 해결했다.

SGA/Cache 정보 <그림3> SGA/Cache 정보

무중단 시스템 운영시의 중요 이벤트 수집

365일 무중단을 목적으로 하는 삼성의료원은 유지보수를 위한 작업 시에도 최소한의 다운타임 만을 인정한다. 의료원의 신용과 진료 업무에 막대한 손해가 예상되기 때문에 패키지 변경과 OS나 DB의 업그레이드, 기타 커널 업데이트 시에 통상적으로 수행하는 백업 후 시스템다운, 커널 변경, 애플리케이션 테스트, 정상 운영 등의 방법을 선택하지 않는다.

따라서 무중단 시스템 운영 및 솔루션의 감시는 삼성의료원 같은 OPS/RAC 환경 하에선 시스템 관리의 핵심이다. 삼성의료원은 오라클 서버의 무중단 솔루션으로 선택한 OPS의 관리시 주의해야 할 내용에 대한 매뉴얼 작성과 DB SQL 쿼리를 통한 이벤트를 수집 중이었으며, IntuVision으로 다음의 내용을 집중적으로 분석, 관리할 수 있게 됐다.

  • Datafile Lock Conversions :동일 오브젝트를 액세스하는 업무를 각기 다른 노드에서 운영하지 않도록 한다. RAC와 달리 OPS에서는 동시에 빈번히 액세스되는 오브젝트는 같은 노드에서 접근하게 한다. 이러한 현상은 다음의 전조를 함께 확인해야 한다.
  • Lock Activity(분당 5000회 미만) :PCM Lock의 Downgrade는 Lock Conversion이라는 오버헤드와 함께 불필요한 데이터 블록을 디스크에 저장하는 디스크 경합을 발생시킨다. 이러한 현상을 ‘Pinging'이라 하며 OPS 시스템의 성능을 저하시키는 주요인이 될 수 있다.
  • Ping Rate(≤1) :PCM Lock의 Downgrade가 있을 때마다 데이터 블록이 버퍼 캐시에서 디스크로 사용된 비율을 보여주며 잘못된 Pinging을 가늠하는 척도로 사용된다. 이 현상이 빈번해지면 시스템 전체 성능이 저하되는 요인이 될 수 있다. 따라서 이러한 Pinging 현상이 발생하지 않도록 업무의 친밀성을 높일 필요가 있으며 업무를 분리할 수 없다면 GC_FILES_TO_LOCKS를 통해 해당 오브젝트가 속한 데이터 파일에 상대적으로 많은 PCM Lock을 할당해 PCM Lock Granularity를 극대화 할 수 있도록 한다.
  • Ping Write Ratio(Target<30%) :한 노드에서 디스크에 사용되는 블록이 Pinging 현상에 의해 쓰이는 비율을 보여준다. GC_FILES_TO_LOCKS를 조정함으로써 조정이 가능하다.
  • Remote Undo Request :한 노드에서 변경되는 데이터 블록을 정리(Commit)하지 않은 상태에서 다른 노드에서 단순 쿼리를 할 때 발생하는 상황으로 Consistent Read를 가능케 하기 위해 롤백 데이터 블록을 디스크에 기록해야 하므로 데이터베이스의 성능저하를 발생시키는 요인이 된다. IntuVision을 통해 과거 번거롭게 노드를 오가며 OPS 간 이벤트를 분석하던 행위를 실시간 OPS/RAC 메뉴의 독립된 화면으로 분석, 조치를 취할 수 있다.

OPS/RAC 화면 <그림4> OPS/RAC 화면

Plan-SQL 통한 성능 극대화 방안 마련

SQL은 RDBMS인 오라클 서버의 성능에 많은 영향을 미친다. 수많은 업체가 SQL을 최적화 하는 방안을 마련 중에 있으며, 애플리케이션 개발자의 SQL 기술을 극대화 하고, SQL이 오라클 서버가 최고의 성능을 발휘할 수 있도록 적절히 사용되기를 원하고 있다.

삼성의료원도 예외는 아니어서 담당 DBA는 먼저 자신이 관리하는 오라클 시스템이 SQL을 잘 사용하고 있는지, SQL의 성능진단을 수행하거나 손쉽게 개선 대상 SQL를 선별하는 방법을 찾고 있었다. 이 부분이 IntuVision 도입시 삼성의료원이 가장 주목했던 부분이었다.

의료원 DBA 입장에서 IntuVision을 사용하며 평상시 가장 많이 사용하는 기능 중 SQL과 Plan-SQL 기능을 통해 업무에 효과를 보았다는 의견을 피력했다.

생산 시스템의 SQL 중 응답시간이 4초가 넘어가면 의료 업무에 영향을 주는 서비스가 몇 개 있었는데, 얼마나 영향을 주는지, 왜 평상시에는 1~2초가 걸리는 SQL이 4초 걸리는지 등의 원인을 찾을 수 있었던 것이다. Active SQL로 임계치를 3초로 설정, 3초 이상을 DB에서 수행한 SQL을 찾아서 Plan-SQL을 이용, 분석해 보니 Where 조건의 데이터 건수가 변수로 확인됐다. 즉 문제가 없을 때는 100건 이내로 Join 조건이 걸리는 경우이고, 4초 이상이 걸릴 때는 1000건 이상의 Join 조건이 걸리게 되는 현상을 확인, Join 대상 오브젝트를 파티셔닝 해 최대 100건 이내로 Join 조건을 유지함으로써 문제를 해결한 것이다. 이외에도 평상을 통해 튜닝 후 Active SQL로 개선시켜 순간적으로 오라클 서버 리소스가 과도하게 사용됨으로써 운영시 긴장 요소가 됐던 부분도 개선했다.

SQL 모듈 화면 <그림5> SQL 모듈 화면

삼성의료원은 IntuVision을 도입함으로써 장애 후 대처 방식에서 사전에 장애 가능한 요소를 예측, 대응 방법을 미리 마련함으로써 실제 장애시 확신을 가지고 대응할 수 있게 됐다.

LG생활건강, DBA 업무 최소화 ‘효과 만점’

이제 PW(Performance Warehouse) 성격을 가진 로그 애널라이저를 이용, 중장기 애플리케이션 트렌드 분석과 성능 개선, 효율적인 용량 산정을 통해 합리적인 전산비용 투자 효과를 본 LG생활건강의 사례를 살펴보자. LG생활건강은 IntuVision 도입 이후, 과중한 DBA의 업무를 최소한으로 경량화 할 수 있었다.

LG생활건강은 인터넷 홈페이지를 이용한 대외 서비스를 목적으로, 지난 2000년에 오라클 데이터베이스 시스템을 구축했다. 처음 시스템을 오픈하고 운영할 때는 1대의 오라클 서버에 4개의 서비스 항목만을 개발했지만, 현재 메인 서버 1대와 보조 서버 2대로 구성된 오라클 서버를 활용, 36개 이상의 서비스를 오픈, 관리하고 있다.

최근 인터넷 서비스 관련 정보 시스템의 확대 적용과 상품 및 고객정보를 이용한 각종 업무가 증가함에 따라 애플리케이션 성능 장애 발생 빈도가 늘었으며 데이터의 증가, 추가 서비스 요청에 의한 CPU/메모리의 증가로 시스템 용량 문제도 대두됐다.

관리자들은 정밀한 성능분석을 할 여유도 없이 성능장애에 대응하기조차 바쁜 상황이었다. 담당 DBA는 당면 문제들을 해결하기 위해 고비용을 들여 수차례의 성능 진단을 받았지만, 몇 달 후 다시 똑같은 문제가 재발됨에 따라 반신반의로 선택한 방법이 IntuVision이었다.

장애 이력 분석 및 개선 항목 마련

LG생활건강은 도입 배경에 맞게 IntuVision의 MyMonitor로 각 업무별 장애이력을 분석, 적절한 항목을 만들어 대응할 수 있게 했다. 예를 들면 고객들의 구매성향을 서비스하는 애플리케이션이 트리거(Trigger)와 업데이트 스냅샷(Update Snapshot)을 이용하는데, 스냅샷 로그의 상황을 실시간으로 감시하는 프로세스를 UI로 디자인해 IntuVision을 모듈화 한 것이다.

Mymonitor로 자주 쓰는 SQL을 모듈화 한 화면 <그림6> Mymonitor로 자주 쓰는 SQL을 모듈화 한 화면

Row 마이그레이션으로 I/O 량을 줄여라

중장기 트렌드 분석을 실시한 결과 인터넷 사용자의 사용 실적을 저장, 관리하는 프로세스가 2초, 4초, 8초로 반복되는 응답시간을 보이고 있음을 확인하게 됐다. 오브젝트와 DB 디자인을 보니 동일 블록을 업데이트하고 있었으며 이로 인해 오라클 서버의 블록 경합이 발생, 응답 시간이 느려지고 빨라지고를 반복하고 있었던 것이다. 이는 Row 업데이트에 의해 row size가 증가되었을 때, 원래의 블록에서 업데이트 된 row를 저장할 공간이 없는 경우 발생할 수 있다.

이를 해소하기 위해 오브젝트의 블록 정보 중 업데이트 공간(Pctfree)을 극대화 하는 솔루션을 IntuVision으로부터 제시 받았으며, IntuVision의 가이드 안을 수용함으로써 응답시간의 반복 문제를 해결하고, I/O 량도 줄어들었다. 이는 Row 마이그레이션을 개선한 효과로, 오라클 서버의 특성상 해당 row의 rowid 정보만 원래의 블록에 저장하고, 실제 row 데이터는 새로운 free block에 저장하는데 따른 것이다. 인덱스를 통해 해당 row를 액세스하게 되면 rowid를 통해 원래의 블록을 액세스한 후, 실제 row 데이터가 저장된 블록도 액세스하게 되어 I/O가 증가하게 되는 현상은 자연스러운 것으로, 개선 이후 I/O 량이 줄게 된 원인으로 확인됐다.

로그애널라이저의 애플리케이션 응답시간 분석 화면 <그림7> 로그애널라이저의 애플리케이션 응답시간 분석 화면

데이터 발생 빈도/량 추측으로 대응 보고서 완성

사한 방법을 통해 애플리케이션 별로 온라인, 배치 그리고 배치성 온라인의 응답 시간을 근거로 재구성해 시간대 별, 날짜 별로 응답시간을 조사, 실사용자의 서비스 별 사용유형을 파악했다. 그 결과 데이터의 발생빈도 및 량을 추측하는 수준에서 벗어나 정확히 예측해 대응할 수 있게 됐으며 이를 근거로 한 보고서를 IntuVision의 로그애널라이저를 통해 활용하고 있다.

주로 관리하는 항목들은 다음과 같다.

  • SQL Layer의 오라클 이벤트가 시간대 별로 달라지는 이유
  • 오라클 인스턴스의 성능이력인 SGA의 통계치 정보
  • 실 사용자가 느끼는 응답시간과 함께 설명할 수 있는 기반 마련
  • 용량 산정시 정확한 예측 환경에 필요한 참조 데이터를 생성, 디스크 증설이나 CPU 증설 등의 투자나 시스템 변경 시점 관리

로그애널라이저의 성능분석 화면 <그림8> 로그애널라이저의 성능분석 화면

LG생활건강의 IntuVision 도입은 사용자가 느끼는 성능 이력을 시스템 자원 사용 내역과 결부시킴으로써 사용자가 먼저 투자의 필요성을 요구하는 환경으로 바꿔 버린 계기가 됐다는 점에서 의미가 있다. 그동안 명분만 있고 실속이 없다는 모니터링 및 성능분석 툴에 대한 이미지 불식과 DBA 같은 시스템 운영자의 입지를 한층 높이는 중요한 역할을 담당한 것이다. 무엇보다 고무적인 것은 이 모든 일을 IntuVision 개발자나 엔지니어가 아닌 담당자가 직접 디자인 하고 리포팅 할 수 있었다는 사실이다.

장애 후 대응 벗어나 사전 대응책을 마련하자

이상 2가지 사례를 살펴봤다. 삼성의료원의 사례를 통해 과도한 트랜잭션에 대한 오라클 구버전 사용자의 대처 방안과 오라클 OPS/RAC같은 특별 옵션을 사용할 때의 문제점과 대응책 등을 알아봤으며 LG생활건강의 사례를 통해 서비스 응답 시간 분석이나 SQL의 성능이력을 근거로 사전에 애플리케이션 개선 항목 등을 도출, 대응책을 미연에 마련하는 이유를 따져봤다.

이처럼 다양한 문제분석 및 해결, 대응이 가능한 요인은 IntuVision이 오라클 서버 감시 및 장애 분석과 튜닝을 위한 PW(Performance Warehouse) 운영시 다양한 주변 영향에 대응할 수 있는 구조로 이루어져 있기 때문이다.

다양한 애플리케이션을 이용해 빠르게 변화하는 기술 트렌드에 발맞추면서, 구 버전에서도 동일한 화면과 동일한 데이터를 볼 수 있는 고객 맞춤서비스를 원하는 요구는 비단 삼성의료원이나 LG생활건강 만의 요구는 아닐 것이다. 이러한 요구에 적극적으로 대응해 DB 모의 상호 관련 정보의 중장기 영향분석 시에도 독창적인 독립 구조로 산출물을 전달할 수 있는 IntuVision의 특징은 오랜 기간 오라클 서버의 특성을 반영한 기술지원을 수행한 경험과 무관하지 않을 것이다.