コンテンツに移動
デベロッパー

2021 年の(現時点での)トップ 5 リリース

2021年9月2日
https://storage.googleapis.com/gweb-cloudblog-publish/images/762-GC-Stephanie_Wong__Blog_Header-AEO_v2-.max-2300x2300.png
Google Cloud Japan Team

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

今年もあっという間に 7 か月経ちました。2021 年が飛ぶように過ぎ去っていくと感じているのは私だけではないでしょう。

たとえそうであっても、Google Cloud ではすでに多くの出来事が起こっています。数え切れないほど多くのプロダクトや機能がリリースされ、Google I/O が初めてバーチャル開催されたほか、Applied ML SummitCloud Data SummitSecurity Summit などの Cloud OnAir イベントが毎月企画されました。プレスリリース、ブログ、ソーシャル メディアといったさまざまなチャネルを通じて発信される出来事に遅れずについていくのは、それほど簡単ではありません。そのため、皆さんがウェブを検索する手間をかけずに済むように、2021 年にリリースされたプロダクトの中から私が選んだ(現時点での)トップ 5 をご紹介します。さらに、Google プロダクトや業界内でのこれらのリリースの位置づけについて、個人的な見解も示します。

1. Vertex AI

5 月の Google I/O において、Vertex AI の一般提供が発表されました。これは、人工知能モデルのデプロイやメンテナンスにかかる時間を短縮するマネージド機械学習プラットフォームです。

2018 年に Google がリリースした AI Platform を覚えていらっしゃるでしょうか。このプロダクトには、トレーニング、予測、データ ラベリング サービス、マネージド ノートブックなどが含まれていて、データの収集からモデルやバージョンの管理に至るすべての ML ワークフローのステップに対応していました。これに加えて、AutoML の Vision、Video Intelligence、Natural Language API のような人気の AutoML プロダクトもありました。

お客様からいただいたフィードバックの中に、データ サイエンティストはさまざまな ML ポイント ソリューションを手動で組み合わせて利用することを余儀なくされているという声がありました。その結果、モデルの開発やテストの段階で時間的な遅れが生じ、実際に本番環境での運用にこぎつけるモデルは少数に限られていました。

Vertex AI は、Google Cloud の各種 ML サービスを単一の統一された UI と API にまとめ、大規模な機械学習モデルの構築、トレーニング、デプロイのプロセスを簡素化します。AutoML と AI Platform が、同じ基盤インフラストラクチャ、データ モデリング、UX、API レイヤを共有します。この単一環境では、モデルのトレーニングや比較を AutoML またはカスタムコードを使用して行うことができ、モデルはすべて一元的なモデル リポジトリに保存されます。これらのモデルを Vertex AI の同じエンドポイントにデプロイできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2021-08-20_at_11.06.16_AM.max-70.max-700x700.png

子ども向けの本の中には、物語の中で選択肢が提示され、どれを選ぶかによって展開が変わるようなものがあります。Vertex AI はこれと似たようなものと考えることができます。カスタムモデルをトレーニングするか、AutoML を使用するか、あるいは BigQuery ML を使用するかを選択しますが、物語に結末があるのと同じように、最後には本番稼働モデルを完成させることができます。同時に、本にしおりを挟んでおけば他のページを自由に覗けるように、現在の慣れ親しんだ感覚とコントロール感を保ったまま、さまざまな選択肢を試してみることもできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2021-08-20_at_11.06.28_AM.max-60.max-600x600.png

主な機能:

  • Deep Learning VM Image

  • Vertex Notebooks

  • Vertex Data Labeling

  • Vertex Explainable AI

  • Vertex Pipelines

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/vertexpipelines.gif

Vertex Pipelines

Google のプロダクト戦略におけるこのプロダクトの位置付け

