삼성SDS 내에선 지난 2010년 이후 리눅스와 공개SW 활용도가 부쩍 높아지고 있다. 2010년에 비하면 4배 이상 급격한 사용수를 보이고 있는 것. 문제는 활용도가 높아지는 만큼 이에 비례해서 장애 발생도 증가할 수밖에 없다는 것이다.

삼성SDS 정영훈 수석은 덤프도커(Dumpdocker), 그러니까 자동 덤프 분석툴이 탄생하게 된 이유도 이렇게 리눅스나 공개SW 제품에 대한 장애 대응이 이슈로 떠올랐기 때문이라고 말한다.

◇ 늘어나는 공개SW, 정확한 분석 위한 스마트한 방법=정 수석은 공개SW 환경이라는 것 자체가 다양한 하드웨어와 리눅스 배포판, 유사 기능을 수행하는 수많은 소프트웨어가 공존하는 세계라면서 그런데 이런 환경에서 장애가 발생하면 장애를 분석하거나 재현을 하는 방법은 너무 단출할 때가 많다고 말한다. 운영자 입장에선 이 방법 자체가 장애가 되어버린다.

그는 한 KVM(Kernel-based Virtual Machine) 충돌 사례를 예로 들면서 덤프 분석을 외부에 요청했지만 20일이 지나도록 답변이 없고 25일이 지나면 완전하진 않지만 분석 결과가 일부 나왔다고 말한다. 하지만 문제는 이 결과만으로는 어디에서 문제가 발생했는지 알 수 없다. 결국 전체 분석을 끝낸 건 덤프 분석 요청 1개월 만이다.

도대체 뭐가 문제였을까. 정 수석은 어떤 게 문제였는지 보니 문제가 발생했던 운영 환경을 그대로 재현하는 데 어려움이 있었다는 걸 알게 됐다고 말한다. 운영 환경이나 라이브러리 같은 게 디버그를 하면서 제대로 매핑이 안 된 탓에 정확한 정보도 나오기가 어려웠던 것.

덤프도커 아키텍처 구성도

정 수석은 결국 장애가 문제가 발생하면 벤더 쪽에만 의존하는 것보다는 공개SW 문제가 발생할 때 운영자가 현장에서 즉시 분석하는 1차 보고서, 퍼스트 패스(First Pass) 기법을 통해 먼저 문제 분석에 접근하는 게 좋지 않을까 하는 생각을 갖게 됐다고 말한다. 물론 굳이 내부 분석이 아니더라도 지원 벤더나 커뮤니티 등에 문제 해결을 위해 덤프를 넘길 때에도 그쪽에서 완벽한 환경을 갖춰서 같은 문제를 해결할 수 있게 해줘야 하는 건 물론이다. 덤프도커는 이런 문제 해결을 위한 스마트한 방식을 고민한 결과물이다.

그렇다면 장애가 발생한 운영 서버와 완벽하게 같은 환경을 구축하려면 어떻게 해야 할까. 박재화 수석은 “물론 가장 쉬운 방법이야 통째로 백업을 받아서 다른 서버에 부어놓고 분석하는 것이겠지만 문제가 있다”고 말한다. 내부에서 분석을 할 때야 그렇다고 쳐도 외부로 파일을 보낸다면 용량이 너무 커지고 내부의 민감한 정보까지 담고 있을 수 있어 걸림돌이 많다는 것이다.

이런 문제 해결을 위해 나온 덤프도커는 지난 3월 첫 버전이 나왔다. 덤프도커는 리눅스 컨테이너 기술을 이용한다. 리눅스의 컨테이너 기술은 사실 2006년부터 시작됐으니 어찌 보면 오래된 것이다. 하지만 컨테이너를 쓰려면 복잡한 단계를 거쳐야 하는데 이 문제를 해결해준 게 도커 엔진이다. 얼마 전 레드햇이 발표한 RHEL7의 경우 공식적으로 도커를 활용한 애플리케이션 배포 등을 지원한다. 박 수석 역시 이를 계기로 본격적으로 도커를 활용해보자는 생각을 갖게 됐다고 말한다.

덤프도커 프로젝트는 말 그대로 자동으로 덤프 분석 환경을 만들어준다. 만들어지는 이미지는 2개다. 도커1 이미지는 분석 환경 구축을 위한 자동 덤프 분석용이다. 이를 통해 퍼스트 패스, 1차 분석 보고서도 자동 생성된다. 또 하나는 도커2 이미지. 1차 분석 보고서가 나오면 이 중 알려진 문제를 도커2 이미지, 그러니까 KDB(Knowledge DB)를 검색해서 일치하는 부분을 찾아 분석 보고서에 추가하게 된다. 물론 아직까지는 KDB까지는 완벽하게 구성된 상태가 아니라고 한다.

◇ 커널 없이 독립 작동, 가상머신보다 편해=그렇다면 단순하게 보고서 자동으로 하나 만들어주는 게 덤프도커의 장점일까. 도커는 애플리케이션 컨테이너다. 가볍고 이동성이 좋다. 덕분에 어떤 환경에서든 운영할 수 있다. 이런 과정을 자동으로 배포할 수 있는 공개SW 엔진인 것이다. 박 수석은 버추얼 머신과 견줘 도커의 장점을 말한다. 보통 버추얼 머신을 운영하려면 운영체제가 하나 더 필요하다. 아파치 웹 서버를 하나 돌리겠다면 실제로 리눅스 운영체제 위에 아파치 웹 서버를 구축하는 식이다.

