クラウドファースト

Energy Drive「サステナビリティの実現」 - Google Cloud を活用したシステムパフォーマンスの動的なモニタリングと分析

Fri, 16 Dec 2022 00:10:00 +0000

※この投稿は米国時間 2022 年 11 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

プールポンプやガレージドアから大型の工業用ファンやポンプに至るまで、さまざまなものに使われている電気モーターは、世界の発電量の約 50% を消費しています。しかし、このような古い設備をより効率的なエンジニアリングで最適化することによって、大幅なエネルギーの節約を実現できる可能性があります。ただ、大きな課題が残されています。大型の工業機器のエネルギー効率を高めるには、どうしたらよいのでしょうか。数十年前の機器の場合にはなおさらです。

こうした課題と電力消費の削減に向けて、私たちは Energy Drive を設立することになりました。当社は、工業環境、とりわけ鉱業（mining）、金属（metals）、鉱物（minerals）のトリプル M と呼ばれる分野の大規模なエネルギー利用者が、エネルギーに関連するサステナビリティの目標を達成し、効率化の障壁を取り除く手助けをしたいと考えました。

当社が取るアプローチは、非常に的を絞ったものです。ファンやポンプのモーターなどの工業機器に可変速駆動装置（VSD）と呼ばれるテクノロジーを組み込みます。この VSD を使用することで、固定周波数の電力供給を可変周波数の出力に変換します。駆動装置（VSD）は、低周波の場合は低速、高周波の場合は高速というようにモーターの動作を制御します。簡単にいうと、モーター速度を比較的細かく調整することによって、消費電力を大きく削減します。

Energy Drive のチームメンバー

エネルギー消費量の削減とダウンタイムの最小化

すべてのシステムのエネルギー消費量とパフォーマンスは、最新の測定技術と工業用コンピュータによりモニタリングされています。このデータはウェブアプリケーションを通じてクライアントに送られ、プラントプロセスの最適化状況と、結果として生じるコストとエネルギーの節約量が迅速に表示されます。

また、Energy Drive は独自の専用システムを使用してクライアントの設備をモニタリングしています。「予測される設備故障に対して早期に警告を出し、問題の可視性を高めることで、予定外のダウンタイムを削減しています。」

ビジネス規模の拡大とともに、当社で保存し、クライアントからアクセスできるようにするデータの量も増加しました。成長目標に合致するデータベース環境を選択する際、目を引いたのは Google Cloud でした。Google Cloud は、機能を犠牲にすることなく優れたスケーラビリティと柔軟性を実現しており、当社が検討したいくつかの他のクラウド環境よりもはるかに管理が簡単です。

当社は Google Compute Engine を利用して Google Cloud インフラストラクチャ上で仮想マシンを実行し、クライアントがパフォーマンスデータの確認に使うカスタムビルドのウェブツールの実行には Google App Engine を活用しています。また、環境内のデータの保存とアクセスには、Google Cloud Storage を使用しています。

BigQuery は、当社のビジネスにとって特に重要です。他のクラウドベースのデータウェアハウスを検討した際、当社の要件に合致する価格モデルはありませんでした。BigQuery では、抽出し、操作したデータに対してのみ料金を支払います。実際、SQL 環境から切り替えたことで、データ使用量を 80% 削減できました。

BigQuery を使用すれば、クライアントは現在のデータまたは過去のデータに数秒でアクセスできます。過去には多くの人が手動システムに依存し、必要な情報を抽出するためにはネットワークや何千ものデータポイントを選別しなければならなかったため、これは大きな改善です。

750 ギガワット時（GWh）の電力を節約

このデータに、クライアントの収益に大きな違いをもたらす分析情報をオーバーレイすることもできます。今では、「去年の今頃、あのシステムでは何が起きていたか」とクライアントから尋ねられたとき、その詳細を素早く取り込み、わかりやすい形式で提示できるようになりました。同時に、当社の設備は資本支出不要のパフォーマンスモデルに基づいているため、クライアントのプロジェクト実施を簡素化し、費用を削減します。資金をめぐって他の社内プロジェクトと競合しなければならない大規模な資本支出計画があると、短期的な打撃を受けがちですが、そういったこともありません。

何より、Google Cloud は、当社のエネルギー消費量の削減に関する取り組みを支える原動力となっています。当社は設立以来、750 GWh の電力を節約してきました。これは平均的な規模の製鋼所の年間消費量の半分に相当します。別の見方をすれば、毎日約 16,500 世帯分に相当する消費量を節約していることになります。

また、省エネ業界において当社の実績が認められたことを誇りに思います。2019 年には、South African Energy Efficiency Confederation から「Energy Efficiency Company of the Year」を授与されました。2021 年には、2040 年のカーボンニュートラルと 2050 年のネットゼロの目標に向けて南アフリカの鉱業会社を支援した活動が評価され、「Industrial Energy Project of the Year」を受賞しました。

さらに当社は、南アフリカでのエンジニアの人材育成にも力を注いでいます。大学卒業生を対象としたプログラムでは、電気工学、機械工学、プロセス工学をはじめとする多くの分野での体験を若者に提供しています。プログラムの参加者は、エンジニアリングと分析における最新の動向を直接把握することで、自信をもってキャリアパスを選択できるのです。

これは、Google Cloud の最新ツールや機能強化など、最高水準のスキルと技術をビジネスに組み込むという当社の決意につながっています。現在、当社は Google Cloud の優れた機械学習機能と、この機能を当社のデータに適用して、さらに効率的なエネルギーをクライアントに提供できる可能性に大きな期待を寄せています。Google が今後も革新を続けていくことを確信しているので、当社は自信を持って事業を拡大し、現在と将来にわたるサステナビリティの目標の達成に向けてクライアントをサポートできるのです。

Google Cloud がスタートアップをサポートする方法について、こちらのページでプログラムの詳細をご確認ください。また、こちらから更新情報の配信にご登録いただいた方には、コミュニティ活動、デジタルイベント、スペシャルオファーなどの情報をお届けします。

- Energy Drive 分析担当ゼネラルマネージャー Ryan Botha 氏
- Energy Drive グローバルビジネスデベロップメントマネージャー James Sharp 氏

Coursera の無料のトレーニングで需要の高いクラウド関連の職種に必要なスキルを磨く

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

※この投稿は米国時間 2022 年 11 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

近年、クラウドテクノロジーの導入が加速しており、2023 年もその成長は続くと予測されています¹。このことは、クラウドスキルを備えた人材を引き付けて維持するという組織のニーズも並行して増大することを意味します2。

デジタルトランスフォーメーションと同じペースでクラウド関連のキャリアアップを続ける

Google Cloud とのパートナーシップにより、Coursera は人気のクラウド関連トレーニングの一部への無料アクセスを提供し、ユーザーがスキルを磨き就職市場で他者との差別化を実現できるよう支援しています。技術的な能力の向上、キャリアアップ、実践経験の蓄積、知識を証明するための認定資格の取得など、さまざまな目標を支援するリソースをご用意しています。

厳選された無料のトレーニングでキャリアの未来に備え、認定資格を取得する

評判の高い各種 Google Cloud プロジェクト、プロフェッショナル認定資格、スペシャライゼーション、コースから 1 つを選んで利用できます。2022 年 12 月 31 日までに利用を開始してください。

今回のプロモーションに含まれる Google Cloud トレーニングは、機械学習エンジニアリング、データエンジニアリング、クラウドエンジニアリング、アーキテクチャ、セキュリティなど、さまざまな職種に関するものです。トレーニングコンテンツは技術職の方と技術職ではない方の両方を対象としており、基礎的な内容から高度な知識および経験レベルまで網羅しています。トレーニングを開始する時点で必要となる知識がある場合は、トレーニングの説明内に記載されていますのでご確認ください。

トレーニング完了までの所要時間もそれぞれ異なるため、以下に詳細をまとめました。ご自分に合った取り組みレベルを選ぶためにお役立てください。Coursera でのトレーニングを完了すると、ソーシャルメディアで他者と共有したり履歴書に記載したりできる証明書が付与されます。

Coursera で利用可能な Google Cloud トレーニングの種類

本プロモーションで提供している Coursera のトレーニングの種類について以下にまとめました。トレーニング完了までの所要時間が短いものから順に記載しています。

プロジェクト: 完了までの所要時間は約 30～90 分

クラウドワークスペースでソフトウェアとツールを使用し、インタラクティブな環境で新しいスキルを習得します。ダウンロードは必要ありません。

コース: 完了までの所要時間は約 4～19 時間

コースには通常、一連の導入レッスン、ステップバイステップ形式の実践演習、Google の知識リソース、知識チェックが含まれます。

スペシャライゼーション: 完了までの所要時間は約 2～6 か月

スペシャライゼーションはスキルを習得するための一連のコースで、実践的なプロジェクトが含まれます。

プロフェッショナル認定資格: 約 1～9 か月

プロフェッショナル認定資格には実践的なプロジェクトとコースが含まれます。完了すると、プロフェッショナル認定資格を取得できます。関連する Google Cloud 認定試験の対策として利用できます。

需要の高いクラウド関連の職種向けの人気トレーニング

自分のペースでトレーニングを進め、現在の職種や将来的に希望する職種向けのスキルを磨くことができます。需要の高い職種向けの人気トレーニングには、以下のようなものがあります。

技術職以外の職種で、クラウドテクノロジーに関わる業務に従事している方向け

プロフェッショナル認定資格 - Cloud Digital Leader
クラウドテクノロジーおよびデータならびにデジタルトランスフォーメーションに関する知識を得られる 4 つのコースの基本レベルシリーズです。クラウド関連のビジネスイニシアチブやディスカッションに、より自信をもって参加できるようになります。営業、人事、オペレーションなど、技術職ではないがそれと隣り合わせの仕事に従事している場合は、このトレーニングからメリットを得られるでしょう。

アプリケーションデベロッパー向け

スペシャライゼーション - Developing Applications with Google Cloud
このスペシャライゼーションは、Google Cloud からマネージドサービスをシームレスに統合するアプリケーションを設計、開発、デプロイする方法を習得することを望むアプリケーションデベロッパーを対象としています。ラボ、プレゼンテーション、デモなど、さまざまトレーニング形式が用意されています。ラボでは任意の言語（Node.js、Java、Python）を使用できます。実際の IT 環境で即座に使用できる実践的なスキルを習得できます。

経験豊富な ML および AI エンジニア向け

プロフェッショナル認定資格 - ML Engineer
このトレーニングでは、Google Cloud の機械学習エンジニアプロフェッショナル認定資格に備えることができます。データエンジニアリングまたはプログラミングの経験があり、実際に機械学習を適用する方法と機械学習関連の職種で成功を収める方法を習得することを望む参加者におすすめの中級レベルのトレーニングです。このプロフェッショナル認定資格には 9 つのコースがあり、週に 5 時間の推奨ペースで進めた場合、完了までの所要時間は約 7 か月となります。

技術職に従事している Google Cloud 初心者向け

コース - Google Cloud Fundamentals for AWS Professionals
このコースでは、動画と実践的なラボを組み合わせて主要なコンセプトと用語を紹介します。完了までの所要時間は約 9 時間です。Google ネットワークインフラストラクチャの構成要素や Infrastructure as a Service と Platform as a Service の違い、さらにプロジェクトの構成方法や Google Cloud の操作方法について学ぶことができます。また、仮想ネットワーキングに焦点を当てた Google Cloud Compute Engine についても取り上げます。

データエンジニアリングの初心者向け

プロジェクト - Introduction to SQL for BigQuery and Cloud SQL
Google Cloud コンソールで実施するセルフペースラボです。BigQuery と Cloud SQL で構造化クエリを実行するインタラクティブな演習を行います。初心者レベルのプロジェクトで、完了までの所要時間は約 1 時間です。

1 年の終わりが近づいている今こそ、クラウドスキルのレベルアップを目指す絶好のタイミングです。無料で利用できる Coursera の Google Cloud トレーニングの詳細をご確認ください。ご利用の期限は 2022 年 12 月 31 日です。

_{1. 出典: Forbes: The Top 5 Cloud Computing Trends in 2023}

_{2. 出典: Forbes: From Crisis to Opportunity: Tackling the U.S. Cloud Skills Gap}

- 学習パートナーシップ担当グローバル責任者 Carl Tanner

モデル化されたデータへのアクセスが可能な Looker Studio の公開プレビュー版がリリース

Fri, 11 Nov 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 11 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は 4 月にLooker と Looker Studio （旧名称: データポータル）のインテグレーションの限定公開プレビュー版を発表しました。10 月に開催された Next では、Looker 傘下のビジネスインテリジェンスをさらに統一するため、データポータルを Looker Studio と改名したことが発表されました。現在、これらのプロダクトは Looker ファミリーの一部になり、Looker Studio は引き続き無料で利用できます。また、Next では、この 2 つのプロダクトのインテグレーションに機能を追加した公開プレビュー版をリリースしたことを発表しています。

インテグレーションの仕組み

Looker コネクタをご利用のお客様は、Looker Studio 内で Looker から管理されたデータにアクセスできます。Looker Studio 用の Looker コネクタは、セルフサービスと管理された BI の両方を一つのツールや環境で利用できるようにします。Looker Studio をご利用のお客様は、Looker に接続することで、セマンティックデータモデルを活用できます。このデータモデルを使用すると、ビジネスデータのキュレート済みのカタログ、事前定義されたビジネス指標、組み込みの変換機能により、複雑なデータをエンドユーザー向けに単純化できます。これにより、ユーザーは計算とビジネスロジックを中央のモデル内で整合させることができ、組織における信頼できる唯一の情報源の構築を促進できます。

Looker Studio のレポート内で Looker のモデルデータにアクセスすることで、アドホックデータと管理されたデータの両方を利用したレポートを一つのツールで作成できます。LookML を利用して Looker のデータモデルを作成できます。これは、ビジネスルールや定義を、1 つの Git でバージョン管理されたデータモデルで、一元的に定義、管理することによって可能です。

ユーザーは、Looker Studio 内で（スプレッドシート、csv ファイル、その他のクラウドソースから）管理されていないデータを分析し、迅速にプロトタイプ化できます。Looker からの管理されたデータと Looker Studio 内の 800 以上のデータソースから利用できるデータを組み合わせて新しい知見を迅速に生み出します。Looker Studio で Looker が管理するデータを情報量の多いカスタマイズ可能なダッシュボードやレポートに変換し、チームメンバーや社外ユーザーとのリアルタイムな共同編集でダッシュボードを作成できます。

公開プレビュー版の新機能

このプレビュー版をより多くのお客様に提供できることを嬉しく思います。すでに多くのお客様から、Looker Studio 用の Looker コネクタへのアクセスについてご要望をいただいております。また、今回の公開プレビュー版では、Looker Studio で Looker モデルをより完全に表現するための機能が追加されました。

大規模な Explore を使用する際にフィールドを整理された状態に保てるよう、Looker Studio のデータパネルでのフィールド階層がサポートされるようになりました。データパネルにフォルダ構造が表示され、フィールドがビュー、グループラベル、ディメンショングループといった通常の方法で整理されていることが確認できます。
Looker のモデルで指定された記述情報をすぐに確認できるように、フィールドの説明を新しい方法で公開することで、より高い視認性を提供しています。フィールドの説明は、データパネルおよびレポート内のテーブルで利用可能です。
また、Looker の Explore から「Looker Studio で開く」オプションが表示され、Explore を参照するデータソースで Looker Studio レポートをすばやく作成できるようになりました。
また、基になるデータソースから最新のデータをユーザーが取得できるように、Looker Studio でデータを更新すると、Looker キャッシュのデータも更新されるようになりました。

