AWS Lambdaの詳細な分析

記事の翻訳はコースの学生向けに特別に用意されました 「クラウドサービス」。 この方向の開発に興味がありますか? Egor Zuev (InBit チームリーダー) によるマスター クラスを視聴する 「AWS EC2サービス」 次のコース グループに参加してください: 26 月 XNUMX 日に始まります。

スケーラビリティ、パフォーマンス、節約、そして毎月数百万、さらには数兆のリクエストを処理する能力を求めて、AWS Lambda に移行する人が増えています。 これを行うには、サービスが実行されるインフラストラクチャを管理する必要はありません。 また、自動スケーリングにより、XNUMX 秒あたり数千の同時リクエストに対応できます。 AWS Lambda は最も人気のある AWS サービスの XNUMX つと言えると思います。

AWSラムダ

AWS Lambda は、サーバーのプロビジョニングや管理を行わずにコードを実行し、カスタム ロジックを使用して他の AWS サービスを拡張できるイベント駆動型のサーバーレス コンピューティング サービスです。 Lambda は、Amazon API Gateway を介した HTTP リクエスト、Amazon S3 バケットまたは Amazon DynamoDB テーブル内のデータの変更などのさまざまなイベント (トリガーと呼ばれます) に自動的に応答します。 または、AWS SDK を使用して API 呼び出しを通じてコードを実行し、AWS Step Functions で状態遷移を実行することもできます。

Lambda は、可用性の高いコンピューティング インフラストラクチャ上でコードを実行し、サーバーとオペレーティング システムのメンテナンス、リソースのプロビジョニング、自動スケーリング、コードの監視、ロギングなど、基盤となるプラットフォームの管理を完全に担当します。 つまり、コードをアップロードし、コードをいつどのように実行するかを設定するだけです。 次に、サービスはその起動を処理し、アプリケーションの高可用性を保証します。

Lambda に切り替えるタイミングはいつですか?

AWS Lambda は、コードの言語とランタイムがサービスでサポートされている限り、さまざまなユースケースに適した便利なコンピューティング プラットフォームです。 サーバーのメンテナンス、プロビジョニング、スケーリングを手頃なコストでアウトソーシングしながら、コードとビジネス ロジックに集中したい場合は、AWS Lambda が最適です。

Lambda はプログラミング インターフェイスの作成に最適であり、API Gateway と組み合わせて使用​​すると、コストを大幅に削減し、より迅速に市場投入できます。 Lambda 関数を使用するさまざまな方法と、サーバーレス アーキテクチャを構成するためのオプションがあり、誰もが自分の目標に基づいて適切なものを選択できます。

Lambda を使用すると、さまざまなタスクを実行できます。 したがって、CloudWatch サポートのおかげで、遅延タスクを作成し、個々のプロセスを自動化できます。 サービスの使用の性質や強度に制限はなく (メモリ消費量と時間が考慮されます)、Lambda に基づいた本格的なマイクロサービスを体系的に作業することを妨げるものはありません。

ここでは、継続的に実行されないサービス指向のアクションを作成できます。 典型的な例は画像のスケーリングです。 分散システムの場合でも、Lambda 関数は依然として関連性があります。

したがって、コンピューティング リソースの割り当てと管理に取り組みたくない場合は、AWS Lambda を試してください。 大量のリソースを大量に消費する計算が必要ない場合は、AWS Lambda も試してください。 コードが定期的に実行される場合は、AWS Lambda を試してください。

セキュリティ

今のところ安全性についての不満はありません。 一方で、このモデルの内部プロセスと実装機能の多くは AWS Lambda マネージド ランタイム環境のユーザーから隠されているため、一般的に受け入れられているクラウド セキュリティのルールの一部は無関係になります。

ほとんどの AWS サービスと同様に、Lambda は AWS と顧客の間で共有されたセキュリティとコンプライアンスに基づいて提供されます。 この原則により、AWS がホスト オペレーティング システムや仮想化レイヤーからインフラストラクチャ資産の物理セキュリティに至るまで、サービス コンポーネントの保守、管理、監視のタスクを引き受けるため、クライアントの運用負担が軽減されます。

特に AWS Lambda について言えば、AWS は基盤となるインフラストラクチャ、関連する基盤となるサービス、オペレーティング システム、およびアプリケーション プラットフォームの管理を担当します。 クライアントはコードのセキュリティ、機密データの保存、そのデータへのアクセスの制御、および使用される機能の制限内での Lambda サービスとリソース (Identity and Access Management、IAM) に対する責任を負います。

