2019年VPC Lambdaが高速に！！ AWS Lambdaの内部構造に迫るセッション「SRV409 A Serverless Journey: AWS Lambda Under the Hood」 #reinvent

2019年にVPC Lambdaが高速化されるそうです！！

AWS re:Invent 2018

#サーバーレス

#AWS Lambda

#AWS

岩田智哉

2018.12.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

サーバーレス開発部＠大阪の岩田です。 re:Invent2018が終了して約3週間、今では各セッションの動画やスライドが多数公開されており、気軽に情報収集ができるようになりました。

私もYoutubeを活用して、現地で参加できなかったセッションの動画を少しづつ視聴していたのですが、　「SRV409 A Serverless Journey: AWS Lambda Under the Hood」の内容が非常に興味深いものでした。

サーバーレス開発部が普段ゴリゴリに触っているAWS Lambda(以後は単にLambdaと表記します)の内部構造に言及しており、2019年にVPC Lambdaが高速化されるという情報も知る事ができました。このセッションの内容を多くの人に知ってもらいたいので、Lambdaの内部構造という観点からセッションの内容をまとめてみます。 ※直訳というよりも自分なりのまとめです。また、Lambdaの内部構造に関係無い話は省略しています。

なお、筆者の英語スキルは低いです。頑張ってまとめたたつもりですが、もし誤訳や認識違いがあれば指摘頂けると幸いです。

資料

まずセッションの資料です。英語がバリバリな方はセッション動画だけ見ておけばOKかと思います。

セッション動画

スライド

ここから個人的な見解を元にセッションの内容をまとめていきます。

Lambdaのコンポーネント

Lambdaのコンポーネントは大きく下記のように分類されます。

Control Plane
- Developer Tools
  - Lambda Console
  - SAM CLI
- Control Plane APIs
  - Configuration
  - Resource Mgmt(Management)
Data Plane
- Synchronous Invoke
  - Front End Invoke
  - Counting Service
  - Worker Manager
  - Worker
  - Placement Service
- Asynchronous Invoke & Events
  - Pollers
  - State Manager
  - Leasing Service

Control Plane

Control Planeは開発者とLambdaのとやり取りを仲介するためのコンポーネントで、Developer ToolsとControl Plane APIsに大別されます。 Developer Toolsは開発者向けの各種ツールの事で、Lambda ConsoleやSAM CLIが該当します。

Control Plane APIsは、Lambdaの設定を行うためのConfiguration APIとリソース管理を行うためのResource Mgmt(Management) APIに分かれます。例えばリソース管理APIではユーザーが作成したコードをパッケージングし、Lambdaサービスへのアップロードと配置を行います。

Data Plane

Data PlaneはさらにSynchronous Invoke(同期呼び出し)とAsynchronous Invoke & Events(非同期呼び出しとイベント)に分類されます。

Asynchronous Invoke & EventsはDynamoDBやKinesis、SQSといったサービスとの相互連携を行う一連のコンポーネント群です。前述のAWSサービスのイベントが処理されると、Synchronous Invoke(同期呼び出し)のエリアに引き渡されます。 ※ここの一連のコンポーネント(Pollers,State Manager,Leasing Serviceの説明は特に無かったようです)

Synchronous Invokeはこのセッションで重点的に説明されていたコンポーネント群です。

Front End Invoke
Counting Service
Worker Manager
Worker
Placement Service

5つのコンポーネントから構成されます。

Front End Invoke

このコンポーネントは同期呼び出しと非同期呼び出し両方に対するオーケストレーションの責務を持ちます。このコンポーネントが呼び出し元の認証を行い、妥当な呼び出しの場合だけLambda Functionの実行を許可します。認証できた場合は、Control Plane APIを介して環境変数やメモリの割当やタイムアウトといったLambda Functionのメタデータをロードします。

次にCounting Serviceと連携して呼び出しの並列度をチェックします。並列度が閾値を超えていない場合は対象のFunctionをWorker Managerに割り当てます。並列度が閾値を超えている場合はWorker Managerをスケールアップさせます。 Worker Managerがスケールアップする事でWorkerもスケールアップされ、負荷分散が実現されます。

Counting Service

このコンポーネントは同時実行性に関するリージョンワイドなビューを提供し、Lambdaの同時実行数の制限を行う責務を持っています。このコンポーネントはLambda Functionの同時実行数を常にトラッキングしており、現在の同時実行数が制限値を下回っている場合はLambda Functionの呼び出しを許可し、制限値を上回っている場合はスロットリングを発生させる可能性があります。

このコンポーネントはLambda Functionの実行毎に呼び出されるため、1.5ミリ秒未満の低レイテンシで高いスループットを実現するように設計されています。また、このコンポーネントは重要なコンポーネントなので、複数のAZに分散して配置されています。

Worker Manager

このコンポーネントはコンテナの状態(アイドル・ビジー)をトラッキングしており、使用可能なコンテナにコードの実行要求をスケジューリングし、環境変数のセットアップやLambda実行ロールの設定などを行います。

Lambda実行ロールに正しい権限が設定されており、かつコンテナが利用できない場合は、Placement Serviceを通じてWorkerのスケールアップを制御します。

