Alibaba Open Source Container Image Acceleration Technology

Alibaba はこのたび、クラウドネイティブなコンテナイメージアクセラレーション技術をオープンソース化し、overlaybd イメージ形式を公開しました。従来のレイヤー型 tar パッケージ形式と比較して、ネットワークベースのオンデマンド読み取りを実現し、コンテナの高速起動を可能にしています。

この技術ソリューションは、もともと Alibaba Cloud 内部の DADI プロジェクトの一部でした。DADI は Data Accelerator for Disaggregated Infrastructure の略称で、コンピュートとストレージの分離アーキテクチャに向けて、さまざまなデータアクセス高速化技術を提供することを目的としています。イメージアクセラレーションは、DADI アーキテクチャがコンテナとクラウドネイティブの分野で取り組んだ画期的な試みです。2019 年の導入以来、オンラインで大量のマシンにデプロイされ、コンテナ起動の累計回数は 10 億回を超え、Alibaba Group と Alibaba Cloud の複数の事業ラインをサポートし、アプリケーションのリリースとスケーリングの効率を大幅に向上させています。2020 年には、国際トップカンファレンスで論文 "DADI: Block-Level Image Service for Agile and Elastic Application Deployment. USENIX ATC'20" を発表し [1]、その後オープンソースプロジェクトを立ち上げ、コミュニティへの技術貢献と、標準の確立およびモデルの構築を通じて、より多くの開発者をコンテナとクラウドネイティブのパフォーマンス最適化の分野に呼び込むことを計画しています。

背景

Kubernetes とクラウドネイティブの爆発的な普及に伴い、企業でのコンテナの大規模な適用がますます拡大しています。コンテナの核心的な利点の一つが、高速なデプロイと起動です。これは、ローカルでのイメージインスタンス化時間が非常に短い、つまり「ホットスタート」時間が短いことを意味します。しかし、「コールドスタート」、すなわちローカルにイメージが存在しない場合は、コンテナを作成する前にレジストリからイメージをダウンロードする必要があります。長期的なメンテナンスと更新により、ビジネスのイメージはレイヤー数と全体のサイズの両方で大規模化しており、数百メガバイトから数ギガバイトに達することもあります。そのため、本番環境でのコンテナのコールドスタートには数分かかることが多く、スケーリング時にはクラスター内のネットワーク輻輳により、レジストリからイメージを迅速にダウンロードできなくなります。

たとえば、ある年のダブル 11 ショッピングフェスティバルでは、Alibaba のあるアプリケーションがキャパシティ不足により緊急スケーリングを行いましたが、過度な同時実行により全体の展開に時間がかかり、一部のユーザー体験に影響を及ぼしました。2019 年に DADI のデプロイと導入により、新しいイメージ形式のコンテナは「イメージプル + コンテナ起動」の合計時間が従来のコンテナの 5 分の 1 に短縮され、p99 のロングテールレイテンシは 17 倍高速化されました。

リモートに保存されたイメージデータをどのように扱うかが、コンテナのコールドスタートが遅い問題を解決する核心です。これまで業界では、ブロックストレージや NAS を使用してコンテナイメージを保存し、オンデマンド読み取りを実現する方法でこの問題の解決を試みてきました。また、P2P などのネットワークベースの配信技術を使用して、複数ソースからイメージをダウンロードしたり、事前にホストにウォーミングアップしたりすることで、単一のネットワークボトルネックを回避する方法もあります。近年、新しいイメージ形式に関する議論が徐々に本格化しています。Harter らの研究 [2] によると、イメージプルがコンテナ起動時間の 76% を占めるのに対し、実際のデータ読み取りにはわずか 6.4% しか費やされていません。したがって、オンデマンド読み取り技術をサポートするイメージが標準的なトレンドとなっています。Google が提案した stargz [3] 形式は、正式名称を Seekable tar.gz といい、その名の通り、アーカイブ全体をスキャンまたは解凍することなく、特定のファイルを選択的に検索および抽出できます。stargz はイメージプルのパフォーマンス向上を目的として設計されています。lazy pull 技術により、イメージファイル全体をプルせず、オンデマンド読み取りを実現します。さらに、ランタイム効率を向上させるため、stargz は containerd スナップシャットプラグインも提供し、ストレージレイヤーでの I/O をさらに最適化しました。

コンテナのライフサイクルにおいて、イメージは準備完了後にマウントする必要があります。階層型イメージマウントの核心技術は overlay fs で、複数の下位レイヤーファイルをスタック形式で結合し、上位に統一された読み取り専用ファイルシステムを公開します。前述のブロックストレージや NAS と同様に、一般的にレイヤーごとにスナップショット形式でスタックでき、stargz とセットの CRFS も overlay fs のもう一つの実装と見なせます。

新しいイメージ形式

