[펌]인프라 구성정보 데이터베이스 구축 사례

인프라 구성정보 관리의 어려움

모든 IT 인프라 관리자들이 많이 고민하는 주제 중 하나가 자산관리입니다. 조직이 크든 작든, 업태가 대규모의 IT 인프라를 요구하는 첨단산업이든 그렇지 않은 전통 산업이든, 그 어디서든 간에 자산관리는 어려운 숙제입니다.

모바일/플랫폼 비즈니스 사업자의 경우는 대개 많은 수의 서버를 보유하고 있고(국내 선두사업자는 몇 천 대에서 몇 만 대, 해외 선두 사업자는 몇 십만 대 이상), 서버를 전문적으로 관리하기 위한 전담인력과 정보시스템도 구축되어 있습니다. 나름 전문적인 체계지만, 막상 들여다보면 관리 수준은 의외로 낮은 경우가 많습니다.

현장의 어려움을 말하자면 일단 서버가 너무 많습니다. 몇 천대나 되는 서버가 여러 곳의 IDC에서 별도로 운영되는데, 날마다 몇 십 대나 몇 백 대의 서버가 생겨나고 이전하고 폐기되며, 이걸 관리하는 몇 개의 조직은 저마다 관리하고 있는 대장에 정보를 제각기 업데이트 합니다. 물론 안 하는 경우도 있습니다.

이런 어려움은 자산관리자에게 국한된 것이 아닙니다. 운영자는 더 어렵습니다. 수천 대의 서버에 대해 하드웨어 스펙, IP, OS 버전, 설치된 소프트웨어 등 여러 정보를 관리해야 합니다. 운영자의 관리 항목은 자산관리자보다 훨씬 많은 한편, 몇 가지 정보는 아주 정확해야 합니다. 인프라에 대한 다양한 작업 및 변경 요청을 원활하게 대응하려면 말이죠. 하지만 운영자가 관리하는 이 스프레드시트는 틀리기 쉬운 정보로 되어 있습니다.

정보시스템의 활용도 대체로 제한적입니다. 시스템은 엑셀을 잠시 담아두는 그릇 정도로 활용되는 경우가 대다수로, 담당자 별로 스프레드 시트를 따로 한 벌씩 가지고 있습니다. 필요할 때마다 시스템에서 스프레드시트를 다운로드 받아 작업하고 일정 주기로 업로드 하는 식인데, 그러다가 데이터가 한 번 꼬이기 시작하면 걷잡을 수가 없습니다.

 인프라 정보 관리를 위한 오랜 고민과 문제해결을 위한 접근

지금 말씀 드린 이런 고민은 1-2년 된 것이 아닙니다. 기업에 전산실이라는 조직이 생긴 이래 계속된 고민입니다. 이론적으로 또는 실무적으로 이 문제의 해결을 위한 여러 가지의 접근이 있었는데, 그 중 가장 대표적인 것이  ITIL (IT Infrastructure Library)입니다. ITIL은 IT 인프라의 변경을 관리하면서 서비스 품질을 높이기 위한 종합 체계입니다. IT 자산관리(ITAM: IT Asset Management) 라는 용어도 있는데, 장비의 모델명, 물리적 위치, 구매 계약 등과 관련된 정보를 관리하는 체계를 지칭합니다. ITSM (IT Service Management) 이라는 용어는 운영자 입장에서 관리 정보의 내용을 변경시키도록 하는 동기가 되는 작업요청, 변경요청에 대한 관리 절차를 말합니다.구성관리 데이터베이스 (CMDB: Configuration Management DataBase)는 IP, 하드웨어 세부 spec, 소프트웨어 stack, 버전, 연동관계 등 가변적 운영성 정보를 관리하는 시스템을 말합니다.

방금 말한 것들은 모두가 비슷한 문제를 해결하는 조금씩 다른  접근법입니다. 용어가 만들어진 배경이 다르기 때문에 정의와 경계가 명확하지 않습니다. HP나 IBM 같은 대형 벤더의 접근이 다르고, 학술기구나 단체의 접근이 다르고, 컨설팅 회사 등이 정의하는 개념도 다릅니다. 최종적으로 지향하는 바도 조금씩 다릅니다만, 인프라와 관련하여 정확한 데이터베이스를 유지하는 절차와 방법을 제시한다는 점은 모두 동일합니다. 그리고 세부 사항에서의 차이에도 불구하고 기본적 아이디어는 비슷한데, 크게 두 가지의 접근이 있습니다.

