DevOps와 스노우플레이크에 대하여

요즘 IT 업계에서는 DevOps 이야기를 하지 않고서는 대화하기 어렵습니다. DevOps는 클라우드에 대한 논의를 이어받아 업계에서 가장 뜨거운 새로운 화두가 되었고, 사람들의 이야기를 들으면 전통적인 시스템 관리가 이미 죽어서 묻힌 것처럼 생각할 수도 있습니다.

먼저 우리가 DevOps라고 말하는 것이 무엇을 의미하는지 이야기해야 합니다. 클라우드처럼 오래된 용어가 종종 이미 존재하는 것과 다른 의미로 또는 잘해야 관련된 것으로 사용되고 있기 때문에 혼란스러울 수 있습니다. 전통적인 DevOps는 개발자와 운영 역할의 통합이었습니다. 1960년대부터 1990년대까지 이것이 시스템을 운영하는 표준 방식이었습니다. 이 세계에서 소프트웨어를 작성하는 사람들이 일반적으로 배포하고 유지 관리하는 사람들이기도 했습니다. 따라서 “개발자”와 “운영”의 통합이며, 운영은 시스템 관리자 역할의 준표준 용어입니다. 이 역할들은 1990년대와 2000년대에 “IT 부서”가 등장하기 전까지는 일반적으로 분리되지 않았습니다. 그 이후로, 두 역할의 통합으로 돌아가는 것이 주로 현대의 호스팅된 웹 애플리케이션 상황에서 두 역할이 함께 큰 가치로 운영될 수 있는 방식 때문에 다시 인기를 끌기 시작했습니다.

오늘날 DevOps에 대해 자주 이야기하는 것은 개발자와 운영 인력의 엄격한 통합이 아니라 클라우드 아키텍처의 자연스러운 확장으로서 애플리케이션 자체가 아닌 코드로 애플리케이션 인프라를 정의하는 데 훨씬 더 높은 초점을 맞추는 운영 인력의 수정입니다. 처음에는 다소 혼란스러울 수 있습니다. 중요한 것은 전통적인 DevOps는 오늘날 일반적으로 발생하는 것이 아니라 개발자는 개발자로 남아 있고 운영은 운영으로 남아 있지만 운영이 개발자가 제공한 코드를 실행하는 서버 관리에 계속 집중하는 새로운 “코드 중심” 역할로 진화한 새로운 “가짜” DevOps라는 것입니다.

오늘날 중요한 것은 시스템 관리자의 역할이 두 가지 관련되지만 상당히 다른 역할로 나뉘기 시작했다는 것입니다. 그 중 하나는 오늘날 업계 대부분에서 부적절하게 DevOps라고 불리고 있습니다(업계의 대부분이 DevOps가 새롭고 참신한 것이 아니라 규범이었을 때를 기억하기에는 너무 젊습니다). 저는 여기서 시스템 관리자 역할의 이 두 가지 측면을 DevOps와 스노우플레이크 접근 방식이라고 부릅니다.

저는 각 개별 서버를 “고유한 스노우플레이크”로 볼 수 있기 때문에 시스템의 전통적인 아키텍처를 가리키기 위해 스노우플레이크라는 용어를 사용합니다. 동일하게 유지하는 방식으로 관리되지 않는 한 모두 다릅니다. 이것이 모두 고유해야 한다는 의미가 아니라 단지 그럴 가능성을 보유한다는 것입니다. 전통적인 환경에서 시스템 관리자는 각 서버에 개별적으로 로그인하여 작업합니다. 관리 작업을 용이하게 하기 위한 일정량의 스크립팅이 일반적이지만 핵심적으로 역할은 개별 시스템에서 많은 시간을 작업하는 것을 포함합니다.

스노우플레이크 아키텍처의 관리를 쉽게 하는 것은 종종 합리적인 방법으로 시스템 간의 차이를 최소화하려는 시도를 포함했습니다. 이것은 일반적으로 모든 서버 설치를 다른 OS나 버전으로 허용하는 대신 단일 표준 운영 체제와 버전(Windows 2012 R2 또는 Red Hat Enterprise Linux 7)을 선택하는 것으로 시작됩니다. 이 표준화는 기본적으로 보일 수 있지만 오늘날에도 많은 업체들이 이 표준화가 부족합니다.

다음 단계는 일반적으로 표준 배포 방법론이나 골드 마스터 이미지를 생성하여 모든 시스템을 만드는 데 사용하여 기본 운영 체제와 모든 기본 패키지(시스템 커스터마이제이션, 모니터링 패키지, 보안 패키지, 인증 구성 및 유사한 수정을 포함하는 경우가 많음)가 표준화되고 균일하게 배포되도록 하는 것입니다. 이것은 시스템 간의 차이를 최소화하기 위한 공통 시작점을 제공합니다. 하지만 기술적으로 이것들은 표준 시작점만 보장하며 시간이 지남에 따라 구성의 차이가 예상되어야 합니다.

