[Korean] 클라우드 운영 모델 : DevOps, 보안, 네트워킹에 대한 도전과제와 솔루션

Transcript

저는 HashiCorp의 데이브 맥자넷(Dave McJannet)입니다. 모든 규모의 조직들이 비즈니스 차별화를 위해 새로운 애플리케이션 개발로 전환하는 방안을 모색하는 과정에서, 인프라 플랜과, 특히, 인프라를 위해 클라우드 운영 모델을 채택하는 방법에 대해 설명하려고 합니다.

앞으로 몇 분간 우리 제품이 운영(ops), 보안, 네트워킹과 관련한 몇 가지 주요 과제를 해결하는 방법에 대해 설명할 것입니다. 여러분들께서 이러한 과제를 해결하는 방법에 대한 아이디어를 얻게 되기를 바랍니다.

인프라 운영 방식에서 세대 교체가 일어나고 있다는 것은 모든 분들이 동의하실 것입니다. 저는 자주 어떤 일이 벌어지는지를 확인합니다. 현재 상황을 요약하면, 실행되고 있는 모든 서버가 전용 데이터센터 상에서의 운영 환경에서 클라우드 개념의 새로운 세계로 전환되고 있습니다. 이런 인프라의 전환은 온프레미스 환경에 인프라 풀을 만드는 것으로 시작되었으며, 이후 Amazon이, 그 다음으로 Azure가 추가되었습니다. 이제 멀티 클라우드가 현실이 되었으며, 모두가 이런 길에 동참하고 있습니다.

이를 촉진하는 요인은 매우 단순합니다. 우리는 왜 클라우드 인프라로 전환하고 있을까요? 그것은 완전히 새로운 시스템에 대한 접근 방식을 만듭니다. 제프리 무어(Geoffrey Moore)는 Systems of Record (SoR) 와 Systems of Engagement (SoE) 라는 용어를 사용하고 있습니다. 기록 시스템은 모든 기업에서 보유한 핵심 시스템입니다. (ERP나 CRM 등) 참여 시스템은 우리의 핵심 시스템 데이터를 활용하여 생성하는 완전 새로운 애플리케이션입니다. 대체로, 기록 시스템은 온프레미스에 구축됩니다.

인프라 전환을 촉진하는 요인은 주로 클라우드에 배포될 완전히 새로운 참여 시스템의 개발입니다. 따라서, 일부 인프라는 온프레미스 환경에 구축되어 있으며, 또 일부는 Amazon으로, 또 일부는 Azure로 전환하고 있기 때문에, 이런 현상으로 불가피하게 멀티 클라우드로 전환되고 있습니다. 하지만, Amazon으로 전환한다고 하더라도, 일부 데이터는 온프레미스 환경에서 보유해야 합니다.

이에 2가지 중요한 사항을 고려해야 합니다. 첫째는 새로운 현실을 고려해야 하는 인프라 운영에 사용할 도구입니다. 둘째는 프로세스입니다. 일반적으로 정적 인프라라고 하는 데이터센터를 기반으로 하는 매우 전통적인 도구에서부터 그 속성이 매우 다르며 완전히 새로운 동적 인프라 세계로 전환하는 프로세스입니다.

하지만, 이 프로세스에서는 사람의 관점인 인프라가 필요하고, 티켓을 열어야 하는 티켓 기반 모델에서 셀프 서비스 모델로 전환해야 합니다. 이들 2가지 모두 인프라 자체의 속성을 변화시킬 뿐만 아니라, 셀프서비스를 위한 요구 사항도 달라지고 있습니다. 따라서 완전히 새로운 참여 시스템을 신속하게 개발할 수 있는 사람들이 인프라를 실행하는 방식에 대한 전반적인 리플랫폼(re-platforming)이 야기됩니다.

저는 인프라 계층으로 이것을 나눠보고자 합니다.

여기 핵심 인프라가 있습니다. 컴퓨팅 용량을 프로비저닝하는 방법을 생각해 보겠습니다. 각각 서버가 고정된 전용 인프라가 있는 세계에서 필요에 따라 동적으로 프로비저닝되는 세계로 넘어가고 있습니다. 이제 필요할 때 컴퓨팅 용량을 프로비저닝할 수 있습니다.

