Authentication




Cancel OK
B!コメントする  2011-06-23 15:32:00 by old

502エラーの出どころ

複雑なネットワーク構成で502エラーが「時々」発生するとの連絡を受けて調査を開始しました。
状況を整理して確認をしたところどうやら携帯で発生する模様。
しかも似たようなページ(商品の購入とか検索とかそういう感じのところ)で発生することが多いらしいとのこと。

 早速調査を開始したのですが、確かに「時々」エラーが発生してうまいこと画面が遷移しなかったり、意図した結果が得られない現象が発生しました。
 表示に関しては携帯とPCで分けていますが、検索の結果などは同一のものなので潜在的なバグと考えるには状況からしてちょっと厳しい。
 DBを覗いたり別の端末からしてみたり色々と検証してみたのですが、原因は掴めずにその日は終了。

 次の日は装備をパワーアップしてパケットのキャプチャーや、検証端末や偽装端末などありったけのものを投入して調査を開始。
 調査のかいもあって夕方ごろに原因を特定することができました。原因を特定出来たときは滅茶苦茶ホッとしました。
(もちろんそれで終わりではないですが)

 原因は1つなのですが、それが引き起こしていた問題が2つありました。
原因は

 ・クエリーが長すぎる

これだけです。どんだけ長いかと言うと1000byteや2000byteを軽く超える勢いなわけで、いくら何でもそりゃ付けすぎだろうと・・・。
むしろそういう設計になっていた構造が問題というか何と言うか・・・。そこは別の所がつくったのでどうしようも出来ないのですが。

 そんでもってこの現象が引き起こしていた問題というのが

 ・中継サーバーでの414エラー
 ・携帯でのクエリー制限

HTTPステータスコード414ってのは「Request-URI Too Large」というもんで要は

 リクエストURIが大きすぎる

ってことになります。
これはセキュリティ上のことであったりという意味合いが多いためにあることが多かったりしますが、とにかく想定外のデカいリクエストのため拒否られているということになります。
 これはあくまで中継サーバーでの出来事なんですが、検証時の携帯には502エラーというのが表示されていました。これは「Bad Gateway」という内容で

 プロキシやゲートウェイといった出入り口にあるようなサーバーが、上位サーバーから不正な戻り値を受け取った

という意味になります。
要はこの流れを整理すると

 1.巨大なクエリーが送信される
 2.WEBサーバーで処理はされるが、その結果を戻す際に経由する
   中継サーバーではクエリーが大きすぎたために414エラーとなっていた
 3.中継サーバーからは414エラーがゲートウェイを経由して携帯へ送信
   されるはずが、ゲートウェイのサーバーでは414が理解出来ず、
   不正なものとして扱われ、携帯に502としてエラーを返していた

ということになります。

携帯のクエリー制限については全ての携帯ではありませんが、docomoのサイトにこんなものを見つけました。

 http://www.nttdocomo.co.jp/service/imode/make/content/browser/html/notice/standard/

これを見ると「URLエンコード後の文字長は最大512バイト」と記載があります。
全ての携帯をもっているわけではないのですが、この現象を確認したときも、特定の携帯のみで出るというのがありましたのこの辺も関連しているんだろうと。

 ゲートウェイでの処理も見直す必要がありますが、そもそもの巨大クエリーも対処しないといけませんので、この結果を持ってクライアントに相談。
コンテンツの方は見直してもらうことになりました。
ゲートウェイの方はネットワーク部分との絡みも多く、調整が難しかったですが対処を終え、現在はコンテンツ修正待ちの状態です。

 分かってみれば大したことはないんですが、こうしてみるともっと効率のいい追求方法があったんだろうと思います。今回の調査で色々と発見もありましたので今後に活かせればいいな~と思ってます。


ネットワーク  

  • コメント
  • コメントはまだありません