以下の図は、AWS Lambda に適用される責任共有モデルを示しています。 AWS の責任はオレンジ色、顧客の責任は青色です。 ご覧のとおり、AWS はサービス上にデプロイされたアプリケーションに対してより多くの責任を負います。

AWS Lambda に適用される責任共有モデル

ラムダランタイム

Lambda の主な利点は、ユーザーに代わって関数を実行することで、サービス自体が必要なリソースを割り当てることです。 システム管理に時間と労力を浪費するのを避け、ビジネス ロジックとコーディングに集中できます。

Lambda サービスは XNUMX つのプレーンに分かれています。 XNUMX つ目はコントロール プレーンです。 Wikipedia によると、コントロール プレーンは、シグナリング トラフィックの転送とルーティングを担当するネットワークの一部です。 これは、ワークロードのプロビジョニング、サービス提供、分散に関するグローバルな決定を行う主要なコンポーネントです。 さらに、コントロール プレーンはソリューション プロバイダーのネットワーク トポロジとして機能し、トラフィックのルーティングと管理を担当します。

XNUMX 番目のプレーンはデータ プレーンです。 コントロール プレーンと同様に、独自のタスクがあります。 コントロールプレーンは、関数 (CreateFunction、UpdateFunctionCode) を管理するための API を提供し、Lambda が他の AWS サービスと通信する方法を制御します。 データプレーンは、Lambda 関数を実行する Invoke API を制御します。 関数が呼び出された後、コントロール プレーンは、その関数用に事前に準備された既存のランタイム環境を割り当てるか選択し、その中でコードを実行します。

AWS Lambda は、Java 8、Python 3.7、Go、NodeJS 8、.NET Core 2 などを含むさまざまなプログラミング言語を、それぞれのランタイム環境を通じてサポートします。 AWS は、これらの環境を定期的に更新し、セキュリティ パッチを配布し、その他のメンテナンス作業を実行します。 Lambda では、適切なランタイムを自分で実装すれば、他の言語も使用できます。 そして、安全性の監視などのメンテナンスを行う必要があります。

すべてはどのように機能し、サービスはどのように機能を実行するのでしょうか?

各関数は XNUMX つ以上の専用環境で実行され、その環境はその関数が存続する間のみ存在し、その後破棄されます。 各環境では一度に XNUMX つの呼び出しのみが行われますが、同じ関数に対して複数のシリアル呼び出しがある場合は、その呼び出しが再利用されます。 すべてのランタイム環境は、ハードウェア仮想化を備えた仮想マシン (いわゆる microVM) 上で実行されます。 各 microVM は特定の AWS アカウントに割り当てられ、そのアカウント内でさまざまな機能を実行するために環境で再利用できます。 MicroVM は、AWS が所有および運営する Lambda Worker ハードウェア プラットフォームの構成要素にパッケージ化されています。 同じランタイムを異なる機能で使用することはできません。また、microVM が異なる AWS アカウントに固有であることもありません。

AWS Lambda 分離モデル

ランタイム環境の分離は、いくつかのメカニズムを使用して実装されます。 各環境の最上位には、次のコンポーネントの個別のコピーがあります。

• 機能コード
• 関数用に選択された任意の Lambda レイヤー
• 関数実行環境
• Amazon Linux に基づく最小限のユーザースペース

異なる実行環境を分離するには、次のメカニズムが使用されます。

• cgroups - 各ランタイム環境の CPU、メモリ、ストレージ、およびネットワーク リソースへのアクセスを制限します。
• ネームスペース - Linux カーネルによって管理されるプロセス ID、ユーザー ID、ネットワーク インターフェイス、およびその他のリソースをグループ化します。 各ランタイムは独自の名前空間で実行されます。
• seccomp-bpf - ランタイムで使用できるシステムコールを制限します。
• iptables とルーティング テーブル - 実行環境を相互に分離します。
• chroot - 基礎となるファイル システムへの限定的なアクセスを提供します。

これらのメカニズムと AWS 独自の分離テクノロジーを組み合わせることで、信頼性の高い実行時の分離が保証されます。 この方法で分離された環境は、他の環境のデータにアクセスしたり、データを変更したりすることはできません。

同じ AWS アカウントの複数のランタイムは 2 つの microVM 上で実行できますが、いかなる状況でも、microVM を異なる AWS アカウント間で共有することはできません。 AWS Lambda は、microVM を分離するために EC2 インスタンスと Firecracker の 2015 つのメカニズムのみを使用します。 EC2018 インスタンスに基づく Lambda でのゲスト分離は XNUMX 年から存在しています。 Firecracker は、サーバーレス ワークロード向けに AWS によって特別に設計され、XNUMX 年に導入された新しいオープンソース ハイパーバイザーです。 microVM を実行する物理ハードウェアは、異なるアカウントのワークロード間で共有されます。

