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