上流設計品質管理のポイント

2. ネットワーク構成設計のチェックポイント | 4. 外部仕様設計のチェックポイント

3. 管理機能設計のチェックポイント

管理機能に漏れがないかをチェックする

通信・ネットワークシステムでは、システムへの直接的な要求事項を実現する機能(メイン機能)のみならず、システム自体を管理するための機能(管理機能)が重要なウェイトを占めることが少なくありません。管理機能というのは、メイン機能のためのデータ管理などとは異なります。例えば、システム利用者情報の追加・削除・変更などといった機能はメイン機能の一部であって、ここで意図する管理機能ではありません。どういった機能が管理機能に含まれるかというと、システムの起動や停止、通信経路やパフォーマンスの監視、システムの動作パラメータの変更、運用開始後のノードの追加・削除などです。通信分野でOAMと呼ばれている機能がこれに含まれます。

管理機能がどこまで要求されるかは、システムによって異なります。通信経路やパフォーマンスの監視は、システムの規模が大きい場合や高い信頼性が要求される場合には必要となる機能ですが、あらゆるシステムで必須という機能ではありません。運用開始後のノードの追加・削除は、同一種のノードを複数台配置するようなシステムで必要になる機能です。他方では、システムの立ち上げや停止、システムパラメータの変更などのように通信・ネットワークシステムであれば必ず検討しなければならない機能もあります。

メイン機能は直接的な要求を実現する機能ですから、比較的設計漏れということは少ないでしょう。それに対し、管理機能は開発者に意識されることなく設計から漏れてしまうことがしばしばあります。上流設計で管理機能の設計が漏れてしまうと、メイン機能は要求を満たすものの運用手順が現実的ではないというようなシステムが仕上がってしまう恐れがあります。ですので、上流設計の段階で開発対象のシステムで必要となる管理項目が不足なく設計されていることをチェックすることが望まれます。次の表に代表的な管理機能を挙げて、それらの機能が必要となる状況を整理してあります。チェックの際の参考にしてください。

管理機能設計の必要性説明
システムの立ち上げ常に設計が必要立ち上げ時にノード間で通信の確立や情報の同期を行わなければならない場合には、システムの立ち上げ時に何らかの処理が必要となります。そうでない場合は、ノードごとに独立した立ち上げ機能を用意すればよいでしょう。
システムの停止常に設計が必要実運用に用いるシステムでは、いきなりシステム全体を停止するのではなく、提供中のサービスを安全に終了してから停止するといった処理が求められることが多いでしょう。
サービスの一時停止と再開連続運用を行うシステムでは検討が必要メンテナンス等のためにサービスを一時停止できる機能が求められるケースも少なくありません。その場合には、システムの停止や立ち上げと同様な配慮を求められることになるでしょう。
システムのパラメータ変更常に設計が必要どのようなインタフェースによってパラメータを変更するのかは設計が必要です(インタフェースの例:Web、SNMP、設定ファイル)。また、サービスを止めずにシステムのパラメータを変更すること(パラメータ動的変更)が求められる場合には、ノード間のデータの同期や各ノード内でのデータの反映など、設計および実装においてさまざまな工夫が必要となります。
通信経路の監視大規模もしくは高信頼性が要求されるシステムでは検討が必要人手による管理では膨大なコストがかかる大規模システムや、高い信頼性が要求されるシステムでは、通信を行うノード間で通信経路の切断などによる通信断がないことを監視する機能が求められます。通信断を検出した場合の動作も設計が必要です。
ノードのパフォーマンス監視大規模もしくは高信頼性が要求されるシステム、高負荷での運用が予想されるシステムでは検討が必要人手による管理では膨大なコストがかかる大規模システムや高い信頼性が要求されるシステム、高負荷が予想されるシステムでは、各ノードのパフォーマンス(CPU使用率、メモリ使用率、ディスク使用率など)を定常的に監視する機能が求められます。過負荷を検出した場合の動作も設計が必要です。
構成ノードのプログラム更新連続運用を行うシステムでは設計が必要機能追加や不具合修正などは一般に必要となるため、運用中のプログラム更新をどのように行うかを設計する必要があります。一時的にバージョンが一致しないノードが混在してしまう状況に関する配慮も必要です。
構成ノードの追加同一種のノードが複数配置されるシステムでは検討が必要運用中にノードの追加が行われる場合、既存ノードのネットワーク構成情報をどのように更新するか、新規追加ノードと既存ノードとの間の通信の確立や情報の同期をどのように行うか、などについて設計が必要です。
構成ノードの削減同一種のノードが複数配置されるシステムでは検討が必要運用中にノードの削減(切り離し)が行われる場合、切り離しノードで提供中のサービスをどのように取り扱うか、残されるノードのネットワーク構成情報をどのように更新するか、などについて設計が必要です。

表1. 通信・ネットワークシステムにおける代表的な管理機能の例

オペレーションを含めた設計になっているかをチェックする

管理機能を設計するにあたっては、オペレーションを想定する必要があります。ここで言うオペレーションの想定とは、管理に際して人手でどのような操作を行うのかといったことや、サービスを止めることを許容するのかといったことのように、システムの外部でどのような取り扱いをするのかということです。

