本記事は、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は送信時の経路しか表示しません。応答時は送信時と異なる経路を通る可能性があるので、双方向がベストです
-
同一システムのサーバー間通信でも取得しましょう、同一システムのサーバー間でもサーバーが乗る物理筐体が違えば、スイッチなどのクラウド共用部のネットワーク機器を通過する場合があります
-
常時取得しましょう。 例えば、以下のコマンドは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