서비스 관리

개요

이 장에서는 데이터베이스 관리자(DBA)가 만들어야 하는 서비스 수준 유지(SLA: Service Level Agreement)에 관해 간략히 소개한다. 서비스 수준 유지를 위한 협의 과정과 효과적인 서비스 수준 유지를 만들기 위해 반드시 포함되어야 하는 요소들에 관해서 다룰 것이다. 또한 이 장에서는 적절한 서비스 수준을 관리하기 위해 데이터베이스 관리자가 할 수 있는 좋은 방안들에 대해서도 기술할 것이다. 이 장에서 기술된 절차들을 수행한다면 데이터베이스관리자는 고객의 요구와 가용한 리소스에 적절한 서비스 수준 유지를 협의하여 만들 수 있으며 그렇게 만든 서비스 수준 유지에 부합하는 서비스를 제공할 수 있을 것이다

소개

지속가능하고 수준 높은 서비스를 제공한다는 것은 데이터베이스 관리자에게 있어서는 하나의 도전이다. 운영체제나 SQL 서버, 네트워크, 그리고 응용 프로그램들은 쉼 없이 업그레이드되고 있고 있으므로 시스템 오류 가능성은 어디에나 상존하고 있다. 그럼에도 불구하고 결함 없는 무중단 서비스에 대한 요구는 여전하다.

서비스 수준 유지(SLA: Service Level Agreement)는 이러한 서비스를 제공하기 위해 필수적이다. 서비스 수준 유지는 일정한 시스템 서비스 수준에 대한 고객의 요구를 명확히 하는 메커니즘일뿐만 아니라 이전까지는 그러한 수준의 서비스를 제공하도록 간섭 받았던 바로 그 프로세스를 데이터베이스 관리자가 직접 통제하고 향상시켜 나갈 수 있도록 하는 도구이기도 한 것이다. 서비스 수준 유지를 이용하여 DBA는 하드웨어나 소프트웨어의 추가나 인력 충원을 뒷받침할 수 있으며 고객의 요청이나 문제가 어떻게 처리되어야 하는지를 조절할 수도 있다.

이 장에서는 서비스 수준 유지에서 반드시 다루어야 하는 서비스 항목들에 대해 다룰 것이다. 요구사항과 제약사항에 대한 협의가 이루어질 수 있도록, 주어진 시스템 환경을 분석하는 과정에 대해서도 가이드할 것이다. 또한 필요한 수준에 부합하는 서비스를 제공할 수 있는 기술에 대해서도 자세히 알아볼 것이다.

디자인 고려사항

이 장에서 소개되는 서비스 수준 유지는 일정 기간에 걸쳐 서서히 운영환경이 향상되는 것을 목적으로 만들어졌으며, 이는 운영 방안의 개선에 좋은 도구가 될 것이다. 이러한 접근법은 다양한 산업 군에 존재하는 많은 데이터 센터에서 이루어진 성공을 기반으로 만들어 졌다.이러한 성공 사례에 공통된 아이디어는 바로 문제는 단지 조치되는 것이 아니라 반드시 해결되어야 한다는 것이다.

이러한 접근법이 치러야 하는 대가는 해당하는 서비스를 제공하기 위해 투입되는 인력의 수이다. 이 접근법은 DBA , 문제 추적 전문가, 중요한 버그 해결을 위한 개발요원, 버그를 테스트하기 위한 테스트 요원 그리고 고객 대변인 등이 필요하다. 만약 담당해야 할 응용 프로그램에 상기한 리소스를 제공할 수 없는 조직체에서 이 일하고 있다면, 앞으로 제시될 서비스 수준 유지 상황에 적절하지 않을지도 모른다.