例えば、システムの立ち上げを考えてみると、人手による特別なオペレーション無しにシステムの起動が行えるようにするためには、立ち上げ時にシステムを構成するノード間でそれなりの通信を行うような設計が必要になります。それに対し、ノード間での情報の同期や起動順序の制御を人手によって何とかするということであれば、各ノードは他のノードとの連携は考えずに自身のみの起動ができれば良いということになります。また、別の例としてシステムパラメータの変更を考えてみると、パラメータの変更タイミングをシステムの停止・再起動時に限定するということであれば、各ノードに要求される機能は起動時に設定ファイルに書かれたパラメータを読み込むということに限定することも可能です。それに対し、システムの停止を伴わずにパラメータの変更が必要ということであれば、ノード間でのパラメータの同期やノード内でのパラメータの動的更新など、設計しなければならないことが数多く出てきます。

裏を返せば、管理機能の設計次第で運用開始後のオペレーションが左右されるということです。オペレーションを明確にしないままに管理機能設計を行ってしまうと、システムの完成後に実運用では許容できないようなオペレーションが必要だということが判明した、などということが起こりかねません。ですので、上流設計における管理機能の設計ではオペレーションを明確にし、発注者による運用観点でのチェックが行われることが望まれます。次の表に代表的な管理機能におけるオペレーションを踏まえた設計例を整理しましたので、チェックの際の参考にしてください。

管理機能オペレーションシステムの設計で求められる配慮
システムの立ち上げ人手によるノード間での情報の事前同期を必要とせず、かつ各ノードを任意のタイミングで起動可能ノード間で近隣ノードを探索するプロトコルおよび検出された近隣ノードと情報の事前同期を行うプロトコルを設計する必要があります。
設定ファイルを用いて人手によりノード間で情報の事前同期を行い、所定(サーバ→クライアント)の順番でノードを起動サーバは起動と同時にクライアントからの通信接続を待ち、クライアントは必要なタイミングでサーバへの通信接続を行うといった簡易な設計でよいことになります。
システムの停止人手を介さずに提供中のサービスを安全に終了した後にシステムを停止システム停止の指示を受けると各ノードが新しいサービスの受付を中止し、提供中の全サービスの停止処理が完了した後にシステムを停止するという設計が必要になります。
人手によって提供中の全サービスを停止してからシステムの停止システムは特段の配慮なく停止処理を行ってもよいことになります。
システムのパラメータ変更システムの運用中にパラメータの変更が可能各ノードにはSNMPやHTTP等によるパラメータ変更インタフェースを用意する必要があります。また、ノード間でのパラメータの同期が必要となるような場合には、各ノードに一括してパラメータの変更指示を行うような中央管理的なノードを設計しなければならないこともあります。
パラメータの変更はシステム停止・再起動のタイミングに限定各ノードのパラメータは設定ファイルに書き、起動時に設定ファイルからパラメータを読み込むという設計のみでもよいことになります。
通信経路の監視通信経路の切断を検出した際には自動的に縮退運転を開始ノード間でメッセージのping-pongを行うことで通信経路の監視を行い、切断を検出した際には障害の発生した経路を使わない縮退運転を開始する設計が必要となります。縮退運転の内容も設計しなければなりません。
通信経路の切断を検出した際にはオペレータが迅速に対応策を実施ノード間でメッセージのping-pongを行うことで通信経路の監視を行い、切断を検出した際には何らかの迅速な手段(SNMP TRAPやE-Mail等)でオペレータに通知するという設計が必要となります。
ノードのパフォーマンス監視ノードの過負荷を検出した際にはシステムが自律的に負荷を下げるための対処を実行SNMP等で定常的にノードのパフォーマンス監視を行い、過負荷を検出した際には新規サービスの受付停止や一部サービスの強制停止などによって負荷を下げる機能の設計が必要となります。なお、通常はオペレータへの迅速な通知も同時に行うでしょう。
ノードの過負荷を検出した際には、オペレータが迅速に対応策を実施SNMP等で定常的にノードのパフォーマンス監視を行い、過負荷を検出した際には何らかの迅速な手段(SNMP TRAPやE-Mail等)でオペレータに通知するという設計が必要となります。
構成ノードのプログラム更新オペレータが現地に赴かずに遠隔操作でノードのプログラムを変更遠隔地からノードにプログラムの更新を指示するプロトコル、ノードが遠隔地からプログラムのダウンロードを行うプロトコル、ノードが自動的にプログラムの更新を行う機能の設計が必要になります。
オペレータがプログラムを書かれた物理メディアを持参してノードを直接操作してプログラムを変更ノードには物理メディアに書かれたプログラムを読み取って更新する機能があればよいことになります。
構成ノードの追加システムを停止せずに運用中にノードを追加新規追加ノードが近隣ノードを探索するプロトコルおよび検出された近隣ノードと情報の事前同期を行うプロトコルを設計する必要があります。
システムが停止したタイミングでノードを追加して新たな構成でシステムを開始構成ノードの追加のために特段の機能を設計しなくてもよいことになります。
構成ノードの削減システムを停止せずに運用中にノードの削減(切り離し)を実施切り離しに先立って切り離すノードに関連した新規のサービス受け付けを停止し、提供中のサービスを終了する処理の設計が必要になります。近隣ノードへの切り離し通知を行うプロトコルの設計が必要になる場合もあるでしょう。
システムが停止したタイミングでノードを削減して新たな構成でシステムを開始構成ノードの削減のために特段の機能を設計する必要はないことになります。

表2. 代表的な管理機能におけるオペレーションに対応して求められる設計上の配慮の例

無料小冊子のお申込みはこちら

株式会社システム計画研究所のオフィシャルサイトはこちら

通信・ネットワークシステム開発に関するご相談はこちら

サーバ監視・ネットワーク監視ツール isNetSentry-S のサイトはこちら

信頼できるITシステムの開発と利用を支援する技術情報提供サイト「信頼のシステム開発.COM」はこちら