ホーム

へぼい日記

#isucon 7 予選敗退しました

  • 投稿者: chiba
  • 2017/10/29 日曜日 13:10:52
  • ISUCON

毎年でているISUCONに今年も山形組として参加してきました。

結果は71位ということで、つまり惨敗してきました。

やったこと

選んだ言語はPerlでした。やれたことは、

  • 全3台でnginx/app 1台でDB構成に
  • index貼り
  • (中途半端だけど)クエリチューニング
  • 既存画像のファイル化と全3台への配置
  • 新規画像のファイル化と他2台への配置
  • /fetchだけfeersumにしてプロセスが詰まらないように
  • /fetchをsleep 9秒にして新規投稿があったらすぐに返すように

で、Bestスコア 81,227, 最終スコア 50,956

やれなかったこと

競技後のネタバラシで気づいたことは

  • Cache-Control: public
  • 画像ファイルの更新時間あわせ

後者は完全なる自分のミスで、競技中にEtagが揃ってるかということは気にして確認したのですが、たまたま確認したファイルは揃っていた(か確認ミスしていた)ため、強制的に揃える仕組みで配置していなかったことに気づかず終わりました。
画像をファイル化してからボトルネックが帯域だと分かっているのに4時間ほど何もできないままでした。
本戦出場されているみなさんのblogをみていると、リクエストHTTPヘッダを冷静に分析するとか、Cache-Controlの仕様を読み直すとかやれることは確実にあったので、実力不足を痛感しました。

Cache-Control: public

これつけなくても普通はキャッシュするジャンスカともやっとしていたのですがRailsのアセットパイプラインのドキュメントだとpublicをつけることが例示されていて、実際にGCPのCDNでは“Cache-Control: public ヘッダーがある。”というのがキャッシュの条件として明示されていることも確認できました。

静的ファイルのCache-Control: publicは今後は実務でもつけていこうという知見を持ち帰ることができました。

来年

人任せなので希望でしかないですが、来年あったらまた参加したいです。

出題チームのKLab、主催のLINE、サーバー提供のSAKURA internetの皆様、本当にお疲れ様でした。本戦もよろしくお願いしますといえないのが非常に残念ですが、本戦の様子がレポートされるのも楽しみにしております。

はてなブックマーク - #isucon 7 予選敗退しました

Web高速化請負事業はじめました

  • 投稿者: chiba
  • 2017/2/28 火曜日 13:25:31
  • 会社

http://e-dreamer.co.jp/wp-content/uploads/2017/02/pressrelease_20170228.pdf

本日上記のとおりリリースをだしましたが、Web高速化請負事業をはじめました。

このブログは一応会社ブログということでやっているのですが、ここ最近は会社でやっていることを書くでもなく社内有志で参加しているISUCONの報告ばかりになっていました。というわけで、趣味がこうじて事業を興すということに。

ビジネスにしてしまえばチューニングを仕事でもっとできるし経験値もあがるぞーという企みもあります。

つきましては、「遅いWebサービス」「重たいWebサービス」「いまひとつ快適さにかけるWebサービス」を抱えてお困りのお客様を募集いたします。
具体的には、たとえばこんな方をお待ちしております。

「直帰率が高く、原因が読み込み速度が遅いことに起因している」
「サービスが全体的に遅いからとにかく速くしたい」
「他社にチューニングの見積りを依頼したら、『イチから作り直さないとダメだからウン千万円』かかると言われた」
「前任者と連絡がとれなくなったので、何がなんやら」
「予算が限られているから、特定の機能だけ速くしたい」


そのむかし、Wantedlyをsecondlifeさんが高速化したことがありましたが、こういう事例を想定しています。

種々の制約がある方も、どうぞ諦めないでご相談ください。

高速化技術の例

SQLクエリ改善、DB設計改善

重くなる原因最多ですが、着実に改善させていただきます。

アプリケーションのチューニング

Web系の言語にはだいたい対応できます(Perl/PHP/Ruby/Python)。

サーバースペック、構成の計画

サーバースペックや構成が現状の利用状況に合っていない場合には、再構成計画の提案もさせていただきます。
ioDriveの提案も辞さないです。

お問い合わせ先

