各システムでは、いかにシステム障害の発生を予防し、発生時の影響を最小限に抑えるかが重要な課題の一つとなっています。その解決手段として登場するのが「システム監視」です。「システム監視」を行わなければ、システムに障害が発生しても気づくことができず、利用者から「システムが使えない」と問い合わせやクレームが来てから障害に気づくことになります。

つまり、システム監視とは「次の2点を事前に確認し、必要に応じて関係者へ通知を行う仕組み」と言えます。

• システムが正常に稼働しているか
• システムに障害予兆となる兆候はないか

一方、運用／保守性の要件にあわせたシステム監視を行うには複数種類の監視方法があり、複雑に組み合わせながら構築することになります。今回は、システム開発で必ず必要となるシステム監視の基本的なシステム構成と様々な監視方法について解説したいと思います。

システム監視が定義される非機能要件「運用／保守性」をやさしく解説！もあわせて参照ください。

システム監視の基本的なシステム構成

一般的なシステム監視のシステム構成イメージを以下に示します。

システム監視では、監視する側、監視される側といった役割が発生します。
監視する側が「監視サーバー」、監視される側の機器を「監視対象機器（Web/APサーバなど）」とよびます。

多くの場合、「監視サーバー」は下記のような監視情報を収集※し、運用者／管理者がパソコン画面で確認し、メールでも監視情報を受信するといったシステム監視を行っています。

※システム監視で収集する情報の例

• Web/APサーバーと通信状況
• DBサーバーのCPU負荷状況
• 共有ストレージのディスク容量
• 機器それぞれのログに怪しいメッセージ出力がないか

念のため補足すると、クラウドサービスではシステム監視に対する考え方が若干違うので注意が必要です。

例えば、AWSには各種リソースを監視してくれるフルマネージドの運用監視サービス「CloudWatch」があり、監視サーバーといった考えはありません。当然ですが、機器といった概念のないマネージドサービスの監視も対応しています。従来のシステム構成で行うシステム監視とは概念的に異なります。

一方、システム監視に対する基本的な考え方が、クラウドやAWSだからといって変わることはありません。基本的には同様の考え方で通用します。マニュアル車が運転できる人はオートマチック車も運転できるのと同じようなものです。

余談ですが、その逆は難しいようです。
徐々にクラウドしか知らないクラウドネイティブのエンジニアも増えてきました。しかし、オンプレとクラウドが混在する過渡期の今、まだまだオンプレミスにおける知見がないと業務をスムーズに進められないケースがあります。具体的には、オンプレでの設計思想を理解できず、クラウド上にリファクタリングできないケースです。クラウドネイティブが悪いわけではありませんが、システム開発の目的は「お客様とコミットしたQCDを守ること」であり、「クラウド機能による開発」ではないことを忘れてはいけません。クラウド利用は、目的達成の手段でしかありません。

システム監視の監視方法

監視サーバーが、監視対象機器の「何」に対して「どのように」監視するかの処理方式が監視方法です。

監視方法の考え方は複数種類に渡ります。そして、その複数種類を組み合わせてシステム監視を実現します。さまざまな監視方法が用意されているのは、あらゆるシステム障害、状況に対して検知、通知しなければならないことの裏返しでもあります。システムの安定運用、障害発生の未然防止はシステム監視の品質にかかっているからです。

以下に示すのは、代表的な監視方法の例です。最低限、押さえておきましょう。
それぞれの監視方法の詳細は表中のリンクを参考にしてください。