特に今回の公開プレビュー版では、Looker Studio における Looker データソースの制限を強化し、管理者が安心して機能を試用できるようにしました。

Looker Studio では Looker データソースの所有者の認証情報を無効にしているため、共有レポートなどについては各閲覧者が自分の認証情報を提供する必要があります。
また、現在、Looker Studio では、これらのデータソースのデータダウンロードとメールのスケジューリングを無効にしています。今後、Looker のこれらの権限と統合する予定です。
計算フィールドが無効になっているため、エンドユーザーは Looker Studio で独自のカスタム指標やディメンションを定義できず、Looker Explore で定義されたフィールドを使用する必要があります。

プレビューにアクセスする方法

このインテグレーションにより、Looker Studio と Looker の両方に加えられた変更を含むコネクタを網羅し、Looker モデルを表現し Looker Studio で Looker のガバナンスを拡張できます。Google Cloud は、セルフサービスと管理された BI を両立させる完全な統一プラットフォームを実現するための取り組みを続けており、今後もこの目標に向けて邁進していきます。引き続き Looker Studio に機能を追加して Looker モデルを完全に表現することを計画しており、Looker の管理者が現在の Looker で System Activity を使うのと同じように、Looker Studio から来る API アクティビティを確実に把握できるようにしたいと思っています。ガバナンスの拡張では、Looker から Looker Studio へと信頼の輪を広げたいと考えています。実現に向けて最善の方法を計画する際にご協力いただけるお客様を探しています。

このインテグレーションは、Looker バージョン 22.16 以降の Google Cloud でホストしたインスタンスと互換性があります。アクセス権を得るには、Looker インスタンスの管理者は、インスタンスの URL と有効化する組織ドメインを指定したお申込みフォームを送信します。Looker Studio の開始方法については、Looker Studio ヘルプセンターをご覧ください。

詳細とデモについては、Next '22 の ANA202: Bringing together a complete, unified BI platform with Looker and Data Studio のセッションと基調講演 ANA100: Looker とデータポータルの新機能をご覧ください。

- アウトバウンドプロダクトマネージャー Ani Jain
- プロダクトマネージャー Andrew Becker

Cloud Workstations のご紹介: クラウド上の安全なマネージド開発環境

Wed, 09 Nov 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 11 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

この 2 年間でリモートコラボレーションが前例を見ないほど急増したことで、開発チームは新しいコラボレーションの方法を見つける必要に迫られています。この新たな現実において生産性を改善するツールの需要も高まる一方です。また、このような分散型勤務によって、データの引き出し（情報が社外に出る）などの新しいセキュリティリスクが発生しています。そのため、開発チームは、多くの企業にとっての知的財産であるソースコードとデータを保護する必要があります。

Google Cloud Next で、統合された Google Cloud 上のフルマネージド開発環境を提供する Cloud Workstations の公開プレビュー版をご紹介しました。Cloud Workstations は、開発者のオンボーディングを加速させ、日々のワークフローの生産性を安全に向上させることに焦点を当てたソリューションであり、Google Cloud コンソールにアクセスし最初のワークステーションを構成するだけで、今すぐ使い始めることができます。

Cloud Workstations の概要

Cloud Workstations は、セキュリティが組み込まれ、開発者に柔軟性をもたらし、よく使われる多くのデベロッパーツールがサポートされているマネージド開発環境を提供します。企業の技術チームのニーズに対応しています。

開発者は、場所を問わずにブラウザやローカルの IDE から安全、高速、カスタマイズ可能な開発環境にすぐにアクセスできます。Cloud Workstations を使用すれば、環境構成を統一できるので、開発者育成に要する時間を大幅に短縮し、「私のマシンでは動いたのに」という問題に対処することができます。
管理者は、開発者向けに開発環境を簡単にプロビジョニング、スケーリング、管理、保護でき、限定公開、自己ホスト型、オンプレミス、さらには他のクラウドで実行されているサービスやリソースへのアクセスを提供できます。Cloud Workstations を使えば開発環境を簡単にスケーリングできるので、日常のタスクを自動化すれば、効率性と安全性の向上を実現できます。

Cloud Workstations は 3 つの核心的な領域に焦点を当てています。

一貫した環境を使った開発者の迅速なオンボーディング
カスタマイズ可能な開発環境
セキュリティ管理とポリシーのサポート

一貫した環境を使った開発者の迅速なオンボーディング

開発者が新しいプロジェクトに着手するには数日から数週間かかることがあり、その多くを開発環境の設定に費やすことになります。従来のローカル設定のモデルでは、時間が経つにつれて構成がずれてしまい、「私のマシンでは動いたのに」という問題が発生し、開発者の生産性が失われ、コラボレーションが阻害されることがあります。

こういった問題に対処するために、Cloud Workstations は、開発環境を構築して管理するフルマネージドソリューションを提供します。管理者やチームリーダーは、1 つ以上のワークステーション構成をチームの環境テンプレートとして設定することができます。数百から数千人の開発者の環境の更新やパッチ適用は、ワークステーションの構成を更新して Cloud Workstations に更新処理を任せるだけで簡単に実行できます。

開発者は、アクセスが許可されている構成の中から選択するだけで独自のワークステーションを作成できるので、整合性の確保が容易になります。開発者がコードの記述を開始する時点で、適切なバージョンのツールを使っているかどうかを確認できます。

カスタマイズ可能な開発環境

開発者はそれぞれのニーズに合わせて最適化されたさまざまなツールやプロセスを使用しています。Cloud Workstations では、ツールを柔軟に選択できるようになっていて、開発者は最も生産性の高いツールを使用しつつ、リモート開発の利点も享受することができます。ここでは、この柔軟性を可能にする機能をいくつかご紹介します。

マルチ IDE のサポート: 開発者はタスクごとに異なる IDE を使用するので、効率性を最大限に確保するために IDE をカスタマイズすることがよくあります。Cloud Workstations は、IntelliJ IDEA Ultimate、PyCharm Professional、GoLand、WebStorm、Rider、Code-OSS など、多数のマネージド IDE をサポートしています。また、JetBrains と提携しているので、既存のライセンスを Cloud Workstations で利用することもできます。これらの IDE は、最適化されたブラウザベースやローカルクライアントのインターフェースで提供されるので、レイテンシやカスタマイズの制限など、汎用のリモートデスクトップツールの課題やレイテンシを回避できるようになります。

コンテナベースのカスタマイズ: 開発環境は、IDE のほかにも、ライブラリや IDE の拡張、コードサンプル、さらにはテスト用のデータベースやサーバーなどで構成されています。開発者が必要なツールを迅速に入手できるように、Cloud Workstations ではコンテナイメージを拡張して、お好みのツールを追加することができるようになっています。
サードパーティの DevOps ツールのサポート: Cloud Build などの Google Cloud サービスや、さらには GitLab、TeamCity、Jenkins などのサードパーティのツール等、どの組織でも独自で試行錯誤を重ねたツールを使用しています。Virtual Private Cloud（VPC）内で Cloud Workstations を実行することで、Google Cloud やオンプレミス、他のクラウドであっても、自己ホスト型のツールに接続できます。

セキュリティ管理とポリシーのサポート

Cloud Workstations では、Google Cloud 上の本番環境で使用しているのと同じセキュリティポリシーとメカニズムを、開発者のワークステーションに拡張できます。開発環境のセキュリティを確保するために Cloud Workstations が提供している手段を紹介します。

ソースコードやデータをローカルマシンに転送することも、保存することもありません。
各ワークステーションは 1 つの専用仮想マシン上で動作するので、開発環境間の分離が強化されます。
Identity and Access Management（IAM）ポリシーが自動的に適用され、最小権限の原則に従って、ワークステーションへのアクセスを 1 人の開発者に制限することができます。
ワークステーションは、プロジェクトや VPC 内で直接作成でき、ファイアウォールルールやディスクのスケジュールバックアップなどのポリシーを適用しやすくなっています。
VPC Service Controls を使ってワークステーションのセキュリティ境界を指定し、機密性の高いリソースへのアクセスを制限したり、データの引き出しを防いだりできます。
セッションが制限時間に達したら、環境を自動的に更新できるので、開発者は適時自動で更新を適用できるようになります。
また、完全にプライベートな上り / 下り（内向き / 外向き）に対応しているので、ワークステーションにアクセスできるのはプライベートネットワーク内のユーザーだけです。

お客様とパートナー様の声

「当社は、世界中に何百人もの開発者を抱えていて、いつでもどんなデバイスからでも接続できる必要がありました。Cloud Workstations を導入することで、当社のカスタムソリューションをより安全で制御された、グローバルなマネージドソリューションに置き換えることができました。」- L'Oréal データエンジニアリング責任者 Sebastien Morand 氏

「従来の完全な VDI ソリューションでは、開発者のエクスペリエンスとは別に、オペレーティングシステムやその他の要素に気を配る必要があります。当行では、新たに問題を増やすことなく問題を解決できるソリューションを求めていました。」- Commerzbank サイバーセンターオブエクセレンス責任者 Christian Gorke 氏

「Cloud Workstations の取り組みで Google Cloud と緊密に連携できることを大変嬉しく思っています。今回の提携により、JetBrains IDE を使ったリモート開発を世界中の Google Cloud ユーザーが利用できるようになります。セキュリティを強化すると同時にコンピューティングリソースを節約しながら、リモート開発での開発者の生産性を向上させるべく、共に取り組んでいきたいと思います。」- JetBrains CEO、Max Shafirov 氏

使ってみる

今すぐ Cloud Workstations を使ってみるには、コンソールにアクセスするか、Google Cloud のウェブページ、ドキュメントで詳細をご確認ください。または、Cloud Next セッションをご視聴ください。Cloud Workstations は、エンドツーエンドのソフトウェアデリバリーシールドを提供するうえで重要な役割を担っています。ソフトウェアデリバリーシールドについて詳しくは、このウェブページをご覧ください。

- プロダクトマネージャー Marcos Grappeggia
- アウトバウンドプロダクトマネージャー Nate Avery

GKE Autopilot で GPU ワークロードとさらにサイズの大きい Pod のサポートを導入

Google Cloud Deploy が Cloud Run とデプロイ検証サポートを追加

Wed, 05 Oct 2022 05:00:00 +0000

※この投稿は米国時間 2022 年 9 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud のお客様は、Cloud Run を含む Google が提供する広範なプラットフォームに、アプリケーションを簡単にデプロイできることを望んでいます。コードを本番環境へ push する際に、デプロイが成功したという確証が欲しいのです。

本日、Google Cloud Deploy 向けに、Cloud Run ターゲットとデプロイ検証のプレビュー版が使用可能になったことを発表いたします。

Cloud Run へのデプロイ

Google のマネージドサーバレスコンテナランタイムである Cloud Run のサポートは、Google Cloud Deploy で最も多い機能リクエストでした。理由は簡単です。Google Cloud Deploy に Cloud Run ターゲットを追加することで、エンタープライズアプリケーションの開発や提供が容易になるからです。

プレビューでは、デリバリーパイプラインで Cloud Run ターゲットの指定とデプロイが可能になり、Cloud Run サービスの継続的デリバリーが可能になりました。

Google Cloud Deploy が他のターゲットに向けて提供する継続的デリバリー機能（ロールバック、承認、監査、デリバリー指標など）は、すべて Cloud Run ターゲットでも利用可能です。この整合性と、同等の機能により、プラットフォーム運用者やアプリケーションデベロッパーは、ランタイムターゲットにかかわらず、同じ方法でアプリケーションデリバリーパイプラインを管理し、推測することができます。

Google が開発し、Cloud Deploy の基盤となるオープンソースのクラウドネイティブツールである Skaffold によって、整合性が実現します。最新の 2.0 ベータ 2 リリースにより、Skaffold ユーザーは、すでに行っているGoogle Kubernetes Engine や Anthos clusters の場合と同じ方法で Cloud Run サービスの開発とデプロイができるようになりました。これにより、Skaffold ワークフローは、Google Cloud Deploy の導入と拡張の一貫したポイントになっています。

2 つの Cloud Run ターゲットでの継続的デリバリーパイプライン

デプロイを検証する

多くの場合、デプロイの成功や失敗には、ターゲットプラットフォームへのアーティファクトの展開だけではなく、デプロイをさらに確認するための、自動化された統合形式やカナリアテスト形式のテストが伴います。

お客様からは、Google Cloud Deploy でデプロイ検証の正式なサポートをしてほしいというご要望がありました。デプロイが成功しても、デプロイ後の検証でテスト失敗となったとき、ロールアウトも失敗と認識されるべきです。

Google Cloud Deploy では、アプリケーションのデプロイが成功したときに 1 つ以上の（テスト）コンテナを特定し、即座に実行できるようになりました。この Google Cloud Deploy でのデプロイ検証サポートは、Skaffold 2.0 で最近導入された verify コマンドに基づいています。アプリケーションの状態を検証するために、コンテナ内で実行される任意のプロセスを使用できます。たとえば、curl コマンドを発行するという簡単なものや、サードパーティーツールを使用してすべてのリンクを検証したり、パフォーマンス指標を集めたりするような複雑なものがあります。デプロイの検証は、デプロイ（「コマンド」）をテストするように Skaffold を構成し、Cloud Deploy デリバリーパイプラインの進行シーケンスに「verify: true」を指定するだけで簡単に実行できます。

レンダーやデプロイのオペレーションと同じように、Google Cloud Deploy のデプロイ検証は、独自の実行環境で行われます。これにより、指定されたワーカープールやサービスアカウントを使用したカスタム検証構成が可能になり、任意の Cloud Storage ロケーションに結果を保存できます。検証結果は、ロールアウトの成功や失敗を決定するときの要因となります。デプロイの検証が失敗したとき、ログを検査し、必要であれば再デプロイせずにデプロイ検証を再実行することは簡単です。

デプロイ検証は、Cloud Run を含むすべてのターゲットタイプで利用可能です。

ロールアウトの詳細におけるデプロイの検証状況と結果

今後の計画

包括的で使いやすく、費用対効果に優れた DevOps ツールは、効率的なソフトウェアデリバリー機能を構築するうえで重要な存在です。Google は、Google Cloud Deploy が完全な CI / CD パイプラインの実装を実現するうえで皆様のお役に立つことを願っています。この取り組みはまだ始まったばかりです。今後数か月にわたって Google Cloud Deploy に魅力的な機能を導入してまいりますので、引き続きご注目ください。

また、プロダクトページ、ドキュメント、クイックスタート、チュートリアルもご参照いただけます。最後に、こちらから Google Cloud Deploy に関するフィードバックをぜひお寄せください。皆様からのご意見やご感想をお待ちしております。

- プロダクトマネージャー S. Bogdan
- プロダクトマネージャー Justin Mahood

Google Cloud で Intel ベースのインスタンスを最大限に活用する方法

Tue, 04 Oct 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 9 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

ミッションクリティカルなアプリケーションを Google Cloud にデプロイすれば、パフォーマンスと総所有コスト（TCO）の面ですぐにメリットを得られます。Google Cloud が Intel とパートナーシップを組み、極めて要求の厳しいワークロードを Intel ベースのインスタンスに最適化できるように共通のお客様をサポートしているのはそのためです。Google Cloud に対応した Intel Software Center of Excellence（CoE）の試験運用が北米で昨年開始され、その結果は目覚ましいものでした。広告ランクアルゴリズム向けの TensorFlow 推論のパフォーマンスが向上し、高負荷時における Redis のスループットとレイテンシが改善され、動画を 1080p にコード変換する速度が上昇しました。

