DigiLoog

続きを読む »

「なんでここまで本気出した」だって？
好きなゲームブランドのWebサイトに接続出来ないの悲しいじゃないですか！

と前置きは置いといて調査結果と解決方法から。
今回エラーになっていたのは、
恐らく「www.lumpofsugar.co.jp」の稼働しているレンタルサーバで実施している(筈の)、
セッション数制限に引っかかり、Webサーバ側でTCPコネクションをDROPされていた。
ただ、推測の域を出ないので真相は闇の中へ…

………

～ Phase.0 状況整理 ～

今回は、自鯖Proxy越しにアクセスが微妙に出来ないのが問題なので、
到達目標は『自鯖Proxy越しに “www.lumpofsugar.co.jp” にアクセスする』事とした。
また、自鯖環境をフル活用して被疑ポイントの特定を行う事に。

～ Phase.1 NW回線切分 ～

まず、真っ先に疑ったのはNW回線とMTS/MSSの設定ミス。
という事で、VPN越しに筆者の所有する下記回線からアクセスしてみたが、
どのキャリアでもProxy越しにアクセスすると全部アウトという事がわかった。

よって、NW回線は問題ではなくProxy有無が問題の可能性が強くなった。
その為、以後の切り分けは全てメイン回線(NTTPC)のみで実施した。

～ Phase.2 Proxy切り分け ～

次に自鯖のProxy構成を疑った。
“ns-lab BB”のアクセスProxyは、HAProxyをLSLB(ロードバランサ)代わりに下図のような構成になっている。
なので、TCPコネクション・SSLセッション維持で不具合が出たのではと疑った。

LBSBはアクティブ・スタンバイで確実に片寄せしているのでセッションは問題無し。
Proxy指定はPACファイルで実施しており、PAC配布用のWebサーバも稼働している。
PAC配布についてセッション維持はどうでも良いのでラウンドロビンで制御。
ProxyはX-Forwarded-ForのクライアントIPアドレス元に、
ソースハッシュで分散しているのでセッション維持の被疑対象外。

という事で被疑箇所を減らす為、HAProxyを外しProxy直指定でWebサイトの確認を行ったが、
Webサイトを見る事はやはり出来なかった。
状況整理と上記切り分けを実施した事で、Proxy直指定でも駄目な事から被疑箇所はProxyに限定化する事が出来た。

そもそも、対象がHTTPなのでセッション維持は必要無いだろうし、
上記構成のままソフマ○プでエ○ゲ購入とかも出来ているので、コネクション管理・セッション維持は問題無いだろう。

～ Phase.3 パケットキャプチャ ～

という事で、いよいよProxyが怪しくなってきた。
ここまで来たらパケット直視した方が楽なので、久々にtcpdumpとwiresharkを起動。
ClientPCとProxyの2箇所で同時に、
www.lumpofsugar.co.jpのindex.htmlを閲覧した時のパケットキャプチャを実施してみた。

[左]：Proxy未設定で直接Webサイト閲覧
[右]：LSLBを使わずProxyを直指定でWebサイト閲覧

キャプチャは、LocalCache・Cookieとかも全消去して環境を出来る限り揃えた状態で実施。
結果、なんとなく方向性の見える結果が出てきた。
今回重要なのは、右側のProxy利用時はTCP Retransmissionが出ている点。
ざっくり言うと、www.lumpofsugar.co.jpからACKが返ってこなかった為、TCP再送要求が発生していた。

コレが判ればしめた物。後はキャプチャ結果を解析していけば良い。
という事で同様のパケットキャプチャを数回実施して、3日程パケットをみつづけてみた。
結果、www.lumpofsugar.co.jpへ接続しに行った時のみ、次の特長が発生している事が判明した。

1. Proxy有無に関係無く「TCP Retransmission」が発生するがProxy越しの方が圧倒的に多い
2. Proxy無しの場合、最初にTCPコネクションを数発張った後、エラーが出つつもデータを受信している
   Proxy有りの場合、最初にTCPコネクションを20発位張って、データを取得しようとしている
3. Proxy有りの場合、HTTP/503、HTTP/504の応答が多かった

ここでなんとなく思い当たる節が。

以前、別件でTCPコネクション過多によるWebサーバ応答不能のデバッグをやった事があった。
その時は、Webサーバ側に仕込んであったIPアドレス毎のセッション数制限に引っかかり、
Webサーバ側で遮断・ACKも返さなくなった為、クライアント側ではパケットが途中で破損してしまい、
HTTP/503などエラーが表示されてしまう事例があった。

