DDoSを受けても動くWebサイトとは

参考:WILLCOMストアが遅いのはなぜ?

 今回のWILLCOMストア祭りで、昨日書いた「停止→戻る→進む→Submit」というやり方が「DDoSと同じなんじゃない?」という話があった。DDoSに近いリクエストが来た場合どうしたらいいんだろう。アプリや設定側ではどうやって備えればいいんだろう?
 自宅のサーバと、玄箱tomcatを入れて試してみるかな…


(以下は思いつきなので、これをやればOKというわけじゃないです。念のため)

  • DDoS
  • F5攻撃
  • SYN Flood
    • 今回はSYNだけのパケットが連発するわけじゃないからなぁ…
  • doPost/doGet
  • doPost実行中にコネクションが切られたのをどう処理するか
    • DoSで一番滞留しそうなのがここではないだろうか。Servletで処理していて、レスポンスを返そうとしたらもう切れてる、というパターン
    • 普通は、処理が終わってServletOutputStreamを取りに行ったらIOExceptionで気づくというパターンが多いが、処理中に中断できたらいいかも? でも一貫性が取れなくなるのかな?
  • Static Contentsの扱い
  • Sorryサーバくらいは立てようよ
  • ハズレサーバの設置
    • さばききれないとき、分散先に1〜2台、常にハズレ(ごめんなさい画面)になるサーバを置いておいて、セッションが切れない限りそこにforwardし続ける
  • ボトルネックは?
    • Queue modelを見て、どこに処理が溜まるポイントはあるのか
  • 回線
  • 入り口側F/W
    • 回線側で80/443だけ通せばいらないんじゃん?
  • 負荷分散装置
  • SSL処理
    • 経験則では、整数演算が高速なx86が最強。最近は負荷分散装置がやってくれるらしい
  • HTTPサーバ
    • TIME_WAITの時間を短く
    • mbuf大きく(しすぎると今度はまた問題が)
    • Listen Queueを長く(しすぎると今度はまた問題が)
    • netstat -sを1分間隔で
    • PMTU Discoveryは使わない
    • セッションアフィニティを使う
  • Apache設定
    • HostNameLookup must be off
    • KeepAliveTimeoutは長くなくていい。むしろ短く
  • APサーバ
    • スレッド数
    • コネクションプール数
    • セッションクラスタは、必要ない限り、やらない
  • AP実装
    • 使い終わったオブジェクトは明示的にnull入れる
    • リリース前に一度は負荷テストをして、プロファイラを取ろう
      • wait for objectが長くないか?
    • 冗長なループはないか?
    • まとめて処理できないか?
    • StringオブジェクトをStringBufferにできないか?
    • ResultSetは逐次処理。メモリに溜めない
    • syncronizedは最小限で
    • JSPからセッションオブジェクトの参照するのは最低限で
    • DBバッチ処理中の裏でオンラインを継続するテクを活用
      • 必要な数値(カウンタなど)の更新と、実行内容のみ記録
      • バッチが終わったら実行内容を一気にDBへ反映。カードのオーソリなどはあとでまとめて処理
  • DMZ/Secure F/W
  • DB
    • SPOFになりがち
    • ロックエスカレーションが起きるRDBMSならロックバッファを大きく
    • デッドロックの起きない、起きにくい設計に
    • DBサーバ分割
      • RACDB2 EEEではなくても、APのちょっとした工夫で分散はできる
    • SQLチューニングをしっかり
    • cache is king
    • Table/Indexは別デバイス
  • その他

追記(2005/12/15)

  • ローリングアップデート可能なように作る
    • APやDBサーバを一台にしない
    • 実行プログラムはローカルに持つ(共有ディスクに入れない)

追記(2005/12/29)

このページに上記文章をベースにした、素晴らしいマインドマップがあります。
http://012.bz/blog/archives/2005/12/wzero32.html