Containers & Kubernetes

GKE、Cloud Run、App Engine、Cloud Functions のための gVisor ファイルシステムのパフォーマンス改善

2023年2月9日

Google Cloud Japan Team

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

柔軟なアプリケーションアーキテクチャ、CI / CD パイプライン、およびコンテナワークロードは、信頼できないコードを実行することが多いため、機密性の高いインフラストラクチャから分離する必要があります。一般的に採用されているソリューションの一つとして、多層防御プロダクト（gVisor を使用する GKE Sandbox など）をデプロイして、保護レイヤーの追加によってワークロードを分離する方法が挙げられます。Google Cloud のサーバーレスプロダクト（App Engine、Cloud Run、Cloud Functions）も、gVisor を使用してアプリケーションのワークロードをサンドボックス化しています。

ただし、防御の階層を増やすと、新たなパフォーマンス上の課題が発生することもあります。Google は、gVisor のユーザー空間カーネルでファイルシステムのパスを走査するためにいくつかの操作が必要となったときに、そのような課題を 1 つ発見しました。Google は、この課題に対処し、gVisor のパフォーマンスを大幅に向上させるため、同レベルのセキュリティを維持しながら、パフォーマンスを考慮したまったく新しいファイルシステム層を記述しました。新しいファイルシステム（VFS2）により、ファイルシステムのシステムコールに必要な操作回数が減り、ロックの競合が減り、より効率的にメモリが割り当てられ、Linux との互換性が向上します。

多層防御とファイルシステム

第 1 の防御層は、ユーザーモードで動作する gVisor カーネルです。gVisor の脅威モデルでは、悪意のあるコンテナが、基盤となるホストインフラストラクチャや他のワークロードから隔離されたまま、gVisor カーネルを侵害できることが想定されています。gVisor カーネルは信頼できないため、ファイルシステムに直接アクセスできません。ファイルシステムの操作は、悪意のあるワークロードから隔離されたプロキシ（Gofer といいます）によって仲介されます。open、create、stat などの操作は、プロキシに転送され、審査された後、プロキシによって実行されます。Gofer は、Pod 内のコンテナごとに 1 つあり、別プロセスとして実行されます。必要なアクセスのみを許可するよう多層防御層でも保護されています。Gofer がファイルへのアクセスを許可した後は、読み書き操作を gVisor が直接ホストに行うことで、パフォーマンスを向上できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_gVisor.max-900x900.jpg

gVisor カーネルのファイルシステムの手直し作業前は、ファイルパスを走査するのに多数の操作が必要であり、パフォーマンスが落ちました。この問題は、各操作の往復費用が RPC とスケジューリングにかかる費用で悪化する、Gofer にマウントされたファイルシステムを使用する場合に特に顕著に見られました。さらに、gVisor のサンドボックスは、各パスコンポーネントを走査するときに Gofer に対して新しい RPC を発行するため、パフォーマンスが大幅に低下します。

ファイルシステムのパフォーマンス向上

この課題に対処するには、パス解決をファイルシステムに直接委ねる機能を gVisor の Sentry に持たせる必要がありました。これにより、Gofer ファイルシステムは、操作時にパスコンポーネントごとに 1 つの RPC を発行するのではなく、大規模な走査を実行するために 1 つの RPC を発行できるようになりました。例として、VFS1 では、stat（/foo/bar/baz）により、Gofer に対して少なくとも 3 つの RPC（foo、bar、baz）が生成されますが、VFS2 では 1 つしか生成されません。

この機会に、サンドボックス - Gofer のプロトコル層についても手直しを行いました。以前は、9P2000.L プロトコルの修正版を使用していました。しかし、このプロトコルは非常に処理量が多く、多数の RPC を発行し、メモリの消費量が大きいことが判明しました。そこで、9P の代わりに LISAFS（Linux サンドボックスファイルシステムプロトコル）という新しいプロトコルを構築しました。LISAFS は、RPC とメモリ使用量に関してより経済的です。LISAFS は、複数のパスコンポーネント走査のための RPC を提供します。VFS2 の Gofer ファイルシステムは、このようなワンショット走査を LISAFS で実行できるようになりました。また、LISAFS は、RPC よりはるかに高速なファイル IO を実行できます。

