クラウド基盤の構築は、どうしてもテクノロジー優位に進む傾向がある。仮想化や自動化といった比較的新しいテクノロジーを使って、早く安くサービス提供しようとするからだ。しかし、良かれと思って安価に構築したサービスが、規模拡大に伴って問題を抱えてしまうことが少なくない。障害発生時の復旧に時間がかかり、現場の負担増大やサービス停止などが起こる。その結果思わぬコストが発生し、安価なサービスではなくなってしまう。
問題発生の理由は多くの場合共通している。提供しているサービス全体を把握している担当者が小人数しかいない状況で、ハードウエアに付属のユーティリティーソフトの稼働監視機能などを使いこなして何となくサービスを提供してしまうのだ。そして、想定外の事態が起こったときに慌てるのである。
個々のサーバーを個別に運用するのではなく、統合されたシステム基盤として構築するクラウド環境では、ハードウエアやソフトウエアに問題が発生すると、その障害がさまざまなシステムに影響する。そのため、クラウド環境が考慮されていない標準のユーティリティーに頼った従来型の運用では、障害が起こっても、サーバーやネットワーク、アプリケーションのどこに問題があるのか分からない、といった事態に陥るのだ。
にもかかわらず、クラウドサービスの提供に当たって、新規に運用手順を作り直すケースは皆無である。既存の運用の延長でとりあえずハードウエアを入れてしまって、運用は人手でやればよいと見切り発車してしまう。
クラウド環境では、障害時対応を標準のユーティリティーツールの機能だけに頼ってはいけない。既存の運用手順まで見直し、状況の把握や対処が確実にできる仕組み作りが不可欠である。
構成情報の場所と収集方法を整理する
まず重要なのは、システムの構成情報を整理しておくことだ。
クラウド環境を構築したシステムに問題が起こったとき、一番時間がかかるのは状況の把握である。何がどこで起こっているのかさえ分かれば後の対応はそれほど大変ではない。ところがサービスがどのインフラと関係しているのかをメンテナンスするのは容易なことではない。構成管理ツールを導入するのは一つの方法だが、規模やコスト面から導入を躊躇しているユーザーは少なくない。
ではそのような状況で、コストをかけずに具体的に何をすべきだろうか。基本的なことだが、まずはサブシステムごとに構成情報を整理することから始めたい。構成情報がどのシステムに格納されているのか、あるいはどのドキュメントに記載されているのかを把握しておく。そして、それらの構成情報をどうやって収集できるのかを整理しておくことを推奨する。表1は、構成情報を整理した一覧表の例である。
構成情報の更新は大変である。将来的には電子化して構成を最新に保つプロセスを導入すべきだろう。前述のように整理された情報は、電子化に取り組む際にも、非常に有効に活用できる。