첫 번째. 절차적 접근

• 인프라의 구성은 아무 이유 없이 변하지 않는다
• 변하는 이유는 누군가가 명시적인 ‘작업’을 했기 때문이다
• 따라서 작업 절차가 종료된 시점에 변경 결과를 업데이트하도록 절차를 만든다

두 번째. 자동화를 통한 접근

• 항상 변화하는 IT 인프라를 사람이 수작업으로 업데이트하는 것은 한계가 있다
• 그러므로 관리가 필요한 IT 시스템에 에이전트를 탑재시켜 정보를 자동으로 서버로 보낸다
• 서버는 기존 데이터베이스와 신규 데이터의 동일 여부를 분석, 차이분에 대하여 반영시킨다

상용으로 출시되는 솔루션들은 위의 두 가지 접근이 혼합되어 있는 경우가 대부분입니다. 보통 프로세스에 대한 준수가 엄격한 SI/SM 전문 회사에서는 절차적인 솔루션을, 자사의 IT를 직접 관리하는 회사의 경우는 후자의 자동화 부분에 조금 더 무게가 실려 있습니다.

그런데 오래된 고민을 수많은 기업에서 노력을 기울였음에도 불구하고 아직도 현실은 그다지 아름답지 않습니다. 장부와 현실의 일치율이 남에게 말해도 부끄럽지 않을 수준인 것은 1년에 한 번, 전체 재물조사 직후 정도인 경우가 많습니다. 날마다 CMDB 솔루션은 자동으로 데이터를 업데이트하고 있지만, 운영자들은 시스템에 탑재된 데이터를 신뢰하지 않고 본인 PC 안에 들어있는 엑셀만 바라보는 경우가 훨씬 더 많습니다.

자동화 체계를 갖춘 CMDB 솔루션을 구축했음에도 불구하고 구성 정보가 맞지 않다는 것은 얼핏 이해가 되지 않습니다. 10년, 20년이나 전세계 수많은 인프라 관리자들의 고민과 학습과 경험이 집약된, 그런 솔루션을 도입하였지만 이 솔루션 구축이 성공이었다고 말하는 조직이 많지 않은 것은 시사하는 바가 큽니다. CMDB는 솔루션 자체의 완성도보다는 조직과의 궁합, 조직에서의 활용이 훨씬 더 중요하다는 점입니다.

 SK planet 의  경우

다른 회사 이야기하듯 말했지만, 사실 SK planet의 상황도 최근까지 크게 다르지 않았습니다. CMDB를 구축하기 전, 기존에는 자산관리 중심의 ITAM 시스템을 보유하고 있었습니다만 데이터의 정확도가 높지 않아서 활용률이 높지 않았습니다. 운영자들은 운영자들대로 각자 최신정보라고 주장하는 서로 다른 엑셀을 가지고 있었습니다. 전사 서버의 대수가 몇 대일까? 집계 시점마다 회사의 서버 대수가 다르게 나오는 난감한 상황이었지요.

데이터의 레코드 숫자가 틀린 상황에서 컬럼 단위의 정확도를 기대할 수가 없었죠. 운영자 별로 각자의 엑셀을 활용했고, 틀리면 안 되는 정보를 볼 때에는 직접 서버에 접속해서 커맨드로 데이터를 추출했습니다. 확인해야 할 서버 대수가 많을 때 모두가 다른 마스터를 보는 상황에서 생기는 비효율은 굳이 설명하지 않아도 될 것 같습니다.

CMDB를 구축해 비효율을 없앨 생각을 하던 시점에, 사람들은 고민이 많았습니다. 우리 회사 운영조직을 구성하는 각기 다른 회사 출신의 운영자들이 입을 모아 이야기하는 것이, ‘내가 전에 다니던 회사’(포털, 게임, 전자 등 동종 업계)에서도 ‘자동 수집’을 통해 사람의 손으로 데이터를 모으기 위한 여러 시도가 있었지만 모두 실패해 결국 각자의 엑셀로 돌아가거나, 몇 명의 알바생을 고용해서 주기적으로 엑셀을 DB에 입력한다는 것이었습니다.

