Alibaba Cloud FaaS Architecture Design

1、ECS ベースの FaaS

Alibaba Cloud の従来のアーキテクチャでは、ユーザーはインターネットを通じてロードバランシングシステムにアクセスし、その後ロードバランシングを通じてシステムリクエストを異なるマシンにスケジューリングします。この従来のアーキテクチャは多くの問題を抱えています。一方では、複数のアプリケーションの比率が容易に不均衡になり、リソースの無駄を引き起こします。他方では、イメージのアップグレードが比較的煩雑で、プロセス全体の起動速度は分レベルであり、拡張速度も比較的遅いです。

(1) アーキテクチャ設計

ECS ベースの FaaS アーキテクチャ設計もインターネットを通じてアクセスされ、SLB 負荷分散にフォールバックします。SLB 負荷分散は、主に DDoS 攻撃に耐え、複数の API へのリクエストを分散するために Alibaba Cloud 内部にデプロイされたシステムです。API サーバーは関数の CRUD 操作を開始し、スケジューラにコンテナを申請します。

スケジューラはワーカー内のコンテナの配置を管理し、コンテナ上にフォールバックするリクエストのスケジューリングされた配信を要求します。ユーザーのワーカーは、私たちがコンピューティングノードと呼ぶものです。ユーザーの VPC 環境にアクセスする必要がある場合は、コンピューティングノード上の ENI ネットワークカードを通じてユーザーの VPC 環境に接続できます。

(2) マルチテナントおよびマルチアプリケーションデプロイメントのサポート

名前空間は、Linux が数年前に導入したリソース分離スキームです。カーネルレベルでいくつかの設定を行い、一部のプロセスを固定指定できます。そして、cgroup 設定のこのセットでリソースアクセスを制御するように設定できます。名前空間と cgroup の完全なセットの下で、コンテナが派生しました。コミュニティで一般的に使用される Docker スキームは、イメージオペレーティングシステム内の多くの詳細を単一のスキームにパッケージ化します。ユーザーは比較的完全なオペレーティングシステムを表示し、ユーザーを単一のユーザーとして仮想マシンに配置します。これは VM であり、ECS に相当します。これはオペレーティングシステムレベルです。これは CPU、メモリ、デバイス全体をシールドし、cgroup レイヤーで封印し、Docker コンテナに対応させます。

アプリケーション配置戦略には、ユーザー専用仮想マシン、VPC 専用仮想マシン、および同じマシン上で同じリソースアクセス権限を持つ APP の混合が含まれます。2 つの異なるユーザーを同じ VM、つまり ECS の下で混合することは、ユーザーにとってリスクをもたらします。カーネルの共有によって提示されるリスクをシールドするために、単一の ECS 実装に対して 1 つのテナントのみを持ちます。このアプローチにはいくつかの問題もあり、最も目立つのは低頻度の関数呼び出しのためのリソースの低い使用率です。

(3) 高速な水平弾力拡張

水平弾力拡張を実現する方法は？

① アプリケーションコンテナデプロイメントを通じて、いくつかの特別な言語、ランタイムコンテナ、および汎用 LIB/SDK をカスタマイズし、一貫したコミュニティエコシステムを維持できます。これにより、追加のダウンロードが不要になり、ユーザーがより簡単に使用でき、非常に高速な起動が可能になります。

② 公共コンテナイメージを設定し、コンテナイメージを ECS イメージに書き込み、ECS イメージでマシンを起動し、マシンプールを迅速に補充することで、マシンリソースプールを制御でき、パフォーマンスとコストの両方を実現できます。

③ プールされたマシンでは、プールされたコンテナの作成、コードディレクトリの遅延マウント、ランタイムの早期起動、および早期ヘルスチェックにより、ユーザーリクエストが到着したときに起動に必要な時間を短くできます。

④ ユーザーアプリケーションサイズの制限、ビジネスロジックの分割、および組み込み SDK/Lib によるアプリケーションサイズの制御。

⑤ P2P イメージ配信を通じて P2P イメージダウンロードアクセラレーションが実現され、ダウンロードサービスへの影響を回避し、オンデマンドロードによりダウンロードレイテンシを削減し、起動速度を向上させます。

リソース使用率を向上させる方法

実際の研究開発プロセスでは、同じ QPS での時間スライス単位のスケジューリングがリソース量に大きな影響を与えることがわかり、スケジューリングを通じてリソース使用率を向上させることができます。たとえば、下の図では、マクロ状態での全体的な TPS が非常に安定していることがわかります。しかし、実際にはミリ秒レベルに拡大すると、実際には非常に不均一であることがわかります。では、この不均一性は私たちにどのような影響を与えるでしょうか？

