数時間かかるトラブルシュートをわずか15分に短縮！
Oracle Management Cloudが現場にもたらすメリット
アシスト データベース技術本部 課長の関俊洋氏
このように豊富な機能を備えるOracle Management Cloudだが、現場のエンジニアに対してはどのような恩恵をもたらすのだろうか？ アシストでデータベースやクラウドの導入支援に当たる関氏が、あるトラブルを想定して検証を実施した。
「データベースを運用しているチームに、ユーザーから『アプリケーションに接続できない』という連絡が入ったとします。監視ツールを確認したところ、アプリケーションもデータベースサーバも正常に動作しています。この状況で、従来の障害対応とOracle Management Cloudによる障害対応でどのような違いが出るのかを検証しました」（関氏）
こうした場合に多くのエンジニアが行う初動対処としては、次の2つが考えられる。
1つは、接続できないセッションの情報を見るためにデータベースを調査するというものだ。Oracle Databaseならばアラートログがあるので、それを見ればよい。しかし、このケースでは有効な手掛かりは得られず、OSのログを見ても負荷は低い。それにもかからず、不具合が解消する気配はない。
次に考えられる初動対処は、アプリケーションを調査するというものだ。調べてみると、最近、アプリケーション担当チームがソースコードを修正したらしい。そこで修正前のコードに切り戻してみるが、残念ながらエラーは解消しない。
その後も調査を続けるが原因はわからず、最終的にサーバを再起動することでようやくエラーが解消した。
結局、この問題の原因はコネクションプーリングのトラブルだったが、このようにデータベースとアプリケーションをまたいで起きた問題を、Oracle Management Cloudによってどう解決できるだろうか。実際に試してみたところ、「アプリケーションとデータベースで原因を切り分け、解決策を実施するまでに要した時間は、わずか15分でした」と関氏は驚く。このとき、Oracle Management Cloudで行ったオペレーションの内容は次のとおりだ。
まず問題の発生に気付いてOracle Management Cloudのダッシュボードを見ると、問題が起きているアプリケーションを一目で特定できる。そこで、そのアプリケーションの稼働情報を深掘りすると、エラーの発生個所が表示される──ここまで、わずか数画面である。OSやデータベースなどの余計な情報は一切見ることなく、問題が起きている個所に最短の手間でたどり着ける。後は、その問題を解消するための対処を実施すればよい。
切り分けもログ分析も不要だから、短時間で原因を究明できる
従来のやり方で数時間かけても究明できなかった原因をわずか15分で突き止められた理由を、関氏は次のように推察する。
※クリックすると拡大画像が見られます
1つは切り分けが不要であることだ。問題の原因がアプリケーションなのか、データベースなのか、それともOSなのかを切り分けるのは運用の現場でも難しい作業だが、Oracle Management Cloudの場合はデータベースとアプリケーション、OS、ネットワークを全て横串で監視するため、どこに問題があるのかを即座に突き止められる。切り分けの手間は不要であり、それによって大きく時間を削減できるのだ。
切り分けと並んで、ログの確認もトラブルシューティングで多くの時間を費やす作業である。Oracle Databaseはアラートログだけで何万行もあり、それにOracle Real Application Clustersやリスナーのログが加われば膨大な量になる。
「ログの確認だけで数時間を費やす場合もありますが、Oracle Management Cloudではこの作業も一切不要です。問題が起きた個所にフォーカスして可視化し、その他の“ノイズ”は全てカットしてくれるのです」（関氏）
※クリックすると拡大画像が見られます
また、何か問題を解決した際には、それを他のシステムに横展開して問題の発生を未然に防ぐことが望ましいが、多忙な現場では実践が難しい場合もある。Oracle Management Cloudならば、発生したエラーを基にしてアラートを設定することで予兆を検知し、一度起きたトラブルが二度と起きないよう運用に反映させていくことができる。
データベース運用のベストプラクティスを実践できている企業は少ない
アシストでは、長年にわたって蓄積したノウハウに基づき、「①予防」、「②検知」、「③調査」、「④復旧」、「⑤改善」の5つの要素から成る「データベースの安定サイクル」をデータベース運用のベストプラクティスとして掲げている。
※クリックすると拡大画像が見られます
しかし、多くの現場を見てきた関氏は、このベストプラクティスを実践できているケースは少ないと話す。
例えば、予防に関しては、設計を正しく行うのは当然だが、パッチを定期的に当てている企業は少ない。また、運用時に検知（監視）をしっかりとできているか、問題の切り分け（調査）や対処（復旧）のフローをきちんと整備しているか、さらには潜在的なリスクを洗い出せているか（改善）と言えば、ほとんどのシステムは不十分なまま運用されているのが実情ではないだろうか。
「多くの企業は設計フェーズでリソース監視や死活監視、エラー監視のことまではしっかりと考えて対策を打つのですが、トラブルが起きた際の調査や復旧、継続的な改善をどう図るかといった運用設計が行われていないシステムが散見されます」（関氏）
それでは、なぜ検知（監視）だけで満足してはいけないのか。アシストのサポート部門は年間で約1万件のデータベーストラブルに対応しているが、その内訳は大きく「障害系」と「それ以外（非障害）」で半々となる。
※クリックすると拡大画像が見られます
障害系のうち、エラーについてはエラー番号がわかれば対処できるが、残りの3割を占める緊急トラブル（異常停止、接続不能、その他障害）について、検知だけで十分に対応できるだろうか。
「トラブルが起きないデータベースが究極の理想ですが、起きてもすぐに対処できる運用設計がなされているかも非常に大切です。実際に起きるトラブルは複雑でシステムの稼働に大きな影響を及ぼすものが多いため、その後の対処をスムーズに行えることが重要なのです」（関氏）
