본문 바로가기

Home > 정보마당 > 공개SW 활용 성공사례

공개SW 활용 성공사례

[공개SW 활용 성공사례 153] 삼성SDS - Dumpdocker 공개SW 프로젝트 통한 장애 분석툴

OSS 게시글 작성 시각 2014-10-14 18:13:49 게시글 조회수 1570
공개SW 덤프 분석, 함께 하실래요?

삼성SDS 내에선 지난 2010년 이후 리눅스와 공개SW 활용도가 부쩍 높아지고 있다고 한다. 현재는 2010년에 비해 4배 이상 높은 공개SW 활용 수치를 보이고 있는 것. 문제는 활용도가 높아지는 만큼 이에 비례해서 장애 발생도 증가하고 있다는 것이다. 덤프도커(Dumpdocker) 즉 자동 덤프 분석툴이 탄생하게 된 이유도 리눅스 등 공개SW 활용에 대한 장애 대응이 이슈로 떠올랐기 때문이다.


- 기     관 삼성SDS
- 수행년도 2014년 3월
- 도입배경 2010년 이후 리눅스와 공개SW의 사내 활용도가 높아지면서 리눅스나 공개SW 제품에 대한 장애 대응이 이슈로 떠올랐고 문제 분석을 위한 자동 덤프 분석툴 필요성 대두
- 솔 루 션 덤프도커(Dumpdocker)
- 도입효과 : 커널 등 모든 요소를 갖춰야 하는 가상머신과 달리 독립 실행할 수 있고 똑같은 환경을 손쉽고 빠르게 재현해 문제 해결 시간을 줄일 수 있다.

 

늘어나는 공개SW, 정확한 분석 위한 스마트한 방법

삼성SDS 사내 기술 연구 모임인 ‘퍼펙트ICT 연구회’에서 덤프도커 프로젝트를 추진하고 있는 박재화 수석과 정영훈 수석의 설명에 따르면, 공개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 엔진인 것이다. 박 수석은 가상머신(virtual machine)과 비교해 도커의 장점을 말한다. 보통 가상머신을 운영하려면 운영체제가 하나 더 필요하다. 아파치 웹 서버를 하나 돌리겠다면 실제로 리눅스 운영체제 위에 아파치 웹 서버를 구축하는 식이다.

 

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

 

docker

 

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

 

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

 

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

 

KDB(Knowledge DB) 확보가 과제 “공개SW로 함께 만들어갈 것”

덤프도커를 이용한 분석 환경은 운영 서버 같은 환경을 그대로 재현해 빠른 분석을 가능하게 해준다. 필요한 라이브러리나 바이너리 정보만 가져오기 때문에 기업이 민감한 정보를 뺀 상태에서 지원 벤더나 외부에 제공할 수 있다. 결국 이런 장점은 보안 문제를 해소할 수 있는 방편이 된다고 설명한다.

 

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

 

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

 

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

 

 

[인터뷰]


“세계 최고 수준 장애 분석 전문가 양성이 목표”

삼성SDS 박재화 수석, 정영훈 수석


삼성SDS 박재화 수석
▲ 삼성SDS 박재화 수석

Q. 퍼펙트ICT 연구회는 어떤 조직인가?

A. 삼성SDS 사내 기술 연구 모임이다. 당초에는 퍼펙트RCA와 오픈ICT라는 연구 모임으로 나뉘어져 있었지만 덤프도커 프로젝트를 추진하면서 퍼펙트ICT로 합쳐 진행하게 됐다. 공개SW의 데이터 센터 내 활용에 대한 연구를 수행하는 한편 ICT 인프라 문제에 대한 해결 방법론 연구를 진행하고 있다. 모임의 목표는 세계 최고 수준의 장애 분석 전문가를 양성하는 것이다.

 

Q. 덤프도커의 가장 큰 장점은 꼽자면?

A. 운영 서버와 같은 환경으로 굉장히 빠르게 분석할 수 있다는 것이다. 꼭 필요한 라이브러리나 바이너리 정보만 가져오기 때문에 기업 내에서 민감하게 생각할 만한 정보는 빼고 외부 분석 기관이나 지원 벤더 같은 곳에 제공할 수 있다. 기업 입장에선 보안 이슈도 없을 수 있는 것이다. 전체를 통째로 복사하는 것보다 가볍고 이동성이 좋다는 것도 당연히 장점이다.

 

삼성SDS 정영훈 수석
▲ 삼성SDS 정영훈 수석

Q. 퍼스트패스 1차 분석 보고서에 나오는 항목에는 어떤 게 있나.

A. 12가지 항목에 대해서 자동으로 분석해서 결과를 출력해준다. 가장 기본적인 건 어떤 프로세스가 죽었는지 시그널 등 일반 정보와 환경 변수를 자동으로 출력해준다. 문제 분석에서 가장 기초가 되는 스택트레이스(Stacktrace) 정보를 출력해준다. 노트라는 부분은 마치 선생님이 빨간펜으로 첨삭해 준 것처럼 이게 왜 죽었는지 경우에 따라서 자동으로 다 작성을 해준다. 운영 장비에 프로세스가 죽었을 때 전문적 분석이 필요할 때 이걸 실행하게 되면 1차적으로 운영 장비에 대한 문제나 뭐가 필요하다는 리포팅을 바로 할 수 있다.

 

문제가 발생한 프레임에 대한 자세한 정보, 소스 코드가 다 사용 가능하다. 소스코드 경로만 지정하면 친절하게 문제가 발생한 곳의 리스팅까지 해준다. 또 소스 코드가 제대로 제공이 안 될 경우 어셈블리 코드 라인에서 문제를 찾아주고 각 내용을 해설을 해서 설명해준다.

 

또 마지막으로 죽었을 때의 레지스터 정보를 출력해준다. 가상 메모리(Virtual address space)를 얼마나 쓰고 있었는지도 확인할 수 있다. 쓰레드 정보(Thread)를 알려준다. 셰어드 라이브러리 어떤 걸 쓰고 있었는지, 각각의 스택트레이스에서 어떤 인자가 어떤 값을 갖고 넘어갔는지도 확인할 수 있다.




- 공개SW 역량프라자
맨 위로
맨 위로