서비스 수준 유지를 만드는데 있어 또 하나 중요하게 고려해야 할 사항은 여러 고객들에게 제시할 수 있는 일반적인 서비스 수준 유지 을 만들고 싶더라도, 반드시 부가 사항, 예외 조항, 특이 상황에 대한 기술을 빼놓아서는 안 된다는 것이다. 표준 서비스 수준 유지는 단지 기대 성능치의 베이스라인을 제시하는데 있어서 유용할뿐이므로 서비스 수준 유지를 만드는 협의 과정과 초안 작성의 초점은, 어떻게 하면 고객의 독특한 환경에 알맞은 서비스가 이루어질 것인가에 맞춰져야 한다. 예를 들어, 어떤 조직의 회계 부서는 월말, 분기별, 년말에 이루어져야 하는 요구사항이 있을 수도 있는 것이다. 게다가 아주 거대한 다국적 기업에서는 본사와 지사의 년말 정산이 다를 수도 있다는 점을 생각해보면 이해가 될 것이다.

필요한 리소스

이 장에서 소개하고 있는 서비스 수준 유지를 구현하기 위해 다음과 같은 소프트웨어가 필요하다.

또한 DBA의 역할 뿐만 아니라 다음과 같은 역할로도 인원을 충당해야 한다.

과정 흐름도

여기서 작성할 서비스 수준 유지는 장애처리요청에 대한 로깅, 대처, 문제 해결에 관한 프로세스를 정의해야 한다. 서비스 수준 유지는 또한 개발 과정과 장애 요청 처리 과정이 버그 추적 도구를 가지고 어떻게 상호 작용해야 하는지에 대해서도 규정해야 한다. 이 과정에 참여하는 모두 주체들이 복잡 다기한 프로세스를 이해해야 하며, 이해를 돕기 위해 흐름도를 서비스 수준 유지에 포함하는 것도 좋을 것이다. 다음 과정 흐름도는 장애처리요청의 접수부터 그 해결까지를 다루고 있다.(그림 8.1)

그림 8.1 장애처리지원 서비스 요청 관리 흐름도

서비스 수준 유지를 위한 협의과정

이 장에서는 서비스 수준 유지를 직접 만들어 내는 프로세스에 관하여 기술한다. 이 장에서 제공하는 정보는 서비스 수준 유지가 포함하는 일반적인 베이스라인의 설정 뿐만 아니라 각각의 고객들에 맞추어 제공해야 하는 특기사항 등에도 공히 적용된다. 이것은 고객의 요구사항과 서비스 사항을 명확히 하는 과정의 일환이다. 만들어야 하는 서비스 수준 유지가 일반적인 베이스라인을 위한 것이든 아니면 고객의 특수한 상황에 국한된 것이든, 그 차이는 규약의 범위나 참여 인력에만 있을 뿐 접근 방법은 동일하기 때문이다.

제공해야 할 서비스에 다수의 역할(role)이 포함되어 있다면 서비스 수준 유지를 협의하는 과정은 결코 쉬운 과정이 될 수 없다. 서비스 수준 유지를 만들다 보면 많은 운영직원을 지시할 용어들에 대해서도 협의하게 되는데, 실제로 이런 자리에 있는 사람들은 협의과정에서 다소 불편한 감정을 가질 수도 있다. 그 까닭에 협의과정에서는 그들의 근심과 걱정에 대해 좀더 귀를 기울여야 한다.

이와 같은 서비스 수준 유지를 둘러싼 막연한 두려움을 물리치기 위해서는 서비스 수준 유지에 영향을 받는 모든 주체들을 포함시키도록 하자. 서비스 수준 유지로 합당한 기대수준을 설정할 수 있다는 점을 모든 주체들에게 명확히 하고 그들의 참여를 독려하는 것이다. 그들이 이 과정에 참여해야만 그들이 기반으로 하여 수행할 수 있는 기대수준을 명확히 할 수 있음을 알려야 한다. 명확한 기대수준을 세운다는 것이 모든 사람들에게 얼마나 도움이 되는지를 강조하고 다시 강조하라. 협의 테이블에서 현재의 운영 과업들에 대해서 얘기를 꺼?? 각 그룹들의 대표를 뽑아야 할 것이다. 이 때 협의 과정의 의미에 대해 모든 그룹에 속한 사람들에게 소개할 기회가 주어질 것이다. 그 다음, 좀더 영향력 있는 그룹의 대표들과 서비스 수준 유지의 구체적인 사항을 논의하도록 하라. 다음과 같은 그룹에서는 반드시 대표가 선임되어야 한다.

