2022年9月28日に『業務に役立つISUCON』というイベントを開催しました。イベントでお話した内容をご紹介します。
登壇者紹介
hogelog
CTO室 バックエンドエンジニア。
ISUCON歴：初参加
ahogappa
STORES ブランドアプリ バックエンドエンジニア。22卒入社。
ISUCON歴：初参加。ずっと参加したかったので、参加できてうれしかった！
waniji
STORES 予約 SRE。
ISUCON歴：ISUCON4から参加していて、ISUCON12で8回目の参加。
ISUCON12 と heyの関わり
ISUCON12 にゴールドスポンサーとして協賛しました。
イベントレポート
予選に向けての準備は？
hogelog：wanjiさんは8回目の参加ということですが、毎回どういう準備をしているのか、今回どういう準備をしたかを教えてもらえますか？
wanji：基本的なところだと、Scrapboxにチートシートを作る、GitHubのプライベートリポジトリを作っておくというのは毎回やっています。
今回は、『達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践』がちょうど発売されたので、みんなで非同期で読んで、感想を言い合う会をやりました。ISUCONに対して気持ちを高めていくのもそうだし、いろんな手法が載っていたので、チートシートに書き写したり、これ使えそうだね、みたいな会話をしましたね。いいタイミングで発売されて、助かりました。
hogelog：僕らのチームでもこちらの本は買って読みましたね。
wanji：過去参加した人たちがブログで書いていた手法も載っていたので、これを読めばよくある設定は網羅できるんじゃないかなと思います。
hogelog：僕とahogappaさんは初参加だったのですが、定番ツールがそれぞれのチームでありますよね。コマンドの実行結果をチャットに流すとか、そういうのってやっぱりするじゃないですか。
wanji：しますね。
hogelog：そういう部分は整っていて、戸惑うことはなかったですか？
wanji：ISUCONが終わった直後は気持ちが高まっているので、これはやった方がいい次回はこうしようっていう話が出るんですけど、1年経つとその気持ちがリセットされてしまったり。ただ、回数を重ねてるので、通知できるようにしたり、ログの分析結果をまとめよう、みたいな部分は整ってきました。
hogelog：何が必要かは参加する中でわかってくるんですね。僕たちも事前に用意してたんですが、予選当日になって、ちょっとバグがあることがわかって、それで時間が取られたり。初参加だなと感じました。
wanji：素振りされてる方もたくさんいらっしゃいますけど、そういうところでトライアンドエラーを重ねないと、本番一発だと怖いですね。
hogelog：素振りも1回くらいしたんですけど、足りなかったですね。
ahogappa：ツールをGitHubにあげるのを忘れてて、素振り環境から引っ張ってくるのを本番でやったときはさすがに初心者ムーブすぎると思いましたね。素振り環境のVMを立ち上げ直したりして、時間かかってしまいました。
hogelog：そういうまごつきで時間を使ってしまいました。ISUCONってチームワークとか、そういうツールを整えていくところがまず一番最初になるよなって、やっていてわかりました。wanijiさんのチームはどの言語のアプリケーションでいったんですか？
wanji：Goが得意なメンバーだったので、Goでいきました。
hogelog：僕らはRubyでいきました。初期状態だとGoになっていましたよね。正しく動いてるか確認するためにベンチマークを回して、そこからRubyに切り替えました。wanijiさんはアプリケーション内部にはあまり触れてないんですか？
wanji：メインの実装メンバーよりは触ってないけど、読みましたね。SQLのチューニングをしないといけない時とか、データの構造を把握しないといけない時とか。
hogelog：RubyとかGoの話を先にしちゃいましたが、環境が提供されて予選開始ですってなるとSSHで入るところから始まるじゃないですか。入ってどう掘っていきましたか？
ahogappa：とりあえず何が動いているのかtopとかpsとかで確認した記憶がありますね。
hogelog：環境の中でどんなプロセスが動いてるか。
ahogappa：あれ、Redis動いてるぞ、みたいな。あとは、Go実装だったので、Rubyに切り替えるためにsystemdとかをわちゃわちゃしないといけないので、その辺りを見ていたと思います。いきなりアプリケーションのコードを見ることはしなかった気がします。
hogelog：そうですね、いきなり動いてるシステムのコードを探れって言うのは仕事じゃなかなかないですよねって言いたいですが、イベントのテーマである業務に絡めると、意外とある気もしています。ahogappaさんはさすがにないですかね。動いてるシステムがあります、これをどうにかしなきゃいけない場面ってありましたか？
ahogappa：ないですね。なんのドキュメントもなしにはないですね。逆に今回初めてだったので、こうやって掘っていくのかぁを素振りの練習環境で学びました。
hogelog：wanijiさんはそういう経験あったんじゃないですか？
wanji：ありましたね。知らないところを触っていく、なんとかして原因を探ることはありますね。把握能力というか、どこから探ればいいのかの感覚を養うのは業務につながる部分がありますね。
特にSREだと障害が発生した時、どうしてもその原因を見つけなきゃいけない時に自分が触ったことがないところも見にいく必要があったりするので。そういうところは業務に繋がると思いますね。
hogelog：ISUCONの最近恒例のオープニング動画、むちゃくちゃ言ってるんですけど、そんなに非現実的でもないですよね。あそこまではなくとも、サービスがいきなり止まることがあるじゃないですか。ここで止まったとわかる時もあるけど、何もわからないこともある。アクセスしたらエラー画面が返ってくるんだけど、どういうこと？って。それにある意味近い。
サービスが落ちていて何とかしなきゃいけない、でもどこだかわからないがやるぞっていう時って、本当にISUCONみたい。業務だと本当に困ってる人達がいるのでISUCONよりももっとヒヤヒヤしてるけど、素早くパフォーマンス・チューニングしなきゃいけない。たまにそういう状況が発生して、そのたまにあるものを素早く解決するのがめちゃくちゃ大事。
しょっちゅう障害が起きてたらいやですし、そういうことが起きないように普段から整備しておくのは大事なんですけども、そういうことが起きた時にそれに素早く対応できる能力はほしい。でも、しょっちゅう起きないから緊急対応の筋力はなかなか鍛えられることがないんですよね。が、ISUCONですよね。
wanji：なるほど、ここで。
hogelog：それは強く感じましたね。ISUCONをやっていて思ったのは、障害が起きた時に掘っていくドタバタと、ISUCONやっている時のボトルネックはどこだ？みたいなものは通じる部分がありました。実際動いているシステムもすべてを把握しているわけじゃないので、探っていく感じは似てましたね。
wanji：似てますね。
SQLiteに不意をつかれた
wanji：今回はISUPORTSという、ISUCONとe-sportsをかけたお題でしたね。
hogelog：初めて見た時、どう思いましたか？何に一番ビックリしましたか？
ahogappa：全部…？1枚のファイルにペタって書いてあるのにびっくりしました。課題なので、1枚に書くっていうのはあると思いますが、この量を1枚で書くのかという驚きがありました。
hogelog：1000行弱のコードでね。ahogappaさんの普段の業務でSinatra使うこともないでしょうしね。ざーっと眺めて、どんなアプリケーションなのかなと思いつつ、オヤっと気になるところがありましたよね。SQLiteとか。
wanji：これはびっくりしましたね。
ahogappa：自分もびっくりしました。
wanji：今までのISUCONはMySQLが多くて、参加ブログなどでチューニング手法が紹介されて参考にしたりするんですけど、SQLiteが出てきて不意をつかれました。
ahogappa：ISUCON本が直前に出ていたので、本で書いたことは出ないかなと予想していました。が、まさかSQLiteが出てくるとは思わなかったですね。
hogelog：びっくりして楽しかったですね。SQLiteのところはほぼ何もできなかったですね。佐々木さんチームはどうにかできました？
wanji：MySQLに全部移行しましたね。
hogelog/ahogappa：おー！
wanji：結構迷ったんですよね。これが罠なのか、MySQL移行前提なのか。移行スクリプトもちょっとあったりして判断が難しかったんですけど、今まで培った知識を活かすには移行した方がいいかなと思って移行しきりましたね。
hogelog：罠ってチラッと考えますけど、ISUCON作問はそういうことはしてこないよなと。SQLiteでDBごとにファイルが分かれるから、MySQLに移行してもクエリはそのまま使えると書かれていたので、触りかけたんですが、ちまちまと書き換えるだけで終わるわけじゃないと途中で気付いてやめたんですよね。
インスタンスが3台用意されていて、それを使い切ることを考えると、SQLiteがあると1台にしないといけないので、複数台を使いこなすにはMySQL移行した方がいいんだけども、うう、てなって。最終的にうちのチームMySQLは別インスタンスにして、App1台、MySQL1台で、1台は遊んでいました。
wanji：なるほど。
hogelog：3台使い切ることができずに終わってしまった。うちのチームはうまくいったところなんかあったかな？
ahogappa：うまくいったところだと、すごいボトルネックになっていた箇所は、hogelogさんが直してくれました。
hogelog：visit_historyかな。めちゃくちゃ大きいんですけど、実はMIN createdのここのデータしかいらない。ここのクエリを改善したら、ボトルネックがMySQLからApp側にうつった。ボトルネックがこっちからこっちに変わるのが体験できて、「あ！ISUCONで見たやつだ！」てなりました。
wanji：たしかに。
hogelog：次はこっちをやっつけないとスコアがあがらないのかぁ、ていう、ISUCONらしい体験ができたのはよかったですね。うまくいかなかったことは、その他全部。基礎練習が足りなかった。wanijiさんたちは、ここをもうちょっとうまくやっておけばっていうのありますか？
wanji：デプロイして、ベンチを回す前にログをローテートして、ベンチ実行後にログを分析する、というサイクルはうまく回せました。チートシートの設定を反映するのも滞りなくできた。
うまくいかなかったのは、準備してなかった瞬発的なところですね。player_scoreという膨大な量のデータがSQLiteにあったんですが、これは一部のデータしか使ってなくて結構削減できるんですよ。さっき出ていたvisit_historyは気づけたんですけど、このplayer_scoreのところは気づけなかった。indexを貼ったけど、データ量が多くて遅い。これをうまく改善できていれば壁一つ超えられたんじゃないかなと。ここは悔いが残ってますね。
hogelog：予選が終わったあとにDiscordで参加者のみなさんがわいわいしているじゃないですか。そこの話を聞いてて思ったのが、アプリケーション理解の解像度が高いんですよね。アプリケーションがどういうものなのか、Webサービスとしての挙動とコードが紐付いていました。
僕は正直そこは結びつかずにコードだけを見てた。眺めて、ボトルネックあるな、なんか倒そうという感じでやってしまった。全体としてアプリケーションコードがどう動いているか、本選にあがった人たちの理解は深いなと思いました。
それってISUCONの定番で、アプリケーションをまず理解しろって言われているじゃないですか。業務でもそうですよね。そもそもどういうサービスなのか特性を理解してると、アプリケーションの解像度も一気に早くなる。
コードをさーっと眺めて、アプリケーション全体の流れを想像できるならいいんですけど、そうじゃない人としては、ユーザーのリクエストがどうくるのか、どういうアクションをするためのアプリケーションなのかを理解するのが大事だということは感じました。
wanji：本当ですね。コードだけ見てても全然わからなくて、過去に失敗をしてきました。今は必ずマニュアルを読むのと、実際のアプリケーションを手で触るのを必須にしています。アプリケーションがどう動くのかを頭で想像できないとなかなか改善がうまくいかないんですよね。
あとは先ほどhogelogさんも言われてたんですけど、ユーザーのアクセスの仕方や傾向ですね。実は1、2回して呼ばれてない場合もあるので、ちゃんとそのアプリケーションの特性とアクセスしてくるユーザーの特性をログや実際の振る舞いを把握してから改善しないといけないので、そこは業務に繋がる部分かなと思いますね。
hogelog：そういう話は聞いていたし、頭には入ってるつもりだったけど、正直初めての参加ではしゃいじゃった部分がありましたね。
wanji：触りたくなりますよね。
ahogappa：最後の数時間の追い上げとかは、アプリケーションの理解度が影響あったなと思います。
hogelog：サービスが理解できていると改善がスムーズっていうのは、業務でプログラミングをしてると非常によくありますね。
個別のトピックでいうと、IDの採番がありましたね。
wanji：一番最初にMySQLのボトルネックになっている箇所でしたね。
ahogappa：これは倒せました。雑にSecureRandom.uuidで直しました。これだけでもだいぶ変わりましたね。
hogelog：予選後のみんなのわいわいを見ていると、SecureRandomやulidで解決していたり。そこもすごくよかったです。本選でも採番の話がありましたね。業務で採番を工夫しないといけないことって今までありましたか？
wanji：表に出すIDと裏で持ってるIDを変えたりとか、そういうのはありましたね。
hogelog：業務でいうと、できるだけIDの採番で工夫したテクノロジーが必要にならないアーキテクチャにしたい、避けられるなら避けていきたいですね。でも、たまにあるんですよね。採番を工夫しないといけないシステムじゃない？て。採番を工夫しなきゃいけないシステムってパフォーマンスが非常に問題になるぞってわかってるシステムなんですね。
wanji：ですね。
hogelog：そんな仕事がいきなりきてもなかなか難しい。ISUCONみたいなパフォーマンスが重要な場面だと、こういう課題になるんだなと。
ahogappa：業務で莫大なデータがあって、これは水平分割した方がいいんじゃないみたいな話が出たときに「ISUCONで見たやつだ！」てなりましたね。
ISUCON で地力がつく
hogelog：本選の画面を開いたので、本選の話もチラッと。ahogappaさん、wanjiさんはゲーム開発はしたことありますか？
ahogappa/wanji：ないですね。
hogelog：僕は前々職でゲーム開発をしたことがあるんですけど、ゲームってほぼWRITEなんですよね。ログインボトルネックもあるあるでした。いわゆる普通のウェブサービスだと、まずサービスが当たらないことにはパフォーマンスの問題のなにもないことが多いですが、ゲームだとリリース当初からパフォーマンスがいきなり問題になることがあって。
水平分割をできるだけ避けたいと話しましたけど、ゲーム開発ではあるある。最近の業務ではあまり触れてない構成なので、筋力が鍛えられそうだなって。
wanji：本番運用でそういう経験をされている人は強いなって思いますね。
hogelog：ISUCONの強い人対談みたいな記事があがってて、fujiwara さんが答えていたんですよね。練習しますか？いやしないです、と。仕事での筋力が強いのかなって。正直、私たちのサービスだと常にそんなにめちゃくちゃヘビーではないが、時々めちゃくちゃアクセスがあるみたいな。
wanji：逆にISUCONで手札を揃えて業務に活かすことはできそうです。こういうところで練習できるのはありがたいですね。
hogelog：実際に予選に参加したり、参加するために準備してきたことで業務に役立ったと感じることはありましたか？
wanji：先ほどデプロイ・ベンチ・その後の分析を回した話をしたんですけど、CI/CDを早く回して、どんどんサイクルを回す、Four Keys の重要性が身にしみて分かりますね。それによって検証もしやすい、障害が起きた時に戻しやすいみたいなところは重要なんだなと。
ahogappa：自分は今回初めての構成や技術が色々あったので、単純に知らない事をたくさん知れました。DBだったらインデックス周りとか、あとはflockみたいな、必要かどうかはわからないんですけど、そういうマニアックな知識があったりして。実際にFORCE INDEXのところは、業務に活かせて改善できた部分があったので、ISUCONって業務の役に立つな、参加してよかったなって思えました。
hogelog：どうやって動いているかわからない仕組みってあるので、それを読み解いていくときに役立つかもしれない、地力がつくというのはありますね。
waniji：例えば転職して初めて入った現場で学んでいくっていう時がISUCONに近そうな状況だと思うんですけど、そんなに頻繁にないと思うんですよね。それを毎年経験できるっていうのはいい地力の上げ方かなと思いますね。
ahogappa：題材も毎年変わるので。今回だとゲームとか。
hogelog：運営の人、本当にすごい。
ahogappa：知識を覚えているだけじゃなくて、活かす。対応力は、ずっと同じサーバとコードではつけられない部分かなって思いますね。
hogelog：普段Railsで仕事をしていて、時によってはコントローラにアクションを追加して、Railsのレールの上で仕事をしている時間が続くことがある。
ISUCONだと、Rubyのサーバサイドアプリケーションをいじっていくために、Pumaの上でSinatraが動いてて、Pumaのコネクション周りはどれくらいチューニングした方がいいんだっけ？みたいなところとかを理解しないといけなかったりする。普段の業務だとそんなに意識し続ける必要性はないんだけど、理解していた方が良い。ISUCONはそんな地力を鍛える筋トレとしても非常にいいなと感じましたね。
次回のISUCONに向けて
hogelog：ISUCON13には参加しますか？
ahogappa：参加したいですね。やっぱり予選を突破してる方はすごく細かいところ、自分たちが気づかなかった、やれなかったチューニングをできているので、それをこの1年間でできるようにならないといけない。予選突破は結構遠いなという感じはします。
hogelog：wanijiさんはどうですか？
wanji：今回参加した課題が出て、毎回反省点をみんなで書いてメモとして残してるんですけど、それを活かして次回も挑戦したいですね。今回の反省として、手の動かし方やコミュニケーション方法を効率的にしたほうがいいんじゃないか、分担をもっとやった方がいいんじゃないかというのがあるので、それを試していこうかと思います。あとは、前日ちゃんと寝る。
hogelog：大事ですね。今年は初参加で、やっぱりISUCONっていいなと感じたので、初参加のハードルは超えられたので、がんばっていきたい気持ちはありますね。
ahogappa：来年も一緒に出ましょう。
hogelog：予選突破を謳うのはうーんって感じですけど、がんばりましょう。ISUCONに参加したことがない人にオススメしたいポイントはありますか？
ahogappa：まずはすごく楽しいですね。ゲーム感覚みたいなところもあります。コードを書く楽しさもある。ソースコードも全部公開されるので、終わった後にじっくり考えることができるのもいいかなと思います。
あとは純粋に知識が増える。サーバ構成、インフラとか OS みたいな、やることがいっぱいあって、広くて深い知識が必要なので、今持っている知識との差分を確認できる機会になります。あと、自分が興味のある分野がISUCONで発見できる部分もあって、自分の場合はインフラに弱かったので、抑えていこうという学びもありました。
hogelog：wanijiさんはどうですか？
wanji：普段業務をやってて、タスクをこなす感じもいいんですけど、ISUCONだと改善するとスコアがでてn倍になったりとかするので、フィードバックが分かりやすい。ゲーム感覚って言われてましたけど、本当にそんな感じでできて楽しいっていうのが大きいですね。
あと、本気で取り組んで事前準備もするので、本番は集中して作業ができるし、終わった後も、他の参加者が自分はこうしました、こういう手法がいいですよというブログを見てより深く学べる。本気で取り組んだからこそ、しっかり読み込めるし、そういうところで地力をつけたり、手札を増やしたり、知識をつけられるのがいいのかなと。
チームで参加して、スコアあがったらわーってみんなで叫んでわいわいするのも良いですし。1人でも、2人でも、3人でも楽しいので、参加してみるといいんじゃないかと思います。
hogelog：今までは見る専で、周りの人が参加しているのを見ていました。知人に優勝経験者がいたのもあって、参加しても予選敗退になりそうだしみたいな気持ちで尻込みがあったんですけど。
今回、参加してすごく思ったのは、まずは見る専の人にとっても、参加っていうのは一番近くでISUCONを見られる場所でもある。参加したことで、これは周りの人にもおすすめできるものだし、学生がすごい取り組んでるのいいなーって感じたり。もっと広がっていくとすごい良いなと思いました。
確か昨日出ていたISUCON12の出題者インタビューで fujiwara さんも言及してたんですけど、もうちょっとライトなISUCON的な催しができるといいなって言っていて。ISUCON12の予選問題のISUPORTSとかまさにそれをお題にしてますよね。ライトなISUCONや社内ISUCON的なものとか、それがあちこちで行われるとすごくいいですよね。弊社でもやっていけるといいな。
ISUCON運営者のみなさん、出題者のみなさん、ありがとうございました！来年の開催も期待しています。
【宣伝】さまざまなイベント開催中！イベント情報はTwitterでチェック
STORES では、さまざまなエンジニア向けイベントを開催しています！イベント情報はTwitter @storesinc_tech で投稿していますので、ぜひTwitterをフォローしてください。