객관적인 여러 정황을 봤을 때, 큰 성과를 보지 못했다고 말하는 동종 업계의 대기업들이 실패했다면 우리도 성공할 확률보다는 실패할 확률이 높다고 느껴졌습니다. 여러 가지 고민이 있었으나 우리 회사에서도 CMDB의 구축에 착수했고, 약 1년의 시간을 보냈습니다.

많은 우여곡절이 있기는 했으나, 현재의 결과를 말씀 드리면 운영자들이 ‘이만하면 조만간 엑셀을 없애도 되겠다’ 라고 말하는 수준까지 정확도가 높아졌습니다. 데이터의 정합성이 제법 높아졌기에 실사자료도 여기서 뽑고 규제기관에 제출할 데이터도 여기서 뽑습니다.  날마다 서버의 데이터들이 모니터링 툴로 자동으로 수집되고, 몇 명의 담당자가 주기적으로 데이터의 정합성을 맞추는 수준까지 업무가 향상되었습니다. 그러니 최소한 현재 시점까지는, 성공적으로 진행 중이라고 말해도 될 것 같습니다.

SK planet CMDB의 구조

그림에서 실선은 구축된 영역, 점선은 구축할 영역입니다. 직관적으로 이해할 수 있지만 조금만 부연하자면 기본적인 구조는 개별 서버에 설치된 agent가 원하는 정보를 수집하여 수집 서버에 탑재하면 일정 절차를 거쳐 CMDB 에 탑재되는 형태입니다. 여기서 일정 절차란 데이터의 파싱, 포맷 변환, 기존 데이터베이스와의 차이점 분석, 사람에 의한 예외 처리 등의 일련의 절차입니다.

개발된 방식은 각각의 수집 대상 별로 조금씩 상이합니다. 가장 많은 정보를 수집하는 서버 관련 정보의 경우, 현재 인프라에서 사용하는 표준 모니터링 툴인 자빅스(Zabbix)에 약간의 스크립트를 얹어서 데이터를 수집하고 있습니다. VM은 하이퍼바이저의 정보를 긁어내어서 데이터베이스에 담고 있으며, 네트워크 또한 장비의 config를 읽어서 활용하고 있습니다.

인프라와 CMDB에 대한 경험이 있는 분의 입장에서는 많이 특별할 것은 없는 구성입니다. 그렇게 많이들 실패한다는 CMDB 구축 프로젝트인데 나름대로 실제 업무에 쓸만한 수준까지 사용할 수 있게 된, 성공 요인이 무엇이었는지를 짧게 짚어보고자 합니다.

첫째. 프로세스를 최소화하고, 데이터 수집에 최선을 다했다

CMDB, ITSM, ITIL 등 용어가 뭐가 되었든 보통 서비스 제공 프로세스와 자동화된 정보 수집, 두 개의 View로 구성되는 경우가 많다고 했는데, 우리의 경우는 프로세스 중심으로 접근하지 않고 데이터베이스 수집 중심으로 접근했습니다. 프로젝트의 1차 목표는 현재 가지고 있는 운영자 별 엑셀 정보를 모두 넣은 데이터베이스 한 통을 만들자는 것이었습니다.

ITSM 프로세스는 얼핏 보면 어려울 것이 없어 보이는, 기껏해야 백 명이나 이백 명의 사용자(개발자)를 대상으로 열 명이나 스무 명의 처리자(SE)가 업무를 관리하는, 프로세스가 탑재되어있다기보다는 업무 관리 증적을 남겨놓는 정도의 시스템으로 보입니다. 사실 이 업무를 맡기 전까지는 저도 그렇게 생각했습니다. 그런데 막상 자세히 들여다보니 그렇게 간단한 시스템이 아닙니다. 프로세스의 복잡도나 난이도가 꽤 높습니다. 조금 더 강조하자면, 중견기업의 ERP 시스템 정도의 난이도는 되는 것 같습니다.

프로세스 설계의 난이도도 높지만, 변화관리의 난이도는 훨씬 높습니다. 그나마 ERP는 안 쓰면 업무처리가 안 되기에 담당자들은 어떻게든 시스템을 써야 합니다. 하지만 ITSM 서비스 프로세스는 안 써도 그만입니다. 심지어 프로세스 준수율 및 서비스 수준 등을 운영자 개인의 고과와 연계시키더라도 마찬가지입니다. 하루하루 고과만 생각하며 일하는 것은 아니니까요.

