k6入門：大規模なテスト実行におけるOSの設定ついて -その1-

今日は、k6を利用した大規模なテスト実行におけるOSの設定についてご紹介します。

背景

Dockerで構築したWebアプリの開発環境において、k6を利用した負荷テストについて調査したときの内容を備忘として残しました。

開発環境のソースは下記のリポジトリにあります。

大規模なテストスクリプトをローカルで実行する際、ユーザーは時にはOS内の制限に遭遇し、テストを完了するために必要なリクエスト数を実行できないことがあります。この制限は通常、Too Many Open Filesエラーとして現れます。これらの制限は、変更されない場合、大規模または複雑なテストをローカルマシンで実行する場合に深刻なボトルネックとなる可能性があります。

この記事では、システムが課すOSの制限を検査し、調整し、より大規模なテストにスケーリングする方法を説明します。

ここで重要なことは、この記事でカバーするすべての内容は慎重にアプローチする必要があるということです。OSに対する変更と同様に、特定の値にシステム設定を盲目的に変更することはお勧めしません。変更前と変更後の関係が明確にわかるテスト方法を文書化する必要があります。たとえば、MSL / TIME_WAIT期間を変更する前に、問題が発生していることを確認し（エラーメッセージ、netstat、ssなど）、設定を慎重に変更し、テストを再実行し、どのような改善があるかを記録します。この方法で最適化の効果を評価し、負の副作用を見つけ、推奨値の範囲を見つけることができます。

注意 以下の変更はmacOS Sierra 10.12以降でテストされています。古いバージョンを使用している場合、これらの設定を変更するプロセスが異なる可能性があります。

ネットワークリソースの制限

GNU/Linux、BSD、macOSなどのUnix系オペレーティングシステムは、システムの安定性を保護するために、プロセスが利用できるシステムリソースの量を制限することがあります。これには、単一のプロセスが管理できる合計メモリ量、CPU時間、またはオープンファイルの量が含まれます。

Unixではすべてがファイルであるため、ネットワーク接続を含むすべてのものがファイルとして扱われます。k6のようなネットワークを大量に使用するアプリケーションテストツールは、特定のテストで使用されるネットワーク接続の量に依存して、設定されたオープンファイルの制限に達する可能性があります。

最初のセクションで述べたように、これはテスト中に次のようなメッセージが表示される結果として現れます：

WARN[0127] Request Failed     error="Get http://example.com/: dial tcp example.com: socket: too many open files"

このメッセージは、ネットワークリソースの制限が達成され、k6が新しい接続を作成できなくなることを意味し、したがってテスト結果が変更される可能性があることを示しています。一部の場合、これは全体のシステムパフォーマンスを測定するために望ましいかもしれませんが、ほとんどの場合、これはHTTPサーバーとWebアプリケーション自体をテストする際のボトルネックとなります。

次のセクションでは、このリソース制限を増やし、k6を使用して単一のシステムから数百または数千の同時VUでテストを実行できるようにする方法について説明します。

制限の設定を表示する

Unixシステムには2種類のリソース制限があります。

• ハードリミット：各ユーザーに許可される絶対的な最大値で、ルートユーザーだけが設定できます。
• ソフトリミット：各ユーザーが設定できますが、ハードリミットの設定を上回ることはできません。

Linux

GNU/Linuxでは、ulimitコマンドを使用して設定された制限を表示できます。

ulimit -Saは現在のユーザーのすべてのソフトリミットを表示します：

ulimit -Sa
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3736
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3736
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

ulimit -Haは、現在のユーザーのすべてのハード・リミットを表示します：

ulimit -Ha
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3736
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1048576
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3736
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

ソフトリミットではオープンファイルの最大数が1024であるのに対し、ハードリミットでは1048576であるという違いに注意しましょう。

macOS

macOSでは、考慮する必要があるいくつかの異なるシステムに課せられた制限があります。

最初の制限は、launchctl limit maxfilesで、ソフトリミットとハードリミットとして指定されたプロセスごとの制限を表示します。ソフトリミットを超えると、プロセスはシグナルを受信するかもしれません（たとえば、CPU時間やファイルサイズが超えられる場合）、ただし、ハードリミットに達するか（またはリソース制限を変更するか）まで実行を続けることが許可されます。kern.maxfilesはシステム全体のファイルディスクリプタの制限で、すべてのプロセスによるすべてのオープンファイルの合計と、カーネルが自身の目的でオープンしているすべてのファイルの合計です。

sysctl kern.maxfiles

sysctl kern.maxfilesperproc

したがって、上記のコマンドを実行すると、ファイルと実行プロセスのシステム制限が表示されます。

おわりに

今日は、k6を利用した大規模なテスト実行におけるOSの設定についてご紹介しました。