謎のOracleトラブルに挑む（前編）
− 事例に見るトラブルシューティング技法 −
松本 庄司
株式会社サンブリッジテクノロジーズ
2001/11/13
開発・テストフェーズでは出なかったトラブルが本番運用中に出てしまい、しかも原因が簡単にはつかめない。仕方がないから、「トラブルには目をつぶって運用で回避している」といったことはないでしょうか？ そんな問題を抱えてしまったクライアント企業からの依頼で弊社が行った、障害原因調査の事例を紹介します。
依頼内容
|
||||||||||||||||||||||||||||||
発端は、「データベースの障害が頻発するので調べてほしい」という依頼が弊社に持ち込まれたことでした。システムの開発・運用元が調べたところ、何らかのきっかけでデータベースがオフラインになってしまうというのです。このトラブルは10日に1度程度の割合で発生するということでしたが、再現条件は分かっていませんでした。手掛かりは、データベースの「kernelがInterrupted System Callを出したのでインデックスを閉じます」というエラーログだけです。
取りあえずインデックスファイルを作り直せば回復はできるので、障害が起きた時点でバックアップから書き戻しを行って運用していたそうです。しかし、これでは数時間のブランクが生じてサービスレベルが低下するため、根本的な対策が必要です。しかし、開発・運用元の方では再現条件が分からないために根本的な対処ができず、データベースサーバの2重化によってダウンタイムを短くするという対症療法的な提案があったそうです。
アプリケーションの作りや目的などによって、データベースアクセスのパターンにはある程度のクセがあるものです。今回のアプリケーションは、SELECTとINSERTが多く、UPDATEは少ないというものです。また、不定期に大量のINSERTとテーブルフルスキャンが集中して負荷が増大するということでした。
問題部分切り分けの勘所
一般的には、以下のようなレイヤのどの部分に不具合があるのか「アタリ」をつけます。
- アプリケーションの作り方
- アプリケーションサーバの設定
- アプリケーションサーバのOS
- アプリケーションサーバのハードウェア
- データベースの作り方、設定
- データベース
- データベースサーバのOS、ドライバ
- データベースのハードウェア
- ネットワーク環境
ほとんどの場合は、エラーメッセージやログを解析することによって、どのレイヤが悪いのか分かります。今回のケースでは、データベースのエラーログに「kernelからInterrupted System Callが出た」と残っていることから、おそらく6、7、8の辺りが最も怪しいと考えられます。また、HDDを換えても同じ障害が発生したということなので、HDDのトラブルは排除できます。しかし、この段階ではアプリケーションがイリーガルなことをしているという可能性も捨て切れません。
テスト環境の構築から障害再現までの道のり
とにもかくにも、障害を再現しなければお話になりません。そこで、障害が発生した状況をできる限り再現するための環境を準備します。トラブルシューティングを効率的に行うための理想的な状態は、以下のようなものです。
- 障害発生時の状態把握
ログやプロセス、メモリ、ストレージ、ネットワークアクセスなど、そのときのマシンの状態をできる限りたくさん採取する。究極的にはメモリダンプを行う。
- 代替マシンの用意
サービス継続のために代替マシンを稼働させる（ホットスタンバイになっていて、自動的に切り替わるようにしておくのが最もよい）。
- 障害発生時の状態保存
障害が発生したらサイトからマシンを切り離し、そのまま解析に移る。何の操作も受け付けない場合を除けば、リブートもしない方がよい。
■第1のハードルは開発・運用元
しかし、現実にはそうはいきません。可能なのはせいぜいログの保全程度でしょう。今回の場合は、悲しいことにシステムの状態もよく分からず、Oracleのエラーログ程度しか残っていませんでした。
また、開発・運用元では障害テスト用に別のマシンを準備する余裕はないとのことで、できるだけスペックの近いマシンを用意せざるを得ませんでした。さらに不幸なことに、本番環境のデータベースのダンプも残っておらず、テスト用にデータベースの情報を出すにもいろいろ準備が必要だしほかの仕事も詰まっているとのことで、テスト開始時にはテーブル構成と設定ファイルしか頂けませんでした。アプリケーションやデータベースの設定手順書もなく、問い合わせに対応する余裕もないとのこと。こんな状態ですから、開発・運用元の設定や運用がまともなのかさえ疑わしくなります。
■テスト環境の構築方針決定
これでは満足な調査ができるはずもありません。かといって指をくわえて環境がそろうのを待っているわけにもいきません。さて何から手を付けたものか……。「kernelからのInterrupted System Call」が出る可能性が高いのは、特にI/O回り（ディスク、メモリ、ネットワークアクセス）です。負荷が非常に高いときや排他処理がまずいときにたまたま起こると考えられます。つまり、疑わしきはOracleかカーネルのどこか（特にI/O回り）と見当をつけました。
ただし、「アタリ」を絞り過ぎるすぎると、それが外れていた場合にいつまでたっても障害を再現できないので、ハードウェアも含めて似た環境にします。ここでは負荷が高いとき、特にスワップが食いつぶされていくような状態のときに起きる可能性が高いと考えられるので、メモリとスワップは本番環境に比べて少なめにしておくことにしました。
データベースへのアクセスパターンも本番環境に近い状態を再現する必要があります。通常の利用方法とはアクセスパターンが異なる偏り方をしているので、「たまたまOracleのバグに当たった」という可能性も残っているからです。理想としては、アプリケーションサーバのテストマシンも本番と同じものを使いたいところなのですが、そちらも準備できないとのことでした。アプリケーション自体が変なことをしていなくても、アプリケーションサーバがたまたま変なことをしているという可能性も捨て切れないので不安ではあるのですが……。幸い、弊社の手持ちモジュールに今回のアプリケーションと機能の似ているものがあったので、これを使ってダミーアプリケーションを作りました。もしこの状態で障害が出れば、原因究明の可能性が見えてきます。
■連続負荷テスト開始
テスト環境を構築しただけでは障害を再現することはできません。テスト環境に負荷を掛ける必要があります。
Webアプリケーションのテストには以下のような要件が必要です。
- 実際のアクセスに近いこと（アプリケーションから見て普通のWebブラウザからのアクセスと区別がつかないこと）
- 繰り返し実行できること
- 同時に大量のアクセスを発生できること
この条件を満たす市販のテストツールはいくつかありますが、どれも安いものではなく使いこなすのも大変です。そこで、弊社で作成した負荷テスト、カバレージテスト、サイトの定常監視に使えるツールを使用することにしました。
このテストツールを使って、テスト環境に負荷を掛け続けます。負荷掛け用のPCを2〜3台用意し、1台につき200個の仮想クライアントから同時に一連のトランザクションを模したアクセスを発生させます。この負荷は、本番環境のピーク時アクセス数の数倍に相当します。同時に、再現条件を調べるためにメモリや負荷の状態を定期的に記録しておきます。
こうして負荷テストを掛け続けること3日目、ついに目的の障害が発生したのです。
|
予告：後編は11月17日公開
|
| 3日間の負荷テストによってようやく障害の再現に成功したが、原因はまったく不明のまま。原因を特定するため、プロジェクトのメンバーはさらなる負荷テストを続けることになる。 負荷テストの果てに彼らが見たものは、「0.0.1の違い」だった……。 |
|
1/2
|
|
||||
|
||||
 |