open、create、stat、list、load libraries など、頻繁にファイルシステム操作を行うワークロードは、VFS2 と LISAFS によりパフォーマンスが向上しています。これらのワークロードの例としては、Python や NodeJS などのインタプリタ言語の実行や、多数のインポート、ソースからのバイナリ構築などが挙げられます。bazel などの CI / CD ワークロードは、大規模なコードベースを基盤とし、ファイルシステムのパフォーマンスに関する優れた分析情報を提供します。このようなワークロードは、多くのソースファイルを開いて読み取り、多くのオブジェクトファイルとバイナリを書き込む必要があります。

2022 年 12 月時点の gRPC と Abseil を構築したオープンソースの bazel ベンチマークの結果を紹介します。これらは GKE に似た環境で実行されました。結果を理解するうえで、以下の用語を把握しておくことをおすすめします。

runsc のオーバーヘッド: gVisor がネイティブと比較して追加するパフォーマンスオーバーヘッドです。たとえば、ワークロードのネイティブ実行（runc を使用）に 10 秒かかり、runsc に 13 秒かかる場合、runsc のオーバーヘッドは 30% となります。
root: プロジェクトのソースコードはルートファイルシステムに置かれ、排他モードでマウントされます。つまり、サンドボックスがファイルシステムを完全制御し、より積極的なキャッシュ保存によってパフォーマンスを向上させます。
bind: プロジェクトのソースコードは、バインドマウントに置かれます。バインドマウントはすべて共有モードでマウントされます。つまり、外部からのファイル変更が発生する可能性があり、gVisor はアクセスのたびにキャッシュを再検証し、状態を最新に保ちます。
tmpfs: プロジェクトのソースコードは、tmpfs（インメモリファイルシステム）に置かれます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_gVisor.max-1200x1200.jpg

VFS2 と LISAFS は、これらすべての構成で一貫してパフォーマンスを向上させ、runsc をネイティブ（runc）のパフォーマンスに近づけていることがわかります。

VFS2 と LISAFS は、GKE とサーバーレスの全プロダクトで 100% リリースされています。Google は、これらの最適化を数か月にわたって段階的に展開しました。これらは、初期化時に多くのファイルシステムの作業を行う一部のアプリケーションのコールドスタート時間の改善にも役立ちました。たとえば、2022 年 8 月からの App Engine 用の LISAFS 公開データでは、LISAFS によってコールドスタートが平均 25% 以上改善されたことが示されています。

コンテナワークロードの多層防御を本格的に実現することで、gVisor ファイルシステムで新しい実装が必要となるなど、パフォーマンスのトレードオフを特定することができました。これらの改善により、セキュリティについて妥協することなく、このパフォーマンスギャップをかなり埋めることができます。Google は、VFS2 アーキテクチャによって、セキュリティとパフォーマンスのトレードオフの改善を継続しながら、エンタープライズ対応のコンテナセキュリティソリューションを提供し続けることができます。

今すぐ GKE Sandbox を試して、ワークロードセキュリティを強化

GKE Sandbox は、ワークロードにもう 1 階層のセキュリティレイヤーを提供し、すぐにでも使うことができます。「GKE Sandbox を有効にする」ガイドを読むか、「GKE Sandbox の概要」を確認してコンテナセキュリティについて学ぶか、Google Cloud の無料トライアルで今すぐ利用してみましょう。技術的な詳細については、gVisor の公式ドキュメントをご参照ください。また、GitHub ではソースの確認や、投稿もできます。Google Cloud 上でサンドボックス化されたワークロードがさらに多く実行されることを期待しています。