Google は、ML アプリケーションを構築、デプロイ、管理する主要なツールを 1 つのツールボックスにまとめながら、BigQuery ML のような他の分析ツールも統合しています。長期にわたる AI への投資を Vertex に結実させるだけでなく、これを初心者や熟練者を問わず ML を簡素化できる手段の着地点としても使用しようとしています。それと同時に、カスタマー サービス エクスペリエンスを強化する Contact Center AI、非構造化データをビジネス ユーザーが使用できるようにする Document AI、臨床ワークフローで ML の力を解き放つ Healthcare API(これには Vertex AI に接続する事前構築済みコネクタが含まれます)のような特定業種向けの AI ソリューションも構築し続けています。

業界全体の中でこのプロダクトが適合する領域

現在 ML の分野は確実に成熟してきており、データ サイエンス チームは、単なるモデルの構築を超えてその先にあるモデルのメンテナンスにも目を向けるようになりました。チームはモデルをテスト、評価、理解し、再現する必要があります。実務者同士の協力は必須であり、責任ある AI を最優先に考えなければなりません。

そのため、ソフトウェア開発の CI / CD のような DevOps プラクティスが ML にも導入されるようになっています。新たに登場した MLOps は、ML モデルを構築および管理するワークフローを DevOps と類似の手法で体系化し、自動化しています。GitHub、Spinnaker、Datadog などのツールが台頭したのと同様に、ML ライフサイクルの一部(問題の追跡、変更履歴の管理、本番環境でのモニタリングと問題発生時のアラートの通知)を支援する新しいツールが多数登場してきています。

しかし、ML チームが求めているのは、パイプライン、特徴ストア、ラベル付けサービス、モデルストア、評価などを含む統一されたエクスペリエンスです。Vertex AI は、まさにそのようなエクスペリエンスをチームに与えようとする Google の大きな試みです。私はこれを、ベスト プラクティスの利用を促進し、新しい実務者の学習を助ける手段ととらえています。まず AutoML から開始し、途中で独自のカスタムモデルの構築に切り替えた場合でも、プロジェクトの基盤となるインフラストラクチャは変わりません。

使ってみる

最初に見る:

実際に体験する:

2. GKE Autopilot

2021 年の最も革新的でエキサイティングな発表の一つは、GKE Autopilot でした。これは、Google Kubernetes Engine(GKE)で Kubernetes クラスタを作成および管理するための新しい運用モードです。このモードでは、ノードやノードプールなどの基盤となるインフラストラクチャの構成と管理を GKE が担当するため、ユーザーはそれらの業務に気を取られることなく、ターゲット ワークロードや Pod 単位で課金されるリソース リクエスト(CPU、メモリ、エフェメラル ストレージ)のみに意識を集中させることができます。Autopilot には、ホストとコントロール プレーンに関する GKE SLA に加えて、Pod に関する SLA も含まれます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2021-08-20_at_11.11.07_AM.max-90.max-900x900.png

Kubernetes をニーズに合わせて最適化するには手動による組み立てや調整に相当な手間がかかる可能性がありますが、Google はそのような問題に尻込みせず果敢に挑戦してきました。GKE は 2015 年にコンテナ オーケストレーション プラットフォームとしてリリースされました。ユーザーは、Docker コンテナ クラスタの作成やサイズ変更、コンテナの Pod、レプリケーション コントローラ、Job、Service、ロードバランサの作成、アプリケーション コントローラのサイズ変更、コンテナ クラスタの更新とアップグレード、コンテナ クラスタのデバッグを行うことができます。

しかし、ちょっと待ってください。「GKE はまだフルマネージドでなかったのか?」と思いませんでしたか?

クラスタ コントロール プレーン、ストレージ、ネットワーキングは GKE によって管理されているため、GKE は実際にすでにさほど手のかからない Kubernetes プラットフォームと言えます。そうでありながら、クラスタ構成のほとんどの側面をユーザーが詳細に制御できるようにもなっています。これは、オペレーター チームにノード構成、クラスタサイズ、クラスタの自動スケーリング、メンテナンスの時間枠を独自に決定させたい企業にとっては最適です。しかし、多くのチーム、特に開発に重点を置いていて GKE のオンボーディングを迅速に済ませたいチームにとっては、これだけの制御レベルや多くの選択肢はチームが求めていることに対して過剰です。まったく不要という場合もあるでしょう。

