스토리지 및 데이터 전송

Google의 미디어 무결화에 대한 미래

Mon, 13 Oct 2025 16:00:00 +0000

해당 블로그의 원문은 2025년 10월 14일 Google Cloud 블로그(영문)에 게재되었습니다.

Google에서 데이터 보호는 가장 중요한 책임이며, 저희는 고객님의 데이터를 안전하게 지키기 위해 최선을 다하고 있습니다. 이러한 약속을 더욱 강화하기 위해, 2025년 11월부터 미디어 완전 삭제에 대한 접근 방식을 전환하여, 강력하고 계층화된 암호화 전략에 전적으로 의존하기 시작할 것임을 알려드리게 되어 기쁩니다.

이는 저희가 약 20년 동안 사용해 온 '무차별적인 디스크 삭제(brute force disk erase)' 프로세스에서 벗어나는 것을 의미합니다. 데이터를 덮어쓰는 방식은 효과적인 방법이었지만, 저장 기술 환경이 급격하게 변화했습니다. 오늘날 현대 미디어의 크기와 기술적 복잡성으로 인해 이 프로세스는 더 이상 지속 가능하지 않습니다.

더 스마트한 접근 방식: 암호화 삭제 (Cryptographic Erasure)

이러한 문제를 해결하기 위해, 저희는 미디어 완전 삭제의 더욱 현대적이고 효율적인 방법인 암호화 삭제(cryptographic erasure)를 도입합니다.

기본적으로 Google 서비스의 모든 사용자 데이터는 다중 암호화 계층으로 보호됩니다. 암호화 삭제는 이러한 암호화를 활용하여 미디어를 완전 삭제합니다. 드라이브 전체를 덮어쓰는 대신, 데이터 암호화에 사용되는 암호화 키를 안전하게 삭제합니다. 키가 사라지면 데이터는 읽을 수 없고 복구할 수 없는 상태가 됩니다.

이 방법은 더 빠를 뿐만 아니라 업계 모범 사례와도 일치합니다. 미국 국립표준기술연구소(NIST)는 특별 간행물 800-88에서 암호화 삭제를 유효한 완전 삭제 기술로 인정하고 있습니다. 저희는 고객님의 데이터 보안을 보장하기 위해 이러한 표준을 충족하고 능가하기 위해 최선을 다하고 있습니다.

혁신을 통한 보안 강화

저희는 심층 방어(defense in depth) 전략을 사용하여 암호화 삭제를 다중 보안 계층으로 구현합니다. 저희의 신뢰하되 검증하는(trust-but-verify) 모델은 독립적인 검증 메커니즘을 사용하여 미디어 암호화 키의 영구 삭제를 보장합니다.

또한, 저장 장치 키와 같은 이 프로세스에 관련된 비밀 정보를 업계 최고의 조치로 보호합니다. 다중 키 순환(key rotations)은 독립적인 신뢰할 수 있는 암호화 계층을 통해 고객 데이터의 보안을 강화합니다.

지속 가능성 및 순환 경제

이전의 미디어 삭제 방법은 환경적 비용을 수반했습니다. 저희의 엄격한 검증 프로세스에 실패한 모든 저장 장치는 물리적으로 파괴되어 매년 상당수의 장치가 폐기되었습니다.

암호화 삭제는 저희가 더 지속 가능한 순환 경제로 나아갈 수 있도록 합니다. 드라이브를 물리적으로 파괴할 필요성을 제거함으로써, 저희는 더 많은 하드웨어를 재사용할 수 있습니다. 또한, 수명이 다한 미디어에서 네오디뮴 자석과 같은 귀중한 희토류 재료를 회수할 수 있게 됩니다. 이 혁신적인 자석 회수 프로세스는 지속 가능한 제조 분야의 주요 성과이며, 책임 있는 성장에 대한 저희의 약속을 보여줍니다.

Google의 앞으로의 방향

저희는 사용자, 더 넓은 산업, 그리고 전 세계를 위해 진정으로 올바른 일을 하는 것에 대해 지속적으로 강력하게 주장해 왔습니다. 이러한 암호화 삭제로의 전환은 그러한 약속을 직접적으로 반영합니다. 이를 통해 저희는 보안을 강화하고, 최고의 산업 표준에 부합하며, 저희 인프라를 위해 더 지속 가능한 미래를 구축할 수 있습니다. 저희는 이것이 사용자, 산업, 그리고 환경을 위한 올바른 길이라고 믿습니다.

암호화 키 관리를 포함한 미사용 데이터 암호화에 대한 자세한 내용은, 저희의 미사용 데이터 기본 암호화 보안 백서(default encryption at rest)를 참조해 주십시오.

Google Kubernetes Engine의 Managed Lustre 관련 5가지 권장사항

Fri, 19 Sep 2025 16:00:00 +0000

* 본 아티클의 원문은 2025년 09월 20일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Kubernetes Engine(GKE)은 확장 가능한 AI 및 고성능 컴퓨팅(HPC) 워크로드를 조정하기 위한 강력한 플랫폼입니다. 하지만 클러스터가 커지고 작업이 더 데이터 집약적으로 변할수록 스토리지 I/O가 병목 현상이 될 수 있습니다. 이로 인해 강력한 GPU와 TPU가 데이터를 기다리느라 유휴 상태가 되어 비용이 증가하고 혁신이 둔화될 수 있습니다.

Google Cloud Managed Lustre는 이러한 문제를 해결하기 위해 설계되었습니다. 많은 온프레미스 HPC 환경에서 이미 병렬 파일 시스템을 사용하고 있으며, Managed Lustre를 사용하면 이러한 워크로드를 클라우드로 더 쉽게 가져올 수 있습니다. 관리형 컨테이너 스토리지 인터페이스(CSI) 드라이버를 통해 Managed Lustre는 GKE 운영과 완전히 통합됩니다.

고성능 병렬 파일 시스템으로의 이전을 최적화하면 첫날부터 투자 효과를 극대화할 수 있습니다.

배포에 앞서 Managed Lustre를 사용해야 하는 경우와 Google Cloud Storage와 같은 다른 옵션을 사용해야 하는 경우를 알아두는 것이 좋습니다. 대부분의 AI 및 ML 워크로드에는 Managed Lustre가 권장되는 솔루션입니다. 학습 및 체크포인팅처럼 지연 시간이 1밀리초 미만으로 매우 짧고 작은 파일에 대해 높은 처리량을 요구하는 시나리오에서 탁월한 성능을 발휘하므로 고가의 가속기를 최대한 활용할 수 있습니다. 반면, 데이터 보관처리 또는 대용량 파일(50MB 초과)을 다루고 지연 시간에 민감하지 않은 워크로드의 경우 Cloud Storage FUSE와 Anywhere Cache 조합이 또 다른 선택지로 고려할 수 있습니다.

초기 고객들과의 협업과 Google Cloud팀의 경험을 바탕으로 GKE에서 Managed Lustre를 최대한 활용하기 위한 5가지 권장사항을 소개합니다.

