社内スピードアップコンテスト・お焚き上げ編

225 Views

July 28, 22

スライド概要

profile-image

hmatsu47(まつ)

@hmatsu47

スライド一覧

Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book

シェア

埋め込む »CMSなどでJSが使えない場合

各ページのテキスト
1.

社内スピードアップコンテスト お焚き上げ編 吉祥寺.pm30【オンライン】 2022/7/28 まつひさ(hmatsu47)

2.

自己紹介 松久裕保(@hmatsu47) ● https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています 最近は Aurora MySQL v1 → v3 移行してます ○ Zenn の本: https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book 2

3.

本日のネタ ● 前回発表で話した社内スピードアップコンテストですが ○ https://speakerdeck.com/hmatsu47/she-nei-desupidoatupukontesutokai-cui-nitiaozhan-sitahua ○ (前回話したとおり)消化不良な感じで終了したので ○ 出題内容のお焚き上げをする …という話です (一部省略あり) 3

4.

出題内容 ● こちらで公開 ○ https://github.com/hmatsu47/kuso-code-samples の kusocode3 ■ ○ https://github.com/hmatsu47/kusocode1-front-app ■ ○ 動作確認用フロントエンド(React) https://github.com/hmatsu47/kusocode-bench ■ ○ 出題(Java Servlet) ベンチマーク(Go) https://github.com/hmatsu47/kusocode-rank-app ■ ランキング表示(Vue) 4

5.

スピードアップ対象 ● Web API(Java 8) ○ ただの Servlet ○ ①画像一覧の表示 ■ 画像は 25 種類 ■ DL 数カウンタ付き ■ DL 数の降順で表示 ○ ②画像ダウンロード ○ ③カウンター初期化 5

6.

レギュレーション(競技は 1.5 時間) ● (AWS)EC2(t3a.small)上のアプリケーション修正可 ○ API で入出力するデータ形式の変更は不可 ○ ダウンロード画像フォーマットの変更も不可 ● EC2 上のミドルウェア設定変更・入れ替え可 ● DB のスキーマ・テーブル設計・初期データ変更可 ○ Aurora MySQL v1 t3.small ● EC2 インスタンスおよび DB インスタンス変更不可 6

7.

出題のポイント ● 主な問題点 ○ ヒープメモリ容量の設定ミス ○ テーブル構造の欠陥 ○ 非効率な DB データ取得 ■ N+1、無駄な行・列の取得 ● 何の対処もしないと ○ 100 点前後で Fail(注:途中 Fail してもそこまでのスコアは有効) 7

8.

順に修正:①ヒープメモリ容量の設定ミス ● 主な問題点 ○ ヒープメモリ容量の設定ミス ○ テーブル構造の欠陥 ○ 非効率な DB データ取得 ■ N+1、無駄な行・列の取得 8

9.

JVM のヒープメモリ ● t3a.small(2GiB)の場合デフォルト最大値 512MiB ● 設定ミスで初期値・最大値が 128MiB に ○ -Xms128m -Xmx128m ○ これを初期値・最大値とも 1.25 GiB 程度に ■ ついでに GC も変えると得点がわずかに UP(パラレル GC → G1GC) ● この程度まで上げると 1,000 〜数千点程度は行く? ○ ただしコードを直さないと GC 頻度が高く、後半で OOM も 9

10.

順に修正:②テーブル構造の欠陥 ● 主な問題点 ○ ヒープメモリ容量の設定ミス ○ テーブル構造の欠陥 ○ 非効率な DB データ取得 ■ N+1、無駄な行・列の取得 10

11.

count_log テーブル ● 中途半端な構造 ○ 1DL ごとに 1 行ある ○ access_count 列がある ■ カウント 0 の行が 1,000 行 ■ ↑ゴミデータ? ○ 行数でカウント? ○ 列値をカウントアップ? ■ ↑どっち狙い? 11

12.

修正方法(案) ● ①行数でカウントする ○ 無駄なデータを全て消す ○ access_count 列を消す ● ②列値をカウントアップする ○ 25 行だけ残して無駄なデータを消す ○ picture_id 列を消す(主キーである id 列を使う) ○ access_count 列をカウントアップに使う 12

13.

修正方法(案) ● ③列値をカウントアップする(別方式) ○ pictureテーブルに access_count 列を追加 ■ 一覧表示時 JOIN が不要に ○ あとは②同様に列値をカウントアップ ■ BLOB はオフページに行くとはいえ更新時負荷が気になる・このテーブルを 壊すと競技終了に追い込まれかねないのでボツ 13

14.

修正方法(案) ● ③列値をカウントアップする(別方式) ○ pictureテーブルに access_count 列を追加 ■ 一覧表示時 JOIN が不要に ○ あとは②同様に列値をカウントアップ ■ BLOB はオフページに行くとはいえ更新時負荷が気になる・このテーブルを 壊すと競技終了に追い込まれかねないのでボツ 14

15.

修正方法(案) ● ③列値をカウントアップする(別方式) ○ pictureテーブルに access_count 列を追加 ■ 一覧表示時 JOIN が不要に ○ あとは②同様に列値をカウントアップ ■ BLOB はオフページに行くとはいえ更新時負荷が気になる・このテーブルを 壊すと競技終了に追い込まれかねないのでボツ 15

16.

順に修正:③非効率な DB データ取得 ● 主な問題点 ○ ヒープメモリ容量の設定ミス ○ テーブル構造の欠陥 ○ 非効率な DB データ取得 ■ N+1、無駄な行・列の取得 16

17.

再度 picture テーブルを見てみる ● 画像が BLOB で入っている ○ ファイルに移して列を削除? ○ 容量は 1GiB ちょっと ■ キャッシュもギリギリ可? ○ 一覧表示で image 列は不要 17

