はじめに
こんにちは。マネージドサービス部の福田です。
先日ISUCON14に初参加してきましたのでせっかくなのでブログにしてみました。
突然ですが、みなさんは「サーバの調子が悪いからEC2のインスタンスタイプを上げればいい」という考えに頼りきっていたりしませんか？
もちろんインスタンスタイプを上げるのは悪いことではありません。
ただ、アプリケーションやミドルウェアの挙動をしっかりと把握した上でインスタンスタイプを上げることが重要になります。
つまり、クエリの最適化やキャッシュの活用、アプリケーションコードそのものの見直しなど、根本的な部分に目を向けたパフォーマンス改善が重要になるということです
ISUCONではそのようなパフォーマンス改善をしていくので普段の業務でアプリ、チューニングをあまり触れない人でも色々と（本当に色々と）考えさせてくれる素晴らしい競技です。
ISUCON参加した理由
今回私はISUCON初参加になります。
参加した理由はパフォーマンスチューニングの考え方を知りたいという思いともう一つ理由がありました。
それは普段からオブザーバビリティツールである「New Relic」に携わる機会が多くボトルネックの特定まではよく行うのですがその先のチューニング作業等はする機会がほとんどないです。
さらにアプリほぼ触らないというこんな私でもNew Relicを活用することでどの程度ISUCONに対して通用するかを試したかったからです。
当日やりたかったこと
パフォーマンスチューニングやアプリケーション開発には慣れていないため、欲張らず以下の目標を設定しました
- アプリ言語をPythonに変更
- New RelicAPMの導入
- 特定したボトルネックを解消
- N+1
- インデックス貼る等
初ISUCON盛大に散る
盛大に散りました。
理由はいくつかあるのですが、大きな理由は
New RelicAPMで思った通りの情報を収集できなかったことです
私の想定していた内容はNew RelicAPMが大前提なので一気に崩れました。崩壊でした。
というもののトランザクション情報はある程度収集できたが、DBクエリ情報が収集できなかったのです。
ただ、後日冷静に今回のアプリケーションはFastAPIだったなーと思いました。
もしかしてNew Relicエージェントの初期化タイミングが遅れたため、非同期処理がうまく追跡できなかった可能性があるのかなーと思い調べると
それらしい公式ドキュメントを見つけました＆原因特定はまだはっきりしていないので後日個人的に実施予定です。
そのほかにも当日を振り返るとなぜ気づかなかったという箇所が多々ありましたので知らずに緊張＆焦っていたというのもあるんでしょうね
当日にNew Relicで確認できた画面
トランザクションは収集できましたがDBクエリは拾えなかったです。
Summaryページ
Pythonの情報は取得できていますがMySQLの情報は取得できておりません。
Transactionページ
Transactionの情報は取得できていました。
Databaseページ
Databaseの情報は取得できていませんでした・・・
翌日色々見直してNew RelicAPM入れた場合
翌日にCloudFomationで作成したリソースに再度New RelicAPMを導入方法を見直したところ
DBクエリも含め詳細に情報を取得することが出来ました。
（ベンチは回さず（回し方不明だったので）適当にIsurideのアプリを手動で操作しました）
Summaryページ
Pythonの情報もMySQLの情報も取得できました。
Transactionページ
Transactionの情報もDBクエリの詳細情報も取得できました。
Databaseページ
Databaseの情報取得できていました。
New Relicを使えなくなった私の末路
だいぶつらみ状態になりました。
とりあえずNew Relic等で処理が重いトランザクション把握できたのでインデックス付与やSQLクエリ改修を試行錯誤していました。 が、こういう状態ってうまくいかないのが世の理でエラーの連発・・・まさに沼にはまった感じでした。
とはいえ、この過程でアプリケーション仕様への理解が深まり、「なぜそのインデックスが必要なのか」「どのようにSQLクエリを改修すべきか」など、チューニング方法への方向性が見えてきました。 やはりロジックを理解することが重要ですね（それはそう
総評
圧倒的なスキル不足
New Relic等を導入してどこが問題点あるかはすぐに把握は出来ました。
ただ、それを改善するスキルが不足し、時間が溶けていきました。
くやしい・・・
当日のアプリの仕様やマニュアルをちゃんと読めていなかった
振り返ると当たり前のことなのですが当日のマニュアルやレギュレーションやアプリの仕様が記載されているドキュメントをしっかりと
読んで把握すべきだったのですが全然できていませんでした。
アプリの経験がないのになぜかソースコードから仕様を理解しようとしていました。仕様含め、改善ポイントもドキュメントにしっかりと記載されてたのに・・・
基本的なことですがドキュメント（仕様等）を把握することの重要性を改めて痛感しました
コミュニケーション大切
今回3名のチームで参加したのですが途中から各自で作業をする時間があり結果として時間ロスにつながりました。
おそらくそれぞれががっつりチューニングできるメンバばかりだったらいいと思うのですが
普段の業務でそこまでがっつりパフォーマンスチューニングしないメンバーだったのでそれぞれが沼にはまり・・・という状態でした
残り1時間ほどで会話するようになってからはスコアも徐々に上がってきてはいたものの時すでに遅し
くやしい・・・
色々反省点はあるものの楽しかった
今まではNew Relic導入しアプリもインフラもボトルネックが把握するまでがメインだったのでシステム全体を把握しながらパフォーマンスチューニングする作業は知らなかった世界に行った感覚で非常に楽しかったです
そのおかげで今自分に足りない知識や学習する方向性が決まったのは大きな成果でした。
今まで見てこなかったNew RelicCodeStreamとかもしっかりと知りたい知識の一つですね
最後に
ISUCON14は失敗も多かったものの、大きな学びと楽しさを得られる機会でした。
そしてとても悔しかった・・
New Relicもフル活用できるよう自分自身のスキルも向上させ来年は上位を目指していきたいです！！