서비스 수준 유지를 구성하는 각 이슈 사항들에 대해 각 그룹의 대표 뿐만 아니라 각 그룹 전체가 하나가 되어 참여할 필요가 있다. 어떤 이슈가 있는지는 다음 섹션에서 제시하기로 한다. 협의 주체들이 각 이슈를 검토하고 협의하도록 하기 위해 서비스 수준 유지의 각 이슈에 대한 아웃 라인을 협의 초기에 제기하면 좋다. 이 아웃라인이 특정 이슈를 해결할 수 있는 제안적 성격의 메시지를 담을 수도 있을 것이다. 그렇지만, 이미 준비해놓은 아이디어를 각 협상 주체들이 제시할 때 그것이 단지 제안에 불과하다는 점을 분명히 해 놓아야 한다. 다시 한번 말하지만 협상에 참여하는 모든 주체들은 이미 불편한 느낌을 가지고 테이블에 임하고 있으며 이 후 뻔하게 결정된 제안에 대해서는 동의하지 않을 수도 있다는 점을 잊지 말자.

서비스 수준 유지 구성요소

서비스 수준 유지는 다음과 같은 섹션을 포함하고 있어야 한다.

서비스 제공

서비스 수준 유지에 대한 협의가 끝나면 각 주체들은 문서에 기술된 각각의 임무를 준비한다. 운영 조직은 새로운 지원 체계를 구성하는 것이 필요하다.

서비스 수준 유지가 제공하는 지원체계의 두 가지 핵심은 장애처리요청과 버그 추적이다. 장애처리요청과 버그 추적은 바로 서비스 수준 유지에 부합하는 서비스를 조직이 제공할 수 있느냐 없느냐를 판가름하는 기준이다.

장애처리요청

잘 운영되고 있는 조직에서 문제가 발생하면, 그 문제는 고객이나 운영 스텝에 의해 보고된 다음 문제가 발생할 때마다 장애를 관리하는 시스템에 기록되고 추적된다. 문제가 최종 해결되면, 운영요원이 경험으로부터 배울 수 있도록 상기 시스템에 기록된다.

만약 여러분이 몸 담고 있는 조직이 장애처리시스템을 가지고 있지 않으면 고객이나 운영요원들이 문제를 처음 발견했을 때 보고할 수 있만약 고객 사이트에서 문제를 발견하고 말하지 않고 다른 경일어날지는 불 보듯 뻔하다. 조직에서 문제를 보고하는 것이 가능한 한 독려되어야 한다. 고객이 문제를 지적하는 것이 이득을 볼 수 있도록 시스템을 디자인한다면, 고객은 반드시 그렇게 할 것이다. 또한 운영상의 문제점을 빠른 시일 내에 지적하는 직원에게 보상이 가도록 하라. 이런 식으로 보상을 하지 않는다면, 장애처리시스템을 구현하는 것이 무의미하다.

장애를 보고하는데 있어 걸림돌을 제거하면 장애처리요청을 접수할 시스템을 구현하는데 착수한다. 전자메일 기반으로 예비적인 테스트를 수행해 볼 수 있다. 이 프로세스는 장애를 기술하는 전자메일이 적절한 요원에게 전달되는 것으로부터 시작한다. 해당 요원은 전자메일 체인에 적절한 정보를 기입하거나 다른 요원에게 메일을 전달할 수도 있다. 단일 그룹이 전자메일 체인을 책임지고 있다면 전자메일을 기반으로 한 장애처리시스템도 운영할 수 있을 것이다.

