要約

  • RFC 2039は、ハードウェア、OS、プロセス、依存関係、容量を見る運用モデルと、Webクライアントの要求と応答を見るサービスモデルを分けた。
  • 1台のホストで3つの仮想ドメインを提供する例は、サービスと実行プロセスの対応が実装ごとに異なり、ホスト情報だけでは障害箇所を特定できないことを示した。

サーバーのランプが点き、CPUにもディスクにも余裕があり、Webサーバーのプロセスが存在する。ここまでの観測はすべて正しくても、動的ページが依存するゲートウェイやデータベースが停止していれば、そのページは利用者に届かない。誤っているのは計測値ではない。そこから別の層の健全性を推定した判断である。

1996年11月にInformational文書として公開されたRFC 2039は、標準化過程のインターネット標準ではない。ロサンゼルスで開かれた第35回IETFのHTTP-MIB BOFを受け、既存の標準トラックMIBがWWWサーバー管理にどこまで使えるかを検討した。その中心に置かれたのが、二つの管理モデルだった。

運用モデルでは、Webサーバーを物理資源とソフトウェアの集合として見る。CPU、ディスク、ネットワーク容量、OS、実行中のプログラム、構成ファイル、ログ、そしてアプリケーション間の依存関係が対象になる。停止や再構成の際には、一つのプロセスが複数サービスを支えている可能性を知らなければならない。

サービスモデルでは、内部をいったん黒箱として扱い、クライアントの要求に何を返したかを見る。取得サービスの利用状況と性能、静的・動的文書、アクセス権限、動的情報を供給するアプリケーションの稼働状態が対象である。

両者は競合する説明ではない。相互補完しながら独立した情報を持つ。マシンが正常でも一つの仮想サービスは壊れ得る。サービスが応答していても、資源余力や依存関係は危機に近づき得る。

一つの箱、三つのサービス

RFC 2039はMIB-II、Host Resources MIB、Network Services Monitoring MIB、開発途上のApplication MIBを検討した。システム、インターフェース、プロセッサ、記憶装置、導入済み・実行中ソフトウェア、ネットワークサービスと接続関係について、有用な属性は既にあった。運用モデルの多くは満たせるという評価だった。

不足が見えたのは層をまたぐ部分である。1台のコンピューターが3つの仮想ドメインを提供するとき、一つのプロセスが全部を担当する場合も、三つのプロセスに分かれる場合もある。静的文書はファイルだけで済む一方、動的文書は外部ゲートウェイやデータベースを通るかもしれない。

プロセス表はWebサーバーが動いていると正しく報告しても、どの仮想ドメインが何を送ったかを語らない。サービス表は各ドメインと通信関係を表しても、修復すべき実行ファイルや下流アプリケーションを特定できない。両者の関係は単純な一対一リンクではなく、実装依存の写像だった。

そのためRFCは、運用側に資源使用量、依存関係、標準化されたエラー報告、容量履歴、ログ相当情報を求めた。サービス側には取得の利用・性能、文書単位の統計と権限、動的生成アプリの状態、集中設定、開始・停止、ログ切り替え、サービス品質の指標を求めた。

ただし、これは要求分析である。普及率、性能改善、障害減少は示していない。記載されたInternet-Draft、メーリングリスト、サンプル実装も展開実績ではない。セキュリティは明示的に論じられていない。

1999年のRFC 2594はWWW Service MIBをProposed Standardとして定義し、文書転送の操作、要求、応答、状態コード、仮想ホスト、統計をサービス指向で扱った。プロセス指向は対象外と明記し、短期の問題発見と診断に範囲を絞った。RFC 2039を形式的に更新・廃止した文書ではないが、サービスにはプロセス台帳とは別の語彙が必要だという分離を具体化した。

情報源