各コンテナに設定された最大同時実行数が 1 であると仮定しましょう。つまり、1 つのコンテナはいつでも 1 つのタスクのみを処理できます。次の図は、a、b、c、d、e、f の複数のリクエストが異なる时间点でスケジューリングされる場合のコンテナ数への影響を示しています。

シナリオ 1 では、各リクエストが均一に入力される場合、いつでも 1 つのコンテナのみが必要であり、これが私たちが理想的に達成したいものです。

シナリオ 2 では、スケジューリングの遅延がある場合、前のリクエストと後のリクエストが特定の时间点で混合され、コンテナ数が倍増する可能性があります。中間のギャップでは、これらのコンテナは完全に活用されておらず、リソースの無駄が発生します。

シナリオ 3 では、コンテナの起動時間が長いか、呼び出し時間が長い場合、元のリクエスト b とリクエスト a が発生時間で重なり、新しいコンテナを作成する必要が生じます。新しいコンテナが長いコールドスタートを必要とする場合、リクエスト c と発生時間で重なることもあります。スケジューリングシステムが十分に実装されていない場合、雪崩効果を引き起こし、リソース使用の急増を引き起こす可能性がありますが、実際の使用率は非常に低いです。

上記のシナリオを通じて、リソース使用率のコストの最適化方向を要約できます。

1. スケジューリングをできるだけ均等で合理的にし、クラスタリングを避けてコンテナを起動する

2. コールドスタート時間をできるだけ短縮し、短期間で大量のコンテナを作成せず、意味のないシステムスケジューリングオーバーヘッドを避ける

上記に加えて、スタンドアロンコンピューターのリソース使用率を向上させるために高密度デプロイメントを検討することもできます

災害に耐え、雪崩を防ぐ方法

実際の操作で例外が発生すると、ユーザーリクエストがエラーを起こす可能性があり、エラー後に再起動したり、新しいリソースを動員して新しいコンテナを作成したりする可能性がありますが、これにより遅延全体が増加します。ユーザーは何度も再試行し、再試行を繰り返すと負荷が増加し、それが逆に例外を引き起こし、悪循環に陥ります。起動速度の最適化、マルチパーティションディザスタリカバリデプロイメント、エクスポネンシャルバックオフ再試行、サーキットブレーカーによる異常リクエストのブロック、複数のアベイラビリティゾーンディザスタリカバリ、および SLB による DDoS 攻撃のブロックを通じて雪崩を防ぐことができます。

2、DPCA 高密度デプロイメントに基づく FaaS

(1) 高密度デプロイメントが必要な理由

まず、弾力的な起動速度に対する高い要件により、秒あたり 10,000 コンテナインスタンスを起動できることが望まれ、起動遅延は 300 ミリ秒以内に制御され、コンテナのライフタイムは分レベルであり、リソースの粒度は 128 MB です。

第二に、コストが低いことです。ECS アーキテクチャのセキュリティ分離の問題により、多くのリソースフラグメントがあり、突発的な呼び出しの遅延が高く、リソース数に影響を与えます。

第三にパフォーマンスです。ECS にはスタンドアロンキャッシュが少なく、リクエストバースト率が高く、最大リクエストレイテンシが高いです。

第四に、安定性、システムへの高同時実行インパクト、リソースの頻繁な作成と削除、および ECS 制御圧力により、爆発半径を制御することが困難です。

(2) 高密度デプロイメントアーキテクチャによってもたらされる技術的課題

高密度デプロイメントアーキテクチャ全体によって提示されるいくつかの技術的課題：

最初に取り組むべきは、スタンドアロンマルチテナンシーの分離のセキュリティリスクを解決する方法です。この問題が解決されない場合、スタンドアロンマルチテナンシーの安全で高密度なデプロイメントを実現できず、リソース使用密度を効果的に向上させることはできません。

第二に、高同時実行起動速度の問題を解決する方法です。これが実現できない場合、前述のように、長いコールドスタート時間はリソースオーバーヘッドを深刻に増加させ、ユーザーの遅延体験に深刻な影響を与えます。

スタンドアロンマルチテナント VPC ネットワーク接続とセキュリティの問題を解決する方法は実際に非常に重要です。ECS ソリューションでの ENI ネットワークカードの接続と切り離しには非常に時間がかかり、少なくとも 2〜3 秒かかり、P99 は 6〜8 秒に達することもあります。DPCA の高密度デプロイメントでは、各セキュリティコンテナに対して複数のネットワークカードプラグインを実行する必要はありません。代わりに、DPCA マシン上でゲートウェイエージェントに均一に接続する必要があり、ユーザー ENI ネットワークカードはゲートウェイクラスター上に常駐します。これにより、ネットワークカード全体のロードがより高速になります。これは、ユーザー体験とリソースオーバーヘッドの両方にとって大きな最適化になります。