GKE Autopilot は、より安全で一貫性のある開発プラットフォームを簡単に構築する方法を提供するために開発されました。クラスタ インフラストラクチャ、コントロール プレーン、ノードの管理を GKE Autopilot に任せられるため、Kubernetes を取り入れやすく、運用を簡素化できます。Google のインフラストラクチャ担当バイス プレジデントである Eric Brewer が次のようにツイートしていますが、これは非常に的を射ています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/9Ut4F3pQ5SUUNP4_image-bytes.max-600x600.max-600x600.png

主な機能:

  • GKE Autopilot がノードとノードプールを管理します。

  • Autopilot クラスタは、最適化されたクラスタ構成を使用してあらかじめ構成されています。

  • Autopilot に付随する SLA は、コントロール プレーンと Pod の両方をカバーしています。

Google のプロダクト戦略におけるこのプロダクトの位置付け

私がよく受ける質問の一つに「これは GKE のサーバーレス版なのですか?」というものがあります。Autopilot は「ノードレス」と考えるほうが適切でしょう。GKE は、Kubernetes API 全体を実装した業界初のフルマネージド Kubernetes サービスです。GKE Autopilot クラスタは、サーバーレス サービスの利点を備えながら、Kubernetes API にも完全にアクセスできます。Kubernetes を使用する人は、IaaS の上にある独自のアプリケーション プラットフォームを構築するためのレイヤとして Kubernetes を使用します。だからと言って、Autopilot は開発者向けでないというわけではありません。むしろ、Kubernetes を気軽に使い始めたいという開発者向けに作られています。

業界全体の中でこのプロダクトが適合する領域

もう一つよく聞かれるのが、「AWS Fargate とどこが違うのですか?」という質問です。GKE Autopilot は Fargate for EKS とよく似ていますが、大きな違いが 1 点あります。それは、Autopilot は DaemonSet、Job、CRD、アドミッション コントローラを含む Kubernetes API のほぼ全体をサポートしているという点です。特筆すべき違いの一つは、ブロック ストレージ(HDD)を Autopilot にアタッチできることです。Autopilot はそれでも Kubernetes であり、一からこのように設計されています。当初からの目標は、Autopilot は GKE であり、派生プロダクトでも別のプロダクトでもないというものでした。つまり、GKE Autopilot で自動スケーリングに加えられた改善の多くは GKE Standard にも反映されます。その逆もまたしかりです。Autopilot では、GKE の自動化とスケーリング、さらには多くの優れたコミュニティ拡張機能が集約されました。

すでに GKE で仕事をしている開発者にとっては、実際には何も変わりません。これから Kubernetes を使い始めようとしている開発者の場合、GKE Autopilot のようなプロダクトがどのように見えるのか、私にはまだわかりません。Autopilot では、引き続き Kubernetes のメリットが得られますが、日常的な管理やメンテナンスは一切必要ありません。以上が、Kubernetes エコシステムの発展に伴って現れている傾向です。しかしながら今のところ、「Kubernetes を効率的に管理できる能力は競合との差別化要因になる」ということを理解している企業はほとんどありません。

使ってみる

最初に見る:

実際に体験する:

3. Tau VM

Tau VM は今年 6 月に発表されたばかりです。Tau VM は新しい Compute Engine ファミリーで、スケールアウト型ワークロードにおいて費用対効果の高いパフォーマンスが得られるように最適化されています。

Tau VM ファミリーの最初のインスタンス タイプである T2D は、第 3 世代 AMD EPYCTM プロセッサをベースとしており、パフォーマンスとワークロードの総所有コストの両方の点で、どの主要パブリック クラウド プロバイダが提供しているスケールアウト型ワークロード用の VM よりも優れています。

