오픈소스

Memorystore for Valkey 8.0 소개: 비할 데 없는 성능과 완전한 오픈소스

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

편집자 주: Ping Xie는 Valkey 기술 운영 위원회(TSC)의 Valkey 유지보수 담당자입니다.

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

오늘 Memorystore에서 Valkey 8.0 프리뷰 버전이 출시되었다는 기쁜 소식을 알려드립니다. 이로써 Google Cloud는 Valkey 8.0을 완전 관리형 서비스로 제공하는 첫 번째 주요 클라우드 플랫폼이 되었습니다. 2024년 8월에 출시된 Memorystore for Valkey 7.2에서 한 발짝 더 나아간 이번 프리뷰는 Valkey 오픈소스 생태계의 유용한 최신 기능을 개발자 여러분에게 제공하며, 오픈소스에 대한 Google Cloud의 노력을 확고히 합니다.

Memorystore for Valkey 8.0은 Google Cloud가 Major League Baseball(MLB)과 같은 고객을 열심히 지원하고 있다는 것을 여실히 보여줍니다. 가장 역사적인 프로 스포츠 리그인 MLB는 실시간 분석을 지원하는 데 Memorystore를 사용하여 방대한 데이터를 처리하고 경기 중 팬들에게 인사이트와 통계를 제공합니다.

"MLB에서는 팬들에게 최상의 경험을 제공하는 데 사활을 걸고 있습니다. Valkey의 캐싱에 대한 진정한 오픈소스 접근 방식은 획기적이며, 팬들과 계속 소통하고 팬들의 참여를 유도하는 데 필요한 성능과 혁신을 보장합니다. 이 커뮤니티의 일원인 것이 기쁘며, Memorystore에서 Valkey의 지속적인 혁신이 기대됩니다." - Rob Engel, Major League Baseball 소프트웨어 엔지니어링 부문 부사장

Valkey 8.0 출시

올해 초, Redis Inc.가 Redis OSS의 라이선스를 허용적인 BSD 3-Clause 라이선스에서 Restrictive Source Available License(제한적 소스 이용 가능 라이선스, RSAL)로 변경하자 오픈소스 커뮤니티는 Valkey(1, 2, 3)를 BSD 3-Clause 라이선스 하에 완전 오픈소스 대안으로 개발하기 위해 결집했습니다. 몇 달 만에 Valkey 커뮤니티는 오픈소스 Valkey 8.0 정식 버전을 출시하며 오픈소스 협업과 제한받지 않는 혁신의 힘을 보여주었습니다.

Memorystore for Valkey 8.0은 Google 완전 관리형 서비스로서 향상된 성능, 개선된 안정성, Redis OSS와의 완전 호환성을 모두 제공합니다.

Valkey 성능 벤치마크 개선은 새롭게 도입된 비동기 I/O 기능 덕분입니다. 향상된 I/O 스레딩 시스템은 메인 스레드와 I/O 스레드가 동시에 실행될 수 있게 하여, 명령어와 I/O 작업을 병렬 처리하고, 들어오는 요청 처리의 병목 현상을 줄여 처리량을 최대화합니다. Memorystore for Valkey 8.0은 Memorystore for Redis Cluster와 비교하여 마이크로초 단위의 지연 시간에서 최대 2배의 초당 쿼리 수(QPS) 를 제공하므로, 애플리케이션에서 비슷한 크기의 클러스터로 더 많은 처리량을 처리할 수 있습니다. 이로 인해 Valkey 8.0은 높은 처리량이 요구되고 우수한 반응형 사용자 경험을 제공하고자 하는 실시간 애플리케이션에 적합합니다.

처리량 향상과 함께, Valkey 8.0은 다음과 같이 서비스의 전체 속도를 더욱 향상하는 여러 최적화를 포함합니다.

SUNION 명령어는 더 빠른 합집합 작업을 위해 최적화되었습니다.
SDIFF 및 ZUNIONSTORE 명령어는 실행 시간을 개선하기 위해 리팩터링되었습니다.
DEL 명령어는 만료된 키의 중복 삭제를 방지합니다.
CLUSTER SLOTS 응답은 클러스터 작업의 처리량을 개선하고 지연 시간을 줄이기 위해 캐시됩니다.
CRC64 성능은 대용량 데이터 배치에 맞게 개선되어, RDB 스냅샷 및 슬롯 마이그레이션 시나리오에서 중요한 역할을 합니다.

Valkey 8.0은 또한 키 메모리 효율성을 개선하여 애플리케이션 변경 없이 더 많은 데이터를 저장할 수 있습니다. 이제 키는 기본 사전 안에 직접 임베딩되어 메모리 오버헤드를 줄이고 성능을 개선합니다. 또한 새로운 슬롯별 사전은 기본 사전을 슬롯별로 분할하여 성능 저하 없이 키-값 쌍당 16바이트의 메모리 오버헤드를 추가로 줄입니다.

한편, Valkey 8.0은 Google에서 개발한 여러 기능 덕분에 안정성을 개선했습니다. 이러한 Google의 기능은 다음과 같이 프로젝트에 기여하면서 클러스터의 복원력과 가용성을 많이 개선했습니다.

자동 장애 조치는 빈 샤드에 대해 초기 확장 단계에서도 고가용성을 보장하여 새로운 슬롯리스 샤드가 원활하게 장애 조치를 수행할 수 있도록 돕습니다.
슬롯 마이그레이션 상태 복제는 모든 CLUSTER SETSLOT 명령어가 기본 노드에서 실행되기 전에 복제본 전반에 동기화되도록 하여 장애 조치 이벤트 중 데이터 비가용성의 리스크를 줄이고, 새 복제본이 자동으로 적절한 상태를 상속받을 수 있게 합니다.
또한 슬롯 마이그레이션 상태 복구는 장애 조치 후 소스 및 대상 노드를 자동으로 업데이트하여 운영자의 개입 없이 요청이 기본 노드로 알맞게 라우팅되도록 유지합니다.

이러한 개선사항 덕분에 Valkey 8.0 클러스터는 슬롯 이동 중에 장애에 대한 복원력이 높아졌으며, 고객은 복잡한 확장 작업 중에도 안심하고 데이터를 계속 사용할 수 있습니다.

Redis OSS 7.2와의 호환성

Valkey 8.0은 Valkey 7.2와 마찬가지로 Redis OSS 7.2 API와 완벽하게 하위 호환되므로 Redis로부터의 원활한 마이그레이션을 지원합니다. Jedis, redis-py, node-redis 및 go-redis와 같은 인기 있는 Redis 클라이언트가 완벽하게 지원되므로 Valkey로 워크로드를 마이그레이션할 때 애플리케이션 코드를 수정할 필요가 없습니다.

오픈소스의 유연성과 관리형 서비스의 안정성이 결합되어 제어와 편의성 간 균형을 확보하면서 Valkey는 Redis OSS 워크로드를 위한 훌륭한 선택지가 되었습니다.

지금 Memorystore for Valkey 8.0 시작하기

지금 Memorystore for Valkey 8.0을 시작하고 앞서 소개한 향상된 기능을 직접 경험해 보세요. Memorystore for Valkey 8.0은 제로 다운타임 확장, 고가용성, RDB 스냅샷 및 AOF 로깅 기반 지속성 등의 기능을 통해 오늘날 매우 까다로운 워크로드에 필요한 성능, 안정성, 확장성을 제공합니다.

지금 바로 Google Cloud 콘솔 또는 gcloud를 통해 완전 관리형 Valkey 클러스터를 생성하고, 진정한 오픈소스 데이터 관리의 미래를 만들면서 성장 중인 커뮤니티에 참여하세요.

Kubernetes 서비스로 GKE를 선택해야 하는 이유

Mon, 18 Dec 2023 01:00:00 +0000

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

Kubernetes는 최신 소프트웨어 개발 환경에서 중요한 역할을 하고 있습니다. 당초 Google에서 개발한 Kubernetes는 현재 역사상 두 번째로 큰 오픈소스 프로젝트로서, 지난 10년간 83,000명이 넘는 기여자가 참여했으며 프로덕션 환경에서 컨테이너화된 애플리케이션을 실행하기 위한 사실상 표준으로 인정받고 있습니다.

Kubernetes는 클라우드의 대중화에 기여했으며, 덕분에 모든 규모의 비즈니스에서 컨테이너화의 이점과 더불어 클라우드를 활용할 수 있게 되었습니다. 다양한 애플리케이션을 실행할 수 있는 강력하고 유연한 플랫폼인 Kubernetes는 모든 규모의 기업에서 사용되고 있으며 세계에서 가장 규모가 크고 복잡한 일부 애플리케이션을 지원합니다. 근래에는 생성형 AI와 대규모 언어 모델(LLM)이 폭증하면서 기업에서 복잡하고 컴퓨팅 집약적인 머신러닝 플랫폼을 실행하고 확장하는 데 Kubernetes의 힘을 빌리고 있습니다.

Kubernetes는 오픈소스 소프트웨어의 위력을 입증한 성공 사례입니다. 극단적일 만큼 개방적인 커뮤니티 중심 프로젝트로서 전 세계 수만 명의 개발자가 Kubernetes의 기능을 향상하고 새로운 사용 사례에 맞게 조율하는 데 참여하고 있습니다. 결과적으로 Kubernetes는 오픈소스에서만 가능한 속도로 계속 진화하고 있습니다.

전체 산업의 기회를 확대한 Kubernetes의 오픈소스 제공

Google에서 개발한 Kubernetes는 2014년에 오픈소스로 출시되었습니다. 그 뿌리는 Google 검색부터 Google 지도, YouTube에 이르는 모든 서비스의 기반이 된 Google 내부의 Borg 시스템(2003~2004년 사이에 출시됨)으로 거슬러 올라갑니다. Google에서 매주 출시하는 컨테이너 수는 평균 40억 개가 넘습니다.

Kubernetes의 오픈소스 제공은 혁신적인 움직임이었습니다. 이를 통해 Cloud Native Computing Foundation(CNCF)이 설립되고 전 세계 기여자와 사용자로 이루어진 커뮤니티가 형성되었습니다. 이 글로벌 커뮤니티가 점점 커짐에 따라 Google은 Kubernetes가 성장을 지속할 수 있도록 관리자 역할을 수행하고 꾸준한 리더십을 발휘하는 등, 그 어느 때보다 Kubernetes에 큰 노력을 기울이고 있습니다.