さらに、高密度デプロイメントの技術的ディザスタリカバリソリューションを設計する方法も検討する必要があります。なぜなら、1 つのコンピューティングノードの例外が多数のユーザーのサービス例外を引き起こす可能性があるからです。

(3) セキュアコンテナテンプレート技術に基づく最適化

セキュアコンテナテンプレート技術に基づいて最適化を実現する方法は？各コンテナには専用仮想マシンサンドボックスがあり、独立した Linux カーネルを持つ独立した仮想マシンに相当します。これにより、各コンテナは独立したカーネルを通じて安全に分離されます。DPCA 起動時に、大量の仮想マシンがテンプレート化され、起動速度が向上します。virtiofs を通じてユーザーコードディレクトリのマウントを遅延し、仮想マシンマイクロカーネルを通じてユーザーを分離することで、シングルマシンあたりマイクロカーネルあたり約 20 メガバイトのメモリを実現でき、シングルマシンあたり少なくとも 2,000 のコンテナを実現でき、コールドスタート時間を約 250 ミリ秒に制御できます。スケジューリングアルゴリズムを通じて、リソースを合理的に使用し、ユーザーのリソースクォータにコミットできます。

(4) コードのオンデマンドロード

コードのオンデマンドロードは、以下の側面を通じて実現されます。ユーザーコンテナは同じコードを再利用し、単一の DPCA は 1 回だけダウンロードする必要があります。スクリプト言語には使用できない大量のコードが含まれています。FUSE (ユーザー空間ファイルシステム) を使用して中間層ファイルのリアル読み取りを行います。基盤層では NAS が低レイテンシデータダウンロードに使用されます。OSS (Alibaba Cloud Object Storage) は高い帯域幅サポートを持つデータダウンロードを提供します。NAS と OSS の混合を使用してコードをロードすることに注意してください。NAS のアクセスレイテンシが比較的-lowく、小さなファイルのロードが高速であることに注意する必要があります。ロードの初期段階で OSS から非同期的にコードの完全ダウンロードを開始しました。すぐにアクセスする必要があるデータについては、NAS から読み取ります。ユーザーコードディレクトリ全体を 2 つのファイルにしたためです。1 つはディレクトリファイルインデックスデータで、もう 1 つはファイルコンテンツデータです。NAS アクセスの低レイテンシにより、GetRange と同様の方法でデータファイルから小さなファイルコンテンツを取得できます。これにより、最速の速度でユーザーコードを即座にロードし、高速なコールドスタートを実現できます。

(5) VPC ネットワーク最適化

ネットワークサービスグリッドに基づく VPC ゲートウェイエージェントは、ユーザー VPC ネットワークセキュリティを通じて分離されます。以前は、ECS ソリューションで ENI ネットワークカードのプラグインとプラグ解除に非常に時間がかかり、少なくとも 2〜3 秒かかり、P99 は 6〜8 秒に達することもありました。DPCA の高密度デプロイメントでは、各セキュリティコンテナに対して複数のネットワークカードプラグインを実行する必要はありません。代わりに、DPCA マシン上でゲートウェイエージェントに均一に接続する必要があり、ユーザー ENI ネットワークカードはゲートウェイクラスター上に常駐します。これにより、ネットワークカード全体のロードがより高速になります。これは、ユーザー体験とリソースオーバーヘッドの両方にとって大きな最適化になります。

(6) リソース割り当て率

さまざまなタイプのマルチテナントビジネスの混合デプロイメントを通じてデプロイメント密度を向上させ、異なるリソース要件を持つコンテナを物理サーバーに合理的にマッチングさせることで、リソース割り当て率を向上させます。

3、まとめ

講師プロフィール：Zhu Peng、Alibaba Cloud サーバーレス技術エキスパート

Alibaba Cloud の関数コンピューティングスケジューリングの設計と開発を担当し、高同時実行、技術的ディザスタリカバリ、コールドスタート最適化、スケジューリングリソース管理、DPCA ベアメタル技術アーキテクチャを含む複数の方向で関数コンピューティングの設計、開発、実装に参加しました。Alibaba Cloud の関数コンピューティングの DPCA 高密度デプロイメントアーキテクチャの主導的促進者の 1 人です。現在、主にリソース使用率の向上、大規模同時実行の低レイテンシリソーススケジューリングソリューションの研究と設計にコミットしています。