Java EE勉強会

BSA / Configuration

BSA

Configuration（コンフィギュレーション） †

要約 †

  • コンフィギュレーションでは、何を、いつ、誰が、正しく設定させるのか、あるいはさせないのかの設計が重要。

内容 †

  • 複雑なシステムは利用可能となるように構成する必要がる。残念ながら、これは一般的に議論されなのでシステムが最終的に必要以上に複雑な構成になってしまう。
  • だからこそ、構成の容易さがマーケテクトとターキテクトの両方のために価値のある目標だ。この章では、構成パラメータと、可能な限り簡単にシステムを構成させるための方法を説明する。

構成の容易さ（Configurability）　ー　ユーザビリティの構成要素 †

全体的な使いやすさの次元で構成可能性を気にする主な理由はコストだ。構成の困難なシステムは、

  • 運用コストを増加させ、使用が困難。
  • パフォーマンスを調整することが困難。
  • テクニカルサポートのコストを増加させ、技術サポートをより必要とする。
  • 競争上不利な立場にあなたを落とし入れて、全体的な顧客の不満を増やす。

モジュラーシステムが構成の要求を高めている。簡単な構成への強いコミットメントがなければ、構成のコストは、アプリケーションの寿命にわたって増加していくのがわかるだろう。 構成の容易さを設計する必要がある。そうすることはすべての人の最善の利益になる。使い勝手の面では、構成容易性は、適切な数の設定パラメータを持たせるべきだ。

システムコンテキスト †

構成パラメータ構造の技術的な詳細を心配する前に、何が設定可能であるべきかを考えてみよう。これらのパラメータでキャプチャする必要がある基本的な情報はシステムコンテキストです　ー　それは適切な機能システムのために必要なコンテキスト情報のすべての側面です。これらのデータをキャプチャし、それらを設定することにより、開発時にではなくデプロイ時に主要なパラメータを設定する機能でを顧客に提供できる。遅延バインディングのこのプロセスは、システムがより柔軟になり展開がはるかに容易になる。


コンテキスト情報 †

開発チームの主要メンバーに知られるよう、コンテキスト情報を特定することは、ターキテクトの仕事だ。これは、いくつかの考慮すべき特定の領域だ。

  • キーファイルとディレクトリの場所
    • 多くの複雑なシステムは、システムのインストール時に設定し、ランタイム環境用の設定ファイルに記録されている、事前定義された既知のファイルまたはディレクトリに依存している。
  • ブートストラップデータ
    • ほとんどの技術システムは、ブートストラップの様々な種類の情報を必要とします。コンピュータにはBIOSが必要だ。アプリケーションには、プログラムの実行を開始するには、オペレーティングシステムのエントリ・ポイントが必要だ。
    • これらのブートストラップデータは失われうることに注意してください。そして良いディフェンシブな設計技術としては、システムがそれなしの合理的な機能の最小セットで実行できるようにすることだ。
  • ポータビリティスイッチ
    • 特殊なコンテキストは、システムの移植性を扱うものだ。例えば、私が働いたチームは、Oracleまたはシステムコンテキストが229のSQLServerを使用して、構成することができるシステムを設計した。それらのシステムが各データベースのパフォーマンス特性のために調整若干異なるSQL文を使用するため選択が重要だった。
  • 互換性のコントロール
    • 開発チームは、古いバージョンをサポートする方法の課題に直面している。気まぐれな任意決定を行う代わりに、顧客にそれを返して、任意の数の構成パラメータを通して決定させる。
  • パフォーマンスパラメータ
    • 性能パラメータは、タイムアウト値から、インメモリストレージ要件、システムを自動的に維持するデータベース接続の数に及ぶ。真に洗練されたアプリケーションは、セルフモニタリングしたシステムのパフォーマンスに基づいて、これらのパラメータを調整することができるが、多くはユーザーがシステム起動時に指定するシンプルなパラメータで設定することを許可して逃げることができる。

コラム：良いことが多すぎる（Too Much of a Good Thing） †

