経過するとアイドル状態の接続は終了させられる。オプションが有効になっているとき、クライアントとの通信がない状態になってから2時間経つと、サーバーからプローブパケットをクライアントへ送ります。ここでクライアントが応答すればコネクションは維持されます。クライアントから応答がない場合、75秒ごとに9回プローブパケットを送った後でコネクションがクローズされます。2時間11分経つと切断されます。仕組みが有効であれば、サーバー側でコネクションがクローズされるようにみえます。標準でネットワーク周りの調査に使えるコマンドがインストールされていると思います。秒数やプローブ数が表示されます。無効になっているときは以下のように表示されます。無効になっていることが分かりました。ソースコードをみてみます。生成していることが分かります。設定していることが分かります。3分に設定していることも分かります。有効となり、クライアントから通信がない状態で3分経つとプローブパケットを3分間隔で送ります。プローブ回数がデフォルト設定なら3分ごとに9回プローブを送り、最終的に30分経つとコネクションがクローズされます。より30分でコネクションがクローズされることが分かりました。無効であることを確認していたため、サーバーアプリケーションのどこかでこれらの設定を無効にしているのではないかという推測がつきます。サーバーを起動していました。有効にするような設定が行われていないことが分かりました。有効になっていないことに気付いていませんでした。サーバー群への通信はロードバランサー経由で行われます。いう仕組みで通信が行われます。ロードバランサーはクライアントからのリクエストをまとめて受け付けますが、レスポンスは実際のサーバーから返す仕組みです。調査の後半になって分かったことですが、このロードバランサーのセッションテーブルの生存期間が2分でした。より確立したコネクションを再利用する場合、通信せずに2分以上経過すると、その前に通信していたサーバーと通信できなくなります。パケットを送ったとしてもロードバランサーのセッションテーブルから削除されているため、実際のサーバーへそのパケットが届かないということも分かりました。3分に設定しています。パケットをクライアントへ送り、その応答がサーバーに戻ってこないことも確認できました。そのため、ロードバランサーのセッションテーブルの生存時間も4分に変更することにしました。課題を修正するここまでの調査結果を整理します。サーバーへ届かない可能性があるここまで分かれば、対応方法はいくつか検討がつきますね。課題の修正も開発チームと相談しながら私がそのまま担当しました。リリースされる予定でした。機能が提供されるというのが話題になっていました。ライブラリを利用していました。アップグレードすることで以下の改善が見込めました。(保守コストの削減)これらにより調査してきた課題を解決できそうです。機能に移行していていくつか気付いたことを以下の記事にまとめました。興味のある方はこちらも参考にしてください。実際に修正が施されたバージョンがリリースされた後のグラフが以下になります。リリース時にサーバーが再起動されるので数値は大きく下がるのですが、なんとなく横ばいになってそうな雰囲気がみえます。その後の経過状況も監視して改善前の右肩上がりの勾配をもつグラフから横ばいのグラフになりました。有効になった結果として通信していないコネクションがクローズされてリソース浪費の問題が解決しました。運用で実際に発生したトラブルシューティングの1つを紹介しました。本稿の課題を解決するには以下のようなスキルや知識が要求されます。いうキーワードを私はよく見かけるようになりました。考え方を積極的に業務へ取り入れていこうとしています。業務の1つではないかと思います。最後にヤフーではこのような課題に取り組むインフラエンジニアまたはサイト信頼性エンジニアを募集しています。JAPANでは情報技術を駆使して人々や社会の課題を一緒に解決していける方を募集しています。詳しくは採用情報をご覧ください。JAPANのサービス開発を支える技術やデザイン、文化を発信しています。Reserved.このページの先頭へ。