LoginSignup
0
0
@yuta-katayama-23(yuta katayama)

k6で秒間○回リクエストする　行ロックを取るような設計のボトルネック度をk6の負荷テストで検証してみた

Last updated at Posted at 2023-10-06

はじめに

思考実験として、投稿とそれに対するコメントやいいねができるシステムを考える（DBスキーマは以下のようなテーブル構成とする）。
image.png

このシステムでは、投稿テーブルでコメントの合計数を持つような設計になっているとする。そのような設計になっているがゆえに、コメントを行うAPIがあった場合には、以下のような実装になる必要がある。実装におけるポイントは、コメントを行うごとに投稿テーブルのcomment_countをインクリメントする必要があるので、投稿テーブルの行ロックを取る必要がある部分になる（ロックを取らずに投稿テーブルを更新すると、数値がおかしくなる）。

このような実装をしたとき、どれくらいのAPIコールがされると行ロックを取っていることがネックになり、サービスに影響が出る（ロック待ちでAPIの応答が遅くなる）が出るのか気になった。そこで今回は、どれくらいの負荷がかかるとこのような設計が破綻するのか？負荷テストを通じて検証してみようと思う。

負荷をかけるために利用するのはk6というツール。

// Node.js Expressの実装（SequlizeというORMを使って実装しているイメージ）
router.post('/:postId/comment', verifyAccess(), async (req, res) => {
	const { sequelize, models, CustomError } = req.app.locals;
	const { postId } = req.params;

	const transaction = await sequelize.transaction();
	try {
		const post = await models.post.findOne(
			{ where: { id: postId, enabled: 1 } },
			{ lock: true, transaction }
		);
		if (!post) throw new CustomError(404, 'data not Found');

		const { id } = await models.comment.create(
			{ ...req.body, postId, userId: req.tokens.userId },
			{ transaction }
		);

		const commentCount = await models.comment.count({ where: { postId }, transaction });
		post.commentCount = commentCount;
		await post.save({ transaction });

		const comment = await models.comment.findByPk(id, { transaction });

		await transaction.commit();

		res.status(200).json(comment.toJSON());
	} catch (error) {
		await transaction.rollback();
		res.status(500).error(error);
	}
});

何はともあれまずはk6を動かしてみる

インストール方法などはGet started > Installationを参照。私の環境はAlmaLinuxだったので、CentOSのインストール方法でインストールした。