株式会社イードリーマー
山田/千葉(fastweb@e-dreamer.co.jp
電話:03-6427-3994  FAX :03-5778-3003

#isucon 6 本戦10位で負けてきました

  • 投稿者: chiba
  • 2016/10/30 日曜日 17:41:42
  • ISUCON

ISUCON6本戦に山形組でISUCON4以来の2年ぶりに参加してきました。結果は既報の通り予選で1位だった「この技術部には問題がある!」チームさんが勢いそのままに優勝され、予選2位だった我々は本選では10位という残念な結果となりました。(予選の結果は本選には何も関係ありませんが)

山形組の過去を振り返ると
ISUCON1、下から数えたほうが早い順位
ISUCON2、準優勝かつ特別賞
ISUCON3、予選総合3位本選5位
ISUCON4、予選総合4位本選10位
ISUCON5、予選落ち
ISUCON6、予選総合2位、本選10位

とまあ、なんとも煮え切らない歴史になっており、せめてISUCON5で予選通過さえしてれば全部でてるんだと胸を張れた部分もあるんですが。

やったことなど

Docker( Compose)で Node.js, mysqld, App が起動されていて、かつNode.jsという特定の言語のアプリケーションが配布時は選択肢なく居座っているというのがいままでになく、Dockerはかろうじて遊びで触ってはいたけどNodeはチュートリアルすらやったことがないという状態で、これはやばい…というのが最初の印象。

で、いつものごとくAppはPerl実装に切り替え。

お絵かきをストリーミングで実装したアプリケーションってことで。お、ストリーミングは昔Plackの実装で遊んだことあるなー、必要になったらそのときのコード持ち出してやってみるかーと思ったものの結局できず。ストリーミングの部分、2秒以内であればPubSub的な実装でそれ以上はやくしてもスコアに直接は影響なかったようなんですが、mysqldへのポーリングがなくなって全体的にチューニングしやすくなったはずなので、やれなかったのは悔いが残るところ。

Dockerによる構成ついては、それ自体が勝敗を分けるパフォーマンス上のボトルネックになるわけがないと思ったので、当初はそのままでアプリケーションの改修をしていくことに。
ところがAppのコードの変更を反映する方法がわからず、イメージの削除をしてかなり時間のかかるbuildしなおしをする方法しか見いだせず…。これは開発上のボトルネックになるなと判断して、Appとmysqldについては外だしを行い、Node.jsはやったこともない環境構築で意味なくはまるのも怖かったのでそのまま。

フロントにNginxをたててTLS終端もそこで行いつつ、Node.jsをHTTPSからHTTPのサーバーに切り替え。
Node.jsのAPI-URLはNginxを一度経由するようにしてAPIをほかのサーバーに分散できるように。

全サーバーでAppを立ち上げてNginx経由で標準分散。

strokeとpointsの取得がN+1だったところを2回のクエリになるように調整。

C10kにはMonocerosやろってことで/api/stream専用のAppをMonocerosでたちあげ。(keep-aliveじゃなくて全プロセスがDBのポーリングしてるので意味なかったんだろうけど…)

あとは各プロセスのワーカー数の調整とmysqldのtoo many connection対策に腐心して終了。

ワーカー数の調整は/api/streamにめいっぱいふっとけばもっとスコアあがったのかもしれないなぁ…。

感想

構成に面喰いすぎて、普段やっている1時間後の戦略会議的なこともきちんと行えなかったし、全体的にふわっふわと場当たり的なことばかりしていて、よくある負けパターンに陥ってしまっていました。
ほかにもチームメイトとの連携など反省点はたくさんありますが、次回以降にそれを活かせるよう普段の仕事でも意識していければなと…。

過去のISUCONにそれなりにでている自分ですが、懇親会で周りを見渡してみると、参加者で一方的にでも顔を知っている人は優勝(経験)者の方とYappoさんのチームとあと何人かぐらいで、こうして普段接することのない人たちと競い合い、感想をぶつけあうことができるというのは本当に素晴らしいことだと思います。(あまり積極的に懇親するタイプではないですが…)
個人的な余談ですが、学生チームの中には自分の息子と同じ学年(高1)の方がいたそうで、そのチームにはなんとか勝ってたようなんですが、これはいよいよ大変なことになってきたぞと。

そして、はたしてISUCON7は開催されるのか…どこが出題するのか…。まだわかりませんが、開催されたらもちろんまた参加したいと思います。

予選・本選の出題者のみなさん、主催・共催をされた企業の方々、今年もめいいっぱい楽しませていただきました。ありがとうございました!

#isucon 6 予選二位で通過しました

  • 投稿者: chiba
  • 2016/9/24 土曜日 18:14:08
  • ISUCON

去年は初めて予選敗退し悔しい思いをしたISUCONに今年も山形組として参加してきました。

結果は総合二位で本戦出場を決めました。やった!

事前準備

前日にメンバーで作戦会議をして、「フルスクラッチ書き換えはやらない」という方針で大決定。過去フルスクラッチ書き換えでそこそこの結果を残してきた我がチームですが、去年の予選で手痛い失敗をしたのもあり今年は確実に予選を突破しようということで封印することになりました。

過去問を改めて解いたりはしなかったですが、matsuuさんのazure-isucon-templatesの一つをazureにdeployしてみて、なるほどazureはこういう感じかというのを確認したりはしていました。

当日

10:00

はじまっておもむろにazureにdeployしたところ

テンプレート デプロイ 'Microsoft.Template' は、検証プロシージャによって無効と判断されました。追跡 ID は 'a080b1d6-56fc-47d7-9228-9de96209bd0e' です。詳細については、内部エラーを参照してください。使用方法の詳細については、https://aka.ms/arm-deploy を参照してください。 (コード: InvalidTemplateDeployment)

というエラーがでてしばらく苦しめられる。もしやとおもい検証用にdeployしていた過去問のリソースを削除したら解消。


fujiwaraさんのこのtweetはもちろん見ていたので、事前に従量課金サブスクリプションを作っていたんですが、今確認したら従量課金なのに無料試用プランであることには変わりがないようで、これどうやって解放するのかわからん。さようならazureという気分です。

deploy完了後、初期状態でPerlで動いていることを確認し、そのまま行くことに。
その後1時間ほどは

  • 初回ベンチ実行
  • コードのローカルへの転送とgitへの展開
  • nginxアクセスログを解析用に修正
  • カーネルパラメーターやapt-get, cpanfileの秘伝のタレの投入
  • コードの解読
  • プロファイリングするまでもない明らかにボトルネックになるポイントをさくっと修正

などをやる。プロファイリングするまでもない明らかにボトルネックになるポイントの修正は具体的には

  • ON DUPLICATE KEY UPDATEの無駄なデータの二重転送排除
    -        author_id = ?, keyword = ?, description = ?, updated_at = NOW()
    -    ], ($user_id, $keyword, $description) x 2);
    +        author_id = VALUES(author_id), keyword = VALUES(keyword), description = VALUES(description), updated_at = NOW()
    +    ], $user_id, $keyword, $description);
    
  • is_spam_contentsをtitle/bodyでひとまとめに
  • isupam, isutarへの接続をkeepalive

