システム全体を階層で理解して「あるべき状態」を知る

技術と情報の管理

「階層」を意識してシステムを理解する

一般に、システムは「階層」で理解するものである。これは、コンピュータの歴史そのものが、電流が「流れる」あるいは「流れない」を、ON/OFFで表現したハードウェアの一番下位の階層から抽象化を繰り返し、常に階層を積み上げてきたことによるものだからだ。あるシステムに対する理解を深める際には、この「階層」を意識することで、理解が進むことが多い。それでは、あるシステムを理解するうえで、どのような観点で階層を意識すればよいのだろうか。システムの一番上位の階層から順番に、見ていくことにしよう。

まず、エンドユーザーに「機能／サービス」そのものを提供するための、「アプリケーション」である。この階層が、エンドユーザーに見えている「システム」のすべてと言ってもいいだろう。システム運用者の使命は、このアプリケーションを正常に稼働させることがすべてとなる。 本書の読者ならおわかりのことだが、アプリケーションの下の階層には 次の4つがある。

1. ミドルウェア
2. （1）が動作する前提となるOS
3. ネットワーク
4. （1）から（3）が動作するハードウェア

ITシステムは、これら個々のレイヤ（層）が正常に動作することと同時に、これらが正しく協調することで初めて、機能をユーザーに提供することができる。

そのため、システム運用の立場では、「そのシステムが正常に稼働する」とはどういう状態なのかを、正しく理解することが必要となる。例えば、システムにトラブルが発生して、システム運用担当者に、エンドユーザーからトラブルの連絡や問い合わせがくる場面を想定しよう。

「アプリケーションが動作しない」「動作はするが動きが怪しい」「ユーザー自身が想定している動作と異なる」といった異なる症状が起点となる。したがって、システム運用担当者は、まずはアプリケーションの機能を理解することが必要となる。

ミドルウェア

アプリケーションの機能を正しく理解することは、すなわちアプリケーションの「動き」を理解することだ。「動き」を理解するには、アプリケーションがどのようなアーキテクチャを持ち、どういうミドルウェアの上で、そのアプリケーションが構築し開発されているのかを、理解することが重要となる。ここで言うミドルウェアの代表的なものとしては、次のようなものがある。

1. データベース
2. Webサーバー
3. Webサーバー、コンテナを含めたWebアプリケーションサーバー
4. 開発言語、フレームワーク、ライブラリ
5. 特定の機能を提供するためのサーバー、中間ゲートウェイなど

アプリケーションは、こういったミドルウェアを組み合わせ、さらに、それらのAPI（Application Programming Interface）を用いて開発されている。

また、昨今のシステム開発では、Webアプリケーションのアーキテクチャが採用されることがほとんどだ。Webアプリケーションでは、ブラウザーをユーザーインタフェースとし、Webサーバーの後ろにいるアプリケーションサーバー上のソフトが、さらにその裏に配置されるDBとやり取りすることで、アプリケーションとしての機能を提供する。このようなWebアプリケーションにおいては、アプリケーション＋ミドルウェアを含めて、「Model」「View」「Controller」という3つの階層で、システムを捉える（図1）。いわゆるMVCモデルだが、このようなモデルとしてアプリケーションやミドルウェア層を捉えることも、システムを理解するうえで有効である。

図1 MVCモデルの概要

OS（オペレーティングシステム）

どのアプリケーションでどのようなミドルウェアが用いられるかは、アプリケーション開発における設計思想に依存する。運用側から指定できることはまずない。システム運用者は、どのようなミドルウェアが用いられていても対応できるように、日頃から様々なプラットフォームに慣れ親しんでおく必要がある。

さらに、これらのミドルウェアが動作するためのOSには、表1のようなものが使われることが多い。

最近のWebアプリケーションだと、アプリケーション層でOSの違いを意識することはあまりない。そのため、アプリケーション開発者であれば、それほどOSの違いを気にしていない、というのが現状だろう。しかし、システム運用の現場ではそういうわけにはいかない。システムが安定動作するためのメンテナンス作業や、稼働状況のモニタリングを行う際には、OSレベルのコマンドを直接、頻繁に使うことになる。

コマンドレベルでは、コマンドの有無そのものからコマンド名、あるいはパラメーターの指定方法、さらにはコマンド実行結果の表示フォーマットに至るまで、大なり小なりOS間の差異があるので注意が必要だ。

ネットワーク

昨今のシステムでネットワークを使わないものは皆無に等しい。また、クラウドによるサーバーホスティングであれば、システムが「どこに」ホスティングされているかすら、意識しないことも多いだろう。以前にも増して、ネットワークが、正常かつ支障なく通信できることが重要となっている。

「システムの動きがおかしい」ことよりも、「システムにつながらない」という問い合わせがくることのほうが多いかもしれない。あるいは、システムとネットワークの区別がついていないユーザーも多いことだろう。トラブルが発生した場合に、どこに原因があるのか問題の切り分けを行うが、その際、ネットワークの存在を意識しておくことは重要だ。

ハードウェア

最後に、ハードウェアだ。コンピューターのハードウェアは機械なので、必ずいつかは故障する。かつてのスーパーコンピューターや大型汎用機、ワークステーションの時代には、厳重な品質管理の元で生産されたハードウェアを使って、システムが構築された。しかし今日では、システムの設計思想やコスト意識が変化してきている。そのため、厳重な品質管理のもとで設計・生産されたハイクオリティのサーバーやストレージではなく、コンシューマー向けの低コストなPCを基盤とするハードウェアが中心となった。

これは、「壊れては困るので、品質管理を厳重に行う」という発想から、「壊れてもいいように、数を用意しておく」という発想への転換である。この最たるものが、クラウドコンピューティングだろう。そこでシステム運用者は、「ハードウェアは故障するもの」という認識のもと、壊れてもサービスに影響を与えない、迅速に復旧させることが重要であり、どこの何が壊れたのか、それによって、どういう範囲に影響がおよぶのか、を判断する必要がある。