Zenn
🚕

Google Cloud Next'24 Day 3 Uber 事例紹介セッションレポート

2024/04/14に公開
Google Cloud
Cloud Storage
Google Cloud Next
infrastructures
tech

こんにちは。バックエンドエンジニアリング部の吉崎です。
好きなハンバーガーは Gordon Ramsay Burger の 24 Hour Burger です。食べてないんですけどね。

そうです。Google Cloud Next'24 @ Las Vegas に参加してきました。
本記事では、Day 3 に行われた Uber の事例紹介のセッションを紹介します。
このセッションでは、Uber の事例を紹介するとともに、Google Cloud Storage(GCS) に関するアップデートが盛り込まれており、Next'24 にける GCS のアップデート紹介にもちょうど良いと思い選びました。なお、以下から概要を見ることができます。Next'24 登録者は加えてセッション録画も見れます。
https://cloud.withgoogle.com/next/session-library?session=ARC312&utm_source=copylink&utm_medium=unpaidsoc&utm_campaign=FY24-Q2-global-ENDM33-physicalevent-er-next-2024-mc&utm_content=next-homepage-social-share&utm_term=-

まとめ

Uber の recap スライドに GCS のアップデートがまとめられていたのでまずは下記写真をご覧ください。スライド右側です。
uber_gcs_recap

書き出すと、以下の通りです。

  • Multi-region buckets(GA)
  • Anywhere Cache(Private GA)
  • gRPC API(Private Preview)
  • IAM with Managed Folders(GA)
  • BigQuery tables access control(GA)
  • Cloud Storage FUSE with local cache(GA)
  • Hierarchical Namespace(Preview in Q2)

本記事では、上記のリストのうちチェックをつけた Anywhere Cache と Hierarchical Namespace を紹介します。

Anywhere Cache(Private GA)

これは何か？

Anywhere Cache は、クライアントと GCS バケットの間にゾーンローカル SSD を持つインスタンスをキャッシュサーバとしてプロビジョニングすることにより、スループットの向上とレイテンシの低減を実現する機能です。簡単に図示すると以下の通りです。

draw_anywhere_cache

付属する機能として、キャッシュサーバの TTL 設定、キャッシュの一時停止／再開、無効化／有効化が紹介されました。

どう役立つのか？

1 つは、レイテンシとスループットの向上です。クライアントと同じゾーンに Anywhere Cache を配置することで、レイテンシが低減します。また、発表によれば、最大 10 Tbps のスループットとなるようです。（キャッシュの容量は 1 PB だそうです）
もう 1 つは、節約です。大規模なワークロードの場合、ネットワーク下りの料金が無視できませんが、この機能は同一ゾーンのため下りの料金がかかりません。
発表においても、デモプロジェクトの金額でしたが、Anywhere Cache を有効化により節約できることが説明されていました。
また、付随する機能として、TTL の設定、キャッシュの一時停止／再開、無効化／有効化の機能もあります。
ゾーンローカル SSD とセットの機能のため、Cloud CDN を使わずに GCS だけでキャッシュを制御できるわけではありませんが、大規模なワークロードでは十分に検討に上がると思います。

使ってみる

Private GA のため恐らく利用できませんが、Cloud Shell を用いて利用可否を探りました。

まずは help を実行したときの結果を下記に書いておきます。コマンドの詳細は公式ドキュメントにも記載されていますので併せてご確認ください。幸い、alpha のステージとして gcloud CLI には含まれていました。

gcloud alpha storage buckets anywhere-caches --help
NAME
gcloud alpha storage buckets anywhere-caches - manage Cloud Storage
Anywhere Caches

SYNOPSIS
gcloud alpha storage buckets anywhere-caches COMMAND [GCLOUD_WIDE_FLAG ...]

DESCRIPTION
(ALPHA) Manage Cloud Storage Anywhere Caches.

GCLOUD WIDE FLAGS
These flags are available to all commands: --help.

    Run $ gcloud help for details.

COMMANDS
COMMAND is one of the following:

     create
        (ALPHA) Create Anywhere Cache instances for a bucket.

     describe
        (ALPHA) Returns details of Anywhere Cache instance of a bucket.

     disable
        (ALPHA) Disable Anywhere Cache instances.

     list
        (ALPHA) List all Anywhere Cache instances of a bucket.

     pause
        (ALPHA) Pause Anywhere Cache instances.

     resume
        (ALPHA) Resume Anywhere Cache instances.

     update
        (ALPHA) Update Anywhere Cache instances.