『今回もコレなんじゃ…？』と思い、クライアントPCの同時コネクション数を一時的に上げてみた所、
Proxy有りの場合と同じく、エラー状況を再現出来た。と、言ってもProxy有り程の顕著な物では無かったが…
ともあれ、状況の再現性を確認出来たので後はコレを解決出来る手段を見つけるだけとなった。

～ Phase.4 打開策検討 ～

次は「Proxy越しにアクセス出来る」様にしないといけないので、
ProxyでoutboundのTCPコネクション数をClientPC(Win10-1703)程度まで減らす制御出来るのか調査。
というのも、Proxyでは受信したデータを一度蓄積した後、
一気にTCPコネクションを張りに行っている(様な)挙動をしていた事から、
「IPアドレス・ドメイン毎のTCPコネクション数を制御出来れば何とかなるのでは？」と考えた為。

今回、物は試しで、Proxyは「Squid / Delegate / WinGate」の3種類、
OSは「Linux(CentOS7) / Windows(WindowsServer2012R2)」の2種類、
LinuxについてはkernelのTIME_WAIT時短設定なども実施してみた。

が力及ばず、自分の知識・技術では実現出来なかった出来なかった (´・ω:;.:…
自分がテストしたが出来なかったのは下記の通り。
Proxyに詳しい御方、やり方知っていたら教えて下さい…

• Squid
  [pipeline_prefetch on/off]
  [half_closed_clients on/off]
  [detect_broken_pconn on/off]
  [client_persistent_connections on/off]
  [server_persistent_connections on/off]
  　
• Delegate
  ※細かいオプション知らないので接続テストのみ。が、あえなく撃沈
  　
• WinGate
  ※そもそも使い方がよく判らないのでProxy越しに見れるかのみ。が、あえなく撃沈

～ Phase.5 ワークアラウンド ～

結局の所、自力では解決出来なかったので今回は諦めた (´；ω；｀)
と言いつつもワークアラウンドは必要なので、今回はProxyPACで制御する事にした。

Phase.2記載の通り前段に構えているProxyPACで、
『”.lumpofsugar.co.jp”ドメイン宛の通信は直接(DIRECT)取得』というルールを追加した。
ProxyPACに色々と記載するのは嫌なのだが、こんな事もあろうかとPAC構成にしておいて事なきを得た。

$ vi proxy.pac

-----

function FindProxyForURL(url, host){
  // Direct access for URL
  if ( dnsDomainIs(host, ".lumpofsugar.co.jp")){
    return "DIRECT";
  }

  // Default PROXY
  return "PROXY [[ProxyFQDN:PORT]]";
}

～ Phase.6 追加調査 ～

ここまでやって解決出来ないのは敗北感が凄いので、調べられる範囲内で情報を引っ張ってみた。
下記はInternet上から取得出来る内容なので、興味ある人は迷惑掛けない程度に調査してください。
ちなみに、筆者は中の人では無い事と、下記情報の正確性担保はしない事を宣言しときます。

• ドメイン：www.lumpofsugar.co.jp
• アドレス：124.146.200.148
• 鯖事業者：WebARENA Suite V1/V2

グローバルIPのAS番号、ドメインのネームサーバ情報、whoisの情報、
DNSのSPF登録情報、などを相関的的に分析した結果だが結構良い線行っている筈。

もし本当にWebARENAを使っているのならば、
ホストを共有している他サーバに引きずられるかもしれないし、
今回の様なコネクション断は仕方ないのかもしれない (´・ω・｀)

………

なんとも煮え切らない結果となってしまったが、技術で解決出来る(殴れる)所はなんとかしたい所。
他サイトで発生する事もあるだろうし、何か解決案が無いか長期的に探っていこうと思う。
今回のワークアラウンドを実施する事で、Lump of Sugar新作ページを見れたので一言。

「木那里もみじ」が可愛すぎる！　(*´Д`)ﾊｧﾊｧ

「ケモ耳＋セミロング＋ニーソ」と色々ぶっ込んできているが､
個人的には大歓迎です (｀・ω・´)
主題歌もKiccoさんだし発売が待ち遠しい。

« 続きを隠す

続きを読む »

今回はセットリストは下記の通り。
一言で「エ○ゲーマーを倒しに来ているセットリスト」だった。

• 前半戦：げーソン

• インターバル

• 後半戦：あにソン

• アンコール

セトリ見るとわかる人はわかるが、エ○ゲーマーを全力で倒しに来ていた (；・∀・)

掴みで敢えてコンシューマ版BLAZBLUEの主題歌を持ってきて、
エ○ゲソング好き・アニソン好きの間を狙いつつ、テンションを上げる曲でスタート。
「resolution of soul」などの古い曲、「恋ひ恋ふ縁」などの新しい曲などを交互に入れてきているのは、
歴史あるエ○ゲ歌姫だから出来る技だと実感した。
戯画育ちの筆者の場合、途中の「Cream+Mint」「Leaf Ticket」でテンションがMAXに。
ただ、『次は「allegretto ～そらときみ」か！？』と思っていたら、
「未来自画像」が来たのは意表を突かれた。
まぁ、allegrettoが来たらその時点で(良い意味の)試合終了になってしまうが (｀・ω・´)

他には、前々から生で聞きたかった「jihad」「原罪のレクイエム」を聞けたのが最高。
KOTOKOのげーソンと言ったら、この二つは外せない！

………

インターバルは、曲数の関係でエ○ゲソングのアレンジだった。
最初はサクッとお手洗いに行こうと思っていたのだが、
初っぱなに「Face of Fact」が流れた瞬間に『こりゃ聞かないと駄目だ！』と思い、行くのをやめた程。
今回、生で聞けなかったが「Fatally」「ユメミボシ」が入っていたのも嬉しかった。
………

アニソンサイドは「Shooting Star」で始まって、
インターバルでクールダウンしたのが、再度テンションMAXに上がりきった。
なんだかんだで聞く事が出来ていなかったので凄くよかった。
先日、丁度おねティをマラソンしていた事もあり、
『自分の中の、KOTOKOアニソンといったらShooting Starだな』と再認識した。

他には、ハヤテのごとく関連、灼眼のシャナ関連など名だたる曲を披露しつつ、
アニそんも追い込んで行ってた。

………

アンコールは待ちに待っていた「Face of Fact」でスタート。
しかも、今回のライブ用にアレンジし直した特別仕様だった！
今までに何回も聞き込んだ曲だが、別アレンジになった事で違った印象を持つ曲に生まれ返っていた。
「INFINIT SKY」を挟みつつ「LOVE A RIDDLE」をぶっ込んできたり、
アンコールなのにさらに盛り上げて来た後、ラストに「Light My Fire」で締めだった。
アンコールで完全燃焼してしまった…　_(:3」∠)_

………

実は、3年前に無料ライブに参加したきりで、KOTOKOライブは行く機会が無かった筆者。
ず～っと、行きたいなと思いつつ念願の参加が出来て良かった。
満足度の高いライブだったが、唯一残念だったのが「allegretto ～そらときみ～」が無かった事
戯画の『丸ねこ』2部作が来ていたのだから、
3部作目となる『この青空に約束をー』の楽曲も歌って欲しかった (´・ω・｀)

筆者が、KOTOKOさんのCDを初めて購入したのは「being」だけど、
一番最初に聞いたのは「allegretto ～そらときみ～」のOPだったので思い入れ深い曲…

『エ○ゲ vs アニソン』のコンセプトは中々無いので新鮮だった。
色々な曲を持っているKOTOKOさんだから出来る技だし、
今回のようなコンセプトライブは今後もやってほしい所。
…という事を、出し忘れたアンケートに書いて、郵送提出をする事にしよ (｀・ω・´)

« 続きを隠す

続きを読む »

最初は、systemd.timerの設定を削除して今まで通りのcronにしようかと思いもしたのだが、
今後のロードマップ見ると、cron自体がsystemd.timerに移行していくのが目に見えていたので、
logrotateについてもsystemd.timerで制御する事にしてみた。

最初は設定に戸惑いもあったのだが、慣れてみるとsystemd.serviceとの連携が楽だったり、
スクリプトの実行タイミングを秒単位で設定出来るので、
ミッションクリティカルなシステムでは、使い方次第で強力なスケジューリングシステムになるかも。

systemd.timerの場合、スケジューラの表示が「systemctl list-timers」というコマンドになっているので、
cronで慣れていた(自分の様な)人は非常に抵抗がある。
ただし、前述の通り細かい時間指定が出来るのは魅力なので、今後は積極的に使ってみようと思う。

« 続きを隠す