"단 2명이 오픈스택 VM 8천개 맡아보니…"

메신저 앱 서비스 회사 카카오가 자사 오픈스택 기반 클라우드 컴퓨팅 인프라의 가상머신(VM) 8천개 이상을 단 2명의 전담인력으로 관리하고 있다고 밝혔다. 대규모 컴퓨팅 자원을 대규모 극소수 인력으로 운영하기 위해 활용 중인 기술과 데브옵스(Devops) 전략도 제시했다.

카카오 클라우드컴퓨팅셀 아키텍트 공용준 수석은 지난 22일 서울 을지로 T타워 수펙스홀 제40회 개발자포럼에 참석해, 자신이 담당하고 있는 카카오의 오픈스택 기반 클라우드 인프라 현황과 자동화 중심의 운영 방법을 발표했다.

이날 공 수석의 발표 자료에 따르면 카카오 클라우드 환경은 3개 리전으로 구성된 오픈스택 킬로(kilo) 버전 인프라로 964개 테넌트가 운영되고, 매일 136개의 VM이 생성 및 제거된다고 쓰여 있었다. 여기서 돌아가는 전체 VM 규모가 7천개로 표기돼 있었지만, 그는 이미 8천개를 넘었다고 언급했다. 카카오에서 8천여개 VM을 관리하는 전담 인력은 몇 명일까? 달랑 2명이다.

카카오 공용준 수석이 2016년 6월 22일 SK텔레콤 개발자포럼에서 발표한 자료 일부. 카카오 오픈스택 기반 클라우드 인프라에서 발생하는 자원 활용 양상을 단편적으로 제시하고 있다.

지난 2월 공개된 카카오의 오픈스택 활용사례[☞참조링크: KakaoTalk speaks volumes about the future of cloud services]에 따르면 공 수석이 언급한 전담인력 2명이 하는 일은 VM 업그레이드 관리, 버그 패치, 신기능 구성 등이다. 그 일부에서 카카오의 수익과 직결되는 '프로덕션서비스'가 구동된다. 물론 프로덕션서비스 환경에는 이 2명만이 아니라, 서비스 운영 품질 보장 업무를 수행하는 인프라 담당팀도 개입한다. 즉 자동 장애 통보, 엔지니어링 서포트, 네트워크 엔지니어링 업무 담당자는 따로 있다.

그렇다고 단 2명이 VM 수천개를 무난하게 관리하길 기대할 수 있다는 얘기는 아니다. 오류나 장애 발생 가능성에 대해 실무자가 수시로 느끼는 부담이 상당할 것이라 짐작된다. 공 수석의 발표 중 프로덕션 서비스를 위한 오픈스택 빌드, 테스트, 배포 자동화툴 'K필드(Kfield)'를 활용하는 업무 흐름을 언급한 부분에서 이를 짐작할 수 있다. 그 일부를 옮겨 본다.

"오픈스택은 오픈소스 소프트웨어라 (상용 소프트웨어 대비) 버그도 있고, 자잘한 패치나 업그레이드를 위한 공수가 많이 필요하다. 커스터마이즈 코드를 적용하기 위해 깃(git)을 사용하고 풀 리퀘스트(pull request)가 날아오면 젠킨스에서 키친 클러스터를 만든 뒤 테스트를 돌려 본 다음, 결과가 (안정적으로) 나오면 병합(merge)을 하는 과정을 거친다. …(중략)… 아주 많은 VM을 관리하고 있기에 스트레스가 굉장히 높은 편이다. (어떤 서비스든) 하나 다운되면, 회사에서 뭐라곤 안 해도 개인적으로는 부담이 된다. 휴먼인터랙션이 (장애 발생을 빌미로) 많아지면 대화가 잘 되는 사람들은 부드럽게 할 수 있지만, 그렇지 않으면 뭔가 하다가 잘 안 된다고 싸우기도 한다."

카카오 공용준 수석이 2016년 6월 22일 SK텔레콤 개발자포럼에서 발표한 자료 일부. 클라우드를 기술이 아닌 자원관리 방법의 하나로 정의하고 이를 실행하기 위해선 이 전제를 공유하는 문화가 바탕에 있어야 한다는 시각을 담고 있다.

현재 VM 인프라는 카카오의 주요 서비스 기반이다. 향후 그 중요성은 계속 커질 전망이다. 공 수석은 "카카오 드라이버 (서비스) 프로모션은 모두 VM 기반으로 구동됐고, 향후 나올 몇몇 서비스들 역시 모두 VM 기반으로 돌아갈 것"이라며 "다음 메일의 스팸 필터 역시 VM만으로 제공되고 있다"고 설명했다.

카카오처럼 혼자서 수천개 VM을 관리할 수 있게 만든 핵심 요소는 뭐였을까. 공 수석에 따르면 그건 기술이 아니라 '문화'에 달렸다. 공 수석은 자신들의 조직문화가 '자동화(Automation)'고, 기술은 이 문화를 지원할 수 있는 수단이라고 설명했다. 앞서 그가 실무에 활용 중이라 언급한 깃, 젠킨스, K필드와 같은 툴도 이런 문화를 지원하기 위한 수단일 뿐이다.

공 수석은 같은 맥락에서 클라우드를 기술이 아니라 "프로그래밍할 수 있는 자원관리(Programmable Resource Management)"라는 방법론적 개념으로 정의하고 이를 실현하기 위해 클라우드 데이터센터가 갖춰야 하는 기능 3가지를 제시했다. 중앙집중형 구성관리데이터베이스(Centralized CMDB), 중앙집중형 측정 시스템(Centralized Measuring system), 중앙 배포 시스템(Central Deploying system)이다.