Google の Compute Engine サービス(汎用 VM、コンピューティング最適化 VM、メモリ最適化 VM、アクセラレータ最適化 VM など)はすでに、開発 / テストからエンタープライズ アプリ、HPC、大規模なインメモリ データベースまでの幅広いワークロード要件をカバーしています。しかしそれでも、メディアのコード変換、Java ベース アプリケーション、コンテナ化ワークロード、ウェブサーバーといったスケールアウト型のエンタープライズ ワークロードを支えるコンピューティングのニーズは存在します。デベロッパーは、スケールアウト型のワークロードに的を絞り、しかも手頃な価格で生産性も犠牲にしない VM を求めています。Tau VM ファミリーの目的は、そのような特性を持つクラウドへの中間的な道筋を提供することにあります。

主な機能:

  • T2D VM は、事前定義された VM シェイプで提供され、VM ごとに最大 60 の vCPU、vCPU ごとに 4 GB のメモリが備わっており、最大 32 Gbps のネットワーキングを提供します。

  • AMD EPYC プロセッサ ベースの VM には x86 との互換性もあります。

  • AMD EPYC プロセッサは Zen 3 アーキテクチャを使用して構築されており、スケールアウト中の通信の遅延を抑えます。

  • T2D ノードを GKE クラスタに追加できます。

Google のプロダクト戦略におけるこのプロダクトの位置付け

Tau VM は、汎用 VM を補完し、企業のデータセンターが常に目標としてきた「エンタープライズ ワークロードのパフォーマンスを最低の価格で最大限に高める」ことを達成可能にするためにリリースされました。T2D の生のパフォーマンスは、主要な競合他社と比較して 56% 高い数字を示しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/65G5U5fzHMXPRLW_image-bytes.max-800x800.max-800x800.png

この結果は、CPU の整数性能を測定する SPECrate2017_int_base ベンチマークによるものです。32 個の vCPU と 128 GB の RAM を備えた VM を使用して、他のクラウド プロバイダのリリース済み VM とリリース前の Tau T2D インスタンスを実行しました。


業界全体の中でこのプロダクトが適合する領域

Google Cloud が置かれた状況の中で Tau を見ると、T2D が提供する VM インスタンス タイプはチームの要求にぴったりと符合します。IT リーダーにとって重要なのは、パフォーマンス、信頼性、費用の 3 つです。エンタープライズ環境の大半は汎用的なコンピューティング スペースで特に問題なく稼働でき、コンピューティング / メモリ / アクセラレータ最適化が必要になるほどのニーズも、それらに伴う費用をかけてまでアップグレードする理由もありません。それと同時に、企業は厳しい予算内で標準的なワークロードをサポートするためにノードを確実にスケールアウトしたいとも考えています。Tau の事前定義された VM シェイプが役立つような企業にとって、競争力のある料金設定とパフォーマンスという利点を持つ Tau VM は、積極的に行動を起こす理由となりえます。つまり、相反する両方の利点を同時に実現することができるのです。

使ってみる

4. Dataplex

Dataplex は、今年 5 月に開催された 2021 Data Cloud Summit でプレビュー版が発表されました。Dataplex は「インテリジェント データ ファブリック」と呼ばれており、これはデータ ウェアハウス、データレイク、データマート、データベースのデータ管理を統合できることを意味します。複数のサイロにわたってデータを一元的に管理、モニタリング、統制し、それらのデータをさまざまな分析ツールやデータ サイエンス ツールから安全に利用できます。

分析が話題になるたびに聞かされる「データサイロ」という言葉に私たちは皆うんざりしています。しかし、企業はいまだにさまざまなソースからのデータの移動やメタデータの抽出に苦労しています。データのクレンジングと準備ではミスが起こりやすく、セキュリティ ポリシーを設定するのは骨が折れます。データ ウェアハウス、オープンソースの分析エンジン、SaaS プラットフォームの相互運用性を確保するには、深い理解が必要です。