監視方法	内容
死活監視	監視サーバーより、pingなどでサーバ、ストレージ、ネットワーク機器が起動しているかを監視する。
エージェント監視	監視対象機器に監視用ソフトウェア（以下、エージェントとよぶ）を導入し、エージェントが監視対象サーバー自身を監視する。怪しいメッセージ出力がログにあれば監視サーバーに通知する。
エージェントレス監視	監視対象機器にエージェント導入をせず、監視サーバーにてリモートで監視対象機器を監視する。エージェント監視に比べて監視できることが限定される場合が多い
リソース稼働情報監視 （エージェント監視の一部）	リソース（CPU、メモリ、ディスクI/Oなど）稼働情報を収集するエージェントによって、パフォーマンス低下の予兆を監視し、パフォーマンスチューニング向けレポート出力など行う。
個別ソフトウェアに特化した監視(エージェント監視の一部）	Oracle、SQL Serverといった個別ソフトウェアのリソース稼働情報のチェックに特化した専用製品で監視する。OS標準コマンドでは検知できない詳細が監視可能 製品例：JP1/Performance Management – Agent Option for Oracle、JP1/Performance Management – Agent Option for Microsoft® SQL Server

例えば、監視対象であるDBサーバーが起動しているのかどうかを監視したい場合は「死活監視」を行います。

なぜ「死活監視」が選択されるのかを補足しておきます。
誤解を恐れずに言えば、IT業界では「死活監視」＝「ping（ICMP Echo Reply）実行結果で判断」とする事が多いからです。もちろん他の方法、例えばsnmpを利用しても死活監視は可能です。このあたりを理解するには、ネットワークプロトコル、アクセス制御の知識が必要になるので詳細説明は割愛しますが、基本の理解としては、表の内容を抑えておけば十分です。

まとめ

システム監視は、システムの正常性確認と予防保守の観点で導入され、必要に応じて監視情報を関係者へ通知する仕組みです。

システム毎に検知、通知しないければならな情報は異なるため、システム要件に応じた適切な監視方法の選択が必要です。検知、通知精度が低いと、重大なシステム障害や予兆を見落とす可能性につながります。まずは、システム監視の必要性と基本を理解しましょう。

• 開発コスト増加
• スケジュール遅延

今回のブログでは、クラウドリフトで発生する予想外の開発コストと、スケジュール遅延について具体的な例を示しながら解説したいと思います。これからクラウドリフトを検討しているプロジェクトではぜひ参考にして頂き、事前に対策を検討しましょう。

まさかの開発コスト増加

クラウドを利用した多くの人が直面する開発コスト増加とは、クラウド利用料です。想像以上に高額なことに驚きます。詳細を確認します。

クラウド利用料の過小評価

基本的に共通しているところは「ハードウェアやソフトウェアの購入が発生しなくなるため、その分費用が浮くであろう」という前提ありきでプロジェクトを進めた結果、開発コストが増加、超過しているプロジェクトが圧倒的に多いという事実です。まず、クラウド利用料金の体系ですが、次の２パターンで提供されることが一般的です。クラウド毎に名称はそれぞれですが、AWSでは前者をオンデマンド、後者をリザーブドインスタンス料金などと呼びます。

1. 利用した分だけ課金される従量課金体系
2. １年や３年といった固定された期間に対する利用料を割引価格で前払いする課金体系

この課金体系を前提として最大限コストメリットを出そうとすると、システム側がクラウドが提供する課金体系でお得になるようにあわせていくことが大前提となるのですが、多くのプロジェクトではそれが出来ていません。具体例で見てみます。

システム開発で必ず利用する開発環境の運用を例に確認します。
多くのプロジェクトでは、特定期間、業務時間であるに日中帯に利用することが多いと思います。１．のオンデマンド利用を前提として開発環境の利用計画を立てることが多いでしょう。時間にして一か月１６０時間程度（算出ロジックは下記の通り）として算出しているケースもあります。

　平日５日を４週間で２０日、１０時－１８時の８時間　→　１６０時間

しかし、システム開発が進んでくると程度の差はあれトラブルが発生し、開発スケジュールの遅延が発生することはままあります。総合試験といったフェーズでは日回し、耐久テストといったことで１週間連続で２４時間運転するといったこともざらです。トラブルが多ければ、何度も実施しなければなりません。このようなことが考慮されてなければ、どうなるかはご想像の通りです。

初めてクラウドリフトしたケースで、開発環境の利用料金が計画値に収まったという話を聞いたことがありません。オンデマンド利用料は想像以上に高額であり、起動しているインスタンスタイプ、開発期間で変わってきますが、オンデマンド利用時間が計画値の２倍になるような状況であればリザーブドインスタンスで計画したほうが良かった、そんなこともざらにあります。参考として、AWSのEC２オンデマンド利用料が確認できるページを載せておきます。

運用のユースケースに対して、何通りもシミュレーションしたうえで適切なインスタンスタイプや課金体系を導く必要があるのです。

オンデマンドインスタンスの料金 - Amazon EC2 (仮想サーバー) | AWS

オンデマンドインスタンスについては、お客様が使用された EC2 インスタンスの料金のみのお支払いとなります。オンデマンドインスタンスを使用することにより、ハードウェアのプランニング、購入、維持に伴うコストや手間が省け、高額な固定費となりがちな運用コストを、より低額な変動費に抑えられます。

aws.amazon.com

クラウド利用のコストメリットを最大限生かそうとすると、システム側がクラウドが提供する課金体系にあわせないとならない理由がお分かり頂けたのではないでしょうか。

クラウド利用料の超過あるある

多くのプロジェクトで１度はやっている、想定外のクラウド利用料が発生するケース２点をあげておきます。
知っていれば防げる内容なので、同じようなトラブルを引き起こさないようにしましょう。

• インスタンスの停止忘れ

手動でインスタンスを停止する運用にしている場合、停止忘れが発生し夜間、土日の利用していない時間帯で利用料が発生します。これは、結構な頻度で発生します。バッチで特定時間に停止させるといった運用で問題ない場合は、仕組みでカバーしたほうが良いでしょう。

• AmazonRDSインスタンスは、7日後に自動起動する

製品仕様となっているため、プロジェクト側で停止する仕組みを用意しないと、知らない間に利用料が発生します。RDSはEC2に比べて高額となるため、大きなインスタンスタイプを利用していると被害額は大きくなるため、十分な注意が必要です。

RDS インスタンスを 7 日以上停止する

AWS Lambda を使用して、Amazon リレーショナルデータベースサービス (Amazon RDS) を 7 日間以上停止したいと考えています。

repost.aws

事前検証の甘さが招くスケジュール遅延

クラウドリフトを一から経験しているエンジニアや有識者はまだまだ少ないのが現実です。そういったメンバーを集めて体制を組もうとしても、まず集まりません。集まったとしてもクラウドの有識者は短期、スポット参画となる人が多いでしょう、それだけ希少な人材であり、需要も単金も高いということです。一方、プロジェクトとしては経験のないクラウドリフトに対して事前の検証やリスクに関する洗い出しが必須であるにも関わらず、そういった事情により事前検証やリスク洗い出しが甘くなる傾向にあります。当然、見切り発車となり、いざトラブルが発生したとしても適切な対策が立てられず、スケジュールが延伸するといった「典型的な炎上プロジェクト」へ発展します。

クラウドリフトプロジェクトにおけるスケジュール延伸は、オンプレミス環境でのそれに比べて格段にリカバリが難しくなります。なぜそのようなことになるのか、その背景を探ってみましょう。

従来の機能・非機能は実現できるのか

クラウドリフトの大前提を確認しておきます。目的は、クラウドへの移行を低リスク、低コストに抑えることにあります。プロセスとしては必然的にオンプレミス環境での基本的な設計思想はそのままとし、追加の発生となる設計や構築稼働は抑えなければなりません。クラウドで提供されるマネージドサービスを最大限活用し最適化する（クラウドネイティブ）といったことが目的ではありません。その上で、従来の機能・非機能をクラウド環境上でどのように実現するのか事前の検証が非常に重要になってきます。なぜなら、AWSやAzureといったクラウドは、オンプレミス環境と違って開発者が好き勝手自由に構築、利用できるわけではなく、クラウドの利用規約や仕様に従ってシステムを構築しなければならないからです。それら事前の検証をPocと呼び、プロジェクトの推進に大きな影響を与えかねない不確実性を取り除く作業が必要なのです。

Pocでは何をすれば良いのか

プロジェクトでの不確実性を取り除くとは、具体的に何をすれば良いのでしょうか。現実的にはPocの教科書的な説明を聞いただけでは抽出できません。結論としては「プロジェクトによる」となります。それでは元も子もないので、検討例の一例を示します。

既存システムがOracleをアクティブスタンバイのHA構成を採用しているとしましょう。考えられるクラウドリフトのパターンは、AWSの場合下記２通りです。

1. Amazon RDS for OracleをマルチAZ構成とし、マネージドサービスのアクティブスタンバイをフル活用　→　多くのPJではこちらの構成を採用しているイメージ
2. Amazon EC2にクラスタソフトを導入しオンプレミス環境と同様にHA構成を構築する　→　構成により制約があり使いずらい印象

当該プロジェクトの場合、これらをPoc対象に抽出したポイントは以下の通りです。RDSを利用しても非機能要件で定義した可用性と性能を担保可能であることが検証できたため、１．の採用を決定しました。

• クラウド上における高可用性の構成に関してはAWSとして様々技術情報が展開されている　→　複数の処理方式が検討可能
• RDSというマネージドサービスの利用が初　→　RDSの制約を見極める必要がある（Pocで確認できたRDSの制約の一部を下記記事で紹介しています）

404 NOT FOUND | いまさら聞けないシステム開発

意外と知らない、だけど知っておくべきシステム開発の基本と裏話を伝えていきます

sys-univ.com

• AWS上のHA構成はオンプレイ以上のレイテンシーとなるため性能評価が必須　→　マルチAZ構成の場合、性能劣化する事象が報告されている

実際にはAWSの有識者に参画して頂き、既存の設計から検証したほうが良いポイントについてアドバイスをもらいましたが、AWS Well-Architected フレームワークを参照し、AWS上で検討すべき項目についての理解も深めて取り組みました。

AWS Well-Architected フレームワーク

docs.aws.amazon.com

Poc不足のプロジェクトが9割

AWS有識者からアドバイスをもらったと記載しましたが、クラウドリフト経験のないプロジェクトとしては良い選択だったと思います。具体的には、アマゾンウェブサービスジャパン社から技術コンサルティングという形でスポット参画してもらいましたが、冒頭で述べた通り多くのプロジェクトでは、AWS有識者を確保するための単価が高いという理由により、本来実施すべき検討が出来ていない現実があります。結果として、大切なポイントを事前検証できず、いざ設計、構築しようとしたら想定する機能が実装できなかった、実現できなかったという事例は枚挙にいとまがありません。

機能が実現出来ないだけなら、大幅なコスト超過を覚悟で当該機能を作りこむことも可能な場合もあるでしょう。一方、目標とする性能に届かない場合は、さらなる悲劇が待ち受けています。

EBSやEFSのIOPS、スループットの変更にも限界があります。設定可能な最大値に変更しても性能目標を達成出来ない場合は、処理方式の変更も視野に入れなければなりません。しかし、処理方式の変更となると、設計からやり直しとなります。これまで実施してきた試験が全て無駄となり、超過するコストもリスク予備費では対応できないレベルで高額となることが予想されます。そもそも、EFSのスループット引き上げで対応できたとしても、EFSのスループット引き上げによるコストインパクトも大きく、通常時にそのスループットでシステムを運用していくことは現実的ではないでしょう。

ちなみに、クラウドを利用するということは、目先のハードウェア、ソフトウェア費用を下げるためではありません。初期の導入費用を抑えつつ、将来のビジネス拡張にむけて柔軟に対応するためといった要素のほうが大きいことを理解しておくべきでしょう。

Pocに関しては、クラウドリフト経験のある有識者を含めて行うことを強く奨めます。

まとめ

クラウドリフトはオンプレミス環境同士の移行とは全く異なります。従来の開発プロセスでは対応できないことも多いので、今まで以上に徹底的にリスクを洗い出し、万が一リスクが顕在化した場合でも想定の範囲内に収めておく必要があります。そのためには、次の２点を必ず考慮してください。

• クラウド利用料を最適化したいならば、システム側がクラウドが提供する課金体系に運用をあわせる
• 設計を踏襲可能なのか、マネージドサービスによる新設計とするのか、性能は目標を達成することが可能かPocを行う