보안 계층은 완전히 다른 세계입니다. 예전에는 신뢰하는 이 IP 범위 내에 있는 것들만 통신을 주고 받을 수 있었습니다. 따라서 기본적으로 이는 신뢰도가 높은(high-trust) 보안 환경이며, IP를 누가 누구와 통신을 주고 받을 수 있는지를 결정하는 기준으로 사용합니다. 여기에 애플리케이션이 있으면, 여기에 있는 데이터베이스와 통신을 주고받을 수 있습니다. 데이터베이스 내에 있는 한, 이러한 방식으로 수행하도록 할 것입니다.

저는 이제 신뢰도가 낮은(low-trust) 세계로 갑니다. 여기서는 더이상 네트워크를 컨트롤 하지 못합니다. 여기서의 가장 큰 변화는 자격증명(identity)을 보안 기준으로 사용하는 것이며, 어떤 것에 대한 접근 권한을 부여하기 전에 자격증명을 인증합니다. 이러한 개념은 클라우드 세계에서 비교적 쉽게 이해되고 있습니다. 그 결과, 우리 모두는 자격증명과 보안에 대한 개념이 널리 일반화되고 있는 상황을 목격하고 있습니다.

네트워킹 계층에서는 호스트 기반 네트워킹으로부터 시작합니다. 이 시스템에는 물리적 위치와 물리적 호스트가 있기 때문에 IP 주소를 할당할 수 있습니다. 여기에 애플리케이션 구성이 있을 수 있고, 여기에 데이터베이스가 있을 수 있습니다. 이것들은 계속해서 움직이고 있습니다.

섣불리 이들의 IP 주소를 제어할 수 있고 IP 기반, 호스트 기반 네트워킹의 세계에서 새로운 세계의 서버 기반 네트워킹으로 전환할 수 있다고 하지는 않겠습니다.

개념적으로 매우 다른 세계입니다. 개발자가 애플리케이션들을 전용 인프라에 배포하는 방식에서 인프라 군에 배포하는 방식으로 전환하고 있습니다.

이를테면, 이 4가지 변화는 사람들이 인프라를 운영하는 방법과 관련하여 어마어마한 영향을 미치고 있으며, 곧, 시장 전반에서 인프라에 대한 사고 방식을 완전히 변화시키고 있습니다.

전반적인 논점은 이같은 변화에 근거를 두고 있습니다. 여기에서 수행한 방식으로 문제를 나누어 보겠습니다. 이런 새로운 동적 인프라 모델의 세계에는 운영 담당자, 보안 담당자, 네트워킹 담당자, 그리고 당연히도 개발자가 있고 이들은 완전히 새로운 참여형 시스템을 개발하는 사람들입니다.

각 4개 부문의 참가자들은 이 새로운 모델에서 인프라를 운영하는 방법을 찾아내야만 합니다. 이 사람들의 역할을 나누어 보겠습니다.

운영 담당자들은 사람들이 다양한 인프라 유형 전반에서 필요한 인프라를 프로비저닝할 수 있도록 하는 방법을 찾아내야 합니다. Terraform은 이를 지원하는 Hashicorp의 플랫폼입니다. Terraform은 이미 널리 사용중이고, 온프레미스, Amazon, Azure 등 다양한 인프라 유형 전반에서 공통의 프로비저닝 메커니즘으로서 사용됩니다. 매일 클라우드에서 Terraform 사용자에 의해 프로비저닝되는 인프라의 비율은 정확하게는 알 수 없지만, 엄청 높습니다. 간단히 말해, Terraform은 다음과 같은 방식으로 작동합니다. 여기에는 CLI 툴인 Terraform 코어가 있습니다. 그리고, 인터페이스하려는 모든 환경을 위한 프로바이더가 있습니다. 자, Amazon에는 구성할 수 있는 500 여개 서비스가 있죠. Azure에는 구성할 수 있는 300여 개 서비스가 있으며, Google은 성숙하는 단계이기 때문에 200여 개 서비스가 있습니다. vSphere에는 대략 200개가 있습니다.

요점은, Terraform은 이들 모든 클라우드 플랫폼에서 모든 고유한 서비스를 구성할 수 있도록 통일된 운영 경험을 제공합니다. 프로바이더는 2개 범주로 나눌 수 있습니다. 코어 인프라 프로바이더와 여러분이 구성하기 원하는 모든 다른 ISV를 위한 프로바이더가 있습니다. 프로비저닝 경험의 일부로서 F5를 구성하거나, 쿠버네티스(Kubernetes)나 Palo Alto Networks를 프로비저닝하는 등의 경우, 200개 이상의 써드파티 프로바이더를 활용할 수 있습니다.