Intel と Google Cloud は現在、厳選した高成長企業アカウントにこのプログラムを開放することでグローバルに CoE を拡大しようとしています。

Intel Software Center of Excellence は、レイテンシの短縮とワークロードの効率性の向上を実現したいと考えているお客様にきめ細かいサポートを提供するプログラムです。このプログラムは、Google Cloud で実行される Intel Xeon スケーラブルプロセッサから得られる価値を高め、お客様にベンチマークとパフォーマンスの最適化手法を提供できるように設計されています。プログラムでは以下のサービスが提供されています。

Intel のエンジニアからのきめ細かなサービスの直接提供
Intel ベースの Google Cloud インスタンスのコストパフォーマンスと運用パフォーマンスを改善するためのガイダンス
Google Cloud への投資から可能な限り多くのメリットを享受できる、Intel プロセッサのコードレベルの推奨事項

極めて要求の厳しいワークロードのパフォーマンスの最適化

CoE プログラムに参加すれば、Intel のエンジニアと直接連携して Google Cloud の Intel インスタンスにおけるワークロードのパフォーマンスを最大化する機会が得られます。以下は、CoE の参加者がプログラムを通じてパフォーマンスを微調整し、より適切に管理できるワークロードの例です。

データベース: さまざまなリレーショナルデータベースと非リレーショナルデータベースを使用して、負荷のピーク時または複雑な条件下でのレイテンシの問題（e コマースアプリケーションにおける Redis の「レイテンシニー」など）に対処する方法を学習できます。
アナリティクス: Apache Spark の使用に関するガイダンスを入手できます。
AI 推論（推奨事項、自然言語処理、視覚認識など）: N2 / C2 インスタンスで Intel DL Boost を活用できます。Intel Math Kernel Library、Tensorflow の最適化も同様です。
安全なウェブトランザクション: 内蔵型の Intel 暗号命令により、NGINX や Wordpress などのアプリケーションのセキュリティ処理を高速化できます。
言語ランタイムライブラリ: Golang Crypto、Java、Python など。
メディア: 動画のコード変換、エンコード、デコード、および AVX-512 最適化やマルチスレッドを含むライブラリ最適化などの画像処理が含まれます。

「Intel Software CoE を活用した Intel、Google、Equifax のコラボレーションにより、Equifax の環境を最適化することに成功しました。約 2 倍のスループットを生み出すとともに、レイテンシの重要な指標を 50% 低減できました。CoE は、エンドカスタマー向けのパフォーマンス SLA を改善しながら、コストの最適化に関する当社の目標をクリアしています」と Equifax のプロダクト、データ、アナリティクス＆テクノロジー最高責任者である Bryson Koehler 氏は述べています。

仕組み

Intel Software Center of Excellence の取り組みは、次の 3 つのフェーズで実施されています。

フェーズ 1: 発見。Google Cloud と Intel のチームは、お客様と協力してパフォーマンス目標を確認し、コンピューティングの傾向に影響を与える可能性のある主要なプロジェクトと長期的な目標を特定します。
フェーズ 2: パフォーマンスレビュー。Intel のエンジニアは、お客様の指標と Intel の内部リソースを活用して、サービスフットプリント全体のリソース使用率をレビューします。
フェーズ 3: パフォーマンスレポート。この取り組みは、Intel チームがパフォーマンスレポートを提供することで総括されます。レポートには、最適化の詳細な推奨事項、アクションプラン、実装プラン、Google Cloud の Professional Services Organization（PSO）から受けられるサポートの推奨事項などが記載されています。これにより、Google Cloud サービスから最大の価値を引き出すための運用ガイダンスを手にすることができます。

参加申し込み

Intel Software CoE には、申請いただくことでご参加いただけます。申請の確認が完了し、承認されたら、サービスを料金なしでご利用いただけます。参加するには、オンライン申請に必要事項を記入してください。

- Google Cloud パートナーデマンドセンターキャンペーン担当シニアマーケティングマネージャー Anisha Nanda

- Google Cloud ISV スペシャリスト Jermell Robinson

重要なヒントと無料学習を活用した Google Cloud 認定試験準備をしましょう

Fri, 22 Jul 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 7 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud 認定資格を取得すると、転職市場における個人の認知度が向上し、組織内で有意義な変化や変革を推進する能力を実証できることが証明されています。

Google Cloud 認定資格保持者の 4 人に 1 人は職場でより大きな責任やリーダーシップを発揮し、Google Cloud 認定資格を持つユーザーの 87% が自分のクラウドスキルにより強い自信を感じている1。
IT 意思決定者の 75% が、組織の目標を達成し、スキルの差を埋めるために、技術的に優れた人材を必要としている2。
IT 部門の意思決定者の 94% が、認定を受けた従業員は認定取得にかかった費用を上回る付加価値をもたらすと回答している3。

無料の学習機会を活用して認定試験の準備をする

無料の学習機会は非常に有益ではないでしょうか。Google は Coursera と提携し、Google Cloud 認定資格の取得をサポートしています。

新規学習者は、Coursera にて選択した Google Cloud プロフェッショナル認定資格のプログラムに 1 か月無料でアクセスして、関連する Google Cloud 認定試験の受験対策ができます。データエンジニアリング、クラウドエンジニアリング、クラウドアーキテクチャ、セキュリティ、ネットワーキング、機械学習、DevOps、ビジネスプロフェッショナル向けの Cloud Digital Leader のプロフェッショナル認定資格から選択できます。

Google Cloud 認定資格を取得する

Google Cloud 認定資格取得のための支援として、2022 年 8 月 31 日までに Coursera のプロフェッショナル認定資格プログラムを修了すると、Google Cloud 認定試験の受験料割引バウチャーを獲得できます。

Coursera のページにアクセスし、今すぐ 1 か月間無料で学習を開始しましょう。

Google Cloud 認定試験準備のための重要なヒント

Google Cloud を実際に体験する
技術職の方は、Google Cloud プロジェクトを活用して、Google Cloud コンソールで実践経験を積むことをおすすめします。Coursera では 500 以上の Google Cloud プロジェクトが公開されており、実際の Google Cloud コンソールを利用した実践演習ができます。ダウンロードや構成は必要ありません。
試験ガイドを確認する
試験ガイドは、試験問題を作成するためのブループリントを提供し、試験勉強中の受験者にガイドを提供します。試験ガイドに書かれているすべてのトピックの質問に回答できるようにしておくことをおすすめしますが、試験ガイド内のすべてのトピックが出題されるわけではありません。
模擬試験を見る
各認定資格のページにある模擬試験を見て、試験問題の形式や出題される可能性のある内容の例に慣れることができます。

Coursera で 1 か月間無料で学習できる機会を利用して、認定資格取得の準備を今すぐ始めましょう。

Google Cloud 認定資格の価値について詳しくは、IT リーダーがチームの Google Cloud 認定資格取得を選ぶ理由をご覧ください。

^{1. Google Cloud、2020 年 Google Cloud 認定資格の影響度に関するレポート}

^{2. Skillsoft Global Knowledge、2021 年 IT Skills and Salary Report}

^{3. Skillsoft Global Knowledge、2021 年 IT Skills and Salary Report}

- Google Cloud クルデンシャルおよび認定資格担当責任者 Magda Jary

リリースパイプラインに割り当ての回帰検出を組み込む

Thu, 07 Jul 2022 08:00:00 +0000

※この投稿は米国時間 2022 年 6 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud では、組織が消費できるリソースの量を公平に保つ方法の一つとして、割り当てを使用しています。サービスのリソース消費量を制限することによって、企業はクラウド費用をより適切に管理できます。多くの場合、割り当てを API に関連付けてリソースにアクセスします。エンドポイントが処理可能な秒間クエリ数（QPS）は大量ですが、割り当てを使用することにより、1 人のユーザーやお客様が使用可能な容量を超えてリソースを独占することがないようにします。ここで重要になるのが公平性です。ユーザーやお客様ごとに設定できるスコープの上限を設け、その上限を増減できます。

リソースプロバイダ（今回の場合は Google Cloud）の視点からすると、割り当ての上限によって、公平性の問題に対処できているといえますが、リソースを使用するお客様には、その上限が守られていることを確認する方法が必要です。また同様に、不注意でこの上限を超えてしまわないようにすることも重要です。これは、自動化が進んでいる継続的インテグレーションと継続的デリバリー（CI / CD）環境では、特に重要なことです。CI / CD はプロダクトリリースの自動化に大きく依存していて、リリースされたプロダクトが常に安定していることを確認する必要があります。ここで、割り当て回帰の問題が発生します。

割り当て回帰とは何か、どのように発生するのか？

割り当て回帰とは、指定された割り当てが予定外に変更されることです。これにより、多くの場合リソースの消費容量が低下します。

会計事務所を例にとってみましょう。私はこの業界には友人がたくさんいますが、1 月から 4 月の繁忙期になると、彼らが私に付き合ってくれることは決してありません。一応は、それが口実です。繁忙期になると、桁外れに大量の取扱い件数を抱えますが、それ以外の時期は少なくなります。この取扱い件数が、実際に Google Cloud のリソース費用に即座に影響すると仮定してみましょう。取扱い件数の急増は、年間を通じて特定の時期にしか発生しないため、常に高い割り当てを維持する必要はないかもしれません。リソースは「従量制」モデルで支払われるため、費用的には賢明とは言えません。

会計事務所が社内にエンジニアリングチームを持ち、システムが目的どおりに機能しているかを確認する負荷テストを構築していれば、繁忙期前に負荷容量が増加することが予想できます。負荷テストがサービス環境とは別の環境で行われている場合（セキュリティやデータへの不要なアクセス許可を避けるためにそうすべきです）、割り当て回帰が発生するかもしれません。この例として、非本番環境の Google Cloud プロジェクト（例: your-project-name-nonprod）で負荷テストを行い、イメージをサービスプロジェクト（例: your-project-name-prod）にプロモートすることが挙げられます。

負荷テストに合格するためには、負荷テスト環境に十分対応できる割り当て量が必要です。しかし、サービス環境でその割り当てが付与されていないこともあり得ます。これは、管理者がサービス環境で、追加の割り当てをリクエストする必要があるプロセスを単に見落としたか、繁忙期の後にその割り当てが元に戻ったことに気づかなかったのが原因かもしれません。どちらにしても、環境間で割り当てに整合性を保つには人間の介入が必要になります。これを見過ごしてしまうと、この会計事務所は、負荷テストに合格して繁忙期を迎えることができても、サービス環境の割り当て不足によるシステム停止に陥る可能性があります。

従来のモニタリングではなぜ不十分なのか？

ここで思い浮かべるのが、「セキュリティのモニタリングとセキュリティガード」の議論です。このような矛盾を検出するモニタリングを行っても、アラートが無視されることや、アラートが遅れる場合があります。アラートは、この動作に関連する自動化がされていない場合に役立ちます。上記の例では、アラートだけで十分かもしれません。しかし、CI / CD の場合は、下位環境に十分な割り当てがあれば負荷テストに合格するため、依存関係に高い QPS を導入するデプロイメントが、下位環境からサービス環境にプロモートされる可能性があります。ここで問題なのは、現在、そのデプロイメントが自動的に本番環境に push され、アラートが発生し、サービスが停止される可能性が高いということです。

このようなシナリオに対処する最善の方法は、モニタリングしてアラートを出すだけでなく、そのような回帰的動作をサービス環境にプロモートしないための自動化された方法を取り入れることです。最も心配なのは、付与されたリソース量よりも多いリソース割り当てを必要とする新しいロジックが、自動的に本番環境にプロモートされることです。

なぜテストで既存の確認を行わないのでしょうか？ソフトウェアエンジニアリングの分野では、いくつかの種類のテスト（単体テスト、統合テスト、パフォーマンステスト、負荷テスト、スモークテストなど）が行われていますが、環境間の整合性を確保するような複雑な問題に対応できるテストはありません。テストの多くは、ユーザーと想定される動作に焦点を当てています。インフラストラクチャに特化した唯一のテストは負荷テストですが、割り当て回帰は必ずしも負荷テストの一部とは限りません。負荷テストは独自の環境で行われ、実際に実行されている環境には依存しないため、検出されないのです。

つまり、割り当て回帰テストは環境を意識する必要があります。負荷テストが行われる想定されるベースライン環境と、プロダクトがデプロイされる実際のサービス環境が必要になります。私は、その他多くの一連のテストに含まれる、環境を意識したテストを提案しています。

Google Cloud での割り当て回帰テスト

Google Cloud では、この機能を簡単に組み込むために利用できるサービスをすでに提供しています。これはむしろ、実行できるシステムアーキテクチャの実践といえます。

Service Consumer Management API では、独自の割り当て回帰テストを作成するために必要なツールを提供しています。例として、リスト API を介して返される ConsumerQuotaLimit リソースについて考えてみます。ここからは、以下のような環境設定を想定して説明します。

リソースプロバイダの非常にシンプルなデプロイパイプラインを示す図。

上の図は、デプロイパイプラインを簡略化したものです。

デベロッパーがリポジトリにコードを送信する
Cloud Build のビルドとデプロイのトリガーが起動する

テストを実行する
前提条件の手順を完了すると、デプロイメントのイメージが push される

イメージは各環境に push される（今回のケースでは、ビルドは開発環境に、以前の開発環境は本番環境に）
割り当ては、デプロイ時にエンドポイントに定義される
Cloud ロードバランサによってエンドユーザーがエンドポイントを利用可能になる

割り当て上限

このメンタルモデルを使用して、全体像の中で割り当てが果たす役割について詳しく見ていきましょう。たとえば、「FooService」というエンドポイントに対して以下のようなサービス定義があるとします。この例で重要なのは、サービス名、指標ラベルの値、割り当ての上限値です。

gRPC Cloud Endpoint Yaml のサンプル

code_block: <ListValue: [StructValue([('code', 'type: google.api.Service\r\nconfig_version: 3\r\nname: fooservice.endpoints.my-project-id.cloud.goog\r\ntitle: Foo Service gRPC Cloud Endpoints\r\napis:\r\n - name: com.foos.demo.proto.v1.FooService\r\nusage:\r\n rules:\r\n # ListFoos メソッドは、API キーがなくても呼び出し可能。\r\n - selector: com.foos.demo.proto.v1.FooService.ListFoos\r\n allow_unregistered_calls: true\r\n # GetFoo メソッドは、API キーがなくても呼び出し可能。\r\n - selector: com.foos.demo.proto.v1.FooService.GetFoo\r\n allow_unregistered_calls: true\r\n # UpdateFoo メソッドは、API キーがなくても呼び出し可能。\r\n - selector: com.foos.demo.proto.v1.FooService.UpdateFoo\r\n allow_unregistered_calls: true\r\nmetrics:\r\n - name: library.googleapis.com/read_calls\r\n display_name: "Read Quota"\r\n value_type: INT64\r\n metric_kind: DELTA\r\n - name: library.googleapis.com/write_calls\r\n display_name: "Write Quota"\r\n value_type: INT64\r\n metric_kind: DELTA\r\nquota:\r\n limits:\r\n - name: "apiReadQpmPerProject"\r\n metric: library.googleapis.com/read_calls\r\n unit: "1/min/{project}"\r\n values:\r\n STANDARD: 1\r\n - name: "apiWriteQpmPerProject"\r\n metric: library.googleapis.com/write_calls\r\n unit: "1/min/{project}"\r\n values:\r\n STANDARD: 1\r\n # デフォルトでは、すべての呼び出しが QPM に対して 1 対 1 の経費で計算される。\r\n # https://github.com/googleapis/googleapis/blob/master/google/api/quota.proto を参照\r\n metric_rules:\r\n - selector: "*"\r\n metric_costs:\r\n library.googleapis.com/read_calls: 1\r\n - selector: com.foos.demo.proto.v1.FooService.UpdateFoo\r\n metric_costs:\r\n library.googleapis.com/write_calls: 2'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fecc7d00>)])]>

