Unyablog.

のにれんのブログ

ISUCON 13 に参加した

isucon

去年11月、Smiling Face with Halo というチームで ISUCON 13 に参加した。チームメンバーはいつもの id:utgwkk と id:wass80 。

スコアは 0! よって最下位!! 直前には 73k くらい出てはいた。

ちょっと遅くなってしまったけど、個人的に楽しい問題だったし振り返ってみる。

以下チームメイトの記事とレポジトリ。

blog.utgw.net

github.com

いつものごとく謎のユーザーで Commit されているのがだいたい自分。基本インフラ周りやってた。

DNS 対策

インフラ担当はたいていやることが決まりがちだったりするんだけど、今回は DNS 攻撃の対策担当になって色々考えていた。

まず MySQL の DB の参照を pdns と app で分けてみた結果（元から分かれてたかも？忘れました）、 DNS の参照負荷がかなり大きいことがわかった。そこで、一旦 DNS 関係を MySQL ともども一つのホストにまとめることにした。手始めに pdns が打つクエリにインデックスを貼ってみたけど、より高速に攻撃が来るようになっただけで一筋縄ではいかなさそう。

さすがに一台を DNS に潰しているのはよくないということで、 dnsdist （初見）を入れて真面目に対策を検討することにした。 tcpdump で見たところ大量の NXDOMAIN が来ているよう。

まずは、一定以上 NXDOMAIN が来たら Drop するなど BAN の仕組みを入れようとした。ただ、 dnsutil で送信元 IP アドレスとポート番号のペアで BAN を決定させる方法が分からず、うまくいかなかった。ベンチマークの IP アドレスは同じなので IP アドレスのみを基準として BAN をしてしまうと、正規リクエストも来なくなってしまう。異常なリクエストの送信元ポートは基本同じだったので、これがうまくできたらよかったんだけど。

さらにクエリを見ていると、NXDOMAIN のときのリクエストされるレコードは明らかにランダムっぽい。 regex で気合で防げるか・・・？と思いきや、アプリケーションが実際に使う record も（ベンチが走ったあとは）ランダム性が高く、確実に見分けるのは難しそうだった。

頑張っている様子。これで防げるのは一部

最終的に、NXDOMAIN なら多少遅延を入れてもいいのでは？ということに気づいた。攻撃が送られる送信元のポートが変わってないということは、レスポンスを遅延させると頻度も減るはず。

addResponseAction(RCodeRule(dnsdist.NXDOMAIN), DelayResponseAction(300))

これが非常に効果があり、攻撃頻度が無視できるレベルになり 1 台分のリソースがほぼほぼ空いた。うまく解決できてよかった～

pdns は実は使ったことがあったのだけど、dnsdist は初めてだったので楽しかった！設定言語が lua なのがよい。lua、 Python みを感じて割と好き。

反省点

いつも同じことしてるので細かい設定や各種ツールのインストールはスクリプトにしたほうがよさそう。

また、今回は前回やっていたような解析周りをあまり提供できていなかった（Kibana は用意していたが結局使わず）。需要があれば当日その場で作る、という気持ちでいたけど、ああいうのは突然欲しくなるものだし、なくてもなんとかなるけどあれば使うものなのでやっぱり準備しておいたほうが良かった。

さすがに前日深夜から全てを準備し始めるのはよくなかったね…。なんか GCP Ops Agent とか Prometheus 使ってみるかとちょっと頑張って諦めてたりしてたし…。

nonylene :tennouji_rina:
23:48 うおー立てるか
23:49 めちゃくちゃ風呂入ってた
01:39 google cloud managed prometheus 使おうかと思ったけど aws だと微妙だな～っていう結論になったので去年同様でいきます
03:26 とりあえず前回と同じ url でたてた（バージョンアップしたけどまあ大丈夫であろう）
03:30 会場 https://github.com/innocent-team/isucon13
03:37 tracer とかも変わらず使えそうだな

poyo.hatenablog.jp

そうそう、ぷりんくんのこの記事がめっちゃよかったです。Grafana で pprof 見れるのすごすぎる。クラウド使うと OSS 版より機能よかったりするし快適そうでいいですね。でも Kibana も UI 使いやすくておすすめだよ！！

その他

  • 前回からコードをレビューするムーブをしはじめて、今回も少し貢献できたので良かった
  • 最後の15分ぐらいでチーム3人の成果が集まってきて、デプロイごとに1万点上がっていくのがめちゃくちゃ楽しかった。最後は fail になっちゃったけど、最後ギリギリまで fix を入れて盛り上がってこそ ISUCON って感じがする。でもやっぱり fail は悔しいので今後も keep safe でギリギリまでやっていきたい。
  • tracing を外し忘れた結果、最後のベンチで明らかにリクエストが止まっている様子や追試うまく動いている様子がわかってちょっと面白かった。fail の覚悟ができてよかったけど外したほうがスコアに寄与しそう。

…ということで今回も楽しい問題でした、運営の皆さんありがとうございました！特にインフラ面でも触りがいがあるのは、さすが Sakura さんだなあと思いました。次は fail せずに勝ちたい！