오늘날 Google은 Kubernetes의 최대 기여자로서 기여 횟수가 100만 건이 넘습니다. 이는 2위부터 5위까지의 조직 4곳을 합친 횟수보다 더 많은 수치입니다. 시간과 개발 리소스를 투자하는 것 외에도 Google Cloud는 매년 수백만 달러를 기부하여 Kubernetes 컨테이너를 호스팅하고 각 출시 버전을 빌드 및 테스트하는 데 필요한 인프라를 지원하고 있습니다.

지난 한 해 동안 클라우드 제공업체만의 기여도를 살펴보면 Google Cloud의 기여도가 2위로 기여한 제공업체보다 3배 더 높았습니다.

출처: Kubernetes 기업 통계 - 지난 한 해

Google Cloud는 Kubernetes에 매우 광범위하게 참여하고 기여합니다.

API Machinery, Autoscaling, Networking, Scheduling, Storage를 비롯한 SIG, Special Interest Groups에서 공동 의장 및 기술 리더로 활약하고 있습니다.
커뮤니티와 Google 고객 모두에게 영향을 주는 복잡한 문제를 파악하고 해결합니다. 예를 들어 Google은 커뮤니티와 더불어 모든 Kubernetes의 업그레이드 및 지원 중단을 개선하는 데 막대한 투자를 해왔으며, 이는 모든 고객에게 훨씬 더 안정적인 플랫폼을 제공하는 데 도움이 되었습니다.
Kubernetes에서 발견된 보안 취약점 중 절반 이상을 해결하고 있습니다. Kubernetes 보안 향상을 위한 이 같은 노력은 사용자를 위해 Kubernetes를 안전하게 보호하고자 하는 Google의 의지를 보여줍니다.
Go 관련 작업을 수행하는 Google 직원과 긴밀하게 협력하여 업데이트된 Go 버전으로 Kubernetes를 안전하게 보호합니다. Go팀은 Kubernetes 코드 작성에 사용되는 Go 프로그래밍 언어를 개발하는 업무를 맡고 있습니다. Google 직원은 Go팀과 긴밀하게 협업하여 Kubernetes가 최신 Go 버전과 호환되도록 하고 Go에서 발견된 모든 보안 취약점을 해결합니다.
Kubernetes 포드 보호를 위한 일련의 권장사항인 포드 보안 표준 개발에 앞장서고 있습니다. Google 직원은 이러한 표준 개발을 주도해 왔으며 사용자가 Kubernetes 포드를 보호하는 데 도움이 되는 여러 가이드와 리소스를 게시하고 있습니다.
컨테이너로 스토리지에 액세스할 수 있는 방법을 정의하는 초기 컨테이너 스토리지 인터페이스(Container Storage Interface, CSI) 사양을 만들었습니다. Google 직원이 CSI의 초기 개발에 참여했으며 초기 사양을 만드는 데 도움을 주었습니다. CSI는 현재 오픈소스 및 상업용 스토리지 공급업체에서 널리 사용되고 있습니다.
정형 데이터에 대해 쿼리와 변환을 표현하기 위한 Common Expression Language(CEL)를 만들었습니다. CEL은 허용 정책 검증과 커스텀 리소스 유효성 검사 표현식을 포함한 다양한 Kubernetes 구성요소에 사용됩니다. CEL은 강력하고 유연한 언어로 Kubernetes의 확장 가능성과 사용성을 개선하는 데 도움이 되었습니다.

Google은 Kubernetes에 상당한 기여를 해왔으며 플랫폼을 더욱 견고하고 확장 가능하며 안전하고 안정적으로 만드는 데 일조했습니다. 더 나아가 Google은 일괄 처리, 머신러닝과 같은 새로운 영역으로 Kubernetes를 확대 적용하면서 Kueue를 사용한 작업 큐잉, Kubeflow를 사용한 ML 작업 및 워크플로 등 CNCF에도 기여하고 있습니다. 이러한 기여는 매우 중요합니다. Kubernetes 커뮤니티가 발전하고 있다면 이는 개인과 회사로 구성된 핵심 그룹이 Kubernetes의 실질적인 발전을 위한 핵심적인 작업에 시간을 투자하고 모두에게 유익한 새로운 기능을 빌드하고 있기 때문입니다. Kubernetes가 AI/ML 같은 새로운 워크로드에도 적합한 플랫폼이 되려면 이러한 워크로드를 처리하는 데 Kubernetes를 활용하고 또 Kubernetes에 기여하는 회사가 더 많아져야 합니다.

고객이 중요한 워크로드에 Google Kubernetes Engine을 믿고 활용하는 이유

Google Kubernetes Engine(GKE)은 가장 확장성이 뛰어나고 완전히 자동화된 Kubernetes 서비스입니다. 업종이나 규모에 관계없이 모든 비즈니스에서 널리 사용되고 있으며 세계에서 가장 크고 복잡한 애플리케이션을 호스팅하는 데에도 사용됩니다. GKE를 사용하면 Google Cloud의 전문성으로 뒷받침되는 안정적이고 확장 가능한 플랫폼에서 애플리케이션이 실행된다는 확신을 가질 수 있습니다. GKE에는 이제 멀티 클러스터 및 분산 팀 관리, 정책 컨트롤러를 사용한 정책 시행, 구성 동기화를 사용한 GitOps 기반 구성, 구성 컨트롤러를 사용한 Google Cloud 리소스의 셀프서비스 프로비저닝, 완전 관리형 Istio 지원 서비스 메시 기능이 포함되어 있습니다. 이 모든 새로운 기능은 GKE Enterprise와 통합되어 있으며, Kubernetes를 사용하기 시작했거나 이미 전 세계에 배포한 고객에게도 이상적입니다.

고객이 중요한 애플리케이션을 실행하는 데 GKE를 사용하는 이유에는 여러 가지가 있습니다.

Kubernetes를 만든 팀보다 내 환경을 더 잘 운영하고 관리할 수 있는 팀이 있을까요? 오픈소스 Kubernetes 프로젝트 전체가 Google Cloud에서 빌드, 테스트, 배포되며 GKE는 Vertex AI와 DeepMind를 비롯한 여러 서비스에 사용되고 있습니다.
GKE는 2023년 Gartner Magic Quadrant의 컨테이너 관리 부문에서 리더로 선정되었습니다.
GKE는 GPU 시간 공유 및 Cloud TPU를 통해 AI/ML 워크로드를 가속화하고 효율적으로 확장합니다.
GKE는 GKE Autopilot을 통해 최초의 완전 관리형 서버리스 Kubernetes 환경을 제공합니다. GKE Autopilot은 기본 컴퓨팅 인프라를 관리하는 핸드오프 작업 모드이자 Kubernetes API의 모든 기능을 제공하고 포드 수준의 SLA와 명성 높은 Google SRE팀의 지원을 받습니다.
GKE는 독보적으로 15,000개의 노드 클러스터까지 확장할 수 있어 가장 크고 까다로운 애플리케이션의 니즈도 충족합니다. 예를 들어 PGS에서는 Cray를 72.02페타플롭스 용량의 GKE 기반 슈퍼컴퓨터로 대체했습니다.
GKE는 잘못 구성된 워크로드와 컨테이너 이미지 취약점을 검사하는 GKE Security Posture, Kubernetes 네트워크 정책이 기본 제공되는 네트워크 정책 시행, 신뢰하지 않는 워크로드를 격리하기 위한 GKE Sandbox, 사용 중인 워크로드 데이터를 암호화하기 위한 Confidential Nodes 같은 기능으로 엔터프라이즈급 보안을 제공합니다.
GKE는 블루-그린 업그레이드, 유지보수 기간 및 유지보수 제외 등 세밀한 제어 도구를 사용해 원활하게 자동 업그레이드할 수 있습니다.
비즈니스, 규제, 규정 준수 관련 니즈 및 요구사항을 충족하는 유연한 배포 옵션입니다. Google Distributed Cloud(완전 관리형 하드웨어 및 소프트웨어 배포 옵션을 통해 Google Cloud를 고객 데이터 센터 또는 에지 위치로 확장), AWS와 Azure로 멀티 클라우드 배포, CNCF와 호환되는 Kubernetes 클러스터를 연결하고 관리하는 기능이 여기에 포함됩니다.
Google Cloud는 최초의 Kubernetes 비용 최적화 상태 보고서를 발행하는 등 비용 최적화된 애플리케이션 실행에 관한 전문 지식을 갖추고 있습니다.
Google Cloud는 새로운 오픈소스 버전을 출시하고 약 30일 후에 이에 상응하는 GKE 마이너 버전을 출시하여 GKE 사용자가 최대한 빨리 최신 보안 패치와 기능에 액세스할 수 있도록 합니다.

마이크로서비스부터 데이터베이스, 가장 까다로운 생성형 AI 워크로드에 이르기까지 무엇을 실행하든 확장 가능하고 안정적인 완전 관리형 Kubernetes 서비스를 찾고 계신다면 GKE가 가장 적합한 선택이 될 것입니다.

Cloud Functions를 사용해 BigQuery에서 Earth Engine으로 이어지는 자동화된 데이터 파이프라인 구축하기

Fri, 02 Dec 2022 00:00:00 +0000

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

여러 해 동안 방대한 양의 위성 데이터가 수집되었으며, 그 어느 때보다 많은 양의 세분화된 데이터가 날마다 수집되고 있습니다. 불과 얼마 전까지만해도 상업 부문에서는 이러한 데이터를 활용하지 못했습니다. 이 같은 유형의 데이터를 대규모로 분석하는 데 필요한 도구와 위성 이미지 자체를 즉시 사용할 수 없었던 것이 주된 이유입니다. 지구 과학 데이터 및 분석을 위한 전 지구적 규모의 Earth Engine은 이러한 문제를 해결할 수 있는 플랫폼입니다.

최근 Google Cloud Platform(GCP) 제품의 정식 버전으로 출시된 이 플랫폼을 사용하면 업종을 불문하고 상업적 사용자들이 원격 감지 데이터로 작업을 수행할 수 있습니다. 지속 가능한 소싱, 기후 위기 감지, 지속 가능한 농업, 천연 자원 관리 등의 분야에서 이미 Earth Engine 사용 사례를 찾아볼 수 있습니다. Earth Engine으로 각 사용 사례에 대한 공간 중심의 솔루션을 개발하면 비즈니스 운영 개선에 유용한 특별한 정보를 얻을 수 있습니다. 해당 솔루션을 자동화하면 유용한 정보를 보다 빠르게 도출하고, 작업 부담을 덜어내고, 오류를 줄이는 데 도움이 됩니다.