今回の定義では、以下のことを確立しています。

サービス名: fooservice.endpoints.my-project-id.cloud.goog
指標ラベル: library.googleapis.com/read_calls
割り当て上限: 1

これらの要素を定義することで、サービスの読み取り呼び出しをちょうど 1 分につき 1 回に制限できるようになります。プロジェクト番号（例: 123456789）を指定し、コンシューマー割り当て指標サービスに呼び出しを発行して、サービス割り当てを表示できます。

コマンドと出力の例

code_block: <ListValue: [StructValue([('code', '$ alias gcurl=\'curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json"\'\r\n$ gcurl https://serviceconsumermanagement.googleapis.com/v1beta1/services/fooservice.endpoints.my-project-id.cloud.goog/projects/my-project-id/consumerQuotaMetrics'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fecc7cd0>)])]>

レスポンス例（省略あり）

code_block: <ListValue: [StructValue([('code', '{\r\n "metrics": [\r\n {\r\n "name": "services/fooservice.endpoints.my-project-id.cloud.goog/projects/123456789/consumerQuotaMetrics/library.googleapis.com%2Fread_calls",\r\n "displayName": "Read Quota",\r\n "consumerQuotaLimits": [\r\n {\r\n "name": "services/fooservice.endpoints.my-project-id.cloud.goog/projects/123456789/consumerQuotaMetrics/library.googleapis.com%2Fread_calls/limits/%2Fmin%2Fproject",\r\n "unit": "1/min/{project}",\r\n "metric": "library.googleapis.com/read_calls",\r\n "quotaBuckets": [\r\n {\r\n\t"effectiveLimit": "1",\r\n\t"defaultLimit": "1"\r\n }\r\n ]\r\n }\r\n ],\r\n "metric": "library.googleapis.com/read_calls"\r\n }\r\n …'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fecc7fd0>)])]>

上記のレスポンスにおいて、注意すべき最も重要なことは、特定のサービス指標に対する実質的な上限です。前述したように、この実質的な上限とは、顧客間の公平性を確立する際にリソースを消費するお客様に適用される上限のことです。

プロジェクトごとのリソースに対して割り当て定義の effectiveLimit を取得する方法を確立したので、割り当ての整合性に関するアサーションを次のように定義できます。

負荷テスト環境での割り当ての実質的な上限 <= サービス環境での割り当ての実質的な上限

このようなテストを行えば、Cloud Build などと統合し、テストに合格しなかった場合は、下位環境からサービス環境へのイメージのプロモートを阻止できます。これにより、新しいイメージからサービス環境に回帰的な動作が発生することによって起こるサービスの停止を防ぐことができます。

早期検出の重要性

割り当て回帰を検出したときにアラートを出し、本番環境へのイメージのプロモートを阻止するだけでは十分とはいえません。可能な限り早く検出を知らせることがベターです。もし、本番環境にプロモートさせるときにリソースが不足していた場合、今度は十分なリソースを時間内にラングリングするという問題に直面します。これは、常に希望するスケジュールで行えるとは限りません。なぜなら、リソースプロバイダが割り当ての増加を処理するために、リソースのスケールアップが必要な場合もあるからです。この作業は、必ずしも 1 日でできることではありません。たとえば、該当するサービスは Google Kubernetes Engine（GKE）でホストされているのか、自動スケーリングを使用したとしても、IP プールが不足した場合はどうするのか、などが影響します。クラウドインフラストラクチャの変更は、弾力性はありますが、少し時間がかかります。実稼働計画の一部は、スケーリングにかかる時間を考慮する必要があります。

要約すると、割り当て回帰テストは、Google Cloud に限らず、あらゆるクラウドサービスにおいて過負荷を処理し、ロードバランシングに対応するという全体のコンセプトにとって、追加するべき重要なコンポーネントです。需要の落ち込みや急増に伴うプロダクトの安定性を確保するうえで重要であり、これは多くの分野で必ず発生する問題です。もし、構成全体で割り当ての整合性を確保するために人間の介入に依存し続けるなら、整合性に欠けた場合、最終的にはサービスの停止を招くことになります。割り当ての操作について詳細は、こちらのドキュメントをご覧ください。

-シニアソフトウェアエンジニア Nethaneel Edwards

Cloud DNS のマネージドゾーン権限のご紹介

Tue, 21 Jun 2022 01:10:00 +0000

※この投稿は米国時間 2022 年 6 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud DNS チームは、マネージドゾーン権限のプレビュー版をリリースいたしました。Cloud DNS は Identity and Access Management（IAM）サービスと統合されているため、Cloud DNS リソースへのアクセスを制御し、不要なアクセスを防ぐことが可能になります。このリリースにより、分散 DevOps チームを抱える企業は、Cloud DNS マネージドゾーンの管理を個々のアプリケーションチームに委任できるようになります。

これまで、Cloud DNS はプロジェクトレベルでのみリソース権限に対応していました。そのため、IAM 権限の一元管理は粗い粒度でのみ可能でした。プロジェクトで特定の権限を持つユーザーは、その権限をその下のリソースすべてに対する権限も与えられていました。たとえばプロジェクトにマネージドゾーンが複数含まれている場合は、プロジェクトにアクセスできる 1 人のユーザーが、そのプロジェクト内のどのマネージドゾーンの DNS レコードでも変更できました。これにより、一部のお客様には 2 つの課題が生じました。

中央チームに、すべての DNS ゾーンとレコードの作成の管理を任せなければいけないこと。これはデプロイのサイズが小さい場合は、通常問題はありません。しかし、マネージド DNS ゾーンが多数あるお客様の場合、管理は中央チームにとって大きな負担となります。
1 人のユーザーが、複数のマネージドゾーンの DNS レコードを変更できるため、DNS レコードの破損や、セキュリティの問題が起きる可能性があること。

今回のリリースで、Cloud DNS は、マネージドゾーンレベルでより細かい粒度のアクセス制御が可能になりました。これにより、管理者はマネージドゾーンの運用の責任を個々のアプリケーションチームに委任でき、あるアプリケーションチームが別のアプリケーションの DNS レコードを誤って変更することを防げます。また、許可されたユーザーのみがマネージドゾーンを変更でき、最小権限の原則がより適切に守られるため、セキュリティ体制が向上します。このリリースにより IAM のロールと権限が変更されることはありません。必要に応じて追加の粒度を利用できるようになっただけです。Cloud DNS の IAM ロールの詳細については、IAM によるアクセス制御をご参照ください。

この機能は、お客様が共有 VPC 環境を使用している場合にも役立ちます。一般的な共有 VPC 設定では、サービスプロジェクトが仮想マシン（VM）アプリケーションまたはサービスの所有権を持っていますが、VPC ネットワークとネットワークインフラストラクチャの所有権はホストプロジェクトが持ちます。多くの場合、サービスプロジェクトのリソースと一致するように VPC ネットワークの名前空間から DNS 名前空間が作成されます。このような設定では、各サービスプロジェクトの DNS 名前空間の管理を各サービスプロジェクトの管理者（多くは別の部門または事業）に委任するほうが便利です。プロジェクト間のバインディングを使用すると、VPC ネットワーク全体の DNS 名前空間の所有権から、サービスプロジェクトの DNS 名前空間の所有権を分離できます。これとマネージドゾーン権限を組み合わせることで、ホストプロジェクト（およびその他のサービスプロジェクト）がそれぞれのプロジェクトから名前空間にアクセスできるようにしつつ、サービスプロジェクト内のマネージドゾーンは、サービスプロジェクトの所有者のみが管理できるようになります。

マネージドゾーン権限を構成および使用する方法の詳細については、ドキュメントをご覧ください。

- Cloud DNS プロダクトマネージャー Karthik Balakrishnan

Snap Inc.、ディープラーニングのレコメンデーションモデルに Google Cloud TPU を採用

Tue, 07 Jun 2022 01:10:00 +0000

※この投稿は米国時間 2022 年 6 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

ディープラーニングというと、学術的な研究をイメージする人がまだ多いと思います。しかし、Snap は、ディープラーニングモデルを応用して、日々レコメンデーションエンジンの改良を行っています。Snap は、Google の Cloud Tensor Processing Units（TPU）を活用し、イノベーションとモデル改良のペースを加速させてユーザーエクスペリエンスの強化につなげています。

Snap のブログ: TPU による大規模なレコメンデーションモデルのトレーニングは、Snap の広告ランキングチームが、Google の最先端の TPU を活用して、ディープラーニングモデルを迅速かつ効率的にトレーニングした方法を紹介しています。この投稿では、Snap のブログで書かれた方法だけでなく、もっと多くのことをお伝えしたいと思います。

より速く、より良いものを提供する

Snap の広告ランキングチームは、「適切な広告を適切な Snapchatter に適切なタイミングで配信する」モデルをトレーニングする役割を担っています。毎日 3 億人以上のユーザーと何百万もの広告をランク付けするので、Snap ML エンジニアは、毎日多くの時間を迅速かつ効率的にモデルをトレーニングすることに注力しています。より多くのモデルを学習させればさせるほど、より良いモデルを見つけることができ、そのためのコストも削減できます。より良い広告レコメンデーションモデルは、ユーザーにとってより適切な広告となり、広告主にとってはエンゲージメントの向上とコンバージョン率の改善につながります。

Snap が広告ランキングに使用しているような大規模な ML モデルを学習するためのハードウェアアクセラレータは、この 10 年間で汎用のマルチコア中央演算処理装置（CPU）からグラフィック処理装置（GPU）、TPU へと飛躍的な進化を遂げました。

TPU は、Google がカスタム開発した ASIC（特定用途向け集積回路）で、ML ワークロードを高速化するために使用されます。TPU は、大規模なモデルを学習する際に、精度を上げるまでの時間を最小にするために、ゼロから設計されています。以前、他のハードウェアプラットフォームでトレーニングに数週間かかっていたモデルが、TPU では数時間で学習できるようになりました。これは、機械学習における Google のリーダーシップと経験の賜物です（Snap のブログで、この技術について詳しく説明しています）。

成功のベンチマーク

Snap は、TPU を使うことで学習速度がどのように向上するのか把握したいと考えていました。Snap チームが TPU を使ったモデル学習のベンチマークを、GPU、CPU と比較したところ、すばらしい結果が得られました。GPU はスループットとコストの両面で TPU を下回り、スループットは 67% の低下、コストは 52% の上昇となりました。同様に、Snap の最も一般的なモデルでは、TPU ベースの学習が CPU ベースの学習を大幅に上回りました。たとえば、標準的な広告レコメンデーションモデルで比べると、TPU は処理コストを 74% も削減しながら、スループットを 250% も向上させ、しかも同じレベルの精度を保っています。

TPU 埋め込み API は埋め込みベースの演算のためのネイティブかつ最適化されたソリューションです。そのため、埋め込みの演算やルックアップをより効率的に実行できます。これは、高速な埋め込み検索や高いメモリ帯域幅などの追加要件を持つ Recommender にとって、特に価値のあるものです。

全体的なメリット

Snap の広告ランキングチームにとって、これらの改善は具体的なワークフローの利点となります。Snap では、特定の広告を表示したユーザーのログや、広告とインタラクションしたかどうかの記録をすべて含む 1 か月分のデータを保有することも珍しくありません。何百、何千万ものデータを処理する必要があるため、Snap はデータをできるだけ早くモデル化し、今後より良い提案をできるようにしたいと考えています。Snap のエンジニアは、1 つの実験の結果をより早く得ることができれば、より良い結果を得るために別の実験をより早く立ち上げることができます。

効率と速度の向上は、Snapchat ユーザーにもメリットがあります。モデルが優れていればいるほど、ユーザーが特定の広告にインタラクションする可能性を正しく予測できるようにななるので、ユーザーエクスペリエンスを強化し、エンゲージメントを高めることができます。エンゲージメントの向上は、コンバージョン率の向上や広告主の価値向上につながります。Snap が扱う広告やユーザーのボリュームを考えると、1% でも改善されると、実質的に経済的な影響が発生します。

最先端での仕事

Snap は、広告主にはより大きな価値を、Snapchat ユーザーにはより良い体験を提供することを目標に、レコメンデーションの品質の向上に努めています。その中には、Google TPU のような、才能ある ML エンジニアを輝かせる最先端のソリューションに全面的に取り組むことも含まれています。

全容がわかったところで、Snap が Google の力を借りて実現したことを、私たちのブログ、TPU による大規模なレコメンデーションモデルの学習でご覧ください。

- Snap Inc.、機械学習エンジニア、Aymeric Damien
- Snap Inc.、ソフトウェアエンジニア、Samir Ahmed

クラウドネイティブアプリの新機能

Wed, 27 Apr 2022 03:00:00 +0000

※この投稿は米国時間 2022 年 4 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

あらゆるタイプのデベロッパーや IT オペレーションのプロが、クラウドファーストでクラウドネイティブの最新アプリケーションの構築に Google Cloud を活用しています。ここでは、アプリ開発、コンテナ、Kubernetes、DevOps、サーバーレスおよびオープンソースといった Google Cloud に関するすべての最新情報をお伝えします。

2022 年 4 月 11 日～15 日の週

Prodcast を聴く

Google の SRE チームは、SRE ブックのコンセプトに焦点を当てた「Prodcast」をリリースしました。ポッドキャストを入手できる場所ならどこからでもお聴きいただけます。

最新のコンテナベースで Apache Spark を実行

Google Kubernetes Engine（GKE）で、Apache Spark のマネージドバージョンである Dataproc の一般提供が開始されました。これにより、セルフマネージド GKE クラスタで Dataproc クラスタを作成して Spark ジョブを送信できるようになります。詳細は、こちらをお読みください。

App Engine と Cloud Functions に数々の新しいランタイムが登場

Java、Ruby、Python、PHP のデベロッパーの皆様に朗報です。Java 17、Ruby 3、Python 3.10、PHP 8.1 を使用して、App Engine と Cloud Functions でアプリの更新や新しいアプリの開発を行えるようになりました。

BeReal が最新のアプリ開発の方法を紹介

ソーシャルメディア企業の BeReal が、Firebase、Cloud Functions、GKE などの Google Cloud サービスを使用してアプリを構築する方法について説明しています。

中断せずに迅速に構築

この全 3 回シリーズでは、ソフトウェアパッケージとインフラストラクチャの整合性を向上させるために設計されたソフトウェアアーティファクトのためのサプライチェーンレベル（SLSA）フレームワークについて学習します。How to SLSA Part 1 - The Basics（ハウツー SLSA パート 1 - 基礎）から開始し、パート 2、パート 3 と続きます。

2022 年 4 月 4 日～8 日の週

コンテナを VM から Cloud Run に移行する方法