といったあたり。このへんをやって11:30ごろ5262点で暫定2位の状態で最初の作戦会議の開催。

11:30

スコア: 5262
第一回作戦会議。アクセスログの解析はできていて、静的ファイル配信とトップがとにかく遅いというのを確認。

  • cssのnginx serve
  • isutarをisudaに吸収
  • gzip_static

をまずはやりましょうとなる。キーワードリンク作成のhtmlifyが本丸でしょうという話はしたけどこの時点でこれについての具体的な解決策はなし。

12:07

isutarのisudaへの吸収完了。
スコア: 5262->5392
が、スコア上昇は誤差の範囲。既にkeepaliveはしていたのでこの時点では意味のない施策だったんだと思われ。ただし状況が進んでハイトラフィックな状態になると効いてくると思うので問題なし。

12:09

isudaのworker数を20にしてみるとスコアが倍増
スコア: 5392->11090

12:14

static fileのnginx serve
スコア: 11090->10902
うーん、誤差の範囲。
このあとmysqlのindex作成など細かい施策をしばらく繰り返すがたいしたスコア上昇には繋がらなくなってきたため、本丸のhtmlifyの改修に着手。

14:04

スコア: 11090->25048
トップページ表示のときに正規表現の作成がエントリごとに行われていたのを1回に集約

16:17

正規表現とキーワードリストをmemcachedにキャッシュ
スコア: 25048->61473

htmlifyの最適化は2時間以上ずーっと取り組んで着実にスコアはあがっていったしずっとボードの5-6位以内につけてたけどこのころすでに20万点オーバーのチームが現れており、このままじゃ駄目だ…と焦りはじめる。

なにか違うアプローチでブレークスルーをおこさないと勝てない、ということでhtmlごとキャッシュの戦略を実施する方向に転換。

16:59

PlackのsessionをPlack::Middleware::Session::Simpleに置き換え。


logoutの処理を

-    $c->env->{'psgix.session'} = {};
+    $c->env->{'psgix.session.options'} = {expire => 1};

にしないとセッションがちゃんと切れずにベンチがfailするのにしばらくはまるが解消。
スコア: 61473->67663
キャッシュするための準備でしかないが、スコアがあがり期待が高まる。

17:03

nginxで$cookie_isuda_sessionがない時だけ

proxy_cache_valid  200 1;

をするようにする。

スコア: 67663->228217

きたー。

で、しばらくもうちょっとスコアあげられないか試したけど誤差の範囲でしか変わりがなかったので17:30ごろにはあとは再起動検証をして終わりにしましょう、となり再起動…

17:38

再起動後1回目

スコア: 18万点台(正確なのはとっておらず)

ん、ちょっとおちたなぁ、mysqlのウォームアップ的なあれだろうか、ともう一度実行することに。

スコア: 30435

え?なんで?何がおきたの?
まったく原因もわからず混乱する一同。そして祈りながらもう一度ベンチマーク実行するも、また数万点台のスコアを叩き出す。
残り時間15分。終わった。俺たちの夏は終わってしまったんやー。
と、泣きそうになりながらもう一度再起動をしてみる…。

17:50

再起動2回目