環境とプロセスの状態を保存する

Lambda ランタイムはさまざまな関数に固有ですが、同じ関数を繰り返し呼び出すことができます。つまり、ランタイムは破棄されるまで数時間存続することができます。

各 Lambda ランタイムには、/tmp ディレクトリからアクセスできる書き込み可能なファイル システムもあります。 その内容には他のランタイムからアクセスできません。 プロセス状態の永続性に関する限り、/tmp に書き込まれたファイルは、ランタイム環境のライフサイクル全体にわたって存在します。 これにより、複数の呼び出しの結果を蓄積できるため、機械学習モデルの読み込みなどの高コストの操作に特に役立ちます。

通話データ転送

Invoke API は、イベント モードとリクエスト/レスポンス モードの XNUMX つのモードで使用できます。 イベント モードでは、呼び出しは後で実行するためにキューに追加されます。 リクエスト/レスポンス モードでは、指定されたペイロードを使用して関数が即座に呼び出され、その後応答が返されます。 どちらの場合も、関数は Lambda 環境で実行されますが、ペイロード パスは異なります。

リクエスト/レスポンス呼び出し中に、ペイロードは AWS API Gateway や AWS SDK などのリクエスト処理 API (API 呼び出し元) からロードバランサーに流れ、次に Lambda 呼び出しサービス (サービス呼び出し) に流れます。 後者は、関数を実行するための適切な環境を決定し、そこにペイロードを渡して呼び出しを完了します。 ロード バランサーは、インターネット経由で TLS で保護されたトラフィックを受信します。 Lambda サービス内のトラフィック (ロードバランサーの後) は、特定の AWS リージョンの内部 VPC を通過します。

AWS Lambda 呼び出し処理モデル: リクエスト/レスポンス モード

イベント呼び出しはすぐに行うことも、キューに追加することもできます。 場合によっては、キューは Amazon SQS (Amazon Simple Queue Service) を使用して実装され、内部ポーラー プロセスを通じて呼び出しを Lambda 呼び出しフルフィルメント サービスに渡します。 送信されるトラフィックは TLS によって保護されており、Amazon SQS に保存されているデータに追加の暗号化はありません。

イベント呼び出しは応答を返しません。Lambda ワーカーは応答情報を単に無視します。 Amazon S3、Amazon SNS、CloudWatch、その他のソースからのイベントベースの呼び出しは、Lambda によってイベントモードで処理されます。 Amazon Kinesis および DynamoDB ストリーム、SQS キュー、Application Load Balancer、および API Gateway 呼び出しからの呼び出しは、リクエスト/レスポンス方式で処理されます。

監視

以下を含むさまざまな AWS メカニズムとサービスを使用して、Lambda 関数を監視および監査できます。

アマゾンクラウドウォッチ
リクエストの数、リクエストの継続時間、失敗したリクエストの数などのさまざまな統計を収集します。

アマゾン クラウドトレイル
AWS インフラストラクチャに関連付けられたアカウント アクティビティ情報をログに記録し、継続的に監視し、維持することができます。 AWS マネジメントコンソール、AWS SDK、コマンドラインツール、その他の AWS サービスを使用して実行されたアクションの完全な履歴が得られます。

AWS X 線
内部コンポーネントのマップに基づいて、アプリケーション内のリクエスト処理のすべての段階を完全に可視化します。 開発中および運用環境でアプリケーションを分析できます。

AWSConfig
Lambda 関数の設定 (削除を含む)、ランタイム、タグ、ハンドラー名、コード サイズ、メモリ割り当て、タイムアウト設定、同時実行設定、さらに Lambda IAM 実行ロール、サブネット化、セキュリティ グループ バインディングへの変更を追跡できるようになります。 。

まとめ

AWS Lambda は、安全でスケーラブルなアプリケーションを構築するための強力なツールのセットを提供します。 AWS Lambda のセキュリティとコンプライアンスの実践の多くは、例外もありますが、他の AWS サービスと同じです。 2019 年 1 月の時点で、Lambda は SOC 2、SOC 3、SOC XNUMX、PCI DSS、医療保険の相互運用性と責任に関する法律 (HIPAA) コンプライアンス、およびその他の規制に準拠しています。 したがって、次のアプリケーションの実装を検討している場合は、AWS Lambda サービスを検討してください。これがあなたのタスクに最適である可能性があります。

出所： habr.com