하나의 Terraform 템플릿에서 4개 Amazon 서비스와 6개 관련 서비스의 프로비저닝을 코드화할 수 있습니다. 이를 통해 운영 담당자들은 승인된 템플릿으로 Amazon 구성요소는 물론 모든 관련 요소들을 프로비저닝하고 구성할 수 있습니다.

이것은 사람들이 여러 인프라 유형 전반의 수요 모델에서 프로비저닝하는 방법과 관련한 과제를 해결하는 방법입니다. 우리는 최소한의 공통 서비스 요소를 구하는 것이 아니라, 이들 모든 다양한 인프라 유형 전반에서 공통의 워크플로우를 작성하려는 것입니다.

보안 계층에서는 Vault로 불리는 제품이 있습니다. Vault는 모든 자격증명을 활용해 시스템 또는 애플리케이션에 대한 액세스를 제어할 수 있도록 합니다. 아주 간단합니다. 과거 전통적인 환경에서 이러한 개념이 설명된 바 있습니다. 여기 클라이언트가 있고, 벡엔드 시스템, 아마도 데이터베이스에 요청을 실행해야 하는 애플리케이션이 있습니다. 돌아보면, 만약 여러분이 제게 현재의 자격증명을 제공하면 정보를 제공하는 것과 같습니다. 우리에게 익숙한 신뢰도가 높은 보안 영역에서 이는 당연한 가정이며 올바른 모델입니다. 허나, 클라우드의 신뢰도가 낮은 환경에서 이는 권장되지 않을 것입니다. 예전에 애플리케이션이나 백엔드 시스템에 액세스할 수 있도록 한 일부 신뢰할 수 있는 자격증명 정보를 기준으로 자격증명을 인증할 수 있기를 원할 것입니다. Vault는 그 중간에 개입해 관련한 모든 자격증명에 대한 인증을 수행합니다.

모든 클라우드 제공자들이 자격증명을 통해 보안을 제공하는 기준으로 사용하고 있는 것으로 밝혀졌습니다. Amazon은 Amazon IAM 모델을, Azure는 Azure Active Directory를, Google은 IAM 모델을 가지고 있습니다. 여러분은 온프레미스 환경에 Active Directory나 LDAP를 사용하고 있을 수도 있습니다. 또는 Amazon에서 실행되지만, 온프레미스에서 운영되는 데이터베이스에 연결해야 하는 애플리케이션이 있을 수도 있습니다. 여러분은 지금의 자격증명을 연결 기반으로 사용하고 있지만, 이들은 여러 다른 자격증명 모델을 가지고 있습니다.

Vault는 Active Directory, 클라우드의 IAM 모델, 그리고 조직 내 일부에서 사용하고 있는 경우, Okta나 GitHub의 OAuth 등 원하는 모든 자격증명을 인증할 수 있습니다. 무엇이든 관계없이, Vault를 이용해 모든 모델에 대해 인증할 수 있습니다. 백엔드 시스템의 자격증명 모델을 인증하기 위해 클라이언트가 Vault에 요청하는 라우팅을 변경할 수 있습니다. 승인이 이루어지면, 인증정보가 생성되고 최종사용자에게 토큰이 반환됩니다.

따라서 모든 애플리케이션 유형 전반에서 시크릿 관리(secrets management)를 중앙집중화하고 보안 팀이 정책을 설정할 수 있습니다. Vault는 이제 이러한 자격증명의 개념을 이용해, 어떤 자격증명 모델 사용 여부에 관계없이 구성 내 모든 시스템이나 애플리케이션에 적용할 수 있도록 합니다. 중앙 보안 관리 플랫폼을 개발한다는 아이디어는 이 새로운 세계에서 매우 설득력이 있습니다.

사람들이 Vault를 사용하게 되면서, 부차적인 용도가 파생됩니다. 첫번째는 시크릿의 중앙집중화입니다. 그 다음은 암호화입니다. 모든 애플리케이션들이 백엔드 시스템에 대한 액세스 권한을 받기 전에 Vault에서 인증을 위한 토큰(token)을 받아야 하기 때문에 이제 이러한 흐름을 암호화하는 정책을 적용할 수 있습니다.

애플리케이션 자체는 전혀 변경하지 않으며 보안 팀이 클라우드 구성 내 모든 것에 대한 암호화를 적용하도록 설명하면 됩니다. 시크릿과 인증정보 관리를 중앙 집중화하고 모든 저장 및 전송 데이터를 암호화할 수 있다면, 클라우드 세계는 보안 과제의 99%는 해결하게 될 것입니다.

