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

導入

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

上図は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は送信時の経路しか表示しません。応答時は送信時と異なる経路を通る可能性があるので、双方向がベストです

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

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

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