Cloud Run を使用すると、Kubernetes を知らなくても、レガシー VM をコンテナに移行して費用を節約できます。その方法をこちらの動画で説明しています。

Slack と Webhook を使用して Error Reporting の通知を受信する

Error Reporting では、お客様の好みのチャネルに合わせて、クラウドサービスで発生した障害の分析、集計、DevOps チームへの通知の受信を行うことができます。詳しくは、こちらのブログをご覧ください。

NCR、カードにクラウドネイティブのアーキテクチャを導入する

今年の初め、NCR Authentic Cards は Google Cloud 上にトランザクション処理プラットフォームを構築する方法について説明しました。NCR とそのコンサルティングパートナーである Opus Systems は、クラウドベースのアーキテクチャへのすべてのコンポーネントの導入について、移行ストーリーのパート 2 で詳しく説明しています。

Cloud Run でサービスを簡単に共有する方法

他の人に使ってもらうためのスクリプトを書いたことはありますか？Cloud Run なら、処理サービスをすばやく簡単にデプロイしやすくなります。このブログ投稿では、デベロッパーアドボケイトの Laurent Picard が、塗り絵を生成する画像処理サービスを作成し、他のユーザーが利用できるようにしています。コードは 200 行足らずで Python と JavaScript で書かれています。こちらのチュートリアルをご覧ください。

2022 年 3 月 28 日～4 月 1 日の週

Cloud Functions でできること

Cloud Storage から BigQuery に取り込みたいデータをお持ちですか？Cloud Functions がお手伝いします。このチュートリアルではその方法について学びます。

Cloud Monitoring アラートポリシーにカスタム重大度レベルを追加する

すべてのアラートが同じように作られているわけではありません。このブログ投稿では、メール、Webhooks、Cloud Pub/Sub、PagerDuty などの拡張通知チャンネルを使用して、静的または動的重大度レベルを Cloud Monitoring アラートポリシーに追加する方法を学びます。

Cloud Run で CPU 割り当てコントロールを使用する方法を学ぶ

昨年秋、「always-on CPU」の機能を Cloud Run に追加しました。これにより、Cloud Run はバックグラウンドや他の非同期処理タスクの実行により適したものになりました。この投稿では、デベロッパーアドボケイトの Wesley Chun が天気情報アプリを使用してこの機能の使い方を説明し、その中でアプリのレスポンスレイテンシの平均を 80% 以上短縮していることを紹介しています。

2022 年 3 月 21 日～25 日の週

最新の Go 1.18 リリースを使用する

バージョン 1.18 のリリースにより、Go プログラミング言語に、パラメータ化された型を使用した汎用コードのサポート、統合ファズテスト、および複数のモジュールを簡単に操作できる新しい Go ワークスペースモードが追加されました。詳しくはこちらをご覧ください。

2022 年 3 月 14 日～18 日の週

Terraform による EventArc トリガーの作成

Google Cloud Console や gcloud 以外に、Terraform リソースを使用して Eventarc トリガーを作成することもできます。Mete Atamel がその方法を解説します。

Cloud Run を活用した新たな市場への拡大

フランスの出版社 Les Echos Le Parisien Annonces は、同社のメインのニュースサイトを各地域版で補完する際に、オンプレミスの専用インフラストラクチャから Cloud Run に切り替えました。Les Echos のウェブサイトアーキテクチャはこちらで共有されています。

「円周率の日」をサーバーレスで祝う方法

「円周率の日」を記念して、Google Cloud のデベロッパーアドボケイトである Emma Haruka Iwao が、新しい Cloud Functions（第 2 世代）を活用してサーバーを使わずに π を計算する方法を解説します。

2022 年 3 月 7 日～11 日の週

ロードアイランド州、Google Cloud ベースの求人掲示板へ移行

パンデミックの発生を受けて、ロードアイランド州は同州の人材開発業務を完全にオンラインへ移行しましたが、その基盤となったのが、Google Workspace と、Firestore や Cloud Functions、Kubernetes などの Google Cloud のリソースでした。その過程をぜひご確認ください。

Lowe’s におけるマイクロサービスのコンテナ化

Lowe's がどのように SRE を活用しているかについては、以前紹介させていただきました。今回同社に再びコンテナ化されたマイクロサービスアーキテクチャと Kubernetes、その他サービスメッシュ用の Istio と Cloud Operations を活用して e コマースウェブサイトをどのように構築したかを解説していただきます。

Cruise の AV、Google Cloud のサービスを搭載して走行

自律走行車（AV）のスタートアップである Cruise に、Google Kubernetes Engine（GKE）などのサービスを基盤とするデータアナリティクスや機械学習を活用し、自動運転車の開発とテストを行っている方法をお聞きしました。こちらで同社によるブログ投稿をお読みください。

サーバーレスで生まれ変わる L’Oréal のデータアナリティクス

当社が目指しているのはプログラム可能なクラウド、すなわちデベロッパーが Cloud Functions のようなクラウドネイティブのサーバーレスツールを活用して、データドリブン型の強力なビジネスインサイトを短時間でプロトタイピングし、構築できる世界です。L’Oréal はその好例です。

Anthos クラスタのためのテレメトリーの改善

Anthos Service Mesh ダッシュボードは現在、ベアメタル版 Anthos クラスタと Anthos clusters on VMware で利用可能（公開プレビュー中）です。Cloud Console 上で、アプリケーションをサービスから優先的に表示できるテレメトリーダッシュボードをすぐに利用できるようになりました。

Java アプリの計測

新バージョンの Google Cloud Logging の Java ライブラリを使用すれば、コードを追加しなくても、アプリケーションのログにより多くの情報をつなげることができます。

Cloud Spanner の指標を可視化

Cloud Spanner をベースにアプリを構築しても、そのアプリの性能を評価できないことがあります。新しい Cloud Spanner の OpenTelemetery レシーバーでは、Cloud Spanner のシステムテーブルから取得した指標を処理して可視化し、それを任意の APM ツールにエクスポートするのも簡単です。詳しくはこちらをご覧ください。

2022 年 2 月 28 日～3 月 4 日の週

Cloud SDK の概要

リブランディングを行った Cloud SDK は、Google Cloud のプロダクトとサービスを操作するために必要なライブラリやツール（Google Cloud CLI を含む）がすべて入ったコレクションです。詳しくはこちらをご覧ください。

Cloud CLI と Terraform の出会い

Google Cloud CLI の新しい Terraform 用宣言型エクスポートを使用すると、Google Cloud インフラストラクチャの現在の状態を、Terraform（HCL）や Google の KRM 宣言型ツールと互換性のある記述ファイルにエクスポートできます。この宣言型エクスポートはプレビュー版で提供中です。

Knative、インキュベーションプロジェクトとして承認

このたび、Knative は Cloud Native Computing Foundation（CNCF）によってインキュベーションプロジェクトとして承認され、サーバーレスアーキテクチャの新たなフェーズへと進むことになりました。

Prometheus は当社が全面的に管理

Google Cloud Managed Service for Prometheus の一般提供を開始しました。オープンソース互換モニタリングのすべての利点と、Google 規模のマネージドサービスの使いやすさを享受できます。詳しくはこちらをご覧ください。

- Google Cloud コンテンツおよび編集担当編集長

データファーストのデジタル化でメインフレームデータを解放する

Thu, 03 Mar 2022 02:00:00 +0000

※この投稿は米国時間 2022 年 2 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

多くの企業にとって、長年使用されてきたメインフレームには、企業の顧客、プロセス、運用に関する数十年分のデータが蓄積されています。そのため、ビジネスでメインフレームのデータにアクセスして、レポートの作成やビッグデータ分析ツールでの分析を行ったり、機械学習や人工知能の新たな取り組みの基礎として使用したりしたいと考えるのは当然のことです。

Google Cloud は、クラウドの時代に向けて企業のメインフレーム資産の変革を支援するために、企業と連携していきたいと考えています。メインフレームアプリケーションをクラウドに移行して、モダナイズするためのサポートを提供するのは言うまでもありませんが、これに加え、パートナー様やお客様の協力を得て、より軽量な別のアプローチを開発しました。これにより、本格的な移行を行うよりもはるかに短い時間で、メインフレーム資産をクラウドで活用し始めることができます。私たちはこのアプローチを、データファーストのデジタル化と呼んでいます。

急速な進化を遂げるデジタルエコシステムでは、「モダナイゼーション」と「デジタル化」の違いを理解することが肝要です。モダナイゼーションでは、現在の状態を起点として将来を見据え、再ホスト（エミュレーション）、リファクタリング（自動コード変換）、再エンジニアリングなどのメインフレームアプリケーションの移行アプローチを採用したり、カスタムアプリケーションを商用のソリューションパッケージで置き換えたりします。デジタル化では、実現したい将来の状態を起点として、そこに到達するために必要なことを逆算します。

クリックして拡大

このデータファーストのデジタル化アプローチには、メインフレームデータファースト統合フレームワークが含まれており、メインフレームから Google Cloud Storage へ異種のデータソースを移行するための自社製品、パートナー様のプロダクト、ツールで構成されています。メインフレームのデータが Cloud Storage にコピーされると、BigQuery、AI と機械学習プロダクト、スマートおよびストリーム分析プラットフォームなどの Google Cloud ツールで統合したり、活用したりできるようになります。この統合フレームワークは、バッチでの一括データ転送とリアルタイムのデータレプリケーション（変更データキャプチャ）の両方に対応しています。

クリックして拡大

データファーストのデジタル化は、「アプリケーションは一時的なものであり、データは永続的なものである」という原則に基づいています。従来のアプリケーションのモダナイゼーションの方法（例: Gartner のモダナイゼーションの 7 つのオプション）ではなく、Google Cloud にデータファーストを取り入れることで、組織は新しいビジネスモデル、ユースケース、エンドカスタマーへの革新的なサービス提供を飛躍的に進歩させることができます。次に例を示します。

スマートおよびストリーム分析プラットフォーム、AI / ML エンジンを使用した意思決定。これらのツールには、意思決定を行うためのデータが必要です。Google は、構造化 / 非構造化された元のデータから情報と価値を抽出するパイオニアであり、このアプローチにより、メインフレームのデータを BigQuery や AI / ML モデルで使用できるようになります。
新しいレポート作成アプリケーションの構築。メインフレームのデータにアクセスし、Looker や AppSheet などの Google Cloud プロダクトを使用して新しいレポート作成アプリケーションを構築できるため、メインフレームのレポート作成アプリケーションを廃止するプロセスを促進し、変革全体を加速することができます。

これまでの経験上、メインフレームに対するデータファーストのデジタル化のアプローチには、以下のような多くのメリットがあります。

ビジネスへの迅速な対応: データファーストのモダナイゼーションは既存のプロダクトを基盤として構築されるため、実装サイクルを大幅に短縮できます。
設備投資の削減: アプリケーションの開発ではなく、プロダクトの統合に時間を費やせます。
リスクの最小化: 実績と信頼性に優れた既存の Google Cloud プロダクトとのデータファーストの統合を実現します。
メインフレーム全体の移行を高速化: モダナイゼーションの中心をアプリケーションからデータに変えることで、メインフレームアプリケーションを単に「稼働し続ける」ものとしてではなく、ビジネスの観点から見ることができます。その結果、最もビジネスクリティカルなアプリケーションのみをモダナイズし、補助的なアプリケーションを廃止できるため、移行の取り組みを加速させることができます。

デジタル化へのデータファーストのアプローチは、まだ比較的新しい取り組みになりますが、お客様が早い段階で成功を収めていることに感銘を受けています。今後も、データファーストに関する新たなインサイト、リファレンスアーキテクチャ、テクニカルホワイトペーパーなどを紹介していく予定です。今回取り上げたアプローチにご興味がありましたら、mainframe@google.com までご連絡ください。

詳細:

- メインフレームソリューションスペシャリスト Aman Gupta

Google Cloud Logging Python v3.0.0 スタートガイド

Mon, 21 Feb 2022 02:00:00 +0000

※この投稿は米国時間 2022 年 2 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、Google Cloud Python Logging ライブラリのメジャーアップデートをリリースしましたのでお知らせいたします。

v3.0.0 では、Python のデベロッパーは Google Cloud からさらに簡単にログを送受信でき、アプリケーションの状況をリアルタイムに把握できるようになりました。 Google Cloud を使用している Python デベロッパーの皆さんは、この機会にぜひ Cloud Logging をお試しください。

「google-cloud-logging」ライブラリに馴染みのない方でも、簡単に始められます。まず、pip を使ってライブラリをダウンロードします。