スコア: 19万点台(正確なのはとっておらず)

よし!なんでかわかんないけど命拾いした!ベストスコアからはおちてるけどこれは予選突破できる数値でしょう。
もうやめよう…と思ったけど、「もう一度走らせてみましょう」というチームメンバー。まじか。止める間もなくエンキューされる。

スコア: 223103 (17:54:14)

なんとその日のベストスコアを更新。そのままフィニッシュ。

感想

最後のはなんだったのかいまだに分からず。終了後にidobataで疑問を呈したりもしたのですが、1秒間のキャッシュというきわどい戦略だったので減点によるブレが大きかったのではないかという推察で終わっています。
エンキューガチャ的なことはなかったと信じたいけど、ちょっとだけもやっとしているので、ベンチの再現環境が提供されたら、いろいろと試してみたいです。

うちがhtmlごと1秒キャッシュというきわどい戦略だったのに対し、他の通過者の感想エントリーを見て回るとhtmlifyの最適化やプリレンダとその効率的なinvalidationなど自分にはできてないことがたくさんあって勉強になるし、これらをちゃんとできるようにならないと本戦は無理だろうなという感じで、2位通過なのにだいぶ厳しい気持ちになっております。

何はともあれ、再びヒカリエでの本戦に参加できることは本当に本当にうれしいです。

songmuさんをはじめ出題者のみなさん、運営者のみなさん、お疲れ様でした。本戦もよろしくお願いいたします。

今度こそ優勝するぞ!

#isucon 5 予選、惨敗でした

  • 投稿者: chiba
  • 2015/9/28 月曜日 15:21:37
  • ISUCON

毎年でているISUCONに今年も山形組として参加してきました。

今年もオンライン予選があり、9/26(土)の一日目に参加し結果は最高スコアが3000を少し超えるぐらいで惨敗でした。

簡単に何をしたのかをまとめると

事前作戦会議

チーム数多いしボーダーあがって厳しいことになるだろうしトップ狙うつもりでやらないとだろうなとは思ってます

イチかバチかで飛び道具でも使って普通じゃないことをやらないと勝てないと思い込み
kazeburoさんのこの時のエントリなどを読み込み脳内素振りを繰り返す。

当日

11:00
動作確認、コードリーディング

11:30
apt-get update;apt-get dist-upgrade;apt-get install xxx,xxx,xxx & reboot
diskがroの罠にはまる。解決策はわからず、instance作り直し

12:30
第一回作戦会議

今回もインメモリDBでいけそう

という作戦決定…。
mysqlのデータ量がぎりぎりメモリに載せられそうだしこれはインメモリDB組に対する挑戦状や、とか思ってしまいました…。
ちな、/var/lib/mysql/isucon5q/データ量が2.4Gでメモリが3.6G

12:30-15:00
perlにentriesもcommentsものせようとする。が、ある一定の量をのせるとまったく処理がすすまなくなる。おそらくmysqldが確保するページキャッシュとの食い合い。mysqlテーブル側をROW_FORMAT=COMPRESSEDにしたりbuffer_poolを減らしたり増やしたり、Perl側のデータの持ち方を効率化したりいろいろ試すも最後まで実行できず。これはLLなPerlじゃ無理じゃね…と15時ちょうどに断念。(後日富豪インスタンスサーバーで試し、全部読み込んだらPerlのプロセスのメモリが4G超えました!!)

15:00
第二回作戦会議

王道チューニングで1から再開しましょう

16:30
普通のクエリのチューニングを進めていくものの、上位陣が1万を超えるようになってきて焦り

もうだめぽ…こんなふつうのチューニングじゃ勝てない…

ということで、htmlのキャッシュ生成をやってそれを返すとこまでやらないと駄目だと思い込み、その作業を進め始める。

17:40
userデータ5000件のindex.htmlの用意が終わり、それをキャッシュ更新/参照する仕組みでスコア1200ぐらい

18:30
POST時にキャッシュ更新してて3秒にまにあわないから途中でやめてあとはinvalidateだけしていたのをなんとかしないと…そもそもindexの作成のコストがまだクエリチューニングが終わってなくて高すぎる、でも時間ない、ということでPOST時にキャッシュ更新はやめてinvalidateだけするようにしたらスコア3000ちょっと超え、その後悪あがきで/friendsのクエリチューニングなどを始めるもそのままフィニッシュ

最終形のコード

感想

飛び道具(今回の場合インメモリDB)の使いみちをきちんと判断できるようになるべきだったなというのが最大の反省点です。
GOで本文データの持ち方を工夫しながら実施して予選突破した方もいたようですしもうちょっとやり方はあったなぁというのもあります。

