【はじめに】
「通信エラーが起きた！」、「通信が遅延している！」 ―― そんな時、すぐに原因を特定したいのに・・・
- 監視が十分に仕込まれていなかった！
- どこから当たりをつけてよいか分からない！
- 詳細ログをセキュリティポリシーやシステムの仕組み上残せない！
といった状況に直面することはありませんか？
本記事では、ログ不足でも「通信シーケンス」を丁寧に追えばボトルネックを特定できた、という実践事例を紹介します。
【事例紹介: 通信シーケンスで見抜いた！HSM負荷によるSSLハンドシェイク遅延】
とあるお客さんから、「ピーク時間帯を迎えると通信トラフィックの6割がエラーになる！」、「原因解明を助けて！」とご連絡を受けました。通常このようなケースではサーバや機器のリソース情報やMWレベル（電波の強さ、ミリワット）の「Access Log」、「Error Log」を見ればある程度要因が掴めることが多いですが、当ケースでは確認しても怪しい痕跡が見つかりませんでした。
下図は、関連のある部分を中心に抜粋した図ですが、ネットワーク構成としてはFW（ファイアウォール）とLB（ロードバランサー）が冗長化されており、LBには「HSM」が接続されていました。
「HSM」とはハードウェアセキュリティモジュールの略でデータの暗号化と復号、およびデジタル署名と証明書の作成に使用される鍵を生成、保護、管理するハードモジュールです。
HSMはセキュリティ機器の為、LBから「StatTree」の情報を取得できた程度で、解析するログとしては不十分なケースが発生します。HSMの製品にもよりますが、「専用CLI （Command Line Interface）」にログインするにもデータセンターに行って、専用のUSBメモリを2本、HSM本体に挿さないとログインできないケースもあるようです。
つまり、ログ入手が物理的に難しく、ほとんど中身がブラックボックスのログから調査する必要がありました。
■対応内容
結論から言うと、「ピーク時間帯に250以上のSSL Client Helloがきているのに対して、HSMがカタログスペック上2,048bitのRSA署名の暗号方式で150TPS（Transaction per Second：秒間トランザクション数）の性能上限」を行うことができました。
当初は・・・
- LBがカタログスペック上4,500TPSまで対応
- お客様の検証環境における性能試験では、事象発生時よりリクエスト数上げても問題が再現しない
- 「HSMがLBの通信に影響することはない」とHSMベンダからの回答もあった
という状況で、問題を決定づけるログも出力されないため特定にかなり苦労しました。
そこで、パケットログからClient Helloに対してServer Helloが遅延していっている様子が分かり、「SSL/TLSレベルの制御をしている機器が怪しいのでは？」と算段を立てました。
▲パケログから作成した返答にかかった時間別のServer Helloの数の集計です。トラフィック量がスペックの閾値を超えだすとServer Helloの応答が遅くなっている様子が見受けられました。
【図解まとめ：何故HSMを疑うことができたのか】
■対策
HSMの増強、及び、ECC（Elliptic Cureve Cryptography：楕円曲線暗号）に対応することで、HSMが処理できるTPS値を増やす対応をとりました。
RSAの暗号方式は素因数分解の困難性を武器にしているのに対し、ECCは楕円曲線という数式を用いることで短い鍵長でも高いセキュリティ強度を誇ると言われているのが特徴です。
「RSA：2,048bit」と「ECC：224～255bit」が同じセキュリティ強度と言われていますが、性能限界が3倍程度まで上昇できるカタログスペックになっています。（RSA 2048bit:150TPS、ECC:256bit:540TPS）
「鍵長が短くなる → 暗号化/復号化処理の負荷が下がる → 性能が上がる」という論理です。
もちろんHSM側だけECC対応にしても、クライアント側もECC対応でないとECCが利用されません。
クライアントがECCに対応しているかどうかはClient Helloパケットの対応暗号方式（Cipher Suite）を見るとわかります。
パケットログからほぼ全ユーザの対応暗号方式（Cipher Suite）にECCが含まれていることを集計し、HSM側がECC対応の証明書を導入することで改善効果ありと判断されました。最近の「Chrome」や「FireFox」など一般的なブラウザは基本的にECC対応されているようです。
【類似ケース:タイムアウト連発、その裏で起きていたApacheワーカ不足】
「Apache ProxyにクライアントからConnectメソッドのHTTP送り、TCP ACKが返ってくるもののHTTP 200 OKが遅くタイムアウトする」といった相談も受けたことがあります。
Apacheのワーカプロセスが不足し、イチからプロセス立ち上げに5秒くらいかかり、レスポンス遅延を引き起こす状態になっていたことが発覚し、Apacheのパラメータをチューニングしました。
ワーカプロセス数の監視ができていればパケットログを見なくてもすぐ気づける類のものですが、「通信エラーだ」となると「パケットログを見てください」という相談になるケースがちょくちょくありますね。
【さいごに】
当社では、上記のような通信トラブルのご相談解決の他にも、通信知識を活用した開発/検証、トラブルの未然防止等、様々な取り組みを行っております。
通信エラーや遅延が起こっているが原因が分からない、新しい機能開発において通信のエラーハンドリングをどこまで考慮・検証すべきか判断できない、といったお客様のご相談にも対応してまいりました。
上記はマニアックな事例かもしれませんが、当社はスマートフォン創世記から長年通信技術の開発に携わっており、これまでに多様な通信パターンを経験し、対応してきた実績があります。
本記事に類似したお悩み、そうでなくとも通信関連のお困りごとがあれば、ぜひご相談いただけますと幸いです。
モバイル事業部 第２システム部
岡田 悠太郎
※本ページに記載されている製品名、サービス名、会社名などは、それぞれの企業の登録商標または商標です。
【公式X（旧Twitter）】
X（旧Twitter）でシェア