20
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

MTRの常時取得のススメ

Last updated at Posted at 2018-11-09

本記事は、Publicクラウドでアプリを作る人へ向けて、MTR(My traceroute)の常時取得を啓蒙する内容です。
自身の体験を交えながら、記載していきます。
なお、MTR自体の詳細は記載しませんので、あしからず。

#導入

突然ですが、みなさんが担当するクラウド上のシステムは、クラウド共用部ネットワークもしくはインターネット上の経路で問題があった場合、障害ポイントを特定できますか?

ibmcloudNW.png

上図はIBM Cloudのネットワーク構成図です(引用元)。

赤マークがネットワークの障害発生ポイントです(厳密にはもっとある)。
想像していたより、たくさんあると思いませんか?
少なくとも、私はそうでした。

#MTRってなんぞ?

MTRとは、tracerouteとpingの機能を組み合わせたツールです。
tracerouteの結果に情報を付加した結果を表示してくれます。

以下はMTR取得結果サンプルです(通信経路上でパケットロスしている思われる時の)
No.11以降からLoss%が一定です。No11で経路で何かしら問題があることがわかります。

Start: Sat Oct 19 14:00:02 2018
HOST: my host                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- xx.x33.68.130             89.1%    55  7016. 3507.   0.8 7017. 2957.1
  2.|-- xxx.x54.195.154            0.0%    55    0.6   1.5   0.6  18.8   3.0
  3.|-- xxx.x02.118.130            0.0%    55    0.5   0.6   0.4   5.7   0.6
  4.|-- xxx.x5.19.206              3.6%    55  7010. 512.3   1.6 7013. 1490.8
  5.|-- xxx.x5.19.161              0.0%    55    0.8   1.5   0.7  12.6   2.1
  6.|-- xxx.x03.177.169            0.0%    55    0.9  20.6   0.7 1002. 134.9
  7.|-- xxx.x50.5.54               0.0%    55    1.5   1.3   1.1   1.7   0.0
  8.|-- xxx.x50.6.128              0.0%    55    1.5 603.5   1.4 7022. 1537.8
  9.|-- xxx.x50.3.56               0.0%    55    1.7   1.8   1.5   2.3   0.0
 10.|-- xxx.x73.175.226            0.0%    55    2.6   2.7   2.4   3.1   0.0
 11.|-- xxx.x38.112.1xx           52.7%    55    3.3   3.0   2.5   3.7   0.0
 12.|-- xxx.x38.89.1xx            52.7%    55    2.7   2.9   2.6   6.0   0.6
 13.|-- xxx.x38.120.1xx           50.9%    55   12.0   3.1   2.5  12.0   1.8
 14.|-- xxx.x32.10.xxx            50.9%    55   12.4   3.5   2.9  12.4   1.8
 15.|-- xxx.x32.184.2xx           50.9%    55   15.7   5.5   3.7  15.7   2.2
 16.|-- xxx.x80.39.x6             50.9%    55   12.8   3.8   3.3  12.8   1.8
 17.|-- xxx.x80.39.1xx            52.7%    55    3.7   3.9   3.6   4.3   0.0
 18.|-- xxx.x48.15.x26            52.7%    55  111.5 109.0  55.6 112.0  11.1

なお、MTRの実行結果の見方については、ここが参考になります

#ことの発端

次に、私の体験談を。

私の担当するシステムは、Publicクラウド上で構築しており、インターネット越しに他のシステムと通信していました。

定期的に、外部への通信で、タイムアウトが頻発する事象が発生していました。
この時のタイムアウトはリクエスト応答待ちではなく、TCP接続のタイムアウトです。
Javaだと以下のメッセージが出力されます。

java.net.SocketException: java.net.ConnectException: Connection timed out

見るからに、ネットワークが怪しそうです。

#原因調査

ひとしきり自システムのFWのログを調べたり、ネットワークキャプチャを取得しても原因は絞り込めず、そのうちにクラウドの共用部ネットワークが怪しいのではと? という話になりました。

で、チケットで問い合わせみると、何も問題はない、とつれない返事。
次に、共用部ネットワークのキャプチャ取得を依頼すると、その前に事象発生時のMTRの結果を提出せよと言われました。つまり、共用部ネットワーク以外の要因が問題ないことを証明できたら、調べてやるというわけです。

そりゃそうです。クラウドのセンター内には無数のネットワーク機器があり、おいそれとキャプチャ取得はできないのは、同業界の人間としては理解できます。

で、お客様に上記内容を報告すると、当然怒られ&何とかせいと言われ、現場は板挟み状態に。。。

#最終的に

現場では、MTRの取得の準備を進めていましたが、お客様の承認など、ワークロード以外の部分で時間を要していました。

そうこうしているうちに、クラウドベンダーから報告があり、クラウド共用部ネットワークのプライベート側のスイッチ不具合であることが判明し、自体は収束に向かいました。

#MTRを取得するメリット

  • 障害ポイントが絞り込めます。これは大きなメリットです。導入で記載しましたが障害ポイントは無数にあります。MTRなしにこれを絞り込むのは大変です。

  • クラウドベンダーへのネットワーク機器の調査依頼に必要なエビデンスを確保できます。前述の通り、この結果がないとやってくれません(というか、大体のケースにおいて提出を求められる)。

#MTRの取得にあたって注意点

  • 全てのネットーワーク経路(TCP接続の終端間)で取得しましょう。一部でも抜けがあると信憑性が薄れます

  • 双方向から取得しましょう。MTRは送信時の経路しか表示しません。応答時は送信時と異なる経路を通る可能性があるので、双方向がベストです

  • 同一システムのサーバー間通信でも取得しましょう、同一システムのサーバー間でもサーバーが乗る物理筐体が違えば、スイッチなどのクラウド共用部のネットワーク機器を通過する場合があります

  • 常時取得しましょう。 例えば、以下のコマンドは1秒間隔で55回パケットを送信後にMTR結果を出力します。これを1分ごとに実行すると、ほぼ常時MTRを実行し、かつ分単位で事象発生時間がわかります。

$ sudo /usr/sbin/mtr -T -P 443 -c 55 -i 1 8.8.8.8 -r -n >> mtr_result.txt
20
13
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
20
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?