DADI は overlay fs を直接使用するのではなく、overlay fs と初期のユニオンファイルシステムのアイデアを参考にしつつ、新しいブロックベースの階層スタッキング技術を提案しました。これが overlay bd と呼ばれるもので、コンテナイメージ向けにブロックベースの統合データビューを一系列提供します。overlaybd の実装は非常にシンプルであり、これまでは実現したくてもできなかった多くのことが現実のものとなります。一方で、完全に POSIX 準拠のファイルシステムインターフェイスを実装することは挑戦に満ちており、バグが含まれる可能性もあります。これは各主流ファイルシステムの開発の歴史から見ても明らかです。

シンプルさ以外に、overlaybd が overlay fs に比べて持つ利点は以下の通りです。

• マルチレイヤーイメージングによるパフォーマンス低下を回避します。たとえば、overlay fs モードでは大きなファイルの更新によりクロスレイヤーの参照複製が発生し、システムはまずファイルを書き込み可能レイヤーにコピーする必要があります。また、ハードリンクの作成速度が遅いという問題もあります

• ブロックレベルの I/O パターンを簡単に収集して記録・再生できるため、データのプリフェッチによる起動のさらなる高速化が可能です

• ユーザーのファイルシステムやホスト OS を柔軟に選択でき、たとえば Windows NTFS のサポートも可能です

• 効率的なコーデックを使用してオンライン解凍を実行できます

• クラウド上の分散ストレージ (EBS など) にオフロードでき、イメージシステムディスクをデータディスクと同じストレージ方式で使用できます

• Overlaybd は書き込み可能レイヤー (RW) をネイティブでサポートしており、読み取り専用マウントは過去のものとなる可能性があります

Overlaybd の原理

overlay bd の原理を理解するには、まずコンテナイメージの階層メカニズムを理解する必要があります。コンテナイメージは複数の差分レイヤーファイルで構成されており、使用時にこれらが重ね合わされるため、イメージ配布時にはレイヤーファイルのみを配布すればよくなります。各レイヤーは、前のレイヤーからの差分 (ファイルの追加、変更、削除を含む) を格納した圧縮パッケージです。コンテナエンジンはストレージドライバーを通じて、約束された方法で差分をスタックし、読み取り専用モードで指定ディレクトリにマウントします。これを lower_dir と呼びます。読み書き可能モードでマウントされる書き込み可能レイヤーのマウントディレクトリは、一般的に upper_dir と呼ばれます。

注意点として、overlaybd 自体にはファイルという概念はありません。イメージを仮想ブロックデバイスとして抽象化し、その上に通常のファイルシステムをマウントするだけです。ユーザーがデータの読み取りを要求すると、まず従来のファイルシステムが読み取りリクエストを処理し、そのリクエストを仮想ブロックデバイスの 1 つ以上の読み取りに変換します。これらの読み取りリクエストは、ユーザーモードの受信プログラム、つまり overlaybd のランタイムキャリアに転送され、最終的に 1 つ以上のレイヤーへのランダム読み取りに変換されます。

従来のイメージと同様に、overlaybd もレイヤーの階層構造を保持していますが、各レイヤーの内容はファイルシステムの変更差分に対応する一連のデータブロックです。Overlaybd は上位に統合ビューを提供します。レイヤーのスタッキングルールは非常にシンプルで、任意のデータブロックについて最後の変更が常に使用され、レイヤー内で変更されていないブロックはすべてゼロブロックとして扱われます。また、一連のデータブロックをレイヤーファイルとしてエクスポートする機能も提供しており、高密度、非スパース、インデックス可能な形式です。そのため、ブロックデバイスの連続した LBA 範囲への読み取り操作には、複数のレイヤーに由来する小さなデータセグメントが含まれる場合があります。これらの小さなデータセグメントをセグメントと呼びます。セグメントの属性からレイヤー番号を特定し、そのレイヤーのレイヤーファイルの読み取りに引き続きマッピングできます。従来のコンテナイメージはレイヤーファイルをレジストリやオブジェクトストレージに保存できます。overlaybd イメージも同様に使用できます。

互換性を高めるため、overlaybd はレイヤーファイルの最外層に tar ファイルのヘッダーとフッターをラップし、tar ファイルとして偽装しています。tar 内には 1 つのファイルしかないため、オンデマンド読み取りには影響しません。現在、docker、containerd、buildkit はいずれもデフォルトでイメージのダウンロードまたはアップロード時に untar および tar の処理を行います。非侵入型のコード修正は避けられません。そのため、tar の偽装を追加することは、互換性とプロセスの統一に有利です。たとえば、イメージ変換、ビルド、またはフルダウンロード時にコードを修正する必要がなく、プラグインを提供するだけで済みます。

全体アーキテクチャ

DADI の全体アーキテクチャを下図に示します。各コンポーネントについて個別に説明します。

