Troubleshooting Connectivity #6 - 接続タイムアウトは悪なのか？

高橋 理香
SQL Developer Support Escalation Engineer

みなさん、こんにちは。

数年以上前からずっと個人的にいつかきっとわかってもらえる...と思いながら今日まで心の中でしまっていたこと。それが接続タイムアウトの存在意義。(いえ、実際にはお問い合わせいただいた方にはそれとなく、もしくははっきりとお伝えしたこともあるのですが、、、)

そんな接続タイムアウトについての考え方について今回は書きたいと思います。

接続タイムアウトとは？

接続タイムアウトとは、アプリケーションからの接続要求が一定時間内に完了しなかった事象を指します。また、その際に返されるエラーが、タイムアウト エラーです。

例えばこんなエラーがありますね。(接続時に発生するエラーとしてどんなエラーがあるかはまた後日に別のトピックにてご紹介予定です。)

• OS レベルのセッション確立に遅延が生じた。
• ログイン認証の処理に遅延が生じた。
• データベース アクセスに遅延が生じた。

ではそれぞれに遅延が生ずる主な理由は・・・

はい、皆様、以前のブログに書いていますので、そちらをご覧くださいね。

Troubleshooting: Connectivity #2 - エラー情報からわかる失敗原因

とにかくです。どこかに遅延が生じて、時間がかかってしまったという状況を指すわけです。

遅延を許容するか？それともエラーで中断させるか？

さてさて、ネットワーク等のインフラが整ってきた昨今ですが、いつどんな環境でも同じ程度のレスポンスって約束されているんでしょうか？？？

私が自宅で使っている PC は CPU のクロック数はそこそこであるもののメモリは少なく、また、ネットワークのスピードも、さっき下り 75Mbps だったのが今は 10Mbps くらいになっているなど、会社と同じようにインフラが整ってます！とは言いがたい状況です。会社で作業していたとしても、一部メンテナンスでつながりにくいことなどもあります。つまり、「いつどんな環境でも」という点でいえば、いまだそこまでは High Performance が保証されてはいないのが現実だと思います。

ではこの遅い状況もあるだろうという昨今の環境において、その遅い状況に遭遇した場合を考えてみましょう。あなたはどちらを望みますか？

遅いことを示すメッセージを出して後で再試行するのがいいですか？

それとも・・・

遅くてもいいからエラーは出さないで終わってほしいですか？

少なくとも私が自宅にてちょっとした興味でどこかのサイトでお買い物なんかを行っているような状況の場合、メッセージが出て処理が中断されても問題ありません。むしろ、混雑していることを教えてもらえれば後日にやればいいだけということもあります。

勢いでクリックしたものなんかは考える余地ができます(笑)

でも、これが職場で仕事中だったりすると「なんとか終わらせたいからエラーにはしないでー！」と思うこともあります。待ちを許容し、エラーよりもむしろ時間がかかっても終わってほしい場合ですね。

このように、遅延を許容するかエラーで中断させるかは、それを使用する環境が普段どのようなスピード感で使用できる環境で、かつ、使用するアプリケーション/システムがどのような要件で提供されるものであるかに依存するといえます。

接続タイムアウトの役割とは？

接続タイムアウトはこの「遅延を許容するか、それともエラーで中断させるか」を判断するための設定値と言えます。

著しく遅延している状況については障害として詳しく調査する必要があるかもしれませんが、いつもよりちょっとだけ遅いくらいなら、エラーにせずに時間かかったなという程度で済むものもあります。この判断材料として接続タイムアウトを使用してほしいのです。

したがって、開発者、および、システム提供者の皆様には、システムの利用環境、システムの利用者、システムの要件を加味してた上で、通常時の接続に要する時間の幅をあらかじめ計測するなどにより見積もり、その最長時間よりもどのくらい長くかかったものを障害とするか、という判断をぜひともまず最初に実施ください。

例えばこんな環境/システムがあったとします。

• LAN 利用者の通常時の接続完了までの時間: 3秒 ～ 10 秒
• WAN 利用者の通常時の接続完了までの時間: 20 秒 ～ 40 秒
• サーバー環境でのフェールオーバーに要する時間: 40 秒 ～ 1分
• システム要件: フェールオーバーした際にも可能な限りエラーとさせない。

上記の場合、接続要求が成功するのに 1分以上を要する可能性があるということになりますね。この場合には、接続タイムアウトが 100 秒ではギリギリの可能性がありますので、余裕を持たせて 120 秒、150 秒としてもいいかもしれません。(*)

(*) 実際の対応としては、接続タイムアウトを延ばすだけではなく、それに加えて接続の再試行のロジックを組み入れることが堅牢性に優れたシステムと言えます。

要件などは様々あり、上記は一例でしかありませんが、考え方の参考になれば幸いです。

最後に: 接続タイムアウトは悪なのか？

「接続タイムアウトは悪なのか？」ですが、私の答えは「No」 です。

前述の通り、接続タイムアウトは利用システム/環境の状況を判断するための材料でしかありません。その環境やシステムに応じて適切に設定している状況下で発生し、その遅延の要因となっているものが想定外の障害であった場合にはじめてそれが悪だといえるのだと思います。

なお、遅延の要因などを調査する場合には、前述した「Troubleshooting Connectivity #2 - エラー情報からわかる失敗原因」のほか、先に公開している以下のブログを参考に切り分けや情報採取などを実施してみてください。

Troubleshooting Connectivity #1 - SQL Server への接続

Troubleshooting Connectivity #4 - 接続エラーの調査方法

※今回は接続タイムアウトについて述べていますが、クエリ タイムアウト (もしくはコマンド タイムアウト) も同様です。どのくらいかかったら「そのシステムにおいて」問題があるとみなすのかの基準値として考えて適切な値を設定しましょう。仕組みについては、以下のブログで紹介していますのでご覧ください。

クエリタイムアウト - その仕組み

次回はまた #2 の続きとして、接続エラーとしてどのようなものが発生しうるかのご紹介ができればと思っています。