OpenResty FAQ | テスト用ネットワーク構造、SSL関連機能、DSL、`ab`ツール

API7.ai

December 1, 2022

OpenResty (NGINX + Lua)

OpenRestyの記事シリーズはこれまでに更新され、テストに関する部分の学習を終えました。遅れずに積極的に学習し、実践を重ね、熱心に感想を残してくれたことに感謝します。

コメントで提起された多くの質問は価値があり、特に典型的で興味深いものは今日のQ&Aとして特別に抽出しました。

今日はこの5つの質問を見ていきましょう。

質問1: テストのためのネットワーク構造をどのように構築するか？

Q: wrkを実行するクライアントは、外部ネットワークのマシンに配置すべきか、それともサーバーと同じLAN上のマシンに配置すべきか？この2つのうち、どちらがパフォーマンステストにとってより意味があるか？

A: Web関連サービスのテストにおいて、適切なテストツールを選ぶことは良いスタートですが、テストのためのネットワーク構造をどのように構築するかもその後の重要な部分です。

一般的に、ネットワークの干渉をすべて排除して、サービス単体の性能限界をテストしたいと考えます。この目的のために、ストレステストを行うためのネットワーク構築方法として2つの方法があります。

1つ目の方法は、wrkとサーバーアプリケーションを同じ高性能なマシンにデプロイすることです。例えば、NGINXで8つのワーカーを起動し、残りのCPUリソースをwrkに割り当てることで、ローカルネットワーク通信のみとなり、ネットワークの影響を最小限に抑えることができます。

2つ目の方法は、専用のルーターでLANを構築し、wrkが配置されているマシンとサーバーが配置されているマシンを接続することです。

既存のネットワークで直接テストすることはお勧めしません。なぜなら、ほとんどのネットワークにはスイッチやファイアウォールがあり、大量のトラフィックをストレステストする際に制限がかかり、テスト結果が不正確になる可能性があるからです。

また、パフォーマンステストツールについてもう少し触れておきます。まず、パフォーマンステストツールにはCoordinated Omissionの問題がある可能性があり、ツールのレイテンシデータを分析する際には特に注意が必要です。

Coordinated Omissionとは、パフォーマンステストを行う際に、送信から応答受信までの時間だけを計測するのは不十分で、これはサービス時間に過ぎず、統計には多くの潜在的な問題が漏れてしまうことを意味します。したがって、テストリクエストの待ち時間も含める必要があり、全体としてユーザーが気にする応答時間となります。もちろん、サーバー側のプログラムがブロッキングする可能性がある場合には、この問題を考慮する必要があります。そうでなければ無視しても構いません。

質問2: test::nginxでSSL関連の機能をテストできるか？

Q: test::nginxではSSL関連の機能をテストできないのか？

A: そうではありません。test::nginxはSSL関連の機能をテストできます。ssl.tを参照してください。このテストケースファイルはSSL証明書の全プロセスをテストしています。まず、テストケースがLuaコードを使用してローカルの証明書の公開鍵と秘密鍵を読み取っていることがわかります。次に、HTTP APIを通じて証明書を設定し、最後にcosocketを使用してSSLハンドシェイクとアクセスを行い、証明書が有効かどうかを検証します。

実際、SSLだけでなく、OpenRestyに含まれる機能もtest::nginxを使用してオーバーライドできます。

特定の機能がtest::nginxで実装できるかどうかわからない場合は、まずlua-nginx-moduleや他のOpenRestyオープンソースプロジェクトのテストケースを検索してみてください。通常、対応する例が見つかります。結局のところ、test::nginxは非常に遊び心があり、変幻自在で、予期しない組み合わせやトリックが発見されるのを待っています。

質問3: DSLとは何か？

Q: DSLとtest::nginxとは何か？

A: DSLはDomain Specific Languageの略です。DSLの目的は一般的な開発言語とは異なり、一般的なドメインのニーズを解決するのではなく、特定のドメインのニーズを解決することです。最も有名なDSLはSQLで、データベースドメインで使用される構造化照会言語です。

test::nginxに関しては、NGINXとOpenRestyのテストニーズに対応するために作成されたDSLです。実際、OpenRestyの作者は多くのDSLのアイデアを発明し、OpenRestyコミュニティに多くの新しい試みと解決策をもたらしました。しかし、前回の記事で述べたように、DSLは両刃の剣であり、DSLの価値を測る主な基準は、エンドユーザーに生産性の向上をもたらすかどうかです。

質問4: test::nginxのインストール問題

Q: git cloneを実行した後、以下のコマンドを実行してtest::nginxをインストールする必要があるか？

cd test-nginx
perl Makefile.PL
make
sudo make install

A: 実際にはそうではありません。ここではいくつかのオープンソースプロジェクトを参照できます。

ステップ1: パッケージマネージャー経由でインストール

sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)

ステップ2: 最新のtest::nginxをgit clone

git clone https://github.com/openresty/test-nginx.git test-nginx

ステップ3: proveコマンドを使用する際にtest-nginxディレクトリを含める

prove -Itest-nginx/lib -r t

前述したように、OpenRestyとその周辺プロジェクトのインストールに関する最良のガイドは、ドキュメントではなくCIにあります。これは他のプロジェクトとは異なるかもしれませんが、主にOpenRestyが周辺プロジェクトのフォークや特定のバージョンを独自に維持していることと、OpenRestyがCIに強く依存しているためです。したがって、OpenRestyを使用してテストする際には、CIでビルドされているのと同じ方法で行い、公式のものと一貫性を保つようにしてください。

質問5: abテストツールは良いか悪いか？

Q: Yichun ZhangがGoogle Groupsで頻繁にabを最高のテストツールとして言及していたのをどう覚えているか？

A: 記事で述べたように、abはツールの機能だけで見ると良いパフォーマンステストツールではありません。なぜなら、十分なリクエスト圧力を生成できないからです。しかし、サーバー側のプログラムの性能は現在非常に強力です。test::nginxでwrkではなくabを使用するのは、TEST_NGINX_BENCHMARKモードでは、test::nginxがHTTPプロトコルのバージョンに応じてabまたはweighttpをパフォーマンステストのツールとして使用するためです。

また、インターネット技術は非常に速く変化しており、私たちはそれぞれ知識とスキルをタイムリーに更新する必要があることに注意してください。例えば、私の意見では、このtest::nginxの選択は現在更新が必要であり、Yichun Zhangは当時wrkの存在を知らなかったかもしれません。もちろん、wrkよりも良いパフォーマンステストツールが時間とともに登場する可能性があり、私たちは自然に積極的でオープンな心を持って学び、選択するべきです。

今日は主に上記の質問に答えました。コミュニケーションとQ&Aを通じて、学んだことを得るものに変えるお手伝いができれば幸いです。この記事を転送して、一緒にコミュニケーションと進歩を図ることも歓迎します。