containerd スナップショッター

Containerd はバージョン 1.4 からリモートイメージ起動の一部機能をサポートしており、k8s は Docker をランタイムとして公式に廃止しました。そのため、DADI のオープンソース版はまず containerd エコシステムを優先的にサポートし、その後に Docker をサポートする方針です。

スナップショットのコア機能は、コンテナ rootfs のマウントおよびアンマウント操作に使用される抽象サービスインターフェイスを実装することです。この設計は Docker の初期バージョンにあった graphdriver モジュールを置き換えるもので、ストレージドライバーを簡素化しつつ、ブロックデバイスのスナップショットと overlay fs の両方に対応しています。

DADI が提供する overlaybd-snapshot により、コンテナエンジンは新しい overlaybd 形式のイメージをサポートできるようになります。すなわち、仮想ブロックデバイスを対応ディレクトリにマウントします。同時に、従来の OCI tar 形式イメージとも互換性があり、ユーザーは overlay fs で通常のコンテナを継続して実行できます。

iSCSI ターゲット

iSCSI は広くサポートされているリモートブロックデバイスプロトコルです。安定性、成熟度、高性能を備え、障害からの復旧も可能です。overlaybd モジュールは iSCSI プロトコルのバックエンドストレージとして使用されます。プログラムが予期せずクラッシュした場合でも、再度起動することで復旧できます。ただし、stargz のようなファイルシステムベースのイメージアクセラレーション方式ではこのような復旧はできません。

iSCSI ターゲットは overlaybd のランタイムキャリアです。本プロジェクトでは、2 つのターゲットモジュールを実装しています。1 つ目はオープンソースプロジェクト tgt [4] をベースにしたもので、バッキングストアメカニズムを持つため、コードを動的リンクライブラリとしてコンパイルし、ランタイムでロードできます。2 つ目は Linux カーネルベースの LIO SCSI ターゲット (TCMU) [5] です。ターゲット全体がカーネルモードで動作し、仮想ブロックデバイスを簡単に出力できます。

ZFile

ZFile はオンライン解凍をサポートするデータ圧縮形式です。固定サイズのブロックごとにソースファイルを分割し、各データブロックを個別に圧縮し、ジャンプテーブルを維持して各データブロックの ZFile 内での物理オフセット位置を記録します。ZFile からデータを読み取る場合は、インデックスを検索して対応する位置を特定し、関連するデータブロックを解凍するだけです。

ZFile は lz4、zstd など多様な効率的な圧縮アルゴリズムをサポートしており、極めて高速な解凍速度と低いコストで、ストレージ容量とデータ転送を効果的に節約できます。実験データによると、リモートの ZFile データをオンデマンドで解凍するパフォーマンスは、非圧縮データを読み込む場合よりも優れています。転送によって節約される時間が解凍の追加コストを上回るためです。

Overlaybd はレイヤーファイルを ZFile 形式でエクスポートすることをサポートしています。

キャッシュ

前述の通り、レイヤーファイルはレジストリに保存されており、コンテナのブロックデバイスへの読み取り I/O はレジストリへのリクエストにマッピングされます (ここでレジストリの HTTP Partial Content サポートを利用します)。ただし、キャッシュメカニズムの存在により、常にそうなるわけではありません。キャッシュはコンテナ起動後しばらくすると自動的にレイヤーファイルをダウンロードし、ローカルファイルシステムに永続化します。キャッシュヒットした場合、読み取り I/O はレジストリに送信されず、ローカルで読み取られます。

業界をリードする

2021 年 3 月 25 日、権威あるコンサルティング会社 Forrester は 2021 年第 1 四半期の FaaS プラットフォーム (Function-As-A-Service Platforms) 評価レポートを発表しました。Alibaba Cloud は製品能力で世界首位という優位性により頭角を現し、8 つの評価項目で最高スコアを獲得して、Amazon AWS と並ぶグローバルな FaaS リーダーとなりました。これは、中国のテクノロジー企業が FaaS リーダークアドラントに入った初めての事例でもあります。

よく知られているように、コンテナは FaaS プラットフォームの基盤であり、コンテナ起動速度はプラットフォーム全体のパフォーマンスと応答遅延を左右します。DADI は Alibaba Cloud の Function Compute 製品を支え、コンテナ起動時間を 50% から 80% 短縮し [6]、新しいサーバーレス体験をもたらしています。

まとめと展望

Alibaba のオープンソース DADI コンテナアクセラレーションプロジェクトとその overlaybd イメージ形式は、新時代におけるコンテナの高速起動ニーズに対応します。今後、プロジェクトチームはコミュニティと協力して主流ツールチェーンとの統合を加速し、新しいイメージ形式規格の策定に積極的に参加する予定です。overlaybd を OCI リモートイメージ形式の標準規格の一つにすることを目標としています。