Infrastructure from Code（IfC）とAmptについて少し学習したので、整理して書きたいと思います。
きっかけ
ServerlessDays Tokyo2023のAWS Eric JohnsonのセッションでIfCという単語を初めて聞いたのですが、中身について触れなかったので何なのか分からなかったのとIaCと何が違うのか気になったためです。
Infrastructure from Codeとは何か
アプリケーションコードから必要なクラウドリソースを推測して、自動でアプリケーションの基盤となるインフラストラクチャをクラウドにプロビジョニングするアプリケーション構築のプロセス。
例えば、アプリケーションコード内にAPIのGETやPOSTが書かれていれば、CDNにAPIサーバが必要だと推測して、AWSならCloudFrontにAPI Gateway、Lambdaのリソースを自動でプロビジョニングしてくれるようです。
背景
サーバーレスアーキテクチャの開発ではクラウドリソースのプロビジョニングにはInfrastructure as Codeのプロセスで行っていましたが、アプリケーションの開発者からすると下記の課題があったようです。
①多量のインフラストラクチャコードを書く必要がある
②アプリケーションコード側にサービス制御のコードが書けない。
③アプリケーションコードとインフラストラクチャコードが密結合になり変更が容易でない。
①はインフラストラクチャコードは何十、何百行と書く必要があり、さらにサーバーレスだと複数のサービスを組み合わせてアプリを開発するので、サービスの数だけインフラストラクチャコードが増えてしまい作業時間が増えて、アプリケーションコードを書くのに割ける時間が減ってしまう。
②はタイムアウトや処理中断時の制御はアプリケーション側でも検討するが、制御するコードはインフラストラクチャコードに書かないといけない。例えばLambdaのタイムアウト時間。
③どのアプリケーションコードがどのインフラストラクチャ上で動くのか宣言しておく必要があり、どちらかに変更があると、もう片方への影響調査や改修が発生してしまう。
Self Provisioning Rumtime
課題に関して、解釈的アプローチで考えていった結果、アプリケーションコードとインフラを紐づける部分を自動的に推測してプロビジョニングさせることを思いつき「Self Provisioning Rumtime」と名付けたようです。
①アプリケーションロジックから必要なリソースとアクセス権限を推測させる
②イベントハンドラーでサービス制御を処理
③サービスとの通信を構造から自動的にマッピングさせる
サービス
簡単にですが、IfCのサービスを紹介します。何をベースにしているかで４つに分類できるらしく、既存のアプリケーションコードに簡単に導入できそうなサービスもあれば、一から開発が必要なサービスもあり、使ってみたいときは導入するアプリの状況によって検討することになるかなと思います。
プログラミング言語ベース：Wing、DarkLang
クラウドリソース定義のための新しいプログラミング言語を利用する。
SDKベース：Ampt、Nitric
アプリケーションコードに独自の SDK を導入して利用する。
Annotations + Frameworks：Encore、Shuttle
既存のプログラミング言語にフレームワークにライブラリの追加やアノテーションを付けて対応している。
Pure Annotations：Klotho
既存のアプリケーションコードのインラインコメントでアノテーションすることで対応する。
ぱっと見ると、プログラミング言語ベースは最もと導入難易度が高く、記載順に導入難易度が下がっていく感じがします。
実際にどうプロビジョニングされるのか
冒頭の技術カンファレンスで紹介されていたという理由でAmptの場合、Lambdaはどのようなコードからプロビジョニングされるのか見てみます。
- Ampt構成
コードの前に少しだけAmptの構成を説明します。先述した通り、AmptはSDKベースのサービスです。開発するにはSDKが必要です。
また、クラウドプラットフォームがあり、Runtimeやコンソールなどの機能を備えており、プロビジョニングされるとプラットフォームを通じて推測、環境構築が行われます。
AmptサイトにあるHow Ampt Worksに簡易的な構成図があるので参考になると思います。
- コード例
では、どうLambdaだと推測してプロビジョニングされるのかスケジュールタスクのコードを例に説明します。
//1時間毎にログを出力する。
schedule.every("1 hour", () => {
console.log("I run every hour!");
});
「.every」はスケジューリングを定義するためのメソッドで、時間指定やcron形式を用いて定期実行を可能にします。このコードでは1時間ごとにログ出力を行います。AmptのRumtimeはこのコードから何のサービスをプロビジョニングすべきか推測を行います。例では、スケジューリングを行えるサービスとログ出力を行うコンピューティングサービスが必要だと推測して、AWSにあるそれらに該当するサービスであるEventBridgeとLambdaをプロビジョニングする。という流れになるようです。
もう１つ例をあげてみます。
//タイムアウトを20分に設定したコード。
schedule.every("12 hours", { timeout:1200000 } () => {
console.log("I run every 12 hours!");
});
前と同じスケジューリングのコードですが、「timeout」のハンドラーが存在しています。タスクのタイムアウトをミリ秒で指定でき、例では1200000ミリ秒＝20分を指定しています。このスケジュールタスクをプロビジョニングするとき、timeoutの指定通りに最低20分は稼働するコンピューティングサービスを選択する必要があるため、タイムアウトが最大15分であるLambdaではなく、Fargateをプロビジョニングする判断をするようです。
所感
- 背景を聴いてサーバーレスにはインフラストラクチャを意識させないという要素がありますが、IaCではまだどのインフラにアプリを乗せるかといったインフラストラクチャを意識させる部分があり、真のサーバーレスに近づけるためにも新しいプロビジョニング方法が求められていたのかなと思いました。
- Self Provisionig Rumtimeで自動化する3点は自分も開発で苦労していた部分で、自動化できないのかと考えたこともありましたが、本当に自動化するサービスが実現していたことに驚きました。
- 触ったサービスの特性やまだ歴史が浅いのもありますが、本格的に導入するのはまだ厳しそうに感じました。でも、クラウドインフラストラクチャを一切意識せずにアプリ開発ができるので、小規模な個人開発や新規サービスのモックアプリ開発で導入してみるのはありかもしれないと思います。
- 今回書けなかったですが、学習にあたってAmptのアカウントを作成し、サンプルアプリをプロビジョニングするところまで触ってみました。CLIやブラウザベースのコンソール画面から操作できるのですが、UIとしてもクラウドインフラストラクチャを意識させるようなところはなく、最初の印象としてはAmptはIfCの考えを徹底しているサービスだなと感じています。触ってみたところは、別途ブログにしたいと思います。
- これが本格的に普及したらクラウドエンジニアの仕事が減るかもしれない…
参考
学習のために見たサイトと動画です。