이 게시물에서 다루는 자동화된 데이터 파이프라인은 데이터를 BigQuery에서 Earth Engine으로 전달하며, 가상의 소비재 회사인 Cymbal에 대한 지속 가능한 소싱 사용 사례를 통해 설명합니다. 이 사용 사례에는 두 가지 유형의 데이터가 필요합니다. 첫 번째 유형은 Cymbal에서 이미 보유한 데이터이고, 두 번째 유형은 Earth Engine과 Earth Engine Data Catalog에서 제공되는 데이터입니다. 이 예시에서 Cymbal이 보유한 데이터는 BigQuery에서 출발해 자동화된 프로세스를 통해 데이터 파이프라인을 따라 Earth Engine으로 전달됩니다.

이와 같은 데이터의 조합을 마치 케이크를 한 층씩 쌓는 레이어링 프로세스로 이해하면 쉽습니다. 이제 이 사용 사례와 관련된 레이어에 대해 살펴보겠습니다. 기본 레이어는 Earth Engine이 제공하는 위성 이미지나 래스터 데이터입니다. 두 번째 레이어는 Cymbal이 제공한 야자수 농장의 위치 정보로, 아래 이미지에서 검은색으로 표시됩니다. 세 번째이자 마지막 레이어는 데이터 카탈로그에서 가져온 나무 분포 데이터로, 아래 이미지에서 분홍색으로 표시됩니다. 케이크의 여러 층처럼 여러 데이터 레이어가 쌓여 최종 제품이 만들어집니다. 데이터 레이어의 집계를 자동화하는 것이 이 아키텍처의 목표입니다.

이와 같은 아키텍처가 적용될 수 있는 또 다른 사용 사례의 예시로 메탄 가스 배출 감지 사용 사례를 들 수 있습니다. 이 사례에서도 첫 번째 레이어는 동일합니다. 두 번째 레이어는 회사나 조직에서 제공하는 시설 위치 세부정보(예: 이름, 시설 유형)입니다. 데이터 카탈로그에서 가져온 메탄 가스 배출 데이터가 세 번째 레이어가 됩니다. 메탄 가스 감지 및 지속 가능한 공급망과 마찬가지로 대부분의 사용 사례에는 회사나 조직에서 수집한 테이블 형식의 데이터가 포함됩니다. 데이터가 테이블 형식이기 때문에 자연스럽게 BigQuery가 출발점이 됩니다. 테이블 형식 데이터와 래스터 데이터의 비교, BigQuery와 Earth Engine을 사용해야 하는 경우에 대한 비교를 자세히 살펴보려면 이 게시물을 참조하세요.

지금까지 자동화된 파이프라인에서 Earth Engine과 BigQuery를 함께 사용할 때의 잠재적인 가치에 대해 알아보았으니 이제 아키텍처를 살펴보겠습니다. 다음 섹션에서는 Cloud Functions를 사용해 분석 목적으로 BigQuery와 같은 GCP 제품에서 Earth Engine으로 데이터 흐름을 자동화하는 방법을 알아봅니다. Earth Engine에서 BigQuery로 데이터를 이동하는 방법이 궁금하다면 이 게시물에서 관련 내용을 읽어보세요.

아키텍처 살펴보기

Cymbal은 주로 인도네시아에 위치한 팜유 공급망을 보다 명확하게 파악하고자 합니다. 구체적인 목표는 삼림 벌채 가능성이 있는 지역을 파악하는 것입니다. 이 섹션에서는 Cymbal이 부지의 상황에 대한 정보를 파악할 수 있도록 Cymbal에서 이미 보유하고 있는 야자수 농장 위치 데이터를 Earth Engine으로 전송하여 위성 이미지에 농장이 있는 지역을 매핑하는 방법에 대해 알아봅니다. 모든 요소가 어떻게 조합되는지 자세히 이해할 수 있도록 아키텍처를 단계별로 살펴보겠습니다. 이 아키텍처의 코드를 보면서 진행하려면 여기를 참조하세요.

아키텍처

단계별 안내

1. BigQuery로 지리정보 데이터 가져오기

Cymbal의 지리정보 데이터 과학자는 Cymbal이 보유한 야자수 농장의 위치 데이터와 이 데이터가 BigQuery에 전달되는 방식을 관리하는 역할을 맡고 있습니다.

2. Cloud Scheduler 태스크가 Pub/Sub 주제로 메시지 전송

Cloud Scheduler 태스크는 파이프라인을 시작하는 역할을 수행합니다. Cloud Scheduler 태스크는 크론 태스크이며 워크플로에 맞는 빈도로 예약할 수 있습니다. 태스크가 실행되면 Pub/Sub 주제로 메시지를 전송합니다.

3. Pub/Sub 주제에서 메시지를 수신하고 Cloud 함수 트리거

4. 첫 번째 Cloud 함수가 데이터를 BigQuery에서 Cloud Storage로 전송

Earth Engine 애셋을 만드는 데 사용할 수 있도록 데이터를 Cloud Storage로 이전해야 합니다.

5. 데이터가 Cloud Storage 버킷에 도착하고 두 번째 Cloud 함수 트리거

6. 두 번째 Cloud 함수가 Earth Engine API를 호출하고 Earth Engine에 애셋 생성

Cloud 함수는 Earth Engine을 인증하면서 시작됩니다. 그런 다음 Cloud Storage에 있는 지리정보 데이터에서 Earth Engine 애셋을 생성하는 API를 호출합니다.

7. Earth Engine에 애셋이 생성되면 Earth Engine 앱(EE 앱)이 업데이트됨

대체로 EE 앱은 영향력이 큰 측정항목에 주로 관심을 갖는 Cymbal의 의사 결정권자들이 사용합니다. 대시보드 형식의 이 앱을 사용하면 복잡한 코드를 살펴보지 않고도 측정항목과 시각화된 정보를 파악할 수 있습니다.

8. EE 앱에서 액세스 가능한 고급 분석 스크립트가 생성됨

Earth Engine 코드 편집기에 고급 분석을 위한 환경이 생성되며 EE 앱을 통해 Cymbal의 기술 관련 사용자들에게 제공됩니다. 이 환경은 기술 관련 사용자들에게 삼림 벌채 가능성이 있는 지역에 대한 의사 결정권자들의 질문을 자세히 분석할 수 있는 공간을 제공합니다.

9. Earth Engine의 분석 결과를 Cloud Storage로 다시 내보내기 가능

고급 분석 환경에서 자세한 분석을 마친 기술 관련 사용자는 태스크를 실행하고 분석 결과를 Cloud Storage로 내보내기할 것인지 선택할 수 있습니다. 이후 사용자는 적절하다고 판단되는 방식으로 워크플로를 이어갈 수 있습니다.

Cymbal은 이와 같은 대략적인 아홉 단계를 통해 솔루션을 제공하는 자동화된 워크플로를 마련하여 팜유 공급망을 자세히 파악할 수 있습니다. 이 솔루션은 전사적인 목표를 달성하는 데 도움이 될 뿐만 아니라 다양한 Cymbal 사용자의 니즈도 고려합니다.

요약

지금까지 Cloud Functions를 사용해 BigQuery에서 Earth Engine으로 이어지는 자동화된 데이터 파이프라인의 아키텍처를 살펴봤습니다. 이 아키텍처를 파악하고 모든 요소가 어떻게 조합되는지 자세히 이해하는 가장 좋은 방법은 자체 환경에서 아키텍처를 직접 빌드해보는 것입니다. GitHub에서 제공되는 Terraform 스크립트를 사용하면 아키텍처를 더욱 쉽게 빌드할 수 있습니다. 아키텍처를 빌드한 다음에는 파이프라인의 여러 요소를 교체하여 자체 운영 환경에 보다 적절하도록 조정해 보세요. 아이디어를 얻고 싶거나 다른 예시가 궁금하다면 Earth Engine에서 BigQuery로의 데이터 이전을 다룬 이 게시물을 살펴보세요. 이 게시물에서는 GEE 카탈로그 내의 Landsat 위성 이미지에서 기온 및 식생 데이터를 가져오는 Cloud 함수를 만드는 작업을 BigQuery에서 SQL로 수행하는 방법을 안내합니다. 읽어 주셔서 감사합니다.

차세대 Dataflow: Dataflow Prime, Dataflow Go, Dataflow ML

Thu, 06 Oct 2022 00:00:00 +0000

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

IDC에 따르면 2024년 말까지 기업의 75%가 시범 운영에서 인공지능 운영으로 전환할 것으로 예상됩니다. 하지만 데이터 유형, 이기종 데이터 스택, 프로그래밍 언어의 복잡성이 커지면서 이러한 전환이 모든 데이터 엔지니어에게 도전과제가 되고 있습니다. 현재의 경제 상황에서는 많은 조직이 더 낮은 비용과 높은 효율성으로 보다 많은 작업을 처리하는 것을 핵심 고려사항으로 삼고 있습니다.

오늘 Google에서는 더 많은 개발자가 Google Cloud의 Dataflow를 확장된 사용 사례와 많은 데이터 처리 워크로드에 활용하면서도 비용을 낮게 유지하도록 지원하는 3개의 주요 버전을 발표합니다. 이번 출시는 모든 개발자가 어디서나 빅데이터, 실시간 스트리밍, ML/AI를 사용할 수 있도록 범용화한다는 목표 아래 발표되는 것입니다.

정식 버전으로 출시되는 3개의 Dataflow 주요 버전은 다음과 같습니다.