ISUCON、初期スコアの100倍、200倍にしないと勝てないみたいなのが通説としてあって、だからそれをやってることってめちゃくちゃすごいことなんだと思いがちなんだけど、初期のコードは本当にクソなので、それの100倍でも普通ぐらいのレベルだという学びもありました。後半も、王道といいつつhtmlキャッシュ作成というキテレツなアイデアに執着しており、そんなことは後にしてまずはシンプルにクエリチューニングを進めるべきだし、結局キャッシュ更新速度のためにもそれは必要だった。

毎回本戦に参加していたのもあって思った以上に悔しい気持ちで、夜どうしても寝れなくて昨夜、まだベンチマークもないのに一人反省会で時間があったらやれた後半のチューニングを進めたりしました。githubにあげてます。基本的にほとんどのページでhtmlをそのまま帰すだけの構成になってます。たぶんバグがまだあるけど通ればトップチームに近いかそれ以上の数値がでるんじゃないかなぁ…。

いろいろやれることは多くて非常に面白い問題ではありました。

本戦にいけなくて本当に悔しいですが、来年も、、、あるのかな、あればもちろん参加したいです。

今回も出題チームの皆様は本当に大変そうで、しかし見事にISUCONの予選を成立させており、素晴らしいとしか言いようがないです。本当に感謝です。
あわせて、主催・共催のLINE、Treasure Data、テコラス、Googleの皆様、ありがとうございました。

YAPC::Asia Tokyo 2015に参加してきました

  • 投稿者: chiba
  • 2015/8/24 月曜日 3:01:10
  • perl

8月20日から3日間にわたって東京ビッグサイトで開催されたYAPC::Asia Tokyo 2015に参加してきました。

2012年にスピーカーで参加してから、2回連続で足が遠のいてしまっていましたが、やはり参加すると刺激をうけてよいものですね。

3年前の自分のトークのようなPerl製の(モジュール|プロダクト)名がタイトルに入っているトークはほとんどなくて(あ、LTではcpmがありましたね!)何とも言えないわびしい気持ちになったりもしましたが、その多様性を受け入れる文化も日本のPerlCommunityの素晴らしさなのかなと思ったりもしたり。自分が参加したトークの中ではやはりGoの話が多くなっていて、そろそろ手を付けるか…という気分になって帰ってきました。

YAPC::Asia、lestrratさん(JPA?)が主催するものとしては10回目の今回で最後とのことで、いままで主催されてきたmiyagawaさんTAKESAKOさんlestrratさん941さんyusukebeさんによる【特別企画】YAPCあるあるもみてきました。自分は2007年からの参加ですが、過去のすべてのトークで一番印象に残っているのは、2009年のPSGI – Perl Server Gateway Interfaceです。もともと別の内容のトークが予定されていた枠を変更して発表の数日前に誕生したばかりのPSGIとPlackの紹介を、miyagawaさんとtokuhiromさんがライブコーディングも混じえながら行うというものでした。その後PSGI/Plackは驚くべき速度で普及しましたが、YAPC::Asiaという場がその普及の役割の一翼を担ったことは間違いないでしょう。

なにはともあれ、何年にもわたり主催されてきたlestrratさんはじめ、スタッフのみなさま、本当にありがとうございました!

#isucon 4 本選10位で惨敗でした

  • 投稿者: chiba
  • 2014/11/11 火曜日 6:27:48
  • ISUCON

ISUCON4本戦に毎度おなじみ山形組で参加してきました。結果は既報の通り、われわれは8千点前後の団子状態から抜け出すことはできず、60倍以上のスコアを叩き出したLINE選抜チームが連覇となりました。おめでとうございます。

ISUCON2で2位を取って以来、ISUCON3で5位、そして今回10位と順位を下げ続けており、年々高まる参加者のレベルが恐ろしい限りです。

やったこと

  • redisを落として本当のインメモリDBアプリ化(aサーバ)
    「来年、もう一度来て下さい、本当のインメモリDBアプリで優勝させますよ」
  • slot-IDベースでのnginxによる3台のサーバへの動画postの振り分け

    • ad-IDはaサーバのアプリに問い合わせて発番した上で動画ファイル保存
  • asset-URLをあらかじめslot-IDベースで3台のサーバのアドレスに分散

    • nginxからmp4を直接serve
  • –hostsは3台のPrivateアドレス指定。

    • 当初Globalアドレスでベンチが通らず、運営からPrivateアドレスを使うようアナウンスが出てた覚え

やれなかったこと

Plack::Handler::Nginx化
 高rps化しなかったのでやっても意味はなかった

感想