Worker

このコンポーネントはLambdaのアーキテクチャーにおいて非常に重要なコンポーネントです。ユーザーのコードを実行するためのセキュアな環境=サンドボックス環境のプロビジョニングを担当しており、メモリやCPU等のリミットを設定したサンドボックス環境を作成、管理します。 Workerの責務としては以下のような処理が挙げられます。

Lambdaのコードをダウンロードし、実行するためにサンドボックス環境にマウントする
複数の言語ランタイムを管理する
顧客のコードの初期化と実行を行う
CloudWatchなどのAWSが管理するモニタリング用のエージェントを管理する
サンドボックス環境内でコードの実行が完了した際にWorker Managerへの通知を行う

Placement Service

このコンポーネントはWorker上に構築されたサンドボックス環境の配置を最適化するコンポーネントです。顧客体験やレイテンシへの影響を与えることなく、サンドボックス環境の密度が最大限になるように配置を行います。

このコンポーネントはWorkerの監視も行なっており、Workerの異常を検出すると対象のWorkerを異常(unhealthy)としてマークします。

Lambdaのコンポーネントがどのように負荷分散を実現しているか

ここからは各コンポーネントの役割を踏まえた上で、具体的なユースケースを見て行きます。 Lambdaは

Workerがプロビジョニング済みか
サンドボックス環境がプロビジョニング済みか

によって、いくつかの動作モードを持ちます。

シナリオ1 Workerはプロビジョニングされているが、新しいサンドボックス環境が必要な場合

このシナリオのフローはざっくり下記の通りです

顧客がALBにリクエストを行う
ALBは配下のFront End Invoke(冗長構成になっている)にリクエストを流す
Front End Invokeは呼び出し元を認証し、呼び出し対象Functionのメタデータを取得する
Front End Invokeは取得したメタデータを使用してCounting Serviceと連携してFunctionの同時実行数をチェックする
Front End InvokeがWorker Managerにサンドボックス環境の予約をリクエストする
Worker ManagerはWorker上にLambdaのコードをダウンロードしてランタイムの初期化と、コードの初期処理(カスタムレイヤーで言うところのbootstrapに該当すると思われます)を実行してサンドボックス環境を構築する。サンドボックス環境が構築できたら、WorkerはWorker Managerに対してサンドボックス環境の構築が完了したことを通知する。
Worker ManagerはFront End Invokeに対してコードの実行準備が完了したことを通知する
Front End InvokeがWorkerにコードの実行を要求する
Worker上でコードが実行され、コード実行に関する各種メトリクスが収集された後、Workerは自身がアイドル状態に遷移したことをWorker Managerに通知する。以後Woker Managerはサンドボックス環境が準備済みであることを認識する。

シナリオ2 Workerもサンドボックス環境もプロビジョニングされている場合

〜略
Front End InvokeがWorker Managerにサンドボックス環境の予約をリクエストする
Worker Managerは準備済みのサンドボックス環境(Warmサンドボックス)が存在することを応答する
Front End InvokeがWorkerにコードの実行を要求する
〜略

基本的にはシナリオ1と同じフローで、Front End InvokeがWorker Managerにサンドボックス環境の予約をリクエストした後のフローが変わります。 Lambdaの実行パターンのほぼ全てはこのモードとのことです。

LambdaのコンポーネントがどのようにAuto Scalingを実現しているか

次はAuto Scalingのフローです。

前述のシナリオ1と最初の流れは同様です。

〜略
Front End InvokeがWorker Managerにサンドボックス環境の予約をリクエストする
Worker ManagerがWorkerとサンドボックス環境を所有していない場合、Front End Invokeに対してWorkerとサンドボックス環境が無いことを応答する
Worker ManagerはPlacement ServiceにWorkerを要求する
Placement ServiceはWorkerをプロビジョニングするための適切な場所を探してWorkerをプロビジョニングし、Workerを配置した場所をWoker Managerに応答する
Worker ManagerはWorker上にサンドボックス環境を作成する※以後前述のシナリオと同様の流れ

Placement Serviceについての補足

Placement ServiceはWorker Managerからの要求を達成するために十分なWorkerを確保する責務を持っており、Worker Managerに対してWorkerを6~10時間の間リースします。

Workerがリース期間の満了に近づくと、Worker Managerは全てのサンドボックス環境がアイドル状態になるように、サンドボックス環境の予約を停止します。全てのサンドボックス環境がアイドル状態になると、Worker ManagerはPlacement ServiceにWorkerを返却します。

Lambdaのコンポーネントがどのように障害に対応しているか

障害は常に発生し得るもので、Lambdaはホスト単位の障害やAZ単位の障害に対応できるようにデザインされています。

Lambdaのコンポーネントは複数のAZをまたいで構成されており、前述の負荷分散・冗長構成に加えて、ホストのヘルスチェックを行なっている。ヘルスチェックに失敗したホストはLambdaの環境から除去される。
Workerが異常(unhaelthy状態)になった場合は、Workaer Managerが異常を検出してサンドボックスのプロビジョニングを停止する。
AZ単位で障害が発生した場合、障害が発生したAZにはトラフィックを流さないようにしてLambdaのコンポーネントは引き続き実行される。