Dataflow Prime - Dataflow Prime은 Dataflow의 노옵스(no-ops) 서버리스 방식이 가진 이점을 한 단계 업그레이드한 버전입니다. Dataflow Prime을 사용하면 스트리밍 데이터 처리 워크로드에 수평 자동 확장(더 많은 머신) 및 수직 자동 확장(더 많은 메모리를 갖춘 큰 머신)을 모두 활용할 수 있으며 조만간 일괄 처리도 지원될 예정입니다. Dataflow Prime에서는 더욱 효율적인 파이프라인이 제공되어 유용한 정보를 실시간으로 적용할 수 있습니다.
Dataflow Go - Dataflow Go는 Go를 위한 기본 지원을 제공합니다. Go는 유연성, 사용 편의성, 차별화된 개념을 바탕으로 사용이 급증하고 있는 프로그래밍 언어로서 일괄 및 스트리밍 데이터 처리 워크로드 모두에 사용할 수 있습니다. Apache Beam 고유의 다수 언어 모델을 사용하는 Dataflow Go 파이프라인은 ML 변환에 대한 광범위한 자바 I/O 커넥터는 물론 곧 제공될 예정인 Python의 I/O 커넥터에서 제공하는 널리 인정받은 동급 최고의 성능을 활용할 수 있습니다.
Dataflow ML - ML 변환과 관련해 이제 파이프라인 내에서 직접 PyTorch 및 scikit-learn 모델을 실행할 수 있는 즉시 사용 가능한 지원 기능이 Dataflow에 추가되었습니다. 새로운 RunInference 변환에서는 소수의 코드만으로 모델을 프로덕션 파이프라인에서 사용할 수 있어 작업이 간소화됩니다. 이러한 기능은 GPU 지원, ML 학습을 위한 전처리 및 후처리 시스템과 같은 Dataflow의 기존 ML 기능에 직접 추가되거나 Tensorflow Extended(TFX)와 같은 프레임워크를 통해 추가로 제공됩니다.

더욱 향상된 Dataflow를 선보이게 되어 매우 기쁩니다. Apache Beam에서 제공하며 전 세계에서 유일하게 진정으로 통합된 일괄 및 스트리밍 데이터 처리 모델, ML 프레임워크에 대한 광범위한 지원, Beam 모델의 고유한 교차 언어 기능에 힘입어 Dataflow가 모든 데이터 처리 요구사항을 충족하는 더욱 우수한 사용 편의성, 속도, 접근성을 갖추게 되었습니다.

시작하기

Dataflow Go를 쉽게 시작하려면 빠른 시작을 확인하고 Go SDK를 다운로드하세요.
Dataflow Prime에 대해 자세히 알아보려면 문서를 참조하세요.
Dataflow ML 및 RunInference에 대해 자세히 알아보려면 Apache Beam 웹사이트에서 new RunInference Beam transform(새로운 RunInference Beam 변환)을 읽어보세요.

자체 데이터를 사용한 개념 증명의 실행에 관심이 있나요? Google Cloud 영업팀에 실무형 워크숍에 대해 문의하거나 여기에서 신청하세요.

PostgreSQL용 AlloyDB : 고가의 기존 데이터베이스에서 벗어나세요.

Thu, 26 May 2022 00:00:00 +0000

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

기업들은 기존 데이터베이스 시스템에서 벗어나기 위해 애쓰고 있으며 애플리케이션을 현대화하기 위한 대체 옵션을 필요로 하고 있습니다. Google I/O에서는 PostgreSQL용 AlloyDB의 미리보기 버전을 발표했습니다. 이 완전 관리형 PostgreSQL 호환 데이터베이스 서비스는 까다로운 엔터프라이즈 데이터베이스 워크로드를 현대화할 수 있는 강력한 옵션을 제공합니다.

성능 테스트 결과 AlloyDB는 표준 PostgreSQL에 비해 트랜잭션 워크로드 속도가 4배 이상 빠르고 분석 쿼리 속도는 최대 100배 더 빠른 것으로 확인되었습니다. 또한 AlloyDB의 트랜잭션 워크로드 속도는 Amazon의 유사 서비스보다 2배 더 빨랐습니다. 이러한 점에서 AlloyDB는 기존 데이터베이스에서 전환할 때 유용한 새로운 현대화 옵션입니다.

많은 조직이 클라우드에서 데이터베이스 자산을 현대화하는 과정에서 기존 데이터베이스 엔진에 대한 종속을 없애기 위해 노력하고 있습니다. 특히 기업 고객은 고가의 불리한 라이선스와 기존 제품에 수반되는 공급업체 종속을 없애기 위해 PostgreSQL과 같은 개방형 시스템에서 표준화를 모색하고 있습니다. 하지만 오픈소스 데이터베이스에서 비즈니스에 중요한 워크로드를 실행하며 플랫폼을 변경하기란 어려울 수 있습니다. 실제로 성능 조정, 데이터 제거로 인한 중단, 애플리케이션 가용성 관리 등의 어려움을 겪는 팀이 많습니다. AlloyDB는 Google의 수평 확장 컴퓨팅 및 스토리지, 업계 최고의 가용성, AI/ML 기반 관리를 PostgreSQL과의 완전한 호환성은 물론 비즈니스에 중요한 애플리케이션을 실행할 때 기업에서 기대하는 성능, 확장성, 관리 효율성, 안정성과 함께 제공합니다.

IDC 데이터 관리 소프트웨어 연구 부문의 칼 올로프슨 부사장은 “점점 더 많은 데이터베이스가 클라우드로 전환되고 있으며 비즈니스의 디지털 혁신을 이루는 기업이 증가함에 따라 이러한 추세는 계속될 것으로 예상됩니다. Google Cloud는 AlloyDB를 통해 속도와 기능을 향상하고 예측 가능한 가격을 투명하게 제공할 것을 약속하며 기업이 PostgreSQL의 모든 이점을 누리도록 지원함으로써 대기업이 도약할 수 있도록 돕고 있습니다.”라고 말했습니다.

AlloyDB는 고객의 이기종 마이그레이션을 지원하는 여정에서 중요한 역할을 하는 차세대 주요 제품입니다. 예를 들어 최근 Oracle-to-PostgreSQL 스키마 변환 및 데이터 복제 기능을 Database Migration Service에 추가했고 새로운 데이터베이스 마이그레이션 프로그램(링크)으로 도구와 인센티브 자금을 지원하여 클라우드로 빨리 이전할 수 있도록 돕고 있습니다.

“애플리케이션을 빌드, 혁신, 마이그레이션하는 데 있어 개발자에게는 많은 선택권이 있습니다. AlloyDB는 완전한 PostgreSQL 호환성, 우수한 성능, 가용성, 클라우드 통합을 지원하는 강력한 관계형 데이터베이스 옵션을 제공합니다. Google과 함께 혁신을 이루게 되어 매우 기쁩니다. 덕분에 엔터프라이즈급 기능을 활용하는 동시에 기존의 독자적 데이터베이스를 비용 효율적으로 현대화할 수 있게 되었습니다." - 발라 나타라잔, PayPal 데이터 인프라 및 클라우드 엔지니어링 부문 전무이사

AlloyDB의 차별화 요소

세계 최고의 확장성 및 가용성을 자랑하는 데이터베이스 서비스 중 일부를 설계하고 관리한 수십 년간의 경험을 AlloyDB에 활용하여 Google 최고의 기술을 PostgreSQL 생태계에 도입했습니다.

AlloyDB의 핵심은 PostgreSQL을 위해 특별히 설계된 데이터베이스에 최적화된 지능형 스토리지 서비스입니다. AlloyDB에서는 YouTube, Google 검색, 지도, Gmail과 같은 대규모 Google 서비스를 지원하는 것과 동일한 인프라 구성요소를 사용하여 스택의 모든 레이어에서 컴퓨팅과 스토리지를 분리합니다. 이 고유한 기술 덕분에 원활하게 확장하면서도 예측 가능한 성능을 제공할 수 있습니다.

AlloyDB는 분석 가속화, 임베디드 AI/ML, 데이터의 자동 계층화에 추가로 투자함으로써 최소한의 관리 오버헤드만으로 모든 워크로드를 처리할 수 있습니다.

마지막으로, 고급 오픈소스 데이터베이스의 최신 버전인 PostgreSQL 14와의 완전한 호환성을 유지하면서 이 모든 기능을 제공하기 때문에 사용자는 기존 개발 기술과 도구를 재사용하고 기존 PostgreSQL 애플리케이션을 코드 변경 없이 마이그레이션하여 전체 PostgreSQL 생태계의 이점을 누릴 수 있습니다. 나아가 PostgreSQL을 AlloyDB의 기반으로 사용하여 고객에게 차별화된 가치를 제공하는 동시에 개방성을 유지하려는 노력을 기울이고 있습니다.

“새로운 PostgreSQL용 AlloyDB 서비스를 사용할 수 있어 무척 기뻤습니다. AlloyDB를 사용하면서 처리량이 크게 늘었지만 PostgreSQL 워크로드의 애플리케이션을 변경할 필요가 없었습니다. 관리형 서비스이기 때문에 팀이 데이터 운영에 들이는 시간을 줄여 가치 있는 작업에 더 많은 시간을 투자할 수 있게 되었습니다.” - 소피안 하디위자야, Warung Pintar CTO 겸 공동 설립자

AlloyDB를 통해 기존 애플리케이션을 현대화할 때 얻는 이점

1. 우수한 성능 및 확장성
AlloyDB는 까다로운 상업용 워크로드에도 우수한 성능과 확장성을 제공합니다. AlloyDB는 표준 PostgreSQL보다 4배 빠르고 Amazon의 유사 PostgreSQL 호환 서비스에 비해 2배 더 빠른 트랜잭션 워크로드 처리 속도를 지원합니다. 워크로드 패턴에 따라 자동으로 계층화된 여러 레이어의 캐싱을 통해 고객에게 동급 최고의 가격 대비 성능을 제공합니다.

2. 업계 최고의 가용성
AlloyDB는 유지보수가 포함된 99.99%의 고가용성 SLA를 제공합니다. AlloyDB에서는 데이터베이스 규모 및 부하에 상관없이 몇 초 내에 대부분의 데이터베이스 장애를 자동으로 감지하고 복구합니다. 또한 AlloyDB의 아키텍처가 무중단 인스턴스 크기 조절 및 데이터베이스 유지보수를 지원합니다. 기본 인스턴스에서 몇 초 내에 일반적인 작업을 재개하고 복제본 풀 업데이트가 사용자에게 완전히 투명하게 제공됩니다. 이에 따라 고객은 중요한 워크로드에 안정성과 지속적 가용성이 뛰어난 데이터베이스를 사용할 수 있습니다.

“새로운 PostgreSQL 호환 데이터베이스에 대한 기대가 큽니다. AlloyDB는 애플리케이션 변경 없이 더 많은 확장성과 가용성을 제공할 것입니다. 전자상거래 플랫폼을 운영할 때는 가용성이 중요합니다. 그런 점에서 AlloyDB가 유지보수 다운타임을 최소화할 것이라는 기대가 큽니다.” - 류조 야마모토, Mercari(Souzoh, Inc.) 소프트웨어 엔지니어