프로세스와 연결되지 않은 데이터베이스는 며칠 안 가서 망가질 거라는 우려도 많았습니다만, 사람들이 일하던 방식을 바꾸어가면서 CMDB를 도입하는 것은 현실적 제약이 너무 크다고 판단했습니다. 우리 시스템은 업무를 처리하는 트랜잭션 시스템이 아니라 정보를 관리하는 데이터베이스 시스템으로 컨셉을 잡았습니다.

둘째. 적정 수준의 기술로 자체 개발했다

인프라 부서에는 개발자가 거의 없습니다. 개인적으로 개발을 할 수 있는 사람이더라도, 조직 차원에서의 미션과 관련이 없기 때문에, 이런 류의 솔루션을 직접 개발하겠다는 생각을 잘 못합니다. 우리 회사도 처음에는 외부 솔루션 도입을 염두에 두고 있었습니다.

전술했듯이 CMDB와 인프라 관리 솔루션은 다양한 조직들의 오랜 고민과 경험이 담겨 있습니다. 하지만 나름의 완성도를 갖춘 솔루션을 도입한 회사들이 하나같이 실패하는 전철을 밟고 싶지는 않았습니다.

외산 솔루션은 우리에게 필요하지 않은 기능요소까지 결합된 거대한 패키지이고 가격이 비싸고 최적화 가능성이 적다는 것을 잘 알고 있었기 때문에, 외산이 아닌 국산 패키지 솔루션을 활용할 생각을 하고 있었습니다. 그리고 우리는 프로세스를 탑재하지 않고 정보수집, 데이터베이스 중심으로 솔루션을 구현할 계획이었습니다.  국산이든 외산이든 이렇게 정보 수집 중심으로 구현된 솔루션은 거의 없더군요.

결국 우리는 내부에서 설계했습니다. bottom-up으로 운영자 개인의 엑셀들을 모두 취합해서 구성관리 항목을 정했고 내부 인력이 설계를 담당했습니다. 부족한 개발 일손은 외부에서 공급받았으나 이들은 개발전문가였을 뿐 인프라나 CMDB에 대한 지식은 전혀 없었습니다. 여기서 특이한 것 한 가지. 사내의 별도 개발조직이 아니라, 사용부서에서 직접 설계를 했다는 부분입니다.

내부에서 개발할 때의 장점은 over-engineering 이 최소화 된다는 것입니다. 우리는 딱 우리가 필요한 것들만 만들었습니다. 물론 필요할 줄 알고 만들었으나 의욕과잉으로 밝혀진 부분도 없지는 않겠습니다만, 요구되는 기능에 비해 일손이 딸려 급하고 중요한 일 중심으로 개발했기 때문에, 몸에 비해 큰 옷을 입고 고생할 일이 없었습니다. 아울러 우리가 원하는 방향으로 확장이 용이하다는 장점이 하나 더 있습니다.

셋째. 데이터 정제 작업을 병행했다 

업무적인 데이터 정제 작업이 지속적으로 병행되었습니다. 비록 정기적인 대사작업은 아니지만, CMDB 설계와 구축에 책임을 지는 개발담당자 이외에, CMDB에 탑재되는 데이터에 책임을 지는 데이터 책임자가 별도로 있었습니다. 데이터 담당자는 수시로 서버 목록을 분석하고, 데이터베이스의 중복, 누락, 보완 요소를 도출하고, 각 데이터센터 별 운영 담당자 및 자산관리자들에게 이슈를 던졌습니다.

자산관리자와 유지보수계약담당자와 서버운영자들 사이의 엑셀은 모두가 달랐고, 여러 사람이 가진 엑셀 간의 차이를 분석하는 것은 길고 긴 vlookup과의 싸움이며 어려운 마라톤이었습니다. 원인이 밝혀지는 경우도 있고 그렇지 않은 경우도 있었습니다. 그런데 이 과정은 데이터의 정확성을 높이고 정제하는 측면의 의미도 있었지만 한편으로는 조직 내 변화관리의 의미도 있었습니다.