NOTES
This command is currently in alpha and might change without notice. If this
command fails with API permission errors despite specifying the correct
project, you might be trying to access an API with an invitation-only early
access allowlist.

ひとまず作成したバケットの Anywhere Cache がオフであることを確認するために describe してみましたが、どうやら create によって cache id を発行しないと describe ができないようです。（でもそもそも 404 ではなく Private GA 的なメッセージが返ってくると思っていた）

$ BUCKET=ca-yoshizaki-anywhere-cache
$ gcloud storage buckets create gs://$BUCKET
...
$ gcloud alpha storage buckets anywhere-caches describe $BUCKET
ERROR: (gcloud.alpha.storage.buckets.anywhere-caches.describe) HTTPError 404: Not Found

よってまずは create します。このとき注意するのは、指定したロケーションに含まれるゾーンを選ぶ必要がある、ということです。
※作成したバケットは us のマルチリージョンバケットです。

$ gcloud alpha storage buckets anywhere-caches create gs://$BUCKET us-central1-c
Creating a cache instance for bucket gs://ca-yoshizaki-anywhere-cache/ in zone us-central1-c...
ERROR: User [yoshizaki.kota@cloud-ace.jp] does not have permission to access b instance [ca-yoshizaki-anywhere-cache] (or it may not exist): yoshizaki.kota@cloud-ace.jp does not have storage.anywhereCaches.create access to the Google Cloud Storage bucket. Permission 'storage.anywhereCaches.create' denied on resource (or it may not exist).
  Completed 0/1

失敗しました。実行したアカウントにはオーナーロールが付与されていますが、storage.anywhereCaches.create が不足しているようです。
この権限が含まれるロールは下図の通りです。

roles_for_anywhere_cache

とりあえず Storage 管理者ロールを付与して再実行しました。

$ gcloud alpha storage buckets anywhere-caches create gs://$BUCKET us-central1-c
Creating a cache instance for bucket gs://ca-yoshizaki-anywhere-cache/ in zone us-central1-c...
ERROR: HTTPError 400: Anywhere Cache management operations are not supported at this time.
  Completed 0/1

権限の問題は解決したようですが、残念ながら、現在この操作はサポートされていないようです。
また、asia-northeast1(東京) にバケットを作り、そこに Anywhere Cache を作成しようとした場合、以下のエラーとなります。
※a, b, c どのゾーンでも試しています

$ gcloud alpha storage buckets anywhere-caches create gs://$BUCKET asia-northeast1-c
Creating a cache instance for bucket gs://ca-yoshizaki-anywhere-cache/ in zone asia-northeast1-c...
ERROR: HTTPError 400: Invalid zone. Anywhere Cache is not available in the requested zone.
  Completed 0/1

東京リージョンはそもそも利用不可のようです。恐らく、Google 側でリージョンごとに利用可否を制御でき、Uber のように限定されたユーザが利用するリージョンは有効化されているのでしょう。
念のため、us マルチリージョンではなく us-central1(アイオワ) リージョンのバケットに同じ操作をしましたが、not supported のため Anywhere Cache は作成できませんでした。

利用できるようになれば、下図赤枠のように、バケットごとに Anywhere Cache の有効／無効を設定できるようになるでしょう。なお、ロケーション構成（マルチ／デュアル／シングル）は不問のようです。
demo_bucket_list

次に、この機能に付随する設定系の機能です。

demo_configure_cache

少し画質が粗く見にくいですが、Zone, Recommendation, Time to live, Ingest on second access の 4 つの列があります。なお、デモ内での Recommendation（推奨）は Time to live(TTL) のみだったので、推奨 TTL と設定 TTL が一致すれば MATCHES RECOMMENDATION と表示されるようです。
Ingest on second access は、1 回目のアクセス時ではなく、2 回目のアクセス時にキャッシュさせるための設定です。
また、TTL と Ingest on second access の設定以外に、下図に示される機能もあります。

demo_cache_summary