3. 실시간 비즈니스 통계
AlloyDB는 표준 PostgreSQL보다 최대 100배 더 빠른 분석 쿼리를 제공합니다. 데이터를 빠른 스캔 및 집계에 최적화된 컬럼 형식으로 메모리에 저장하는 벡터화된 컬럼 형식 가속기 덕분에 가능한 결과입니다. 이러한 점에서 AlloyDB는 비즈니스 인텔리전스, 보고, 하이브리드 트랜잭션 및 분석 워크로드(HTAP)에 적합합니다. 게다가 가속기가 자동으로 채워지므로 버튼 하나만 클릭하면 분석 성능을 개선할 수 있습니다.

“PLAID는 고객 경험 플랫폼인 KARTE를 개발하고 있습니다. KARTE에서는 방대한 양의 행동 데이터에 대한 고급 실시간 분석 기능을 제공하여 심층 통계를 살펴보고 고객과 소통할 수 있는 환경을 조성할 수 있습니다. AlloyDB는 PostgreSQL과 완전하게 호환되며 컬럼 기반 처리를 투명하게 확장할 수 있습니다. 고유한 기술 접근 방식을 사용하여 새로운 전문 기술에는 최소한으로 투자하면서도 격리된 OLTP, OLAP, HTAP 워크로드를 통합할 수 있는 시스템 설계를 지원하므로 새롭고 강력한 옵션이라고 생각합니다. 향후 Google Cloud의 다른 강력한 데이터베이스 서비스와의 데이터 통합을 개선하여 분석 기능에 더 많은 성능과 확장성을 더하고자 합니다.” - 타쿠야 오가와, PLAID 리드 제품 엔지니어

4. 예측 가능한 투명한 가격 책정
AlloyDB에서는 가격 책정이 투명하고 예측 가능하며 고가의 독점 라이선스 및 불확실한 I/O 요금 청구가 없습니다. 스토리지가 자동으로 프로비저닝되며 고객에게는 사용한 만큼만 요금이 청구되고 읽기 복제본에 대한 추가 스토리지 비용이 발생하지 않습니다. 인스턴스 메모리 외에도 자동으로 프로비저닝되는 무료 초고속 캐시로 가격 대비 성능을 극대화할 수 있습니다.

5. ML 기반의 관리 및 통찰력
많은 관리형 데이터베이스 서비스와 마찬가지로 AlloyDB도 데이터베이스 패치, 백업, 확장, 복제를 자동으로 처리해 줍니다. 그러나 이 제품은 여기에서 몇 단계 더 나아가 PostgreSQL 데이터 제거 관리, 스토리지, 메모리 관리, 데이터 계층화, 분석 가속화에 적응형 알고리즘과 머신러닝을 사용합니다. 워크로드를 학습하여 데이터를 메모리, 초고속 보조 캐시, 내구성 있는 스토리지에 지능적으로 정리해 줍니다. 이처럼 자동화된 기능으로 DBA 및 개발자의 관리가 간소화됩니다. 또한 AlloyDB는 고객이 애플리케이션에 머신러닝을 더 잘 활용하도록 지원합니다. Google Cloud의 인공지능 플랫폼인 Vertex AI와의 통합이 기본적으로 제공되어 사용자가 쿼리 또는 트랜잭션 내에서 바로 모델을 호출할 수 있습니다. 따라서 추가 애플리케이션 코드를 작성하지 않고도 높은 처리량, 짧은 지연 시간, 향상된 통찰력를 얻을 수 있습니다.

AlloyDB 시작하기

현대적인 데이터베이스 전략은 우수한 애플리케이션을 빠르게 개발하고 고객에게 새로운 경험을 제공하는 데 중요한 역할을 합니다. AlloyDB 출시는 Google Cloud 데이터베이스에 매우 의미가 큽니다. 고객들이 어떻게 이 제품을 사용하여 조직 전반의 혁신을 주도하고 데이터베이스 워크로드에 대한 통제권을 되찾아 다시 자유롭게 사용할지 무척 기대가 됩니다.

AlloyDB에 적용된 혁신 기술에 대해 자세히 알아보려면 지능형 스토리지 시스템에 대한 심층 탐구를 확인하세요. 그런 다음 cloud.google.com/alloydb를 방문하여 시작하고 첫 번째 클러스터를 만들어 보세요. Google I/O 2022 데모 및 출시 발표도 검토할 수 있습니다

Storage Write API를 사용해 데이터를 BigQuery로 스트리밍하기

Tue, 08 Mar 2022 00:00:00 +0000

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

많은 고객이 즐겨 사용하는 BigQuery는 높은 확장성과 비용 효율성을 자랑하는 서버리스 데이터 웨어하우스입니다. Dataflow 역시 대규모 데이터 처리를 위해 수평 확장 및 수직 확장되는 서버리스 플랫폼입니다. 많은 사용자가 오늘날 기업에서 생성되는 방대한 데이터를 적시에 분석하기 위해 두 제품을 함께 사용하고 있습니다. Google Cloud는 BigQuery와 Dataflow를 함께 사용하는 사용자가 만족스러운 경험을 하도록 보다 간편하게 사용, 확장, 최적화할 수 있는 새로운 통합을 선보이기 위해 계속 노력 중입니다. 예를 들어 최근 Google Cloud는 BigQueryIO 커넥터를 위한 자동 샤딩 지원을 출시했습니다. 이 기능은 스트리밍 파이프라인의 처리량을 평균 3배 증가시킵니다.

오늘 Dataflow 사용자에게 BigQuery 최고의 기능을 제공하는 또 다른 통합을 출시하게 되어 기쁩니다. 최근 BigQuery팀에서는 새로운 BigQuery Storage Write API를 정식 버전으로 출시했습니다. BigQuery Storage Write API는 BigQuery용 통합 데이터 수집 API입니다. Dataflow 사용자가 이 기능을 사용하면 스트리밍 수집 및 일괄 로드를 하나의 고성능 API로 결합할 수 있습니다. Storage Write API를 사용하면 기록될 때 쿼리에 사용할 수 있는 레코드를 BigQuery로 스트리밍하거나 많은 수의 레코드를 일괄 처리하고 단일 원자적 작업으로 커밋할 수 있습니다. 새 API는 이전 버전인 table.insertAll() API보다 많은 처리량을 제공하며 최대 2TB의 무료 월별 사용량 등으로 스트리밍 수집 비용을 크게 절감시켜 줍니다.

새로운 API는 자바 클라이언트 라이브러리, Python 클라이언트 라이브러리를 통해 사용하거나 gRPC를 지원하는 모든 언어로 사용할 수 있습니다.

이제 BigQueryIO 커넥터에 두 가지 메서드를 추가로 제공하여 Dataflow에서 Storage Write API를 지원합니다. BigQuery에 데이터를 삽입하는 1회만 실행되는 시맨틱스를 사용하는 메서드와 1회 이상 실행되는 시맨틱스를 사용하며 지연 시간이 짧고 보다 저렴한 메서드 중에서 선택할 수 있습니다.

1회만 실행되는 시맨틱스를 통한 BigQuery Storage Write API 사용

다음 섹션은 약간의 변경만으로 기존 자바 파이프라인을 업데이트하고 Storage Write API의 강력한 트랜잭션 시맨틱스를 활용하는 방법을 보여줍니다.

1. Write API(버전 2.36.0 이상 권장)를 지원하고 Dataflow에서 지원되는 Beam SDK 버전으로 파이프라인을 업데이트합니다.

2. 새로운 API를 사용하려면 BigQueryIO의 Write 변환을 만들 때 새 메서드인 STORAGE_WRITE_API를 설정합니다. 일반적으로 코드는 다음과 같이 표시됩니다.

