AWSを活用して社内ISUCONを開催したはなし

JAWS-UG朝会 #34 での登壇資料です。
Date: 2022.06.07
https://jawsug-asa.connpass.com/event/240121/

NRIの社内ISUCONのリソースはこちら
https://github.com/nri-isucon/nri-isucon2022

Transcript

1. 株 式 会 社 野 村 総 合 研 究 所 ⼭ ⼝ 渡 AWSを活⽤して社内ISUCONを開催したはなし 2022年06⽉07⽇ JAWS-UG 朝会
2. はじめに 本⽇は以下についてお話します • ISUCONの紹介、社内ISUCONを開催した理由 • AWSを使って社内ISUCONを開催するノウハウ • 社内ISUCONの運営の裏側 社内ISUCONを開催する際の⼀助になると幸いです！ 2 「ISUCON」は、LINE株式会社の商標または登録商標です
3. 3 ⼭⼝ 渡 株式会社野村総合研究所にて、⾦融業界向けに、スマートフォン アプリやWebアプリケーションなどフロント領域の開発案件に従事。 AWSは2017年頃から興味を持ち、ソリューションアーキテクト （アソシエイト）を取得したのが始まり。 2021年9⽉に開催されたAWS GameDay Online ~ APN杯 vol.2 ~では、 Lords and Ladies of Questivus Award（最多クエストクリア）を受賞。 趣味はテニス、謎解き（脱出ゲーム）。 Yamaguchi Wataru
4. 4 ISUCON / 社内ISUCONとは
5. ISUCONとは • 与えられた8時間のあいだにWebサービスを限界まで⾼速化する、 チーム対抗の性能改善コンテスト • いい感じに(I)スピード(S)アップ(U)コンテスト(CON)の略 • 2011年にライブドア社（現LINE社）主催ではじめて開催され、 今年で12回⽬を迎える 5 https://isucon.net/
6. 今年も7⽉に開催されます！ 開催期間 • オンライン予選: 2022年7⽉23⽇(⼟) 10:00-18:00 • オンライン本選: 2022年8⽉27⽇(⼟) 10:00-18:00 募集期間 • 第⼀期参加者募集 6⽉ 1⽇(⽔) 10:00 上限220枠 • 第⼆期参加者募集 6⽉ 6⽇(⽉) 20:00 上限215枠 • 第三期参加者募集 6⽉11⽇(⼟) 10:00 上限215枠 6 IUUQTUXJUUFSDPNJTVDPO@PGGJDJBM 超⼈気イベント・・・
7. ⾼速なアプリケーションとは？ レスポンスが速い 7 App 1500ms App 150ms App App スループットが⾼い 多くの⼈が快適に利⽤できるアプリケーション ⾼速であることは、Webサービスの必須要件に
8. Webアプリケーションを⾼速化するには？ • ボトルネックを特定（計測）して、改善する • 幅広い領域の知識が必要 8 ブラウザ Javascript Web サーバ Application サーバ Database Linux バックエンドの改善 フロントエンドの改善 パラメータチュー ニング • ワーカー数 • キャッシュ ロジック改善 • N+1問題 • 最適なアルゴ リズム • 同期/⾮同期 SQL最適化 インメモリ カーネルチューニ ング • ロジック改善 • キャッシュ
9. チームの動き⽅ ベンチマーカーの挙動 性能スコアをチーム間で競う • 運営が準備したベンチマークを使って、 各チームのWebアプリケーションのスコアを算出 • 各チームは、「計測→改善→ベンチマーク」のサイクルを回す 9 Web Application Benchmarker I/Fなどの動作チェック ⼀定期間内により多くのシナリオをクリアすると、⾼いスコアが付く ベンチ マーク 計測 改善 あらゆるシナリオを⼀定期間、 多重にリクエスト
10. 多くの企業で社内ISUCONが開かれている 他にも、Wantedly社やPR TIMES社などでも開催されている 10 NTTコミュニケーションズ社 https://developer.ntt.com/ja/blog/31e9fb86-7309-4145-a72b-0ea5f17e3f5a リクルート社 https://blog.recruit.co.jp/rtc/2021/04/26/isucon-2021-winter/
11. NRIでも社内ISUCONを企画 • ⼈材育成、⼈材発掘、社員同⼠の交流の場の提供を⽬的に、 2021年2⽉に初めて開催。2022年2⽉に２回⽬の開催に⾄った。 11 第2回（2022年02⽉） 参加者：28チーム70名 開催⽅法：リモート 第1回（2021年02⽉） 参加者：26チーム70名 開催⽅法：リモート
12. 幅広い職種の⼈が参加 • 技術系のイベントはインフラ系の社員の参加が想定されたが、 幅広い職種の⼈に参加いただけた • 協⼒会社や顧客の⽅も参加し、 コロナ禍の関係構築の場にもなった 12 インフラ系 46% アプリ系 33% セキュリティ系 10% 関係会社 11% 第2回の参加者 内訳（70名）
13. 普段の業務では関わらない領域にチャレンジ • コンテスト終了直後の”⼀⾔感想”への回答 13 Ø 楽しかったです！次回の開催お待ちしてます！ Ø 環境⾯の整備を含めて、様々な視野でシステムを⾒ることができて貴 重な経験となった。 Ø ⾮常に疲れました。ありがとうございました。 Ø 途中ではハマったら抜け出せなかった・・・ Ø ⽂系学部卒で、配属先でもホストしか触ったことないようなよわよわ で参加させて頂いたので、ssh接続からとても苦労しておりました、、 環境接続できてからは、性能確認の⽅法やそのデータを⽣かした対策 を⽴てるという流れの経験ができて楽しかったです！ありがとうござ いました！ Ø 疲れた・・・途中までルンルンでやっていたが、お昼過ぎに504エラー が出始め、環境を戻すのに精いっぱいだった。もう少しお勉強してか ら再挑戦します・。。 Ø GO最強 Ø 初期設定の説明や問題の難易度はすごく良かったですが、ベンチが遅 い Ø 普段の仕事ではなかなかコーディングをする機会がないため、とても 楽しく良い機会でした。⾃分の実装⼒のなさには絶望しましたが、今 回の経験を糧に本家isuconなども頑張って⾏きたいと思います。 Ø Goを勉強しようと思いました！！！ Ø 何かしらチューニングできた...！ Ø 慣れていないのもあり、⼤変難しかったです。 Ø 最後謎のエラーに遭遇し最⼤のパワーが出せず残念でしたが、いろい ろと性能改善の勉強になったので良かったです！ Ø 難しかったです。。 Ø 初めての挑戦で四苦⼋苦しましたが、最後の⽅はこんな感じかな？と いう⾵に⾃分達で考えながらできたので楽しかったです！ Ø 消化不良気味です。。 Ø むちゃくちゃ勉強になった。最後の最後にボトルネックに気づいたの に直しきれなかったのが悔しい…。本家も出てみようかしら…。 Ø 勉強＆⼒不⾜のため当⽇は他メンバーの作業を⾒守ることしかできな かったので悔しかったです！ただ、普段インフラや性能周りの業務を していないので、ISUCON参加にあたっての勉強はためになりました！ Ø つかれた Ø 悔しい、クラスタの構築が失敗 Ø 練習したことがある程度発揮でき、楽しむことができました。 ありがとうございました。 Ø おもしろかったー Ø 楽しかったです！！ Ø つかれました Ø 楽しかったです！SQLクソ雑⿂でした。。 Ø 普段こんなに会話しながらワイワイやっていないのでとても楽しかっ たです。 Ø 最後3時間くらいずっとエラー解消できなくてとても⾟かった Ø ⾃分の無⼒さを痛感しました！ Ø 題材がたいへん⾯⽩く、⼀から作った⼈達は凄いと感じた Ø 準備が⾜りないことがあり、残念。。。 Ø 疲れたー！ Ø チューニングしても全くスコアが伸びず、全然ボトルネックをとらえ られていなかったことを痛感しました。 Ø 楽しめました Ø 疲れた＆消化不良。flaskでスレッド増やしたときになんだかグローバ ル変数が怪しい動きをする気がするので、そこに躓いてチューニング がはかどらなかった・・・ Ø おなかが減った。 Ø ⼤変でしたが、楽しかったです！ Ø 普段AWSのマネージドサービスを中⼼に使っており、IaaSを触る機会 があまりなかったので、改めてログ調査や性能ボトルネックの特定な どといったLinux操作が重要だと感じた。 良かれと思って改修した結果、性能劣化するといった事象が多発した ので、アプリやインフラ修正の勘所をもっと磨いていきたいと感じた。 Ø 普段業務では使わないプロダクトや⾔語に触れられて学びになった。 Ø ボトルネックがわからなかった・・・ Ø 前回に引き続きの参加でした。また０点でしたが楽しかったです！！ Ø 楽しかったです。途中で発⽣したエラーの原因を最後まで突き⽌めら れなかった点が悔しいです。 Ø なかなかスコアが上がらなかった。。⻭ごたえがありました。 Ø ⼀⽇チームで改善に向けて取り組めたことが、良かったです。Python のソースコードの改良が時間内に完了しなかったことが⼼残りです。 Ø パフォーマンスチューニング何も知らなかったのですがNginx頑張りま した、、！ Ø 楽しかった Ø とにかく⼤変でしたがいい経験になりました！mysql恐怖症にかかりま したが…(⼀気の変更ダメ絶対) Ø 思っていたよりも難しかったです。 Ø 運営のみなさんお疲れさまでした！楽しかったです。 Ø 楽しかったです。終了直前にfailになってしまったのが⼤変悲しいので すが、次回頑張ろうと思いました！ Ø ⾊々と考えて⼿を動かせたので楽しかったです。 Ø 不完全燃焼です Ø 悔しい部分もありましたが，楽しい時間を過ごすことができました！ 疲れた疲れた Ø 前回も参加させていただきましたが、今回の⽅が難しくなっていて、 苦労しながらも楽しく取り組ませていただきました。 Ø 楽しかったです！機会があればまた参加したいです。 Ø 最初はサーバにsshするところからつまづいてしまい、よちよち歩きな 参加でしたが、「ISUCONとは何ぞや」が分かって良かったし楽しかっ たです。ありがとうございました。
14. 14 社内ISUCONの運営について
15. 社内ISUCONの運営 • 開催前に、運営でハッカソンを⾏うイメージ 15 改善対象 Webアプリ ケーション 題材検討 コンテスト基盤構築 ポータルサイト構築 Webアプリケーション開発 ベンチマーカー開発 運営内で 模擬ISUCON ★ 社内ISUCON 開催 １ヶ⽉間 ２ヶ⽉間
16. 16 コンテスト基盤について
17. 改善対象のWebアプリケーション リアリティのあるテーマを運営メンバーでアイデアを出し選定 もちろん、アプリケーションは性能のボトルネックを抱えたものをあえて開発 テーマ • ワーケーションやAfterコロナのGoto需要を狙った、⺠泊をサポートするサービス • 直近はワーケーション需要の緩やかな増加を想定していたが、急なGoto事業の再開で予想以上に利⽤が加速 • 急遽、性能改善が必要となった 17
18. インフラ構成 • コンテスト環境は⼤きく3つで構成 18 参加者⽤ インスタンス ベンチマーカー ポータルサイト
19. 競技者⽤インスタンスの概要 • 競技者が性能改善を⾏うアプリケーションが稼働する環境 • 1チームあたり、踏み台＋性能改善対象サーバの4台を提供（28チームなので、112台!） • 初期状態では単⼀サーバでアプリケーションが稼働する • 3台のリソースをうまく使って、アプリケーションを⾼速化する作戦もあり • 1台はDBサーバ専⽤にする、など 19 nginx Go Python Java MySQL Webサーバ APサーバ DBサーバ Ubuntu
20. 競技者⽤インスタンスのAWS構成 • OSレイヤー以上の改善を可能とする ため、EC2を利⽤ • 112台のインスタンスをチームごとに 異なる設定（SSH鍵など）で構成する 必要がある • Terraform + ansibleで構成管理 20
21. （参考）Terraform Cloud Plan&Applyをクラウドで実⾏し、状態を管理してくれる。開発体験が最⾼。 • GitHubでPRを作成すると、Planを実⾏ • PRをマージすると、Applyを実⾏ 21
22. ポータルサイトの概要 • 運営から競技者に、競技中に必要な情報や機能を提供するポータルサイト • ランキング・スコアの確認 • インスタンス情報の確認 • ベンチマークの実⾏ 22 ランキング サーバ⼀覧 ベンチマーク
23. ポータルサイトのAWSの構成 • SPA＋サーバレス構成 • フロントエンド：React + Cloud Front + S3 • バックエンド：API-GW + Lambda + DynamoDB ① インスタンス情報などチームごと に異なる情報の表⽰ • Terraformによるリソース構築時に、Parameter Storeに格納する • それをバックエンドから取得することで実現 ② ベンチマークの実⾏ • 参加者のリクエストはDynamoDBに記録 • DynamoDB Streamをトリガーに、ベンチマーク （AWS Batch）のジョブを作成 23 ② ①
24. ベンチマーカー • Webアプリケーションの性能を評価しスコアを算出する • (NRI-ISUCON2022の場合）スコア = 宿・アクティビティの予約成功数 * 3 - 減点 • Golangで実装、コンテナ化し、AWS Batch for AWS Fargateで稼働 24 Runner benchmark worker worker worker worker ･･･ DynamoDB DynamoDB ステータス（実⾏中）更新 ステータス（完了）更新 worker
25. ベンチマーカー • 実⾏環境はAWS Batch for AWS Fargateで構築 • 第⼀回社内ISUCONの開催準備中に ベンチマーカーの構成を検討して いる最中に、AWS Fargate対応の アップデートが来たので、 これだ！と思い採⽤ • ポータルサイトからのベンチ マーク実⾏をトリガーに、Lambda でAWS Batchのジョブを作成 25
26. （参考）AWS Batch • Fargateで稼働するおかげで、ジョブ作成からの⽴ち上がりが⾼速 26 ・ジョブごとにCloudWatchログを確認できる ・ジョブの実績がダッシュボードで確認できる ジョブを作成してから 開始まで30秒程度
27. 27 当⽇の運営について
28. 当⽇の運営の様⼦ 28 • 運営メンバーはオンサイトで運営を実施 • 参加者からの問い合わせ対応やAWSのリソース状況を監視 ※感染症対策に⼗分留意して運営を実施しました
29. 何事もなく、無事・・・終わらなかった • 16時頃、参加者から、ベンチマークの不具合と思われる事象の報告があった 29
30. よし、これで解決・・・しなかった • ファイルディスクリプタが⾜らなくなったか？と、とりあえず上限を上げる ことを検討 • Terraformで管理しているからすぐに変更できたと思いきや・・ 30
31. よし、これで解決・・・しなかった • ファイルディスクリプタが⾜らなくなったか？と、とりあえず上限を上げる ことを検討 • Terraformで管理しているからすぐに変更できたと思いきや・・ 31 Fargateは設定を変えられないことが判明・・
32. コンテスト終了後に調査を実施 コンテスト終了後、ファイルオープンの数を計測するラッパーをコンテナの エントリーポイントにして、AWS Batch on Fargateで実⾏ • Fargateのファイルディスクリプタ上限は1024 • 120秒ぐらい実⾏すると、ファイルオープン数が 1005に達していた • ベンチマーカーのアプリケーションを調査した ところ、⼀部の異常系でHTTPコネクションの解放 処理に不備があることが判明した 32 運営チームのISUCONは敗北に終わりましたとさ。 参加者の皆様にはご迷惑をおかけしました!‍‍ 上限1024 実⾏時間(sec) ファイルオープン数
33. なぜ気づけなかったか？ • ベンチマーカーのテストはローカルのDocker環境で実施していた • ローカルのDocker環境のファイルディスクリプタは異なり（1048576）、 枯渇することがなかった • （⾃分がアプリ寄りのエンジニアだからかもしれないが） コンテナはどこで動かしても同じ挙動をするのがメリットの⼀つだと思って いたので、意外な学びだった 33
34. 34 さいごに
35. なぜ運営をしようと思ったか？ 何にも縛られず⾃分の好きなものを作って、⼈々に使ってもらえる環境を作りたかった （＝実践の場） 35 アプリケーション • 様々な⾔語 • Go • Python • Java • Typescript • API設計 • Swagger • コンテナ • 性能改善の知識 インフラ • アーキテクチャ設計 • AWSサービス • EC2/Fargate • ECS • AWS Batch • ネットワーク設計 アプリ共通 • CI/CD整備 その他 • イベント運営 • 社内⼿続き
36. まとめ • ISUCONに興味を持っていただいた⽅ • 本家ISUCONに参加してみましょう！ • ぜひ、皆様の会社でも社内ISUCONを開催してみましょう！ • 運営活動を通じて、アプリケーション〜インフラのフルスタックな経験を積めます！ • 運営⾯で不明な点があれば、気軽に聞いてください！ 改善対象のWebアプリケーションを考えるのが⼤変！と⾔う⽅は、 社内ISUCONのリソースを公開しているところもあるので、 活⽤すると良いです。弊社も公開しています！ https://github.com/nri-isucon/nri-isucon2022 36