code_block: <ListValue: [StructValue([('code', '$ pip install "google-cloud-logging>=3.0.0"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fece6e80>)])]>

ここで、Python の組み込み「logging」ライブラリと連動するようにクライアントライブラリを設定します。これにより、すべての標準 Python ログステートメントが Google Cloud にデータを送るようになります。

code_block: <ListValue: [StructValue([('code', '# Google Cloud Logging python クライアントライブラリを設定\r\nimport google.cloud.logging\r\nclient = google.cloud.logging.Client()\r\nclient.setup_logging()\r\n\r\n# Python\' の標準 Logging ライブラリを使用して GCP にログを送信\r\n\r\nimport logging\r\nlogging.warning("Hello World")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fece6ee0>)])]>

上記で示されているように、ログの作成にはPython の標準「logging」インターフェースを使用することをおすすめします。ただし、他の Google Cloud Logging の機能（ログの読み込み、ログシンクの管理など）にアクセスする必要がある場合には、直接「google.cloud.logging」を使用できます。:

code_block: <ListValue: [StructValue([('code', 'import google.cloud.logging\r\n\r\nclient = google.cloud.logging.Client()\r\nlogger = client.logger(name="log_id")\r\n\r\nclient.list_entries(max_size=5) # read logs from GCP\r\nlogger.log("hello world", resource={"type":"global", "labels":{}}) # write log to GCP'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fece6f40>)])]>

今回のリリースで追加された主な機能をご紹介します。

より多くのクラウド環境をサポート

google-cloud-logging の以前のバージョンでは、 App Engine と Kubernetes Engine のみがサポートされていました。Cloud Run や Cloud Functions といったサーバーレス環境では、しばしばライブラリでログがドロップする現象が発生するとの報告がユーザーから寄せられていました。これは、ライブラリがネットワーク上でログを一括で送信していたためでした。サーバーレス環境がスピンダウンすると、未送信のバッチが失われる恐れがあったのです。

v3.0.0 では、サポートされる環境（GKE、Cloud Run、Cloud Functions）で GCP に組み込まれた構造化 JSON Logging 機能を使って、この問題を修正しています。構造化ログをサポートしている環境でライブラリが実行されていることを検出すると、新しい StructuredLogHandler が自動的に使用されます。この StructuredLogHandler は、標準出力に出力された JSON 文字列としてログを書き込みます。Google Cloud の組み込みエージェントは、ログを生成したコードがスピンダウンした場合でも、ログを解析し、Cloud Logging に配信します。

構造化ロギングはサーバーレス環境での信頼性がさらに高く、v3.0.0 では主要な GCP のコンピューティング環境をすべてサポートしています。従来通りネットワーク上でログを送信したい場合、CloudLoggingHandler インスタンスで手動でライブラリを設定できます。

code_block: <ListValue: [StructValue([('code', 'from google.cloud.logging.handlers import CloudLoggingHandler\r\nfrom google.cloud.logging_v2.handlers import setup_logging\r\n\r\n# ネットワーク経由でログを送信する CloudLoggingHandler を明示的に設定\r\nhandler = CloudLoggingHandler(client)\r\nsetup_logging(handler)\r\n\r\nimport logging\r\nlogging.warning(“Hello World”)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fece6fa0>)])]>

メタデータの自動検出

アプリケーションのトラブルシューティングを行う際には、できるだけ多くの環境に関する情報をアプリケーションのログに記録しておくと便利です。「google-cloud-logging」は、環境に関するメタデータを検出して各ログメッセージに添付することにより、このプロセスの支援を試みます。次のフィールドが現在サポートされています。

「リソース」: ログの生成元である Google Cloud リソース

例: Functions、GKE、Cloud Run など

「httpRequest」: ログのコンテキストに含まれる HTTP リクエストの情報

Flask と Django が現在サポートされています。

「sourceLocation」: ファイル名、行名、関数名
trace、spanId、traceSampled: Cloud Trace のメタデータ

X-Cloud-Trace-Context と w3c transparent のトレースフォーマットがサポートされています。

ライブラリは、可能な限りこうしたデータの入力を試みますが、これらの項目は、ライブラリを使用するデベロッパーが明示的に設定することもできます。

code_block: <ListValue: [StructValue([('code', 'logging.info("hello", extra={\r\n "labels": {"foo": "bar"},\r\n "http_request": {"requestUrl": "localhost"},\r\n "trace": "01234"\r\n})'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fece9040>)])]>

標準ライブラリのインテグレーションにおける JSON サポート

Google Cloud Logging は、 LogEntries の文字列と JSON ペイロードの両方をサポートしていますが、これまで Python 標準ライブラリのインテグレーションでは文字数のペイロードでしかログを送信できませんでした。

「google-cloud-logging」の v3 では、 JSON データのログの方法には次の 2 つがあります。

1. JSON で解析可能な文字列を記録します。

code_block: <ListValue: [StructValue([('code', 'import logging\r\nimport json\r\n\r\ndata_dict = {"hello": "world"}\r\nlogging.info(json.dumps(data_dict))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fece90a0>)])]>

2. Python Logging の「extra」引数を使って「json_fields」ディクショナリを渡します。

code_block: <ListValue: [StructValue([('code', 'import logging\r\n\r\ndata_dict = {"hello": "world"}\r\nlogging.info("message field", extra={"json_fields": data_dict})'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61fece9100>)])]>

次のステップ

v3.0.0 のバージョンでは、Google Cloud Logging Python ライブラリはさらに多くのコンピューティング環境をサポートしています。また、より有用なメタデータを検出し、JSON ログのさらに綿密なサポートも提供します。こうした主要な機能に加え、新しいログメソッドやさらに多くの制約なしの引数解析など、ユーザーエクスペリエンスの向上も実現しました。

今回のリリースについての詳細は、v3.0.0 移行ガイドをご覧ください。変更点などについて詳しく説明しています。ライブラリについて馴染みのない方には、google-cloud-logging ユーザーガイドもご用意しています。一般的な GCP でのオブザーバビリティについて知りたい場合は、Cloud Ops Sandbox を使って、テスト環境をスピンアップできます。

最後に、今回のリリースのご感想や新機能のリクエストなどの投稿をいただける場合は、Google の GitHub リポジトリで issue を開いてください。Google Cloud Logging ライブラリはオープンソースソフトウェアです。新しい投稿者をお待ちしています。

- デベロッパープログラムエンジニア、Daniel Sanche

2022 年以降に向けてクラウド FinOps の影響を測定するための 5 つの主な指標

Fri, 17 Dec 2021 05:00:00 +0000

※この投稿は米国時間 2021 年 12 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

指標のベースラインを確立することによるメリット

組織がクラウドへの投資を進めてビジネスの成長と収益向上を推進するなか、ビジネスで高い成果を上げる取り組みに注力することがビジネス、財務、テクノロジーを担当する経営幹部たちに求められるようになってきています。ビジネス機能とテクノロジー機能への投資がもたらす価値を数値化することが、これまで以上に経営幹部には求められているのです。こうした現状を受け、ビジネスと IT のリーダーたちは、業務と戦略の成果だけでなく、リスクと機会に関する一連の価値指標を必要としています。しかし多くの場合、IT 運用に関する指標とビジネスの成果は連動していません。つまり、経営幹部はテクノロジーとビジネスの成果を結び付けて、IT リーダーとビジネスリーダーが有意義な会話を交わせるよう取り持つ必要があります。

多くの IT 関連業務同様、一般的に指標と KPI の測定は長期にわたる取り組みとなります。組織では通常、クラウドコストに重点を置いた単位指標からこの取り組みに着手し、明確に定義されたビジネス価値指標へと発展させていきます。

Google Cloud では、クラウド FinOps を構成する 5 つの主な構成要素に関して指標を定義しています。これには、アカウンタビリティとイネーブルメント、測定と実現、コスト最適化、計画と予測、ツールとアクセラレータが含まれます。これらの指標を容易に測定し、デジタルトランスフォーメーションジャーニーを実施している組織で誰もが指標を取得できるよう Google Cloud では取り組んでいます。

アカウンタビリティとイネーブルメントに関する指標

アカウンタビリティとイネーブルメントは、コストと価値を意識する文化を形成するうえで欠かせない要素であり、クラウド FinOps でプロセスと文化に変革を起こす取り組みにおいて指針となるものです。この指標の主な目標は、IT の財務プロセスを合理化し、スムーズなクラウドガバナンスを実現することで、財務アカウンタビリティを向上させ、ビジネス価値の実現を推進することです。イネーブルメントでは、クラウドのリソースと戦略を効率的にデプロイ、管理できるよう、理解度を高めるトレーニングを IT、財務、ビジネスの各チームに提供します。アカウンタビリティとイネーブルメントを向上させるには、ビジョン、そして柱となるガバナンスポリシーを策定したうえで、財務、IT ビジネスの各オーナーを巻き込んでプロセスの変革を進めます。

アカウンタビリティとイネーブルメントの標準的な指標として、クラウドイネーブルメント率を導入することをおすすめします。この指標は、組織内のビジネスリーダーの合計人数のうち、トレーニングと認定を受けたビジネスリーダーの割合で表されます。

理解度とトレーニングが不足していることが原因で、多くの組織がクラウド FinOps の導入に失敗しているため、これは見逃すことのできない指標です。クラウドの価値、そして持続可能なビジネス成果の推進においてクラウドが果たす役割をビジネスリーダーが深く理解するうえでこのクラウドイネーブルメント指標が役立ちます。

組織内で特定したビジネスリーダーの人数に基づく一連の目標を通じて、クラウドイネーブルメント指標を簡単に導入できます。この場合、上位 20% が全体の 80% を左右するというパレートの法則を利用し、クラウドのサービスを多用している主なビジネスリーダーを特定することが重要になります。Google Cloud では先日、ビジネスリーダーと経営幹部を対象とした、新たな Cloud Digital Leader 認定資格を発表しました。Cloud Digital Leader　認定資格を取得することで、クラウドの基本的なコンセプトについて精通していることを証明できるだけでなく、さまざまな場面でクラウドコンピューティングの知識を幅広く応用し、Google Cloud のサービスがビジネス目標の達成において果たす役割を説明できるようになります。また、FinOps Foundation では、クラウド、財務、テクノロジーの各部門の担当者が FinOps の知識を確認し、プロとしての信頼を高められるトレーニングと認定プログラムを提供しています。

Cloud Digital Leader　認定資格をビジネスリーダーの 70% 以上が獲得することで、組織全体でクラウド FinOps の連携と導入が大幅に推進され、クラウドテクノロジーを活用して持続可能なビジネス成果を策定できるようになります。

測定と実現に関する指標

優れたプロセスに欠かせないのが正確なデータと効果的な指標です。まず、クラウドコストを把握、追跡する必要があります。それを支えるのが適切なリソース階層とプロジェクト構造の標準です。また、組織におけるクラウドリソースの使用状況を明らかにする、ラベル付けおよびタグ付けデータアーキテクチャも威力を発揮します。アプリケーションや環境、プロジェクトなど、IT を中心とした指定子がタグとして使用されることが多いものの、コストセンターか勘定科目表をタグとして含めることで、損益をラベル付けおよびタグ付けアーキテクチャと直接連動させることが重要です。また、タグ付けを自動化することで、一貫性と精度が高いラベルですべてのタグ付け可能リソースをデプロイし、FinOps 指標に信頼性の高いデータを反映できるようになります。

関連する事業部門と損益ごとに、特定のプロダクトやプロジェクトだけでなく、詳細なコストセンターにクラウドリソースを割り当てることが、一貫性のあるきめ細かいタグ付けを実現するうえで非常に重要です。典型的なクラウドサービスの全額チャージバックを受けるためには、3 つのタイプのクラウドリソースにコストを割り当てる必要があります。 1 つ目にして最もシンプルなのが、あるアプリケーションを利用した事業部門が 1 つだけの場合などに、特定の損益に連動させる形でタグ付け可能リソース（コンピューティングインスタンス、データベース、ストレージバケット）を割り当てることです。

2 つ目が、複数の事業部門で同じタグ付け可能リソースを使用する場合です。関連する事業部門の収益または従業員数を使用してコストを割り当てるといった、従来型の損益割り当てモデルに落ち着くお客様も多く出てくるでしょう。共有アプリケーションのコストをより正確に割り当てるために、他社の一歩先を行くお客様は API 呼び出しなどの要素をクラウドマイクロサービスアーキテクチャで使用することで、共有アプリケーションの相対的な使用状況を厳密に測定しています。

3 つ目は、タグ付けできないクラウドリソースです。一般的には、サポートやネットワーキングに関連するコスト、サードパーティマーケットプレイスのコストなどがこれに含まれます。このクラウドリソースの場合、さきほど紹介した（従業員数か収益を使用する）従来型の損益割り当てモデルがよく使用されます。タグ付け可能リソース割り当ての相対的な配分を使用して対応するタグ付け不可コストを事業部門に割り当てながら、ネットワーキングなど、一部のタイプのコストを API 呼び出しに基づいて割り当てるお客様も出てくるでしょう。

これら 3 つのタイプのクラウドリソースでクラウド FinOps の測定と実現の有効性を測定するには、クラウド割り当て率をメインの指標として採用することをおすすめします。担当ビジネスオーナーに割り当てられた総クラウドコスト（各事業部門が利用したタグ付け可能リソース、複数の事業部門で共有されたタグ付け可能リソース、タグ付け不可リソース）の割合としてこの指標を測定します。

この指標はショーバックモデル（クラウドコストは中央の IT 損益に計上されるが、報告は事業部門に行われる）とチャージバックモデル（クラウドコスト全額が事業部門の損益に計上される）に対応できます。また、リソースのタグ付けの基本的な効果と精度、事業部門へのコスト配分が反映されます。クラウド割り当て率は次の 2 つの方法で導入できます。なんらかの損益指標（使用量、または収益か従業員数を基準にした従来型の損益割り当て）によって分配されたコストを定性化するシンプルな方法。タグ付けか API 呼び出しを使用して使用量を測定し、関連コストを事業部門に割り当てるリソース（専用リソースと共有リソースの両方）だけを定性化するより高度な方法。

導入において初歩から中級レベルへと進んだお客様は、総クラウドコストの 70% 以上を割り当てを目指します。一方で、上級レベルにまで達したお客様は使用量を直接測定することで、コストの 90% 以上の割り当てを実現します。

コストの最適化に関する指標

クラウドコストを最適化するには、コストを削減するだけでなく、ビジネス価値を最大化するにはどこに投資すればよいかを把握する必要があります。これは、一貫性のある方法を用いて、最も費用対効果が高い方法でクラウド使用量を可視化、管理する反復的かつ継続的なプロセスです。コストの最適化に成功すれば、クラウドコストを大幅に削減できるだけでなく、アプリケーションのパフォーマンスが向上することで、処理できるトラフィック（1 秒あたりのユーザーリクエスト、または処理するトランザクション件数）の量を同じ予算範囲内で増やすことができる場合さえあります。

組織では、請求と使用量やコストに関するデータを取り込むことで生成されるレポートと、最適化のために生成される推奨事項を自動化する必要があります。こうした最適化により、節約できる費用（実現されていないコスト削減）が明らかになり、チームは導入に注力することでコスト削減を実現できます。

通常は以下を行うことでコストを削減できます。

確約利用割引（リソースベースと支出ベース）や BigQuery の予約などの価格の最適化。
ビジネス価値を一切もたらさない、無駄の多いリソース（古くなったスナップショット、アイドル状態のインスタンス、大きすぎるデータベースなど）の最適化。

この指標を取得することで、組織では内部の非効率な部分について状況を常に把握できます。また、経営陣はコスト削減の実現に注力することで、クラウドでワークロードを実行することでもたらされる真のメリットを実感できます。

おすすめハブを FinOps ワークフローに統合することで、コスト最適化指標を導入できます。おすすめハブは、Active Assist に含まれています。Active Assist には、最小限の労力でワークロードを最適化できる、インテリジェントなツールと機能が豊富に用意されています。複数のプロジェクトにおよぶすべての推奨事項だけでなく、節約できるコスト（ドル単位）の概要が表示されるため、コスト最適化の取り組みに優先順位を付けて進めることができます。アイドル状態の VM Recommender、確約利用割引 Recommender、VM マシンタイプ Recommender など、さまざまな Recommender から生成された推奨事項を実行に移すことでコスト削減を実現したお客様もいらっしゃいます。

最終的には、最適化対象のすべてのクラウドサービスで 90% を超えるコスト削減が可能であると見込んでいます。削減されたコストを他社にはないプロダクトやサービスの開発に再投資し、カスタマーエクスペリエンスを向上させることで、クラウドがもたらすビジネス価値の実現を推進したお客様をこれまで目の当たりにしてきました。

計画と予測に関する指標

企業におけるクラウドコンピューティングの予測精度に直接影響するため、財務計画は財務組織に欠かせない能力です。企業の財務目標の指針となる、年単位で設定される財務指標の正確な予測に財務計画では力を入れます。年間計画は四半期ごとに評価され、年間を通じて、パフォーマンスに応じて調整されます。ビジネスの成果を高めるために、予測の精度は月単位でモニタリングされます。

通常は、クラウド運用を担当しているチームがクラウドコンピューティングコストの計画と予測も行います。業務予測計画は利用ワークロード計画、過去の傾向、季節性と主要な指標に基づいて策定されます。変革プロジェクトは予測精度に重大なリスクももたらします。

クラウド支出を財務的な観点から正確に予測するには、資産の減価償却期間に対する従来のアプローチ、およびメンテナンスとライセンスのコストに対するトレンドベースの予測を見直す必要があります。安定状態のワークロードに対するトレンドベースのモデル、アプリケーションのスケーリングに対するドライバベースのモデル、月ごとのバリアンス分析を組み合わせた、ワークロード専用予測モデルを使用することで、変動が激しいクラウドのニーズを極めて高い精度で予測できるようになります。

予測精度を把握、測定することで、企業は計画を実行に移した場合の結果を明らかにできます。予測精度のバリアンスに関する測定、話し合いを行い、クラウド支出の割り当てをきめ細かく管理することで、企業は予測どおりの結果を得られます。

財務担当チームとクラウド運用チームでは、最低でも月に 1 度はクラウドコンピューティングの予測精度について話し合う必要があります。クラウド運用チームでは 1 か月間の予測の傾向をモニタリングし、予想外の動きが見られた場合には調整の内容を評価する必要があります。

高い精度で予測を行うことで、経営幹部や投資家を動揺させるようなこともなくなります。オンプレミス環境の設備投資の減価償却と比較すると、クラウドコンピューティングの方が通常は変動性と季節性が高くなります。プロジェクトとスプリントアジャイル管理を調整することで、予想外の事態を避けることができます。開発における変更によって支出が予想外に増加した場合は、予想外の事態が今後発生しないように、チェンジマネジメントプロセスを見直す必要があります。

ツールとアクセラレータに関する指標

FinOps のプラクティスを最大限に活用するには、適切なツールとアクセラレータを導入することが重要になります。初期段階では、クラウド支出の詳細な分析をフル活用できないこともあります。プラクティスの習熟度と質が向上すれば、特定のプロジェクト / チームのコストの把握、そして単価指標の確立においてリソースへのラベル付けとタグ付けがもたらすメリットを実感できるようになります。

リソースのモニタリングを自動化し、支出、価値、コンプライアンス、推奨事項に関する洞察を得ることで、こうした機能がさらに大きな威力を発揮します。

コスト削減につながる自動生成された推奨事項のうち、何件が実際に導入されかを導入率として評価することで、ツールとアクセラレータの習熟度を測定することをおすすめします。

組織が新しいワークロードをクラウド環境にオンボーディングする際、実用的で効果の高い推奨事項とモニタリング機能がないとクラウドの無駄が増えるため、この指標は重要です。クラウドへの投資に見合うだけの価値を組織が実現できないのも、実用的で効果の高い推奨事項とモニタリング機能がなかったことが主な原因です。

ツールの習熟度を上げる取り組みを始めるお客様には、特別な構成が不要のおすすめハブをご利用いただけます。おすすめハブは、Google Cloud Console で、推奨事項の表示、優先度設定、適用の操作が行えるページです。 VM の適切な推奨サイズの提示、BQ スロットの最適化、確約利用割引、アイドル状態のリソースに関する推奨などが利用できます。Recommendations API を使用することで、おすすめハブを既存のエンタープライズツールに統合することもできます。組織の習熟度が上がれば、Cloud Monitoring を活用して、独自のビジネスロジックに基づく高度な推奨事項を作成できるようになります。

最終的には、推奨事項を提示するツールが成熟することで、自動生成された推奨事項の 50% 以上が導入され、組織ではクラウドの無駄を最小限に抑えて、クラウドへの投資から最大限の価値を引き出せるようになると見込んでいます。

すべての指標を Cloud FinOps ダッシュボードで一元管理

時代の変化に応じてテクノロジーやビジネス目標も変わっていくため、目標が変化してもクラウド FinOps 指標を継続的に確認できるプロセスを確立することが重要です。また、特定した指標の目標において、すべての組織が「上級」状態になる必要はないことを念のためお伝えしておきます。今回ご紹介した指標は、組織の優先事項に合わせてビジネス成果を達成するためのものです。クラウド FinOps 指標の数値化と測定において各チームが部門の枠を超えて協力することで、経営幹部たちは上層部からの承認を素早く取得し、組織が一丸となって目指すべき目標を掲げて迅速に行動に移せるようになります。

今回ご紹介した指標を把握できる Cloud FinOps ダッシュボードを構築することで、変化を歓迎する企業文化を促進するとともに、主な指標に関する結果を共有、追跡できるツールを変革とビジネスを担当するリーダーにもたらすソリューションを Google Cloud では開発しました。クラウド FinOps 指標の導入を成功させることで、組織はビジネスで成果を上げることに集中できるようになります。また、ダッシュボードが実現する有意義なフィードバックループによって、ビジネスへの影響を把握し、組織全体を見渡せるようになります。

では、お客様の現在の FinOps への取り組みはどのような状況にあるでしょうか。またどのようにして今後の課題を克服していくべきでしょうか。Google は、それについてお客様が考え、クラウドによるビジネス価値の最大化を進めるお手伝いができます。

クラウド変革への道のりのどの時点でも、Google とのインタラクティブなセッションにより、組織の経営幹部が一堂に会し、クラウドにおけるビジネス価値を加速、実現するための共通のビジョンとプランの確立に取り組むことができます。詳細にご興味がありましたら、Google までお問い合わせください。

^{このブログ記事には Daniel Pettibone、Amitai Rottem、Bruce Warner、Jon Naseath、Nihar Jhawar に共同執筆者としてご参加いただきました。また、この分野の専門知識、およびクラウド FinOps 関連トピックへの継続的なサポートでは、FinOps Foundation のメンバーである J.R. Storment 氏、Vas Markanastasakis 氏、Anders Hagman 氏、John McLoughlin 氏、Mike Bradbury 氏、Rich Hoyer 氏にご協力いただきました。}

-プロフェッショナルサービス、テクニカルアカウントマネージャー Pathik Sharma

- Cloud FinOps 担当責任者、サービス提供リーダー Eric Lam

Cloud FinOps のデコーディングでデジタル変革を加速する

Wed, 10 Nov 2021 02:00:00 +0000

※この投稿は米国時間 2021 年 10 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

デジタル変革を加速する

デジタル変革はビジネスと業界の推進要因となります。スタートアップ企業からグローバル企業まであらゆる規模の組織が、規模に応じた改善を行うためだけでなく、大きな変化を促進し、デジタル時代に完全に対応するためにデジタル変革に注力しています。このパンデミックをきっかけに、多くの企業がビジネスモデルのデジタル化、ビジネスのアジリティ、復元性、速度の向上による変革を実行すると同時に、顧客に新たなイノベーションとビジネス価値を提供するために本格的な取り組みを開始しました。

しかしながら、ボストンコンサルティンググループによると、デジタル変革を成功に導く企業はたったの 30% にすぎません¹。多くの大規模なデジタル変革が失敗したのは、明確なビジネス上の優先順位がなかったこと、エグゼクティブによるトップダウンの支持がなかったこと、または変革をやり遂げるための専用のリソースとコミットメントがなかったことが原因です。

デジタル変革を成功させるための基盤づくり

デジタル変革により、組織の運用方法の根本的な変化の促進、内部リソースの最適化、顧客への価値の提供が可能になりますが、これは一夜にして実現できることではありません。組織全体で変革を成功させるために、デジタル変革は、段階的でありながらアジャイルで、優れた費用対効果、価値重視、サステナブルな戦略によるプログラマティックなアプローチが必要です。

成功の基盤となる重要な要素の一つが、Cloud FinOps（Cloud 財務運用）です。Cloud FinOps は、クラウド変革により技術、財務、ビジネスを一体化する運用フレームワークおよび文化の変革であり、財務の説明責任を推進し、ビジネス価値の実現を促進します。デジタル変革では、部門間のコラボレーション、アカウンタビリティの推進、費用の透明性の提供、責任を追及しない文化のために行動や文化の変化を促進する、新しい作業モデルと運用モデルが必要です。

最も重要なことは、Cloud FinOps がデジタル変革のプログラムを成功に導き、テクノロジーチーム、財務チーム、ビジネスチームの間の境界を取り払うことで、ビジネスのアジリティを実現する機能としての役割を果たすことです。この複数の職能にまたがるチームコラボレーションにより、テクノロジーのリーダーは財務担当やビジネス担当のリーダーと協力してテクノロジーへの投資の理解を深め、サステナブルなビジネス成果を生み出します。そうすることで、ビジネス上の優先順位がより明確になり、焦点を価値創出、顧客中心主義、イノベーションに移すことができます。

それにより、企業はビジネスモデルを再構築してバリューストリームに投資し、クラウドテクノロジーへの投資を戦略的なビジネスの成果に結び付けています。また、クラウドの費用の可視化が向上することで、財務担当チームは予算に対するクラウドの支出をより正確に把握できるようになります。組織はテクノロジーサービスの TCO をメリット指標に合わせることで、十分な情報に基づいた将来の投資の意思決定と需要の予測ができます。

ビジネス価値の実現を促進する Cloud FinOps

Cloud FinOps の構成要素を適切にデプロイし実装することで、組織は費用の節約だけでなく、次のようなデジタル変革の加速が可能になります。

ビジネス価値の実現とイノベーションの促進
財務の説明責任と可視性の向上
クラウドの使用量と費用対効果の最適化
組織をまたいだ信頼関係と協力関係の実現
無秩序なクラウド支出の防止
部門間のサイロの解消

多くの場合、デジタル変革に成功している組織はビジネス価値を測定、追跡するプロセスを確立しています。Cloud FinOps の重要な構成要素の一つは「測定と実現」です。ビジネス目標に向けたビジネス価値指標の追跡とモニタリングを行う、強固な価値測定アプローチを確立することで、Cloud FinOps の規範を通じてテクノロジー、財務、ビジネスの各リーダーをまとめます。そしてデジタル変革によって組織が新しい革新的な機能を生み出し、収益を向上させる方法を示します。

ビジネスのメリット指標は、費用対効果、復元性、ベロシティ、イノベーション、サステナビリティという複数の要因に分かれます。Google は以下の指標カテゴリに KPI を割り当てることをおすすめします。

費用対効果: インフラストラクチャの節約、移行、サポート費用による費用対効果を測定します。顧客は一般的に、日、週、月ごとのコンピューティングやストレージの費用などの指標から始め、サービスを提供した顧客あたりの費用やトランザクションあたりの費用などの単位の指標に発展させます。ここで、アプリケーションスタックの費用は顧客の要因に合わせることができます。
復元性: サービス品質の向上とセキュリティリスクの継続的な状況把握により、業務の復元力を高めます。システムサービスレベルや、深刻なダウンタイムイベントの頻度と期間などの従来の指標は、IT の耐久性を測る効果的な測定基準です。また、顧客はダウンタイムイベントの 1 分あたりの費用を関連付けることでこれらの指標を増強でき、そうしたイベントの直接的な影響だけでなく、逃した収益も反映できます。
ベロシティ: プロダクトやサービス提供の流動性を加速することで製品化までの時間を短縮します。クラウドベースのマイクロサービスアーキテクチャに移行することで、顧客は通常、ソフトウェアのリリース頻度を上げるだけでなく、リリース前に多くのテストシナリオを実行できるというメリットが得られるため、コードの品質向上につながります。たとえば、Google による最新の State of DevOps Report 2021 によれば、優れた成果を上げた企業はその他の企業に比べて、973 倍の頻度でコードのデプロイとリリースを行っています。
イノベーション: 迅速なテストを行う文化を実現することで、イノベーションとクラウド変革を推進します。クラウドテクノロジーを使用することで、企業は固定費投資や長期間の調達リードタイムといった財務上の制約を回避できます。その結果、テストの限界費用や、プロダクトのコンセプト考案からテストまでの時間が大幅に削減される一方で、単位時間あたりのテスト回数が飛躍的に増加します。
サステナビリティ: 循環型経済戦略を採用し、炭素排出量ゼロでのアプリケーションの実行から、生産性の向上やサービスのコラボレーションによる炭素排出量の削減にいたるまで、あらゆる活動にサステナビリティを組み込むことで、環境と社会における真のサステナビリティ指標を組織全体に浸透させます。Accenture によると、オンプレミスからクラウドへの移行を行う企業は、平均で 65% のエネルギー削減と 84% の炭素排出量削減を実現できます¹。

開始方法

Cloud FinOps を開始するための最初のプロセスは、指標の定義またはアップデートです。ビジネス目標や戦略の要件は時間の経過とともに変化する可能性が高いため、目標が変わるたびに Cloud FinOps の指標を見直すことが重要です。チーム内部の優先順位に変化があった場合は、指標の見直しにビジネス目標の変更も含める必要があります。エグゼクティブは、意思決定における指標の影響を改善し、進化するビジネス機能とテクノロジー機能に適切な優先順位を付けて投資するために、テクノロジーとビジネス間の成果の依存関係を特定する必要があります。優れた指標を定義するのは、単にビジネス目標に照準を絞って価値を示すためだけではありません。戦略的なイニシアチブに優先順位を付け、効果的なリソース配分を導き、組織全体の認知度を向上させ、クラウドでの新しい運用方法に対する考え方の転換を促すという重要な目的もあります。

パンデミックの影響で、企業がデジタル機能をモダナイズする必要性は高まりました。テクノロジーによる創造的破壊があらゆる業界に及んでいる今、サステナブルなビジネス成果を達成するために自らを変革し、アジャイルな考え方を取り入れ、クラウドのテクノロジーや機能に大胆な投資を行うことが、組織にとってかつてないほど重要になっています。

では、現在のお客様のクラウドの FinOps への取り組みはどのような状況にあるでしょうか。またどのようにして今後の課題を克服していくべきでしょうか。Google は、それについてお客様が考え、クラウドによるビジネス価値の最大化を進めるお手伝いができます。

この重要な Cloud FinOps のトピックに対してそれぞれの分野の専門知識を提供し、協力してくれた Pathik Sharma、Bruce Warner、Jon Naseath、Nihar Jhawar に感謝します。

- Cloud FinOps 担当責任者、サービス提供リーダー Eric Lam

- ディレクター兼デジタル変革担当責任者 Daniel Pettibone

Flywheel の事業を加速させた Google Cloud のマネージドサービス

Wed, 20 Jan 2021 12:00:00 +0000

※この投稿は米国時間 2021 年 1 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: マネージド WordPress ホスティングを専門に扱う WP Engine の子会社 Flywheel は、35,000 以上の代理店やクリエイティブなブランドのサイトを運用するためのプラットフォームとして、堅牢なインフラストラクチャを必要としていました。Flywheel は Google Kubernetes Engine に移行することで、必要としていた信頼性の獲得とリソースの活用を実現しました。さらに、アプリケーションを Google Cloud のマネージドサービス上で運用できる多層のクラウドネイティブアプリケーションとして再設計し、新たなレベルでの業務の効率化と費用の管理を達成しました。その方法の詳細をお読みください。

Flywheel は広告代理店に対する効果的なウェブサイトソリューションの提供を専門としており、WordPress の CMS 向けにカスタム構成かつ最適化されたプラットフォームを構築しています。専用リソースの提供、堅牢なワークフローツール、WordPress のエキスパートの配備、さらにサイトのスピードを重視することで、優れたサイトパフォーマンスとユーザーエクスペリエンスを提供しています。

優れたサイトパフォーマンスとユーザーエクスペリエンスを成し遂げるには、ユーザーの期待に応えて進化する WordPress に合わせて刷新していく必要があります。デジタルが新たな標準となり、ますます競争が激化する状況の中で、Flywheel のプラットフォームに対するユーザーの期待は、未だかつてないほど高まっています。

創業間もない頃、（多くの SaaS 企業のように）Flywheel も単一ティアの VM ベースのプラットフォームとカスタムオーケストレーションツールを構築していました。始めはこのアプローチがうまくいきましたが、Flywheel が成長するにつれ、運用上のオーバーヘッドの多さ、頻発するメンテナンスのニーズ、低いリソース使用量、そして強い結合によるアジリティの欠如を経験するようになりました。

そして、新機能や新商品に関する顧客サポートではなく、すでに構築したものへの対応に多くの時間を費やしていることに気がつきました。また、プラットフォーム内のデータの大規模な分析を行う能力にも欠けていました。運用上のオーバーヘッドが少なく、顧客のニーズを受けて素早くシフトできるアジリティのプラットフォームに進化する必要があることは明白でした。

そこで、アーキテクチャのリエンジニアリングの一環として、Google CloudでGoogle Kubernetes Engine（GKE）、Filestore、Cloud SQL そして BigQuery をテストしようと決めました。すぐにいくつかの重要な利点を発見し、パフォーマンスの改善、より優れた費用管理、必須のスマートアナリティクス機能の獲得が可能になりました。

リソース効率に優れた Kubernetes アプリ: GKE のリソース使用量には非常に驚きました。90% を超える CPU 負荷でノードが実行できるようになったことにより、未使用のリソースが 85% 減少ししました。加えて、GKE では問題なくこのレベルでノードを確実に実行し続けることができました。以前のプロバイダは、高い CPU 負荷に VM が耐えられず、頻繁にアクセスできない状態になっていました。

高パフォーマンスでフルマネージドのファイルストレージ: Filestore は、GKE と統合されたフルマネージドの NoOps サービスです。そのため、自分たちで運用していなくても、顧客のニーズに応じてファイルシステムを簡単に拡大または縮小できます。
MySQL 用のフルマネージドリレーショナルデータベースサービス: Cloud SQL であれば、パフォーマンスや可用性を損なうことなく、容易にデータベースをスケールできます。また、メンテナンス費用も大幅に削減されました。
サーバーレスでスケーラビリティの高い、優れた費用対効果のデータウェアハウス: BigQuery のデータ分析能力、そして数回クリックするだけで結果を共有できる能力に満足しています。BigQuery を新しいアーキテクチャに統合することにより、必要とするスマートアナリティクス機能を、運用上のオーバーヘッドがゼロの状態で利用できます。

GKE のリソース使用量と信頼性の向上を活用し、さらにいくつかのマネージドサービスを実装して、すべてのティアを自分たちで運用する手間を省きたいと考えていました。しかし、そのためにはアーキテクチャに簡単な変更を加える必要がありました。

コンテナベースの多層アプリケーションの構築

まず、軽量のコンテナを使用するためにアーキテクチャを再設計しました。これには膨大な手動のリファクタリングが必要であることがわかっていたため、最初から正しい方法で行いたいと考えていました。コードを書き始める前は、このアーキテクチャの設計と検証に協力してくれた Google Cloud のチームに頼り切っていました。クラウドネイティブソフトウェアの開発、運用に対する Google の専門知識は、Google をパートナーとして選ぶ上での重要な差別化要因でした。この強力なパートナーシップと緊密なコラボレーションを通して、適切な戦略の構築、実行ができ、さらには望ましい成果まで上げることができました。

こうした設計上の決定は、コンテナベースのアプリケーションのリソース利用の促進が発端でした。VM ベースのプラットフォームでは CPU アイドルが非常に多く残されていて、85% に達する場合もありました。コンテナベースのワークロードを GKE 上で実行することで、平均 30% しかなかった CPU の使用率が、90% へという、200% もの増加を見せました。

そこからは、簡潔さを心掛けるというソフトウェアエンジニアリングにおける特に重要な原則の一つに従いました。Flywheel の目標は、プラットフォーム上のすべての WordPress サイトが最大のパフォーマンスと信頼性で運用できるようになることです。そのために、3 つの Google Cloud サービスを主に使用しました:

ファイルシステムを管理する Filestore
データベースを管理する Cloud SQL
クラスタの自動スケーリングと、コードを実行するためのクラスタマルチテナンシーが有効になった GKE

新たなアーキテクチャには多くのコンポーネントがありましたが、マネージドサービスを選んだので、チームに追加のオーバーヘッドは発生しませんでした。Flywheel がサイトパフォーマンスの最大化という目標の達成に集中する一方で、Google Cloud はサービスの信頼性とスケーラビリティにフォーカスしています。Google Cloud Console UI、REST API または Cloud SDK を通して、顧客のニーズに応じて簡単にコンポーネントをスケールアウトまたはスケールインできます。これにより、チームがプラットフォームの管理と運用を行う上で必要とする柔軟性と制御が得られるようになりました。

BigQuery の役割

コアプラットフォームが設計され、GCP での運用が始まった後は、迅速な分析のためにプラットフォームから BigQuery へデータのフィードを開始しました。もしシステムにパフォーマンスのボトルネックがあれば、即座に特定し、修正できます。もし顧客が未使用のリソースを保有していれば、ハイライト表示し、効率の改善につながる方法を推奨できます。このようなプラットフォーム内のデータから得た新たな発見により、市場の動向や顧客のニーズに対応する際に必要となるアジリティが備えられるようになりました。

最後に

振り返ってみると、カスタムプラットフォーム、カスタムオーケストレーションツール、カスタムコンポーネントを維持するための手動作業を省くことができ、新商品や新機能に関する顧客サポートにより多くの時間をかけられるようになったため、このプロジェクトは非常に有益でした。顧客の目的は読み込みが早く確実なウェブサイトを簡単に公開することで、新たなアーキテクチャの少ない運用上のオーバーヘッド、頻度の低いメンテナンスのニーズ、リソース使用量の増加、スケーラビリティの改善がその目的の達成に役立つことになりました。

Flywheel が Google Cloud を選んだ理由は技術の素晴らしさというだけではなく、スケーリングに不可欠な要素に対するチームの独自の知識でした。Google には、それぞれ 10 億人以上のユーザーがいる 9 つの製品があり、ピークパフォーマンスを実現するための専門知識を提供できる独自の立場にあります。Google チームとの協力的なパートナーシップが、この重要な戦略的取り組みを成し遂げるための指針となりました。

この投稿でハイライトした Google Cloud ソリューションを実際に体験するための、無料トライアルにぜひご登録ください。

-Google Cloud エンタープライズカスタマーエンジニア Micah Knox

-WP Engine プラットフォームエンジニアリング担当バイスプレジデント Charles Wagner

Cloud Run で段階的なロールアウトとロールバックを支援

Fri, 14 Aug 2020 08:00:00 +0000

※この投稿は米国時間 2020 年 7 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

すべてのデベロッパーは、次のデプロイが成功するという確証を求めています。

しかし、急に 100% のトラフィックにデプロイしては、何か問題が発生したときにリスクが生じかねません。ベストプラクティスは、変更を段階的にロールアウトして、新しいバージョンのコードで新たな不具合やエラーが発生しないかを確認することです。実際 Google では、4 日かけてコンポーネントの多くのロールアウトを行っています。

Google のフルマネージドコンテナコンピューティングプラットフォームである Cloud Run を使用すれば、変更のロールアウトをより詳細に管理できます。Cloud Run サービスの構成を変更した場合は常に、新しいリビジョンが作成されます。デフォルトでは、Cloud Run は自動的に、新しく作成されたリビジョンに 100% 移行します。現在は、トラフィックをリビジョン間で手動で分割することによって、リビジョンを段階的にロールアウトしたり、古いリビジョンにロールバックしたりもできるようになりました。

段階的なロールアウト

Blue / Green デプロイと呼ばれる段階的なロールアウトの例を見てみましょう。現在のリビジョン（「blue」というタグが付いています）から新しいリビジョン（「green」というタグが付いています）に段階的に移行します。

git commit のハッシュ（この例では「f5bd774」）でタグ付けするコンテナイメージに新しいコードをビルドします。

code_block: <ListValue: [StructValue([('code', 'gcloud builds submit . --tag gcr.io/project/image:f5bd774'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61ff0ea4c0>)])]>

これで、このコンテナに対して統合テストを実施して、それをステージング環境（ステージング GCP プロジェクトなどの環境）にデプロイできるようになりました。このコンテナの検査が完了したら、これを本番環境に push します。

この新しいコンテナを本番環境サービスにデプロイして、新しいリビジョンを構成しますが、まだトラフィックは送信しません。また、このリビジョンに green というタグを付けます。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run deploy myservice --image gcr.io/project/image:f5bd774 --no-traffic --tag green'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61ff0ea1f0>)])]>

「green」タグを使用すれば、トラフィックを移行しなくても、特定の URL で新しいリビジョンを直接テストできます。

デベロッパーは、次の URL でタグが付いているリビジョンをテストできます。

code_block: <ListValue: [StructValue([('code', 'https://green---myservice-abcdef.a.run.app'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61ff0ea2e0>)])]>

新しいリビジョンが正しく動作することを確認したら、トラフィックの移行を開始できます。

1 日目は、1% のトラフィックを新しいリビジョンに移行することから始めます。

コマンドラインから実行するには、次のように入力します。

code_block: <ListValue: [StructValue([('code', '$ gcloud beta run services update-traffic myservice --to-tags green=1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61ff0ea820>)])]>

または、次のようにして Cloud Console から実行します。

これで、Cloud Monitoring、Logging、または Error Reporting をリビジョンで絞り込んで調べ、新しいエラーやレイテンシが発生するかどうかを確認できます。

2 日目は、10% のトラフィックを新しいリビジョンに移行し、状態インジケーターを確認します。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run services update-traffic myservice --to-tags green=10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61ff0ea040>)])]>

3 日目は、50% のトラフィックを新しいリビジョンに移行します。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run services update-traffic myservice --to-tags green=50'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61ff0ea520>)])]>

4 日目は、すべてのトラフィックをこのリビジョンにルーティングします。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run services update-traffic myservice --to-tags green=100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61ff0ea5b0>)])]>

これで、ロールアウトが完了しました。新しいコードが Cloud Run サービスに到着したすべてのリクエストを処理するようになりました。

もちろん、必ずしも 4 日かけてロールアウトを行う必要はありません。同じコマンドを使用し、数時間かけて段階的にロールアウトできます。

ロールバック

デプロイ中やデプロイ後に問題が発生した場合、「blue」というタグが付けられた古い安定したリビジョンにトラフィックをロールバックできます。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run services update-traffic myservice --to-tags blue=100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61ff0ea7c0>)])]>

または、リビジョンにタグが付けられていなかった場合は、gcloud またはユーザーインターフェースを使用し、リビジョンの名前を指定して特定のリビジョンにロールバックできます。そのためのコマンドラインは次のとおりです。

code_block: <ListValue: [StructValue([('code', 'gcloud run services update-traffic myservice --to-revisions my-service-0002-joy=100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f61ff0eabb0>)])]>

ユーザーインターフェースからロールバックを実行する方法は次のとおりです。

安全第一

サービスに新しい機能を追加する場合、追加することでエラーが発生するのは最も避けなければなりません。段階的なロールアウトとロールバックのサポートを利用すれば、特に重要なユーザー向けアプリケーションを自信を持って Cloud Run でホストできます。ぜひ Cloud Run をお試しください。新しい機能のご要望がございましたらお知らせください。

-プロダクトマネージャー Steren Giannini

IDC の調査が示す Google Cloud Platform による SMB の 222% ROI でのビジネス成長促進

Tue, 11 Aug 2020 01:00:00 +0000

※この投稿は米国時間 2020 年 7 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

時間とリソースが制約されることが多い中小企業（SMB）では、イノベーションの加速と競争優位性の獲得に役立つソリューションがますます必要となっています。その結果、多数の SMB はインフラストラクチャの管理に費やす時間を短縮し、ビジネスの成長により多くの時間を割くことができるクラウドテクノロジーに目を向けるようになってきています。とはいえ、SMB にとってパブリッククラウドプロバイダはどれも同じというわけではありません。SMB のお客様の多くは、Google Cloud を選んだ理由として、スマートアナリティクスや人工知能が組み込まれており、使いやすく、オープンで信頼性が高く革新的であるように設計されている点を挙げています。

Google では、SMB がクラウドテクノロジーを採用する際の課題を把握するために、IDC Research に依頼して Google Cloud が SMB 独自のニーズにどのように対処できるかについて評価しました。本日は、この調査結果をまとめた The Business Value of Improved Performance and Efficiency with Google Cloud Platform（PDF）から引用してご紹介します。このホワイトペーパーでは、SMB がビジネスの成長を加速しつつ、コスト効率を向上させる方法が説明されています。この調査の一環として、Google Cloud SMB のお客様が 3 年間で 222% の投資収益率を達成し、組織あたり 109 万ドルの平均年間利益を獲得できることがわかりました。

それでは、IDC の調査結果を詳しく見てみましょう。

1. IT のアジリティと生産性の向上

IDC の調査によると、SMB は顧客の需要と行動の変化に迅速に反応する必要があることが多く、これは現在の世界的な状況において特に当てはまります。Google Cloud を使用すると、SMB は需要に合わせてスケールアップやスケールダウンができ、使用した分だけ支払えば済みます。調査ではまた、向上したインフラストラクチャのアジリティや、スケーラビリティ、フレキシブルな容量に加えて、Kubernetes Engine による自動スケーリングなどのその他のプラットフォーム機能を使用して変化するビジネス要件に対処することで、Google Cloud がアプリケーション開発チームにどのように役立つかついての分析情報も示されています。IDC は最終的に、Google Cloud で新しいアプリケーションと機能を効率的に構築するために必要なリソースにシームレスにアクセスすると、デベロッパーの生産性が 19% 向上することを明らかにしています。これはつまり、開発チームメンバーが 4 人以上追加された場合に匹敵します。

Google Cloud のお客様である idwall の場合、デベロッパーの生産性が約 30% 向上しました。

2. ビジネスの成果とパフォーマンスの向上

SMB はビジネスの維持や成長のために、既存の顧客との関係やブランドに依存する余裕は必ずしもありません。代わりに、ビジネスチャンスが生じたときにそれを迅速に活用し、競争力を維持するために顧客の期待に応え続けるために、機敏性と順応性が求められます。IDC の調査によれば、Google Cloud Platform はアジリティ、柔軟性、パフォーマンスを向上させることで、SMB がビジネスを迅速に成長させるのに役立っています。Google BigQuery、Kubernetes Engine、AutoML などの最先端のクラウドサービスを使用すれば、各企業は組織あたり年間 16%、つまり年間 881,500 ドルの収益増加を実現できます。

Google Cloud のお客様の 1 社は成長の 25% が Google Cloud Platform によるものだと述べています。

3. 運用コストの削減

SMB は予算が制限され、人員配置のモデルに余裕がないことが多いため、IT 運用をできる限り費用対効果の高い方法で行うことが重要です。人員配置の効率は運用コストの削減で大きな効果を発揮します。IDC によれば、Google Cloud Platform を使用すると、SMB は IT チーム全体の効率を 41% も向上できます。つまり、約 3 人の IT 人員リソースと同等の生産性を達成できるということです。IDC はインフラストラクチャコストを詳細に調査し、Google Cloud Platform を使用する SMB は、プリエンプティブル VM インスタンス、自動パッチ、Google の強力なカスタマーサポートチーム、サーバーレスサービスによってコスト削減が実現し、3 年間でコストを 26% 削減できると算出しました。

Google Cloud のお客様で、ブラジルのヘルステック企業である GESTO の場合、サーバーレスコンピューティングを利用して約 15% コストを削減できました。

SMB はクラウドでより多くのことを実現

SMB 向け Google Cloud Platform のメリットに関する IDC の調査結果について詳しくは、ホワイトペーパーをダウンロードしてください。Google Cloud と SMB について詳しくは、SMB ソリューションについて調べるか、SMB 向けに特化して用意された Google Cloud Next ‘20: OnAir のセッションパッケージをご覧ください。たとえば、スタートアップ: 入門、スタートアップ: 上級、ビジネス継続性、ビジネス / デジタル変換などをご確認ください。

-Google Cloud グローバル SMB セールス担当ディレクター Lindsey Scrase

クラウド ファースト

Energy Drive「サステナビリティの実現」 - Google Cloud を活用したシステム パフォーマンスの動的なモニタリングと分析