code_block: <ListValue: [StructValue([('code', 'WriteResult writeResult = rows.apply("Save Rows to BigQuery",\r\nBigQueryIO.writeTableRows()\r\n .to(options.getFullyQualifiedTableName())\r\n .withWriteDisposition(WriteDisposition.WRITE_APPEND)\r\n .withCreateDisposition(CreateDisposition.CREATE_NEVER)\r\n .withMethod(Method.STORAGE_WRITE_API);\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa92455e220>)])]>

3. 파이프라인에서 테이블을 만들어야 하는 경우(테이블이 존재하지 않고 생성 배치를 CREATE_IF_NEEDED로 지정한 경우) 테이블 스키마를 제공해야 합니다. 테이블 스키마는 백엔드를 호출하기 전에 API에서 데이터를 검증하여 효율적인 바이너리 프로토콜 버퍼 메시지로 변환하는 데에도 사용됩니다. 백엔드에 제출하기 전에 새 API에서 이 스키마를 사용해 데이터 검증을 수행합니다.

code_block: <ListValue: [StructValue([('code', 'TableSchema schema = new TableSchema().setFields(\r\n List.of(\r\n new TableFieldSchema()\r\n .setName("request_ts")\r\n .setType("TIMESTAMP")\r\n .setMode("REQUIRED"),\r\n new TableFieldSchema()\r\n .setName("user_name")\r\n .setType("STRING")\r\n .setMode("REQUIRED")));'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa928f35fd0>)])]>

4. 마지막으로 스트리밍 파이프라인에서는 스트림 수 및 트리거 빈도라는 두 매개변수를 추가로 설정해야 합니다.

스트림 수는 BigQueryIO Write 변환의 동시 로드를 정의하며 파이프라인에서 사용될 Storage Write API의 스트림 수와 대략 일치합니다. withNumStorageWriteApiStreams 메서드를 통해 변환에서 명시적으로 설정하거나 BigQueryOptions 클래스에 정의된 대로 'numStorageWriteApiStreams' 옵션을 파이프라인에 제공하면 됩니다.

트리거 빈도는 BigQuery에서 쿼리하는 데이터가 표시되는 속도를 결정합니다. withTriggeringFrequency 메서드를 통해 명시적으로 설정하거나 'storageWriteApiTriggeringFrequencySec' 옵션을 설정하여 시간(초)을 지정하면 됩니다.

이 두 매개변수 조합은 Storage Write API를 호출하기 전에 BigqueryIO에서 만드는 행의 배치 크기에 영향을 줍니다. 빈도를 너무 높게 설정하면 배치 크기가 작아져 성능에 영향을 줄 수 있습니다.

프로덕션에서 실행하기 전에 대표적 볼륨으로 파이프라인을 테스트하고(모든 파이프라인에 권장) 앞서 언급한 두 매개변수에 대한 최적의 값을 찾는 것이 좋습니다. 먼저 시작에 도움이 될 몇 가지 지침을 알려드립니다. 단일 스트림에서 초당 1Mb 이상의 처리량을 처리할 수 있어야 합니다. 이 메서드에서 사용할 독점 스트림을 만드는 BigQuery 서비스 작업에는 많은 비용이 발생합니다. 사용 사례에 필요한 수량의 스트림만 사용하세요. 대부분의 파이프라인에서는 한 자릿수 초 단위의 트리거 빈도가 적절합니다.

앞으로 자동 샤딩을 통해 런타임에서 매개변수를 결정하고 조정할 수 있도록 지원할 계획입니다.

1회 이상 실행되는 시맨틱스를 통한 BigQuery Storage Write API 사용

대상 테이블의 잠재적 중복 레코드가 허용되는 사용 사례의 경우 STORAGE_WRITE_API 메서드의 사촌 격인 STORAGE_API_AT_LEAST_ONCE 메서드를 사용할 수 있습니다. 이 메서드는 BigQuery에 기록할 레코드를 셔플 스토리지(STORAGE_WRITE_API 메서드의 1회만 실행되는 시맨틱스를 제공할 때 필요)에 유지하지 않으므로 비용이 더 저렴하고 대부분의 파이프라인에서 지연 시간이 더 짧습니다. 사용도 더 간단합니다. 앞서 다룬 두 개의 추가 매개변수가 필요하지 않습니다.

상당수(수천 개)의 스트림이 필요한 대규모 파이프라인을 실행하기 전에 Storage Write API 할당량을 검토하세요. 이 할당량은 BigQuery 서비스에 열려 있는 gRPC 연결 수와 관련이 있습니다. BigQueryIO 구현에서 연결 수는 메서드에 따라 다릅니다. STORAGE_WRITE_API 메서드에서는 대략 스트림 수와 같습니다. STORAGE_API_AT_LEAST_ONCE 메서드의 경우에는 연결 수를 파이프라인의 최대 작업자 수까지 사용할 수 있습니다. 멀티 리전 BigQuery 위치('us' 및 'eu')에 위치한 테이블로 수집하기 위한 최대 연결 수는 리전별 위치에서보다 많습니다.

다음 단계

BigQuery Storage Write API와 이에 대한 Dataflow 지원이 Beam SDK 2.36.0(또는 이상)을 사용하는 모든 사용자에게 제공됩니다.

에릭 브루어와 함께하는 Kubernetes의 과거, 현재, 미래

Fri, 11 Feb 2022 00:00:00 +0000

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

Kubernetes라는 단어가 기술 업계에 처음 등장한 것은 2014년이었습니다. 그 당시 Kubernetes를 처음 접했을 때 가장 먼저 떠오른 생각은 '도대체 어떻게 발음해야 하지?'였습니다. 그로부터 7년이 지난 후 Kubernetes는 세계 최대 규모의 오픈소스 프로젝트 중 하나가 되었습니다. Kubernetes의 초기 관리자 중 한 명이 Google 펠로우인 에릭 브루어입니다. 지난 10여 년 동안 에릭은 Google 기술의 개발과 외부 출시를 적극 지원하며 주도적으로 이끌어 왔습니다. 현재는 Kubernetes, 서버리스, DevOps, Istio, 기타 서비스와 같은 다양한 Google Cloud 서비스에 주력하고 있으며, 이전에는 컴퓨팅과 스토리지 분리, 대규모 VM 라이브 마이그레이션 보급 추진, 분할을 위한 어플라이언스 사용 정립 등 획기적인 작업에서 중요한 역할을 했습니다. 저는 몇 번의 세션에 걸쳐 수년간 그가 경험한 IT 현장의 이야기를 듣고 에릭이 클라우드 컴퓨팅의 미래를 결정지은 4대 요소로 꼽는 Kubernetes 및 오픈소스 관련 유용한 정보를 상세히 알아보는 시간을 가졌습니다.

1. 오픈소스로 제공되는 Kubernetes는 클라우드 기반 컴퓨팅의 중심축이 되었으며 우리는 오픈소스 기술에 지속적으로 투자해야 합니다.

UC 버클리 학부에 입학한 에릭은 많은 프로세스, 서비스, API를 사용하는 상용 서버 클러스터에 기반한 모델이자 훗날 클라우드 컴퓨팅의 모체가 되는 기술에 큰 관심을 가졌습니다. 2011년, Google에 입사한 후에는 이러한 생각을 토대로 높은 수준의 추상화를 중심으로 한 신종 클라우드를 개발했습니다. 이 신종 클라우드는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하기 위한 오픈소스 시스템인 Kubernetes의 시초가 된 초기 프로토타입과 잘 연동되었습니다.

2010년대 초반 클라우드가 태동하던 시기에 에릭은 Google 내부의 컨테이너에 기반한 접근법이 VM과 디스크보다 훨씬 더 강력한 클라우드를 구현해 낼 수 있음을 알고 있었습니다. Google에서 생각이 같은 사람을 모으는 것은 비교적 쉬웠지만 이제껏 경험해 보지 못한 새롭고 검증되지 않은 아이디어가 업계 전반에 받아들여지기까지는 대개 시간이 오래 걸리기 마련입니다. 선견지명이 있었던 에릭은 프로젝트를 오픈소스로 제공하는 것이 클라우드 컴퓨팅을 혁신할 수 있는 Kubernetes의 잠재력을 실현할 수 있는 단 하나의 방법임을 바로 알아챘습니다.

물론 일부 저항에 부딪히기도 했습니다. 2012년 무렵, Google Cloud는 이미 App Engine과 VM을 제공하고 있었습니다. 비평가들의 공통적인 질문은 '왜 컴퓨팅을 하는 데 제3의 길이 필요하냐?'는 것이었습니다. Kubernetes의 등장 전부터 Google은 이미 매주 수십억 개의 컨테이너를 실행하고 있었으며 에릭은 이 기술을 더욱 발전시킴으로써 산업 전반에 걸쳐 막대한 가치를 창출할 수 있을 것으로 예상했습니다. Kubernetes는 자동화와 유연성을 갖추고 있어 원시 VM 또는 원시 디스크를 사용할 때에 비해 훨씬 더 수월하게 운영할 수 있습니다.

수년 동안 오픈소스 지원이 이루어진 후 Kubernetes는 Knative, Kubeflow와 같이 Kubernetes를 기반으로 실행되는 한층 더 독자적이고 수평적으로 확장 가능한 서비스를 통해 클라우드에서 애플리케이션을 실행하는 실질적인 방법으로 자리 잡았습니다. 클라우드 컴퓨팅이 또 한 번의 전환점을 맞이하는 상황에서도 이 프로젝트는 계속 발전하고 있습니다. 현재 에릭은 Kubernetes의 근본 철학과 보안에 민감한 업계가 요구하는 엄격한 보호 조치를 결합하기 위한 노력을 진두지휘하고 있습니다. 오픈소스 및 소프트웨어 공급망 보안에 중점을 두고, 공격 지점을 최소화하기 위해 소스 코드 작성에서 배포까지 더욱 독자적인 도구를 개발하는 것을 목표로 삼고 있습니다.

2. 소프트웨어 개발에 사용된 종속 항목의 수가 늘어날수록 보안 위험이 급격히 커지게 됩니다. 소프트웨어 공급망 보안에 대한 투자는 필수적이며 자체 관리 솔루션보다 관리형 서비스로 전환하는 것이 실제로는 더 안전합니다.

SolarWinds와 CodeCov 등 최근 발생한 공격을 보면 소프트웨어 산업 전반에서 재사용이 증가하고 개발 속도가 빨라지면서 공격의 여지가 될 만한 보안 허점이 늘어나는 것을 알 수 있습니다. 에릭은 전지구적인 최우선 과제를 해결하기 위한 기반을 닦고 있습니다.

취약점의 99%는 애플리케이션에 작성한 코드가 아니라 깊고 복잡하게 얽혀 있는 종속 항목에 존재하며, 여러분이 잘 알고 있는 것도 있고 전혀 모르는 것도 있습니다. 에릭 브루어

소프트웨어 개발에서 오픈소스 소프트웨어와 종속 항목의 사용이 늘고 있기 때문에 조직이 소프트웨어에서 중점 투자할 부분을 판단하고 그 이유를 이해하는 것이 중요합니다. 검증되지 않은 소프트웨어 종속 항목을 코드에 포함하는 대신, 이 소프트웨어를 평가하고 기준에 부합하지 않거나 제대로 관리되지 않는 요소를 찾아내는 데 시간을 할애해야 합니다.

수백 개의 소프트웨어 종속 항목이 존재하는 Kubernetes에 Google은 어떻게 투자하고 있느냐는 질문에 에릭은 2015년에 Cloud Native Computing Foundation(CNCF)이 설립되기까지 Google Cloud가 크게 기여했다고 설명했습니다. CNCF는 Kubernetes, Prometheus, Envoy 등 빠르게 증가하는 오픈소스 프로젝트의 공급업체 중립적인 발상지 역할을 하고 있습니다. CNCF의 사명은 클라우드 기반 컴퓨팅을 널리 보급하고 생태계 확장을 조성하는 것입니다. CNCF 지원을 기반으로 Google은 2020년에 123,000건이 넘는 항목을 비롯하여 프로젝트에 680,000건 이상을 추가로 기여했습니다.

Google은 오래전부터 오픈소스 분야에 상당한 노력을 기울여 왔으며, 실제로 최근에는 오픈소스 보안을 지원하는 제3자 재단에 1억 달러를 후원하기도 했습니다. 뿐만 아니라 에릭은 조직 보안 책임자들이 일련의 오픈소스 종속 항목에 대한 보안을 이해하고 확인하도록 돕는 오픈소스 보안 도구와 권장사항을 주로 개발하는 Open Source Security Foundation(OpenSSF)을 설립하는 데 큰 역할을 했습니다. 에릭은 선례를 마련한다는 측면에서 이 성과를 중요하게 생각합니다. 오픈소스의 안전성을 최대한 확보하기까지 길고 지루한 과정을 거쳐야 하겠지만 이는 반드시 필요한 작업이며 재정적인 지원이 필요합니다.

오픈소스는 공공 인프라이기도 합니다. 모든 공공 인프라와 마찬가지로 유지보수와 지원이 필요합니다. 에릭 브루어

더 높은 수준의 추상화를 채택하는 서비스가 계속 늘어나면서 관리형 서비스가 안전한 소프트웨어 제공을 보장하는 탄탄한 토대가 되고 있습니다. 관리형 서비스를 이용하면 제공업체가 자동화된 보안 예방 조치와 증명을 사용할 수 있습니다. 예를 들어 GKE Autopilot은 노드와 노드 풀을 포함한 클러스터의 기본 인프라를 프로비저닝 및 관리하여 핸드오프 환경에서 최적의 클러스터를 구현해 줍니다. 클러스터, 워크로드 설정, 보안에 대한 Google Kubernetes Engine(GKE) 권장사항과 추천을 따르는 동시에 보다 효과적으로 컨테이너를 격리하는 설정을 적용합니다. 에릭의 의견에 따르면 이 모델은 앞으로 계속 성장하며 주류로 자리 잡을 것입니다. 시간이 지날수록 보안을 비롯하여 제공업체가 관리하는 기능이 늘어나고 수년에 걸쳐 축적되고 입증된 프로토콜과 권장사항을 이용하여 기업이 직접 관리하고 싶어 하지 않는 기능들을 제공업체가 책임지고 관리하게 될 것입니다.

3. 플랫폼 운영자는 기업이 중시하는 가이드라인을 적용하면서 범용 플랫폼으로 GKE를 실행해야 합니다.

몇 년간 에릭이 꾸준히 받았던 공통적인 질문은 GKE와 같은 관리형 Kubernetes를 기업에서 활용하는방법에 관한 것입니다. 첫 번째로 기억해야 할 사항은 클라우드 제공업체는 여러분이 생각하는 것보다 더 다양하고 많은 요소와 옵션, 기능을 개발자에게 제공한다는 점입니다. 플랫폼 소유자는 이러한 요소를 이용해 최신 앱을 구동하기 위한 안전하고 유지보수 가능한 플랫폼을 구축할 수 있습니다. 예를 들어 백업을 기본적으로 적용하고 루트 파일 시스템 액세스나 백엔드 시스템의 공개 IP 생성을 금지하는 정책을 시행하는 것이 현명합니다. 신용카드 거래를 처리하는 기업이라면 내부 개발자에게 무제한의 권한을 주는 것이 아니라, 서비스 구조에 의하여 거래가 운영 지역의 규정을 준수하도록 보장해 주는 플랫폼을 제공하기를 원할 것입니다.

Kubernetes를 프로젝트 생성과 사용하는 노드, 가져올 라이브러리와 저장소에 대한 제어를 통해 기업이 중시하는 규칙을 적용하는 맞춤 플랫폼을 구축하는 방법이라고 생각해 보세요. 백그라운드 제어는 일반적으로 앱 개발자에 의해 관리된다기보다는, 통제되는 안전한 운영 프레임워크를 개발자에게 제공합니다.

대부분의 관리형 서비스는 플랫폼 운영자가 손쉽게 이용할 수 있는 자동화된 정책 제어와 권장사항을 제공하거나 지원합니다. 예를 들어 Anthos Service Mesh는 서비스 간의 트래픽 흐름과 API 호출을 제어하도록 도와줍니다. 서비스를 자동으로 선언적으로 보호하는 기능을 통해 개발자는 생산성이 향상되는 효과를, 조직은 더 많은 기능을 더 빠르게 제공하는 효과를 누릴 수 있습니다. 동시에 회사 정책이나 정부 규정에 위배되는 기능을 출시하는 것을 방지할 수 있습니다.

Google Cloud는 Dockerfile 없이 소스 코드로 프로덕션에 즉시 사용 가능한 안전한 컨테이너 이미지를 쉽고 빠르게 만들 수 있는 오픈소스 기술인 buildpacks를 지원합니다. Artifact Registry는 Google Cloud에 안전한 비공개 빌드 아티팩트 스토리지를 설정하여 아티팩트를 액세스하거나 조회, 다운로드할 수 있는 사람을 계속 제어할 수 있도록 해 줍니다. 컨테이너 분석은 Artifact Registry 및 Container Registry의 이미지에 대한 취약점 스캔을 제공합니다.

4. Kubernetes는 에지로 계속 확장되고 보조 프로세서를 이용하며 퍼블릭 클라우드와 프라이빗 클라우드에서 효율적으로 실행될 것입니다.

이 시리즈의 마지막 에피소드에서는 에지의 Kubernetes, 보조 프로세서에서 실행되는 Kubernetes, 퍼블릭 클라우드와 프라이빗 클라우드 간 적절한 균형 찾기 등 현장에서 대두된 몇 가지 화두와 관련된 질문들을 간단히 취합했습니다.

에지의 Kubernetes.

Google은 이미 에지에서 Kubernetes의 잠재력이 실현되고 있는 것을 목격하고 있습니다. 예를 들어, 전자통신 및 소매업 분야에서는 에지에 Kubernetes가 사용되고 있습니다. 에지 보안에 대한 우려섞인 견해에 대해 에릭은 Kubernetes를 실질적으로 보호할 수 있으며 중요한 것은 풀 스택이라고 설명합니다. 신뢰할 수 있는 루트를 통해 하드웨어와 하드웨어에서 실행되는 스택에 이르기까지 종합적으로 보호하여 보안을 강화할 수 있습니다.

이 분야는 Google Cloud의 지속적인 투자 대상입니다. Google Cloud는 Next 2021에서 Google Cloud의 인프라와 서비스를 에지로 확장하는 완전 관리형 하드웨어 및 소프트웨어 솔루션 포트폴리오인 Google Distributed Cloud를 발표했습니다. 이 솔루션은 GKE가 주요 구성요소인 Anthos를 기반으로 하며 로컬 데이터 처리, 에지 컴퓨팅, 온프레미스 현대화는 물론이고 주권, 엄격한 데이터 보안 및 개인 정보 보호 요구사항을 충족하는 데 이상적입니다. Kubernetes를 에지에서 안전하게 사용할 수 있도록 Distributed Cloud는 Google 에지 네트워크, 통신사 에지(통신 서비스 업체 파트너가 제공하는 5G 및 LTE 서비스) 또는 소매 매장, 공장 현장, 지사 등 자체 에지에서 클러스터에 대한 중앙화된 구성 및 제어를 제공합니다.

보조 프로세서에서 실행되는 Kubernetes

Google은 에지에서 Anthos를 실행하는 데 필요한 GPU 가속화 컴퓨팅 및 네트워킹 솔루션을 제공하기 위해 NVIDIA와도 협력하고 있습니다. 이러한 협업은 Kubernetes와 관련된 보조 프로세서의 잠재력을 보여줍니다. 에릭은 컴퓨팅의 미래에서 보조 프로세서가 중요한 부분을 차지한다고 생각합니다. 무어의 법칙이 그 유효성을 다해가는 이 시점에 이를 보완하기 위해 업계는 GPU 기반 그래픽 처리, TPU 기반 머신러닝과 같은 사용 사례에 맞게 가속화된 전문 분야별 하드웨어를 채택하고 있습니다.

퍼블릭 클라우드와 프라이빗 클라우드 간의 적절한 균형

이 모든 급격한 혁신에도 불구하고 퍼블릭 클라우드와 독립된 프라이빗 클라우드를 균형감 있게 운영하는 문제는 여전히 회사에 골치 아픈 질문을 던집니다. 에릭은 퍼블릭 클라우드가 왜 더 많은 혜택을 가져다 줄 수 있는지에 대한 명백한 이유를 제시합니다.

개방형 퍼블릭 클라우드는 비용 효율성이 더 우수하기 때문에, 둘 중 하나만 사용할 수 있다면 거의 대부분의 경우 개방형 퍼블릭 클라우드를 사용하는 것이 좋습니다. 혁신의 속도가 빨라지고, 시간이 지날수록 할 수 있는 일이 늘어날 것입니다 에릭 브루어

퍼블릭 클라우드 제공업체를 이용한다면 클라우드 제공업체와 이 업체가 위치한 국가(오늘날은 대개 미국임)의 정부를 신뢰해야 합니다. 그들을 신뢰하지 않거나 너무 많은 위험이 존재한다고 생각하면 독립된 프라이빗 클라우드를 통해 자국에서 운영할 수 있습니다. 이 경우 Kubernetes는 프라이빗 클라우드에서 실행하기에 매우 적합하다는 장점이 있습니다. 에릭이 개발을 지원한 Anthos를 사용하면 Kubernetes를 하이브리드 및 멀티 클라우드 환경의 GKE에서 실행하거나 베어메탈에서 실행할 수 있습니다. 공급업체 종속을 우려하는 기업의 경우, Anthos에서 이전하여 온프레미스에서 Kubernetes 애플리케이션을 계속 실행할 수 있습니다.

Google Cloud의 다음 외부 출시 제품과 클라우드 컴퓨팅의 미래에 대한 에릭의 예측을 들으려면 위의 동영상을 확인하세요. Google에서 에릭의 연구 활동에 대한 최신 소식을 확인하려면 Twitter에서 @eric_brewer를 팔로우하세요.

@stephr_wong을 팔로우하면 최신 콘텐츠를 계속 확인할 수 있습니다.

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 0x7fa91c6ff9a0>)])]>

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

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

