インフラ開発のやり方に変革がもたらされるかも？ InfraCopilotを試してみた

InfraCopilotを試してみる

インフラ基盤のアーキテクチャ設計のあり方を変えてくれそうなサービスとして最近登場してきた「InfraCopilot」を試しに触ってみたので紹介します。

InfraCopilotとは？

https://infracopilot.io/
ここの公式サイトで紹介されている通り、インフラの構成をエディタ上で描いてIaCのコードを生成してくれたり、設定を調整したりできるツールです。
設定の調整や構成を作る部分を、チャットベースで指示を出してその意図に合わせて構成を調整してくれるといったこともできます。

このサービスのインプットとアウトプットのイメージは以下のようになります。

インプット

• ブラウザ内のエディタ上でグラフィカルに設計要素を入力
• 設計要素(リソース)のパラメータは手動で調整も可能
• チャットベースで実現したい構成を指示

アウトプット

• PulumiのIaCコード
• TrerraformのIaCコード(これは2024/3/14時点ではまだ使えなさそうです。(エクスポート用のボタンはあるが押せない状態))

このような仕組みのため、これまでは基盤を設計して図に書き起こしつつ、基盤の要件に対してTerraformやPulumiなど各種基盤構築用のIaCコードを記述し、環境に適用するという流れだったところが、グラフィカルなエディタで図を描いたり、チャットで指示を出すだけで図とIaCコードが実装されていくという世界観に変わるイメージです。

InfraCopilotの使いかた

• サービスにアクセスし、ユーザ登録・ログインします
  • 現時点では全ての機能が無償提供されています(いつかは有償化されるんじゃないかと思います)
• 「New architecture」で新規にアーキテクチャを作ります
• 初期状態では何も構成がない状態のキャンバスが作成されます
• 左メニューにAWSのサービスに関するアイコンが並んでいるので作りたいサービスのリソースをドラッグアンドドロップでキャンバスに配置していきます

• アイコンから矢印を伸ばすことができるため、矢印をつなげることでリソース間の接続に関連する設定を自動で構成してくれます
• たとえば、以下はAPI GatewayからLambda functionを呼び出し、LambdaはRDSと連携するといった図になります

• この状態でアイコンをクリックすると右側の表示パネルに、このリソースに対する設定パラメータ情報がどのように設定されているかが確認できます
• API Gatewayの設定を見てみると、APIのPOSTの呼び出し時の実行ターゲットがさきほど繋いだLambda(lambda_function_5)であるとわかります

• また、Lambdaのリソースアイコン等にはアイコンの下に小さいサイズのアイコンが表示されているものがあります
• このアイコンは追加の関連リソースを表現しているものになります
• Lambdaの場合だと、ECRのイメージの設定先をどこに指定するか、EDRのリポジトリをどこを参照するか、実行時のIAMロールを何にするかといった付随するリソース定義も管理できます

• このようにキャンバス上で形を作っていくだけで構成が少しずつ作り上げられていきます
• Exportのタブからたどると、キャンバス上で構成した内容をIaCコードでダウンロードできるようになっています
  • 2024/3/14時点では、Pulumiが対応しているので表示されているPulumiのコードを確認して良さそうであればダウンロードすることで一式のコードが取得できます

• あとは、このコードを使って実環境を構成すれば実機でも環境が作れてしまうといったものになります

チャットベースでの調整指示

• 画面右下に「チャットマーク」があります
• ここを開くと、チャットプロンプトが表示されます
• このチャットに対して、構成を変更してほしいことの指示を与えると、それに合わせて更新してくれます
• たとえば、先程の構成に対して、以下のような投げかけをしてみました

Please add one more API Gateway.

• すると指示に合わせてAPI Gatewayを作ってくれました(上記画像の真ん中下にあるrest_api_2というオブジェクトです。)
• なお、日本語で指示してもちゃんと同じように対応してくれます

• また、このチャットが反応するのはInfraCopilotが作成に対応しているリソースに対する操作というのに限定されそうなイメージです
• たとえば、「Web3層のシステムを作りたいんだけど構成してくれますか？」といった聞き方をするとNGでした

• ドキュメントに記載されている内容などを見ると、LLMが使われているポイントとして、「チャット上で指示された内容からユーザの意図を解釈する部分にのみ使われている」といった趣旨のことが記載されていました
• LLMを使って構成を生成しているわけではないということかと思います
• そのため、上記のように曖昧な表現で指示を与えたとしても実際のリソースの作成には繋げられないということなのではないかと思われます(これは中の動きを把握しているわけではないのであくまで推測ですが。。)

環境の管理

この機能はどこまでどういう役割なのかわかっていないですが、InfraCopilotで作ってアーキテクチャには「default」と「prod」という"環境"と概念があるようです。
defaultの環境の方で基本的には編集などを行い構成を作っていくようです。
ある程度の構成ができたらdefaultの内容をprodに昇格させる(promote)ことができます。
そうするとprodの環境の方にも同様の構成が生成されます。

prodの環境では、アーキテクチャの構成自体を変えることはできないように制限されているようです。
ただし、各種パラメータなどの設定は変更できるようになっています。

defaultの方は「アーキテクチャの編集」も「パラメータ設定の変更」も可能です。

このように2環境扱えるようにすることで、実際の運用で、開発環境と本番環境のように適用仕分けるようなケースにも対応できるようにしているのかもしれません。

InfraCopilotとKlotho(クロトー)

InfraCopilotの解説ページを見ると、Klotho Engineというキーワードがでてきます。
https://infracopilot.io/how-it-works/

上記ページのInfraCopilotのアーキテクチャ図にある仕組みが参考になります。

Klotho Engineというのが「サーバレスアーキテクチャ」で「メッセージパッシング」といった用語に対してそのために必要なものとしてVPCやIAMなど具体的なリソースに落とし込むというところを担う部分のようです。

チャットで投げかけた言葉の意図をLLMで解釈させ、その解釈した結果をこのKlotho Engineが具体的な構成に変換してくれるといった役割分けのようです。

Klothoは以下のGitHub上でコード公開されています。
https://github.com/klothoplatform/klotho

Klothoだけでも利用できるようです。
使い方的としては、JavaScriptやGo、Pythonなどのアプリケーションコードの中に、exposeやpersistという形で情報を宣言することで、それに合わせたAWS上でのリソース構成のコード(Pulumiのコード)をコンパイルして自動生成してくれるようです。
このような使い方にすることで、アプリの開発コードの範囲だけでIaCのコードの自動生成ができる仕組みを作ることができ、管理が効率化されるということだと思います。
(実際にはまだ使えてないので詳細はわかりません。)

所感

• このサービスの考え方はかなりインパクトがあるものだと感じました
• 今後仕組みが成熟してくるとすごく便利にIaCのコード管理が実現できるようになるかもしれません
• ただ、現状は対応しているクラウドサービスが少なかったりと活用できる範囲は限定的かと思います
• また、使い方もこれまでの考え方とは異なるので、慣れるには少し時間がかかるかもしれません
• 参考にしていただければ幸いです