通常は、サイロの間でデータを移動および複製するか、データを分散させたままにしてアジリティを犠牲にするかのどちらかを選ぶ必要があります。Dataplex は、データを複製または移動せず、自社製システムも構築せずに、データをキュレート、統合、分析できる単一のエクスペリエンスを提供するものとして開発されました。

主な機能:

  • Dataplex の相互運用可能なストレージ レイヤにより、レイク、データゾーン、アセットなどを論理的に構築できます。

  • Google AI を使用して、構造化データと非構造化データのメタデータを自動的に収集します。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/dataplex1.gif

  • すべてのデータとロケーションにわたって一貫したポリシーを定義し、適用できます。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/dataplex2.gif

Google のプロダクト戦略におけるこのプロダクトの位置付け

Dataplex は、DatastreamAnalytics HubBigQuery Omni for Azure などの 10 以上の他のプロダクトと同時に発表されたプロダクトの一つにすぎません。それは、環境の違いを越えてデータ ガバナンスを提供する大きなイニシアチブの一部です。Dataplex は、Apache Kafka、Apache Spark、Presto と統合できるように作られています。また、Accenture、Collibra、Confluent、Informatica、HCL、Starburst、NVIDIA、Trifacta などが提携先として名を連ねています。

業界全体の中でこのプロダクトが適合する領域

SaaS やカスタムメイド システムの採用により、今後データサイロの再構築が続くと考えられます。業界は閉鎖的なデータレイク ソリューションから手を引き、相互運用可能なオープンソースの互換プラットフォームに向かっています。Dataplex のコントロール プレーン、データプレーン、セキュリティ、メタデータ、カタログ、インテグレーション、発見強化機能の設計には、複数の分野にまたがる努力が必要でした。その努力の結果、そのまますぐにデータレイクの構築に取り掛かることができるソリューションが誕生しました。

使ってみる

5. Workflows

Workflows はサーバーレス カテゴリに分類されるプロダクトで、今年 1 月に一般提供が発表されました。Workflows では、サーバーレス ワークフローを使用して Google Cloud サービスや HTTP ベースの API サービスのオーケストレーションと自動化を行うことができます。一言で言えば、Workflows は「もの」をつなぎ合わせます。どのような種類の「もの」でしょうか?それは、公開 API を持つほぼすべてのものです。複数の Cloud Functions をつなぎ合わせることができ、Cloud Functions を Cloud Run サービス、Google Cloud APIs、さらには外部 API と組み合わせることも可能です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2021-08-20_at_11.08.30_AM.max-90.max-900x900_2BjCuqR.png
イベント ドリブン ワークフローの例

クラウドの利用範囲が広がると必然的に、管理するサービスや結び付けるサービスの数が増えるという問題に直面します。柔軟なサービスをデプロイする方法としてよりモジュール性の高いアーキテクチャやコンテナが事実上の標準となっている現在、ソリューションの開発、デバッグ、可視化はますます複雑かつ困難になっています。

API ドリブン アーキテクチャが世に広まったことから、統合を管理するカスタム サービスを作成し、手動でメンテナンスする仮想マシンでそれらのサービスをホストするのが普通になりました。もう一つの方法は、入念に作られたイベント ドリブン アーキテクチャによってそれらのサービスを結び付けることです。しかし、特にワークフローが数日かかるような場合には、ワークフローの実行の進捗を監視することはほぼ不可能です。エラー処理を実装することは難しく、イベント チェーンに沿って障害を追跡するのは大きな負担になります。さらに、あるワークフローのためにイベントに変更を加えると、同じイベントを使用している他のワークフローが破綻する場合があります。ワークフロー全体の一元的な定義がなければ、全体像を把握して適切な変更を加えるのは困難です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2021-08-20_at_11.08.45_AM.max-90.max-900x900.png
あるワークフローのためにイベントに変更を加えると、同じイベントを使用している他のワークフローが破綻する場合があります。