하지만 도커는 다르다. 운영체제 없이 그냥 아파치 웹 서버만 있으면 된다. 운영체제로 없이, 그러니까 커널이 없어서 부팅 과정 없이 곧바로 실행하는 것이다. 도커 이미지를 실행하면 독립된 프로세스로 동작한다. 간단하게 말해 아파치 웹 서버와 관련한 구성 파일, 바이너리, 라이브러리만 묶어서 배포하면 어떤 환경에서나 똑같은 상태로 애플리케이션을 운영할 수 있다는 얘기다. 박 수석은 도커의 장점으로 “이동성은 물론 훨씬 더 가볍고 자원도 덜 쓰는 환경을 만들어주는 것”이라고 설명했다.

도커는 활용 방안. 요즘 인터넷에서 보면 애플리케이션 배포에 초점이 맞춰져서 활용되고 있다. 덤프도커의 경우에는 디버깅에 속한다. 도커를 기반으로 한 분석 환경이라는 건 운영 중인 서버에 문제가 발생했다면 이를 해결하기 위해 코어 파일이 필요하게 된다. 관련 바이너리와 라이브러리를 모조리 수집해야 한다. 이런 걸 다 모아야 다른 곳으로 옮겨서 분석할 수 있는 것.

삼성SDS 박재화 수석은 퍼펙트ICT 연구회의 목적이 세계 최고 수준의 장애 분석 전문가를 양성하는 것이라고 밝혔다.

덤프도커가 없는 상태라면 문제가 된 바이너리와 코어 파일을 불러오면 관련 라이브러리를 불러오지 못해 제대로 된 정보를 못 본다. 이것저것 다시 맞추는 작업을 해도 일부는 제대로 정보를 보여주지 못하는 문제가 여전할 수 있다. 번지수나 모든 걸 매칭해야 하는 번거로움도 감수해야 한다.

하지만 덤프도커를 이용하면 간단하다. 운영서버에서 코어 파일과 프로세스, 바이너리만 지정하면 관련된 모든 파일을 자동 수집한다. 이 환경을 분석 환경 서버에 옮겨와서 도커 이미지를 만들어서 띄우는 것이다. 이 과정을 거치면 운영 서버에서 직접 실행한 것처럼 완벽한 결과를 재현한다. 박 수석은 “덤프도커를 이용하면 귀찮은 작업을 할 필요가 없다는 게 주요 골자”라고 말한다.

◇ KDB 확보가 과제 “공개SW로 함께 만들어갈 것”=덤프도커를 이용한 분석 환경은 운영 서버 같은 환경을 그대로 재현해 빠른 분석을 가능하게 해준다. 필요한 라이브러리나 바이너리 정보만 가져오기 때문에 기업이 민감한 정보를 뺀 상태에서 지원 벤더나 외부에 제공할 수 있다. 결국 이런 장점은 보안 문제를 해소할 수 있는 방편이 되기도 한다.

덤프도커는 현재 진행형이다. 공개SW 개발자 커뮤니티인 기트허브(Github)를 통해 공개SW 프로젝트(https://github.com/pjhwa/dumpdocker)로 진행하고 있다. 지금까지 완성된 부분은 운영 서버에 문제가 발생한 프로세스 관련 파일을 모두 자동 수집하는 덤프도커 스크립트, 퍼스트패스 1차 분석 보고서를 자동 생성해주는 툴 등이다. KDB 도커는 아직 진행 중이다.

퍼스트패스 1차 분석 보고서는 기본 정보와 환경 변수, 소스 코드나 어셈블리 코드 라인, 레지스터 정보와 가상 메모리, 스레드 정보와 셰어드 라이브러리 등 12가지 항목에 대한 정보를 자동 분석해서 결과를 출력해준다. 물론 이것만으론 뭔가 부족하다고 느낄 수 있다. 부족함을 메워줄 13번째 요소가 바로 KDB다.

정 수석은 “문제는 아직 케이스가 얼마 되지 않는다는 것”이라고 말한다. 분석에 필요한 더 많은 케이스가 필요하다는 얘기다. 정 수석은 이런 케이스를 더 확보하는 게 과제인 만큼 더 많은 사람이 참여하는 공개SW 프로젝트로 해야 가능할 것이라고 말한다. 더 많은 덤프 분석과 KDB 구축이 필요하기 때문이다. 그는 운영 서버 등에 문제가 발생했을 때 덤프도커 이미지를 만들어서 보내주고 이메일로 연락을 하면 무료로 분석을 해주는 한편 KDB 케이스로 확충하는 생태계를 구축할 수 있다면서 참여가 필요하다는 점을 강조했다.

※ 이번 공개SW 활용 성공사례는 테크홀릭과 정보통신산업진흥원 공개SW 역량프라자가 공동으로 발굴한 기사(http://www.oss.kr/oss_repository10/567992)다.

이석원 기자  lswcap@techholic.co.kr

<저작권자 © 테크홀릭, 무단 전재 및 재배포 금지>