현재 카카오가 이런 기능에 초점을 맞춘 데이터센터 관리시스템을 개발, 활용 중이다.

카카오 공용준 수석이 2016년 6월 22일 SK텔레콤 개발자포럼에서 발표한 자료 일부. 8천개 이상의 VM을 단 2명이 관리할 수 있는 수준의 자동화 관리 전략을 실행하기 위해 클라우드 인프라에 3가지 핵심 기능을 갖추고자 했다는 내용이다.

중앙집중형 CMDB는 구성관리를 네트워크, 서버, 스토리지 등 개별 하드웨어나 시스템이 아니라 데이터센터 수준에서 수행할 수 있게 해 줄 수단이다. 공 수석은 앤서블(Ansible), 퍼펫(Puppet), 셰프(Chef)같은 도구를 쓰는 것만으로는 충분치 않다고 지적했다. ERP, 구성자동화, 자산관리 시스템 등과의 연동을 위한 중앙화된 방식이 필요하다는 설명이다.

중앙집중형 측정 시스템은 네트워크, 서버, 스토리지 등의 작동상태를 개별 인프라가 아니라 데이터센터 수준에서 측정해 줄 수단이다. 클라우드 사용자들은 자신이 사용하는 애플리케이션을 위한 자원에 여유가 부족할 경우에 대비할 수 있는 통지를 받고 싶어하고, 운영자 입장에서도 어떤 사용자에게 어떤 자원이 얼마나 쓰였는지를 파악할 수 있어야 과금(billing)과 자동확장(Autoscaling)을 할 수 있다.

중앙 배포 시스템은 데이터센터를 통합된 자원 덩어리(Resource Pool)로 인식하고 이를 사용자가 정의하는대로 떼어 나눠줄 수 있는 기능을 의미한다. 물리적 서버, VM, 컨테이너 등 인프라 수준으로 정의된 자원뿐아니라 DB서버, 웹서버, WAS 등 기능으로 정의된 자원까지도 흔쾌히 떼어 나눠줄 수 있어야 한다. 자원의 형태나 위치와 무관하게 전체 데이터센터를 아우르는 '제어 플레인'이 필요하다는 설명이다.

공 수석은 "카카오는 자체 데이터센터 인프라 없이 (국내 주요 데이터센터 공급업체) 인프라 3곳을 빌려 쓰고 동시에 퍼블릭클라우드 인프라 자원도 많이 사용하고 있기 때문에 모든 자원이 추상화돼 있어야 한다"며 "이런 (중앙제어 방식으로 CMDB, 측정시스템, 배포시스템 기능이 동작하는) 콘셉트를 기반으로 클라우드 데이터센터 관리시스템을 만들게 된 최대 이유"라고 밝혔다.

카카오 공용준 수석이 2016년 6월 22일 SK텔레콤 개발자포럼에서 발표한 자료 일부. 카카오의 오픈스택 기반 클라우드 인프라의 효율적인 자동화 관리를 수행하기 위해 활용한 툴과 개발한 시스템 구성 개념도를 포함하고 있다.

그는 이렇게 개발한 시스템의 기술적 구성에 대해서도 대략적으로 설명했다.

우선 카카오는 중앙집중형 CMDB 기능을 위한 API를 만들었다. 이걸로 CMDB에 네트워크 팀, 시스템 팀 등이 각자 매칭되는 정보를 올리고, VM 자원 요청시 새로운 서버에 운영체제(OS) 및 이더넷 드라이버 설치 등을 자동으로 수행하는 툴박스를 사용했다. 여기에 네트워크팀은 CMDB 기준으로 필요한 스위치 구성 등을 처리하게 했다. 이렇게 구성된 자원이 셰프 코드를 통해 오픈스택 환경으로 배포되게 했다.

그리고 소프트웨어정의네트워킹(SDN)을 구성했다. 서브넷, 터널, DPDK, 오픈V스위치는 안 쓰였다. 컴퓨트 노드와 톱오브랙 스위치 연결에 오픈플로가 아닌 BGP 프로토콜을 사용했고, 외부망 연동에는 eBGP를 적용했다. 컴퓨트 노드는 가상랜(vlan)을 통해 가상 스위치 블록과 프로세스 블록으로 나뉜다. 가상 스위치 블록에서 뉴트론 I3 에이전트가, 프로세스 블록에서 리눅스브릿지 에이전트가 돌아간다.

또 카카오는 케미(KEMI)라는 중앙모니터링툴을 개발 중이다. 핵심은 통합서비스버스(ISB)인데, 스케줄러가 CMDB에서 불러낸 구성목록을 바탕으로 모니터링 활동(job)을 지시하면 이를 수행하고, 결과 이벤트를 처리해 상태 정보를 제공하거나 알림을 보내는 식으로 작동한다. 이를 위해 SNMP 프로토콜로 물리서버, 컨테이너, VM 등의 모니터링 정보(메트릭)를 가져온다. SNMP를 적용한 이유는 모니터링 대상에 네트워크 스위치를 포함시키기 위해서였다. 카프카(Kafka), 삼자(Samza), 카멜(Camel), 스톰(Storm), 고블린(Gobblin), 얀(Yarn), 하둡파일시스템(HDFS), Etcd, 오픈TSDB(OpenTSDB), H베이스(Hbase), 타조(Tajo), 그라파나(Grafana) 등 다양한 오픈소스 구성요소가 동원됐다.