3rd 파티에서 제공하는 패키지를 구입하는 것도 권고할 만한 사항이다. 이런 종류의 시스템은 장애처리요청 할당과 장애처리 요청이 종료될 때까지 표준화된 절차, 그리고 요청 상태 보고를 가능하게 한다. 이런 3rd 파티 시스템은 대규모 운영이 이루어지는 조직체에서 필요하다.

버그 추적

응용 프로그램이 계속적으로 향상되기 위한 가장 좋은 원천은 버그를 끊임 없이 추적하고 퇴치하는 방법 뿐이다. (그런 툴을 도입하지 않았다면) 버그 추적 소프트웨어를 도입함으로써 조직은 반드시 주요 프로세스에 친숙해져야 한다. 버그 추적 소프트웨어를 이용하면 응용 프로그램 문제를 운영과정에서 발생할 수 있는 문제와 분리하여 관리할 수 있게 된다. 조직에서 하루에 수 많은 장애처리요청이 있다 할지라도 응용 프로그램의 버그는 단지 한두 개에 불과하다. 별도의 버그 추적 시스템은 개발그룹이 운영상의 이슈에 휘말리지 않도록 해준다.

버그 추적 시스템은 전자메일을 기반으로 해서 구현할 수 없다. 전자메일을 가지고 정보를 주고 받기에는 버그와 관련된 내용은 너무나 중요하다. 만일 이러한 정보가 중간에 유실되기라도 한다면, 버그를 퇴치하기 위해 투입된 개발자는 문제를 재현하기 위해 수시간에 걸쳐 별도의 테스트를 수행해야 할지도 모른다. 더군다나, 버그 추적 시스템은 수많은 배포 패키지와 개발팀에서 시스템 개발 중에 만들어 내는 버그를 모니터링 해야 한다. 그런데, 개발자가 프로젝트에서 손을 떼기라도 한다면, 오로지 해당 개발자만 알고 있던 버그 배경과 해결책은 돈을 주고도 살 수 없게 된다.

서비스 수준

고객이 어떤 요청을 하던 간에 제공할 수 있는 서비스 형태는 다음 두 가지 밖에 없다: 모니터링과 대응조치. 응용 프로그램의 성능을 향상시키거나 성능 향상을 마치 독립적인 서비스로 제공하고 싶을지도 모르지만, 응용 프로그램의 성능에만 초점을 맞추는 것은 별로 도움이 되지 않는다. 꾸준히 응용 프로그램 성능을 모니터링 해왔고 어떤 부분의 성능이 개선되어야 하는지를 정확하게 알지 못하면 말이다. 충분한 모니터링이 이루어져 어디를 개선해야 하는지를 알게 되었다면 성능 향상을 위한 작업은 낮은 성능에 대한 대응조치로서 간주될 수 있다. 따라서 응용 프로그램 튜닝 역시 이러한 관점에서 모니터링과 대응조치의 프로세스 중의 하나로 볼 수 있는 것이다.

서비스 수준은 관찰해야 하는 시스템 상태(모니터링)와 어떤 상황이 발생하였을 때 취해야 하는 행위(대응조치)에 대해 자세히 기술한다. 모니터링과 대응조치가 모두 준수해야 할 타임프레임도 제공해야 한다. 서비스 수준은 일정 타임프레임 안에 취해야 하는 운영상의 특정 상태의 대응조치라고 간단히 정의할 수 있다.

운영상의 상태

서비스 수준 유지가 기술해야 하는 서비스 수준을 제한하기 위해, 다음과 같은 상태 혹은 상황에서만 대응조치가 이루어지도록 제안한다.

마지막 세 개의 운영 상태에 대해서는 여러 가지 가능한 대응조치를 취할 수 있다. 단순 데이터베이스 응용 프로그램보다 복잡한 시스템을 지원한다면, 부정적 지표를 포함하는 운영 상태를 각 응용 프로그램 구성요소의 지표로 풀어서 보도록 권고한다. 다소 복잡한 응용 프로그램에서, 상기한 마지막 세 개의 운영 상태는 다음과 같은 세부 지표로 풀어서 볼 수 있다.

복수 부정적 지표

