スマートキャンプ エンジニアの瀧川です。
私は最近社内では開発をほぼせず、もっぱらエンジニア組織の課題に思いを馳せています。
そんな私ですがエンジニアとしての情熱がなくなったわけではありません。
個人でとても関心を持っているのが、みなさんもご存じであろうISUCONです。
今回はISUCONを題材として、Datadogの習熟・活用、パフォーマンス改善スキルの向上を狙った、SMARTCAMP 社内ISUCON(以下S-ISUCON)をご紹介します。
※「ISUCON」は、LINE株式会社の商標または登録商標です。
目的
弊社では9月にメインのアプリケーションの監視をMackerelからDatadogに移行しました。
移行理由としては、APM(Application Performance Management)やRUM(Real User Monitoring)、各種Log管理などを一元的に担えるところにDatadogの魅力を感じたことが挙げられます。
とても便利そうと感じる一方で、Mackerelと比較したときの長所の裏返しですが、Datadogの機能の多さ・複雑さが際立っており、移行に際してこれらの機能をどのように開発者に浸透させていくかという課題がありました。
また別の軸で、Webアプリケーションのパフォーマンスに関するスキルについて課題感がありました。
N+1に代表されるようなパフォーマンスに関わる実装はどのような機能開発でも基本的に意識すべきものだと思います。 しかし現状社内ではあまりフォーカスされず、属人化しているのではという懸念がありました。
これは既存プロダクトではすでにキャッシュ戦略が整備されていたり、RailsだとN+1の対応が容易だったりと、なんとなくで改善できてしまうことが多いといった理由もあるかもしれません。 しかしこれでは、いざ新規プロダクトを開発したり、別の言語で開発する際に生産性が低下する要因になりうると感じていました。
そこで今回はISUCONを題材として、「Datadog(Infrastructure, APM)の習熟」と「パフォーマンス改善スキルの平準化」に向けたイベントを社内で企画することにしました。
なぜISUCONなのかについては、ISUCON11予選に私が参加したことが関連しています。
過去問を解いたり実践に参加するなかで私が感じた重要なポイントは、「ソースコードを見ただけで改善してもスコアが上がらないこと」「曖昧な知識で改善してもスコアは上がらないこと」の2つでした。
しっかりとAPMやプロファイラを見てボトルネックを見つけないと、そもそもほぼリクエストがないエンドポイントかもしれません。
またなんとなくindexを貼っただけでは効かないことが多々あります。
そういった性質が今回の課題感とマッチしていると感じ、実施に踏み切りました。
事前準備
オリジナルで問題を作成したほうが公平に取り組んでもらえると思いましたが、今回はDatadogの習熟が急務だったこととパフォーマンス改善スキルの平準化が目的だったので、メンバー間での議論や教え合いが重要だと考えました。そこで今回はISUCON10予選(過去問)を使わせていただくこととしました。
※ 運営の皆さん、いつもおもしろい問題をありがとうございます。
加えて以下の条件で環境を準備しました。
- 各チーム1台のEC2インスタンス
- VPNからのアクセス設定(SSH: 22, HTTP: 80)
- ※ 本番は3台が多いが、アプリケーションの改善に集中してもらうため
- Datadog Agent(Infrastructure, APM)インストール
- Rubyの実装への切り替え
- ※ Rubyメインのプロダクトが多いため
- 各チームのサーバーのソースコードと対応したGitHubリポジトリ
- ※ Deploy Keyも登録
ISUCONの環境はAWSなどで簡単に作成できるように整備されているため、今回もスムーズに整えることができました。 https://github.com/matsuu/aws-isucon
また参加者に向けて簡単な説明会も実施しました。
ほぼISUCON未経験者だったので、ISUCONの概要や修正の勘所、ISUCON10予選(過去問)のレギュレーション・マニュアルの読み合わせ、修正・デプロイ・ベンチマークの流れなど少し厚めに説明をしました。
ISUCON10予選(過去問)について検索は一応控えてもらい、それ以外の勉強は許可としました。
当日の流れ
当日はリモートか出社かはチームで相談してもらうことにしました。 (出社していたチームはホワイトボードを駆使して仕様を紐解いていたようでした)
丸一日S-ISUCONに割かせてもらうよう調整して、競技は11:00~18:00の7時間とし、10:00~11:00の間でSSHやHTTPでの接続確認など準備、18:00~19:00を最終スコア発表と感想戦にしました。
競技中、ベンチマークは各チーム自由に自サーバー内で叩くこととして、ポータルサイトも用意してなかったので、ベストスコアを更新したらSlackでアピールするようにしてもらいました。
※ 本番のISUCONだと、各チームのスコアが随時反映されるポータルサイトがある。
サポート
ISUCON経験者がほぼおらず、また練習期間も設けなかったので当日いくつかサポートが必要になる場面がありました。
- ローカルでの環境構築方法は?
- 基本的には過去問リポジトリのREADMEを参照
- 構築に時間がかかりそうなチームは都度サーバーにデプロイして確認
- 本番環境でスキーマ変更を反映させるには?
- リポジトリ内の特定のファイルを編集してデプロイすればinitialize時に反映
- MySQLやnginxの設定ファイルへの変更を反映させるには?
- 特に整備できてないので/etc/nginx以下のファイルを直接編集しsystemdで再起動
結果と事後FB
ISUCON10予選(過去問)は実務で経験することが少ない座標計算のロジックがあったり、単純にDBのindexを貼るだけだと効かなかったりと難しかったと思いますが、各チーム試行錯誤しながらスコアを伸ばしておりホッとしました。
1位のチームは各種index、Redisによるキャッシュ、バルクインサートなどがしっかりと効果的に実装されていたため、スコアを伸ばすことができたようでした。
終了後に以下のアンケートを実施しました。
- S-ISUCONの満足度
- S-ISUCONでの活躍度
- S-ISUCONで学べたこと
- Datadogで見れなかった情報があるか
- 感想や要望
アンケートの結果をいくつか抜粋して紹介します。
- 普段使うところのない脳の筋肉を使ってよいエクササイズになった
- みんなで速度を上げていくのが初めてだったのですごい楽しかった
- N+1の解消に少し時間かかりすぎた
- Ruby周りは貢献できたが、MySQL周りは微妙だったかも
- Datadog APMの見方がわかった
- indexが効かないパターンについて知った
- DatadogのSQL表示でパラメータが見れなかった
- Datadogがかなり見やすかったのでこれから活用していきたい
みんな技術的に課題を感じながらも、楽しみながらパフォーマンス改善に取り組んでいたのが印象的でした。 (ISUCONのスコアが上がるというモチベーションがやはり鍵だと感じています)
「Datadog(Infrastructure, APM)の習熟」と「パフォーマンス改善スキルの平準化」にしっかりと寄与するイベントになり、実施して非常によかったと感じています。
また感想戦でお互いの取り組みを話す中で、普段業務内で見えなかった各メンバーの強みに触れることができて、メンバー間の相互理解にもつながるよいイベントになりました。
満足度もとても高かったので、今後も継続して(次回はオリジナルの設問を...)開催していこうと思います。
来年のISUCONに参加するメンバーがでるとなおよしですね!
おわりに
今回「Datadog(Infrastructure, APM)の習熟」と「パフォーマンス改善スキルの平準化」を目的としたSMARTCAMP 社内ISUCON with Datadogを紹介しました。
こういったエンジニアのスキルアップにつながるイベントを時間をもらって実施できるのはよい環境ですし、必ずプロダクトの成長にも効いてくるので今後も継続して企画・運営していければと思います。
同じような課題感を持っている方や、弊社の雰囲気を知りたい方の参考になっていれば幸いです!