Infrastructure As Codeでモジュール化が難しいのはなぜなのか

Infrastructure As Codeにおいて、コードのモジュール化により再利用性を高めることが難しいと言われている。それはなぜなのかを考察する。

1つ目の理由は、サーバ上のファイルシステムクラウドサービスの設定などのインフラはグローバルの共有空間に状態をもつことから、状態管理をモジュール内に留められない(カプセル化ができない)ことだ。複数の異なるモジュールが共有空間を操作してしまい、操作が競合することがあり得る。

この問題によって、モジュール単位で単体テストを書いても、複数のモジュール間が混在する環境では動作を保証できない。Serverspecは最後に状態が収束した結果をテストすることにより、サーバ構成管理の範囲でこの問題を解決している。

現在では、サーバ構成管理については、コードをモジュール化するのではなく、コンテナのようにより小さい粒度で状態空間を作成して、空間を局所化することにより、操作の競合を防ぐことが一般的である。

2つ目の理由は、モジュールを作成するときに、モジュールへの入力パラメータが多いほど、入力パラメータ数に比例してコードを書かなければならないため、モジュールを作成・メンテナンスするためのコストが高くなることだ。例えば、nginxやMySQLなど一部のミドルウェア、非常に多くの設定パラメータをもつ。

したがって、特定の組織やシステムに必要なパラメータのみを入力として受け付けるようにして、それ以外はデフォルト値や推奨値でパラメータを固定するといった解決をすることがある。

3つ目の理由は、昨今のクラウドサービスでは、非常に多くのコンポーネントを利用することがあるため、単純にそれらのコンポーネントの設定を逐一コード化するための手間が大きいことだ。

したがって、検証のために試行錯誤したいときや、ほとんど変更しないと分かっているコンポーネントはコード化しないといった判断をすることがある。

3つ目の理由はコード化が疲れる理由であって、モジュール化が難しい理由ではなかったので、削除した。

他にも理由はあるかもしれないが、思いついたのは一旦ここまで。

追記

3つ目の理由として、モジュールの作成時に、OSやネットワークスイッチなどインフラの環境の差異をモジュールが吸収しようとすると、環境ごとの分岐処理が追加されるため、理由2と同様に、モジュールを作成・メンテナンスするためのコストが高くなることがある。