クラウド時代のシステム運用
運用の自動化について今一つイメージが沸かない方もいらっしゃるでしょう。まずは具体的なメリットを挙げてみます。
- 作業に（ほぼ）人が介在しないためミスは格段に減り品質が保証されます。
- 作業手順書を作成する必要がありません。AnsibleのPlaybookやChefのCookBookといった実質的な作業手順書が存在するためです。
他にも自動化ツールが運用面で優れているのは「構成管理」という点にもあります。
例えば、本番環境で障害が発生し、設定を変更する必要があったとします。ここでの変更作業において、自動化ツールを用いていれば、開発環境にもすぐさま同様の変更を適用できます。本番と開発の差異が発生する期間を極端に短くできます。逆に「世代管理」もでき、トラブルが発生する前の状態に戻す、といった作業も容易です。
ただここまで読んで「作業内容を全てシェルスクリプトで記述し、運用者がシェルを実行することとAnsibleで作業内容が書かれたPlaybookを実行することの違いは何か」と疑問を持つかもしれません。
広義の意味ではシェルスクリプトを用いる運用も自動化の範囲です。もちろん、単純な作業ならばシェルスクリプトを用いても問題ありませんが、複雑な作業には不向きです。
また前回構築スクリプトについて説明した時と同様に「冪等性」が肝となってきます。シェルスクリプトには冪等性がありません。定常作業といった頻繁に同じ運用作業が入るならば冪等性をもった自動化ツールを使用した方が安全かつ確実です。（ことAnsibleに関して述べるならばシェルスクリプトよりも可読性が高いというメリットもあります。）
Infrastructure as Code
以上のように、運用に限らず「人」ではなく「コード」によってインフラを管理する効率的な手法を「Infrastructure as Code」と呼びます（IaC）。仰々しい名前がついていますが、特に難しいものではなく前回記事のAnsibleでの自動構築概要がIaCにあたります。名称に「Infrastructure」と入っていますが、インフラレイヤのみを指すのではなく、システム全体をコードで管理しようという概念です。
コードで書かれている以上、人為的なミスは起こりえませんし、クラウドであれば検証環境を作るのも容易なため、コードの信頼性も確認できます。他人が作成したコードに変更を加え、精度を上げることも可能です。IaCについては、クラウドの登場により、システム運用はオンプレミスのそれとは概念レベルで変わったと言っても過言ではありません。
終わりに
さて第1回、第2回と自動化導入のメリットを書き続けてきましたが、最後に自動化ツールを用いる側のデメリットを述べたいと思います。
それは、扱うツールのコードの読み書きができないと話にならないという点です。インフラエンジニアになりたての方は、簡単なシェルスクリプトやバッチファイルを作成することがせいぜいで、アプリエンジニアのように素早く読めて書けるという方はなかなかいないのではないでしょうか。
IaCは魅力的ではありますが、システムの運用担当者全員がツールのコードについてある程度の知識がなければ使用できません。何より避けたいのは、運用自動化ツールを使う人と使わない人が同じシステム運用に携わることです。かたや自動で、かたや手動でとなると管理がより煩雑になります（実際は自動化ツールを「使わない」が優先されるでしょう）。
現在ITエンジニアは人手不足ですが、既存のオンプレミス環境からクラウド環境への移行が加速するのに伴い、自動化技術がこのままの勢いで導入されていくと、やがて人手不足が解消されるということです。もちろん、ユーザーや現場の技術者にとって人手不足解消は喜ばしいことですが、今後スタンダードとなりうる自動化ツールを使えないエンジニアがいつまでも雇われ続けるとは思えません。
デメリットとは書きましたが、自分が勉強すれば解決する話です。これからの時代、アプリもインフラもどちらもできるエンジニアが求められます。現に両者の境界が溶け出しています。その一つに「DevOps」という概念が存在します。次回はそのDevOpsについてIaCとの関連性を述べるとともに、自動化がどう関わっているのかを説明します。
- 慶田 洋啓
- 株式会社BFT
- 「インフラエンジニア3年目。仮想化プロジェクトからスタートし、DB更改プロジェクトを経て現在はクラウドによるMSPサイト一括化、およびオンプレミスの分析ツール変更の設計、構築、試験などに携わる。Linux、Windowsどちらも満遍なく触れている。」