Workflows は、結び付けられたサービスの全体像を提供し、値の解析や各サービス間での値の引き渡しを処理します。エラー処理や再試行ポリシーは最初から組み込まれています。さらに、Workflows はサーバーレスなのでインフラストラクチャの管理は不要であり、需要に応じてシームレスにスケールします(ゼロへのスケールダウンも可能)。料金モデルは従量課金制で、料金は実行時間に対してのみ発生します。

主な機能:

  • 組み込みのエラー処理

  • ワークフロー ステップ間での変数値の引き渡し

  • Google Cloud プロダクトに対する組み込みの認証

  • 低レイテンシでの実行

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/Workflows.gif

Google のプロダクト戦略におけるこのプロダクトの位置付け

数人の方から、「Google にはすでに Cloud Composer という汎用のワークフロー オーケストレーション ツールがあるが、Cloud Composer ではなく Workflows を使用したほうがよいのはどのような場合か」という質問を受けました。あえて単純化して言えば、データ処理、ETL、または機械学習パイプラインを管理していて、これを BigQueryDataflow のようなデータ プロダクトと統合する場合は、Cloud Composer が適しています。それに対して、イベントまたはチェーン API をサーバーレスな方法で処理したい場合に、トラフィック パターンがバースト的である、実行ボリュームが大きい、または低レイテンシが必要なときは、まず Workflows を検討したほうがよい可能性が高いと言えます。Workflows は、「コールド スタート」の影響なしに、ステップ間を高速に遷移しながら自動的にスケールアウトします。そのため、Workflows はレイテンシの影響を受けやすいアプリケーションに適しています。

業界全体の中でこのプロダクトが適合する領域

データベースに未完了の注文を照会するような顧客請求書処理やバッチプロセスの実用的なワークフローを作成するというニーズは数十年前から存在します。しかし、このようなワークフローを大量のカスタム ロジックを記述せずに作成できる良い方法はこれまでありませんでした。RPAAppSheet Automation のように、ビジネス ユーザーでも使用できるローコードのワークフロー自動化ソリューションが注目を浴びることはありました。しかし、マイクロサービス、エンタープライズ ERP システム、外部 API、IT インフラストラクチャの自動化を扱うときは、実行の継続的な追跡、エラー処理、データ変換、条件付きジャンプなどの高度な機能が必要となります。Workflows は、デベロッパーが HTTP ベースの API サービスをサーバーレスでオーケストレートするのに最適です。

使ってみる

最初に見る:

実際に体験する:

最後に

以上が、私が選んだトップ 5 のリリースです。最後までお付き合いいただき、ありがとうございました。このリストから、Google がこの 1 年間取り組んできたビッグ プロジェクトの一端を理解していただければ幸いです。図らずも、出来上がったリストは AI、コンテナ オーケストレーション、コンピューティング、分析、サーバーレスという異なる分野を横断したものとなりました。そして、来る Google Cloud Next '21 ではさらに多くのプロダクトやサービスをご用意しています。上記のカテゴリでも新しいプロダクトをいくつか発表する予定ですので、この 3 日間のバーチャル イベントにぜひご登録ください。

https://storage.googleapis.com/gweb-cloudblog-publish/images/6mSebWYvZzWUJW2_image-bytes.max-1100x1100.max-700x700.png

効率の向上以上に、変革の推進のためにクラウドが活用される時代になったことは明らかです。私にとって、これらのリリースは(数あるプロダクトの中でも特に)効率を向上させ、変革を促すものです。デベロッパーは、ツール、柔軟性、使いやすさを犠牲にすることなく、アプリやデータを最も意味のある場所で安全にホストする自由を手に入れました。

ご意見やご質問がございましたら、@stephr_wong までお寄せください。


-デベロッパー アドボケイト Stephanie Wong

投稿先