青いリンクの PAUSE/RESUME A CACHE と DISABLE/RESUME A CACHE です。
名前の通りではありますが、PAUSE = キャッシュの一時停止、RESUME = キャッシュ再開、DISABLE = キャッシュの無効化、RESUME = キャッシュ再開です。
キャッシュを使う場合はさまざまな問題に対処する必要があり、これらの機能は問題の切り分け時に有用だと紹介されていました。
よくあるのは、オリジンの（＝元の）データが更新されているにもかかわらずキャッシュが更新されておらず、古いデータをキャッシュから読み取ってしまうケースです。
この場合、キャッシュを DISABLE にすれば、キャッシュの問題か否かを切り分けられるでしょう。

また、デモ中では、OBSERVABILITY タブにキャッシュヒット率などの指標が表示されており、キャッシュサーバの監視に必要な各種指標が簡単に見られるようでした。

Hierarchical Namespace(Preview in Q2)

これは何か？

GCS といえばオブジェクトストレージであってファイルシステムでないことを耳にしたことがある人も多いはずです。わざわざ GCS FUSE というライブラリを使ってファイルシステムとしてマウントする方法が用意されているほどです。公式ドキュメントには以下の通り書いてあります。

オブジェクト名はバケット内のフラットな名前空間に置かれます。

フラットな、というのは「単一の」もしくは「階層的でない」ことを意味しています。上記のドキュメントにも書いてありますが、とくにコンソールから GCS を触るといかにもファイルシステムかのように振る舞います。が、実体はそうではありません。つまり、バケット内にフォルダを作成し、スラッシュ区切りで階層構造を成しているように見えますが、あれは単なるシミュレーションであり、実際は単一のバケット内に列挙されたオブジェクトに過ぎません。このために、以下の 2 つの問題がありました。

  • フォルダのリネームが原子的でない
  • フォルダ階層の一覧処理に大量の ListObject 操作が必要になる

個人的には、オブジェクトストレージ＝単一の名前空間と理解していたため、ファイルシステムに近づけるこのアップデートは革新的に感じています。

どう役に立つか？

前述の 2 つの問題を解決します。別の話題も含まれていますが、セッションスライド（下図）をご覧ください。

hierarchical_namespace

フォルダのリネームが原子的でない

フラットな名前空間の場合、フォルダの名前を変更すると何が起きるでしょうか？
実際はフォルダではないので、そのフォルダ名を含むオブジェクトすべてのリネームが行われます。
スライドだと、たとえば Folder A を Folder AA に変えたとき、その下にある（ように見える）オブジェクト 5 つについても、オブジェクト名の一部が Folder A から Folder AA に変わります。なので、hns-bucket/folderA/object1 というオブジェクトは hns-bucket/folderAA/object1 となります。
発表では、原子性という言葉が使われていたので、たとえば名前を変更したフォルダ以下に 10,000 個のオブジェクトがあったとき、そのリネーム処理中に他の処理の影響を受けうる、ということでしょう。
→ 名前空間が階層的になると、フォルダのリネーム＝名前空間のリネームでしかないので、その名前空間内にあるオブジェクトがリネームされる必要はなく、原子的な操作となります。

フォルダ階層の一覧化に大量の ListObjects 操作が必要になる

下記 Issue に問題の一部が書かれています。
https://github.com/GoogleCloudDataproc/hadoop-connectors/issues/151

Hadoop の GCS コネクタを使用する際、GCS のスラッシュ区切りのパスをフォルダ階層とみなすために ListObjects 操作を行います。しかし、ListObjects の maxResults という結果の数を設定するオプションに、最大で 1,000 しか設定できません。このため、多くのオブジェクトがあるバケットだと オブジェクト数 / 1,000 回の ListObjects を実行する必要がありました。

このアップデートと同時に使えるようになった Folder Resource API を使えば、名前空間をフォルダと見立て、名前空間ごとの関係性からフォルダ階層を簡単に一覧化できるようになり、ListObjects 操作が不要になります。
代わりに Folder Resource API を使うことにはなりますが、これは名前空間を扱うだけのため、オブジェクトを一覧化する操作に比べはるかに少ない呼び出し回数になることが予想できます。

おわりに

Next'24 では「What's new」を冠する明らかにアップデートを紹介するセッションがありましたが、このように顧客事例の紹介に多くのアップデートがまとまっていることもあります。また、当然ではありますが、顧客の要望に応じて Google Cloud が進化していく、つまり、顧客の成長とともに Google Cloud が成長していることを理解しました。欲しいと思った機能は Google Cloud に伝え、より多くの顧客に対応できるプラットフォームになっていってほしいですね。

Discussion