이러한 단계를 넘어, 스노우플레이크 환경은 일반적으로 시간이 지남에 따라 시스템 간의 표준화를 유지하기 위해 맞춤형 관리 스크립트나 관리 도구를 사용합니다. 시스템 간에 더 많은 공통점이 존재할수록 유지 관리 및 문제 해결이 더 쉬워지고 관리 인력에게 필요한 지식이 줄어듭니다. 더 많은 표준화는 더 적은 놀람, 더 적은 미지수, 훨씬 나은 테스트 기능을 의미합니다.

좋은 관행과 툴링을 갖춘 단일 시스템 관리자 환경에서 스노우플레이크 환경은 높은 수준의 표준화를 취할 수 있습니다. 하지만 많은 시스템 관리자가 있는 환경, 특히 많은 지역에서 24시간 지원되고 많은 수의 시스템이 있는 환경에서는 매우 성실한 관행을 갖추더라도 표준화가 매우 어려워질 수 있습니다. 그것도 다른 역할을 수행하는 시스템에 다른 패키지와 아마도 다른 패키지 버전이 필요하다는 명백한 문제를 다루기 전에 말이죠.

DevOps 접근 방식은 클라우드 아키텍처 모델에서 유기적으로 성장합니다. 클라우드 아키텍처는 프로그래밍 방식의 인터페이스나 API를 통해 제어되는 자동으로 생성되고 자동으로 소멸되는 광범위하게 동일한 시스템(적어도 그룹 내에서)을 중심으로 설계됩니다. 이 모델은 수동적인 시스템 관리자의 노력보다 관리 시스템을 통해 중앙에서 제어되기에 매우 적합합니다. 이 모델에서 수동 관리는 사실상 불가능하고 완전히 비실용적입니다. 개별 시스템은 스노우플레이크 모델처럼 고유하지 않으며 어떤 차이도 심각한 문제를 일으킵니다.

클라우드 아키텍처 세계에서 나온 아이디어는 시스템 아키텍처가 서버 자체가 아닌 중앙에서 “코드로” 정의되어야 한다는 것입니다. 처음에는 혼란스럽게 들리지만 더 깊이 살펴보면 많은 의미가 있습니다. 이 모델을 지원하기 위해 아직 정말 표준화된 이름을 갖지 못했지만 종종 시스템 자동화 도구, DevOps 프레임워크, IT 자동화 도구 또는 단순히 “인프라스트럭처 애즈 코드” 도구로 불리는 새로운 유형의 시스템 관리 도구가 등장하기 시작했습니다. 이 영역의 일반적인 툴셋으로는 Puppet, Chef, CFEngine, SaltStack이 있습니다.

이러한 자동화 툴셋 뒤의 아이디어는 중앙 서비스가 모든 시스템을 관리하고 제어하는 데 사용된다는 것입니다. 이 중앙 권한은 시스템이 어떻게 보이고 어떻게 동작해야 하는지에 대한 코드 기반 설명을 통해 개별 서버를 관리합니다. Chef 세계에서는 이것들이 귀엽게 “레시피”라고 불리지만 비유는 잘 작동합니다. 각 시스템의 코드에는 설치해야 할 패키지와 패키지 버전의 목록, 수정해야 할 시스템 구성, 박스에 복사할 파일과 같은 정보가 포함될 수 있습니다. 많은 경우 이러한 배포나 수정에 대한 결정은 잠재적으로 복잡한 로직을 통해 처리되므로 마크업이나 템플릿과 같이 더 단순한 것보다 실제 코드가 필요합니다. 그런 다음 시스템은 역할별로 그룹화되어 그룹으로 관리됩니다. “웹 서버” 역할은 일련의 시스템에 Apache와 PHP를 설치하고 메모리가 매우 적게 스왑하도록 구성하도록 할 수 있습니다. “SQL Server” 역할은 MS SQL Server와 해당 애플리케이션에만 사용되는 특수 백업 도구를 설치하고 SQL Server 머신 풀에 원하는 대로 메모리가 튜닝되도록 구성할 수 있습니다. 이것들은 단지 예입니다. 일반적으로 조직은 매우 많은 역할을 가지고 있으며, 일부는 “웹 서버”처럼 일반적이고 다른 일부는 매우 특정 애플리케이션을 지원하기 위해 훨씬 더 구체적입니다. 역할은 일반적으로 레이어링될 수 있으므로 시스템은 “웹 서버”이면서 “자바 서버”일 수 있어 두 가지 필요사항을 모두 충족합니다.

이러한 표준 정의는 한 역할이나 다른 역할에 속하도록 지정된 시스템이 자동으로 “자체적으로 구축”될 수 있음을 의미합니다. 새 시스템은 관리자가 요청하거나 용량 모니터링 시스템이 역할에 추가 용량이 필요하다고 결정하여 어떠한 인간 개입도 없이 자동으로 새 서버 인스턴스를 생성할 수 있습니다. 시스템이 인간에 의해 또는 자동으로 요청되는 시점에서 역할이 지정되고 자동화 프레임워크를 통해 시스템은 완전히 구성되고 최신 상태의 “노드”로 변환됩니다. 인간 시스템 관리자의 개입이 필요하지 않습니다. 프로세스는 빠르고 간단하며 가장 중요하게는 완전히 반복 가능합니다.

코드로 시스템을 정의하는 것은 명백하지 않은 결과를 가져옵니다. 하나는 완전한 시스템의 백업이 더 이상 필요하지 않다는 것입니다. 최소한의 노력으로 거의 즉시 재생성할 수 있는 시스템을 왜 백업해야 할까요? 데이터베이스 시스템의 로컬 데이터는 백업해야 하지만 전체 시스템이 아닌 데이터베이스 데이터만 백업하면 됩니다. 이것은 백업 인프라의 부담을 크게 줄이고 복원 프로세스를 더 빠르고 신뢰할 수 있게 만들 수 있습니다.

코드로 이미 정의된 시스템에 필요한 문서화의 양은 매우 최소화됩니다. 스노우플레이크 환경에서 시스템 관리자는 모든 호스트에 특정한 문서를 수동으로 유지 관리해야 합니다. 이것은 매우 시간이 많이 소요되고 오류가 발생하기 쉽습니다. 중앙 코드를 통해 정의된 시스템은 거의 또는 전혀 문서화가 필요하지 않으며 문서화는 개별 노드 수준이 아닌 그룹 수준에서 처리될 수 있습니다.

코드로 정의된 시스템을 테스트하는 것도 쉽습니다. 코드를 통해 시스템을 생성하고 테스트한 다음 해당 정의를 프로덕션으로 이동할 때 프로덕션 시스템이 테스트에서 생성된 것과 정확히 동일하게 반복적으로 생성될 것이라는 것을 알 수 있습니다. 스노우플레이크 환경에서는 이를 시도하는 테스트 관행이 일반적이지만 수동적 노력을 통해 수행되며 부주의하고 정확하게 반복 가능하지 않으며 정치로 인해 실제로 반복성을 추구하는 것보다 반복성을 모방하는 것이 더 빠르다고 지시하는 경우가 매우 흔합니다. 코드로 정의된 시스템은 이러한 문제를 우회하여 테스트를 훨씬 더 가치 있게 만듭니다.

각 역할 내에 존재할 노드 수를 정의하는 것 외에도 시스템은 처음부터 자동으로 전체 아키텍처를 재프로비저닝할 수 있습니다. 재해 후 재구축이나 보조 사이트 구축을 매우 빠르고 쉽게 수행할 수 있습니다. 또한 Amazon, Microsoft, IBM, Rackspace 및 기타 업체의 클라우드를 포함하여 로컬 호스팅 시스템과 원격 호스팅 시스템 간 이동이 매우 쉽습니다.

물론 DevOps 세계에서는 클라우드 아키텍처를 사용하여 가장 극단적인 수준의 자동화를 가능하게 하는 데 큰 가치가 있지만 이러한 유형의 도구를 활용하기 위해 클라우드 아키텍처가 반드시 필요한 것은 아닙니다. 그리고 물론 코드로 정의된 아키텍처를 부분적으로 사용하면서 하이브리드 접근 방식으로 수동 관리를 구현할 수도 있지만 이것은 개별 시스템에는 거의 권장되지 않습니다. 두 가지 접근 방식이 모두 요구될 때 하나는 스노우플레이크로 관리되고 다른 하나는 DevOps로 관리되는 두 가지 환경을 갖추는 것이 일반적으로 훨씬 낫습니다. 이것이 훨씬 더 나은 하이브리드화를 만듭니다. 저는 이것이 수만 개의 각각 매우 고유한 “스노우플레이크” 서버가 있는 엔터프라이즈 환경에서 두 가지 가능한 구성 중 하나를 사용하여 모든 노드가 동일하고 교환 가능해야 하기 때문에 DevOps 방식으로 관리되는 수만 개의 노드로 이루어진 전용 환경과 함께 매우 효과적으로 작동하는 것을 보았습니다. 하이브리드화는 매우 효과적이었습니다.