Linux Square全記事インデックス |
| Linux Squareフォーラム Linux導入事例関連記事 |
 |
オープンソースで情報システムを刷新した嘉悦大学 嘉悦大学は情報システムのインフラを、CentOSやOpenLDAP、Sambaといったオープンソースソフトウェアで刷新した |
|
日米大手銀行がLinuxを採用したそれぞれのワケ バンク・オブ・アメリカと三菱東京UFJという日米を代表する大手銀行は、なぜLinuxとその上で動作するオープンソースソフトウェアを導入したのか |
|
特集：謎のOracleトラブルに挑む（前編） わずかな手掛かりから障害を解決した事例をとおして、トラブルシューティングのあり方や技法、困難さが見えてくる |
|
特集：謎のOracleトラブルに挑む（後編） 編で障害再現に成功したが、原因が特定されたわけではない。彼らはどのようにして問題を切り分けていったのだろうか？ |
|
3年間無停止でNTTグループを支えるLinux 国内で最初期にLinuxで業務システムを構築したNTTコムウェア。このシステムはNTTグループ全体にも導入され、3年間無停止で稼働し続けている |
|
Linux Squareフォーラム全記事インデックス |
|
- 【 pidof 】コマンド――コマンド名からプロセスIDを探す （2017/7/27）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、コマンド名からプロセスIDを探す「pidof」コマンドです。 - Linuxの「ジョブコントロール」をマスターしよう （2017/7/21）
今回は、コマンドライン環境でのジョブコントロールを試してみましょう。X環境を持たないサーバ管理やリモート接続時に役立つ操作です - 【 pidstat 】コマンド――プロセスのリソース使用量を表示する （2017/7/21）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、プロセスごとのCPUの使用率やI/Oデバイスの使用状況を表示する「pidstat」コマンドです。 - 【 iostat 】コマンド――I/Oデバイスの使用状況を表示する （2017/7/20）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、I/Oデバイスの使用状況を表示する「iostat」コマンドです。
 |
|
|
|
|
