iwamotのブログ : ITエンジニアリング

2021年08月22日22:52

カテゴリ: ISUCON

ISUCON11予選、予想以上に厳しい結果だった

ISUCON11の予選にチーム「iwamot solo」で参加したものの、参考順位299位という厳しい結果に終わりました。一昨年のISUCON9が参考順位98位、昨年のISUCON10が参考順位66位だったので、今回は惨敗だと感じています。

一番の敗因は、Sinatraに不慣れなためにソースコードの改善にもたついてしまったことでした。現在の勤務先では主にRubyが使われているので競技でもRubyを選んだのですが、Sinatraアプリをメンテナンスする機会はまずないんですよね。

そんなわけで、競技時間中に実施できたことは下記くらいでした。

サーバ構成の変更（Web＋Appサーバ、Appサーバ、DBサーバ）
インデックスの追加
NginxとMySQLのちょっとしたチューニング
calculate_condition_levelメソッドの高速化
リクエストを落としている部分のコメントアウト

他にも試したいことがたくさんあったのですが、前述の不慣れな部分をあれこれ調べているうちに終了時間を迎えてしまった感じです。

今回の惨敗で思ったのは、勉強や練習に時間をかけなければ予選通過は無理そうだなということでした。ISUCON以外にも時間をかけて取り組みたいことがあるので、まあぼちぼちですかね。

2020年09月12日22:42

カテゴリ: ISUCON

ISUCON10に参加した

ISUCON10の予選にチーム「iwamot solo」として参加しました。チーム名の通りソロ参加で、最終スコアは1,635でした。順位はまだ分かりませんが、昨年初参加したISUCON9では参考スコアベースで98位だったので、それより上だといいなと思っています。

（2020-09-14追記：参考スコアベースで66位でした。自分としては善戦だったと思います）

言語はRubyを選びました。本当は昨年同様PHPにするつもりだったのですが、エラーでうまく動かせませんでした。時間があれば、くわしく調査したかったところです。

使えるサーバは3台でした。1台目はNginxとUnicorn、2台目はMySQL、3台目はUnicornと振り分けました。昨年はアプリケーションコードの改善だけでほぼ終わってしまったので、少しは進歩できたかなと思っています。

その他、実施したタスクは下記の通りです。

NewRelicの導入
各種インデックスの作成
camelize_keys_for_estateの排除
ループ外で実行可能な処理のループ外への移動
冗長なwhere句の整理
SELECT FOR UPDATEの排除
ログ出力の停止（Nginx、Sinatra）
Sinatraのリロード停止
「stock > 0」の「stock != 0」への変更
MySQL、Nginx、Unicornのパラメータ調整

（2020-09-14追記：GitHubリポジトリをpublicにしました。ソロ参戦なので適当な感じですし、アプリケーションコードしか含まれていませんが、どなたかの参考になれば幸いです）

こうまとめてみると、まだまだやれることはあったと思います。が、競技時間内ではこれで一杯一杯でした。

限られた時間内でのチューニングという経験はなかなかできないので、来年以降もスケジュールが合えば参加するつもりです。運営のみなさま、ありがとうございます。

2020年05月02日15:39

カテゴリ: ITエンジニアリング

フロントエンドはサーバサイドと同じ轍を踏むか

下記の記事で考えていた「移植性の高いWebアプリのアーキテクチャパターン」や「Fat Controllerをコードで防ぐ方法」は、サーバサイドを主に扱ってきた経験に基づくものだ。

ただ、あらためて考えてみれば、サーバサイドでHTMLを組み立てるアーキテクチャパターンそのものが、Webアプリの移植性を低めている元凶なのだろう。気を抜けばビューロジックがコントローラに漏れ出すし、多くの場合テンプレートエンジン依存のビューテンプレートファイルが大量に作られるし、いざ移植したくなったときには、相当な労力が必要になりがちだ。

となれば、サーバサイドをAPIに特化させるのが一案だろう。APIに特化させれば、少なくともサーバサイドにおいては、ビューテンプレートファイルを作らなくてよくなる。

なんだか、汚いものをフロントエンドに押し付けているようで気が引けなくもないが、ちょうどよいことに、昨今ではサーバサイドをAPIに特化させるのが当たり前になってきている。これは、ブラウザ・Android・iOSなど、さまざまなプラットフォームでアプリを提供するのに適しているからだ。

そうなると、今度はフロントエンド側の移植性が気になってくる。たとえば、Nuxt.jsからNext.jsに乗り換えたい、みたいなニーズがあるのかどうか、あるとしたら労力はどのくらいなのか、といったことだ。

そのあたりの感覚はフロントエンドの経験を積まなければわからない。サーバサイドが生んできたいわゆる技術的負債をフロントエンドも生んでいくことになるのか、もうすでに生みまくっているのか、はたまた、優秀なエンジニアたちが日々返済してくれているのか。ぼくが気にすることではないのかもしれないが、でも気になる。

少し探したら下記の記事が見つかった。「強く依存しているライブラリやツールを減らす」といった表現が出てくる。やはりサーバサイドと同じ轍を踏んでいるようだ。とはいえ、あきらめずに返済を進めているのがすばらしい。

大規模フロントエンドの技術的負債と向き合うためにやったこと - ログミーTech

iwamotのブログ

ITエンジニアリング

ISUCON11予選、予想以上に厳しい結果だった

「ISUCON」カテゴリの最新記事

ISUCON10に参加した

「ISUCON」カテゴリの最新記事

フロントエンドはサーバサイドと同じ轍を踏むか

「ITエンジニアリング」カテゴリの最新記事