これは、ユーザインタフェースのデフォルトのレイアウトに割り当てられるべきであるどのくらいのデフォルトメモリからすべてについての意見の相違を平和的に、解決しようとする目的をもった開発チームでスタートしました。それらが終わった頃には、私はちょうどお客様が当社のソフトウェアをインストールおよび構成を支援するエキスパートシステムを必要とすることを恐れていた。 私たちは、あまりにも多すぎるオプションの設定パラメータを持っていた。各パラメータは、良い感じだった。全体で、システム管理者に途方にくれる選択肢のリストを提示した。私たちは、堅実でオンラインヘルプおよびパラメータへの変更は、システムのパフォーマンスに影響を与える方法の例をたっぷり使って、賢明なパラメータグループを作成することによって、実行可能な解決策に到達するように管理した。それでも、私は私なりの教訓を学んだし、設定パラメータの中に何かを置くことについてより慎重になった。 良いルールは、システムがプロキシサーバのように、それが設定されずには機能することはできない場合にのみこそ何らかの設定パラメータでなければならないということです。何かが賢明な方法で変えることができる場合、または単にあなたのユーザーより大きな柔軟性を提供したい場合は、そのカスタマイズパラメータにして、合理的なデフォルトを提供なさい。違いは微妙ですが重要だ。設定パラメータは通常、動作するようにシステムに正しく設定する必要があり、彼らは彼がやっていることを知っている人（例えば、システム管理者）によって設定されなければならないことを意味する。いくつかのオブジェクトの属性であるべきカスタマイズ情報は、すべてが設定されない場合がある。 ところで、あなたは構成パラメータを管理するためのエキスパートシステムを必要とすることが過剰だと思う場合には、XCONという最も有名なエキスパートシステムはDEX VAX computerを設定するために特別にされたことを覚えておいてください。

初期化　対　実行 †

  • 基本的にシステムを構成できる時は２回ある。実行前と動作中です。前のセクションで説明したように、すべてではないにせよ多くの構成パラメータ情報は初期化中に処理される。必要なコンテキスト情報を取得するためにこれらのデータを読み取ることに加えて、システムはまた総エラーと構成の不整合を処理しなければなりません。実績のあるアプローチは、矛盾を無視する賢明なデフォルトを選択し、エラーを記録することだ。エラーを無視することはできない場合は、処理を停止し、そのことをユーザーに知らせる。
  • システムの初期化中に処理る構成データを必要とするの欠点の1つは、ユーザーが一見些細な変更のためにシャットダウンして再起動が必要になることがあることだ。これは、単純なシステムなら許容されるが、複雑なシステムのために耐え難くなりやすい。
  • また、逆に動作中に設定を変更できるシステムは、データを構成に対する重要な変更をシステムに通知する方法があるか、システムがそれ自身の通常動作中に重要な変更を発見することができる設計とする必要がある。

値の設定 †

  • 設定が必要な値と時とを決定したら、それらを設定できるのは誰なのかを検討する必要がある。3つのエンティティが一般的です：システム管理者など人間。2つのシステムが値を交換したり相互運用のためのコマンドを受信するような別のシステム。もしくは、1つ以上の値を自動設定するように設計された時のシステムそれ自身。システムは、仕事を得るために3つの任意の組み合わせに依存することができる。
  • 値を設定するエンティティは設定パラメータを変更することを許可されているものとするが、これは、すべてのエンティティがこの権限を持っているべきであることを意味するものではない。それが変える影響を完全に理解するように、各パラメータ、またはパラメータの各クラスが検討されていることを確認してください。 任意の個々のユーザーが任意のパラメータを変更できるようにしたくない場合がある。そうでない場合、適切なシステム管理者が適切な値を変更することを保証することを通した管理者アクセス権の保護によって、システムに保存する設定データが必要される。
  • 必要な場合は、データベースにこれらのデータの監査証跡を作成することによって、監査を管理するために必要なすべての設備を提供することも検討したほうが良い。
  • 1つ以上のエンティティが同じパラメータを変更する権限を付与され、あるエンティティが他を上書きすることができる状況が必要なときは興味深い課題が出てくることがある。私は、アクティブなデータベース接続の数は、システム管理者によって、または独自の性能の評価に基づいて、システム自体のいずれかによって設定できるアプリケーションを作成した。管理者がとてつもなく低いまたは高い値に設定した場合に、システムが自動的に値を調整することができた。

正しい値の設定 †

  • 設定パラメータについての議論では、ターキテクトとマーケテクトはそれを一緒に議論し、パラメータ設定によって影響を受けるユーザーのニーズと設定するユーザー（またはシステム）のニーズの両方を満たす必要がある。
  • 前のセクションでは、設定値をエンティティに与えるために必要な情報を提供しました。簡単に言えば、彼らが設定する値をどのように、なぜ、それら（書式設定および有効な値を含む）を設定すると、システムの動作に影響をおよぼすのか、知る必要がある。外部の文書またはWebサイトに隠すのではなく、ファイル自体にこの情報を与えなさい。
  • （書籍のP232の例の設定ファイルを参照のこと）
  • これらのパラメータ（ターキテクトによってレビューされた個々の開発者の仕事）の初期に説明を書くべきではありません。しかしながら、彼らは重要な情報を構造化し通信する方法を知っているので、最終的なレビュープロセスに関与させるべきです。

