Google의 '클라우드 네이티브'를 사용하면 800억 건 이상의 조회수를 얻을 수 있습니다. 분명히 클라우드 네이티브는 중요한 용어입니다. 과 사람들은 그것이 실제로 무엇을 의미하는지 잘 모릅니다. 얼마 전 "비즈니스에 종사하는" 다른 사람과의 대화에서 저는 "하지만 클라우드 네이티브는 아닙니다!"라고 말했습니다. 그녀는 동의한다는 뜻으로 현명하게 고개를 끄덕였습니다. 분명히 이는 "클라우드 네이티브"라는 약칭을 사용하여 일부 복잡한 구성에 동의할 수 있으므로 의미가 있습니다. 더 자세히 살펴보겠습니다.
클라우드 네이티브가 무엇인지 정의하려면 다음과 같은 더 간단한 질문부터 시작해야 합니다.
클라우드란?
분해에 관한 모든 것
약 50년 전 – Microsoft가 설립되기 전 – 하버드 학생 Bill Gates와 Paul Allen은 세계 최초의 마이크로컴퓨터 중 하나인 MITS Altair 8080용 BASIC 인터프리터를 작성했습니다. 그들은 전체 프로그램을 종이 테이프(초기 저장 형태)에 저장하고 MITS에게 그들이 쓴 내용을 보여주기 위해 뉴멕시코로 날아갔습니다.
앨버커키로 내려가는 동안 Allen은 종이 테이프(BASIC 인터프리터가 이를 Altair 8080에 로드하는 데 필요함)를 읽을 수 있는 방법이 없다는 것을 깨달았습니다. Allen은 종이 테이프를 읽는 프로그램을 빠르게 작성했습니다. 효과가 있었고 나머지는 역사입니다.
"집합"이 무엇을 의미하는지 알고 싶다면 이것이 좋은 예입니다. Gates와 Allen의 BASIC 인터프리터를 실행하는 데 필요한 모든 것은 Gates와 Allen이 작성해야 했습니다. 여기에는 종이 테이프에서 시스템 메모리로 코드를 읽는 루틴도 포함되었습니다.
완전히 분산하는 것이 목표인 클라우드 컴퓨팅으로 빠르게 발전합니다. 무엇을 분해합니까? 잘 - 모두. 컴퓨팅은 다른 모든 것과 분리되어 있으므로 다른 모든 것과 독립적으로 필요한 컴퓨팅 양을 구입할 수 있습니다. 스토리지와 네트워크도 마찬가지입니다.
하지만 그것은 단지 인프라일 뿐입니다. 클라우드는 소프트웨어도 분리합니다. Gates와 Allen은 애플리케이션에 대한 모든 코드 라인을 작성해야 했지만 오늘날 클라우드 앱은 "서비스"를 활용하여 특정 작업을 처리합니다. 수년간 대규모의 모놀리식 애플리케이션을 코딩하는 대신 오늘날의 클라우드 앱은 수십(또는 수백) 개의 클라우드 서비스를 연결하는 수백 줄의 코드로 구축됩니다.
클라우드는 다음과 같이 가장 잘 표현된 구성 가능성에 대한 Unix 철학의 논리적 확장입니다. 더그 맥엘로이, 유닉스 파이프의 발명가, “한 가지 일을 잘 수행하는 프로그램을 작성하세요. 함께 작동하는 프로그램을 작성하세요.”
이것이 바로 클라우드의 본질입니다. 그런데 왜 분해합니까? 가장 단순한 수준에서 세분화는 탄력성과 민첩성을 제공합니다.
탄력
워크로드에 필요한 리소스는 시간에 따라 달라집니다. 예를 들어 제임스 카메론의 아바타는 특수 효과의 한계를 뛰어 넘었습니다.. 단일 프레임을 렌더링하려면 클라우드에서 한 시간 동안 3,000개의 vCPU에 해당하는 것이 필요했습니다. 아바타는 초당 48프레임으로 촬영되었고 192분 동안 실행되었으므로 렌더링할 프레임이 1.6만 개가 넘었습니다. 이는 XNUMX억 시간이 넘는 가상 CPU 주기입니다.
이 영화는 총 12년 동안 제작되었지만 모든 영화와 마찬가지로 최종 렌더링의 대부분은 영화 개봉에 가까워졌습니다. 클라우드가 탄력성을 제공했습니다. 아바타의 특수효과 작업을 완료하려면 공급업체가 필요합니다. 수석 VFX 프로듀서인 David Conley는 AWS가 없었다면 이 작업을 수행할 수 없었을 것이라고 말했습니다.
탄력성은 컴퓨팅, 스토리지, 네트워킹 및 필요한 거의 모든 리소스에 적용됩니다. 클라우드를 사용하면 필요에 따라 사용량을 쉽고 빠르게 확장하고 다시 줄일 수 있습니다.
민첩
클라우드의 또 다른 이점은 모든 의미에서 민첩성입니다. 클라우드는 다음을 가능하게 합니다:
- 개발 민첩성 앞서 언급한 서비스 아키텍처 때문입니다. 개발자는 다양한 서비스를 도입하고 수년, 수백만 줄의 코드에서 몇 주, 수천 줄로 코딩을 줄입니다.
참고로 이 새로운 "서비스 아키텍처"는 네트워크 효과의 이점을 누릴 수 있습니다. 더 많은 워크로드가 서비스를 사용할수록 제XNUMX자가 새로운 서비스를 개발하려는 동기를 더 많이 갖게 됩니다. 그리고 서비스가 많을수록 개발자는 타사 서비스를 사용하려는 동기를 갖게 됩니다. 이 선순환은 모놀리식 코딩 방식에서 서비스 아키텍처로의 전환을 가속화했습니다.
- 인프라 민첩성, 인프라를 구매, 설치, 관리하는 대신 사용자는 간단한 요청을 통해 필요할 때 필요한 것을 요청하기만 하면 됩니다. "코드형 인프라"라는 용어는 간단한 "코드"를 사용하여 몇 주 또는 몇 달이 아닌 몇 분 만에 필요한 모든 인프라를 프로비저닝하는 것을 의미합니다.
- 경제적 민첩성, 필요할 때 필요한 만큼만 플레이할 수 있기 때문입니다. 아바타는 대규모 SFX 데이터 센터를 구축하고 12년 동안 관리할 필요가 없었습니다. 대신, 그들은 필요할 때 필요한 것을 간단히 가동했습니다.
이제 클라우드가 무엇인지 이해했으므로 진정한 클라우드 네이티브가 되기 위해 필요한 것이 무엇인지 논의할 수 있습니다.
클라우드 네이티브란?
쉬운 대답은 클라우드 네이티브 애플리케이션이 다음을 사용하여 클라우드와 상호 작용한다는 것입니다. 클라우드 네이티브 기초 요소. 예를 들어 클라우드 네이티브 앱은 Amazon AWS의 기본 스토리지 서비스(S3, EBS, EFS 등)를 직접 호출합니다. 이 원칙은 컴퓨터, 매장, 네트워크 등 모든 클라우드 서비스에 적용됩니다.
"클라우드에서 태어난" 애플리케이션(즉, 처음부터 클라우드에서만 실행되도록 설계된 애플리케이션)의 경우 이는 충분히 쉽습니다. 그러나 온프레미스 환경에서 탄생한 애플리케이션의 경우에는 고통스러운 리팩토링 작업이 필요합니다. 이를 위해서는 애플리케이션이 컴퓨팅, 스토리지, 네트워킹 등 모든 인프라에서 완전히 분리되어야 합니다.
진정한 클라우드 네이티브가 되기 위한 두 번째 중요한 요구 사항은 "코드형"으로 관리되는 것입니다. 이는 몇 주에 걸쳐 모든 것을 수동으로 설치하고 구성하는 전통적인 온프레미스 프로세스와 달리 몇 줄의 코드로 애플리케이션을 가동할 수 있음을 의미합니다.
임신과 마찬가지로 "부분적인 클라우드 네이티브"는 없습니다. 앱은 클라우드 기반이거나 그렇지 않습니다. 앱이 "코드형" 방법론을 완전히 분리하고 수용하지 않으면 클라우드가 약속하는 탄력성과 민첩성의 이점을 잃게 됩니다.
클라우드 네이티브 스토리지 솔루션이 있습니까?
클라우드 네이티브 스토리지 솔루션에 대해 이야기하기 전에 "스토리지"와 관련된 클라우드 "기본 요소"를 검토해 보겠습니다.
객체 스토리지(Azure Blob/AWS S3)입니다. 이는 처리량으로 측정했을 때 뛰어난 성능을 갖춘 놀랍도록 저렴하고 확장 가능하며 내구성이 뛰어난 데이터 지속성 레이어입니다. 단점은 RESTful이며 최종적으로는 일관성이 있는 새로운 인터페이스라는 것입니다.
그러면 가난한 사람이 원하는 SAN, 즉 AWS의 EBS 및 Azure의 Managed Disk가 있습니다. 이는 "로컬 디스크"처럼 존재하고 탄력적이며 대부분 일반 오래된 스토리지 서버의 일반 디스크처럼 작동합니다. 이러한 기본 요소는 "보호된 로컬 디스크"와 동일한 역할을 합니다(로컬 컴퓨팅 인스턴스에 연결되지 않은 경우 제외). 이러한 프리미티브는 적당한 성능 특성을 가지며 "임의 읽기/쓰기"를 지원할 수 있지만 비용이 많이 듭니다.
마지막으로 인스턴스 연결 NVMe SSD가 있습니다. 이는 이러한 "드라이브"의 데이터가 인스턴스를 다시 시작해도 유지되지 않는다는 점에서 DRAM의 확장과 비슷하지만 DRAM이나 "보호된 로컬 디스크"보다 훨씬 저렴합니다. 이 둘 사이의 성능 특성.
지금까지 스토리지 업계는 클라우드에 완고하게 저항해 왔습니다. 레거시 공급업체(Dell, NetApp)는 클라우드 네이티브 기본 요소를 활용하기 위해 제품을 리팩토링하기에는 하드웨어 관련 코드(NVRAM에 대한 깊은 종속성, 데이터 복원력 및 데이터 서비스 계층의 긴밀한 결합)가 너무 많습니다.
그리고 VAST와 Pure도 하드웨어에 최적화된 스토리지 스택을 선택했습니다.
퓨어의 클라우드 블록 스토리지 이 서비스는 퓨어스토리지 고객이 그토록 원했던 블록 데이터 서비스를 제공하기 위해 클라우드 네이티브 기본 요소를 사용한다는 점과 매우 슬프다는 점에서 모두 관련이 있습니다! 도대체 누가 클라우드의 SAN에서 실행되고 있습니까? 그냥 마음이 흔들립니다. 그리고 이 주제를 다루는 동안 클라우드에서 VMWare를 사용하는 사람이 누구인지 이해하기 어렵습니다. 이것도 마음이 흔들립니다!
차세대 스토리지 제공업체 중에서 실제로 인상적인 것은 Weka.io입니다. 이들은 "클라우드 네이티브" 아키텍처를 보유하고 있으며 클라우드 개체 스토리지를 탄력성 계층으로 활용합니다. 이제 HPC 틈새 플레이어, '유리 페라리'라는 평판만 없었더라면…
그렇다면 Qumulo의 CTO로서 Qumulo의 클라우드 제품에 대해 무엇을 말해야 할까요?
계속 지켜봐 주시기 바랍니다.
달력에 날짜를 표시하세요. 9년 2023월 XNUMX일 목요일, 깜짝 놀랄 준비를 하세요 🙂