우리 포트폴리오의 세번째 요소는 Consul입니다. Consul은 세계에서 가장 널리 사용되는 Hashicorp 제품입니다. Consul을 통해 서비스 기반 네트워킹의 과제를 해결할 수 있습니다. 전통적인 세계에서는 애플리케이션 구성을 자체 환경에 배포합니다. 이것을 데이터베이스로 하고, 이것은 앱 서버라고 하겠습니다. 여기 IP를 할당하라고 이야기하겠죠.

고정된 IP를 할당하기 위해서는 일반적으로 구축된 모든 각 요소들 앞에 로드 밸런서를 배치해야 합니다. 이에 따라 수백, 수천 개의 로드 밸런서가 있는 구조를 초래하게 되는 것입니다. 1.1.1.1. 과 1.1.1.2.를 할당할 때 Consul은 앞서와 같은 작업을 수행하는 것이 아니라 공통의 서비스 레지스트리를 만듭니다. 애플리케이션이나 구성, 또는 각 요소들을 배포하면, 검색을 위해 작은 클라이언트 라이브러리가 생성됩니다.

이제 Consul은 모든 것이 어디에 있는지 알고 있으며, IP 주소가 아니라 이름으로 이러한 작업을 수행합니다. 따라서 이것은 앱 서버 1이고, 이건 데이터베이스 1입니다. Consul은 이제 모든 것이 어디에 있는지에 대한 공통 서비스 레지스트리를 생성했습니다. 이제 Consul을 조회해서 트래픽을 전송할 수 있습니다.

이제 사람들은 비싼데다가 애플리케이션 트래픽 요구에 따라 여러모로 많은 비용이 요구되는 고가의 로드 밸런서를 설치할 필요가 없습니다. 그리고 모든 애플리케이션 요청을 north-south로 보내지 않고 직접 서비스 간에 트래픽을 라우팅할 수 있습니다. 로드 밸런서에 대한 필요성을 완전히 없애는 것은 아니지만, 필요한 로드 밸런서의 수는 확실히 줄어듭니다. 먼저, Consul은 공통 서비스 레지스트리이지만, 파생적인 용도로서 이제 라우팅에 활용할 수 있습니다. 다음으로, 이를 서비스 분리에 활용할 수 있습니다.

이와 관련해 최근 서비스 메시(service mesh)라는 개념에 대한 논의가 시작되고 있습니다. 서비스 메시는 누가 누구와 연결될 수 있고, 연결이 되면 서비스 간에 암호화된 통신을 있도록 합니다. Vault가 변화하는 보안에 대해 접근하는 방식과 개념적으로 매우 유사합니다. 이는 이전 환경에서와 같은 방식을 시도하거나 흉내내지 않지만, 무엇이 핵심 문제인지 알려주고 해결할 수 있도록 합니다.

네트워킹 세계에서 Consul을 살펴보기 위해, 우리가 가지고 있는 핵심 문제가 모든 것들이 어디에 있느냐 하는 것이라고 간주해 보겠습니다. 이는 각각의 위치를 기반으로 트래픽 라우팅을 시작하고 원하는 모든 서비스 전반에 mutual TLS를 적용할 수 있도록 합니다.

이것들은 여러분 환경에 있는 모든 다양한 유형의 애플리케이션을 실행하는 3가지 핵심 요소입니다. 여러분은 Java, C#, Cloud Foundry, Kubernetes, 컨테이너 기반 애플리케이션 등을 보유하고 있습니다. 여기서 문제는 스케줄링입니다.

4번째 제품은 Nomad입니다. Nomad은 애플리케이션 스케줄러입니다. C# 애플리케이션, VM 또는 Java 애프리케이션, 아니면, Cloud Foundry 기반 애플리케이션이건 상관없이 환경 전반의 애플리케이션에 대한 스케줄링을 실행할 수 있도록 합니다. 따라서, 이 모든 인프라를 가동하려고 한다면, 최소한 바이너리 패킹이 사용중인 환경 전반에서 최적의 스케줄로 실행되어야 합니다.

이것들은 기본적으로 핵심 개념입니다. 첫째는 정적 인프라에서 동적 인프라로 전환하는 것이며 각 계층에서 재차 확인할 수 있습니다. 둘째는 Hashicorp의 포트폴리오가 실행되는 방식입니다. 이들 개별 제품들은 지금까지 설명한 이들 각 4가지 요소들의 요구사항을 충족합니다.