18.
[beta]
一覧表示のコード(ListItem.java)を見てみる
CountLogDAO countDAO = new CountLogDAO();
PictureDAO pictureDAO = new PictureDAO();
StringBuffer sb = new StringBuffer();
(中略)
List<AccessCount> countList = countDAO.findTopCount();
sb.append("[");
for (AccessCount accessCount: countList) {
int pictureId = accessCount.getPictureId();
Picture picture = pictureDAO.find(pictureId);
String title = picture.getTitle();
String description = picture.getDescription();
int count = accessCount.getAccessCount();
(後略)

● 無駄な N+1(ループ処理)
○

countDAO.findTopCount() を直せば SQL 1 つで必要な全データが取れそう

18

19.
[beta]
呼び出し先(CountLogDAO.java)を見てみる
public List<AccessCount> findTopCount() {
(中略)
StringBuffer sb = new StringBuffer();
sb.append("SELECT picture_id, SUM(access_count) AS count_sum FROM count_log");
sb.append(" WHERE picture_id IN (");
sb.append("
SELECT id FROM picture");
sb.append(" ) ");
sb.append(" GROUP BY picture_id");
sb.append(" ORDER BY count_sum DESC, picture_id ASC");
(後略)

● 不思議かつ無駄なサブクエリとの組み合わせ方をしている
● picture テーブルと count_log テーブルを JOIN すれば一発
○

方法①なら picture に count_log を LEFT JOIN & GROUP BY & COUNT(*)

○

方法②なら picture と count_log を 1:1 で INNER JOIN
19

20.
[beta]
画像ダウンロード関連のコードを見てみる
・GetImage.java
countDAO.incrementCount(pictureId);
Picture picture = pictureDAO.find(pictureId);
String image = Base64.getEncoder().encodeToString(picture.getImage());
sb.append("{");
sb.append("\"pictureId\":" + String.valueOf(pictureId) + ",");
sb.append("\"image\":\"" + image + "\"");
sb.append("}");
(後略)
・PictureDAO.java(find)
ps = db.prepareStatement("SELECT * FROM picture WHERE id = ?");

● 方法②なら count_log テーブルは UPDATE する
○

UPDATE picture.count_log SET access_count = access_count + 1

● id・image 列以外の情報は不要
○

title・description 列を外す
20

21.

ここまでの修正で ● 方法①なら 8,500 点+α(G1GC 化で 9,000 点+α) ○ count_log テーブルに INSERT →ロックが軽い ■ 実質 AUTO_INCREMENT 値の生成時ロックのみ ○ 一覧表示の COUNT(*) スキャン行数が多い(どんどん増える) ● 方法②なら 9,500 点前後(G1GC 化で 10,000 点+α) ○ count_log テーブルに UPDATE →行ロック競合が発生 ○ 一覧表示のスキャン行数は少ない(25 行✖ 2 から増えない) 21

22.

他の修正 ● StringBuffer → StringBuilder ● 接続プーリングを DBCP2 から HikariCP に変える ● Java 11 or 17 に上げる ○ Java 11 で 1.5 倍くらい、17 で 1.6 倍くらいスコアが上がる ● picture テーブルを Caffeine でキャッシュする ○ 方法② & Java 17 との組み合わせで 17,500 点前後 ■ Java 8 のままだと Fail する(GC 性能の問題?) 22

23.

ベンチマーク ● 主な仕様 ○ 60 秒間に成功したリクエストについてスコアを加算 ■ 途中で Fail した場合はその時点までのスコアが結果となる ○ 最初に一覧データ取得の所要時間を計測してスレッド数を決定 ■ 2 〜 20 の範囲 ○ その後は各スレッドで一覧データ取得と一覧最下行にある画像の ダウンロードを繰り返す ■ それぞれ +10 点、+ 2 点 23

24.
[beta]
ベンチマーク(Goroutine によるスレッド処理)
// 計測時間の起点を取得
now := time.Now()
(中略)
// 設定スレッド数でリクエストを流す
var wg sync.WaitGroup
wg.Add(threads)
i := 0
for i < threads {
go func() {
// スレッド毎の初期値を設定
thscore := 0
thlastcount := -1
thmessage := ""
(中略)
for thmessage == "" && time.Since(now).Seconds() < 60 {
(ここにチェック本体を記述)
}
// 結果を返す(スコア加算・メッセージ返却)
mu.Lock()
defer mu.Unlock()
defer wg.Done()
result.Score += thscore
if thmessage != "" {
result.Message = thmessage
}
}()
i++
}
wg.Wait()

24

25.

ベンチマーク ● チェック内容(主なもの・タイムアウトは 10 秒) ○ 一覧データ:25 行あるか? 項目値は正しいか? (初回のみ)カウンタは全て 0 か? (それ以降)カウンタは降順か? 25 行の合計値が前回の応答時より大きいか? ○ 画像ダウンロード:ID・画像データは正しいか? 25

26.

ベンチマーク ● Go で作った理由 ○ 高速 ■ Java は JIT の問題がある ○ ビルド&デプロイが楽 ■ ワン(シングル)バイナリ 26

27.

実施のメリット(まとめ的なもの) ● 社内事情に合わせて出題できる ○ と言いつつ自社では消化不良のまま失敗しましたが ● 簡単な出題でも意外と盛り上がる ○ 時間に追われると意外と良い判断&対処ができなくて焦る ● 出題者が一番学習効果が高い ○ 曖昧な理解だとそもそも問題が作れない・スコア設定ができない 27

28.

出題を 夏の夜空へ お焚き上げ 28