Python 생태계 지원

Mon, 22 Mar 2021 00:00:00 +0000

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

Python은 Google Cloud와 고객 모두에게 매우 중요한 프로그래밍 언어입니다. 십여 년 전 출시된 App Engine부터 Cloud Functions와 같은 최신 서버리스 제품에 이르기까지 Google Cloud 호스팅 서비스 대다수에서 런타임으로 널리 사용되고 있습니다. Google Cloud는 Python Package Index(PyPI)를 사용해 인기 있는 오픈소스 머신러닝 라이브러리인 TensorFlow를 포함한 수백 개의 클라이언트 라이브러리와 개발자 도구를 배포합니다. 또한 Google의 여러 핵심 제품과 서비스를 지원하기 위해 내부적으로도 사용하고 있습니다.

오랫동안 Python 생태계를 지원해 온 Google Cloud는 이제 Python 프로그래밍 언어, 생태계, 커뮤니티를 이끌고 있는 비영리단체인 Python Software Foundation에 대한 지원을 확대합니다.

첫째, Python 생태계의 공급망 보안 강화에 중점을 둔 3가지 특정 PSF 프로젝트를 지원하기 위해 $350,000가 넘는 기금을 기부합니다. 지원 대상은 다음과 같습니다.

PyPI용 제품화된 멀웨어 감지
기본 Python 도구 및 서비스 개선
CPython 프로젝트에서 유지보수에 우선순위를 두고 백로그를 해결하도록 돕는 정규직 직원으로 구성된 2021년 CPython Developer-in-Residence

