KDDIグループでアジャイル開発事業を行うKDDIアジャイル開発センター（東京都港区）社員が公開した、AIモデルと外部データソースやサービスをつなぐ規格「Model Context Protocol」（MCP）の初心者向け解説資料が話題だ。同社の御田稔さん（テックエバンジェリスト）が4月6日に公開したもので、はてなブックマークで736ブックマークを集め、テクノロジーカテゴリーで1位になる（7日午後1時時点）など、注目を浴びている。
⇧「MCP（Model Context Protocol）」の存在を初めて知りましたが、
The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you're building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.
⇧「LLM（Large Language Models）」のアプリケーションが外部の機能を利用する際の「接続方法」について「標準化」しようという試みらしい。
ザックリと、
⇧ と言うことらしい。
イメージとしては、
⇧ 上図のようなことを実現したいということかと。
「MCP Protocol」経由にしてしまえば、利用する側の独自の実装の乱立を防げると言った感じでしょうか。
Ansibleのテスト自動化と言ってもテストする内容の設計を自動化してくれるわけではない
ネットの情報を漁っていたところ、
重要なのは「成功すれば」という部分です。 Ansibleでは、宣言のサーバの状態を設定できなかった段階で実行が失敗する「fail-fast」設計となっています。 言い換えれば、Ansibleの実行に成功したならば、宣言通りにサーバの状態がセットアップされていることが保証されることになります。
テストとは、「期待される結果（状態）となるか」を検証することです。 Ansible自体が宣言的に状態を定義し、その状態となっていることを保証しているので、あらためてテストを実施しなくても良い、というのがAnsibleの思想となります。
⇧ 上記サイト様によりますと、そもそもとして、「Ansible」が
- 失敗
- 成功
のどちらかの状態しか取り得ない設計思想になっているらしく、『明示的なテストの実施は不要』という前提ではあるらしい。
とは言え、
Ansible Playbook とテストの統合
「Ansible Playbook とテストを最適な方法で統合するにはどうしたらいいのか」との質問が多数寄せられます。統合のオプションは、多数あります。Ansible は実際には、「フェイルファースト (Fail fast)」の順番ベースのシステムとなるように設計されているため、Ansible Playbookに直接、テストを簡単に埋め込むことができます。本章では、インフラストラクチャーのテスト統合パターンについて触れ、適切にテストするための正しいレベルについても説明します。
https://docs.ansible.com/ansible-core/2.15_ja/reference_appendices/test_strategies.html
⇧ 公式のドキュメントを見た限りでは、「テスト」に関するドキュメントがあることから、「テスト」をすることは禁じているわけではないと。
ネットの情報を漁っていたところ、
この「fail-fast」な設計により、Ansibleの実行が失敗しなかった場合はPlaybookに記述した通りに構築が行われたことが保証されます。そのため、Ansibleにはテストが必要ないという考えも存在します。しかし、人の手でコードを書いている限りは、設定の順序やパラメータの間違いなどのヒューマンエラーが発生する可能性はあります。そのような可能性を洗い出すためにも、テストをする必要性は出てくると考えます。
⇧ 上記サイト様によりますと、「テスト」はすべきであると。
確かに、「Docker」のような「コンテナ仮想化」による環境内で稼働している「アプリケーション」レベルで考えた場合、
- Dockerコンテナが正常に稼働しているか
- Dockerコンテナ内のアプリケーションが正常に稼働しているか
の2つの観点で「状態」を確認する必要があると思うのだが、「2. Dockerコンテナ内のアプリケーションが正常に稼働しているか」については、「Ansible」が良しなにチェックしてくれている気がしない...
そもそもとして、「2. Dockerコンテナ内のアプリケーションが正常に稼働しているか」については、「アプリケーション」によって、「正常」と判定される定義が様々と思われるので、「Ansible」側で判定の仕様がないと思われる。
「Ansible」でどこまで実現するかに依りけりということにはなると思われますが、
- インフラレイヤー
- アプリケーションレイヤー
の2つで大きく分けた場合に、「2. アプリケーションレイヤー」については「テスト」が必要になってくる気がしている。
「1. インフラレイヤー」が正常に構築済みである前提の「テスト」ということになりますが、「テスト」については「Ansible」の利用者側で用意する必要がありますと。
で、「Ansible テスト自動化」などで、ネット上で検索すると、
- ansible_spec
- Molecule
あたりの「Ansible」の「テスト」向けの「ライブラリ」がヒットするのだが、いずれについても、どのような「テスト」を実施するかについては、自動化してくれるわけではない。
つまり、どういった内容を「テスト」したいのかについては、自分たちで考える必要があるわけだ。
そう考えると、わざわざ、「Ansible」の「テスト」向けの「ライブラリ」を導入する意味があるのかが疑問ではある。
そもそも、
⇧「Ansible」の標準の「モジュール」として「ansible.builtin.assert」というものが用意されているのよね...
何よりも、
- ansible_spec
- Molecule
のような外部の「ライブラリ」は、
- メンテナンスされなくなるリスク
- 破壊的変更が発生するリスク
あたりの考慮が、標準の「モジュール」を利用している時よりもより一層必要になってくる気がするのよね...
テスト自動化は置いておいて、
シェルスクリプトをテストする
Ansibleには、commandモジュールやshellモジュールのようにシェルスクリプトをそのまま実行できるモジュールが存在しています。これらのモジュールは、シェルスクリプトが正常に終了したことを保証します。そのため、Ansibleの実行が正常に終了したにもかかわらず、期待した結果にならない可能性が高くなります。これらのモジュールを使用する際は、シェルスクリプトそのものが間違っている可能性を考慮して、期待通りの結果であることをテストしてあげるべきだと考えます。
⇧ 上記サイト様にありますように、最低限、
- ansible.builtin.command
- ansible.builtin.shell
あたりでしか実現できないことについては、「テスト」すべきですと。
例えば、
⇧ 上記の記事の時に触れたのだが、現状、「Ansible」の「モジュール」で、
- docker compose ps
- docker compose logs -f
のような機能を実現できるものは用意されていないようなので、
- ansible.builtin.command
- ansible.builtin.shell
あたりで、「シェルスクリプト」を実行する形で頑張るしか無さそうではある。
とりあえずは、
- どのような「テスト」が必要かの洗い出し
- 必要な「テスト」を選別する
Ansible側で検証できていない内容について「テスト」の追加が必要 - 「テスト」の内容を設計する
あたりの作業が必要になって来るとは思うのだが、「Ansible」側が良しなに検証してくれている部分がハッキリしないので、「テスト」を追加すべきかどうかの切り分けが難しいのよね...
「ライブラリ」を利用する以上、「ライブラリ」の「ブラックボックス」な部分と付き合っていくしかないのだが、「良く分からない」という状態に晒され続けることになるのでストレスを感じ続けるわけで、エンジニアは早死にしそうだなぁ...
とは言え、「車輪の再発明」が芳しくない以上、「ライブラリ」を利用した方が良いのかもしれないのだが、「ライブラリ」の設計思想が見えてこないと辛いのよね...
何が辛いって、
モジュール
2019年頃からモジュールの数が3000以上になったためにAnsible本体のリリース方式に限界が出始めたため、Ansible 2.10からは本体に含めるモジュールは基本的なもののみとして、その他のモジュールはCollectionsとして切り出して別なリリースサイクルで配布されるようになった。これに伴い、リリース番号は本体としてのAnsible Coreと、Collectionsを含む全体のまとまりとしてのリリースのそれぞれに採番されるようになっている。例えば2023年2月現在の最新版であるAnsible 7.2.0では、Ansible Core 2.14.2と110種のCollectionsを含んだものとなっている。
⇧「モジュール」を作成した人の数だけ思想があるわけで、「モジュール」の数は3000を超えるという絶望...
- 実現したいことを達成できる「モジュール」を探す
- 「モジュール」で実現できることを調べる
- 「モジュール」の使い方を調べる
という感じで、「モジュール」を選定するので膨大な時間を取られることは容易に想像できると思われますと...
「決定回避（選択回避）の法則」と呼ばれるものがありますが、「選択肢が多過ぎると適切な選択が判断できず選択することができなくなる」ということらしいのですが、
⇧「認知的疲労」に関係してくる気はする。
昨今の技術革新で「ライブラリ」や「フレームワーク」が爆発的に増えたことによって「エンジニア」の「認知的疲労」を増加せる要因の増加も止まることを知らない感じにはなってきていると言っても過言ではない。
ザックリと、
- 要求、要件を整理するための調査
- 影響範囲を特定するための調査
- 方式検討に必要な情報を整理するための調査
- 技術選定のための調査
- 技術の利用方法についての調査
- 事前要件についての調査
- 環境構築についての調査
- 実現すること・できないことの整理のための調査
のあたりの「調査」が存在するので、「エンジニア」は考えることが多過ぎるのよね...
兎にも角にも、「Ansible」で「アプリケーション」のデプロイとかまで実施しているのならば、「テスト」は必要ということでしょうかね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