하지만 DevOps 접근 방식에도 주요 주의사항이 있습니다. 이 방식으로 시스템을 관리하는 데 필요한 기술 셋은 최소한 모든 전통적인 시스템 관리 지식이 여전히 필요하고 거기에 더해 일반적으로 Python과 Ruby 같은 현대 언어의 견고한 프로그래밍 지식과 해당 프레임워크에 대한 지식이 필요하기 때문에 전통적인 시스템 관리보다 훨씬 더 큽니다. 이 확장된 지식 기반 요구사항은 DevOps 실무자들이 드물 뿐만 아니라 비용도 많이 든다는 것을 의미합니다. 또한 대학 교육이 이미 시스템 관리자나 개발자를 전문적인 세계에서 일할 준비를 시키는 데 크게 부족한데 이제 DevOps 모델 하에서 일할 졸업생을 준비시키는 데 더욱 부족하다는 것을 의미합니다.

이 두 진영에서 일하는 시스템 관리자들은 모든 시스템이 자신의 틀에 맞아야 한다고 보는 경향이 있습니다. 새로운 DevOps 실무자들은 스노우플레이크 시스템이 레거시이고 업데이트가 필요하다고 믿는 경우가 많습니다. 스노우플레이크(전통적인) 관리자들은 “인프라스트럭처 애즈 코드” 운동이 어리석고, 불필요한 오버헤드가 가득하고, 지나치게 복잡하며, 매우 틈새적이라고 봅니다.

현실은 두 가지 접근 방식 모두 엄청난 장점이 있으며 둘 다 매우 실행 가능한 상태로 유지될 것이라는 것입니다. 둘 다 매우 다른 워크로드에 적합하며 대규모 조직에서는 어떤 형태의 하이브리드화를 통해 두 가지 모두를 갖추는 것이 일반적일 것으로 생각합니다. 일반적으로 서버 수가 매우 적고, 클라우드 아키텍처를 정당화할 스케일링 레버리지가 없으며, 시스템 간 높은 불균형이 있는 SMB 시장에서는 DevOps가 필요한 오버헤드와 추가 기술을 획득하는 것이 비현실적이거나 심지어 불가능하기 때문에 거의 무기한으로 규범 밖에 머물 것으로 예상합니다. 대규모 조직은 워크로드를 살펴봐야 합니다. 많은 전통적인 워크로드와 전통적인 소프트웨어의 많은 부분이 DevOps 접근 방식, 특히 클라우드 자동화에 잘 맞지 않으며 하이브리드화를 요구하거나 DevOps 모델을 정당화하기 불가능하게 만드는 시스템별로 비현실적으로 높은 수준의 코딩이 필요합니다. 하지만 웹 아키텍처를 기반으로 구축되거나 수평적으로 매우 잘 확장될 수 있는 워크로드는 대규모에서 DevOps 모델로부터 크게 혜택을 받을 것입니다. 이것은 대규모 엔터프라이즈 회사나 외부 소비를 위해 호스팅된 애플리케이션을 생산하는 소규모 회사에 적용될 수 있습니다.

이러한 접근 방식의 차이는 예를 들어 미국에서 미국 대부분은 스노우플레이크 관리 모델에 계속 집중할 회사들로 구성되어 있지만 일부 동부 해안 회사들은 DevOps 모델을 효과적으로 평가하고 그 방향으로 이동하기 시작할 수 있다는 것을 의미합니다. 하지만 더 현대적인 아키텍처와 외부 소비를 위한 호스팅된 애플리케이션에 훨씬 더 집중하는 것이 주요 경제적 요인인 서부 해안에서는 DevOps가 이미 신규자에서 성숙하고 확립된 정상으로 이동하고 있습니다. DevOps와 스노우플레이크 접근 방식은 IT가 일반적으로 서로 다른 지역으로 이동하는 다른 기술 셋을 보듯이 지역별로 크게 분리된 상태를 유지할 것으로 보입니다. 전통적인 IT가 상당히 저조한 성과를 보인 Austin 같은 시장에서 DevOps가 자리를 잡기 시작하는 것은 놀라운 일이 아닐 것입니다.

어느 접근 방식도 더 낫거나 나쁘지 않으며, 시스템 프로비저닝의 두 가지 매우 다른 방식과 해당 시스템의 두 가지 다른 근본적인 요구사항을 서비스하는 두 가지 다른 접근 방식입니다. 하지만 클라우드 아키텍처와 DevOps 모델의 부상으로 기존 시스템 관리자들이 DevOps 모델이 무엇을 의미하는지, 언제 적용되는지 이해하여 자신의 워크로드와 고유한 요구사항을 올바르게 평가할 수 있도록 하는 것이 매우 중요합니다. 전통적인 스노우플레이크 시스템 관리 세계의 상당 부분이 시간이 지남에 따라 DevOps 모델로 이동할 것입니다. 우리는 업계에서 이 두 가지 모델의 균형에 대한 안정적인 상태에 도달하기까지 아직 매우 멀리 있습니다.

원래 StorageCraft 블로그에 게재되었습니다.