IT/모바일
제공 : 한빛 네트워크
저자 : Mike Loukides
역자 : 최종훈
원문 : Beyond the stack
분산된 개발자들의 스택(DDS)에 속한 도구들이 매우 분산된 환경속에서 개발을 관리 가능하게 만듭니다.
지난 20년간 소프트웨어 개발의 외향은 매우 급격히 변해왔습니다. 우리는 인터넷, 웹, 가상화, 그리고 클라우드 컴퓨팅에 있어서 매우 많은 변화들을 목도해 왔습니다. 이 모든 변화들은 하나의 본질적인 새로운 현실을 가리킵니다. 바로 모든 컴퓨팅이 분산 컴퓨팅이 되었다는 점입니다. 홀로 독자적으로 운영되는 애플리케이션의 시대는 사라졌고, 한 대의 컴퓨터에서 운영되는 애플리케이션은 거의 생각할 수도 없게 되었습니다. 분산은 기본이 되었습니다. 게다가 애플리케이션이 AWS(아마존 웹 서비스)에서 동작하든, 사설 클라우드에서 동작하든, 심지어 하나의 데스크탑이나 모바일에서 동작하든, 그 애플리케이션은 그 개발자의 통제 밖에 있는 다른 시스템들과 서비스들의 동작에 의존하게 되었습니다.
지난 몇 년동안, 광범위하게 분산된 애플리케이션들의 개발을 돕기 위해 새로운 도구모음들이 발전해왔습니다. 우리는 이러한 새로운 도구모음을 DDS(Distributed Developer’s Stack)라고 부릅니다. 이것은 전통적인 서버들, 프레임워크들, 운영체들과는 관계가 거의 없습니다. 이는 LAMP(리눅스, 아파치, Mysql, php)와 같은 전통적인 스택을 대체하는 것은 아니지만, 매우 분산된 환경 속에서 개발을 관리가능하게 만들어주는 도구들의 집합입니다.
DDS는 전통적인 의미의 하나의 스택이라기 보다 그 이상의 의미를 지닙니다. 이것은 하나로 규정된 것은 아닙니다. 우리는 당신이 AWS나 OpenStack을 사용하는지, 혹은 GIt이나 Mercurial을 사용하는지에 관심이 없습니다. 우리는 당신이 클라우드를 염두해 두고 개발을 한다는데 관심이 있고, 당신이 분산된 버전 통제 시스템을 사용한다는 데 관심이 있습니다.
플렛폼으로서의 클라우드
AWS는 소프트웨어 개발에 대변혁을 가져왔습니다. 스타트업에 종사하는 이들은 그들이 필요한 만큼의 많은 서버를 그들의 요구사항에 맞게끔 저렴한 비용으로 쉽게 할당하는게 가능해졌습니다. 이미 규모를 갖춘 회사의 개발자들은 전통적인 IT기반의 조달방식을 간단히 할 수 있게 되었고, 신용카드만 있으면 금방 서버룸을 구성할 수 있게 되었습니다.
심지어 AWS나 다른 클라우드 기반 도구를 사용하지 않는 애플리케이션도 분산되어 있습니다. 가장 단순한 웹페이지만 하더라도 서버, 웹브라우저, 호스트 이름 변환을 위한 DNS 서버, 신호를 전달하는 수많은 스위치와 라우터들이 필요합니다. 조금만 더 복잡한 웹 애플리케이션을 생각해 보면, 인증서버, 데이터베이스, 실시간 데이터를 위한 웹 서비스들에 의존하고 있습니다. 이 모든 것이 가장 단순한 애플리케이션을 분산된 시스템에 대입해보면 간단히 확인가능한 사실입니다. 정전, 라우터 멈춤, 혹은 당신이 들어보기 힘든, 어떤 도시의 케이블 불량까지 당신의 애플리케이션을 멈추게 할 수 있습니다.
저는 클라우드로 인해 하늘이 무너질거라고 주장하는게 아닙니다. 하지만 우리가 배치하고 운영하는 시스템들에게, 이런 클라우드 기반이 무엇을 의미하는지 이해하는게 매우 중요합니다. 한 애플리케이션에 연관된 시스템들의 수가 증가할수록 고장의 유형도 급격히 증가합니다. 10대의 서버들에서 운영되는 애플리케이션은 1대의 서버에서 운영될 때 보다 10배 복잡한게 아니라 1,000배는 더 복잡합니다.
클라우드는 이제 일상화되었습니다. 사설이든 공용이든, AWS, OpenStack, Microsoft Azure, Google Compute Engine을 사용하든, 애플리케이션들은 가까운 미래에 클라우드에서 동작할 것입니다. 우리는 이에 잘 대처해야만 합니다.
분산된 프로세스로서의 개발
수년간 소스 관리에 있어서 우리는 많은 진보를 이루었지만, 최근까지 소프트웨어 개발 자체가 분산되었다는 사실에 우리는 결코 대처하지 못했습니다. 우리의 개발 모델은 한명의 프로그래머가 고립된 머신에서 운영되는 단일한 프로그램들을 만든다는 것에 기초해왔습니다. 우리는 이런 프로세스들을 더욱 쉽게하기 위한 도구들, 소스 관리 도구들과 같은 것들은 만들어 왔지만, 이 어떤 것도 개발 프로젝트 자체가 팀을 필요로 한다는 것을 진지하게 인지하지 못했습니다. 개발자들은 그들의 개발 프로젝트에 있어서 그들이 속한 부분에서만 일했고, 그 이후에 모든 분리된 조각들을 모으기 위한 광범위한 통합의 단계에서 이미 엉망이된 상태를 해결하기 위한 시도를 해왔습니다.
버전 통제 시스템인 Git은 개발자들로 구성된 하나의 팀은 근본적으로 분산된 시스템이며, 소프트웨어 개발의 자연적 프로세스는 가지나 분기점을 만들며 퍼져나가는 것이며, 이후에 이 가지들이 하나의 핵심 저장소에서 합쳐진다는 것을 인지했습니다. 모든 개발자들은 자신에게 익숙한 코드에 기반하고 있으며, 핵심으로부터 분기했습니다. 그들이 그들의 기반에서 준비가 끝나면, 그들은 그들의 코드 변화를 통합하여 다시 핵심으로 융합시킵니다. 이 시점에서 그 팀의 다른 멤버들은 그들의 코드기반을 업데이트하기 위해, 다른 이들로 부터의 변화를 확인할 수 있습니다. 각 개발자들의 업무는 다른 이의 업무로부터 분리되어 있습니다. 팀원들은 비동기적으로 일할 수 있고, 공간 뿐만 아니라 시간도 분산되어 있습니다.
Jenkins나 그 이전 버전인 Hudson과 같은 지속적 통합 도구는 페러다임 변화를 인지한 첫 도구들입니다. 지속적 통합은 개발이 분산되어 있을 때, 모든 개발자들의 업무를 통합하는 것이 일관적 작업이어야 한다는 현실을 반영했습니다. 이것은 최종 버전이 발표될 때 까지 연기될 수 없었습니다. 조금이라도 앞으로 나아가 프로젝트가 항상 구축되고 운영되는 것이 중요했습니다.
분산된 개발자들의 팀의 통합을 가능케 하는 것이 결코 간단한 문제는 아닙니다. 독자적으로 움직이는 프로그래머에 대한 신화를 유지하기 위해 노력하는 것보다, 분산된 개발의 속성을 인지한 툴들을 더욱 다루기 쉽게 하는게 문제입니다.
코드로서의 기반체계
Velocity 컨퍼런스에서 기반체계로서의 코드(Infrastructure as code)가 슬로건이 되었습니다. 이는 무슨 의미일까요?
클라우드 컴퓨팅은 개발자들이 메모리를 할당하듯 서버를 쉽게 할당하는게 가능하게 만들었습니다. 하지만 90년대 시스템 관리자가 잘 알고있듯, 실제 힘든 점은 서버를 박스에서 꺼내는 것이 아니라, 올바르게 설치하고, 설정하는 것입니다. 그리고 그건 당신이 콘솔 화면 바로 앞에 있든, 수마일 떨어진 곳에서 원격으로 접속해 있든 고통스러운 일입니다. 당신이 하나의 서버나 작은 규모의 클러스터구조에서 전 세계의 분산된 수백개의 AWS 노드로 구조를 증강하려 한다면 그 고통은 더 큽니다.
지난 10년간 우린 이 문제를 해결하기 위한 도구들의 급증을 지켜봤습니다. Chef, Puppet, CFEngine, Ansible, 그리고 그 비슷한 도구들이 시스템 설정들을 스크립트로 담아냈고, 물리적이든 가상화든, 컴퓨터 설정을 자동화했습니다. 기계를 동적으로 할당하고, 설정을 자동화시키는 능력은 컴퓨팅 자원과 우리의 관계를 변화시켰습니다. 이전에는 리부팅, 재설치, 디스크 교체 등과 같은 수단을 써서 무엇인가 고장났을 때 당신이 고쳐야만 했습니다. 이는 우리의 데스크탑이나 휴대폰에 있어서는 여전한 사실이지만, 우리의 개발환경기반에서는 더 이상 사실이 아닙니다. AWS 서버의 뭔가가 잘못 동작하면, 당신은 그것을 지우고 다른 것을 시작시키면 그뿐입니다. 이건 쉽고, 간단하고, 빠르고, 저렴합니다. 최소한의 운영자만으로 수천, 수만의 서버를 관리할 수 있습니다. 적절한 모니터링 도구를 이용해 고장난 서버를 확인하고, 중지시키고, 지우고, 새로운 것을 할당하는 작업을 자동화 할 수 있습니다.
설정이 코드라면, 설정은 소프트웨어 개발의 일부로 고려되어야만 합니다. 당신의 노트북에서 개발된 소프트웨어가 운영자에 의해 배치되어야 할 곳에 배치되어 설치되리라 기대하는 것은 충분하지 않습니다. 개발과 배치는 분리된 프로세스가 아니라 같은 업무의 다른면일 뿐입니다.
배치로서의 컨테이너화
컨테이너는 스택에 가장 최근에 추가된 것입니다. 컨테이너는 가상화에서 한 단계 더 나아간 것입니다(Docker 같은 시스템은 당신의 소프트웨어를 배치하기 위해 꼭 필요한 패키지를 알맞게 설치하게끔 해준다는 것, 그 이상도 이하도 아닙니다). 이 패키지는 수십년간 화물 운송에 있어 혁명을 가져온 전통적 선적 컨테이너와 비슷합니다. 이것은 운반 선적에 조심히 피아노, 오일을 담은 통과 같은 것들을 적재하는 것 보다, 적재하기에 딱 맞아 떨어지는 표준 컨테이너에 쌓아 올리는 것이며, 이는 화물을 싣고 내리는 작업을 쉽게했고, 선박 뿐만 아니라, 트럭, 기차로 운반가능하며, 목적지에 도착할 때 까지 오픈되지도 않습니다.
컨테이너는 항상 같은 방식으로 동작하기 때문에 특별합니다. 당신은 Docker 컨테이너에 당신의 애플리케이션을 묶어서 당신의 노트북 컴퓨터에서 실행시킬수도 있고, Amazon으로 전송해 AWS에서 실행시킬 수 있고, OpenStack 같은 클라우드에서 실행도 가능합니다. 만약 아직도 사설 서버룸을 갖추고 있다면, 당신의 서버에서도 실행가능합니다. 컨테이너에는 코드를 올바르게 실행시키기 위해 필요한 모든 것이 포함되어 있습니다. 당신은 OS 업그레이드, 새로운 버전의 Apache, nginx 설치, 더 나은 버전의 라이브러리로의 교체와 같은 뜻밖의 불쾌함을 가져올 어떤 걱정도 할 필요가 없습니다. 물론 당신은 이제 당신의 컨테이너가 최신의 OS와 라이브러리로 패치되어 있게끔 유지할 책임이 있습니다. 당신은 이제 시스템 관리자에게 의존할 수 없습니다. 하지만 당신은 그 프로세스를 관리하게 되었습니다. 당신의 소프트웨어는 항상 당신이 지정한 바로 그 환경에서 운영될 것입니다. 그리고 분산된 환경 속에서 소프트웨어가 멈출 수 있는 많은 상황을 고려해 볼 때, 실패한 소스 한 부분만을 제거한다는 것은 좋은 생각입니다.
테스팅으로서의 모니터링
거대하게 분산된 시스템속에서, 소프트웨어는 당신이 테스트하지 못한 많은 이유로 멈출 수 있습니다. 테스트 주도 개발은 라우터가 멈췄을 때 당신의 애플리케이션이 어떻게 응답할지를 말해주지 않습니다. 어떤 합격판정테스트도 당신의 예측보다 1,000배 많은 부하에서 당신의 애플리케이션이 어떻게 동작할지 말해주지 않습니다. 테스트는 종종 당신이 인지하지 못한 실행오류를 제거해 주지만, 그건 일반적이라기 보다 우연에 가깝습니다.
Netflix사의 Chaos Monkey는 이 문제가 얼마나 근본적인지 보여줍니다. 체계적 테스트는 분산된 시스템 속에서 모든 문제를 결코 찾아내지 못하기 때문에 Netflix사는 임의의 중단에 의지해 문제를 확인합니다. Chaos Monkey는 주기적으로 그들의 생산 시스템에 멈춤을 야기할 수 있는, AWS 클라우드의 임의의 서비스를 종료시킵니다. 이러한 중단은 거의 알려지지 않은 체로 진행되는데, 이는 Netflix의 개발자들이 중단에 직면했을 때, 회복력있고 탄탄한 시스템을 만들기위한 배움을 위해서입니다. 하지만 경우에 따라, Chaos Monkey는 다른 어떤 방법으로도 발견하지 못할 문제점을 발견해 내기도 합니다.
모니터링은 테스팅의 다음단계입니다. 테스트가 불가능한 분산된 시스템을 위한 계속적인 실시간 테스팅이 바로 모니터링입니다. Riemann, statsd, Graphite와 같은 모니터링 도구들은 실제 세계의 조건을 당신의 시스템이 어떻게 처리하는지 말해줍니다. 라우터가 멈추거나, 서버가 죽거나, 예상치 못한 부하를 견디지 못할 때 어떻게 될지 당신에게 알리는 툴들이 존재합니다. 하지만 60, 70년대에는 컴퓨터들이 주기적으로 멈췄으며, 시스템 관리자들이 달려가 문제가 뭔지 발견하고 재시작하게끔 했습니다. 우리는 더 이상 중단이 발생하기를 기다리는 사치를 누리지 못하며, 무엇이 잘못되었는지 추측할 뿐입니다. 모니터링 도구들은 문제점이 발견되는 것을 볼 수 있게 하며, 그 이후에 무엇이 발생할지 분석가능케 합니다.
모니터링은 또한 개발자들에게 어떤 기능이 사용되고 있고, 어떤 기능이 사용되지 않고 있는지 이해할 수 있게 하며, 클라우드 서비스로서 배치된 애플리케이션들은 A/B 테스트에 적합합니다. 독자적 소프트웨어를 디자인하는 것 보다, 당신은 Eric Ries가 최소의 실행가능한 제품이라고 부른 것으로 시작할 수 있으며, 그것으로부터 구축까지 가능합니다(최소한의 실행가는한 제품이라는 것은 고객이 진실로 원하는게 무엇이고, 무엇에 반응하는지에 관한 입증된 학습을 제공합니다). 당신은 사용자 요구에 관한 가설에서 시작할 수 있으며, 지속적으로 그러한 요구를 더 만족시키기 위해 어찌해야 하는지 배우고 측정할 수 있습니다. 이는 소프트웨어 디자인 자체가 반복되는 것입니다.
이게 DevOps인가요?
아닙니다. DDS 스택은 고도로 분산된 환경을 위한 도구에 관한 것입니다. 이런 도구들은 종종 DevOps에 관한 동향을 따르는 사람들에 의해 사용됩니다. 하지만, 도구의 본질을 오해하지 않는게 중요합니다. DevOps는 개발자들과 운영자, 더 나아가서는 회사 전체적으로 함께하는 소프트웨어 개발 문화에 관한 것입니다. 아마 이에 관한 가장 최고의 언급은 Velocity의 Jeff Sussna의 기고문인 “공감 : DevOps의 본질(Empathy: The Essence of DevOps)”일 것입니다.
가장 세계적으로, DevOps는 소프트웨어 개발이 비즈니스의 과정이며, 모든 비즈니스들은 소프트웨어 비즈니스이며, 모든 비즈니스는 궁극적으로 사람에 관한 사업이라는 것을 인식하는 것에 관한 것입니다. 이런 도구들을 문화의 변화를 위한 도구들로 오해하는 것은 적화신앙입니다.
Fidelity 자산운용의 CIO는 언젠가 Tim O"Reilly에게 다음과 같이 언급한 적이 있습니다. “우리는 최근의 모든 소프트웨어 개발툴들을 알고 있습니다. 우리가 모르는 것은 그것들을 사용하기 위해 우리 스스로를 어떻게 체계화해야 하는지입니다.” DevOps는 그런 비즈니스적 질문(현대 회사들이 현재 소프트웨어 시스템들이 동작하는 방식의 이점을 살리기 위해 어떻게 조직되어야 하는가?)에 대한 정답의 일부입니다. 하지만 이건 단지 개발과 IT운영을 합치는 문제가 아닙니다. 이는 마케팅, 비즈니스 모델링과 평가, 그리고, 공공분야의 전후 맥락속에서, 정책 결정과 시행을 개발과 결합시키는 것입니다.
왜 지금인가?
웹 소프트웨어처럼 보이지 않는 소프트웨어 조차도 그런 것처럼, 모든 소프트웨어는 웹 소프트웨어입니다. 우리는 수백만 서버에서 운영되는 거대한 애플리케이션에 익숙해 졌습니다. 구글과 페이스북이 우리 의식의 가장 선두에 서 있습니다. 하지만 웹은 놀라운 위치까지 침투해 있습니다. 당신은 아마 웹 소프트웨어로서의 기업용 애플리케이션을 생각해보지 못했겠지만, 기업 내부의 애플리케이션이 웹 인터페이스를 가지는 것이 급격히 일상화 되었습니다. 모든 사내 애플리케이션들이 방화벽 뒷단에 있다는 사실은 무의미해 졌습니다.
비슷하게, 우리는 모바일이 미래이며, 웹은 죽었다는 언급을 여러번 들어왔습니다. 그때 말하는 웹이 파이어폭스나 크롬을 의미한다면 그럴지도 모릅니다. 하지만, 그런 말이 처음 나왔을 때, Nat Torkington은 다음과 같이 언급했습니다. “나는 웹이 죽었다는 말을 들었습니다. 하지만 그 웹을 죽인 모든 애플리케이션이 80포트를 사용하는 HTTP를 사용하는 서비스를 이용합니다.” 비교적 흥미롭지 않은 몇몇 모바일 애플리케이션만이 실제로 독립적으로 운영되는 애플리케이션이지만, 대부분은 데이터 서비스를 이용합니다. 그리고 그런 서비스들은 웹서비스입니다. 그 서비스들은 HTTP를 이용하며, Apache를 이용하며, JSON 형식의 자료들을 사용합니다. 죽었든 살아있든, 웹은 승리해 왔습니다.
하지만 웹 서비스는 승리 그 이상을 성취했습니다. 웹은 모든 애플리케이션이 분산되도록 만들어 버렸습니다. 우리의 모델은 더 이상 마이크로소프트의 Word, 어도비의 InDesign, 혹은 초기의 VMWare가 아닙니다. 우리는 더 이상 수축포장된 박스속의 상품을 언급하지 않으며, 거대하게 배포되는 기업 소프트웨어에 대해서도 언급하지 않으며, 이제 우리는 수천대의 서버로부터 실시간으로 업데이트되고 제공되는 Gmail이나 Netflix와 같은 제품에 대해 이야기합니다. 이러한 제품들은 개발자들의 통제 밖에 있는 서비스들에 의존적이며, 이것들은 전 대륙의 수많은 데이터 센터들에 흩어진 서버들에서 운영되며, 아찔하게 다양한 플랫폼 위에서 동작합니다.
소프트웨어 개발의 미래는 분산된 시스템들과 관계가 있으며, 그것이 수반할 복잡성과 불확실성과 연계되어 있습니다. 우리는 분산된 시스템들을 다룰수 있게 만들기위해 필요한 도구들을 개발하기 시작했습니다. 당신이 소프트웨어 개발팀이나 운영팀의 일원이라면, 이것들에 관해 알 필요가 있습니다.
*****
Mike Loukides (OReilly의 컨텐츠 전략 담당부서에서 일하며, 기술적 주제들에 관한 많은 저서를 집필해왔다. 특히 프로그래밍 언어, 유닉스, 리눅스, 시스템, 네트워크 관리에 관심을 두고 있으며 최근에는 데이터 분석, R, 메스메티카, Octave같은 언어에도 관심을 두고 있다.)
저자 : Mike Loukides
역자 : 최종훈
원문 : Beyond the stack
분산된 개발자들의 스택(DDS)에 속한 도구들이 매우 분산된 환경속에서 개발을 관리 가능하게 만듭니다.
지난 20년간 소프트웨어 개발의 외향은 매우 급격히 변해왔습니다. 우리는 인터넷, 웹, 가상화, 그리고 클라우드 컴퓨팅에 있어서 매우 많은 변화들을 목도해 왔습니다. 이 모든 변화들은 하나의 본질적인 새로운 현실을 가리킵니다. 바로 모든 컴퓨팅이 분산 컴퓨팅이 되었다는 점입니다. 홀로 독자적으로 운영되는 애플리케이션의 시대는 사라졌고, 한 대의 컴퓨터에서 운영되는 애플리케이션은 거의 생각할 수도 없게 되었습니다. 분산은 기본이 되었습니다. 게다가 애플리케이션이 AWS(아마존 웹 서비스)에서 동작하든, 사설 클라우드에서 동작하든, 심지어 하나의 데스크탑이나 모바일에서 동작하든, 그 애플리케이션은 그 개발자의 통제 밖에 있는 다른 시스템들과 서비스들의 동작에 의존하게 되었습니다.
지난 몇 년동안, 광범위하게 분산된 애플리케이션들의 개발을 돕기 위해 새로운 도구모음들이 발전해왔습니다. 우리는 이러한 새로운 도구모음을 DDS(Distributed Developer’s Stack)라고 부릅니다. 이것은 전통적인 서버들, 프레임워크들, 운영체들과는 관계가 거의 없습니다. 이는 LAMP(리눅스, 아파치, Mysql, php)와 같은 전통적인 스택을 대체하는 것은 아니지만, 매우 분산된 환경 속에서 개발을 관리가능하게 만들어주는 도구들의 집합입니다.
DDS는 전통적인 의미의 하나의 스택이라기 보다 그 이상의 의미를 지닙니다. 이것은 하나로 규정된 것은 아닙니다. 우리는 당신이 AWS나 OpenStack을 사용하는지, 혹은 GIt이나 Mercurial을 사용하는지에 관심이 없습니다. 우리는 당신이 클라우드를 염두해 두고 개발을 한다는데 관심이 있고, 당신이 분산된 버전 통제 시스템을 사용한다는 데 관심이 있습니다.
플렛폼으로서의 클라우드
AWS는 소프트웨어 개발에 대변혁을 가져왔습니다. 스타트업에 종사하는 이들은 그들이 필요한 만큼의 많은 서버를 그들의 요구사항에 맞게끔 저렴한 비용으로 쉽게 할당하는게 가능해졌습니다. 이미 규모를 갖춘 회사의 개발자들은 전통적인 IT기반의 조달방식을 간단히 할 수 있게 되었고, 신용카드만 있으면 금방 서버룸을 구성할 수 있게 되었습니다.
심지어 AWS나 다른 클라우드 기반 도구를 사용하지 않는 애플리케이션도 분산되어 있습니다. 가장 단순한 웹페이지만 하더라도 서버, 웹브라우저, 호스트 이름 변환을 위한 DNS 서버, 신호를 전달하는 수많은 스위치와 라우터들이 필요합니다. 조금만 더 복잡한 웹 애플리케이션을 생각해 보면, 인증서버, 데이터베이스, 실시간 데이터를 위한 웹 서비스들에 의존하고 있습니다. 이 모든 것이 가장 단순한 애플리케이션을 분산된 시스템에 대입해보면 간단히 확인가능한 사실입니다. 정전, 라우터 멈춤, 혹은 당신이 들어보기 힘든, 어떤 도시의 케이블 불량까지 당신의 애플리케이션을 멈추게 할 수 있습니다.
저는 클라우드로 인해 하늘이 무너질거라고 주장하는게 아닙니다. 하지만 우리가 배치하고 운영하는 시스템들에게, 이런 클라우드 기반이 무엇을 의미하는지 이해하는게 매우 중요합니다. 한 애플리케이션에 연관된 시스템들의 수가 증가할수록 고장의 유형도 급격히 증가합니다. 10대의 서버들에서 운영되는 애플리케이션은 1대의 서버에서 운영될 때 보다 10배 복잡한게 아니라 1,000배는 더 복잡합니다.
클라우드는 이제 일상화되었습니다. 사설이든 공용이든, AWS, OpenStack, Microsoft Azure, Google Compute Engine을 사용하든, 애플리케이션들은 가까운 미래에 클라우드에서 동작할 것입니다. 우리는 이에 잘 대처해야만 합니다.
분산된 프로세스로서의 개발
수년간 소스 관리에 있어서 우리는 많은 진보를 이루었지만, 최근까지 소프트웨어 개발 자체가 분산되었다는 사실에 우리는 결코 대처하지 못했습니다. 우리의 개발 모델은 한명의 프로그래머가 고립된 머신에서 운영되는 단일한 프로그램들을 만든다는 것에 기초해왔습니다. 우리는 이런 프로세스들을 더욱 쉽게하기 위한 도구들, 소스 관리 도구들과 같은 것들은 만들어 왔지만, 이 어떤 것도 개발 프로젝트 자체가 팀을 필요로 한다는 것을 진지하게 인지하지 못했습니다. 개발자들은 그들의 개발 프로젝트에 있어서 그들이 속한 부분에서만 일했고, 그 이후에 모든 분리된 조각들을 모으기 위한 광범위한 통합의 단계에서 이미 엉망이된 상태를 해결하기 위한 시도를 해왔습니다.
버전 통제 시스템인 Git은 개발자들로 구성된 하나의 팀은 근본적으로 분산된 시스템이며, 소프트웨어 개발의 자연적 프로세스는 가지나 분기점을 만들며 퍼져나가는 것이며, 이후에 이 가지들이 하나의 핵심 저장소에서 합쳐진다는 것을 인지했습니다. 모든 개발자들은 자신에게 익숙한 코드에 기반하고 있으며, 핵심으로부터 분기했습니다. 그들이 그들의 기반에서 준비가 끝나면, 그들은 그들의 코드 변화를 통합하여 다시 핵심으로 융합시킵니다. 이 시점에서 그 팀의 다른 멤버들은 그들의 코드기반을 업데이트하기 위해, 다른 이들로 부터의 변화를 확인할 수 있습니다. 각 개발자들의 업무는 다른 이의 업무로부터 분리되어 있습니다. 팀원들은 비동기적으로 일할 수 있고, 공간 뿐만 아니라 시간도 분산되어 있습니다.
Jenkins나 그 이전 버전인 Hudson과 같은 지속적 통합 도구는 페러다임 변화를 인지한 첫 도구들입니다. 지속적 통합은 개발이 분산되어 있을 때, 모든 개발자들의 업무를 통합하는 것이 일관적 작업이어야 한다는 현실을 반영했습니다. 이것은 최종 버전이 발표될 때 까지 연기될 수 없었습니다. 조금이라도 앞으로 나아가 프로젝트가 항상 구축되고 운영되는 것이 중요했습니다.
분산된 개발자들의 팀의 통합을 가능케 하는 것이 결코 간단한 문제는 아닙니다. 독자적으로 움직이는 프로그래머에 대한 신화를 유지하기 위해 노력하는 것보다, 분산된 개발의 속성을 인지한 툴들을 더욱 다루기 쉽게 하는게 문제입니다.
코드로서의 기반체계
Velocity 컨퍼런스에서 기반체계로서의 코드(Infrastructure as code)가 슬로건이 되었습니다. 이는 무슨 의미일까요?
클라우드 컴퓨팅은 개발자들이 메모리를 할당하듯 서버를 쉽게 할당하는게 가능하게 만들었습니다. 하지만 90년대 시스템 관리자가 잘 알고있듯, 실제 힘든 점은 서버를 박스에서 꺼내는 것이 아니라, 올바르게 설치하고, 설정하는 것입니다. 그리고 그건 당신이 콘솔 화면 바로 앞에 있든, 수마일 떨어진 곳에서 원격으로 접속해 있든 고통스러운 일입니다. 당신이 하나의 서버나 작은 규모의 클러스터구조에서 전 세계의 분산된 수백개의 AWS 노드로 구조를 증강하려 한다면 그 고통은 더 큽니다.
지난 10년간 우린 이 문제를 해결하기 위한 도구들의 급증을 지켜봤습니다. Chef, Puppet, CFEngine, Ansible, 그리고 그 비슷한 도구들이 시스템 설정들을 스크립트로 담아냈고, 물리적이든 가상화든, 컴퓨터 설정을 자동화했습니다. 기계를 동적으로 할당하고, 설정을 자동화시키는 능력은 컴퓨팅 자원과 우리의 관계를 변화시켰습니다. 이전에는 리부팅, 재설치, 디스크 교체 등과 같은 수단을 써서 무엇인가 고장났을 때 당신이 고쳐야만 했습니다. 이는 우리의 데스크탑이나 휴대폰에 있어서는 여전한 사실이지만, 우리의 개발환경기반에서는 더 이상 사실이 아닙니다. AWS 서버의 뭔가가 잘못 동작하면, 당신은 그것을 지우고 다른 것을 시작시키면 그뿐입니다. 이건 쉽고, 간단하고, 빠르고, 저렴합니다. 최소한의 운영자만으로 수천, 수만의 서버를 관리할 수 있습니다. 적절한 모니터링 도구를 이용해 고장난 서버를 확인하고, 중지시키고, 지우고, 새로운 것을 할당하는 작업을 자동화 할 수 있습니다.
설정이 코드라면, 설정은 소프트웨어 개발의 일부로 고려되어야만 합니다. 당신의 노트북에서 개발된 소프트웨어가 운영자에 의해 배치되어야 할 곳에 배치되어 설치되리라 기대하는 것은 충분하지 않습니다. 개발과 배치는 분리된 프로세스가 아니라 같은 업무의 다른면일 뿐입니다.
배치로서의 컨테이너화
컨테이너는 스택에 가장 최근에 추가된 것입니다. 컨테이너는 가상화에서 한 단계 더 나아간 것입니다(Docker 같은 시스템은 당신의 소프트웨어를 배치하기 위해 꼭 필요한 패키지를 알맞게 설치하게끔 해준다는 것, 그 이상도 이하도 아닙니다). 이 패키지는 수십년간 화물 운송에 있어 혁명을 가져온 전통적 선적 컨테이너와 비슷합니다. 이것은 운반 선적에 조심히 피아노, 오일을 담은 통과 같은 것들을 적재하는 것 보다, 적재하기에 딱 맞아 떨어지는 표준 컨테이너에 쌓아 올리는 것이며, 이는 화물을 싣고 내리는 작업을 쉽게했고, 선박 뿐만 아니라, 트럭, 기차로 운반가능하며, 목적지에 도착할 때 까지 오픈되지도 않습니다.
컨테이너는 항상 같은 방식으로 동작하기 때문에 특별합니다. 당신은 Docker 컨테이너에 당신의 애플리케이션을 묶어서 당신의 노트북 컴퓨터에서 실행시킬수도 있고, Amazon으로 전송해 AWS에서 실행시킬 수 있고, OpenStack 같은 클라우드에서 실행도 가능합니다. 만약 아직도 사설 서버룸을 갖추고 있다면, 당신의 서버에서도 실행가능합니다. 컨테이너에는 코드를 올바르게 실행시키기 위해 필요한 모든 것이 포함되어 있습니다. 당신은 OS 업그레이드, 새로운 버전의 Apache, nginx 설치, 더 나은 버전의 라이브러리로의 교체와 같은 뜻밖의 불쾌함을 가져올 어떤 걱정도 할 필요가 없습니다. 물론 당신은 이제 당신의 컨테이너가 최신의 OS와 라이브러리로 패치되어 있게끔 유지할 책임이 있습니다. 당신은 이제 시스템 관리자에게 의존할 수 없습니다. 하지만 당신은 그 프로세스를 관리하게 되었습니다. 당신의 소프트웨어는 항상 당신이 지정한 바로 그 환경에서 운영될 것입니다. 그리고 분산된 환경 속에서 소프트웨어가 멈출 수 있는 많은 상황을 고려해 볼 때, 실패한 소스 한 부분만을 제거한다는 것은 좋은 생각입니다.
테스팅으로서의 모니터링
거대하게 분산된 시스템속에서, 소프트웨어는 당신이 테스트하지 못한 많은 이유로 멈출 수 있습니다. 테스트 주도 개발은 라우터가 멈췄을 때 당신의 애플리케이션이 어떻게 응답할지를 말해주지 않습니다. 어떤 합격판정테스트도 당신의 예측보다 1,000배 많은 부하에서 당신의 애플리케이션이 어떻게 동작할지 말해주지 않습니다. 테스트는 종종 당신이 인지하지 못한 실행오류를 제거해 주지만, 그건 일반적이라기 보다 우연에 가깝습니다.
Netflix사의 Chaos Monkey는 이 문제가 얼마나 근본적인지 보여줍니다. 체계적 테스트는 분산된 시스템 속에서 모든 문제를 결코 찾아내지 못하기 때문에 Netflix사는 임의의 중단에 의지해 문제를 확인합니다. Chaos Monkey는 주기적으로 그들의 생산 시스템에 멈춤을 야기할 수 있는, AWS 클라우드의 임의의 서비스를 종료시킵니다. 이러한 중단은 거의 알려지지 않은 체로 진행되는데, 이는 Netflix의 개발자들이 중단에 직면했을 때, 회복력있고 탄탄한 시스템을 만들기위한 배움을 위해서입니다. 하지만 경우에 따라, Chaos Monkey는 다른 어떤 방법으로도 발견하지 못할 문제점을 발견해 내기도 합니다.
모니터링은 테스팅의 다음단계입니다. 테스트가 불가능한 분산된 시스템을 위한 계속적인 실시간 테스팅이 바로 모니터링입니다. Riemann, statsd, Graphite와 같은 모니터링 도구들은 실제 세계의 조건을 당신의 시스템이 어떻게 처리하는지 말해줍니다. 라우터가 멈추거나, 서버가 죽거나, 예상치 못한 부하를 견디지 못할 때 어떻게 될지 당신에게 알리는 툴들이 존재합니다. 하지만 60, 70년대에는 컴퓨터들이 주기적으로 멈췄으며, 시스템 관리자들이 달려가 문제가 뭔지 발견하고 재시작하게끔 했습니다. 우리는 더 이상 중단이 발생하기를 기다리는 사치를 누리지 못하며, 무엇이 잘못되었는지 추측할 뿐입니다. 모니터링 도구들은 문제점이 발견되는 것을 볼 수 있게 하며, 그 이후에 무엇이 발생할지 분석가능케 합니다.
모니터링은 또한 개발자들에게 어떤 기능이 사용되고 있고, 어떤 기능이 사용되지 않고 있는지 이해할 수 있게 하며, 클라우드 서비스로서 배치된 애플리케이션들은 A/B 테스트에 적합합니다. 독자적 소프트웨어를 디자인하는 것 보다, 당신은 Eric Ries가 최소의 실행가능한 제품이라고 부른 것으로 시작할 수 있으며, 그것으로부터 구축까지 가능합니다(최소한의 실행가는한 제품이라는 것은 고객이 진실로 원하는게 무엇이고, 무엇에 반응하는지에 관한 입증된 학습을 제공합니다). 당신은 사용자 요구에 관한 가설에서 시작할 수 있으며, 지속적으로 그러한 요구를 더 만족시키기 위해 어찌해야 하는지 배우고 측정할 수 있습니다. 이는 소프트웨어 디자인 자체가 반복되는 것입니다.
이게 DevOps인가요?
아닙니다. DDS 스택은 고도로 분산된 환경을 위한 도구에 관한 것입니다. 이런 도구들은 종종 DevOps에 관한 동향을 따르는 사람들에 의해 사용됩니다. 하지만, 도구의 본질을 오해하지 않는게 중요합니다. DevOps는 개발자들과 운영자, 더 나아가서는 회사 전체적으로 함께하는 소프트웨어 개발 문화에 관한 것입니다. 아마 이에 관한 가장 최고의 언급은 Velocity의 Jeff Sussna의 기고문인 “공감 : DevOps의 본질(Empathy: The Essence of DevOps)”일 것입니다.
가장 세계적으로, DevOps는 소프트웨어 개발이 비즈니스의 과정이며, 모든 비즈니스들은 소프트웨어 비즈니스이며, 모든 비즈니스는 궁극적으로 사람에 관한 사업이라는 것을 인식하는 것에 관한 것입니다. 이런 도구들을 문화의 변화를 위한 도구들로 오해하는 것은 적화신앙입니다.
Fidelity 자산운용의 CIO는 언젠가 Tim O"Reilly에게 다음과 같이 언급한 적이 있습니다. “우리는 최근의 모든 소프트웨어 개발툴들을 알고 있습니다. 우리가 모르는 것은 그것들을 사용하기 위해 우리 스스로를 어떻게 체계화해야 하는지입니다.” DevOps는 그런 비즈니스적 질문(현대 회사들이 현재 소프트웨어 시스템들이 동작하는 방식의 이점을 살리기 위해 어떻게 조직되어야 하는가?)에 대한 정답의 일부입니다. 하지만 이건 단지 개발과 IT운영을 합치는 문제가 아닙니다. 이는 마케팅, 비즈니스 모델링과 평가, 그리고, 공공분야의 전후 맥락속에서, 정책 결정과 시행을 개발과 결합시키는 것입니다.
왜 지금인가?
웹 소프트웨어처럼 보이지 않는 소프트웨어 조차도 그런 것처럼, 모든 소프트웨어는 웹 소프트웨어입니다. 우리는 수백만 서버에서 운영되는 거대한 애플리케이션에 익숙해 졌습니다. 구글과 페이스북이 우리 의식의 가장 선두에 서 있습니다. 하지만 웹은 놀라운 위치까지 침투해 있습니다. 당신은 아마 웹 소프트웨어로서의 기업용 애플리케이션을 생각해보지 못했겠지만, 기업 내부의 애플리케이션이 웹 인터페이스를 가지는 것이 급격히 일상화 되었습니다. 모든 사내 애플리케이션들이 방화벽 뒷단에 있다는 사실은 무의미해 졌습니다.
비슷하게, 우리는 모바일이 미래이며, 웹은 죽었다는 언급을 여러번 들어왔습니다. 그때 말하는 웹이 파이어폭스나 크롬을 의미한다면 그럴지도 모릅니다. 하지만, 그런 말이 처음 나왔을 때, Nat Torkington은 다음과 같이 언급했습니다. “나는 웹이 죽었다는 말을 들었습니다. 하지만 그 웹을 죽인 모든 애플리케이션이 80포트를 사용하는 HTTP를 사용하는 서비스를 이용합니다.” 비교적 흥미롭지 않은 몇몇 모바일 애플리케이션만이 실제로 독립적으로 운영되는 애플리케이션이지만, 대부분은 데이터 서비스를 이용합니다. 그리고 그런 서비스들은 웹서비스입니다. 그 서비스들은 HTTP를 이용하며, Apache를 이용하며, JSON 형식의 자료들을 사용합니다. 죽었든 살아있든, 웹은 승리해 왔습니다.
하지만 웹 서비스는 승리 그 이상을 성취했습니다. 웹은 모든 애플리케이션이 분산되도록 만들어 버렸습니다. 우리의 모델은 더 이상 마이크로소프트의 Word, 어도비의 InDesign, 혹은 초기의 VMWare가 아닙니다. 우리는 더 이상 수축포장된 박스속의 상품을 언급하지 않으며, 거대하게 배포되는 기업 소프트웨어에 대해서도 언급하지 않으며, 이제 우리는 수천대의 서버로부터 실시간으로 업데이트되고 제공되는 Gmail이나 Netflix와 같은 제품에 대해 이야기합니다. 이러한 제품들은 개발자들의 통제 밖에 있는 서비스들에 의존적이며, 이것들은 전 대륙의 수많은 데이터 센터들에 흩어진 서버들에서 운영되며, 아찔하게 다양한 플랫폼 위에서 동작합니다.
소프트웨어 개발의 미래는 분산된 시스템들과 관계가 있으며, 그것이 수반할 복잡성과 불확실성과 연계되어 있습니다. 우리는 분산된 시스템들을 다룰수 있게 만들기위해 필요한 도구들을 개발하기 시작했습니다. 당신이 소프트웨어 개발팀이나 운영팀의 일원이라면, 이것들에 관해 알 필요가 있습니다.
*****
Mike Loukides (OReilly의 컨텐츠 전략 담당부서에서 일하며, 기술적 주제들에 관한 많은 저서를 집필해왔다. 특히 프로그래밍 언어, 유닉스, 리눅스, 시스템, 네트워크 관리에 관심을 두고 있으며 최근에는 데이터 분석, R, 메스메티카, Octave같은 언어에도 관심을 두고 있다.)
TAG :
이전 글 : 자바 8에서 새로워진 점 : 람다
최신 콘텐츠