$ sudo dnf install https://dl.k6.io/rpm/repo.rpm
$ sudo dnf install k6
$ k6 --help

          /\      |‾‾| /‾‾/   /‾‾/   
     /\  /  \     |  |/  /   /  /    
    /  \/    \    |     (   /   ‾‾\  
   /          \   |  |\  \ |  (‾)  | 
  / __________ \  |__| \__\ \_____/ .io

Usage:
  k6 [command]

Available Commands:
  ...

続いて公式のRun local testsに書かれているスクリプトを実行して負荷テストを実行できるか？を確認してみる。
image.png

画像のように、ひとまずk6で負荷テストを行うことはできた。結果として出力されているメトリクスの説明はBuilt-in metricsに詳細が書かれている。

k6の特徴について

k6ではJavaScriptでコードを書ける。そのためJavaScript（厳密には別物だがNode.js）で開発をしている開発者にとっては負荷テストを行う敷居が低くなる。それについては、公式の方でも触れられおり、開発チームでの負荷テストの敷居を下げられると書かれている。

Grafana k6 is an open-source load testing tool that makes performance testing easy and productive for engineering teams. k6 is free, developer-centric, and extensible.
（Grafana k6はオープンソースの負荷テストツールで、エンジニアリングチームのパフォーマンステストを簡単かつ生産的にします。）

実際に負荷をかけてみる

まずリクエストを行うためのスクリプトだが、以下のようなスクリプトになる。負荷をかけるAPIは、ログインを行うことで取得できるトークンをAuthorizationヘッダーのBearerに指定してAPIを呼び出せるようなAPIとしている。

import http from 'k6/http';
import { sleep, check } from 'k6';

export function setup() {
	const signinUrl = 'http://localhost:3000/api/v1/internal/signin';
	const signinPayload = JSON.stringify({ email: 'sample@example.com', password: 'password' });
	const signinParams = { headers: { 'Content-Type': 'application/json' } };

	const signinRes = http.post(signinUrl, signinPayload, signinParams);
	const { token } = signinRes.json();

	const postUrl = 'http://localhost:3000/api/v1/post';
	const postPayload = JSON.stringify({ title: '負荷テスト' });
	const postParams = {
		headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${token}` }
	};
	const postRes = http.post(postUrl, postPayload, postParams);
	const { id } = postRes.json();
	return { token, postId: id };
}

export default function (data) {
	const url = `http://localhost:3000/api/v1/post/${data.postId}/comment`;
	const payload = JSON.stringify({ content: 'コメント' });
	const params = {
		headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${data.token}` }
	};
	const res = http.post(url, payload, params);
	check(res, {
		'is status 200': (r) => r.status === 200
	});
}

少し上記のコードについて補足をする。

  • export function setup() {...}
    負荷テストを実行する前に実行される関数で、テストに必要な事前準備の処理を実装する。returnにより、後続のdefaultの関数の引数で受け取ることのできるデータを返すこともできる。詳細はTest lifecycleを参照。

  • export default function() {...}
    メインとなる処理を書く関数で、この関数に実装されている内容が負荷テストの内容になる。

上記のスクリプトでAPIに負荷をかけていくが、今回は1s以内の応答になる、つまりhttp_req_durationが1s以下に収まる最大の秒間リクエスト数を見ていきたいと思う。

秒間に一定のリクエスト（負荷）をかけるには、constant-arrival-rateというExecutorを利用するのが手っ取り早い。

というわけで、上記のコードに少し設定のためのコードを追加する。以下は秒間10リクエストを送るような設定。rateの部分を変えていくことで秒間のリクエストを増やせる。

export const options = {
	scenarios: {
		constant_request_rate: {
			executor: 'constant-arrival-rate',
			rate: 10,
			timeUnit: '1s', // 毎秒10回の反復、すなわち10RPS
			duration: '30s',
			preAllocatedVUs: 100, // VUの初期プールの大きさ
			maxVUs: 300 // プレアロケートされたVUが足りない場合、さらに初期化できる上限数
		}
	}
};

以下で、実際に秒間に○○回リクエストをした結果をまとめてみた。

検証していたマシンスペックは以下（Windows上のVirtualboxで立てたAlmaLinux）。
image.png

また、ローカル環境で立てているDBはMySQLで、Dockerを利用してMySQLサーバーを起動していた。

rate: 10 の時

image.png

つまりどうなの？というのはChatGPTやBardに聞けば教えてくれるが、要は以下のようなことがわかる。

  • HTTPリクエストの平均応答時間: 25.81ms　←秒間10リクエストでは応答までに1s以内はOK
  • HTTPリクエスト: 303回
  • 1イテレーションあたりの平均時間: 26.59ms
  • 1秒あたりのイテレーション数: 9.968001/s　←ほぼ秒間10リクエストということ

rate: 30 の時

image.png

  • HTTPリクエストの平均応答時間: 29.56ms
  • HTTPリクエスト: 903回
  • 1イテレーションあたりの平均時間: 29.86ms
  • 1秒あたりのイテレーション数: 29.831412/s

rate: 50 の時

image.png

  • HTTPリクエストの平均応答時間: 68.5ms
  • HTTPリクエスト: 1503回
  • 1イテレーションあたりの平均時間: 68.75ms
  • 1秒あたりのイテレーション数: 49.700691/s

rate: 60 の時

image.png

  • HTTPリクエストの平均応答時間: 1.15秒
  • HTTPリクエスト: 1779回
  • 1イテレーションあたりの平均時間: 1.15秒
  • 1秒あたりのイテレーション数: 55.660957/s　←秒間55リクエストしかできていない・・・

秒間60リクエストで1sを超えてしまった・・・。そしてBard曰く、

この結果から、次のことが言えます。

HTTPリクエストの平均応答時間が1.54秒であることは、一般的に許容できる範囲を超えています。システムの応答速度を向上させる必要があります。

とのことなので、今回の結果はNGのレベル…という結論になる。

まとめとして

今回はk6を利用して行ロックによる非効率性を調べてみるということをやってみた。

ローカル環境での検証であり、マシンスペックなど全くもって本番環境のそれと違うので、今回の検証は本来的に意味はないが、それでも行ロックの設計がまずそうか？の判断をする上では参考になった気がする（まあk6を使ってみたかったというのも、モチベーションとしてあったのでやった意味はあったかなと思う）。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0