단일 부정적 지표

부정적 지표 없음

타임프레임

서비스 수준 유지에 있어 타임프레임 역시 중요한 요인으로 포함시켜야 한다. 데이터 센터에 요원들이 하루24*7일 동안 대기하고 있지 않는다면, 지원 가능한 타임프레임은 쉽게 정의할 수 있다. 운영과정에 대한 대응조치와 관련된 타임프레임은 다음과 같다.

대응조치

서비스 수준에서 가장 복잡한 요소는 각 수준마다 정의해야 하는 대응조치들이 다르다는 것이다. 각 대응조치들은 응용 프로그램과 운영환경에 맞도록 디자인 되어야 한다. 서비스 수준 유지 협의 과정에 참여하는 모든 주체들은 운영 상의 여러 상태에 대한 적절한 대응조치가 어떤 것이어야 하는지 결정하는데 다 함께 동참해야 한다. 이에 대한 자세한 기술은 이 장의 범위를 벗어나는 것이므로 여기서 제외하였다.

그러나 대응조치를 정의하는 프로세스에 대한 가이드라인은 제시할 수 있다. 먼저, 현재 고객이 요구하지 않는다고 해서 적절하다고 생각하는 대응조치를 버리지 말라는 것이다. 적절하다고 생각했던 조치가 서비스 수준에 포함되지 않았다면, 그 조치들은 서비스 수준 유지에 '추가적인 조치 사항' 혹은 '비상시 조치 사항'으로 반드시 포함되어야 한다. 목표는 어느 시점에서 필요할지는 모르지만 가능한 모든 대응조치를 정의하는 것이다.

가능한 많은 대응조치들과 각각의 지원 체계를 정의함으로써, 서로 다른 타입의 대응조치로 전환이 쉬워지고 고객의 요구에 더욱 유연하게 대처할 수 있다. 이것은 고객 대표가 흔히 서비스 수준 유지에 따라 서비스를 수행하기 전에 잘못된 상황 판단을 할 수 있기 때문에 매우 중요하다. 지원 체계가 막 꾸려지고, 서비스 수준 유지에 관한 결재 도장의 인주가 마르기도 전에, 고객 대표는 서비?력을 행사할지도 모른다. 서비스 착수 시에 추가적인 대응조치 사항이 있다면 고객 대표와 함께 논의할 수 있는 근거를 마련해야 한다.

또 하나 고려할 사항은 운영 상태에 대한 대응조치에 참여하는 담당자들의 역할을 정의하는 것이다. 문제 해결 과정에 모든 주체가 개입할 수 있도록 대응조치를 정의하는 것은 정말 좋은 생각이다. 이렇게 하면, 문제 해결 과정이 진행될수록 도움이 되는 많은 리소스가 소개될 것이다. 다음 예는 문제양상에 개입할 수 있는 역할 및 개입하는 순서에 관한 것이다.

서비스 수준의 관리

다음 내용은 SQL서버에서 문제가 일어나지 않도록 만들기 위한 지침이다.

요약

서비스 수준 유지의 목적은 대응 조치할 수 있는 지원조직의 수립이다. 이러한 지원조직 구성원은 서비스 수준 유지에서 제기되는 서비스 수준에 부합하도록 노력하며, 정의된 지원체계가 개입 가능하도록 하는 도구들을 제공한다.

서비스 수준 유지는 지원하는 인프라가 성숙해가는 정도에 따라 변경 가능한 살아 있는 문서여야 한다. 모든 주체는 서비스 수준 유지의 협의 과정을 받아들여야 하며 협의 결과에 기꺼이 승복해야 한다. 명확한 기대사항들과 표준화된 대응조치가 주는 혜택을 모든 주체들을 만들려면 상당한 노력이 필요하다. 모든 주체를 참여시키고 복잡한 이슈를 함께 다루어야 하고 또한 그들의 근심도 풀어 주어야 하는 것이다. 이러한 노력은 가치 있는 결과를 가져다 준다는 것을 잊지 말자.