Workerの詳細について

ここからさらにWorkerについて深掘りしていきます。

Isolation(環境の分離)

Lambdaというサービスは複数のLambda　Functionを同一のハードウェア上で実行しています。これらのLambda Functionはセキュリティと操作上の観点から環境を分離することが重要です。

Lambdaというサービスのレイヤーはこのような構成になっています。

Lambda RuntimeのレイヤーはJava,Node.js,Pythonといった言語のランタイム
ゲストOSはAmazonLinuxを実行している
サンドボックス環境内のランタイムは1つのLambdaFunctionでのみ利用される
Lambdaを複数回呼び出すと、同じサンドボックス環境内で直列に実行される。スケールアップすることはあるが、1つのサンドボックス環境が複数のLambda Functionで利用されることは無い
ゲストOSは同一AWSアカウントの複数のLambda Functionで共有されることがあるが、同一のゲストOSを複数のAWSアカウントが共有することは無い。
AWSアカウント間の境界は仮想化レイヤー

サンドボックスレイヤーではコンテナ型の仮想化と同じ技術を用いてサンドボックス環境間の環境分離を実現しています。

利用しているLinuxカーネルの機能は下記の通りです。

cgroups サンドボックス環境へのリソース(メモリ、CPU、ディスクスループット)の割り当てをコントロールします
namespaces プロセス間でリソースの分離を行う同じホスト上で複数のサンドボックス環境が稼働していう場合でも、それぞれのサンドボックス環境から見たLambda FunctionのプロセスIDは常に1に見えます。
seccomp カーネルのための一種のファイヤーウォールのような機能で、プロセスから発行可能なシステムコールを制限することが可能です。Lambdaから発行可能なシステムコールは必要最低限に制限されています
iptables ネットワークの隔離機能を提供します
chroot ファイルシステムの隔離機能を提供します

LambdaのWorkerをビルドする方法について

現在、LambdaのWorkerをビルドする方法は2種類あります

EC2インスタンス上にWorkerを構築する方法

AWSがLambdaのサービスを開始した時から利用されているモデルで、この方法は今でも利用されています。このモデルでは複数のAWSアカウント間の環境分離はゲストOSレベルで実現しています。

Firecrackerを利用する方法

もう1つの方法はFirecrackerを用いる方法です。 Firecrackerを用いる場合は、ベアメタルのEC2インスタンス上で何十万ものEC2のマイクロVMを稼働させ、マイクロVM上にLambdaのサンドボックス環境を構築します。この方法はより柔軟、かつ迅速にサンドボックス環境を分離することが可能です。

このモデルでは複数のAWSアカウント間の環境分離はマイクロVMレベルで実現しています。

デバイスのエミュレーションについて

Firecrackerの上では数十万のマイクロVMが稼働していると言われていますが、実際のハードウェア上には数十万のHDDやネットワークカードは存在しません。しかし、マイクロVMの各ゲストOSはHDDやネットワークカードを認識し、それぞれのユーザー空間からはハードウェアのように見えます。これはデバイスのエミュレーションによって実現されています。

ゲストOS向けのデバイスエミュレーションにはvirtioを利用しています。 virtioはゲストカーネル内のブロックデバイスやネットワークカードを実装するセキュアな方法です。 virtioを使うことでゲストOS<->ホストOS間のやり取りを減らしています。Firecrackerの革新はデバイスエミュレーションが非常に制限されたサンドボックス内で実行されることです。

※virtio周りの知識不足でFirecrackerの有無でvirtioの使い方がどう変わるのかがよく分からず...

Utilization

次のトピックはUtilizationについてです。 Lambdaのシステムはいかにハードウェアリソースの利用量をコントロールしているのでしょうか？

サーバーがビジー状態を保つように調整する

例えば7つのサンドボックス環境がそれぞれリソース使用率60%で稼働するのは無駄です。対して4つのサンドボックスがそれぞれリソース使用率99%で稼働するのは良い状態です。

通常のシステムでは余裕を持った閾値でWorker群をスケールさせて負荷分散を行いますが、Lambdaは少量のサンドボックス環境が全てビジー状態になるように負荷をコントロールします。これはコード実行の観点からは良いことで

キャッシュ
事前計算されたリソース
オープン済みのNW接続
一時ファイル

といったリソースを効率よく利用することができます。理想的な稼働状態はCPUのサイクルは全てコードの実行に利用されており、WorkerのRAMはユーザーデータで埋め尽くされている状態です。

ワークロードの配置について

Placement Serviceはワークロード=Lambda Functionの配置を最適化するように動作します。

同じワークロードを実行するサンドボックス環境のコピー群を1つのサーバー上で動かす構成は良くない構成です。コピー同士のワークロードに相関関係があり、1つのサンドボックス環境でリソースの使用率が跳ね上がったときに、同じワークロードを実行する別サンドボックスのリソース使用率も跳ね上がることになります。こうなるとホストの限られたハードウェアリソースを有効活用できなくなり、1つのハードウェアに詰め込めるサンドボックス環境が少なくなります。