특정 영역만 담당하는 운영자의 입장에서는 본인이 개별 보유한 엑셀의 정확도가 그럭저럭 일하는 데에 지장이 없다고 생각합니다. 하지만 조직의 여러 다른 담당자가 각자 가지고 있는 데이터와 교차분석을 해보면, 자신이 가진 데이터가 생각만큼 정확하지 않다는 사실을 깨닫게 됩니다. 보름이나 한 달 단위로 대사를 해보면 예상도 못했던 착오들이 드러나고, 그 착오들을 맞추기 위해서 많은 시간을 소비해야 하는 상황.

결국 운영자들은 각자 데이터의 정합성을 맞추기 위한 스스로의 최선의 방안을 찾았습니다. 담당자를 지정해서 주기적으로 전수조사를 하겠다는 운영그룹도 있었고, 개별적으로 관리하던 엑셀 문서를 포기하고 자동 수집되는 데이터의 틀린 부분만 확인하겠다는 운영그룹도 있었습니다. 그 어느 쪽이든 간에 기존에 관리하던 방식 대비해서 훨씬 정합성 높은 데이터를 관리하기 시작했습니다.

프로세스 중심의 시스템에서는 운영자들에게 특정 작업이 종료되면 반드시 데이터를 업데이트하도록 강제화하고 있는 바로 그 부분을, 우리 회사의 경우는 약간은 느슨하게, 결과의 정합성을 중심으로 관리한 것입니다.

결론 

좋은 말만 쓰고 있지만, 사실 CMDB 프로젝트는 이슈도 많고 고민도 많았습니다. 위에서 말한 여러 성공요소들은 전략적이고 연역적이었다기보다는 환경적 제약 때문에 어쩔 수 없이 선택한 것들이 많았으며, 시스템을 오픈하기 직전까지 고민이 많았습니다. 이 데이터가 과연 믿어도 되는 데이터일까? 이 데이터를 정확한 데이터라고 공개해도 될까?

고민도 많았지만 일단 데이터를 오픈 했습니다. 여러 개발부서나 지원부서는 인프라 데이터를 활짝 열어두고 볼 수 있게 되었다는 부분에서 좋은 반응을 보였습니다. 그리고 정말 가끔씩 왜 데이터가 맞지 않느냐는 문의가 있기는 했지만, 지적이라기보다는 개선을 위한 협의에 가까웠습니다.

자산/엔지니어링/운영 담당자가 같은 데이터를 보기 시작했습니다. 어떻게든 사용자가 생기자 데이터 정합성 관리의 선순환 사이클이 생겨났습니다. 데이터는 지속적으로 정합성이 향상되고 있으며, 덕택에 운영자 업무의 효율성이 상당히 높아지고 있습니다.

현재 우리 CMDB는 다음 단계를 향해 나아가고 있습니다. 이제까지의 데이터들은 주로 자산과 IP, hostname, OS, 메모리 등 한 번 구성된 이후에는 잘 변화하지 않는, infra 성격의 정적인 데이터들을 중심으로 관리했습니다. 다음 단계로 수집하려는 것은 조금 더 동적인 서비스 관련 데이터, 예를 들면 netstat 을 통한 서버간의 세션 연결 구조라든지, Web/WAS 서버의 config 파일 등을 수집하고자 합니다.

한편 개별 운영관리시스템의 연동 작업도 준비하고 있습니다. 서비스 프로세스가 담겨있는 티켓관리 시스템, 장애대응 및 전파를 위한 incident 관리 시스템 등의 개별 시스템과 연동은, 이제까지와 마찬가지로 프로세스 수준의 타이트한 연동이 아니라 마스터 코드 등 기준정보 데이터 연동이 중심이 될 것입니다.

위에서 언급한 여러 성공요소들은 회사마다 다를 것입니다. SK planet은 태생이나 발전 과정이 여타 회사에 비해 우여곡절이 많은 편이라서 IT Infra도 더 복잡합니다. 다른 회사들의 경우 성공요소들이 조금은 다를 것입니다. 기술적인 deep-dive 보다 조직 특성에 맞는 해법을 찾는 것이 CMDB 의 성공 요인이 아닐까 생각합니다.

감사합니다.

출처: http://readme.skplanet.com/?p=12486