これから出題者側による詳細の講評があると思うのでそれを見てみないと最終的な判断はできないとは思いますが、優勝チームのkazeburoさんのエントリを読む限りでは、ベンチマーククライアントが特殊すぎる状況を模倣してるように見受けられます。
いつもやっていることを当たり前にやることでスコアを伸ばさせたかったんなら、redisからLast-Modifiedを付けずに動画を配信しているところから、ファイル化していつものようにnginx等のwebサーバに配信を任せて、Last-Modifiedが付いた時点で、クライアントはキャッシュするべきだった。
もちろん、Cache-Control(max-age)/Expires をつけることはより良いことだし一足飛びにその設定をする場合もあるだろうけど、普通は狙う効果が違って、これは304すら無くす場合に設定するものです。
実はCDN経由でデフォルトのmax-ageが0でした~という話もあるようだけど、サーバのIPアドレス直でアクセスさせておいてそれはかなり苦しいし、もし特殊なip routingを駆使してそれを実現しているのであればそれこそいつもやってることを当たり前にやってもしょうがない話になってしまう。前任者はトラックにでもはねられたのだろうか。
ISUCONの面白さは、一般に存在する”問題”が散りばめられていて、経験者はいつもやっていることが功を奏し、そうでないものは今後に活かせる教訓を得られるということだと僕は思っています。ISUCONにしか存在しない”問題”が作成され、それが解けたか解けないかで出題者が出場者に勝った負けたと騒ぐイベントだったのかなぁと。

というわけでたっぷり負け惜しみを書きました。

来年も開催されるとのことですが、予選を含めた過去のISUCON本番計測のすべてにおいて完走というちっぽけな記録が継続中なので来年も最低限そこは死守しつつリベンジします。もう負け惜しみを書きたくないです。

出題を担当されたクックパッドの皆様、主催/共催の、LINE、テコラスの皆様ありがとうございました。

#isucon 4 予選参加してきました

  • 投稿者: chiba
  • 2014/9/29 月曜日 18:53:44
  • ISUCON

毎年でているISUCONに今年も山形組として参加してきました。

今年もオンライン予選があり、9/27の一日目に参加し結果は暫定で7位でAMI審査に問題がなければほぼ予選通過はすると思われます。

で、今年は何をやったか、というとあいも変わらず去年と同じことをしておりました。去年と同じ方式でかくと

やったこと

静的ファイルはnginx serve
アプリ全書き換え
 1fileなPSGI
 データはすべてオンメモリ
 永続化はテキストファイルへ追記
nginx embedded perl + Plack::Handler::Nginx ←NEW!

最終形の構成をgithubにおいときました。

やれなかったこと

無し

最終提出スコア

–workload 8で
62145

コンテスト中の流れ

事前にHDD8G メモリ15Gのm3.xlargeインスタンスだとわかっていたので、それがボトルネックの解消につながるかは別として、インメモリDBアプリにすることは可能だとわかっていました。
で、蓋をあけてみたらいままでで最も簡単な内容のアプリだったため、いつもの通り全書き換えしつつのインメモリDBアプリをFeersumで動かす方針に決定。
もう一人のメンバーにクエリ書き換え等の王道チューニングを進めてもらいつつ、14:10ごろに書き換えとバグとりが完了。workloadの調整などをおこない、14:20ごろにworkload:5 58000ぐらいのスコアで提出。この時点では2位。nginxによるキャッシュをいれて、14:28ごろ、workload:6 60806で提出。1位。
この時のチャットログ

9/27 14:28 
workload:6
tag:benchmarker type:score      success:281500  fail:0  score:60806
で提出完了
9/27 14:28
もうほぼ限界だとおもう
...中略...
9/27 14:31
もう10チーム以上6万台の誤差勝負とかにならない限りは大丈夫だとおもう

というわけでしばらくのんびりしていたら、いつのまにか7万点台のスコアを叩き出すチームが現れ…。

16:13
うおおおおおおおおおおおおおお
16:13
7万ごえきた
16:13
YABAI!
16:18
まじか…
16:21
nginx embededやるか…

と、この時点では、nginx->feersumというリバースプロキシ構成だったので、nginx embeded perlで完全に1プロセスにしてしまうことに。
で、nginxのビルドやPlack::Handler::Nginx自体への修正なども行い、新たなバグとも戦いつつ

17:47
tag:benchmarker type:score      success:287690  fail:0  score:62145

で、フィニッシュとなりました。もっとスコアが上がって7万点台に届くとおもっていたので、トップの人はどうやってるのか謎すぎる状態での終了でした。
結果も更に順位が落ちて7位となっていました。

感想

で、workload解法があったということだったのですが、まあこういうことも含め競技だとは思っていますので結果には納得していますし、その後の運営の対応も素晴らしいものでよかったと思っています。

出題内容は、過去のパターンと比較しても優しすぎて、参加人数が増えている今となっては上位スコアが団子状態になってしまってるんじゃないかなぁと。いろいろな制約の上での出題だと思いますので、難しいところではあるとは思いますが。

本戦はもちろんそういったことにはならないと思っていますので、(出場できるであれば)準備を万全にして臨みたいと思っています。