aside_block: <ListValue: [StructValue([('title', 'Google Cloud 컨테이너 및 Kubernetes를 체험할 수 있는 $300 무료 크레딧 제공'), ('body', <wagtail.rich_text.RichText object at 0x7fd2387f75e0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

1. 데이터 지역성을 고려한 설계

성능에 민감한 애플리케이션의 경우 컴퓨팅 리소스와 스토리지가 가능한 한 가까이 있어야 하며, 특정 리전 내 동일한 영역에 있는 것이 이상적입니다. 볼륨을 동적으로 프로비저닝할 때는 StorageClass의 volumeBindingMode 파라미터가 가장 중요한 도구입니다. 이를 WaitForFirstConsumer로 설정하는 것이 좋습니다. GKE는 기본적으로 WaitForFirstConsumer 바인딩 모드를 사용하는 Managed Lustre용 내장 StorageClass를 제공합니다.

생성된 YAML:

code_block: <ListValue: [StructValue([('code', 'apiVersion: storage.k8s.io/v1\r\nkind: StorageClass\r\nmetadata:\r\n name: lustre-regional-wait\r\nprovisioner: lustre.csi.storage.gke.io\r\nvolumeBindingMode: WaitForFirstConsumer\r\n...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd2387f7850>)])]>

권장하는 이유: WaitForFirstConsumer를 사용하면 이를 필요로 하는 포드가 예약될 때까지 GKE가 Lustre 인스턴스의 프로비저닝을 지연하도록 지시합니다. 그러면 스케줄러는 포드의 토폴로지 제약 조건(즉, 예약된 영역)을 사용하여 정확히 동일한 영역에 Lustre 인스턴스를 만듭니다. 이렇게 하면 스토리지와 컴퓨팅이 동일한 위치에 배치되어 네트워크 지연 시간이 최소화됩니다.

2. 성능에 맞는 등급 선택

모든 고성능 워크로드가 동일한 것은 아닙니다. Managed Lustre는 여러 성능 등급(스토리지 1TiB당 읽기 및 쓰기 처리량(Mbps))을 제공하므로 성능 요구사항에 맞춰 비용을 제어할 수 있습니다.

1,000 및 500Mbps/TiB: I/O 대역폭이 주된 병목 현상인 파운데이션 모델 학습 또는 대규모 물리 시뮬레이션과 같이 처리량이 중요한 워크로드에 적합합니다.
250Mbps/TiB: 균형 잡힌 비용 효율적인 등급으로, 많은 일반적인 HPC 워크로드와 AI 추론 서빙, 데이터 집약적인 분석 파이프라인에 적합합니다.
125Mbps/TiB: 최대 처리량을 달성하는 것보다 대규모의 POSIX 규격 파일 시스템을 갖추는 것이 더 중요한 대용량 사용 사례에 가장 적합합니다. 또한 컨테이너화된 온프레미스 애플리케이션을 별도의 수정 없이 마이그레이션하는 데도 유용하므로 온프레미스 워크로드를 클라우드 스토리지로 더 쉽게 마이그레이션할 수 있습니다.

권장하는 이유: 무조건 최고 등급을 선택하는 것이 항상 비용 효율적인 전략은 아닙니다. 워크로드의 I/O 프로필을 분석하면 총소유비용을 크게 최적화할 수 있습니다.

3. 네트워킹 기반 구축

병렬 파일 시스템은 네트워크로 연결되는 리소스입니다. 네트워킹을 처음부터 올바르게 설정하면 문제 해결에 드는 시간을 줄일 수 있습니다. 프로비저닝하기 전에 문서의 설정 단계를 따라 VPC가 올바르게 구성되었는지 확인하세요. 이 과정은 문서에 자세히 설명된 아래 세 가지 주요 단계로 이루어져 있습니다.

서비스 네트워킹을 사용 설정합니다.
VPC 피어링의 IP 범위를 만듭니다.
Lustre 네트워크 포트(TCP 988 또는 6988)에서 해당 범위의 트래픽을 허용하도록 방화벽 규칙을 만듭니다.

권장하는 이유: VPC당 한 번만 설정하면 되는 작업으로, GKE 노드가 Managed Lustre 서비스와 통신할 수 있도록 안전한 피어링 연결이 설정됩니다.

4. 단순성을 원한다면 동적 프로비저닝을, 장기 공유 데이터에는 정적 프로비저닝을 사용

Managed Lustre CSI 드라이버는 스토리지와 GKE 워크로드를 연결하는 두 가지 모드를 지원합니다.

동적 프로비저닝: 스토리지가 특정 워크로드나 애플리케이션의 수명 주기가 긴밀하게 연결되어 있는 경우 사용합니다. StorageClass와 PersistentVolumeClaim(PVC)을 정의하면 GKE가 자동으로 Lustre 인스턴스 수명 주기를 관리해 줍니다. 가장 간단하고 자동화된 접근방식입니다.
정적 프로비저닝: 장기 Lustre 인스턴스를 여러 GKE 클러스터와 작업 간에 공유해야 하는 경우에 사용합니다. Lustre 인스턴스를 한 번 만든 후 클러스터에서 마운트하기 위해 PersistentVolume(PV)과 PVC를 만듭니다. 이렇게 하면 스토리지 수명 주기가 단일 워크로드에서 분리됩니다.

권장하는 이유: 데이터 수명 주기를 고려하면 적절한 패턴을 선택하는 데 도움이 됩니다. 단순성을 위해 기본적으로 동적 프로비저닝을 사용하고, 파일 시스템을 조직 전체에서 지속적으로 공유되는 리소스로 취급해야 하는 경우에는 정적 프로비저닝을 선택하세요.

5. Kubernetes 작업으로 병렬 처리 설계

데이터 전처리 또는 일괄 추론과 같은 많은 AI 및 HPC 작업은 병렬 실행에 적합합니다. 하나의 대규모 포드를 실행하는 대신 Kubernetes 작업 리소스를 사용하여 작업을 여러 개의 작은 포드로 나누세요.

다음 패턴을 고려하세요.

Managed Lustre 인스턴스에 대해 단일 PersistentVolumeClaim을 만들어 클러스터에서 사용할 수 있도록 합니다.
병렬 처리 수를 높게 설정한 Kubernetes 작업을 정의합니다(예: 100).
작업에서 생성된 각 포드는 동일한 Lustre PVC를 마운트합니다.
애플리케이션을 설계할 때 각 포드가 데이터의 서로 다른 하위 집합(예: 서로 다른 범위의 파일 또는 데이터 청크 처리)에서 작동하도록 만듭니다.

권장하는 이유: 이 패턴에서는 Lustre 인스턴스에 대해 단일 PVC를 만들고, 작업에서 생성된 각 포드가 동일한 PVC를 마운트하도록 합니다. 각 포드가 데이터의 서로 다른 하위 집합에서 작동하도록 애플리케이션을 설계하면 GKE 클러스터를 강력한 분산 데이터 처리 엔진으로 전환할 수 있습니다. GKE 작업 컨트롤러는 병렬 작업을 조정하는 역할을 하고 Managed Lustre는 고속 데이터 백본 역할을 함으로써, 대규모 집계 처리량을 달성할 수 있습니다.

지금 시작하기

GKE의 조정 기능과 Managed Lustre의 성능을 결합하면 진정으로 확장 가능하고 효율적인 AI 및 HPC 플랫폼을 빌드할 수 있습니다. 이 권장사항을 따르면 강력하면서도 효율적이고 비용 효과적이며 관리하기 쉬운 솔루션을 만들 수 있습니다.

시작할 준비가 되셨나요? Managed Lustre 문서를 살펴보고 지금 바로 첫 번째 인스턴스를 프로비저닝하세요.

인스턴트 스냅샷: Compute Engine 워크로드의 오류와 손상 방지

Mon, 17 Mar 2025 10:57:00 +0000

* 본 아티클의 원문은 2024년 8월 31일 Google Cloud 블로그(영문)에 게재되었습니다.

여러분이 애플리케이션 관리자이고 1시간의 유지보수 동안 애플리케이션 업그레이드를 수행해야 하는데 갑자기 업그레이드에 실패했다고 생각해 보세요. 이런 상황에서는 롤백 절차를 시작하게 됩니다. 일반적인 롤백 과정에서는 정기적인 스냅샷을 바탕으로 몇 분간 복구를 진행하게 되는데, 작업 완료에 필요한 시간은 복원할 데이터양에 따라 달라집니다. 애플리케이션의 사전 업그레이드 복제본을 바탕으로 복원하는 방법도 있지만 이는 유지 비용이 많이 든다는 단점이 있습니다.

유지보수 기간을 더 여유롭게 확보하고 롤백 시간도 예측할 수 있으며 비용 효율적이면서도 디스크 크기에 구애받지 않는 아주 빠른 복구 솔루션이 있다면 어떨까요?

오늘 소개해 드릴 Compute Engine의 인스턴트 스냅샷은 필요에 따라 신속하게 복원 가능하도록 거의 즉각적인 고빈도 특정 시점 디스크 체크포인트를 제공합니다.

인스턴트 스냅샷은 몇 초 단위의 목표 복구 시간(RPO)과 수십 초 단위의 복구 시간 목표(RTO)를 제공합니다. Google Cloud는 단 몇 초면 복구가 가능한 고성능 체크포인트를 제공하는 유일한 하이퍼스케일러입니다. 타사 하이퍼스케일러를 사용할 경우 워크로드가 최대 성능으로 복구되기까지 수십 분 또는 몇 시간이 걸릴 수 있지만 인스턴트 스냅샷으로 복구를 진행하면 Compute Engine 워크로드가 최대 디스크 성능으로 즉시 실행됩니다.

Compute Engine의 인스턴트 스냅샷을 사용해 복구를 진행하려면 핵심 인프라에 아무 문제가 없어야 하며 데이터를 이전 상태로 롤백해야 합니다. 일반적인 사용 사례는 다음과 같습니다.

사용자 오류, 애플리케이션 소프트웨어 장애, 파일 시스템 손상을 신속하게 복구합니다.
데이터베이스 워크로드 등을 위한 백업 인증 워크플로에서 주기적인 스냅샷을 생성한 뒤 즉시 복원하여 데이터 일관성 검사를 실행합니다.
예정된 유지보수에 실패한 경우 신속한 롤백이 가능하도록 애플리케이션 업그레이드 전에 복원 지점을 설정합니다.

위 사용 사례 외에도 인스턴트 스냅샷을 사용하면 다음과 같은 이점이 있습니다.

개발자 생산성 개선: 빠른 개발 주기에서 빌드 시간이 길거나 코드가 복잡한 경우 실수로 인한 오류가 발생하거나 빌드에 실패하면 작업을 완료하는 데 걸리는 시간이 늘어납니다. 인스턴트 스냅샷을 사용하면 외부 백업에 의존하지 않아도 빠른 복원이 가능합니다.
백업 전 상태 확인: 수행한 백업이 사용 가능하고 원하는 상태인지 확인할 수 있습니다. 장기 백업을 시작하기 전에 인스턴트 스냅샷을 사용해 디스크를 검사하고 클론하여 예비 머신에서 확인할 수 있습니다.
백업 빈도 증가: 인스턴트 스냅샷을 사용하면 긴 백업 시간을 기다릴 여유가 없는 대용량의 비즈니스 크리티컬 데이터베이스를 더 자주 백업할 수 있습니다.

인스턴트 스냅샷의 주요 특징

Compute Engine 인스턴트 스냅샷은 기존 스냅샷에 비해 더 많은 이점을 가지고 있습니다.

인플레이스 백업: 인스턴트 스냅샷은 영역 디스크 또는 리전 디스크에 생성되며 소스 디스크 및 미디어 유형과 동일한 위치에 저장됩니다. 다시 말해 SDD 또는 HDD 유형의 디스크에서 생성된 인스턴트 스냅샷은 동일한 디스크에 저장됩니다. 인스턴트 스냅샷은 생성 시 고정 요금이 부과되며 사용하는 스토리지가 늘어남에 따라 추가 요금이 책정됩니다.
신속성 및 증분성: 인스턴트 스냅샷은 몇 초면 생성되며 각 인스턴트 스냅샷에는 이전 인스턴트 스냅샷이 생성된 이후 변경된 증분 데이터 블록만 저장됩니다. 스냅샷 생성 빈도가 훨씬 높기 때문에 백업 스냅샷보다 더 자주 스냅샷을 생성할 수 있습니다.
빠른 디스크 복원: 단 몇 초면 각 인스턴트 스냅샷을 새 디스크에 복원할 수 있습니다. 이러한 새 디스크는 스냅샷과 동일한 영역에 위치하며 해당 디스크 유형을 상속합니다.
백업 또는 보관 파일로 변환 가능: 장기 지리적 중복 스토리지를 위한 보조 접속 지점으로 인스턴트 스냅샷을 옮길 수 있습니다.

인스턴트 스냅샷의 실행 방식

인스턴트 스냅샷은 초기 체크포인트와 비교하여 변경된 데이터만 저장하기 때문에 몇 초면 생성이 가능합니다.

따라서 위 예시에서도 인스턴트 스냅샷 생성 시 체크포인트가 만들어지지만 이 디스크의 세 번째 블록에 새 데이터를 덮어쓸 때만 데이터가 저장됩니다. 여기에서 블록 6 및 7에 데이터를 쓴 것처럼 데이터를 추가한 경우에도 체크포인트에 추가 스토리지가 필요하지 않습니다.

스토리지를 아주 효율적으로 사용할 수 있을 뿐 아니라 성능 효율성 또한 탁월한 셈입니다. 인스턴트 스냅샷 생성 시 기본 디스크의 성능에 아무 영향을 미치지 않으며, 앞서 언급했듯이 단 몇 초면 인스턴트 스냅샷을 만들고 복원할 수 있습니다.

표준 변경 관리 및 유지보수 과정에서 이와 같은 스토리지와 성능, 비용 효율성을 갖춘 인스턴트 스냅샷을 사용하면 워크로드를 더욱 쉽고 효율적으로 보호할 수 있습니다.

스냅샷 유형 비교

다음과 같은 인스턴트 스냅샷의 여러 가지 성능 특성 개요에서 표준 백업 스냅샷과의 차이점을 살펴보세요.

사용 사례

애플리케이션 관리자인 Maya는 영구 디스크 볼륨에 호스팅된 소프트웨어를 업그레이드해야 합니다. 이 작업에 주어진 유지보수 기간은 단 1시간입니다. 유지보수 기간이 끝난 후 볼륨에 새 소프트웨어가 포함되어 있으면 업그레이드에 성공한 것이며, 업그레이드에 실패할 경우 유지보수 기간이 시작되기 직전과 정확히 동일한 상태, 즉 롤백 상태가 됩니다.

정기적인 스냅샷과 인스턴트 스냅샷 사용 시 Maya의 워크플로가 어떻게 달라지는지 비교해 보세요.

지금 바로 사용하기

인스턴트 스냅샷은 거의 즉각적인 온디바이스 특정 시점 백업을 제공하여 신속한 복원과 고빈도 백업을 지원합니다. 또한 애플리케이션 업그레이드 기간을 최적화하고 외부 백업에 드는 시간을 절약하는 데 도움이 되며 업그레이드 실패 또는 사용자 오류 발생 시 빠른 복원을 가능하게 합니다.

Persistent Disk 인스턴트 스냅샷을 활용하는 방법은 인스턴트 스냅샷 문서 페이지를 참조하세요.

AI 기반 쿼리 및 인사이트를 통해 Cloud Storage 사용 현황 파악하기

Mon, 17 Mar 2025 08:31:00 +0000

* 본 아티클의 원문은 2024년 10월 2일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Cloud Storage는 단순성과 경제성, 무한대에 가까운 확장성 덕분에 클라우드 배포를 위한 핵심 솔루션으로 많은 고객의 선택을 받고 있습니다. 그러나 수많은 프로젝트에서 수백 명의 개발자가 협업하여 수백만에서 수십억 개의 객체를 관리하는 작업은 상당히 복잡할 수 있으며, 분석팀이 데이터를 수동으로 분석하여 인사이트를 얻어야 하는 경우도 많습니다. 2024년 초 Google Cloud는 Cloud Storage를 위한 강력하고 새로운 스토리지 인사이트 생성 기능의 실험 버전을 소개한 바 있습니다. 가장 규모가 크고 성능이 뛰어난 AI 모델인 Gemini를 활용한 스토리지 인사이트 생성 기능을 사용하면 질문을 통해 Cloud Storage 환경에 대한 유용한 인사이트를 발견할 수 있습니다.

스토리지 인사이트 생성 기능의 이점

수동 데이터 분석 과정을 없애고 신속하게 답을 얻을 수 있습니다.
잠재적인 보안 및 규정 준수 위험을 사전에 발견할 수 있습니다.
비용 절감 기회를 파악하여 스토리지 비용을 최적화할 수 있습니다.

Google Cloud는 객체 메타데이터를 쿼리하고 대규모 언어 모델(LLM)을 사용하여 특정 환경에 맞는 스토리지 인사이트를 생성하는 최초의 하이퍼스케일 클라우드 제공업체입니다. Cloud Storage 객체 메타데이터에서 직접 생성된 이러한 AI 기반 인사이트는 수십억 개에 달하는 객체 규모에서도 새로운 차원의 제어와 이해를 가능하게 합니다. 이 블로그 게시물은 스토리지 인사이트 생성을 시작하는 방법을 제시하고, AI 어시스턴스가 스토리지 운영에 어떤 도움이 되는지 안내합니다.

Gemini로 스토리지 인사이트 생성

먼저 여러 Google Cloud 프로젝트와 BigQuery 연결 데이터 세트의 리전에 걸쳐 모든 객체 및 버킷 메타데이터를 수집하고 중앙화하는 새로운 기능인 Storage Insights 데이터 세트를 설정해야 합니다. 각 데이터 세트는 24시간마다 새로고침되며 최대 90일의 과거 데이터를 보관할 수 있습니다. 데이터 세트를 설정하는 동안 Gemini 옵션으로 인사이트 생성을 선택해야 합니다.

초기 설정이 끝나면 데이터 세트에 대한 간단한 요약이 포함된 고급 사용자 환경에 액세스할 수 있게 됩니다.

시작할 때 활용할 수 있도록 미리 선별하여 검증된 응답이 있는 프롬프트 조합이 제공됩니다. 이 프롬프트는 고객들이 가장 자주 묻는 질문을 바탕으로 선별되었습니다. 맞춤 프롬프트를 작성하기 위한 출발점으로 삼기에도 아주 좋습니다.

Google Cloud 콘솔 UI의 Storage Insights 시작 페이지

선별된 프롬프트 중 하나를 선택하면 검증된 응답이 표시됩니다. 응답은 차트로도 제공되어 복잡한 데이터를 명확한 시각적 표현으로 변환할 수 있으며, 이를 통해 주요 정보를 쉽게 이해하고 분석하며 팀끼리 공유할 수 있습니다.

Google Cloud 콘솔 UI의 Storage Insights 응답 페이지

또한 멀티턴 채팅을 사용하여 인사이트를 더 자세히 살펴보고 나만의 대화형 분석을 실행할 수 있습니다. 아래 예시는 수백만 개의 객체에 대한 메타데이터를 조합하여 자연어 프롬프트에 응답하는 것을 보여줍니다. 모든 응답에는 기본 쿼리가 함께 표시되며 클릭 한 번으로 BigQuery로 이동하여 쿼리를 편집하거나 수정할 수 있습니다.

Google Cloud 콘솔 UI의 Storage Insights 응답 페이지

신뢰성, 정확성, 안전성

생성형 AI의 강력한 기능에도 불구하고 가끔 할루시네이션이 발생할 수 있습니다. 따라서 Google Cloud는 생성된 답변을 평가하는 데 도움이 되는 여러 가지 정보 지표를 함께 제공해 드립니다. 모든 응답에는 간편한 검증을 위해 SQL 쿼리가 포함되며, 선별된 프롬프트에는 '높은 정확성' 태그가 표시되고, 데이터 최신 상태에 대한 유용한 정보가 제공됩니다. 좋아요/싫어요 아이콘을 사용하여 응답에 대한 의견을 공유할 수도 있습니다.

Google Cloud는 자연어를 적절한 SQL 쿼리로 변환하고, 데이터 세트를 쿼리하고, 응답을 요약하는 데 AI 모델을 사용합니다. 고객의 객체와 버킷 메타데이터는 전적으로 고객에게 귀속되며 Google Cloud의 AI 모델 학습에 사용되지 않습니다. 고객이 의견 옵션을 통해 공유하도록 선택하지 않는 한 고객의 프롬프트는 저장되지 않습니다. 데이터 세트에는 선택한 프로젝트를 기반으로 한 객체 및 버킷 메타데이터만 포함되며 객체 콘텐츠에는 액세스할 수 없습니다. 아울러 Google Cloud는 Google의 책임감 있는 AI 접근 방식을 통해 모델의 답변을 검증하고 콘텐츠의 안전성을 높입니다.

더 단순하고 쉬운 스토리지 관리

새로운 기능과 더불어 Cloud Storage는 규모에 맞게 스토리지를 더욱 쉽고 효율적으로 관리할 수 있는 종합적인 관리 기능을 제공합니다. Cloud Storage 고객이라면 지금 바로 Google Cloud 계정팀에 문의하여 Gemini를 통해 인사이트 생성을 시작해 보세요. 자세한 내용은 Google Cloud Next 2024의 ‘Managing Google Cloud Storage at Scale with Gemini(Gemini로 규모에 맞게 Cloud Storage 관리하기)’ 세션 녹화 동영상을 참조하세요.

블록 스토리지 성능을 훨씬 간단하게 계획하고 관리하는 방법

Mon, 17 Mar 2025 05:20:00 +0000

* 본 아티클의 원문은 2024년 9월 4일 Google Cloud 블로그(영문)에 게재되었습니다.

2024년 초 Google Cloud는 블록 스토리지 용량을 간편하게 관리하고 총소유비용(TCO)을 절감하는 데 도움이 되는 Hyperdisk Storage Pool의 고급 용량 정식 버전을 발표했습니다. 이제, 이와 동일한 수준의 혁신을 블록 스토리지 성능에 제공할 Hyperdisk Storage Pool의 고급 성능 유형을 소개합니다. 이제 애플리케이션이 데이터를 읽고 씀에 따라 Hyperdisk Storage Pool이 동적으로 할당하는 IOPS와 처리량을 종합적으로 프로비저닝하여 리소스 사용률을 높이고 성능 계획 및 관리를 대폭 간소화할 수 있습니다.

Google Cloud 콘솔에서 지금 바로 고급 성능 스토리지 풀을 시작할 수 있습니다. 고급 성능 스토리지 풀은 Google Cloud에서 제공하는 Hyperdisk 블록 스토리지 제품군의 일부로, 여기에서 자세히 알아보실 수 있습니다.

난제: 적절한 양의 성능 리소스 프로비저닝하기

많은 고객이 모든 블록 스토리지 성능 리소스를 활용하는 일과 워크로드를 성공적으로 처리하기 위해 필요한 리소스를 확보하는 일 사이에서 균형을 이루는 데 어려움을 느끼고 있습니다. 이러한 상황의 근본 원인은 '피크의 합'이라고도 하는 문제에서 찾을 수 있습니다. 고객은 워크로드의 성능이 저하되지 않게 하기 위해 그동안의 관찰을 바탕으로 블록 스토리지를 최대 성능으로 프로비저닝하는 경우가 많지만, 대부분의 경우 디스크가 소비하는 성능은 이보다 훨씬 적습니다. 이는 디스크의 성능 사용률이 만성적으로 낮다는 의미입니다. 이러한 현상은 아래와 같이 시각화할 수 있습니다.

고급 성능 스토리지 풀을 통해 40~50% 더 낮은 TCO 달성하기

Google Cloud는 이 문제를 해결하기 위해 Hyperdisk Storage Pool의 고급 성능 유형을 마련했습니다. 고급 성능 스토리지 풀을 사용하면 워크로드의 성공적인 처리와 높은 성능 사용률 사이에서 고민할 필요가 없습니다. Hyperdisk Storage Pool의 고급 성능 유형에서는 사용자가 성능을 종합적으로 프로비저닝하고, 스토리지 풀이 필요에 따라 풀 내 디스크 전반에 리소스를 지능적으로 배포합니다. 이때 디스크의 작동 방식을 변경하지 않아도 되므로 애플리케이션이 정상적으로 실행됩니다. 애플리케이션의 성공적인 실행이나 리소스 효율성을 타협하는 일 없이 간편하게 성능 니즈를 계획하고 TCO를 절감할 수 있습니다.

몇 가지 워크로드 예시를 통해 Hyperdisk Storage Pool의 고급 성능 유형으로 어떻게 TCO를 낮출 수 있는지 알아보겠습니다. 최대 25,000IOPS(예: 모든 사용자가 동시에 로그인할 경우)가 필요하지만 안정적인 상태에서는 10,000IOPS가 필요한 엔터프라이즈 애플리케이션 제품군과 최대 75,000IOPS(예: 분기 보고서 제출 마감일인 경우)가 필요하지만 안정적인 상태에서는 35,000IOPS가 필요한 데이터베이스 워크로드가 있다고 가정해 보겠습니다. 풀 외부에서 이러한 워크로드의 성능 사용률은 40~45%일 겁니다. 안정적인 상태에서의 성능은 프로비저닝된 성능의 절반 수준이기 때문입니다. 하지만 Hyperdisk Storage Pool 고급 성능 유형의 동적 리소스 할당을 사용하면 이러한 워크로드를 약 80%의 사용률로 실행할 수 있으며, 고객은 워크로드를 변경할 필요 없이 프로비저닝해야 하는 성능 리소스를 대폭 줄이고 TCO를 40~55% 절감할 수 있습니다.

블록 스토리지 성능 간소화 및 계획

고급 성능 스토리지 풀은 성능 리소스를 프로비저닝하는 방법을 근본적으로 혁신합니다. 지금까지 인프라 관리자는 낮은 사용률을 감수하고 성능을 최적화하는 방안과 애플리케이션 오류의 리스크를 감수하고 효율성을 최적화하는 방안 중 하나를 선택해야 했습니다. 즉, 각 볼륨의 성능을 적극적으로 관리하고 반복적인 관리 업무를 감당해야 했습니다.

Hyperdisk 고급 성능 스토리지 풀은 블록 스토리지 성능 관리를 간단하게 만들어 줍니다. 고급 성능 스토리지 풀의 디스크 IOPS와 처리량은 '씬 프로비저닝'됩니다. 다시 말해, 디스크 수준에서 성능을 프로비저닝할 때 리소스를 소비하지 않으며 풀에 풀 내 디스크의 최대 5배에 달하는 IOPS 및 처리량을 프로비저닝할 수 있습니다. 그러면 더 이상 각 디스크의 성능 니즈를 정확하게 예측할 필요가 없으므로 배포를 계획하기가 쉬워지며, 각 디스크에 할당된 IOPS와 처리량을 적극적으로 관리하지 않아도 되기 때문에 높은 효율성을 달성하게 됩니다. 필요한 만큼 높은 성능을 갖춘 디스크를 간단히 만들고, 필요할 때 고급 성능 스토리지 풀이 리소스를 할당하도록 할 수 있습니다.

고급 성능 스토리지 풀을 초기에 이용한 REWE 같은 고객은 그 가치를 직접 경험했습니다.

"REWE에서는 배포를 계획할 때 애플리케이션의 성능 급증을 예측해야 한다는 고충이 있었습니다. 스토리지 리소스의 성능 사용률을 적극적으로 관리하는 일은 더 어려웠죠. 고급 성능 스토리지 풀 덕분에 이 두 문제를 모두 해결할 수 있었습니다. 인프라에 고급 성능 풀을 도입하여 TCO와 반복 업무를 줄일 수 있게 되어 정말 후련합니다." – Jan Rundshagen, REWE 인프라 관리자

시작하기

Hyperdisk Storage Pool을 만드는 것과 동일한 워크플로를 통해 Hyperdisk 고급 성능 스토리지 풀을 시작할 수 있습니다. Google Cloud 콘솔에 로그인하고 Compute Engine으로 이동해 스토리지를 찾으세요. 그런 다음 스토리지 풀을 만들고 볼륨 유형(균형 또는 처리량)과 고급 성능을 선택하고 풀에 필요한 전체 용량과 성능을 설정합니다. 풀에 새 Hyperdisk 볼륨을 만드는 데에서 시작하면 기존 스토리지 풀처럼 풀의 용량을 공유하는 것은 물론 리소스 전반에 동적으로 성능을 공유할 수 있다는 또 다른 이점이 있습니다.

고급 성능 스토리지 풀을 통해 애플리케이션의 성능 효율성을 달성하고 관리하는 방식을 근본적으로 개선할 수 있기를 바랍니다. Hyperdisk 고급 성능 스토리지 풀은 현재 여러 리전과 영역에 출시되고 있습니다. 지금 바로 Google Cloud 콘솔에서 고급 성능 스토리지 풀 사용을 시작하거나 관련 문서에서 고급 성능 스토리지 풀을 만들고, 사용하고, 관리하는 방법을 자세히 알아보세요.

새로운 데이터 저장 리전 보장을 통한 전 세계 생성형 AI 혁신 가속화

Wed, 13 Dec 2023 01:00:00 +0000

*본 아티클의 원문은 2023년 11월 14일 Google Cloud 블로그(영문)에 게재되었습니다.

엔터프라이즈 생성형 AI 서비스에 대한 수요가 전 세계적으로 증가하고 있습니다. 생성형 AI를 최대한 활용할 방법이 모색되는 한편, 데이터 주권과 글로벌 규제 요건이 강조되는 환경 속에서 많은 기업이 데이터가 저장되는 리전을 설정할 수 있기를 바라고 있습니다.

이러한 요청에 부응하여, Google Cloud의 생성형 AI 서비스를 사용하는 고객은 북미, 유럽, 아시아의 10개 국가 중 어느 곳이든 저장 데이터를 보관할 수 있게 되었습니다. 이번 발표는 고객을 위한 데이터 저장 리전을 확대하고 업계의 요구를 충족하기 위한 지속적인 노력의 일환입니다.

새로운 Vertex AI 데이터 저장 리전

Google Cloud는 Vertex AI 생성 기능에 대한 새로운 데이터 저장 리전 약정과 더불어 일반 서비스 약관에 따라 고객이 선택한 리전을 고객 데이터를 보관할 것을 약속합니다. 여기에는 구체적으로 다음 사항이 포함됩니다.

Text Embeddings API 및 Multimodal Embeddings API뿐만 아니라 PaLM2, Codey, Imagen 모델을 포함하는 Vertex AI의 생성형 AI는 고객에게 다음과 같은 데이터 저장 옵션을 제공합니다.
- 북미: 미국 및 캐나다
- 유럽: 네덜란드, 독일, 벨기에, 영국, 프랑스
- 아시아: 대한민국, 싱가포르, 일본
Vertex AI Search는 고객에게 다음과 같은 데이터 저장 옵션을 제공합니다.
- 북미: 미국(멀티 리전)
- 유럽: EU(멀티 리전)
Vertex AI Conversation은 고객에게 다음과 같은 데이터 저장 옵션을 제공합니다.
- 북미: 미국(멀티 리전)
- 유럽: EU(멀티 리전)

"Minna Bank는 Vertex AI에서 생성형 AI 서비스를 사용할 예정인데, 이는 PaLM2와 같은 생성형 AI 서비스와 관련해 Google Cloud가 제공하는 일본 내 데이터 저장 리전 약정 때문입니다. 이는 높은 수준의 개인 정보 보호, 보안, 거버넌스를 요구하는 금융 업계 및 기타 업종에 매우 중요한 변화였습니다. 이제 데이터 저장 리전을 제어할 수 있기 때문입니다." - Masaaki Miyamoto, Executive Officer & CIO, Minna Bank

앞으로 전 세계 더 많은 지역에서 Google Cloud 고객에게 데이터 리전 제어가 가능한 생성형 AI 기능을 제공할 수 있게 되길 기대합니다.

엔터프라이즈급 생성형 AI

새로운 데이터 리전 보장을 통해 엔터프라이즈급 규모, 안전, 보안, 개인 정보 보호를 갖춘 AI 서비스를 제공하기 위해 계속 노력할 것입니다. Google Cloud는 전 세계의 조직이 AI의 잠재력을 활용할 수 있도록 Google의 연구 성과를 제품에 적용하는 데 중요한 역할을 수행하고 있습니다.

고객 데이터 및 개인 정보 보호는 언제나 Google Cloud의 사명에서 핵심 역할을 해왔으며, AI가 계속 발전하고 점차 대규모로 채택되면서 이러한 노력은 그 어느 때보다 중요해졌습니다. 새로운 데이터 저장 리전 외에 고객 데이터 및 개인 정보 보호 처리 방식에 관한 주요 사실 몇 가지도 함께 알려드립니다.

고객은 자체 데이터와 모델을 제어하며 그에 대한 액세스도 제어합니다. 조직은 데이터와 모델에 액세스할 수 있는 사용자와 이러한 애셋을 사용할 수 있는 방식을 결정합니다.
고객은 데이터와 모델을 저장하는 리전과 방법을 제어합니다. 조직은 원하는 리전에 데이터를 저장하도록 선택하여 지정된 지리적 경계를 벗어난 배포를 방지할 수 있습니다.
Google은 고객 데이터를 절대 사용하지 않습니다. Google의 모델, 또는 다른 기업이 사용하는 모델을 훈련하는 데 고객 데이터를 무단으로 사용하지 않습니다.
고객 데이터는 필요할 때 언제든 사용할 수 있습니다. Google의 데이터 센터와 네트워크 아키텍처는 안정성과 복원력을 최대화하도록 설계되었으며, Google의 AI 제품은 다른 Google Cloud 서비스와 동일한 고가용성 표준을 따릅니다.
고객은 기본적으로 엔터프라이즈급 보안과 개인 정보 보호를 누릴 수 있습니다. Google Cloud의 AI 서비스를 사용하면 보안 관련 특정 요구 사항이나 규제 요건을 충족하기 위해 조직에서 데이터와 모델 전반에 걸쳐 개인 정보 보호와 세분화된 보안 제어를 적용할 수 있습니다.

또한 Google Cloud는 기술적 제어와 계약 약관, 업계에서 인정하는 인증과 감사를 통해 이러한 보장을 뒷받침합니다. 즉 조직이 Google의 AI 플랫폼에서 모델을 빌드하거나 조정할 때 Google은 위험 관리를 위한 공동의 운명 접근 방식을 채택하여 첫날부터 조직과 협력하며 데이터와 모델을 보호합니다. 이러한 노력에는 사이버 보안에 대한 협력적인 접근법과 함께 기업이 AI 관련 위험을 완화하기 위한 실질적인 고려 사항을 제공하는 보안 AI 프레임워크(SAIF) 개발이 포함됩니다.

Google Cloud는 데이터 저장 리전 약정을 계속 확대할 것으로 기대하며 더 많은 소식을 공유할 예정입니다. Google Cloud가 AI 서비스를 개발하는 방식에 대한 자세한 내용은 책임감 있는 AI 페이지를 참조하세요. Google의 AI 플랫폼에 대해 알아보려면 여기를 클릭하세요.

맞춤설정 가능한 모니터링 대시보드로 시스템 관측 가능성을 향상시키는 Cloud Storage

Mon, 02 Jan 2023 00:00:00 +0000

* 본 아티클의 원문은 2022년 11월 15일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Cloud Storage는 비정형 데이터를 저장하고 사용자가 원하는 만큼 데이터를 가져올 수 있는 관리형 서비스입니다. Cloud Storage는 활용도가 높은 기본 서비스이기 때문에 스토리지 관측 가능성이 스토리지 엔지니어와 관리자의 일상적인 운영 업무에 매우 중요하며 비즈니스의 확장성과 지속 가능성을 위해서도 중요합니다.

스토리지 관측 가능성과 관련해 Cloud Storage 사용자들은 다음과 같은 질문을 합니다.

스토리지 프로젝트 및 버킷 관측을 시작하기 위한 권장사항은 무엇인가요?
문제를 사전에 식별하고 해결하기 위해 모니터링해야 할 가장 중요한 운영 측정항목/로그는 무엇인가요?
내가 관심을 두고 있는 스토리지 측정항목에 대한 알림을 만들려면 어떻게 하면 되나요? 스토리지 프로젝트 안에서 알림을 확인하거나 버킷에 대한 알림을 볼 수 있나요?

또한 사용자들은 여러 관측 가능성 도구를 오가야 하기 때문에 다양한 모니터링 플랫폼 간에 이동하는 동안 컨텍스트를 놓치는 경우가 많다고 말합니다.

오늘 Google에서는 프로젝트 수준과 버킷 수준 모두에서 사용할 수 있는 새로운 Cloud Storage용 모니터링 대시보드를 공개 미리보기 버전으로 출시한다는 기쁜 소식을 전해드립니다.

이제 모든 Cloud Storage 사용자가 왼쪽 탐색 메뉴에서 모니터링 탭을 통해 새 대시보드를 이용할 수 있습니다.

니즈에 따른 고도의 맞춤설정

Google은 모든 사용자의 니즈를 충족할 수 있는 단일 관측 가능성 도구란 없다는 사실을 잘 알고 있습니다. 사용자가 자신만의 대시보드 버전을 만들고 기본 뷰로 설정할 수 있도록 대시보드를 컨텍스트에 따라 맞춤설정할 수 있게 만든 이유가 바로 여기에 있습니다. 모니터링 편집자 또는 소유자 액세스 권한이나 프로젝트 편집자 또는 소유자 액세스 권한이 있다면 전에 만든 알림 정책에서 알림 차트를 추가하거나 즉시 사용 가능한 대시보드를 맞춤설정하여 알림을 만들 수 있습니다. 맞춤설정된 대시보드에 알림 차트를 추가하면 Cloud Storage 모니터링 페이지에서 컨텍스트별로 알림을 직접 확인할 수 있습니다. 또한 Google Cloud 콘솔의 스토리지 페이지를 벗어나지 않고도 대시보드에 여러 서비스의 측정항목을 추가하여 상관관계를 관측할 수 있습니다.

로그 패널에서는 관심을 두고 있는 가장 중요한 로그를 반영하도록 로그 뷰어 쿼리를 수정하고 해당 쿼리를 스토리지 프로젝트 맞춤설정 대시보드에서 유지할 수 있습니다. 동일한 대시보드에서 측정항목과 로그를 살펴볼 수 있어 컨텍스트 전환이 줄어들고 보다 효과적으로 문제를 해결할 수 있습니다.

맞춤설정 가능한 대시보드를 사용하면 플랫폼의 스토리지 페이지 내에서 문제 해결 과정을 수행할 수 있으므로 여러 모니터링 도구나 모니터링 플랫폼 간에 이동할 필요성이 줄어듭니다.

즉시 사용 가능한 운영 측정항목

스토리지 관측 가능성에는 여러 가지 측면이 있는데 새 모니터링 대시보드는 문제 해결에 초점을 맞추고 있습니다. 여기에는 모든 스토리지 사용자가 Google Cloud에서 스토리지 서비스를 시작할 때 자동으로 받게 되는 즉시 사용 가능한 스토리지 시스템 측정항목과 스토리지 시스템 로그가 포함됩니다.

Cloud Monitoring UI에서 차트 위로 마우스를 가져가 값을 읽거나 범례를 펼치고, 기간을 확대 또는 축소하여 데이터를 보다 상세하게 또는 간략하게 살펴보고, MQL 또는 PromQL 같은 고급 쿼리를 사용할 수 있습니다. 실제로 Google Cloud 콘솔의 스토리지 페이지 내에서 Cloud Monitoring 대시보드의 모든 기능을 사용할 수 있습니다.

대시보드에서 사용할 수 있는 차트와 로그 패널에 대해 자세히 살펴보도록 하겠습니다.

차트

Storage API 요청 수의 서버 오류율: 모든 서버 측 5xx 오류를 표시하도록 필터링합니다.

Storage API 요청 수의 클라이언트 오류율: 응답 코드를 포함해 모든 클라이언트 측 4xx 오류를 표시하도록 필터링합니다.

읽기 오류가 가장 많이 발생한 상위 5개 버킷: 응답 코드가 INTERNAL 및 UNAVAILABLE 오류인 List 및 Read 메서드로 필터링되며 상위 5개 버킷에서 측정됩니다. 이러한 오류가 발생한 버킷을 더 많이 표시하도록 차트를 손쉽게 맞춤설정할 수 있습니다.

쓰기 오류가 가장 많이 발생한 상위 5개 버킷: 읽기 오류가 가장 많이 발생하는 경우와 마찬가지로 이 차트는 응답 코드가 INTERNAL 및 UNAVAILABLE 오류인 WriteObject 메서드로 필터링됩니다.

총 Read/List/Get 요청 수: Read, List, Get 메서드의 API 요청 수로 필터링됩니다. 특정 시간 동안 이 3가지 메서드에 대해 발생한 총 요청 수와 API 메서드의 위치별로 분류한 총개수가 표시됩니다.

총 쓰기 요청 수: 모든 API 요청의 Write 메서드로 필터링되며 쓰기 요청의 총개수가 위치별로 분류되어 표시됩니다.

네트워크의 데이터 인그레스 속도: 수신 바이트 속도를 표시하여 프로젝트당 또는 버킷당 인그레스 속도를 쉽게 파악할 수 있습니다.

프로젝트의 총 수신 바이트 볼륨을 표시하도록 이 차트를 맞춤설정할 수 있습니다.
버킷 수준 대시보드에서는 프로젝트의 버킷당 인그레스 속도를 표시하도록 차트가 필터링됩니다.

네트워크의 데이터 이그레스 속도: 전송 바이트 속도를 표시하여 프로젝트당 또는 버킷당 이그레스 속도를 쉽게 파악할 수 있습니다.

로그 패널

GCS 로그 및 감사 로그 위젯

이 2가지 로그 위젯은 심각도가 오류와 같거나 큰 GCS 로그 및 GCS 감사 로그로 필터링됩니다. 심각도가 오류, 심각, 알림, 긴급에 해당하는 로그가 로그 패널에 표시됩니다.
위젯에서 로그 항목을 펼쳐 '로그 탐색기에서 보기' 버튼을 클릭하면 로그 탐색기 뷰로 쉽게 이동할 수 있습니다.

프로젝트 수준에서 사용할 수 있는 모든 차트가 버킷 수준에서도 제공되며 특정 버킷으로 대시보드가 필터링됩니다. 버킷 수준 대시보드의 맞춤설정이 생성되면 프로젝트 내의 모든 버킷 수준 대시보드에 맞춤설정된 버킷 수준 대시보드가 자동으로 표시됩니다. 간편하게 다른 버킷으로 이동하고 드롭다운 메뉴에서 맞춤설정된 대시보드를 선택해 확인할 수 있습니다.

지금 미리보기로 시작하기

Cloud Storage UI의 왼쪽 탐색 메뉴에서 모니터링 탭을 클릭하면 지금 바로 미리보기를 시작할 수 있습니다. 모든 Cloud Storage 사용자에게 미리보기가 제공됩니다.

이 대시보드를 모든 사용자에게 공개적으로 제공하게 된 것을 기쁘게 생각하며 여러분의 소중한 제안과 의견을 기다리겠습니다.

각 대시보드에서 '의견 보내기' 버튼을 사용하면 의견을 제출할 수 있습니다. 보내주신 모든 제안을 신중하게 검토하고 모든 사용자가 Cloud Storage 내에서 일상적인 운영을 분석하는 데 도움이 되도록 대시보드를 지속적으로 개선해 나가겠습니다.

정식 버전으로 제공되는 Cloud Spanner의 변경 내역

Wed, 17 Aug 2022 01:19:00 +0000

* 본 아티클의 원문은 2022년 5월 28일 Google Cloud 블로그(영문)에 게재되었습니다.

올해 Google Data Cloud Summit에서 Google은 Cloud Spanner 변경 내역을 발표했습니다. 오늘 변경 내역의 정식 버전이 출시된다는 반가운 소식을 전해드립니다. Spanner 사용자는 변경 내역을 사용하여 Cloud Spanner 데이터베이스의 변경사항(삽입, 업데이트, 삭제)을 거의 실시간으로 캡처하고 스트리밍할 수 있습니다.

변경 내역은 변경 데이터를 다른 Google Cloud 서비스와 통합할 수 있는 다양한 옵션을 제공합니다. 일반적인 사용 사례는 다음과 같습니다.

분석: 분석에 사용할 수 있는 최신 데이터가 BigQuery에 있도록 BigQuery에 변경 이벤트를 보냅니다.
이벤트 트리거링: 다운스트림 시스템에서 추가 처리를 위해 Pub/Sub에 데이터 변경 이벤트를 보냅니다.
규정 준수: 보관 목적으로 Google Cloud Storage에 변경 이벤트를 저장합니다.

변경 내역 시작하기

이 섹션에서는 변경 내역을 만들고, 변경 내역 데이터를 읽고, 분석을 위해 BigQuery로 데이터를 보내는 간단한 예시를 살펴봅니다.

아직 숙지하지 않은 경우 Spanner Qwiklab을 통해 Cloud Spanner에 대한 기본사항을 숙지하세요.

변경 내역 만들기

Spanner 변경 내역은 테이블 및 색인 생성 작업과 유사하게 DDL을 사용하여 생성됩니다. 변경 내역 DDL에는 다른 스키마 변경(spanner.databases.updateDdl)과 동일한 IAM 권한이 필요합니다.

변경 내역을 사용하면 열 집합, 테이블 집합 또는 전체 데이터베이스의 변경사항을 추적할 수 있습니다 각 변경 내역의 보관 기간은 1~7일이며, 여러 변경 내역을 설정하여 특정 목표에 필요한 변경사항을 정확하게 추적할 수 있습니다. 변경 내역 만들기 및 관리를 자세히 알아보세요.

다음과 같은 Orders라는 테이블이 있다고 가정해 보겠습니다.

code_block: <ListValue: [StructValue([('code', 'CREATE TABLE Orders (\r\nOrderID INT64 NOT NULL,\r\nCustomerID INT64 NOT NULL,\r\nProductId INT64 NOT NULL,\r\nOrderDate DATE,\r\nPrice INT64,\r\n) PRIMARY KEY(OrderID);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd22bf9f490>)])]>

기본(암시적) 보관 기간이 1일인 전체 Orders 테이블을 추적하는 변경 내역을 만들기 위한 DDL은 다음과 같이 정의됩니다.

code_block: <ListValue: [StructValue([('code', 'CREATE CHANGE STREAM OrdersStream FOR Orders;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd22bf9f9a0>)])]>

변경 내역 만들기는 장기 실행 작업입니다. Cloud 콘솔의 변경 내역 페이지에서 진행 상황을 확인할 수 있습니다.

생성된 변경 내역의 이름을 클릭하면 추가 세부정보가 표시됩니다.

데이터베이스 DDL은 다음과 같이 나타납니다.

이제 변경 내역이 생성되었으므로 변경 내역 데이터를 처리할 수 있습니다.

데이터를 BigQuery로 스트리밍하기

여러 가지 방법으로 변경 내역 데이터를 처리할 수 있습니다. 가장 쉬운 방법은 Apache Beam용 Spanner 커넥터를 사용하는 것으로 이 방법을 통해 Google Cloud Dataflow를 위한 확장 가능한 데이터 처리 파이프라인을 빌드할 수 있습니다. 변경 데이터를 처리하고 BigQuery 또는 Google Cloud Storage에 각각 변경 데이터를 쓸 수 있는 Dataflow 템플릿이 제공됩니다. Cloud Spanner 변경 내역과 Dataflow의 작동 방식을 자세히 알아보세요.

이 예시에서는 BigQuery에 Spanner 변경 내역 작성 템플릿을 사용하여 변경 내역 데이터를 BigQuery에 씁니다.

먼저 Google Cloud 콘솔에서 Dataflow 작업 페이지로 이동합니다. '템플릿에서 작업 만들기'를 클릭하고 'BigQuery에 변경 내역 작성' 템플릿을 선택한 다음 필수 입력란을 작성합니다.

'작업 실행'을 클릭한 다음 Dataflow에서 파이프라인을 빌드하고 작업이 시작될 때까지 기다립니다. Dataflow 파이프라인이 실행되면 Dataflow 작업 페이지에서 작업 그래프, 실행 세부정보, 측정항목을 볼 수 있습니다.

이제 추적 대상인 Orders 테이블에 데이터를 작성해 보겠습니다.

Spanner가 변경 내역에서 추적하는 데이터 세트의 데이터 변경을 감지하면 동일한 트랜잭션 내에서 해당 데이터 변경과 동기화하는 방식으로 데이터 변경 레코드를 씁니다. Spanner는 이러한 쓰기를 모두 같은 위치에 배치하기 때문에 동일한 서버에서 처리되어 쓰기 처리가 최소화됩니다. Spanner가 변경 내역을 쓰고 저장하는 방법을 자세히 알아보세요.

마지막으로 BigQuery 데이터 세트를 보면 변경 내역 레코드에 대한 몇 가지 추가 정보와 함께 방금 삽입한 행이 표시됩니다.

준비가 완료되었습니다. Dataflow 파이프라인이 실행되는 한 추적 대상 테이블의 데이터 변경사항이 BigQuery 데이터 세트로 원활하게 스트리밍됩니다. 파이프라인 모니터링을 자세히 알아보세요.

변경 내역 데이터를 처리하는 다양한 방법

BigQuery 및 Google Cloud Storage용으로 Google에서 제공하는 Dataflow 템플릿을 사용하는 대신 커스텀 Dataflow 파이프라인을 빌드하여 Apache Beam으로 변경 데이터를 처리할 수 있습니다. 이 경우 DataChangeRecord 객체의 Apache Beam PCollection으로 변경 데이터를 출력하는 SpannerIO Dataflow 커넥터가 제공됩니다. 자체 데이터 변환을 정의하거나 BigQuery 또는 Google Cloud Storage와 다른 싱크가 필요한 경우에 적합합니다. 변경 내역 데이터를 소비 및 전달하는 커스텀 Dataflow 파이프라인을 만드는 방법을 자세히 알아보세요.

또는 Spanner API를 사용하여 변경 내역을 처리할 수 있습니다. 이 접근 방식은 특히 지연 시간에 민감한 애플리케이션에 적합하며 Dataflow에 의존하지 않습니다. Spanner API는 변경 내역에서 직접 읽고 자체 커넥터를 구현하며 선택한 파이프라인으로 변경사항을 스트리밍할 수 있는 강력한 인터페이스입니다. Spanner API를 사용하면 변경 내역이 여러 파티션으로 나뉘며, 각 파티션을 사용하여 변경 내역의 쿼리를 병렬로 실행해 처리량을 높일 수 있습니다. Spanner는 부하 및 크기를 기반으로 이러한 파티션을 동적으로 생성합니다. 각 파티션은 Spanner 데이터베이스 분할과 연결되어 변경 내역이 Spanner의 다른 부분처럼 간편하게 확장될 수 있습니다. 변경 내역 쿼리 API 사용 방법을 자세히 알아보세요.

다음 단계

이제 모든 고객이 추가 비용 없이 Spanner 변경 내역을 사용할 수 있습니다. 일반 Spanner 요율에 따라 변경 스트림 데이터의 추가 컴퓨팅 및 저장에 대해서만 비용을 지불하면 됩니다. 변경 내역이 Spanner에 내장되어 있기 때문에 소프트웨어를 설치할 필요가 없으며, 외부 일관성 및 업계 최고의 가용성을 누릴 수 있을 뿐만 아니라 데이터베이스의 다른 부분과도 쉽게 확장할 수 있습니다.

지금 변경 내역 개요에서 변경 내역에 대해 살펴보세요.

Open Saves 소개: 게임용 오픈소스 클라우드 기반 스토리지

Mon, 02 Aug 2021 02:52:00 +0000

* 본 아티클의 원문은 2021년 4월 30일 Google Cloud 블로그(영문)에 게재되었습니다.

오늘날 게이머가 지속적인 스토리라인의 일부가 되는 방식으로 참여할 수 있는 풍부한 몰입형 환경을 제공하는 게임이 많습니다. 이러한 지속적인 경험을 선사하기 위해서는 게임 데이터가 게이머의 요구에 맞게 확장될 수 있도록 수많은 스토리지 기술이 필요합니다. 게임 개발자는 저장, 인벤토리, 패치, 다시보기와 같은 다양한 유형의 데이터를 저장해야 할 뿐만 아니라 스토리지 시스템의 고성능, 가용성, 확장성, 비용 효율성을 유지해야 합니다.

Google이 2K와 협력하여 개발한 Google Cloud 기반의 Open Saves는 여러 스토리지 백엔드에서 사용할 수 있도록 특별히 제작된 새로운 단일 인터페이스입니다. 이제 개발팀은 Cloud Storage, Memorystore 또는 Firestore 등 사용할 스토리지 솔루션에 대한 기술적 결정을 내리지 않고도 게임 데이터를 저장할 수 있습니다.

“Open Saves는 심층적인 업계 지식과 Google의 규모가 모두 필요한 게임 솔루션 분야에서 최고의 개발자와 협업하려는 당사의 의지를 잘 보여주는 결과물입니다."라고 2K IT 및 보안 부문의 조 가르폴라 부사장은 말했으며 "Google Cloud와의 지속적인 협업을 기대합니다.”라고 덧붙였습니다.

게임 개발팀은 최적의 백엔드 스토리지 솔루션에 대한 걱정 없이 Open Saves에서 게임 데이터를 저장할 수 있으며 운영팀 역시 필요한 확장성과 스토리지 옵션에 집중할 수 있습니다. 실제 작동 방식은 다음과 같습니다.

게임 개발자는 Open Saves를 사용하여 다음과 같은 특성의 클라우드 기반 게임 스토리지 시스템을 실행할 수 있습니다.

단순성: Open Saves는 메타데이터, 구조화된 객체, 구조화되지 않은 객체의 모든 작업에 사용할 수 있는 적절하게 정의된 통합 gRPC 엔드포인트를 제공합니다.
속도: Open Saves는 기본 제공되는 캐싱 시스템을 통해 데이터 배치를 빈도 및 데이터 크기에 따라 최적화하여 소형 바이너리 객체에 대해서는 지연 시간을 단축하고 대형 객체에 대해서는 높은 처리량을 달성합니다.
확장성: Open Saves API 서버는 Google Kubernetes Engine 또는 Cloud Run에서 실행할 수 있습니다. 두 플랫폼 모두 초당 수십만 개의 요청을 처리하도록 확장할 수 있습니다. 또한 Open Saves는 Firestore 및 Cloud Storage에 데이터를 저장하며 수백 기가바이트의 데이터와 초당 최대 수백만 개의 요청을 처리할 수 있습니다.

Open Saves는 확장성을 염두에 두고 설계되었으며 온프레미스부터 클라우드 또는 하이브리드에 이르는 모든 인프라에서 실행되어 모바일, 콘솔, 멀티플레이어, 싱글플레이어 등 어떤 게임과도 통합될 수 있습니다. 이 서버는 Go로 작성되었지만 API를 gRPC로 정의하기 때문에 다양한 프로그래밍 언어를 사용해 클라이언트나 서버에서 연결할 수 있습니다.

다음 코드에서 볼 수 있듯이 Open Saves에 쓰기 및 읽기가 매우 간단합니다.

code_block: <ListValue: [StructValue([('code', '// To write\r\n record := &pb.Record{\r\n Key: uuid.New().String(),\r\n Tags: []string{"tag1", "tag2"},\r\n OwnerId: "owner",\r\n }\r\n createReq := &pb.CreateRecordRequest{\r\n StoreKey: storeKey,\r\n Record: record,\r\n }\r\n _, err := client.CreateRecord(ctx, createReq)\r\n if err != nil {\r\n t.Fatalf("CreateRecord failed: %v", err)\r\n }\r\n \r\n // To read\r\n getReq := &pb.GetRecordRequest{StoreKey: storeKey, Key: recordKey}\r\n response, err := client.GetRecord(ctx, getReq)\r\n if err != nil {\r\n t.Errorf("GetRecord failed: %v", err)\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd22ad66550>)])]>

Google은 2K Games와 협업하여 Open Saves를 활발하게 개발 중이며 GitHub에서 여러분의 참여를 기다리고 있습니다. 참여하는 방법에는 몇 가지가 있습니다.

Open Saves 서비스 설치 및 배포
API 참조 확인
개발 가이드를 읽고 참여
open-saves-discuss 메일링 리스트 가입

Colossus 심층 분석: Google의 확장 가능한 스토리지 시스템 간단히 알아보기

Mon, 28 Jun 2021 01:33:00 +0000

* 본 아티클의 원문은 2021년 4월 20일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Cloud를 믿고 중요한 데이터를 맡기는 고객은 많지만 Google의 다른 비즈니스도 동일한 스토리지 인프라를 기반으로 운영된다는 사실을 아는 고객은 많지 않습니다. 사실은 Google Cloud를 구동하는 스토리지 시스템이 YouTube, Drive, Gmail처럼 전 세계에 서비스되는 Google의 가장 유명한 제품도 동일하게 지원하고 있습니다.

바로 그 기반이 되는 스토리지 시스템인 Colossus는 Cloud Storage 및 Firestore 같은 Google의 광범위한 스토리지 서비스 생태계를 뒷받침하고 트랜잭션 처리, 데이터 제공, 분석 및 보관처리, 부팅 디스크, 홈 디렉터리 같은 다양한 워크로드를 지원하는 역할을 합니다.

이 게시물에서는 Colossus 파일 시스템을 중심으로 VM 이면의 스토리지 인프라는 어떤 모습이고 고객 애플리케이션과 Google 서비스에 높은 확장성과 데이터 내구성을 더하는 데 어떤 도움이 되는지 보다 심도 있게 살펴봅니다.

Google 규모의 확장성을 그대로 발휘하는 Google Cloud

스토리지 서비스 운영 방식을 자세히 살펴보기에 앞서 Cloud와 Google 제품을 둘 다 지원하는 하나의 인프라를 이해하는 것이 중요합니다. 우수한 설계를 갖춘 소프트웨어 시스템이 보통 그렇듯 모든 Google 서비스에는 확장 가능한 서비스 집합이 공통적으로 계층화되어 있습니다. Google의 각 스토리지 서비스에는 다음과 같은 3가지 주요 구성 요소가 사용됩니다.

Colossus: Google File System(GFS)의 뒤를 잇는 Google의 클러스터 수준 파일 시스템입니다.
Spanner: 전역 일관성 및 확장성을 갖춘 관계형 데이터베이스입니다.
Borg: 컴퓨팅부터 스토리지 서비스에 이르는 모든 것을 실행하는 확장 가능한 작업 스케줄러입니다. 지금까지는 물론 앞으로도 Kubernetes의 설계 및 개발에 큰 영향을 미칠 것입니다.

이러한 3가지 핵심 구성 요소가 Firestore부터 Cloud SQL, Filestore, Cloud Storage에 이르는 모든 Google Cloud 스토리지 서비스의 기반 인프라를 구성합니다. 즐겨 찾는 스토리지 서비스에 액세스할 때마다 이와 같은 3가지 구성 요소가 함께 작동하여 필요한 모든 것을 제공해 줍니다. Borg는 필요한 리소스를 프로비저닝하고, Spanner는 액세스 권한과 데이터 위치에 대한 모든 메타데이터를 저장하며, Colossus는 모든 데이터를 관리 및 저장하고 그에 대한 액세스를 제공합니다.

Google Cloud에서도 이러한 구성 요소가 동일하게 사용되며 스토리지 서비스에 요구되는 가용성, 성능, 내구성 수준을 제공하는 데 필요한 모든 것을 계층화합니다. 다시 말해 이러한 3가지 서비스를 기반으로 고객의 니즈에 맞게 확장되는 동일한 핵심 인프라를 활용하기 때문에 고객의 애플리케이션 역시 Google 제품과 동일한 확장성을 갖추게 됩니다.

Colossus 요약 정보

이제 Colossus의 작동 방식을 보다 자세히 살펴보겠습니다.

먼저 Colossus에 관한 간략한 배경 정보는 다음과 같습니다.

차세대 GFS입니다.
스토리지 확장성을 개선하고 가용성을 높여 점점 많아지는 애플리케이션에서 폭발적으로 증가하는 데이터 니즈를 처리하도록 설계되었습니다.
Colossus는 분산형 메타데이터 모델을 도입하여 확장성 및 가용성이 높은 메타데이터 하위 시스템을 제공했습니다.

그렇다면 이 시스템은 어떻게 작동하는 걸까요? 어떻게 이 하나의 파일 시스템이 광범위한 워크로드를 지원할 수 있을까요? 아래는 Colossus 제어 영역의 핵심 구성요소를 나타낸 다이어그램입니다.

클라이언트 라이브러리

클라이언트 라이브러리는 애플리케이션이나 서비스가 Colossus와 상호작용하는 수단이 됩니다. 클라이언트는 아마도 전체 파일 시스템에서 가장 복잡한 부분일 것입니다. 소프트웨어 RAID를 비롯한 많은 기능이 애플리케이션의 요구사항을 바탕으로 클라이언트를 구성합니다. Colossus를 기반으로 설계된 애플리케이션은 다양한 인코딩으로 서로 다른 워크로드의 성능과 비용을 미세 조정하여 절충점을 찾습니다.

Colossus 제어 영역

Colossus는 수많은 큐레이터로 구성된 확장 가능한 메타데이터 서비스를 기반으로 합니다. 클라이언트는 파일 생성과 같은 제어 작업을 큐레이터에 직접 전달하고 수평으로 확장할 수 있습니다.

메타데이터 데이터베이스

큐레이터는 Google의 고성능 NoSQL 데이터베이스인 BigTable에 파일 시스템 메타데이터를 저장합니다. 처음에 Colossus를 구축하게 된 계기는 Google File System(GFS)에서 검색과 관련된 메타데이터를 수용하려고 할 때 확장 한도가 발생하는 문제를 해결하기 위해서였습니다. BigTable에 파일 메타데이터를 저장한 덕분에 Colossus는 최대 규모의 GFS 클러스터에서 100배 넘게 수직 확장할 수 있게 되었습니다.

D 파일 서버

Colossus는 네트워크에 있는 데이터 홉 수를 최소화합니다. 데이터는 클라이언트와 'D' 파일 서버(Google의 네트워크 연결 디스크) 사이를 바로 통과합니다.

Custodians

Colossus에는 Custodians라는 백그라운드 스토리지 관리자도 포함됩니다. 이 도구는 전반적인 효율성은 물론 데이터의 내구성과 가용성을 유지하는 데 핵심적인 역할을 하며 디스크 공간 균형과 RAID 재구성 같은 작업을 처리합니다.

Colossus에서 안정적이고 확장 가능한 스토리지를 제공하는 방식

이 모든 요소가 실제로 작동하는 방식을 살펴보기 위해 Cloud Storage에서 Colossus가 사용되는 방식을 생각해 보겠습니다. 아카이브 스토리지부터 처리량이 높은 분석에 이르기까지 Cloud Storage의 광범위한 사용 사례는 익히 들어 잘 알고 있지만 그 기반이 되는 시스템에 대해서는 알려진 이야기가 많지 않습니다.

Colossus를 사용하면 하나의 클러스터를 엑사바이트 규모의 스토리지와 수만 개의 머신으로 확장할 수 있습니다. 예를 들어 위의 예시에서는 Compute Engine VM, YouTube 제공 노드, Ads 맵리듀스 노드에서 Cloud Storage에 액세스하고 이 모든 노드가 동일한 기반 파일 시스템을 공유하여 요청을 완료하고 있습니다. 이를 위해서는 반드시 공유 스토리지 풀을 Colossus 제어 영역으로 관리해 분리된 자체 파일 시스템을 갖춘 것 같은 효과를 내야 합니다.

리소스를 분할하면 소중한 리소스를 보다 효율적으로 사용하고 모든 워크로드의 비용을 낮출 수 있습니다. 예를 들어 YouTube 동영상처럼 지연 시간이 짧은 워크로드의 최대 수요에 맞춰 프로비저닝한 다음 유휴 시간으로 낭비될 수 있는 공간을 채워 보다 저렴한 비용으로 일괄 분석 워크로드를 실행하는 것이 가능합니다.

Colossus를 통해 얻을 수 있는 몇 가지 다른 이점도 살펴보겠습니다.

하드웨어 복잡성 간소화

쉽게 예상할 수 있듯이, Google 서비스를 지원하는 파일 시스템은 수 테라바이트에 달하는 파일과 방대한 데이터 세트를 처리해야 하기 때문에 버거울 정도로 높은 처리량과 확장성을 갖춰야 합니다. Colossus는 많은 물리적 하드웨어 복잡성을 추상화하여 스토리지를 많이 소모하는 애플리케이션의 과부하 가능성을 방지합니다.

Google 데이터 센터는 기본 스토리지 하드웨어를 매우 다양하게 갖추고 있어 여러 규모와 유형의 회전 디스크와 플래시 스토리지 조합을 제공합니다. 그뿐만 아니라 애플리케이션별로 내구성, 가용성, 지연 시간에 대한 요구사항이 극단적으로 다르기 때문에 Colossus는 각 애플리케이션이 필요한 스토리지를 갖출 수 있도록 다양한 서비스 등급을 제공합니다. 애플리케이션은 I/O, 가용성, 내구성 요구사항을 지정한 후 추상화되어 통일된 단위로 리소스(바이트 및 I/O)를 프로비저닝하는 방법으로 이러한 다양한 등급을 사용합니다.

또한 Google 규모에서는 하드웨어 장애가 사실상 늘 발생합니다. 안정성이 부족해서가 아니라 하드웨어 수가 많기 때문입니다. 이처럼 거대한 운영 환경에서는 장애가 자연스러운 현상이기 때문에 파일 시스템에서 필수적으로 내결함성과 투명한 복구를 제공해야 합니다. Colossus는 이러한 장애를 중심으로 I/O를 조정하고 신속하게 백그라운드 복구를 진행하여 내구성과 가용성이 높은 스토리지를 제공합니다.

결과적으로 하드웨어 리소스를 처리해야 하는 복잡한 문제가 발생할 가능성이 크게 줄어 모든 애플리케이션이 쉽게 필요한 스토리지를 확보하고 사용할 수 있게 됩니다.

스토리지 효율성 극대화

알다시피 오늘날 오버프로비저닝 없이 애플리케이션에서 필요로 하는 스토리지 리소스를 제때 제공할 수 있으려면 마법과 같은 관리 기술이 필요합니다. Colossus는 액세스 패턴과 빈도(예: 자주 액세스되는 핫 데이터)가 데이터마다 다르다는 사실을 활용하여 필요에 따라 플래시와 디스크 스토리지를 조합해 사용합니다.

사용률이 가장 높은 데이터는 제공 효율성 향상 및 지연 시간 단축을 위해 플래시에 저장합니다. 기가바이트당 I/O 밀도를 디스크에서 일반적으로 제공 가능한 수준에 맞출 수 있을 정도로만 플래시를 구매하고 충분한 용량을 확보할 정도로만 디스크를 구매합니다. 적절한 조합을 통해 스토리지 효율성을 극대화하고 불필요한 오버프로비저닝을 피할 수 있습니다.

디스크 기반 스토리지의 경우에는 인벤토리 초과 및 디스크 IOPS 낭비를 피하기 위해 디스크를 채워진 상태로 상시 사용하려고 합니다. 이를 위해 Colossus는 가용 디스크 IOPS에서 최대한의 가치를 얻기 위해 지능형 디스크 관리를 사용합니다. 새로 작성된 데이터(예: 사용률이 높은 데이터)는 클러스터의 모든 드라이브에 균등하게 분산됩니다. 데이터의 분포는 재조정되며 시간이 지나고 사용률이 낮아지면 더 큰 용량의 드라이브로 이동합니다. 이 방식은 일반적으로 시간 경과에 따라 데이터의 사용률이 떨어지는 분석 워크로드에 적합합니다.

철저한 현장 검증을 거친 높은 확장성

이처럼 Colossus는 Google의 스토리지 인프라를 비밀스럽게 떠받치고 있는 뛰어난 확장 기능입니다. Colossus는 Google Cloud 서비스의 스토리지 니즈를 처리할 뿐 아니라 Google 내부 스토리지 니즈에 따른 스토리지 용량을 제공하며 매일 검색, 지도, YouTube 등을 이용하는 수십억 명의 사용자에게 콘텐츠를 전달하는 과정을 돕고 있습니다. Google Cloud를 기반으로 비즈니스를 구축하면 Google 서비스를 지원하는 것과 동일한 최고급 인프라를 이용하게 됩니다. 물론 지속적인 인프라 개선 작업도 Google이 담당하므로 걱정할 필요가 없습니다.

Google Cloud의 스토리지 아키텍처에 대해 보다 자세히 알아보려면 이 게시물의 기반이 된 'VM 이면의 Google Storage 인프라 간단히 살펴보기'라는 Next ‘20 세션을 확인해 보시기 바랍니다. 또한 Google의 모든 스토리지 제품군을 자세히 알아보려면 클라우드 스토리지 웹사이트를 방문하세요.

Google Cloud의 객체 스토리지 비용 최적화: 위치 및 클래스

Tue, 11 May 2021 00:00:00 +0000

* 본 아티클의 원문은 2021년 4월 14일 Google Cloud 블로그(영문)에 게재되었습니다.

스토리지는 클라우드 기반 인프라의 중요한 구성요소입니다. 데이터를 저장하고 제공하는 공간이 없으면 데이터베이스가 작동하지 않고 컴퓨팅이 실행될 수 없으며 네트워크를 통해 전달되는 데이터를 저장할 곳이 없습니다. 스토리지는 많은 고객에게 3대 클라우드 비용 중 하나를 차지하며 대부분의 기업에서는 스토리지 니즈가 증가하고만 있습니다. 따라서 스토리지 비용 최적화 방법을 문의하는 고객이 많은 것은 당연한 일입니다.

대부분의 온프레미스 환경에서는 파일 또는 블록 스토리지를 사용하지만 클라우드 스토리지 환경에서는 주로 객체 스토리지를 사용합니다. Google Cloud의 객체 스토리지 서비스인 Cloud Storage는 많은 양의 데이터를 저장하는 대량 스토리지에 적합합니다. 객체 스토리지는 본질적으로 매우 큰 값을 포함하는 '구조화되지 않은' 키-값 쌍이지만 안에 저장되는 파일은 바이너리 데이터, 텍스트 데이터 또는 Apache Parquet, Avro 같은 특수한 데이터 형식일 수 있습니다.

1GB당 $0.01 이하의 객체 스토리지는 대부분의 데이터에 대해 가장 저렴하고 확장성이 뛰어난 솔루션입니다. 하지만 객체 스토리지 가격이 낮게 책정되어 있더라도 비용이 추가될 수 있습니다. 실행되는 워크로드가 많고 시간이 지나면서 니즈가 달라지는 조직의 경우 애플리케이션을 새로 만들거나 마이그레이션할 때마다 클라우드 스토리지 니즈(및 비용)를 최적화하기 어려울 수 있습니다.

클라우드 스토리지 비용을 절감하는 방법에는 여러 가지가 있으며 데이터 수명 주기 니즈, 가져오기 패턴, 거버넌스 요구사항 등 다양한 요인에 따라 사용해야 할 방법이 달라집니다. 이 블로그는 Google Cloud에서 객체 스토리지 비용을 절감하는 방법을 다루는 시리즈의 첫 번째 게시물입니다. 먼저 가장 중요한 결정사항인 데이터를 저장하는 Google Cloud 리전과 선택 가능한 스토리지 클래스 옵션부터 살펴보겠습니다.

올바른 구성으로 시작하기

처음으로 버킷을 설정할 때가 바로 객체 스토리지 비용을 절감할 수 있는 첫 번째 기회입니다. 스토리지 설정은 쉽지만 이때 몇 가지 중요한 결정을 내립니다. 스토리지 위치와 같은 선택사항은 저장하는 데이터 양이 늘어나면 변경하기가 어렵고 시간도 많이 듭니다. 따라서 니즈에 맞는 결정을 내리는 것이 중요합니다.

위치

스토리지 위치 선택은 비용, 성능, 가용성 사이에서 균형을 맞추는 작업이며 Regional Storage가 가장 적은 비용이 들고 이중 리전 또는 멀티 리전 구성에서는 비용이 늘어납니다.

Regional Storage는 이름에서 알 수 있듯이 단일 리전으로 제한되어 있기 때문에 일반적으로 가용성이 가장 낮으나 데이터의 가용성은 여전히 높습니다. 단일 리전 스토리지를 사용하면 데이터가 해당 리전의 여러 영역에 중복 저장됩니다(자세한 내용은 Google Cloud 리전 및 영역 페이지 참조). Google Cloud 시스템은 한 영역 내에서 장애를 격리하도록 설계되었습니다.

이중 리전 및 멀티 리전 스토리지는 요청을 제공할 수 있는 리전이 여러 개(각각 다수의 영역 포함)이므로 드문 일이지만 리전 전체에 정전이 발생하더라도 데이터 액세스를 제공할 수 있다는 점에서 더 나은 가용성을 제공합니다.

성능을 고려한 스토리지 위치 선택은 복잡한 주제입니다. 일반적으로 리전 위치 또는 이중 리전 위치를 선택하여 데이터를 한 리전에 고정하면 리더와 작성자가 동일 리전에 위치해 있을 때 중요한 성능상의 이점을 얻을 수 있습니다. 예를 들어 워크로드를 단일 Google Cloud 리전에서 호스팅하는 경우 객체 스토리지가 동일 리전에 위치해야 네트워크 홉 수를 최소화할 수 있습니다. 또는 읽기와 쓰기에 Cloud Storage를 사용하는 온프레미스 워크로드가 있다면 전용 리전 상호 연결을 사용해 전체 대역폭 소비를 줄이고 성능을 개선할 수 있습니다.

반대로 멀티 리전 스토리지는 Cloud CDN 사용 여부와 관계없이 일반적으로 유럽 또는 북미와 같이 큰 지리적 영역에 직접 트래픽을 제공할 때 우수한 성능을 제공합니다. 많은 애플리케이션, 특히 소비자용 애플리케이션에서는 클라우드 리전과 최종 사용자 사이의 '라스트 마일' 지연 시간을 고려해야 합니다. 이러한 상황에서는 이중 리전 스토리지보다 고가용성과 비용 절감을 제공하는 멀티 리전 스토리지에서 설계자가 더 많은 가치를 찾을 수 있습니다.

비용에 있어서는 Regional Storage가 가장 저렴한 옵션입니다. 이중 리전은 메타데이터가 공유되는 두 리전 버킷이며 관련 위치 고정, 높은 성능이 지원되어 가장 비쌉니다. 멀티 리전은 중간 가격대입니다. Google에서 데이터를 저장할 위치를 유연하게 선택할 수 있어서 데이터를 더 경제적으로 저장할 수 있기 때문입니다. 클래스에 상관없이 Regional Storage 비용이 대략 $1일 때 멀티 리전은 최대 $1.30, 이중 리전 스토리지는 최대 $2를 지불한다고 예상하면 됩니다.

이렇게 비용 차이가 크므로 Cloud Storage 버킷의 위치를 전략적으로 고려하는 것이 중요합니다. 일부 서비스에서는 기본적으로 미국 멀티 리전에 버킷을 만들지만 무조건적으로 기본값을 적용하지 마세요. 성능 및 가용성 요구사항을 고려하고 지리적 중복성과 가용성을 위해 필요 이상으로 비용을 지불하지 마세요.

스토리지 클래스

Cloud Storage 버킷 위치를 선택한 후에는 기본 스토리지 클래스를 선택해야 합니다. Google Cloud에서는 Standard, Nearline, Coldline, Archive와 같은 4가지 클래스를 제공합니다. 클래스마다 적합한 데이터 가져오기 프로필은 각기 다르며 클래스를 지정하지 않으면 기본 클래스가 모든 쓰기에 자동으로 적용됩니다. 정밀도를 높이기 위해 버킷의 개별 객체별로 스토리지 클래스를 정의할 수 있습니다. 객체 수준에서 객체를 다시 쓰거나 객체 수명 주기 관리를 사용하여 스토리지 클래스를 변경할 수 있습니다. (수명 주기 관리에 대해서는 이 시리즈의 이후 블로그에서 자세히 다룰 예정입니다.)

스토리지 가격은 주문형 사용량을 기준으로 책정되지만 가격에는 암묵적인 '계약'이 존재하여 사용 사례에 가장 적합한 스토리지를 확보할 수 있습니다. 이를테면 '핫' 또는 '표준' 스토리지의 경우 1GB당 월 스토리지 가격이 더 높지만 가져오기 또는 조기 삭제에 1GB당 수수료가 추가로 청구되지 않는 암묵적인 계약이 존재합니다. '쿨' 스토리지 클래스에서는 1GB당 월 스토리지 비용이 훨씬 낮은 대신 가져오기 및 조기 삭제의 1GB당 수수료를 고려해야 합니다. 일반적으로 사용 사례의 총비용이 가장 적게 발생하는 기본 스토리지 클래스를 선택하는 것을 목표로 하며 장기적인 관점(예측)이 필요합니다.

시작하려면 문서에 제공된 가이드라인을 따르는 것이 좋습니다.

Standard: 정기적 액세스, 최소 보관 기간 없음, '핫' 데이터
Nearline: 한 달에 한 번 미만 액세스, 한 달 이상 보관
Coldline: 한 분기에 한 번 미만 액세스, 한 분기 이상 보관
Archive: 일 년에 한 번 미만 액세스, 일 년 이상 보관

데이터 액세스 가져오기가 일관되지 않을 경우에는 어떻게 해야 할까요? 많은 Cloud Storage 사용자가 무기한까지는 아니더라도 데이터를 1년 이상 보관합니다. 따라서 분석이 복잡해지지 않도록 여기서는 조기 삭제 비용을 제외할 것입니다. 즉, 이 분석에서는 모든 데이터를 1년 이상 보관한다고 가정합니다. 하지만 가져오기 비용과 관련해 쉽게 예측할 수 없거나 높은 정확성을 원하는 사용 사례들이 섞인 애매한 경우에는 다음 공식을 사용해 두 스토리지 클래스 간 액세스 빈도에 대한 손익분기점을 찾으면 됩니다.

각 변수의 의미는 다음과 같습니다.

hs = '핫' 클래스의 1GB당 월 스토리지 비용

cs = '콜드' 클래스의 1GB당 월 스토리지 비용

cr = '콜드' 클래스의 1GB당 가져오기 비용

(hs - cs) / cr = 손익분기점의 월별 데이터 읽기 비중

예를 들어 us-central1에서 표준 Regional Storage와 Nearline Regional Storage를 사용할 경우를 비교해 보겠습니다(2021년 1월 기준 가격).

(0.02GB/월 - 0.01GB/월) / 0.01GB = 1.0/월 = 월별 100%

즉, Nearline에 저장하는 데이터의 100%를 매달 한 번 읽어도 손익분기점에 도달한다는 의미입니다. 하지만 이 계산에는 주의사항이 두 가지 있습니다.

반복 읽기도 집계됩니다. 데이터의 1%를 한 달에 100번 읽으면 데이터 100%를 정확히 한 번 읽은 것과 같습니다.
이 계산에서는 가정하는 평균 객체 크기가 큽니다(수십 MB 이상). 파일이 매우 작은 경우 운영 비용이 계산에 영향을 미치게 됩니다.

그렇지만 저장한 데이터의 100% 미만을 읽고 작은 객체가 없다면(아래에서 자세히 설명) Nearline Storage를 사용할 경우 비용을 절감할 수 있습니다.

us-central1(아이오와) Regional Storage 클래스의 스토리지 및 보관 비용을 다룬 다음 차트로 모든 스토리지 클래스에서 보이는 이러한 추세를 시각화했습니다. 이 추세는 모든 위치에서 유사하지만 '최고 비율' 변곡점이 다릅니다.

다시 데이터를 1년 이상 보관할 계획이라고 가정한다면 위에 표시된 '최고 비율' 점선을 따라 스토리지 클래스를 선택하면 됩니다. 이 경우 한 달에 정확히 한 번 발생하는 데이터 읽기의 변곡점은 Archive, Coldline, Nearline에서 각각 약 10%, 60%, 100%입니다.

한 달에 한 번 미만 데이터의 10%에 액세스하는 경우 Archive가 가장 비용 효율적인 옵션이라는 사실에도 주목해야 합니다. 정확히 한 달에 한 번 데이터의 10~60%에 액세스하는 경우에는 Coldline이 비용 최적화된 옵션이며 정확히 한 달에 한 번 데이터의 60~100%에 액세스한다면 Nearline이 가장 저렴한 스토리지 클래스입니다. 표준 스토리지는 데이터 100%에 액세스하거나 한 달에 한 번 이상 액세스할 때 가장 적합한 옵션입니다. 다수의 반복 읽기로 자주 액세스하는 데이터가 있는 경우에 이상적입니다.

결론

객체 스토리지는 클라우드 애플리케이션에서 중요한 역할을 차지합니다. 클라우드 스토리지 사용 비중이 큰 기업은 객체 스토리지 비용을 예의주시해야 합니다. Google의 객체 스토리지 서비스인 Cloud Storage는 고객이 스토리지 비용을 최적화할 수 있도록 다양한 방법을 제공합니다.

시리즈의 첫 번째 게시물인 이 블로그에서는 가장 중요한 2가지 요소인 스토리지 위치와 스토리지 클래스에 대한 몇 가지 안내를 다루었습니다. 스토리지 위치와 스토리지 클래스는 버킷을 만들 때 정의하며 옵션마다 장단점이 다릅니다. 위의 안내는 스토리지 요구사항에 맞게 선택하는 데 도움이 되도록 작성되었습니다.

Cloud Storage 및 시작 방법에 대한 자세한 내용은 안내 가이드를 참조하세요. 가져오기 패턴 및 수명 주기 관리와 관련된 객체 스토리지 비용 최적화를 다룬 추가 블로그 게시물을 기대해 주세요.

선택의 자유: Compute Engine VM에서 9TB SSD로 얻는 최고의 비용당 IOPS

Wed, 24 Mar 2021 00:00:00 +0000

* 본 아티클의 원문은 2021년 2월 11일 Google Cloud 블로그(영문)에 게재되었습니다.

지연 시간이 짧은 I/O 집약적 작업을 수행하는 애플리케이션은 컴퓨팅과 긴밀하게 결합된 고성능 스토리지를 갖춘 가상 머신에서 실행해야 합니다. 실시간 분석, 전자상거래, 게임, 소셜 미디어, 광고 플랫폼을 기반으로 한 애플리케이션이라면 더욱더 그러합니다. Compute Engine의 커스텀 머신 유형을 사용하면 고성능 로컬 SSD에 연결할 수 있을 뿐 아니라, 워크로드의 정확한 요구사항에 맞게 VM을 맞춤설정할 수 있는 유연성이 확보됩니다.

오늘 Google Cloud는 6TB 및 9TB 로컬 SSD를 2세대 범용 N2 Compute Engine VM에 연결하여 비용당 우수한 IOPS를 달성할 수 있다는 소식을 발표하게 되어 기쁩니다. 9TB 로컬 SSD는 24개 이상의 vCPU를 사용하는 모든 N2 VM에서 직접 연결 지연 시간으로 최대 240만 개의 IOPS와 9.4GB/초의 처리량을 제공합니다. 이 SSD는 모든 N2 VM 형태(커스텀 형태 포함)에 연결할 수 있기 때문에 애플리케이션에 필요한 CPU, RAM, SSD를 정확히 갖춘 VM을 정의할 수 있습니다. I/O 집약적 또는 스토리지 집약적인 워크로드에서 요구하는 것 이상으로 CPU와 메모리를 연결할 필요가 없어 특히 비용당 IOPS나 비용당 밀도 또는 둘의 조합을 최적화할 수 있습니다.

면책조항: Google Cloud 내부 벤치마킹을 기반으로 한 결과입니다.

더 적은 vCPU로 스토리지 성능 극대화

지금까지는 6TB 및 9TB 로컬 SSD를 N1 VM에 사용하여 32개 이상의 vCPU로 최대 240만 개의 IOPS를 달성할 수 있었습니다. N2 VM을 사용하면 24개의 vCPU만으로 동일한 성능을 얻을 수 있습니다. 즉, N2 VM을 사용하면 N1 VM에 비해 총 소유 비용이 7% 개선되는 것입니다.

다양한 I/O 큐 깊이 또는 블록 크기에서 성능을 최적화할 수 있는 유연성을 제공하는 애플리케이션도 있습니다. FIO와 같은 성능 벤치마킹 도구를 사용하면 최선의 선택을 하는 데 도움이 될 수 있습니다. 아래에서 볼 수 있듯이 내부 테스트 결과 로컬 SSD는 워크로드에 요구될 수 있는 광범위한 구성에서 일관된 성능을 제공합니다.

면책조항: Google Cloud 내부 벤치마킹을 기반으로 한 결과입니다.

최대 처리량

로컬 SSD를 VM에 연결하는 것은 높은 스토리지 처리량을 요하는 워크로드에도 좋은 전략입니다. 아래 차트에서 보다시피 로컬 SSD는 데이터베이스 및 애플리케이션 요구사항에 따라 다양한 블록 크기(4K, 16K, 128K)와 I/O 깊이에서 거의 최대치에 가까운 처리량을 제공할 수 있습니다.

면책조항: Google Cloud 내부 벤치마킹을 기반으로 한 결과입니다.

지금 시작하기

로컬 SSD 가격은 연결되는 VM과 상관없이 GB 단위로 책정됩니다. 리전별 가격을 확인하려면 가격 책정 페이지를 방문하세요. 6TB 및 9TB 로컬 SSD가 이제 N2 및 N2D VM 모두에서 정식 버전으로 제공됩니다. 자세한 내용은 로컬 SSD 문서를 참조하세요. 질문이나 의견이 있다면 지원 받기 페이지를 확인하세요.

Cloud Storage에서 99.999999999% 내구성을 제공하는 방법과 도움이 되는 권장사항

Wed, 10 Mar 2021 00:00:00 +0000

* 본 아티클의 원문은 2021년 1월 29일 Google Cloud 블로그(영문)에 게재되었습니다.

스토리지 솔루션의 가장 기본은 내구성으로 데이터가 손실이나 손상으로부터 얼마나 잘 보호되는지를 나타냅니다. 클라우드 환경에서는 이 내구성이 특히 중요하게 느껴질 수 있습니다. Cloud Storage는 최소 99.999999999%의 연간 내구성(9가 11개)을 갖추도록 설계되었으므로 100년의 시간이 지난다고 해도 10억 개의 객체 중 하나라도 손실되는 일이 없을 것입니다.

Google은 내구성 목표 달성을 매우 중요하게 생각합니다. 이 게시물에서는 Cloud Storage 데이터를 보호하는 주요 방법을 살펴봅니다. 이와 동시에 데이터 보호는 궁극적으로 모두의 책임이므로(데이터 손실의 가장 일반적인 원인은 사용자 또는 스토리지 관리자가 실수로 삭제하는 경우임) 자연재해, 사용자 오류와 같은 위험으로부터 데이터를 보호하는 데 도움이 되는 권장사항을 소개합니다.

물리적 내구성

대부분의 사람은 내구성이라고 하면 네트워크, 서버, 스토리지 하드웨어 장애로부터 데이터를 보호하는 상황을 떠올립니다.

궁극적으로 하드웨어 장애로부터 데이터를 보호하는 가장 좋은 방법은 소프트웨어라는 Google의 철학에 따라 생소한 하드웨어 솔루션에 의존하지 않고 경제적인 비용으로 더 높은 안정성을 확보할 수 있습니다. 하드웨어 장애는 언제든지 일어날 수 있다고 가정하고 있고 실제로도 그렇지만 이로 인해 내구성이 저하되어서는 안 됩니다.

객체를 Cloud Storage에 저장하기 위해 수많은 ‘데이터 청크’로 나눈 다음 각기 다른 전원을 사용하는 여러 서버에 저장합니다. 또한, 중복성을 위해 많은 ‘코드 청크’도 만듭니다. 하드웨어(예: 서버, 디스크) 장애가 발생하면 이 데이터 청크와 코드 청크를 사용하여 전체 객체를 재구성하는데, 이러한 기법을 이레이저 코드(Erasure Code)이라고 합니다. 게다가 객체를 찾고 읽는 데 필요한 메타데이터 사본을 여러 개 저장하므로 하나 이상의 메타데이터 서버에서 장애가 발생해도 해당 객체에 계속 액세스할 수 있습니다.

이때 중요한 점은 데이터를 항상 여러 가용성 영역에 중복 저장해야만 쓰기 작업이 성공한 것으로 확인된다는 것입니다. Google에서 사용하는 인코딩은 하드웨어 장애 시 99.999999999% 이상의 내구성 목표를 지원하기에 충분한 중복성을 제공합니다. 데이터가 저장되면 정기적으로 체크섬을 검증하여 저장 데이터를 특정 유형의 데이터 오류로부터 보호하고 체크섬이 일치하지 않는 경우에는 인코딩의 중복성을 이용하여 데이터가 자동으로 복구됩니다.

권장사항: 이중 리전 또는 멀티 리전 위치 사용

물리적 내구성 위험 요소에 대비한 이러한 보호 레이어가 잘 구현되어 있지만 이것으로 리전의 상당한 물리적 파괴(예: 전쟁이나 소행성 충돌, 기타 대형 재해)에 대해 데이터를 보호할 수는 없습니다.

Cloud Storage의 99.999999999% 내구성 목표는 리전 하나하나에 적용됩니다. 전체 리전을 완전히 파괴할 수 있는 자연재해로부터 보호하려면 가장 중요한 데이터를 이중 리전 또는 멀티 리전 버킷에 저장하는 것이 좋습니다. 이러한 버킷은 여러 지리적 리전에 저장되어 있으므로 데이터 중복성이 저절로 보장됩니다. 이 위치 유형에서는 버킷을 사용하기 위해 애플리케이션을 추가 구성하거나 API를 변경할 필요가 없으며 매우 드물지만 치명적인 결과를 초래할 수 있는 이벤트 발생 시 더욱 향상된 내구성을 제공합니다. 뿐만 아니라 이 위치 유형은 일시적으로 리전에 액세스할 수 없는 경우에도 둘 이상의 위치에서 객체를 투명하게 제공할 수 있기 때문에 높은 수준의 가용성 SLA를 지원합니다.

전송 중 내구성

또 다른 내구성 위험 요소로 전송 중 데이터의 손상이 있습니다. Cloud Storage 자체 서비스 내의 네트워크를 통해 전송되거나 Cloud Storage에 객체를 업로드하거나 다운로드할 때 전송되는 데이터가 여기에 해당할 수 있습니다.

이러한 손상을 원천적으로 방지하기 위해 Cloud Storage 내에서 전송 중 데이터는 예외 없이 항상 체크섬으로 보호되도록 설계되었습니다. 체크섬 검증 오류가 발생하면 상황에 따라 요청을 자동으로 재시도하거나 오류가 반환됩니다.
권장사항: 업로드 및 다운로드에 체크섬 사용
Google Cloud에서는 Google 서비스 내에서 이동하는 모든 Cloud Storage 객체에 체크섬이 적용되지만 엔드 투 엔드 보호를 실현하기 위해 데이터를 Cloud Storage에 업로드할 때는 체크섬을 제공하고 객체를 다운로드할 때는 클라이언트에서 이 체크섬을 검증하는 것이 좋습니다.

사람으로 인한 내구성 리스크

서비스 개발자와 운영자 또는 Cloud Storage 사용자의 실수 등 사람이 저지르는 실수가 데이터 손실을 유발하는 가장 큰 위험 요소로 알려져 있습니다.

데이터 내구성을 위협하는 가장 큰 단일 위험 요소는 소프트웨어 버그일 수 있습니다. 소프트웨어 버그로 인한 내구성 손실을 방지하기 위해 Google은 처음부터 데이터를 손상시키거나 데이터를 지울 수 있는 버그를 피하는 조치를 취합니다. 그런 다음 이러한 유형의 버그를 신속하게 감지하는 보호 장치를 유지하여 내구성 저하가 내구성 손실로 이어지기 전에 이를 포착하려고 합니다.

버그를 사전에 포착하기 위해 대규모 통합 테스트를 통과한 후에만 새로운 Cloud Storage 버전을 프로덕션 환경에 배포됩니다. 가용성 영역의 작동 중지와 같이 다양하고 극단적인 장애 시나리오를 연습하고 데이터 인코딩 및 배치 API의 동작을 이전 버전과 비교하여 회귀를 검사하는 등의 테스트를 거치게 됩니다.

새 소프트웨어 출시가 승인되면 가용성 영역에 따라 매우 제한적으로 영향을 받는 초기 영역을 시작으로 보편화될 때까지 서서히 대상을 확대해 가는 단계별 업그레이드를 수행합니다. 이렇게 하면 버그가 큰 영향을 미치기 전에, 필요할 경우 복구에 사용할 데이터 사본(또는 충분한 수의 이레이저 코드 청크)이 있는 상태에서 문제를 포착할 수 있습니다. 이러한 방식의 소프트웨어 출시는 필요한 경우 빠르게 롤백할 수 있도록 마련된 계획에 따라 면밀히 모니터링됩니다.

이 외에도 데이터가 손실되지 않도록 보호하기 위한 다음과 같은 다양한 권장사항이 있습니다.

권장사항: 객체 버전 관리 사용 설정

데이터 손실을 유발하는 가장 일반적인 원인 중 하나는 스토리지 관리자 또는 최종 사용자가 실수로 데이터를 삭제하는 것입니다. 객체 버전 관리를 사용 설정하면 나중에 복원해야 하는 경우에 대비해 삭제된 객체가 Cloud Storage에 보관됩니다. 객체 수명 주기 관리 정책을 구성하면 버전 관리된 객체가 영구 삭제되기 전까지 보존되는 기간을 제한하여 스토리지 비용을 효과적으로 제어할 수 있습니다.

권장사항: 데이터 백업

Cloud Storage에서 99.999999999%의 내구성 목표가 실현된다고 해서 데이터를 백업할 필요가 없는 것은 아닙니다. 예를 들어 악성 해커가 내 Cloud Storage 계정의 액세스 권한을 손에 넣는다면 어떤 일들이 일어날 수 있는지 생각해 보세요. 목표에 따라 예비 데이터 사본을 다른 리전이나 클라우드 또는 온프레미스에 백업해 두거나 에어 갭을 통해 테이프 또는 디스크에 물리적으로 분리하여 백업해 둘 수 있습니다.

권장사항: 데이터 액세스 보관 정책 및 감사 로그 사용

데이터를 장기간 보관하려면 Cloud Storage 버킷 잠금 기능을 사용하여 데이터 보관 정책을 설정하고 일정 기간 동안 데이터가 잠겨 있도록 하세요. 이렇게 하면 실수로 수정 또는 삭제하는 상황을 방지하고, 데이터 액세스 감사 로깅과 함께 사용할 경우 FINRA, SEC, CFTC와 특정 의료 산업 보존 규정 등의 관련 규제 및 규정 준수 요건을 충족할 수 있습니다.

권장사항: 역할 기반 액세스 제어 정책 사용

업무 분리와 최소 권한의 원칙을 따르는 IAM 데이터 액세스 제어 정책을 마련한다면 악성 해커의 영향 범위와 실수로 인한 삭제를 제한할 수 있습니다. 예를 들어 프로젝트 삭제 권한이 있는 사람과 버킷 생성 권한이 있는 사용자를 분리하는 것이 좋습니다.

암호화 키와 내구성

모든 Cloud Storage 데이터는 클라우드 내에서 저장 상태이든 전송 중이든 항상 암호화되도록 설계되었습니다. 암호화 키가 없으면 객체를 읽을 수 없기 때문에 암호화 키 분실은 내구성에 심각한 위험을 초래합니다. 내구성이 아무리 좋은 데이터라고 하더라도 읽을 수 없다면 결국 아무 소용이 없기 때문입니다. Cloud Storage에서는 1) 신뢰를 바탕으로 Google에서 암호화 키를 대신 관리하도록 하거나 2) 고객 관리 암호화 키(CMEK)와 Cloud KMS를 사용하거나 3) 고객 제공 암호화 키(CSEK)와 외부 키 서버를 사용하는 세 가지 키 관리 옵션이 제공됩니다.

Google은 이레이저 코드, 일관성 확인과 같이 앞의 설명과 유사한 조치를 통해 관리하는 암호화 키의 내구성을 보호합니다.

권장사항: 암호화 키 보호

키 관리를 위해 CMEK 또는 CSEK를 선택하면 자신의 키를 직접 관리할 수 있습니다. 이 경우에도 99.999999999% 이상의 내구성을 제공하는 방식으로 키를 보호하는 것이 중요합니다. CSEK의 경우 키의 외부 백업을 유지하므로 키가 어떤 식으로든 분실되거나 손상되더라도 복구할 방법이 있습니다. 이러한 예방 조치를 취하지 않는다면 데이터의 내구성이 암호화 키의 내구성에 의해 결정됩니다.

99.999999999%를 넘어서

Google Cloud는 데이터 보호 책임을 매우 중요하게 생각합니다. 실제로 여기에 소개된 많은 기술 덕분에 Cloud Storage는 지금까지 99.999999999%가 넘는 연간 내구성을 달성할 수 있었습니다. 이에 더해 이 게시글에 소개된 권장사항을 적용한다면 현재 혹은 향후 수십 년 후에도 언제든지 필요할 때 데이터를 이용할 수 있는 내구성을 확보할 수 있습니다. 시작하려면 Cloud Storage 안내 가이드 전체 문서를 확인해 보세요.

^{이 게시글의 참고 자료가 된 문서의 공동 저자이며 Office of the CTO 테크니컬 디렉터인 딘 힐데브랜드에게 감사의 인사를 전합니다.}

Microsoft 기반 워크로드를 지원하는 Google Cloud의 파일 스토리지 옵션

Sat, 30 Jan 2021 00:00:00 +0000

* 본 아티클의 원문은 2020년 12월 8일 Google Cloud 블로그(영문)에 게재되었습니다.

기업은 라이선스 비용을 절감하고 클라우드 기반 아키텍처 역량을 완전히 활용하는 현대화 전략에 착수하기 위해 앞다퉈 Microsoft 및 Windows 기반 워크로드를 클라우드로 이전하고 있습니다. 데이터 센터의 운영 방식으로는 오늘날 비즈니스 환경에서 요구하는 민첩성, 탄력성, 확장성, 비용 최적화를 달성하기가 훨씬 어려워졌기 때문입니다. Google Cloud는 Microsoft 기반 서비스 및 도구를 위한 최고의 엔터프라이즈급 환경을 제공합니다.

Windows 기반 워크로드에 서버 메시지 블록(SMB) 파일 서비스 구성요소가 필요한 경우가 많습니다. 예를 들어 Windows Server 클러스터에서 실행되는 가용성 높은 SAP 애플리케이션 서버는 SMB 파일 서버가 있어야 구성 파일과 로그를 중앙에 저장할 수 있습니다. 코로나19 팬데믹의 영향으로 갑작스럽게 원격 근무 환경에 적응해야 하는 작업자를 지원해주는 가상 데스크톱 솔루션의 수요가 증가했습니다. 이러한 가상 데스크톱 사용자가 문서를 저장하고 동료와 협업하기 위해 SMB 파일 서버에 액세스해야 하는 경우가 많습니다.

다행히 Google Cloud에는 Microsoft 시스템 사용 환경의 다양한 요구사항을 충족하는 SMB 파일 서비스 옵션이 많이 준비되어 있습니다. 이러한 서비스는 완전 관리형, 준관리형, 자체 관리형 서비스라는 세 가지 카테고리로 나눌 수 있습니다. 이 게시물에서는 세 가지 카테고리에 속하는 몇 가지 옵션을 살펴봅니다. 참고: 여기서는 Google Cloud의 SMB 파일 서비스 제공업체를 전부 다루지 않고 널리 사용되는 옵션 위주로 간단히 소개합니다.

완전 관리형 SMB 파일 서비스

많은 기업에서 운영 오버헤드 감소를 클라우드 혁신의 핵심 목표로 삼고 있습니다. 완전 관리형 서비스는 IT 담당 직원이 개입해 소프트웨어 설치 및 구성, 애플리케이션 패치, 백업과 같은 일상적인 업무에 신경쓰지 않더라도 기능과 성과를 제공합니다. 이러한 관리형 SMB 파일 서비스 옵션을 사용하는 고객은 Windows 애플리케이션과 사용자의 작업 속도를 높이고 수고와 위험도를 줄일 수 있습니다. 단, 관리형 서비스는 파트너에서 제공하므로 사용하게 될 리전을 확인하여 서비스 제공 여부를 알아보세요.

NetApp Cloud Volumes Service

IT 관련 부서에서 근무하면서 스토리지를 관리 혹은 사용했거나 고려한 경험이 있다면 NetApp이 낯설지 않을 것입니다. NetApp은 1992년부터 엔터프라이즈급 솔루션을 제공해 왔습니다. NetApp Cloud Volumes Service(CVS)를 선택하면 Google Cloud와 원활하게 통합되는 가용성 높은 클라우드 기반 관리형 SMB 서비스를 이용할 수 있습니다. 스토리지 용량은 대규모 애플리케이션 환경 수요에 맞게 1~100TB 범위로 조정할 수 있으며 자동 스냅샷 및 신속한 볼륨 프로비저닝 같은 검증된 NetApp 기능이 서비스에 포함됩니다. 이 서비스는 Google Cloud Marketplace에서 직접 배포한 후 Google에서 지원하는 Google Cloud Console에서 관리할 수 있으며 사용 요금은 Google Cloud 청구서에 포함됩니다.

Dell Technologies PowerScale

Dell Technologies는 엔터프라이즈급 스토리지 시장의 또 다른 선두 기업으로, Google Cloud에서 PowerScale을 제공하기로 Google과 파트너십을 맺었습니다. PowerScale은 올플래시 아키텍처를 활용하여 매우 빠른 스토리지 작업 속도를 제공합니다. 하지만 이전 버전과의 호환도 가능하므로 올플래시, 하이브리드, 아카이브 구성의 Isilon 노드와 PowerScale 올플래시 노드 중에 선택할 수 있습니다. OneFS 파일 시스템은 네임스페이스당 최대 50PB의 용량을 자랑하며 확장성을 갖추고 있습니다. NetApp과 마찬가지로 Google Cloud의 PowerScale에는 스냅샷, 복제, 온프레미스 스토리지와의 하이브리드 통합과 같은 엔터프라이즈급 기능이 포함됩니다. Google Cloud와 긴밀하게 통합되는 이 시스템은 Google Cloud Marketplace에서 제공되며 Google Cloud Console과 통합됩니다. 또한 Google로부터 직접 비용 청구 및 지원 서비스를 받게 됩니다.

이 두 가지 관리형 파일 스토리지 제품은 SMBv3까지 지원하므로 많은 관리 오버헤드 없이 Windows 워크로드를 지원하는 뛰어난 옵션입니다.

준관리형 SMB 파일 서비스

모든 고객이 완전 관리형 SMB 서비스를 원하는 것은 아닙니다. 관리형 서비스는 업무 부담을 많이 덜어주지만 특정 요구사항에 맞춰 솔루션을 맞춤설정할 수 있는 방법도 줄어들 가능성이 높습니다. 따라서 일부 고객은 자체 Windows 워크로드에 필요한 정확한 사양에 맞춰 구성하기 위해 아래에 소개된 스토리지 서비스와 같은 자체 관리형(또는 준관리형) 서비스를 사용하는 편을 선호합니다.

NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP(CVO)는 완전 관리형 NetApp Cloud Volumes Service와 마찬가지로 SnapMirror를 비롯해 데이터 센터의 NetApp 시스템에 사용하던 친숙한 기능과 장점을 제공합니다. 하지만 준관리형 서비스이기 때문에 Google Cloud의 데이터를 보다 강력하게 통제하고 보호해야 하는 고객에게 적합합니다. CVO는 Google Cloud 프로젝트 안에서 Google Compute Engine 인스턴스의 Google Cloud Virtual Private Cloud(VPC)에 배포되므로 내부 또는 외부 규정 준수 요구사항을 충족하는 데 필요한 방식대로 정책, 방화벽 규칙, 사용자 액세스 권한을 적용할 수 있습니다. CVO는 NetApp의 단계별 지침을 따라 직접 배포해야 합니다. Marketplace에서 CVO 요금제별로 다양한 SMB 스토리지 용량(2TB~368TB)과 서비스 제공 여부를 확인하고 선택할 수 있습니다. NetApp Cloud Volumes ONTAP는 모든 Google Cloud 리전에서 제공됩니다.

Panzura Freedom 하이브리드 클라우드 스토리지

Panzura Freedom은 글로벌 기업의 파일 저장, 공동작업, 백업을 지원하는 클라우드 전용 하이브리드 파일 서비스입니다. Panzura Freedom은 Google Cloud VPC, 기업 사무실, 온프레미스 데이터 센터, 기타 클라우드에서 동시에 액세스할 수 있도록 지리적으로 분산된 Panzura CloudFS라는 단일 파일 시스템을 제공합니다. 권한 데이터가 Google Cloud Storage 버킷에 저장되고 로컬에 배포된 Panzura Freedom Filers에 캐시 처리되므로 Windows 애플리케이션 및 사용자의 파일 시스템 액세스 성능이 향상됩니다. Google Cloud의 글로벌 광섬유 네트워크와 100개 이상의 접속 지점(PoP)은 전역 지연 시간을 낮춰 어디서나 빠른 액세스를 제공합니다. Panzura도 Google Cloud Marketplace에서 확인할 수 있습니다.

자체 관리형 SMB 파일 서비스

경우에 따라 관리형 서비스가 일부 요구사항을 충족하지 않을 수도 있습니다. 기술 요구사항뿐만이 아닙니다. 예를 들어 규정 준수 요건이 적용되는 업종이라면 인증된 관리형 서비스가 없을 수도 있습니다. 완전 관리형 및 준관리형 SMB 파일 서비스 옵션을 모두 살펴봤지만 예산과 요구사항에 맞는 서비스가 없더라도 염려하지 마세요. Google Cloud에는 자체적으로 Windows SMB 파일 서비스를 운영할 수 있는 옵션도 있습니다. 이 접근방식을 사용하면 서비스 배포, 구성, 보호, 관리의 책임과 함께 최대한의 유연성을 확보할 수 있습니다. Microsoft 시스템을 담당하던 직원에겐 매우 익숙한 옵션일 것이므로 미리 겁낼 필요는 없습니다.

Google Compute Engine 인스턴스상의 Windows SMB 파일 서버

이 옵션은 매우 단순합니다. 원하는 버전의 Windows Server를 실행하는 Compute Engine 인스턴스를 배포하고 파일 서버 역할을 설치하면 모든 준비가 완료됩니다. 이제 Windows에 내장된 모든 기능을 원하는 대로 사용할 수 있습니다. 온프레미스 Active Directory를 Google Cloud에 확장 또는 통합했거나 Active Directory용 관리형 서비스를 사용하는 경우 온프렘에서와 마찬가지로 사용 권한을 적용할 수 있습니다. Persistent Disk는 Windows 파일 서버의 유연성을 크게 높여줍니다. Persistent Disk를 추가하거나 확장하는 방법으로 다운타임 없이 SMB 파일 서버의 스토리지 용량과 디스크 성능을 추가할 수 있습니다. SMB 파일 서버가 하나면 단일 장애점이 되지만 Compute Engine에 내장된 보호 조치와 중복성 덕분에 장애가 장시간의 다운타임으로 이어질 가능성이 낮아집니다. 리전 영구 디스크를 활용하기로 선택하면 디스크가 지속적으로 다른 Google Cloud 영역에 복제되므로 VM 또는 영역의 장애 발생에 대비해 보호 조치가 강화되고 신속한 복구가 가능해집니다.

Windows 클러스터링

Windows 파일 서비스에 다운타임이 용납되지 않는 요구사항이 있는 경우 하나의 Windows 파일 서버로는 대응이 어렵습니다. 다행히 Windows 장애 조치 클러스터링이 이런 경우의 해결책이 됩니다. Windows Compute Engine 인스턴스 및 Persistent Disk를 두 개 이상 유지하면 Persistent Disk, VM, OS는 물론 전체 Google Cloud 영역에 장애가 발생했을 때도 다운타임을 제로에 가깝게 유지할 수 있는 가용성 높은 SMB 파일 클러스터를 빌드할 수 있습니다. 파일 서버 클러스터와 수평 확장 파일 서버(SOFS)라는 두 가지 서로 다른 방식의 Windows 파일 클러스터가 있습니다.

Windows 파일 서버 클러스터는 개발된 지 20년 가까이 되었습니다. 기본 아키텍처는 Windows 장애 조치 클러스터의 Windows 서버 두 개가 스토리지 영역 네트워크(SAN)와 같은 공유 스토리지에 연결되어 있는 구조입니다. 이러한 클러스터는 기본적으로 활성-수동 구성이므로 언제든 클러스터의 서버 중 하나만 공유 스토리지에 액세스하고 SMB 클라이언트에 파일 서비스를 제공할 수 있습니다. 클라이언트는 내부 부하 분산기 프런트엔드의 유동 IP 주소를 통해 서비스에 액세스합니다. 활성 노드에 장애가 발생하면 수동 노드가 공유 스토리지에 대한 읽기/쓰기 액세스를 설정하고 유동 IP 주소를 바인딩한 후 파일 서비스를 실행합니다. 클라우드 환경에서는 실제 공유 스토리지 기기를 클러스터 스토리지 용도로 사용할 수 없습니다. 대신 Storage Spaces Direct(S2D)를 사용할 수 있습니다. S2D는 여러 VM의 영구 디스크를 하나의 가용성 높은 가상 스토리지 풀에 결합하는 클러스터된 스토리지 시스템입니다. 분산형 가상 SAN이라고 볼 수 있습니다.

수평 확장 파일 서버(SOFS) 역시 Windows 장애 조치 클러스터에서 실행되지만 보다 최근에 개발된 향상된 기능의 클러스터 파일 서비스 역할입니다. Windows 파일 서버 클러스터와 마찬가지로 SOFS도 S2D를 클러스터 스토리지로 활용합니다. 하지만 Windows 파일 서버 클러스터와 달리 SOFS는 활성-활성 구성의 파일 서버입니다. SOFS는 클라이언트에 유동 IP 주소를 제시하는 대신 SOFS 역할의 노드마다 DNS에 A 레코드를 별도로 생성합니다. 각 노드는 공유 데이터 세트의 완전한 복제본을 소유하며 Windows 클라이언트에 파일을 제공하여 SOFS를 수평과 수직으로 확장 가능하게 만들 수 있습니다. 그뿐만 아니라 SOFS는 애플리케이션 서버의 복원력을 강화하는 최신 기능도 갖추고 있습니다.

앞서 언급한 것처럼 Windows 파일 서버 클러스터와 SOFS는 공유 스토리지로 S2D를 사용합니다. Google Cloud 가상 머신에 S2D를 설치하는 절차는 여기에 설명되어 있습니다. 선택한 SMB 파일 서비스 역할은 그 후에 설치할 수 있습니다. 파일 서버 클러스터 역할을 배포하는 절차와 SOFS 역할 설치 절차도 확인하세요.

수평 확장 파일 서버와 파일 서버 클러스터의 비교

파일 서버 클러스터와 SOFS는 S2D를 통해 가용성 높은 SMB 파일 공유를 제공한다는 점에서 유사합니다. SOFS는 보다 최근에 개발된 기술로, 파일 서버 클러스터에 비해 처리량이 많고 확장성이 큽니다. 하지만 SOFS는 최종 사용자 파일 사용 작업(열기, 이름 변경, 수정, 복사 등)에 공통적으로 수반되는 메타데이터 위주의 작업에는 최적화되어 있지 않습니다. 따라서 최종 사용자 파일 서비스로는 파일 서버 클러스터를, 애플리케이션에 SMB 파일 서비스가 필요할 때는 SOFS를 선택하는 것이 일반적입니다. 이 페이지에서 파일 서버 클러스터(해당 문서에서는 '일반 용도 파일 서버 클러스터'로 표기)와 SOFS의 기능을 자세히 비교한 내용을 확인해 보시기 바랍니다.

어떤 옵션을 선택해야 하나요?

지금까지 Microsoft 시스템 사용 환경에서 안전성, 성능, 확장성이 우수한 SMB 파일 서비스에 대한 사용자 액세스와 Windows 워크로드를 제공하는 데 적합한 여러 옵션을 알아봤습니다. 그렇다면 나만의 니즈에 가장 적합한 옵션을 선택하려면 어떻게 해야 할까요? 이때 고려해야 할 몇 가지 결정 기준을 소개합니다.

IT 작업을 간소화하고 운영상의 부담을 덜 수 있는 방법을 찾고 있나요? 그렇다면 완전 관리형과 준관리형 옵션을 살펴보세요.
관리형 서비스로는 충족되지 않는 특별한 기술 측면의 구성 요구사항이 있나요? 그렇다면 자체적인 SMB 파일 서비스 솔루션을 단일 Windows 인스턴스 또는 Windows 클러스터 옵션 중 하나로 운영해 보세요.
여러 영역에 걸쳐 완전 자동화된 고가용성 서비스가 필요한가요? 그렇다면 NetApp Cloud Volumes ONTAP와 단일 인스턴스 Windows 파일 서버를 고려해 보세요. 이러한 서버는 하나의 Google Cloud 영역에서 실행됩니다.
특정 Google Cloud 리전에 대한 요구사항이 있나요? 그렇다면 해당 리전에서 NetApp Cloud Volumes Service와 NetApp Cloud Volumes ONTAP가 제공되는지 여부를 확인해야 합니다. 이 두 가지 서비스는 특화된 하드웨어가 필요한 파트너 서비스이며 현재 많은 Google Cloud 리전에서 사용할 수 있지만 제공되지 않는 리전도 있습니다.
온프레미스와 클라우드를 아우르는 하이브리드 스토리지 기능이 필요한가요? 그렇다면 모든 관리형 옵션에 하이브리드 옵션이 있습니다.
예산이 빠듯한가요? 예산이 충분하지 않고 단일 장애점일 경우 우려되는 다운타임을 최소화하기 위해 약간의 수작업 계획 수립과 작업을 감내할 용의가 있다면 단일 Windows Compute Engine 인스턴스 파일 서버가 적합합니다.
여러 지역을 포괄하는 재해 복구가 필요한가요? 여기에 설명된 모든 옵션이 재해 복구 서비스를 제공하므로 염려하지 않아도 됩니다.

아래 표에는 완전 관리형 및 준관리형 옵션이 요약되어 있습니다. 이러한 옵션 중 어느 것도 요구 사항을 충족하지 않는 경우 자체 관리형 옵션 중 하나를 선택하는 것이 좋습니다.

GCP의 관리형 파일 스토리지 옵션

다음 단계

이 게시글에서는 Google Cloud에서 사용할 수 있는 Windows 파일 서비스의 여러 옵션을 간략하게 살펴봤습니다. 이 중에 관심이 가는 옵션이 있다면 자세한 정보를 살펴보세요. 선택의 폭이 좁아졌다면 Marketplace 페이지에서(관리형 서비스의 경우) 자세한 정보를 확인하거나 서비스 실행 프로세스를 시작하세요. 위의 자체 관리형 옵션에는 시작하는 데 참고할 수 있는 Google Cloud 관련 지침 링크와 선택한 클러스터 옵션 배포에 관한 일반 Microsoft 문서 링크가 포함되어 있습니다.

속도 향상 및 확장 가능: Filestore 이제 고성능 지원

Tue, 20 Oct 2020 10:00:00 +0000

* 본 아티클의 원문은 2020년 6월 17일 Google Cloud 블로그(영문)에 게재되었습니다.

세계 최고의 과학자와 연구진이 코로나19와 싸우기 위한 치료법 및 백신을 개발하기 위해 쉼 없이 일하고 있습니다. 이러한 석학들이 하나의 목표에 집중하고 있는 만큼, 이들이 사용하는 기술 역시 당면한 문제를 감당할 역량이 있어야 합니다. 전 세계적인 코로나19 대유행 상황에서 해결해야 할 도전과제도 많지만 오늘날의 기술력 또한 강력합니다. 분자 스크리닝과 같은 처리 작업에는 방대한 연산 능력과 뛰어난 처리량을 갖춘 고성능 스토리지가 필요합니다.

Google Cloud는 코로나19 치료법 연구를 비롯한 여러 산업에 고성능 컴퓨팅(HPC) 지원 도구를 제공하고 있다는 점에 자부심을 느끼고 있습니다. 과학자와 연구진은 강력한 기술을 통해 기술적인 장벽 없이 훨씬 더 빠르게 업무를 수행하여 전 세계에 있는 사람들을 도울 수 있습니다. HPC의 핵심 기능 중 하나는 파일 스토리지입니다. Google Cloud는 Elastifile의 확장 가능한 파일 스토리지 기능이 포함된 Google의 차세대 파일 스토리지 제품인 Filestore High Scale의 베타 출시를 발표하게 되어 매우 기쁘게 생각합니다.

Google은 2019년 8월에 Elastifile의 인수를 마쳤고 해당 기술을 Filestore에 통합하여 확장성과 성능을 더했으며, 이를 통해 워크로드를 클라우드로 더 쉽게 이동할 수 있게 되었습니다. 새로운 Filestore High Scale에는 수십만 IOPS, 수십 GB/s의 처리량, 수백 TB로 확장할 수 있는 공유 파일 시스템을 손쉽게 배포하는 기능이 추가되었습니다. 기존 애플리케이션의 마이그레이션, Kubernetes를 사용한 기존 애플리케이션의 현대화, 대규모 컴퓨팅 워크로드의 성능 요구사항을 충족하기 위한 확장과 같은 다양한 과제를 이제 Filestore를 통해 해결할 수 있습니다.

프로덕션 환경에서 Filestore 사용하기

하버드 의학전문대학원 와그너 랩의 박사후 연구원인 크리스토프 고굴라는 Google Cloud의 확장 파일 스토리지를 사용하여 코로나19 치료법에 대한 VirtualFlow 가상 스크리닝 프로그램을 구현합니다.

"가상 스크리닝을 사용하면 기존 실험용 테스트 방식보다 훨씬 빠르게 잠재적 치료법을 발견하고, 표적 단백질을 대상으로 수십억 개의 저분자를 컴퓨팅을 통해 선별할 수 있습니다." “연구자에게는 불필요하게 복잡한 파일 시스템 클러스터를 설정하고 관리하는 방법을 배우거나 스토리지 시스템의 상태를 계속 모니터링할 시간이 거의 없습니다. 수십만 개의 vCPU를 보유한 수천 개의 클라이언트가 부하를 동시에 생성하는데 이를 처리할 수 있는 파일 시스템이 필요했습니다. Filestore는 대부분의 설정이 자동화되어 있고 즉각적으로 용량을 확장할 수 있으며 간단한 그래픽 인터페이스를 통해 워크플로우 속도를 수시로 모니터링할 수도 있습니다. VirtualFlow를 통해 의약품 및 치료법을 발견하는 데 필요한 시간을 크게 단축할 수 있으며 이는 코로나19 및 기타 질병에 대한 치료법의 빠른 개발로 이어질 것으로 기대됩니다."

최근 발행된 네이처 기사에서 크리스토프의 연구에 대해 자세히 알아보고, 최신 블로그 게시물에서 Google Cloud가 코로나19 학술 연구를 지원하는 방법에 대해 알아보세요.

또한 Filestore는 전자 설계 자동화(EDA), 동영상 처리, 유전체학, 제조, 재무 모델링과 같은 워크로드 지원 뿐만 아니라 고성능 및 고용량이 필요한 기타 사용 사례 지원에도 적합합니다. Filestore High Scale의 지원에 의한 워크로드의 이점은 수만 개의 클라이언트 동시 액세스 지원에서 최대 16GB/s 처리량 및 480K IOPS로 확장 가능한 성능, 필요에 따라 용량을 확장하거나 축소할 수 있는 기능입니다.

파일 스토리지는 HPC 애플리케이션의 중요한 구성 요소이며 Filestore High Scale은 이러한 요구사항을 해결하기 위해 구축되었습니다. Filestore High Scale에는 클라우드의 수평 확장형 파일 스토리지에 대한 예측 가능한 성능, 필요에 따라 파일 시스템을 확장 및 축소할 수 있는 기능이 포함됩니다. 필요한 성능에 관련된 비용을 파악하면 변화하는 워크로드 수요에 따라 솔루션을 훨씬 쉽게 설계하고 최적화할 수 있습니다.

Filestore High Scale을 사용하면 분산된 수평 확장형 파일 시스템의 기능과 성능을 확보할 수 있으며, 완전 관리형 서비스이므로 다른 Google Cloud 제품처럼 쉽게 관리할 수 있습니다. Cloud Console에서 몇 번의 클릭만으로 인스턴스를 가동할 수 있으며 gcloud 및 API 호출을 통해 관리를 자동화할 수 있습니다. 또한 Cloud Monitoring을 사용하여 이러한 파일 시스템을 감시하고, HPC 워크로드 관리 예약 시스템에 파일 시스템을 통합할 수 있습니다.

또한 고급 보안이 요구되는 배포를 더 효과적으로 지원하고자 이번 출시에서는 모든 Filestore 계층에 NFS IP 기반 액세스 제어에 대한 베타 지원을 추가했습니다. 이 새로운 기능은 루트 스쿼시 및 읽기 전용 NFS 내보내기 옵션의 IP별 범위 구성을 추가하여 VPC의 클라이언트에 대한 액세스 제어를 지원합니다. 자세한 내용은 IP 기반 액세스 제어 문서를 참조하세요.

Filestore High Scale은 전문적인 클라이언트 측 플러그인을 배포하거나 유지 관리할 필요 없이 NFS를 사용하여 수만 개의 클라이언트를 직접 마운트할 수 있는 영구 스토리지를 제공합니다. 이를 통해 HPC 사용자는 워크로드에 선점형 VM 인스턴스를 사용할 수 있으므로, 배치 워크로드에 대한 컴퓨팅 인스턴스 비용을 최대 80% 절감할 수 있습니다. 개별 클라이언트 VM은 선점할 수 있지만 데이터는 Filestore에 유지되므로 새로운 VM을 즉시 가동하고 계속 처리할 수 있는 기능을 제공합니다.

Filestore High Scale을 통해 대용량 문제를 해결할 수 있으므로 고객은 비즈니스 관리에만 집중할 수 있습니다. 시작하려면 Filestore 문서를 확인하거나 Google Cloud Console에서 인스턴스를 만드세요.