AWS LambdaをEC2インスタンス上で動かす「AWS Lambda Managed Instance」
まず1つ目は、AWS Lambda Managed Instanceです。これは、EC2インスタンス上でLambda関数を実行できるサービスなのですが……ちょっと待ってほしい。そもそもAWS Lambdaのメリットはサーバー（＝EC2インスタンス）が要らないことだったのでは？
どうやら、AWS Lambdaの手軽さを維持しながら、実行基盤としてAmazon EC2を選べるようになった、ということのようですが、もう少し詳しく見ていきましょう。
そもそもAWS Lambdaはサーバーがいらない＝AWSが用意した環境で動作するもので、「どの環境で実行するか」を選べませんでした。そのため、「高速で処理したい」ものでも「このLambda関数はハイスペックな環境で実行する」などの指定はできません。「サーバー運用不要」というメリットと背中合わせの課題とも言えます。また、他アカウントと共通の基盤リソースで実行されるため、厳格なネットワーク分離が必要なケースでは使えないなど、セキュリティの課題もありました。
もうひとつ、従来のAWS Lambdaで言われていたのが「コールドスタート問題」です。AWS Lambdaは関数が実行されるときだけ環境ができる（＝コストを抑えられる）一方で、該当する関数をはじめて実行するときや、長時間実行しなかったあとで再度実行するときなどは、環境を用意するために時間がかかっていました。
そしてこれらの課題を解決するのが、AWS Lambda Managed Instance、というわけですね。まず、実行環境としてインスタンスタイプを選べるようになります。高性能なCPUなども選べて、処理にあった実行環境を指定できます。さらにVPCやセキュリティグループの設定もできるので、セキュリティ問題もクリアです。
とはいえ、運用についてはマネージドで提供され、オートスケーリングなどを気にすることなく、これまでと同様に使えるとのこと。かなり便利そうなのでは？
さらに、インスタンスが常に起動する状態になるため、コールドスタート問題も発生しません。ただし、従来のAWS Lambdaと違い、アイドル時間も課金されるようになるので、このあたりのコストは要注意かもしれません。……としつつ、1つの実行環境で複数リクエストを処理できるようになったため（これまでは1つの実行環境で1つのリクエストを処理）、CPUやメモリをフル活用できるうえ、Savings Plansも利用可能ということで、用途によってはコストメリットも出そうです。AWS Lambdaを使うときは選択肢のひとつとして押さえておきたいですね。
「AWS Lambda Durable Functions」で、長期間に渡る処理が可能に
もうひとつが、「AWS Lambda Durable Functions」です。「durable」とは「耐久性のある、長持ちする、永続性のある」といった意味で、Lambda関数を実行するときに「永続実行」というものが選べるようになりました。これは、Lambda関数の処理を中断し、続きから再開できる機能で、たとえるなら「処理をセーブできるようになった」というイメージのようです。以前は、処理時間15分という制約がありましたが、AWS Lambda Durable Functionsでは最大1年間の実行まで対応と、長期間に渡る処理も可能になることが特長です。
で、それってなにがうれしいの？という話ですよね。そもそも、AWS Lambdaは処理時間の制約もありますし、「途中でなにかを待ってから、続きの処理をさせる」ことが苦手で、実装するにはなにかしらの工夫が必要でした。そこでよく使われてきたのがAWS Step Functionsで、簡単に言うと複数のAWSサービスを組み合わせてワークフロー化できるものです。これにより、「まずこのLambda関数を呼び出して、しばらく待機して、次に別のLambda関数を呼び出す」といったことが可能になります。
たとえば、出張申請などのワークフローで、入力＆申請し、上司の承認をもらって、OKだったらデータを登録という処理にしたい場合、当然ながら上司の承認に15分の制限をつけるわけにはいきません。なので、入力＆申請と、承認後の処理を分けて、AWS Step Functionsなどでうまく連携させて実現するしかありませんでした。そう！これを待機まで含めて1つの関数で実装できちゃうのがAWS Lambda Durable Functionsです。
仕組みとしては、処理をステップに分けると、ステップごとに「チェックポイント」が自動で作成され、実行中にはステップごとに成功したかどうかが保存されます。そのうえで、必要なところで「待機」が可能になり、待機後は、成功したステップをスキップし、続きから再開される、という感じになります。
ちなみに、この「待機」の間は実行時間課金が発生しないので、その点も安心です。ただし、データを保持するとそこにはコストが発生するので、ご注意を。
こうなると、複雑なワークフローもLambda関数1つで完結できて、用途がググっと広がると期待されているわけです。たとえば、PC持ち出し申請や休暇申請など、途中に「人の承認」が入るようなフローだって実現できそう。エンジニアの皆さんが、おもしろそうとワクワクしている理由が分かる気がします。
もちろん、「なんでもAWS Lambda Durable Functionsを使えばいいじゃん」ということはなく、大規模で処理が複雑なものなどはこれまでのようにAWS Step Functionsを使う方がよさそうで、どう使い分けていくのかがポイントと言えるでしょう。
「サーバーレス」の用途がさらに広がるアップデート
「サーバーレス」という言葉が出はじめたころから、その中心的な役割を果たしてきた「AWS Lambda」。AWS関連で構成図を書くときにも、本当によく見かけますし、すでに相当使われているサービスです。今回のアップデートは、かなりエンジニア向けというか、もしかしたらビジネス面での成果として大きくは見えづらいのでは、という気もしますが、「用途が広がる」というのは確かにそうだろうなと思います。これまでの課題を取りこぼさずに、しっかりキャッチアップしてくるあたりは、さすがAWSなのでしょうか。
次回は、やっぱり今回もメインテーマだったAI、なかでも「AIエージェント」について紹介します。以上、シイノキでした！
