サーバーレスとは何でしょうか？確かに「サーバーレス」という名前は奇妙に聞こえますが、AWS Lambda のようなサーバーレステクノロジーは、アプリケーションを迅速に構築したい開発者の間でますます利用されています。
キーワードは「開発者」です。サーバーレスとは、開発者がシステム管理者を介さずにコードを実行できるようにすることです。DevOpsは存在せず、すべてがDevです。サーバーレスでは、「運用」のあらゆる要素がサーバーレスプラットフォームにオフロードされます。
サーバーレスプラットフォームに関して言えば、AWS Lambdaはサーバーレス技術のデフォルト名称ですが、Project Kratosのような他の実装も存在します。Project Kratosはオープンソースのサーバーレスであり、組織は自社のインフラストラクチャ上でサーバーレス環境を実行できます。Amazon、そして多くのサーバーレスエバンジェリストは、これはサーバーレスの本質を完全に見失っていると言うでしょう。
AWS Lambdaの目的は、開発者がサーバーのプロビジョニングや管理を行うことなくコードを実行できるようにすることです。Lambdaの使用は、コードをサーバーにデプロイする従来のモデルに似ていますが、スケーリングや可用性を含むサーバーの管理はLambdaが行うという点が異なります。
開発者が実行したい各コードは、Lambda 上の関数と呼ばれます。基本的に、各 Lambda 関数は、開発者が 1 つのコンテナ内に配置したコードです。
Lambdaとコンテナ
従来のコンテナソリューションでは、開発者は実行したいコードと定義ファイル（通常はDockerfile）の両方を提供する必要がありました。この定義ファイルはコンテナ環境を指定します。例えば、Zendを使ってPHP用のライブラリやフレームワークをロードするといった要件です。すべてのコンテナには定義ファイルが必要です。
Amazon Lambdaでは、様々な言語に対応した環境を提供する、あらかじめ用意された一連のコンテナが提供されています。デフォルトのLambda環境で提供されるライブラリのみを使用する開発者は、Webフォームにコードを貼り付けるのと同じくらい簡単に関数を作成できます。
開発者が環境を多少変更したい場合（例えば、コードが実行される環境にライブラリを追加する場合など）、Lambdaの「デプロイメントパッケージ」を作成する必要があります。しかし、これはいくつかの問題を引き起こす可能性があります。
Lambdaは、限られた言語を特定の環境でサポートすることで、サービスを低価格で提供しています。サポート対象となる環境の削減は、多くのベンダーが目指すものです。
Amazon Lambdaは、物理層からコンテナ層に至るまで、インフラの自動化を実現しました。これは、ステートレスで完全にコンポーザブルなマイクロサービスという特定のクラスに最適です。しかし、Amazonに完全にロックインされることなくメッセージキューイングの問題を解決するには、慎重な事前検討と注意が必要です。
テラフォームとは一体何なのか：恐ろしい異星の世界を探検する人々の生命維持装置
続きを読む
自動化されたコンテナ環境に期待されるように、すべてのLambda関数はステートレスである必要があります。永続的なストレージを必要とする関数は、Amazon S3、Amazon Dynamo DB、またはサードパーティのインターネット対応ストレージソリューションにデータを保存できます。開発者が管理するコンテナ上のマイクロサービスとLambdaの類似点は、この点で終わります。
解約して居住継続
従来のマイクロサービスコードでは、開発者は何らかのリスナーと、実行するコードチャンクを定義する必要がありました。開発者は、これらに関するあらゆる側面を考慮する必要があります。コンテナ内のコードは、いつ何を行うべきかをどのように判断するのでしょうか？HTTPSリクエストを受信するのでしょうか？それともメッセージキューからのイベントを受信するのでしょうか？コンテナは内部IPアドレスを持つ可能性が高いため、メッセージはどのようにコンテナに配信されるのでしょうか？ロードバランサーを使用するのでしょうか？メッセージキュープロキシを使用するのでしょうか？
AWSを使えば、開発者はこうした心配を大幅に減らすことができます。Lambdaは「イベント駆動型開発」を謳っており、事前定義されたイベントトリガー、コード実行言語、そして実行するコードを選択するだけで、Lambda関数を簡単に作成できます。イベントが発生すると、Lambdaコードがトリガーされます。
従来のコンテナ環境では、例えば人気のメッセージキューであるRabbitMQを利用したい開発者は、コードが適切に応答することを保証するために、RabbitMQのライブラリを組み込み、RabbitMQとのやり取り方法を理解する必要がありました。これは、開発者が関連するイベントのイベント処理を単一のマイクロサービスにまとめることが多く、イベント処理の再実装を回避したり、マイクロサービスの無秩序な拡張を回避したりするためでした。そのため、マイクロサービスは任意の数の異なるイベントに応答できる場合が多くありました。
Lambdaは開発者を異なる方向に導きます。理想的には、各Lambda関数は特定のイベントに応答します。これにより、Lambda関数は、Dockerスタイルのコンテナ化されたマイクロサービスによくある疑似TSRではなく、バッチスクリプトを呼び出す機能に非常に近づきます。
セッションの持続性
擬似TSRとして設定されたDockerスタイルのコンテナは、理論上はコンテナが起動している限りセッションを永続化できます。コンテナが情報をキャッシュしたり、イベントへのレスポンスの実行時間よりも長い期間、一時的なデータを保持したりするようにアプリケーションを設計することも可能です。
Lambdaでは、開発者にはこのオプションはありません。開発者は、Lambda関数が関数の実行時間よりも長くデータを保持することを期待しないよう明確にアドバイスされています。例えば、ローカルコンテナのファイルシステムに書き込まれた一時ファイルは実行後すぐに消去され、実行間でメモリが保持されることはありません。
つまり、Lambda関数は完全に構成可能でなければなりません。例外はありません。
Lambdaのイベント
Lambda関数はイベントによってトリガーできます。イベントは、任意の数のAWSサービスによって生成できます。イベントは、マイクロサービス連携における従来の方法、つまりメッセージキューイング、ファイルシステム監視、データベース監視を通じてトリガーできます。Lambdaは、S3ストレージにアップロードされたファイルを監視したり、Dynamo DBデータベースの更新を監視したり、AmazonのSimple Notification Service（SNS）でメッセージをリッスンしたりできます。
しかし、Lambdaの真の実用性は、マイクロサービスでは通常監視されない様々なイベントによってもトリガーできることにあります。例えば、受信メールへの反応や、Alexa、Cognito、Kinesis StreamsといったAmazon独自のサービスへの反応などです。Lambda関数はHTTP呼び出しによってもトリガー可能です。これは、カスタムREST APIを定義し、Amazon API Gatewayサービスを使用することで実現できます。
Lambda 関数がどのようにトリガーされるかは、Lambda 関数の実行コストに直接影響します。
価格
Lambdaは、リクエストごと、または100万秒ごとに月額料金を請求します。Lambda関数は、何かを実行するためにトリガーされた場合にのみ課金されるため、経済的に魅力的です。作成されたものの呼び出されなかった関数は課金されません。Lambdaを使用すると、リスナーマイクロサービスを作成して永続的に実行することができ、実際にマイクロサービスに何らかの操作が行われない限り、課金は発生しません。
ただし、Kinesis Streams、SNS、Dynamo DB などのサービスは無料ではありません。選択したイベントブローカーによって、関数の実行ごとにコストが決まります。
つまり、Amazonはマイクロサービスを導入するコストで利益を上げているわけではない。Amazonが無料で（あるいはほぼ無料で）提供しているのは、まさにその部分だ。Amazonは、ユーザーにマイクロサービスを構築させ、高額なトリガー料金がかかるイベントトリガーや、高額な（そして独自の）バルクデータ計算分析（BDCA）サービスを利用させることで利益を上げている。
基本的な使用例
セキュリティシステムの顔認識機能を考えてみます。Lambda関数の目的は、顔写真を受け取り、既存のデータベースと照合し、新しい顔を保存することです。
このユースケースでは、極めて基本的な顔認識機能を組み込んだセキュリティシステムを想定しています。オンプレミスのセキュリティシステムの顔認識機能は、カメラに動きがあり、顔がカメラに映っている可能性が高いと判断できる程度の性能であると想定しています。顔を検出すると、その顔のスナップショットがAmazon S3バケットにアップロードされます。
このファイルのアップロードにより、Lambda関数がトリガーされます。Lambda関数はAmazon独自のRekognitionのようなものを呼び出し、画像に対して何らかの処理（場合によっては他のBDCAツールも使用）を行い、画像と結果データを利用可能な無数のデータベースのいずれかに保存します。これはそれほど難しいことではありません。
コード (および呼び出されたサービス) の実行にかかる時間に関係なく、関数は「実行中」であると見なされます。
これはハイブリッドワークロードと言えるでしょう。Lambda関数が画像を安全なサードパーティ製ストレージ（NetApp Private Storage for Cloudなど）に保存し、アップロードに使用したS3バケットから画像を削除すると、さらに効果的です。その後、アプリケーションはオンプレミスの「ダム」コンポーネント（セキュリティシステム）とパブリッククラウドベースのサーバーレス関数を利用し、サードパーティのサービスプロバイダーのストレージを使用してデータを永続化します。これほど「ハイブリッド」なワークロードは他にないでしょう。
マルチクラウドの場合、別のパブリック クラウド (Azure や GCP など) にサーバーレス関数を作成し、サードパーティのストレージの変更を監視して、そのプラットフォームでのみ利用可能な独自のサービスを使用してそのイメージに対してさらに作業を実行します。
別れの言葉
一言で言えば、これがシステム管理者のためのサーバーレスです。ここで取り上げられている概念は、「モダンハイブリッドクラウド」「マルチクラウドコンピューティング」「ハイブリッドマルチクラウド」といった言葉で延々と語られることになるでしょう。また、インフラプロバイダー間でVMをシャッフルするだけのハイパーコンバージド企業もこれらの用語に固執し、誰にとっても混乱を招くことになるでしょう。
re:Invent や 2018 年中にこれらのいずれかが言及されるたびに注射をしないでください。すぐに失明してしまいます。®
