ネットサービス基盤を支える3つの掟：インターネットサービスの新基準（2/2 ページ）

[大澤文孝，ITmedia]

　セキュリティアップデートをホスティングサービスに依頼する場合、注意したいのは、サーバの基本的なパッケージのみのアップデートであるという点だ。つまり、OS本体やRPMパッケージなど、パッケージ化されたものだけが更新対象となる（図2）。更新から除外されてしまうのが、独自にカスタマイズなどを行ったソースから構築している場合や、Webアプリケーションが独自のライブラリを使っている場合である。このようなソフトウェアは更新対象とならないため、関連する情報に日ごろから目を光らせておく必要がある。このような点からも、近年では、商用のWebアプリケーションを構築する場合には、よほどのカスタマイズを伴うチューニングが必要な場合を除き、ソフトやライブラリをソースから構築することなくパッケージとしてインストールすることがほとんどだ。

　Webアプリケーションを構築する場合には、運用時の手間を省くためにも、「できる限り標準構成で稼働するよう構築すべき」というのが、商用のインターネットサービスにおいて重要なポイントだと言える。

図2■セキュリティアップデートの対象範囲

死活監視と改ざん検知に対しては

　インターネットサーバは24時間稼働していることが必須だが、時にはサーバが停止したり、サーバ上のプロセスが異常終了することも考えられる。そこで定期的にサーバが活きているか、それともダウンしているのかを調べ、通知が可能な死活監視があるとよい（図3）。サービス利用者からの通知によってサーバダウンを確認できた、という後手の事態は避けたい。

図3■死活監視

　死活監視の基本は、定期的に該当サーバにpingを実行し、その応答が帰ってくるかを調べるものだ。しかし、最もベーシックなpingコマンドによる確認では、実際のサービス自体が停止しているかどうかが分かりづらい。そこで近年は、Webで利用している80番ポートやメールで使う25番ポートなどに実際に接続し、応答が返ってくるかどうかを判定するものが多くなってきた。ただし、サーバがダウンしていた場合の対応は、死活監視サービスによって異なることも忘れてはならない。

　ダウンしていた場合には、管理者にメールで通知することが基本だが、さらに対処方法を一歩進め、サーバを自動リセットするオートリブート機能を提供するホスティングサービスもある。

　オートリブートに対応していると、迅速な自動復帰が期待できる。しかしその半面、「何が原因でトラブルを起こしたのか？」という原因究明が難しくなるデメリットもある。このような形態では、定期的にシステムログを確認する必要性があるだろう。サーバが停止するという事態は、そもそも何らかの不具合があるからであり、リセットによって復旧するからといって原因究明せずに放置しておくと、大事に至ることがあるからだ。

　ちなみに当然ではあるが、オートリブートの契約をしている場合には、サーバをメンテナンスする際に、Webサーバやメールサーバなどを長期にわたって停止すると、意に反してリセットを実行されてしまう。そのため、メンテナンスする際には、オートリブート機能を忘れずにオフにしなければならない。

　停止する方法は、ホスティング事業者にあらかじめ「何時から何時までは停止してほしいと事務的に伝える方法」と、「自分で好きな時にWeb管理画面などからオフにできる方法」がある。

　サーバの運用や監視は、「できる限り自動化を心がけたいもの」と筆者は考える。これは、作業そのものが単純で人手を介したくないという理由もあるが、むしろ、人手を介すと見過ごしてしまう部分を回避できるからである。サーバダウンを起こした理由の大半は、人為的なミスによるもの、という統計があるほどだ。ホスティングサービスを選ぶ場合には、これらの運用面のサポートも重視すべき項目だといえるだろう。