はじめに
構成情報の維持および配布を目的とする構成システムは、あらゆるエンタープライズソフトウェアシステムの基幹的コンポーネントです。サーバーが数台しかない小規模の企業では、レジストリ項目と個々の構成ファイルから成る非常に単純な構成管理ソリューションで済みます。しかし、組織の規模が拡大して複雑さが増し、物理的に複数の場所で多くのコンピュータを稼動させるようになると、関連するソフトウェアコンポーネントを正しく構成することは重大な課題になります。本稿では、構成情報の保管に利用できるさまざまなストレージ戦略を説明し、簡単に実装できる構成システムを提案します。
まず、大企業のサーバーとソフトウェアコンポーネントの構成プロパティを管理する便利なシステムに必要な属性を考えてみましょう。このようなシステムの主な特性を優先順位の高い順に示すと、次のようになります。
- ストレージおよび管理の中央集中化
実際に設定値が中央に保管されているか、ツールを使って中央集中ストレージのように見せるかに関係なく、設定値は中央で一括管理しなければなりません。
- 設定のローカライズ化
システムはプロパティ値をモジュール、サーバー、またはソフトウェアが動作する場所（たとえば、ソフトウェアの特定の部分、つまりモジュール）に割り当てることができるだけでなく、もっと汎用性の高いホストサーバーやロケーション（1次データセンタや災害復旧施設などの物理的な場所）にも割り当てることができなければなりません。この機能によって（たとえば）サーバーレベルでログファイルディレクトリを設定する（同じサーバーにあるすべてのソフトウェアモジュールを同じディレクトリに記録する）ことや、ロケーションレベルでエラーレポートWebサービスを割り当てる（1つロケーションにあるすべてのサーバー上で実行されているすべてのソフトウェアモジュールが同じ値を共有する）ことをサポートします。
- 信頼性
万一、ネットワーク障害やデータベース障害が発生しても、ソフトウェアコンポーネントは「適切に」動作するために必要な構成情報を取得できなければなりません。このような障害の際、ソフトウェアは完全には実行できないかもしれませんが、入手可能な構成により、少なくともエラーをログに記録したり、メッセージを動作可能なコンポーネントに転送したり、復旧するまで作業要求をキューに入れたりできることが必要です。
- スケーラビリティ
数多くのサーバーやソフトウェアコンポーネントが非常に速く構成情報を読み取っている場合でも、構成システムは需要の増加に対応できなければなりません。
ストレージと配布戦略
これまで、ソフトウェア構成情報を保管する主要な方法は、（1）レジストリ、（2）.configファイルと.iniファイル、（3）中央集中データベース、および（4）カスタムテキストまたはXMLファイルの4つでした。これらの戦略はそれぞれに長所がありますが（変更の容易さ、ツールの可用性、取得の速さなど）、エンタープライズソフトウェア環境の規模が拡大して複雑さが増すにつれて、それぞれ問題が出てきました（表1を参照）。
表1 構成情報の代表的なストレージ戦略とその長所・短所
| ストレージ | 長所 | 短所 |
| レジストリ | ローカルストレージ、読み取りが速い、ネットワーク障害やデータベース障害に強い | サーバー数が多いと維持が非常に面倒になる可能性がある |
| 構成ファイル | ローカルストレージ、読み取りが速い、ネットワーク障害やデータベース障害に強い | ツール不足のために維持が非常に難しい |
| 中央集中データベース | 中央での一括管理 | 読み取りが遅い、サーバー数の増加に対応しにくい |
| カスタムファイル | ローカルストレージ、読み取りが速い、ネットワーク障害やデータベース障害に強い | ツール不足のために維持が非常に難しい |
構成システムを構築する
これから説明する構成システムには2つの目標があります。1つは中央構成ストレージ、もう1つはエンタープライズレベルでの構成プロパティの配布です。
著者注
本稿に出てくる「モジュール」という用語は、単一のエンティティとして実行（または構成）されている、ソフトウェアの論理的な部分のことです。「ロケーション」とは、類似の構成を持つサーバーの物理的または論理的なグループのことです。また、「プロパティ値」とは、ソフトウェアシステムの動作に影響を与える名前付きの情報のことです。