둘째, PSF에 현물 기부 중인 Google Cloud 인프라를 계속 지원하기로 했습니다. Google Cloud 인프라는 Python Package Index 등 PSF에서 운영하는 중요 인프라를 지원하는 데 도움이 되고 있습니다.

“Google Cloud가 Cloud Storage를 통해 중요 피어링 계약에 대한 액세스 권한을 부여한 덕분에 PyPI 다운로드를 비용 효율적으로 제공하고 다른 인프라 제공업체의 제한된 리소스를 효과적으로 관리할 수 있게 되었습니다.” - Python Software Foundation 인프라 부문 책임자 이이 더빈

셋째, 이제 Google Cloud 공개 데이터 세트 프로그램이 거의 실시간으로 업데이트되는 PyPI 다운로드 통계 및 PyPI 프로젝트 메타데이터의 새로운 공개 데이터 세트 환경으로 이용됩니다. Google Cloud 계정 소유자는 누구나 BigQuery 또는 월 최대 1TB의 데이터 쿼리를 무료로 제공하는 BigQuery 샌드박스를 사용해 이 데이터 세트에 쿼리할 수 있습니다. 데이터 세트 분석에 대한 자세한 내용은 이 사용자 가이드를 참조하세요.

“PyPI 분석을 BigQuery의 공개 데이터 세트로 게시하면서 PyPI을 온라인 상태로 유지하는 팀과 라이브러리 유지보수 담당자에게 중요한 정보 액세스를 지원하고 관리하는 부담을 덜 수 있었습니다. 데이터 세트를 피드하는 파이프라인을 Cloud Functions로 이전한 결과 더 큰 비용 절감 효과를 누리고 배포가 간편해졌습니다.” - 이이 더빈

마지막으로 Google Cloud는 지난해 기준으로 11년 연속 PSF 재단 스폰서십을 갱신했습니다. 이처럼 다양한 형태의 지원을 모두 고려하여 조직 최초로 새로운 스폰서십 등급 시스템의 최고 등급에 해당하는 'Visionary' 후원자가 된 것을 자랑스럽게 생각합니다.

많은 Google Cloud 고객과 마찬가지로 Google Cloud도 Python을 적극 지지합니다. 이러한 PSF에 대한 지원은 앞으로 오랫동안 Python 생태계의 굳건하고도 성공적인 미래를 보장하는 데 도움이 될 것입니다. 관련 프로젝트와 스폰서십에 대한 자세한 내용은 PSF 블로그에서 확인할 수 있습니다.

빌드팩 도입으로 간편해진 컨테이너 이미지 만들기

Thu, 12 Nov 2020 09:00:00 +0000

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

새 애플리케이션을 빌드하는 개발자는 코드 컨테이너화가 아닌 코드 작성에 집중하기를 원합니다. 이미 컨테이너를 사용하는 경우에도 양질의 안전한 컨테이너 이미지를 만들기가 복잡하고 시간이 많이 들 수 있습니다. 오늘 Google은 Google Cloud 전반에서 빌드팩에 대한 광범위한 지원을 발표합니다. 빌드팩은 Dockerfile 없이 소스 코드로 프로덕션에 즉시 사용 가능한 안전한 컨테이너 이미지를 쉽고 빠르게 만들 수 있는 오픈소스 기술입니다.

이번 출시의 중심에는 오픈소스 빌드팩 및 빌더 모음이 있습니다. CNCF 빌드팩 v3 사양을 기반으로 한 이 빌드팩은 권장사항을 따르며 Cloud Run(완전 관리형), Anthos, Google Kubernetes Engine(GKE) 등 Google의 모든 컨테이너 플랫폼에서 실행하기에 적합한 컨테이너 이미지를 생성합니다. 이 빌드팩은 프로덕션 강화 및 테스트를 거쳤으며 3월부터 App Engine 및 Cloud Functions의 대다수 빌드에서 규모에 맞춰 사용되었습니다.

Buildpack 사용

빌드팩은 다양한 방법으로 활용할 수 있습니다. 우선 컨테이너화를 아직 완전히 도입하지 않았다면 빌드팩을 통해 최신 컨테이너 런타임 및 전송 플랫폼을 사용할 수 있습니다. 원시 상태로 찾은 Dockerfile을 적절하게 검사하고 맞춤설정할 시간이 없는 경우 프로젝트를 빠르게 수행하는 데에도 유용합니다.

클릭 몇 번이면 Google Cloud 빌드팩을 사용해 볼 수 있습니다. 빌드팩 샘플 프로젝트를 방문하여 'Google Cloud에서 실행' 버튼 중 하나를 클릭하면 됩니다.

로컬에서 빌드팩을 애플리케이션에 사용해 보려면 Docker 및 ’pack’ CLI 도구를 설치한 후 다음 명령어를 실행합니다.

code_block: <ListValue: [StructValue([('code', 'cd my-app\r\npack build my-app --builder gcr.io/buildpacks/builder'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa91c2574f0>)])]>

(Go, 자바, Node, Python, .Net이 지원됩니다. 정상적인 빌드를 위해서는 추가 구성이 필요할 수 있습니다.)

설치를 원하지 않는 경우 Cloud Build에서 빌드팩 기반 빌드를 실행하면 Cloud Run에 간편하게 배포할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud alpha builds submit --pack image=gcr.io/[project-id]/my-app\r\ngcloud run deploy --image=gcr.io/[project-id]/my-app --platform managed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa91c2575b0>)])]>

빌드팩은 어떻게 작동하나요?

빌드팩은 빌더라고 부르는 OCI 이미지로 배포 및 실행됩니다. 각 빌더에는 하나 이상의 빌드팩이 있을 수 있습니다. 오늘 출시되는 Google Cloud 빌드팩의 빌더는 gcr.io/buildpacks/builder에서 제공됩니다.

빌더에는 소스 코드의 언어를 자동으로 감지하는 기능이 있습니다. 빌드팩에서 실행할 수 있는 `bin/detect`를 사용하면 됩니다. 감지 스크립트는 특정한 순서로 호출되며 빌드에 적절한 개수의 빌드팩이 선택되면 중지됩니다. 예를 들어 대부분의 Node.js 빌드팩은 packages.json 파일이 있는지 찾습니다. 사용할 빌드팩을 수동으로 지정하여 자동 감지 단계를 건너뛸 수도 있습니다.

빌드팩이 선택되면 `bin/build`가 실행됩니다. 이 스크립트는 소스 코드를 일반적으로 종속 항목 설치 또는 코드 컴파일 등의 작업을 수행하는 실행 가능한 아티팩트로 변환해 줍니다.

빌드 단계의 출력이 'run' OCI 기본 이미지 위에 추가되어 선택한 플랫폼에서 실행할 수 있는 최종 컨테이너 이미지를 만듭니다.

Google Cloud 빌드팩

Google Cloud 빌드팩은 보안, 속도, 재사용성에 최적화되어 있습니다. 앱과 함수 모두를 컨테이너 이미지로 빌드할 수 있습니다. 함수를 빌드할 때는 Google Cloud의 오픈소스 함수 프레임워크를 사용해 패키지화합니다.

Google Cloud 빌드팩에서 사용하는 관리형 Ubuntu 18.04 기본 이미지는 정기적으로 보안 취약점을 스캔하며 감지된 취약점에 자동으로 패치를 적용합니다. 이를 통해 빌드팩으로 소스 코드를 빌드할 때 최대한의 보안을 보장합니다.

Google Cloud 빌드팩은 추가 시스템 패키지를 사용하거나 개발팀의 특정 니즈에 맞게 맞춤설정할 수도 있습니다.

빌드팩 자체가 Go로 작성되어 언어마다 빌드팩을 하나씩 만드는 대신 소형 모듈식 빌드팩을 결합할 수 있습니다. 노드 패키지를 설치하는 NPM 빌드팩을 예로 들어 보겠습니다. 이 빌드팩은 Node.js 빌드에 사용되는 것은 물론이고 NPM 패키지(예: Rails의 Ruby)를 사용하는 다른 언어 및 프레임워크에도 사용될 수 있습니다.

Google Cloud의 광범위한 지원

오픈소스 빌드팩 외에도 Google Cloud의 다양한 제품에서 빌드팩을 지원합니다.

Cloud Build에서는 현재 gcloud CLI 도구(gcloud alpha builds submit --pack image=gcr.io/[project-id]/my-app)를 통해 빌드팩을 기본적으로 지원합니다(문서 참조).
Cloud Run - Cloud Run에 대한 지속적 배포(Cloud Build 트리거 이용)에 빌드팩이 사용되도록 구성할 수 있습니다(문서 참조).
App Engine - 현재 빌드팩은 대부분의 최신 App Engine 런타임에서 소스 배포에 활용되는 기본 메커니즘입니다. 무엇보다도 빌드팩에서 소스 기반 자바 배포를 지원합니다(이전에는 JAR 기반 배포만 지원됨). 앞으로 새로 출시될 모든 런타임에서 빌드팩을 사용할 예정입니다.
Cloud Functions - App Engine과 마찬가지로 빌드팩이 배포된 함수를 빌드하는 기본 메커니즘입니다.
Cloud Code - Cloud Code IDE에서 빌드팩으로 소스 코드를 빌드하고 생성된 컨테이너를 직접 GKE에 배포할 수 있습니다.
Skaffold는 빌드팩을 사용한 실시간 개발을 지원합니다. 소스 코드를 수정하면 빌드팩에서 지속적으로 앱을 다시 빌드하여 앱의 로컬 인스턴스에 적용되는 변경사항을 미리 확인할 수 있습니다.
Cloud Shell - 이제 pack CLI 도구가 Cloud Shell에 기본적으로 설치됩니다. 덕분에 추가 패키지를 설치하지 않고도 Cloud Shell에서 빌드팩을 실행할 수 있습니다.

지금 시작하기

GitHub 저장소에서 Google Cloud 빌드팩에 대해 자세히 알아보세요. 버튼 하나만 클릭하면 빌드팩을 사용하는 앱 샘플을 배포해 볼 수 있습니다.