셋째는, 가장 일반적인 것으로, 클라우드로 전환하면서 셀프 서비스의 과제를 어떻게 해결할 것인가 하는 것입니다. 대부분 고객들은 그림을 그리면서 이 애플리케이션 요소나 구성을 기반으로, 여기에 도달하는 방법을 파악해야 한다고 말합니다. 이것이 클라우드 1이고, 이건 클라우드 2, 그리고 클라우드 3입니다.

이들은 애플리케이션 구성을 자체적으로 배포하기 보다는 운영, 보안 및 네트워킹 팀의 요구를 충족해야 하기 때문에 애플리케이션을 클라우드 환경으로 전환할 때 안전하게 보호되고, 트래픽을 확인할 수 있으며 하며, 지나치게 비싸지 않아야 한다고 말합니다. 저는 운영, 보안 및 네트워킹 담당자들의 요구를 해결해야 합니다. 이를 위해 대부분의 고객들은 Terraform, Terraform Enterprise, Vault Enterprise 및 Consul Enterprise로 필수적인 중앙화된 공유 서비스를 개발합니다.

Terraform을 활용함으로써 기본적으로 애플리케이션을 클라우드로 전환하는 데 대해 내부적으로 승인하는 템플릿 세트를 누구나 사용 가능하게 작성할 수 있습니다. 이제 운영 담당자들은 필요한 모든 애플리케이션 요소들을 확보하고 있다는 것을 알고 있기 때문에 원하는 경우, 하루에 수백 번 프로비저닝할 수 있습니다.

둘째, 모든 구성이 인증정보를 받기 위해 Vault로 요청되는 것은 보안 팀이 적극 환영할 것입니다. 이제 애플리케이션에 하드코딩된 인증정보에 대해 걱정하지 않으며, 향후 실행하려는 모든 암호화를 위한 통제 지점을 제공했습니다. 이제, 해결됐습니다.

셋째, 배포된 구성이 Consul을 포함하고 있는 경우, 해당 Consul 서버는 이를 발견하고 즉시 라우팅 트래픽을 시작할 수 있습니다. 따라서 이 3가지 요소는 Java 애플리케이션이건, C# 애플리케이션이건, 또는 Cloud Foundry이건 관계없이 일관된 부분이 됩니다.

보안 및 정책 요구를 해결하기 위해 상용 버전들은 정책을 적용하는 공통의 방법을 추가합니다. 예를 들어, Terraform에서는 누구도 금요일 오후 5시 이후에는 프로비저닝을 실행할 수 없습니다. 금요일 5시 이전에는 가능하지만, 그 시간이 지나면, 허용되지 않습니다. 그 동작은 거버넌스의 개념을 필요로 합니다. 이들 모두가 대부분 엄격한 규제를 받는 기업들이기 때문에 누가 무엇을 했는가, 어떻게 들어갔는가, 누가 ACL과 같은 것을 만들 수 있는 액세스 권한이 허용되었는가 등에 대한 감사 추적이 필요합니다.

우리의 상용 버전으로 중앙에서 공유가능한 서비스를 구성하는 경우, 클라우드 인프라에서 새로운 애플리케이션을 신속하게 제공하기 위한 업무용 프로세스를 개발할 수 있습니다. 이들은 모두 클라우드 세계의 현실이 얼마나 다른 지를 인식하고 셀프 서비스 기능을 개발합니다. 글로벌 2000개의 기업들은 조직 내 중앙 공유 서비스를 개발함으로써 소규모 스타트업들과 유사한 방식으로 애플리케이션을 제공할 수 있습니다.

이 동영상을 통해 인프라 세계의 진화와 특히 HashiCorp 제품이 어떻게 우리가 하루 종일 사용하는 많은 애플리케이션을 뒷받침하는 클라우드 운영 모델을 지원하는지에 대한 이해에 도움이 되기를 바랍니다.

HashiCorp 웹 사이트에서 클라우드 운영 모델(The Cloud Operating Model) 백서를 다운로드하여 읽어 보실 것을 권장합니다. 또한, 보다 직접적인 지원이 필요하시면 언제든지 연락주십시오.

HashiCorp 툴을 사용하는 방법을 배우려면, HashiCorp Learn 웹 사이트를 방문해 주십시오.