第1回「システムをプログラミング」


まずシステムのライフサイクルを考えてみましょう。

一般的にシステムは計画立案、実現可能性の調査から始まり、要求仕様の収集、設計へと進み、製造、テスト、構築、保守・運用と進んでいきます。

ライフサイクル序盤の計画立案や要求仕様の収集などは人間が主体の作業ですので、さすがに自動化することはできません。

設計から製造、テストまでの工程は開発自動化というジャンルで、昨今さまざまな自動化ツールがあります。本コラムは環境構築と運用の自動化に焦点を当てていますので、ここではお話しませんが、興味があれば調べてみるとよいでしょう。

次工程となる構築、保守・運用が本コラムで自動化を考える対象のフェーズとなります。ですが、開発フェーズにおいても開発環境の構築や運用は必要でしょう。そのため本コラムでは「環境」を構築、保守・運用の自動化を考えていきます。

自動化という言葉を口にしますと、何もかも自動化されたバラ色の未来を想像される方もいらっしゃいますが、そうは問屋が卸しません。先ほど「環境」を構築、保守・運用を自動化すると書きました。ではこれらの工程ではどのような作業があるか考えてみましょう。

構築する時に一番大事なドキュメントは設定パラメーターのドキュメントでしょう。プロジェクトによっては手順書が予め作られ、その手順書通りに操作するだけかも知れませんが、その手順書も設定パラメーターのドキュメントが無ければ作れないでしょう。

保守・運用についても考えてみます。定型、非定型それぞれさまざまな手順書があり、その手順書に従って作業を進めるかと思います。

つまり構築、保守・運用のフェーズにおいては、設定パラメーターのドキュメントやさまざまな作業手順書が無いと作業ができません。ではこれらのフェーズを自動化するとなった場合、これらのドキュメントないし手順書などはどこから来るのでしょうか。答えは「人間が用意しなければならない」です。

少し視点を変えてみましょう。コンピューターは何でもできると考える人は少なからず居ます。それはある意味正解でもあり、不正解でもあるという事は、このコラムをご覧になるような方ならご理解頂けるでしょう。コンピューターは何でもできますが、逆にプログラミングされた事以外は一切できず、プログラムは人間が作らなくてはなりません。

この関係は構築、保守・運用の自動化を考えた時もよく当てはまります。
自動化を実現する「自動化システム」が「コンピューター」としましょう。先ほど出てきた設定パラメーターのドキュメントや、定型、非定型の作業手順書などは「プログラム」と考えると、とてもよくマッチします。

構築、保守・運用の自動化とは実際そのような仕組みになっており、「コンピューター」である「自動化システム」で動作する「プログラム」を作るという事です。

ここまで読んで、自動化も大した事無いじゃないかと思われた方がいらっしゃるかも知れません。「プログラム」に相当するものを作る必要があり余計な手間が掛かるのですから、そのように思われるのも仕方ないかも知れません。ですが、自動化するとその手間を差し引いて余りあるほどのメリットがあります。そのメリットとは何でしょうか。

コンピューターのプログラムを考えてみてください。プログラムは一度作れば何度でも実行して同じ結果を得ることができます。これは自動化でも同じです。「プログラム」に相当するものを一度作れば、ハードウェアなど周辺環境に変更が無い限り、何度でも同じ環境を作り、また同じ作業を実施する事ができるのです。

これはすなわち環境構築においては、同じような環境であれば一度「プログラム」を書いてしまえば、それを使いまわして簡単に何台でも作る事ができるようになるという事なのです。例えば、負荷分散環境でのWebサーバーのように、構成はほとんど同じでホスト名などのごく一部分だけ異なるようなサーバーを数百台作るとしましょう。人手で作るとすれば大変な作業です。人間はほとんど同じだけども少しだけ違いがあるという作業が苦手ですので、途中で設定ミスなど間違いが入ることもあるでしょう。構築が終わった後、数百台のうち1台だけ動作がおかしいという時、それを探し出すのはとても苦労するのではないでしょうか。

これが自動構築だったらどうなるでしょうか。最初に「プログラム」を書き、テストして不具合が無い事を確認します。これは普通のプログラミングと何ら変わりません。「プログラム」は引数でサーバー固有の情報を受け取れるようになっています。つまり「ほとんど同じだけど少しだけ違う」の違う部分を引数で渡せるのです。すると「プログラム」を固有の引数を渡して実行する事で、数百台のサーバーを一気に構築する事ができるようになります。それも引数の指定ミスが無いという前提ならば、構築で設定ミスなどの間違いが入る余地がありません。

これは保守・運用でも同じ事です。現在でもスクリプトを使って可能な限り自動化する努力はされていますが、スクリプト化が難しい設定ファイルの変更などのような作業は人手に頼っている現場がほとんどでしょう。「自動化システム」はこの設定ファイルの変更などの作業も自動化する事ができますので、これらの作業も一度「プログラム」に書いてしまえば、先のサーバー構築の例と同じく人間の作業は「プログラム」を実行するだけになります。そうすると保守・運用現場で一番恐れられているであろう、ヒューマンエラーの入る余地を限りなく小さくする事ができるのです。

今回は「自動化システム」「プログラム」と少し抽象的な書き方をして、構築、保守・運用の自動化をアプリケーションのプログラミングに重ねました。実際に考え方は同じです。「システムをプログラミングする」事ができれば、普通のプログラムと同様に一度書いたプログラムは何度でも実行して何度でも同じ結果を得ることができます。これは大量のサーバーを必要とするような用途やImmutable Infrastructureのような、サーバーを「使い捨て」にする考え方と大変親和性が高いのです。

次回以降、今回は抽象的な書き方をした「自動化システム」や「プログラム」について詳細をお話していきます。



第1回「システムをプログラミング」