Ansible トレイルマップ
MOUNT BUTTON

Ansible の全体像

　まずAnsibleが提供する自動化の全体像について、製品版であるRed Hat Ansible Automation Platformの例を使って確認しておきましょう。下の図は大きく2つの階層に分かれています。下側が既に多くの方に馴染みがある「Playbookを書いてコマンドラインから実行する」部分になります。ここが手順を置き換える自動化1.0を担当します。そして上側が自動化をボタン（サービス）にして利用者に提供する自動化2.0になります。

　このボタンを押すことで「仮想マシンを払い出す」「ロードバランサーを一時的に閉塞する」など、今までインフラ担当者が行っていた作業が代わりに実行されるようになります。またこれらのボタンは人が押す以外にも、別システムからボタンを押すことが可能です。例えば、「サーバーのログを収集するボタン」を作っておき、監視システムでエラーが起こった場合には、このボタンを監視システムが自動で押すことで、障害発生時の初動対応を自動化、無人化するといったことが可能になります。もちろんこのボタンは人が押すこともできるので、アプリ担当者がログを確認したいときに使ってもらうことも可能です。

　自動化をボタン化・サービス化する、という行為は、表現を変えると「インフラ作業を連携可能なAPI化する」と言うことができます。これらのAPI同士を連携させ、時には周辺システムとつなげることで、インフラ構築・運用の「作業をシステムへ」と変化させていくことが可能となります。これは従来の「人の作業」を基本としたインフラの運用形態から飛躍することへとつながっていきます。

ボタンの作り方

　Tower と Engineを例に、ボタンをどう定義するかについて確認してみましょう。と言っても既にPlaybookを書いて実行したことのある方には難しいことはありません。基本的な概念は自動化1.0の時とほぼ一緒だからです。

　以下の表ではそれぞれAnsible Engine/Tower（自動化1.0/2.0）における自動化の実行方法とその時に与えるインプット情報の比較になっています。与え方こそ違えど、インプットしている情報は全く同じになります。

　このインプットの与え方の違いは「インフラ担当者の作業の置き換え」と「他人が押すボタン」に起因します。一例としてPlaybookに注目してみましょう。自動化1.0ではPlaybookはansible-playbookコマンドを実行するサーバー上にファイルとして保存します。この方法は配置したファイルのバージョン管理に関する課題がつきまといます。古いバージョンを使わないように、現場で作業を行うエンジニアが常に注意を払う必要があるため、自動化を使う前に知識を持った担当者による確認作業が毎回必要になります。

　一方で、自動化2.0ではgit等のSCM上に配置しPlaybookを一元管理します。そしてTower サーバーがSCMと連携して、常に指定されたリビジョンやブランチを使うようにできます。これで「誰がどのように実行」しても、常に適切なPlaybookが使われるという状態を作れます。まさしく安心して他人にボタンを押してもらえるようにするというサービスの発想になっています。

ボタン化は働き方をどう変えてくれるのか？

　ボタン化することの効果について、1つ前のステップで「人や組織のオーバーヘッドを削減する」と説明しました。ここでは少し視点を変えて、ボタン化していくことがインフラに関わるメンバーの「働き方」にどのような変化をもたらすかを図をみながら確認していきましょう。

　手順にフォーカスした自動化1.0の状態は、広い意味でとらえると、自動化以前と比べて働き方は変化しませんでした。今まで通り依頼を受け、検証・確認を行い、ドキュメントを作成し、それをレビューしたら本番作業となっていきます。作業依頼というインプットがあり、本番作業というアウトプットがあります。インフラチームの中で作業が自動化されていても、いなくても同じ流れになります。そしてこのインプットからアウトプットを出すためのサイクルが大きく、その中のオーバーヘッドも大きくなっています。

　自動化2.0の場合はどうでしょうか。大きな変化の1つ目として、作業依頼と本番作業というインプット・アウトプットがインフラチームから切り離されます。これらはどこへ行ったのでしょうか？そうです「ボタン」としてインフラチームから独立して、様々な作業依頼を処理してくれています。作業が「機能」としてボタンになることで、人の処理能力や体調、他の業務の忙しさといったものとは無関係にリクエストを処理できるようになり、インフラチームのスループットが安定します。更にボタンは処理能力が足りなくなればサーバーをスケールアップ・アウトすることで簡単に性能向上をすることも可能です。これもチームメンバーを増員して育てることに比べたら遥かに簡単です。

　2つ目の大きな変化は、インフラ担当者自身の仕事内容です。従来は調整やドキュメント作成、レビュー等がメインでしたが、Playbookの開発とボタンの作成という「サービス開発」が主な仕事内容になっていきます。

　もちろん全ての作業依頼をボタン化するのは難しいため、突発的な依頼や特殊な要件には今まで通り対応することになります。またボタンが揃っていない自動化の初期段階においては、一時的にボタンの開発もしながら従来どおりの依頼もこなすという状況も生まれます。しかし、ボタン化が進むことで徐々に人から人への依頼は減り、自動化2.0に適したインフラにも徐々に変化していきます。こうなった時に、インフラ構築・運用チームは「インフラサービス」のチームとなり、従来とは比べ物にならないスループットを安定して出せるようになっていきます。自動化2.0に取り組む際には、この「働き方の変化」も意識すると今までは気づかなかった課題も発見できるはずです。