なにはともあれ、出題されたクックパッドの皆様、主催・共催のLINE、DATAHOTEL、Amazonの皆様、ありがとうございました。
本戦の出場が正式に決定しましたら、その際はまたどうぞよろしくお願いいたします。

#isucon 負けてきました

  • 投稿者: chiba
  • 2013/11/10 日曜日 18:30:30
  • ISUCON

ISUCON3本戦に毎度おなじみ山形組で参加してきました。結果は過去2回の出題者チームであるLINE選抜チームが圧倒的スコアで優勝という結果で、さすがでした。

うちは一応本番計測で完走したため5位という結果でしたが、途中経過では11位ぐらいをさまよっていましたので惨敗といって良いと思います。
ちなみに、予選も含めた過去4回の本番計測すべてを完走しているのはうちだけじゃないでしょうか。パーマネントなチーム自体が少ないので個人単位ならいるかもしれませんが。

やったこと

nginx化
serve static
x-accel-redirect
既存画像の事前リサイズ
新規画像のPOSTはオリジナルを置くだけにして、リサイズをApp::watcherで実施
明らかに無駄なコードの最適化

やれなかったこと

インメモリDB化
画像ファイルのストレージ分散
新規画像のリサイズ処理のCPU分散

コンテスト中の流れ

いつもどおり開始から1時間ほどは現状分析を行い作戦会議をしたのですが、初期画像データがだいたい3Gあり、そのSML版を作ると最大12Gになるからこれをメモリ4Gの4台でうまくすべてをファイルキャッシュにのせるようにしましょう、で、変換もそれぞれの分散先のサーバ自身で変換するようにしましょうと話していました。のちにimageのL版はなく、さらにオリジナルの劣化版をつくっておけば(LINEチームはそれで画像サイズを1/3ぐらいにしたそうです)1台でもそれなりにキャッシュにのることを知ることになるわけですが。

あとは、転送量制限が最終的には問題になるからフロントは5台にして内部のアプリケーションサーバ(1台)にPrivate IPでリバースプロキシしましょう、という戦略でした。(アプリケーションサーバが1台なのはインメモリDB化を見据えていたため)

画像の転送はNFSという話もあがったのですが、アプリケーションサーバを画像ストレージ用のサーバにも置いてそこにPOSTすれば楽にいけそうですねとなりました。

あとはいつもやっているアプリケーションの書き換えは今回はさすがに他にやることが多すぎて無理っぽいので部分書き換えで、最終的にはmysqlのデータのインメモリ化までいけたらいいね、といっておりました。

結果、最初にたてた戦略の半分も実行できず、既存画像の事前リサイズで6800ぐらいを出したところでボトルネックを見失い、timeline等のmysqlのクエリチューニングに走ってしまい、そこからはたいしてスコアがあがらずに時間の浪費。

終了30分前ぐらいに、そういえばworkloadをあげてなかったと、あげてみたところ新規画像のリサイズのCPUボトルネックになってFAILすることがわかったのですが、もう時間的に根本対策は無理で終了。

感想

予選のあとにインメモリDBどうなの話の流れで @methane さんが


っておっしゃってたのを見ていたので、「あ!ここtwitterでやったやつだ!」となりました。

アプリケーションロジックやMySQLのチューニングがボトルネックになるのは多分まだまだ先の話で、まずは画像の配信時の処理を速くすることと、workloadをあげていった時に新規画像の生成(CPUボトルネック)をいかに矛盾なく速くするかという戦いだったように思います。(自分は後者の戦いにはほぼ参加できていませんが)

あとはアプリケーションの複雑性があがっていたり、まっさらのサーバが4台あったり、既存データの処理を別途する必要があったりで、発想と瞬発力だけではなく、きちんとチームとして機能していないと勝てないようになっているように感じました。(正直二人ではきつかった)

ということで、かなり悔しい思いでいぱいですので、来年またあったら3人目の組員と共に参加したいとおもいます。

主催/共催のカヤック、LINE、DATA HOTELの皆様ありがとうございました。

#isucon 3 予選総合3位でした

  • 投稿者: chiba
  • 2013/10/7 月曜日 2:41:23
  • ISUCON

毎年でているISUCONに今年も山形組として参加しております。

今年からオンライン予選があり、10/5の一日目に参加し結果は現在のところ暫定で3位で予選通過の予定です。
暫定なのは使ったサーバの運営側による検査が残っているためです。

で、今年は何をやったか、というとあいも変わらず去年と同じことをしておりました。去年と同じ方式でかくと

やったこと

アプリ全書き換え
 1fileなPSGI
 https://gist.github.com/nihen/6852251
 feersum(1プロセスマルチスレッド)
 データはすべてオンメモリ
  スレッド間でシェア
 永続化はテキストファイルへjsonで追記
html renderのキャッシュ(といってもmarkdownぐらいか)
リバースプロキシをnginxにして静的ファイルもそこでserve

やれなかったこと