構成パラメータの発見（Configuration Parameter Heuristics） †

設定パラメータを設計する際には、次の発見的方法（heuristics）が便利です。

  • システムの残りの部分がダウンした場合でも、それらの変更が用意にさせる。これは単純で簡単に管理できる非バイナリ形式で、外部からそれらを保存できることを意味する。
  • 一箇所にすべてのデータを格納する。あなたが複数の場所でそれらを持っている必要があると思う場合は、信頼できる人を見つけて、複数の場所にデータを格納することは良い考えであることを納得させなさい。
  • 明白な名前で明白な場所にファイルを保存します。私はインストールされたアプリケーションのルートディレクトリのような「システム構成データ（ystem Configuration Data）」のような名前と場所をお勧めする。
  • .iniなどのプラットフォーム固有のファイル形式でも大丈夫ですが、なぜXMLを使用しないのか？それは、あなたが必要とする程度に冗長で、管理が容易で、簡単です。
  • レジストリエントリのようなものに注意してください。それらはポータブルではなく、技術的な知識のないユーザーにとっては変更することが困難な場合がある。
  • 構成データは簡単にキャプチャして、テクニカルサポートに転送できるようにしなさい。驚くべきことに多くの問題は、システムが構成されている方法を理解すれば、技術サポート担当者が解決することができる。
  • 間違った値を設定することが困難なようにしなさい。間違っている場合は、できるだけ早くユーザに通知し、実行を停止したり、適切なデフォルト値を続行の可能ないずれか。
  • ほとんどの回復力のある設計は、構成パラメータは、いくつかのエンティティまたはオブジェクトの永続的な属性であるという考えに基づいている。これは、他のオブジェクトまたはサブシステムに、このオブジェクト内の情報に対処し、INIファイルまたはXMLファイルを管理する方法を心配させないことを可能にする。これらの属性は、多くの場合、異なるオブジェクトに貼り付けることができるので、ターキテクトは、次のいずれかが有用かもしれないことを考慮すべきだ。
    • システム全体のコンテキストに関する情報を格納するためのシステム・コンテキスト・オブジェクト
    • コンピュータごと、サービスごとのインスタンス、ユーザごとの、あるいは選択可能なユーザープロファイルごとのオブジェクト
    • コンフィギュレーションデータのセマンティクスを取り込むオブジェクト システムの開始時に必要とする正しい構成データのすべてを取得する必要はないが、改修が煩雑になる可能性があり、そしてアーキテクチャの変更を必要とするかもしれない、ということを覚えておいてください。

❑❑❑❑❑❑❑❑❑

章の要約 †

  • 構成は、ユーザビリティの重要な側面です。システムを設定することが困難である場合は、顧客は最大能力でそれを使用することはできません。
  • コンフィギュレーション・パラメータが適切に機能するシステムに必要なコンテキスト情報の全てであるシステムコンテキストを、捕捉するように設計されるべきだ。例えば、キーファイルとディレクトリ、ポータビリティスイッチ、および互換性コントロールの位置を含む。
  • 2回、システムを構成する必要がある場合がある。起動時と動作中。実行中に値が変化を処理できるシステムがデバッグのために良い。
  • 顧客は、適切な値を設定する際に支援を必要としている。彼らにそれを与えられる。

Check This (これをチェック) †

  • 我々は、すべてのシステム構成パラメータを定義した。各パラメータについては、我々はそのセキュリティーおよび監査要件、そしてそれが唯一の初期化時に使用されているか、システムの実行中に変更することができるかどうかをを定義している。
  • 私たちは、それぞれの値を設定する方法を文書化しており、それを正しく設定するためのガイダンスを提供した。

Try This(これを試しなさい) †

  • 新しい設定パラメータを追加するときに・どのように選ぶのか？チーム内の誰がこれを行うには許可されるのか？
    • どこに設定パラメータのドキュメントが格納されているか？ユーザーは、構成ファイルから必要なすべてを取得することはできるか？
    • 誤った値が設定されている場合、あなたのシステムはどのように耐性があるか？何が起こるのか？あなたはこれをテストしたことがありますか？

Menu