# Automated Planning for Configuration Changes Navigation: [[../index|index]] | [[../overview|overview]] > [!abstract] 概要(abstract の日本語訳) > 本論文は、宣言的な状態間のワークフローを計算するために自動計画(automated planning)技術を用いた設定システムのプロトタイプ実装を報告する。生成されたワークフローは、ControlTier と Puppet という一般的な組み合わせを用いて実行される。これにより、手動でのワークフロー記述が現実的でない無人の「自律的(autonomic)」状況でもこのツールを利用でき、また、ワークフローの実行を通じて重要な運用上の制約が常に維持されることを保証できる。本論文では、設定と計画の技術の背景、プロトタイプのアーキテクチャを説明し、典型的な再設定問題のいくつかの例に対してシステムがどのように対処するかを示す。 ## 論文情報 - 著者: [[Herry Herry]]・[[Paul Anderson]]・[[Gerhard Wickler]](いずれも [[University of Edinburgh]] School of Informatics) - 会議: 25th Large Installation System Administration Conference(USENIX LISA '11、2011年12月、Boston, MA) - 公式ページ: https://www.usenix.org/conference/lisa11/automated-planning-configuration-changes - PDF: https://www.usenix.org/events/lisa11/tech/full_papers/Herry.pdf - スライド: https://www.usenix.org/events/lisa11/tech/slides/herry.pdf - 発表動画: https://www.youtube.com/watch?v=otjfUsDGctQ ## 概要 宣言的な設定ツール(Puppet・Cfengine・BCFG・LCFG)は、目標状態を宣言すれば必要な変更を自動的に計算・実行してくれる点で従来の手続き型スクリプトより信頼できるとされてきた。しかし、これらのツールは変更を実装する際のアクションの実行順序については何も保証しない。本論文は、AI計画(automated planning)技術を用いて、現在状態・目標状態・中間状態が満たすべき運用制約(例:クライアントは常に稼働中のサーバを参照しなければならない)から、順序制約を満たすワークフローを自動生成するプロトタイプを提案する。生成されたワークフローは ControlTier のワークフロー記述に変換され、各ステップは Puppet マニフェストとして実行される。 ## 問題設定 サーバ A・B とクライアント C からなる単純な例(図1)を用いて問題を提示する。現在状態は A が稼働・B が停止・C が A を参照、目標状態は A が停止・B が稼働・C が B を参照である。この変更を宣言的ツールにまかせると、3つのアクション(A停止・B起動・C参照変更)の実行順序として理論上6通りの並びがあり得るが、「C は常に稼働中のサーバを参照しなければならない」という制約を満たすのはそのうち1通り(B起動→C参照変更→A停止)だけである。宣言的ツールはアクションを本質的に不定な順序で実行するため、この唯一の正しい並びを保証できず、高い確率でシステムが一時的に機能しない状態を経由する変更列を生成してしまう。 ![[fig1a-current-state-server-transition.png]] ![[fig1b-goal-state-server-transition.png]] *図1(Figure 1、Figure 1a/1b): サーバ移行例の現在状態(a)と目標状態(b)。* 従来はこの問題を、管理者が中間状態を手作業で洗い出して逐次投入するか(手動ワークフロー)、ControlTier や IBM Tivoli Provisioning Manager のような固定ワークフローツールに事前に手作業でワークフローを登録しておくことで回避してきた。しかし後者は、想定されるあらゆる出発状態の組み合わせに対して大量のワークフローを事前に用意する必要があり、目的の状態に適したワークフローを選ぶこと自体も自明ではない。 ## 提案手法 - 各アクションを、事前条件(preconditions、実行前に満たすべき制約)と効果(effects、実行後に成立する状態)の組として `actions database` に登録する。アクションは第三者ベンダー・社内エンジニア・管理者など誰でも記述できる。 - 現在状態は `facter` が収集した事実を、目標状態は管理者が宣言した仕様を、それぞれ translator が PDDL(Planning Domain Definition Language、バージョン 2.1)へマッピングする。 - planner(プロトタイプでは LPG を採用)が、PDDL 化された現在状態・目標状態・アクション定義から、順序制約を満たすプラン(ワークフロー)を計算する。LPG は各ステージ内のアクションが相互排他になるプランを生成でき、同一ステージ内のアクションは並列実行できる。 - mapper がプランから ControlTier のワークフローコマンドを生成し、各プリミティブコマンドについて対応する Puppet マニフェストファイルを生成する。 - ControlTier がワークフローの実行を管理し、対象ノードへ Puppet マニフェストを送って Puppet に実際の変更を実装させる。 ![[fig2-system-architecture.png]] *図2(Figure 2): プロトタイプのシステムアーキテクチャ(actions database・translator・planner・mapper の4主要コンポーネント)。* アクションには、任意の設定問題に再利用できる汎用的な「configuration pattern」(例: start-service・stop-service)と、特定の設定問題にのみ適用可能なドメイン固有アクションの2種類がある。実行中にエラーが発生した場合(例: change-reference アクションの対象サーバが故障している)、実行ログからエラーを検知して再計画(re-planning)し代替プランを計算する、あるいは現在状態と目標状態を定期的に評価して構成のドリフトを自動修復する「自己修復(self-healing)」能力を持たせることも構想として述べている(いずれも本プロトタイプでは実装評価は示されていない)。 ## 新規性 - 宣言的設定ツールが変更順序を保証しないという「シーケンシング問題」を明示的に定式化し、AI計画技術で解く方式を提案した点。既存の CHAMPS(Keller et al. 2004)は現在状態や事前条件・効果を考慮せず健全性を欠く恐れがあり、Hagen & Kemper(2010)や El Maghraoui et al. のモデリングは仕様が複雑で実運用向けのインタフェースが不明瞭だったのに対し、本論文は標準的な PDDL プランナーを、Puppet・ControlTier という広く使われる本番品質のツールへ直接接続する経路を示した。 - 生成したワークフローが「相互排他なアクション群のステージ列」というパーシャルオーダー計画になるよう LPG を選定し、同一ステージ内のアクションを並列実行してデプロイ時間を短縮する設計にした点。 - 論文自身が「本プロトタイプの目的は概念が実環境に適用可能であることを示すことであり、まだ実運用品質のツールではない」と明言しつつ、実際の Puppet マニフェスト・ControlTier ワークフロー記述(付録B・C に全文掲載)まで生成する、エンドツーエンドで動く実装を示した点。 ## 実験設定 正式なベンチマークやユーザースタディは行っていない。2つのシナリオを用いた実装可能性の実演(walkthrough)として提示される。 1. **Webサービス実験**: Webサービス WS-A・WS-B、クライアント PC、ファイアウォール FW からなる系で、稼働中の WS-A をメンテナンスのため停止し PC の参照先を WS-B へ切り替える。制約は「PC は常に稼働中の Web サービスを参照する」「ファイアウォールの未使用ポートは閉じる」の2つ。既存アクション7種に加えて手を加えずに、これらのアクションを再利用してプランを生成した。 2. **クラウドバースト実験**: プライベートクラウド上の重要な財務系Webサービス WS-A を、需要スパイクに備えてパブリッククラウドへ一時移行するシナリオ。制約は「移行中もサービスを24時間無停止で提供する」「ファイアウォールを再設定してLAN側PCとパブリッククラウド上サーバの接続を確保する」「ライセンス制約により当該アプリケーションを他マシンへインストールしない」の3つ。前実験のアクションを再利用しつつ、start-vm・stop-vm・change-ref・migrate・set-need-firewall の5アクションのみを新規に actions database へ追加してプランを生成した。 ![[fig3a-web-services-current-state.png]] ![[fig3b-web-services-goal-state.png]] *図3(Figure 3): Webサービス実験の現在状態(a)と目標状態(b)。* ![[fig4a-cloud-burst-current-state.png]] ![[fig4b-cloud-burst-goal-state.png]] *図4(Figure 4): クラウドバースト実験の現在状態(a)と目標状態(b)。* ## 実験結果 両実験とも、プロトタイプは制約を満たす ControlTier ワークフロー(パーシャルオーダー計画)を自動生成し、それぞれ1つの主ワークフローと複数のサブワークフロー(相互排他なアクション群を並列実行するグループ)に分解した。クラウドバースト実験では、既存アクションの大部分(9個)を再利用し、新規アクション5個の追加だけで、より複雑な3制約の問題に対応できたことを、アクションデータベースの再利用性を示す結果として報告している。 ![[fig5a-workflow-web-services.png]] ![[fig5b-workflow-cloud-burst.png]] *図5(Figure 5): 生成されたワークフローのフローチャート。Webサービス実験(a)とクラウドバースト実験(b)。* ## 考察 論文は次の2点を今後の主要課題として挙げる。第一に、ユーザビリティの課題であり、管理者が自身の要件・仕様を計画に利用可能な形式へ翻訳するための言語・インタフェースが必要であること、また計画技術が仕様の曖昧さを突いて「創造的」で予期しない解を見つけてしまう性質があるため、管理者がシステムの振る舞いを予測できる形にする必要があることを指摘する。第二に、エラー回復である。再設定はシステム自体が不安定な状況(ネットワーク障害・コンポーネント故障・過負荷)でこそ発生しがちであり、計画の実行が途中で失敗したり、集中管理型のプランナーが実行中のプランの現在状態を見失ったりする可能性があると論じる。全体として、管理者が完全に自動化されたシステムに大きな変更を委ねることには依然として抵抗があるとし、自動計画と人間の判断を組み合わせた「mixed initiative」な解法や、提案された解の自動説明といった方向性を今後の課題とする。 ## 強み / 弱点・課題 - 強み: 宣言的設定ツールが抱える「実装順序の不定性」という具体的かつ実務的な問題を明確に定式化し、標準的な AI 計画技術(PDDL・LPG)を Puppet・ControlTier という実運用ツールへ接続する完結したプロトタイプを示した。アクションの再利用性(クラウドバースト実験で既存9アクション+新規5アクションのみで対応)は、actions database というアーキテクチャの実務的な妥当性を裏付けている。 - 弱み・課題: 実験は2つの小規模な手作りシナリオの実演にとどまり、定量的なベンチマーク(計画時間・スケーラビリティ・アクション数増加時の探索コストなど)は示されていない。エラー回復・再計画・自己修復の能力は構想として述べられるのみで実装・評価されていない。論文自身が認めるとおり、計画技術が仕様の緩さを突いて予期しない解を返すリスクや、管理者が完全自動化されたシステムを信頼できるかというユーザビリティ上の課題は未解決のまま残されている。