benchmark –workloadの試行
さらなるhtml renderのキャッシュ(メモリストの各liとか)
POST後に与えられている1秒間の猶予の活用
nginx embedded perl
 Plack::Handler::Nginx
 二年ぶりにnginx,perlそれぞれ現在の最新バージョンでやろうとしたらまったく原因不明のbugった挙動になっており、断念

コンテスト中の流れ

まず始まる前から決めていたのは、外部要件をブラウザで丁寧に確認するということでした。
予定通りこれを時間をかけて行い、その後それに対応したコードの読み込みを行い予め取り決めていた11:30にそれを打ち切って作戦会議。ここまでコードやサーバに変更は一切なし。ベンチマークは初期状態で実行しました。

作戦会議の結果、前回と同じ手法が使えるはずと決まり、実装開始。今回は前回よりアプリケーションとして複雑というのもあり途中少し諦めかけるも、14時ぐらいには完成。意気揚々とtestを実施するもFAIL。まあ一発で成功するとおもってもいなかったので出てきたメッセージを元にひたすらデバッグ。しかしだいたいめぼしいバグとれただろう…という段階になっても原因不明なFAILがまったくとれなくなり、ここでひたすら時間を浪費する。

2013/10/05 16:58:11 [FAIL] Post http://localhost/mypage: EOF
2013/10/05 16:58:11 [FAIL] Post http://localhost/mypage: EOF
2013/10/05 16:58:12 [FAIL] Post http://localhost/memo/41324: use of closed network connection
2013/10/05 16:58:12 [FAIL] Post http://localhost/memo/41326: use of closed network connection
2013/10/05 16:58:12 [FAIL] Post http://localhost/memo/41325: EOF
2013/10/05 16:58:12 [FAIL] Post http://localhost/memo/41328: EOF
2013/10/05 16:58:12 [FAIL] Post http://localhost/memo/41327: EOF
2013/10/05 16:58:21 [FAIL] Get http://localhost/recent/35: EOF
2013/10/05 16:58:41 [FAIL] Get http://localhost/recent/89: EOF
2013/10/05 16:58:45 [FAIL] Get http://localhost/recent/31: EOF
2013/10/05 16:58:46 [FAIL] Get http://localhost/recent/60: EOF
2013/10/05 16:58:56 [FAIL] Get http://localhost/recent/168: use of closed network connection

出てたエラーはこんな感じ。ログに書かれている時間を見ると分かるように、この状態で残り1時間を切るという状態に追い込まれておりました。もうこれはだめかもわからんね、という話をし、ここから1時間王道チューニングで足掻こう…と既存アプリのチューニングを始める。

計測はしていないものの全要件をコーディングしていたおかげでボトルネックはなんとなく把握していたので、ボトルネックの解消自体は順調に進められたのだけれども、いかんせん時間が足りそうになくその頃既に1位は3万点台を計測しており、もうこれはやはりFAILを取ることに全力を傾けたほうが後悔はないだろう、と再度17:30ごろにFAILをとることに舵を切り直す。

で、実はFAILをしていたときはテストがしやすかろう、とFeersum単独で80ポートをlistenしていたのだけれども、Apacheからリバースプロキシというもとの構成にもどしてみる。しかしまだFAIL。ここで静的ファイルをApacheでServeをやっていないことに気づくもAliasの書き方等をぐぐる時間も無かったので、豊富にローカルに設定を持っているnginxに切替え、静的ファイルのserveをしたところ…Success!。急いで本番用のbenchmarkコマンドを実行し、32270点を出したのがたしか17:45ごろ。あとはちょこちょこアプリを修正しつつ終了。正直いまだにFAILの原因は分かっておりませんのでベンチマークツールが公開されたらじっくりしらべてみようと思います。

というわけで長々と書いてしまいましたが、つまりギリギリまでスコア提出をほとんどしていなかったのは高度な情報作戦でもなんでもなく単純にFAILしていたからなのでした。

感想

前回参加からのこの一年の間に、幸運にも負荷を要因としたスケールアウトが必要になるような案件に携わらせていただいており、そういった王道チューニングもいいだろうなぁと思いつつも、いまの自分の実力的にはやはりこの飛び道具を使わざるを得なかったというのが実情ではあります。

今回はKlabさんのチームも似たようなアプローチで2位にはいっており、運営のfujiwaraさんも対策すると言明されているので、本戦でまったく同じアプローチが通じるとは思っていません。本戦まで本業のほうも含め王道チューニング的な経験値、やはり増やして臨みたいところですね。

主催されたfujiwaraさんをはじめKayacの皆様、LINEの皆様、いつもこんなに熱く楽しいイベントを開催していただきありがとうございます。
本戦の出場が正式に決定しましたら、その際はまたどうぞよろしくお願いいたします。

1 2 3 4 5 6 9

ホーム

検索
フィード
メタ情報

ページの上部に戻る