未来のマスタリング:IaC技術を活用したLLM生成データアーキテクチャの評価
未来のマスタリング:IaC技術によるLLM生成データアーキテクチャの評価と活用
LLMを使用したInfrastructure as Codeの生成によるモダンアプリケーションのプロビジョニング、設定、展開の適合性の評価
イントロダクション
この記事では、LLMを使用して、インフラストラクチャのプロビジョニング、設定管理、展開におけるリアルアプリケーションのライフサイクルに対する適合性について取り上げます。この取り組みから生じたソースコードは、GitHub¹¹で公開されています。Infrastructure as Code(IaC)のソリューションは、手動のプロセスではなくコードによってインフラストラクチャの管理とプロビジョニングを容易にします¹。これらは一般的になりつつあり、主要なクラウドプロバイダーは独自のIaCソリューションを実装しています。この点で、AWS CloudFormation、Google Cloud Deployment Manager、およびAzure Resource Manager Templatesは、サーバー、データベース、およびネットワークの手動プロビジョニングが不要なクラウドサービスのプロビジョニングを効率化します。ただし、これらの多くの可能性は、異なるクラウドプロバイダーが必要な場合に必要なIaCの定義を移植する必要があるため、ベンダーロックのリスクをもたらします。この点で、Terraform²やPulumi³などのツールは、さまざまなクラウドプロバイダーのさまざまな実装に対して抽象化を提供し、ポータブルな展開の開発を容易にします。これにより、ベンダーロックのリスクが軽減され、組織は実装コストをかけずにダイナミックにニーズに対応することができます。さらに、IaCテクノロジーが提供する多くの利点があります⁴:
- 一貫性:繰り返し可能なデプロイメントを可能にすることで、インフラストラクチャのプロビジョニングの自動化を許可します。
- リスク低減:手動の介入が最小限に抑えられるため、インフラストラクチャの管理におけるエラーの少ない近似方法を促進します。
- コスト最適化:不要なリソースの特定を容易にし、請求の変更に対応するためにクラウドプロバイダー間の迅速な移行が可能になります。
- 協力の改善:スクリプトはバージョン管理ツールに統合することができ、個人やチーム間の協力を促進します。
ただし、アプリケーションのライフサイクルはインフラストラクチャのプロビジョニングを超えています。次の図は、さまざまなIaCテクノロジーがサポートするアプリケーションのライフサイクルを示しています⁵。
このシナリオでは、IaCテクノロジーの目標は、単なるインフラストラクチャのプロビジョニングを超えています。必要なインフラストラクチャを立ち上げた後、設定管理の段階では、すべての要件が適切にインストールされることを確認します。この段階は、通常ansible⁶、chef⁷、またはpuppet⁸などのツールで行われます。最後に、アプリケーションの展開では、さまざまなインフラストラクチャデバイス上でのアプリケーションのオーケストレーションを監督します。
LLMの理解
Large Language Models(LLMs)とは、人間のようなテキストを入力に基づいて理解し生成するために設計された人工知能モデルの一種です。これらのモデルは、言語の複雑なパターンやニュアンスを捉えるために、多数のパラメータを持つことで知られています⁹。
- テキスト生成:LLMによって作成されたテキストは、まとまりがあり、その周囲と関連性があります。テキストの仕上げ、素材の生成、創作的な文章の作成などの活動に使用されます。
- 言語理解:LLMはテキストを理解し、情報を抽出することができます。態度分析、テキスト分類、情報検索などが可能です。
- 翻訳:LLMは、1つの言語から別の言語へのテキストの翻訳ができます。これは機械翻訳アプリケーションに非常に役立ちます。
- 質問に答える:LLMは、与えられた文脈に基づいて質問に答えることができます。チャットボットや仮想アシスタントでユーザーのクエリに答えるために使用されます。
- テキスト要約:LLMは、長いテキストをより短く、より結束性のある要約にまとめることができます。これは情報を短時間で凝縮するために役立ちます。
上記の能力の中で、私たちはテキスト生成に焦点を当てます。特に、入力プロンプトに基づいて正しいIaCコードを生成する能力において、大規模言語モデル(LLM)は自然言語処理の分野で大きな進歩を遂げていますが、いくつかの課題や懸念も引き起こしました。LLMに関連する主な問題と懸念には次のようなものがあります。
- 偏見と公平性:LLMは、訓練されたデータに存在する偏見を学習することがあり、バイアスのあるまたは公平でない結果につながる可能性があります。
- 誤情報とディスインフォメーション:LLMは、虚偽や誤解を招く情報を生成することがあり、これはオンラインでの誤情報とディスインフォメーションの拡散に寄与する可能性があります。これらのモデルは信頼できるように見えるコンテンツを作成する可能性がありますが、事実に反する場合があります。
- セキュリティとプライバシー:LLMは、ディープフェイクテキスト、フェイクニュース、またはフィッシングメールなどの悪意のあるコンテンツを生成するために誤用される可能性があります。
次の表は、さまざまなLLMの比較を示しています¹⁰
LLMを使用したIaCの生成
IaCの領域で現在のLLMツールがどのように機能するかをテストするために、ユースケースが設計されました。最終目標は、FastAPIフレームワークを使用して、クライアントがHTTPメソッドを介してElasticsearchクラスタでの検索および削除タスクを実行できるAPIを仮想マシンに構築することです。クラスタは3つのノードで構成され、各ノードは独自の仮想マシン上に配置され、別のマシンには可視化をサポートするクラスタの管理ツールであるKibanaがあります。すべてはAWSクラウド上に配置されます。次の図はこのアーキテクチャを示しています。
この課題では、LLMツールを使用して次の3つのタスクを成功させることが求められます。この記事では、OpenAIのChatGPTを使用しました。
- AWS内で5つの仮想マシンを構築するためのTerraformコード。
- APIのHTTPメソッドを介してドキュメントの検索および削除操作を実行するためのFastAPIアプリケーションのソースコード。
- 3つのノードにElasticsearchクラスタ、別のノードにKibana、残りのノードにFastAPIアプリケーションを展開およびインストールするためのAnsibleコード。
タスク #1
この課題について、以下のプロンプトを使用しました:
私はTerraformを使って、好きなパブリッククラウドプロバイダで5つの仮想マシンを作成する必要があります。これらの仮想マシンの目的は次のとおりです:3つは1日あたり2GのデータをインジェストするためのElasticsearchクラスタの展開のためです。もう1つはKibanaのためであり、最後の1つはFastAPIアプリケーションの展開のためです。各仮想マシンのハードウェアとクラウドプロバイダを選択してください。わからない変数についてはプレースホルダとして使用してください。安価なインスタンスを使用してください。
最初の応答は良い努力でしたが、引き続き改良を行う必要がありました。たとえば、すべての変数を別のファイルで定義したかったので、次のイメージが生成されました。
変数の定義が含まれるvariables.tfのコード抜粋
同様に、展開のIPアドレスも別のファイルで管理したいと思いました。
新たに生成された仮想マシンのIPアドレスが含まれるoutput.tfのコード抜粋
AIは、望んだインスタンスを記述し、それぞれに必要なセキュリティグループで構成するために優れた仕事をしました。
仮想マシンを生成するためのセクションが含まれるmain.tfのコード抜粋
また、必要なセキュリティグループのリソースも作成し、さまざまなポートを変数として定義する場合にはプレースホルダを使用しました。
セキュリティグループを使用するためのセクションが含まれるmain.tfのコード抜粋
ChatGPTはこのタスクを遂行する上で素晴らしい仕事をしました。ただし、実行可能な構成を取得するまでに時間がかかりました。ネットワーキングの構成を正確に行う必要がありました。たとえば、以下の方法でプロビジョニングされた各仮想マシンに接続したいと思いました。
私はノートパソコンからそれら全てへのsshアクセスと、kibanaインスタンスへのhttpおよびhttpsアクセスが必要です。
上記のプロンプトは、イングレスとエグレスのポリシーに混乱してしまったため、ほぼ正しいコードが生成されました。ただし、これは簡単に見つけて修正できる問題でした。
仮想マシンに到達できるようになった後、権限の不足によりそれらに接続できないという問題が発生しました。これにより、より長い会話が生じ、これらの行を自分で追加する方が簡単でした。
Task #2
この課題では、以下のプロンプトを使用しました:
FastAPIアプリケーションを作成する必要があります。このAPIの目的は、Elasticsearchクラスタに単一のJSONドキュメントを保存するメソッド、複数のドキュメントを保存するメソッド、およびドキュメントを削除するメソッドを持つことです。Elasticsearchクラスタは3つのノードに展開されており、ユーザー”tecnalia”とパスワード”iac-llm”で基本認証が行われています。
このプロンプトの結果は非常に成功しています。このアプリは、ElasticsearchのPythonパッケージ¹²を使用してElasticsearchクラスタと対話するため、完全に有効です。ただし、クラスタが展開されているノードのIPアドレスを変更する必要があることを覚えておく必要があります。次の図では、最初のメソッドが作成され、単一のドキュメントをElasticsearchに挿入する目的で使用されています。
単一のドキュメントを保存するメソッドのコード抜粋。
次に、2番目のメソッドは複数のドキュメントを一括で挿入するために使用されます。
複数のドキュメントを保存するメソッドのコード抜粋。
最後に、最後のメソッドはElasticsearchクラスタから単一のドキュメントを削除するために使用できます。
ドキュメントを削除するメソッドのコード抜粋。
この実験は非常に成功したと考えています。なぜなら、適切なライブラリを選択してタスクを実行するからです。ただし、このコードを本番のソフトウェアにするためには、さらなる手動の調整が必要です。
Task #3
この課題では、以下のプロンプトを使用しました:
3つのノードにElasticsearchクラスタをインストールするためのansibleコードを生成してください。また、クラスタに接続されたKibanaノードも追加してください。
このプロンプトは、要求されたansibleスクリプトを生成するのにはまずまずです。ソースコードがさまざまなファイルにうまく組織化されている点で優れています。まず、すべてのノードの詳細情報を含むインベントリがあります。このファイルは、Task #1で生成された正しいIPアドレスに合わせて調整する必要があります。
インベントリ.iniのコード抜粋
そして、Elasticsearchのインストールのためのメインのansibleスクリプトが以下の図に表示されます。これはその一部ですが、完全な例はリポジトリ¹¹にあります。
elasticsearch_playbook.ymlのコード抜粋
また、Elasticsearchの各ノードの必要な構成は、Jinjaファイルとして便利に生成されました。この場合、Elasticsearchが権限の問題で起動できなかったため、path.logsとpath.dataの構成を手動で追加する必要がありました。
elasticsearch.yml.j2のコード抜粋。
同様に、Kibanaインスタンスの構成についてもChatGPTは同様の構成を生成できました。ただし、この場合、便利のために構成を別のファイルに手動で分割しました。このファイルの抜粋は以下の画像で確認できます。
kibana_playbook.ymlのコード抜粋。
同様に、Kibanaインスタンスを参照するJinjaファイルも良好ですが、IPアドレスはパラメータ化する方が良いでしょう。
kibana.yml.j2のコード抜粋
全般的に、ChatGPTはプロジェクトの骨組みを生成するのに非常に優れています。しかし、その骨組みを本番レベルのアプリケーションにするには、まだ多くの作業が必要です。そのため、使用する技術の深い専門知識が必要です。
結論
この記事では、LLMを使用してアプリケーションのライフサイクルを管理する方法について説明しています。この取り組みの利点と欠点について以下で詳しく議論します。
利点
- LLMを使用してアプリケーションライフサイクルのさまざまな段階のサポートを行うことは、特によく知られた技術でプロジェクトをスタートさせる際に特に有益です。
- 初期の骨組みは構造化されており、それによって通常使用されなかった構造や方法論が利用されます。
欠点
- LLMはAIソリューションの使用に関連するバイアスリスクの対象となります。この場合、ChatGPTは他の類似のオプションよりもAWSを選択しました。
- プロジェクトを本番用に仕上げることは困難であり、使用するコードを手動で調整する方が簡単な場合もあります。そのため、使用する技術の広範な知識が必要です。
謝辞
この作業は、バスク州政府(ELKARTEK 2022 KK-2022/00007)からのSIIRSE Elkartekプロジェクト(産業5.0向けの堅牢で安全かつ倫理的なスマート産業システム:仕様、設計、評価、監視のための先進的なパラダイム)によって資金提供されています。
著者の貢献
この概念化、分析、調査、執筆は、Juan Lopez de Armentia、Ana Torre、およびGorka Zárateの共同の取り組みです。
参考文献
- Infrastructure as Code(IaC)とは何ですか?(2022)。 https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac
- Terraform by HashiCorp。 (n.d.)。2023年10月5日にhttps://www.terraform.ioから取得しました。
- Pulumi-ユニバーサルなInfrastructure as Code。 (n.d.)。2023年10月5日にhttps://www.pulumi.com/から取得しました。
- インフラストラクチャとしてのコードの7つの最大の利点-DevOps。 (n.d.)。2023年10月5日にhttps://duplocloud.com/blog/infrastructure-as-code-benefits/から取得しました。
- Diaz-De-Arcaya、J.、Lobo、J. L.、Alonso、J.、Almeida、A.、Osaba、E.、Benguria、G.、Etxaniz、I.、およびTorre-Bastida、A. I.(2023)。IEM:多言語IaCデプロイメントの統一ライフサイクルオーケストレータACMリファレンスフォーマット。https://doi.org/10.1145/3578245.3584938
- AnsibleはシンプルなIT自動化です。 (n.d.)。2023年10月5日にhttps://www.ansible.com/から取得しました。
- Chef Software DevOps Automation Solutions | Chef。 (n.d.)。2023年10月5日にhttps://www.chef.io/から取得しました。
- Puppet Infrastructure & IT Automation at Scale | Puppet by Perforce。 (n.d.)。2023年10月5日にhttps://www.puppet.com/から取得しました。
- Kerner、S. M。 (n.d.)。Large Language Modelsとは何ですか? | TechTargetの定義。2023年10月5日にhttps://www.techtarget.com/whatis/definition/large-language-model-LLMから取得しました。
- Sha、A.(2023)。2023年の12の最高のLarge Language Models(LLMs)| Beebom。https://beebom.com/best-large-language-models-llms/
- Diaz-de-Arcaya、J.、Lopez de Armentia、J.、およびZarate、G.(n.d.)。iac-llms GitHub。2023年10月5日にhttps://github.com/josu-arcaya/iac-llmsから取得しました。
- Elastic Client Library Maintainers。 (2023)。elasticsearch · PyPI。https://pypi.org/project/elasticsearch/
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles