受付の負荷リハーサル：チェックインを検証する方法

負荷をかけた状態での登録受付を検収するための実践的プラン：ピークシナリオ、安全なデータ、バックアップ、PASS/FAIL基準、ベンダー報告書。

負荷リハーサルで証明すべきこと

受付の負荷リハーサルは、実際の来場者数の中でゲストの全行程が機能することを示さなければなりません。記録が見つかり、QRコードが読み取られ、ステータスが一度だけ変わり、バッジが印刷され、その結果が隣のワークステーションでも確認できることです。ここでのチェックインとは、記録の検索とゲストの到着の記録です。個別のフォームの成功応答やスキャナーの音声信号だけでは、プロセス全体の準備ができていることを証明できません。

Aventuraではまず検証の範囲を定めます。ゲストは招待状を提示するか、記録の検索を依頼します。システムはステータスを確認し、到着を記録し、データを印刷に渡します。

オペレーターは分かりやすい確認を受け取ります。依存関係マップには外部サービスも含まれます。

受付の全体的な流れはイベント参加者の受付の記事で詳しく解説しています。ここでの課題はより限定的です。この流れを負荷の下で検証し、事前に記録した基準に基づいて「合格」か「不合格」の判定を得ることです。

スキャナーはバーコードのデコードに成功すると音を鳴らすことがあります。これはデバイスがシンボルを読み取ったことを示しますが、中央システムに新しいステータスが記録されたことを示すものではありません。そのため観察者はスキャナーの反応だけでなく、オペレーターの画面、ゲストカード、印刷、最終出力を照合します。

発注者視点でのピークフロー

ピークは仮想ユーザーの切りのよい数ではなく、ゲストの到着シナリオによって設定します。発注者は来場の時間帯、主要グループの割合、複数の入口、手動対応のケース、同時操作を説明します。技術チームは、毎分何件の操作が始まり、各段階がどれだけかかるかを算出します。

カンファレンスの運営では、交通のスケジュール、全体会議の開始、セッションへの入場、資料配布のルールをまとめると役立ちます。バスや全体ブロックの終了は需要の段差を生みます。前の操作がすでに遅くなっていても、ゲストは到着し続けます。

最小限のモデルには以下が含まれます。

• 時間帯ごとの予想来場者数
• QR、手動検索、事前登録のないゲストの割合
• 入口、カウンター、スキャナー、プリンターの数
• 再スキャンと再印刷の割合
• ステータスやカテゴリーの直前の変更
• ネットワーク、メール、SMS、外部データベースへの依存

このようなプロファイルにより、技術的な負荷と目に見える行列を対応させることができます。サーバーが高速に応答しても、検索、印刷、不明瞭なエラーによってワークステーションがゲストを処理するのに時間がかかることがあります。そのため、システム操作とカウンターでの全サイクルを別々に測定します。

シナリオにはどの業務を含めるべきか

シナリオは、受付でチームが実行する業務を例外も含めて再現する必要があります。登録ページを1つ確認するだけでは、準備が整ったという誤った安心感を得てしまいます。通常フローは、手動検索、QRの再発行、遅延登録、印刷と一緒に実行し、共有リソースの競合や複雑なケースが待ち行列に与える影響を確認します。

私たちは次のようにルートを組み立てます。

1. ゲストがQRコードを提示するか、検索用のデータを伝えます。
2. オペレーターが正しい1件のレコードを見つけます。
3. システムが現在のステータスとアクセス権を確認します。
4. チェックインがステータスを正確に1回だけ変更します。
5. プリンターが最新のカテゴリーでバッジを発行します。
6. 隣のカウンターが手動でのデータ更新なしに変更を認識します。
7. 最終出力に確認済みの記録が1件だけ含まれます。

シナリオには、入力ミス、同姓同名、QRコードがないケース、使用済みコード、遅延登録、バッジ再発行のリクエストを追加します。詳細な媒体のセットはイベントにおける安全なQRコードの記事で確認できますが、負荷テストをQRセキュリティの個別監査にしてしまう必要はありません。

後からの変更も同じ一連の流れを通過しなければなりません。管理用出力の後にレコードを作成または変更し、検索、権限、印刷、新しいステータスの反映を確認します。遅延登録に関する関連記事は、プロジェクトのカレンダー全体を繰り返すことなく、そのようなシナリオを準備するのに役立ちます。

登録はイベント運営全体に組み込まれています。会場、協力会社、受付チームを含む全体の流れが必要な場合は、ビジネスイベントの運営をご覧ください。役割、チェックポイント、予備の対応策を事前に合意します。

会場の準備やチームの動きに関する実践的な解説は、「Aventura」のTelegramチャンネルでも公開しています。

3つの実行モード

当社の受け入れプロトコルでは、基本チェーンの短い確認、想定される業務フロー、急激なスパイクという3つのモードを使用します。これらはそれぞれ異なる問いに答えるものです。1回の滑らかな立ち上げではシナリオの誤りが隠れることがあり、限界性能の探索では合意されたピークがビジネス基準を満たすことを確認できません。

k6のドキュメントには、基本チェック、通常負荷、過負荷、急激なスパイク、システム限界の探索のための個別のモードがあります。発注者はツールの設定を理解する必要はありませんが、実行の目的を理解する必要があります。

あるモードは突然の流入への反応を示し、別のモードは限界を探します。業務実行はイベントの具体的なシナリオを確認するものです。

大規模なリハーサルの前に、チームは各パスの基本実行を行います。これにより、誤ったテストレコード、必要な権限の不足、統合のエラーを検出します。その後、負荷は技術者の即興ではなく、合意されたプロファイルに従って増加します。

安全なテストデータを準備するには？

リハーサルには、実際の連絡先を含まずゲストデータベースの構造を再現した合成プロフィールを使うのが適切です。データセットにはさまざまな役割やカテゴリが含まれます。一部のレコードは、似た姓、後からの変更、例外を模倣しています。開始前にチームはアクセス権と削除期限を合意し、外部配信は安全なテスト環境に切り替えます。

連邦法第152-FZ第5条の原則は、処理目的の特定、その目的とデータの整合、過剰性の排除を求めています。負荷テストにとってこれは、同じシナリオを架空のレコードで再現できるなら「リアリズムのため」に本番データベースをコピーしないという実務的な根拠になります。

データセットは次の手順で準備します：

1. チェックインに実際に関与する項目とステータスを特定する。
2. 必要なカテゴリと分布の合成レコードを作成する。
3. QRの再発行、後からの変更、再印刷用のレコードを別途マークする。
4. オペレーターとオブザーバーのアクセスをテスト用の役割に限定する。
5. 実際の宛先へのメールやメッセージの送信をブロックする。
6. 受け入れ後にレコード、ログ、エクスポートの削除期限を設定する。

フォームや同意に関する法的要件は別途確認する必要があります。これについては152-FZに基づく登録フォームに関する資料があります。負荷リハーサルでは、すでに承認されたデータスキームを検証します。テストレコードの構成、アクセス権、ログ記録、保存期間は、個人データ責任者または弁護士と合意してください。

起動前の「合格／不合格」（PASS/FAIL）基準

PASS/FAILは、あらかじめ記録された基準に対する「合格／不合格」を意味します。テスト前に受け入れ基準を記録し、約束したゲスト導線と結び付けます。遅延や操作回数についての普遍的な基準はありません。プロジェクトチームが許容フロー、エラー、サービス時間、停止ルールを定め、その後で基準値を後から調整することなく、実際の結果と比較します。

k6のしきい値条件は、メトリクスの基準を満たしたかどうかを自動的に示します。ドキュメントに記載された具体的な値を、そのままプロジェクトの基準値として持ち込むことはできません。それらは、許容される待ち行列と約束したサービスを考慮して、システムオーナー、発注者、運用チームが決定します。

特別な基準は負荷ジェネレーターに関するものです。予定された操作が開始されなかった場合、レポートには申告より少ないフローが記載されます。メトリクスdropped_iterationsは、テスト対象システムの劣化と、ジェネレーター自体のリソース不足や設定ミスを切り分けるのに役立ちます。

リハーサル中に何を壊すべきか

リハーサル中、私たちは合意した時間枠の中で、ネットワーク、プリンター、外部サービス、または1つのワークステーションといった個々の依存関係を順番に切断または遅延させます。チームは検知速度、メッセージの分かりやすさ、バックアップへの切り替えを確認します。各障害は、即時停止の権限と事前に任命された実行責任者を伴うシナリオに従って発生させます。

有用な障害のセット：

• 遅い、または一時的に利用できないネットワーク；
• 1台のスキャナーまたはプリンターの故障；
• 実際には完了したチェックインの応答が失われる；
• 再試行までの待機時間を示すHTTP「リクエストが多すぎます」応答；
• 利用できない外部データベースまたは印刷サービス；
• 不明なステータスによるオペレーターの二重押し；
• 手動マーク後の依存関係の復旧。

即時の自動再試行は新たなリクエストの波を生み出す可能性があります。すでに過負荷のサービスはさらに多くのリクエストを受け取り、復旧に時間がかかります。操作がゲストのステータスを変更する場合、盲目的な再試行は重複を生む可能性があります。システムは安全な再試行、待機、結果の手動確認を区別する必要があります。

ネットワーク部分は会場のインフラ所有者と調整するのが望ましいです。カンファレンスでのゲストWi-Fiに関する記事では、業務用の登録をゲストトラフィックと一緒に単一の共通速度テストで評価してはいけない理由を説明しています。

受付カウンター、QRコード、フィードバック

ラボテストは、実際のカウンター、デバイス、媒体を使った実地リハーサルで補完されます。チームは異なる明るさのスマートフォン画面、紙のコード、反射、再かざし、ノイズを確認します。オペレーターは、インターフェースの音や色だけに依存しない、操作の明確な結果を確認できなければなりません。

GS1は、二次元コードの読み取りやすさを、シンボル周囲の余白、コントラスト、均一なグリッド、グラフィカルノイズの不在と関連付けています。そのため、リハーサルにはゲストが実際に受け取るサイズ、素材、表示方法を含めます。モニター上の完璧なテスト画像は、実際の媒体の代わりにはなりません。

私たちのシナリオでは、6つの識別可能な状態を確認します：「コード読み取り済み」「確認中」「入場確認済み」「すでにチェック済み」「記録が見つからない」「接続なし」。W3Cのステータスメッセージに関するガイドラインは、フォーカスを強制的に移動させることなく、状態の変化をプログラムで判別できることを求めています。受付カウンターにとっては、スタッフの習熟速度の問題でもあります。

入口の物理的な配置、待ち行列、機器の配置は会場選定の際に考慮する必要があります。システムがサーバーテストに合格しても、狭いロビー、複数カテゴリ共通の列、オペレーターがゲストの流れを横切って行かなければならないプリンターなどにより、処理能力を失う可能性があります。

予備系と復旧をどう検証するか

予備系は、実際の切り替え、ログインの継続、そして突き合わせによる照合を経て初めて機能すると見なされます。ローカルモードまたはオフラインモードが謳われている場合、チームは主要な依存先を切断し、操作を蓄積し、接続を復元して競合を確認します。オフラインモードがない場合は、手動プロセスと全ラック共通の切り替え指示をリハーサルします。

復旧シナリオは次のように進みます。

1. 演習責任者が対象の依存先の障害を宣言します。
2. チームが検知時刻と目に見える症状を記録します。
3. 受付責任者が合意済みの切り替え指示を一つ出します。
4. オペレーターは予備経路でログインを継続します。
5. 観察者が手動およびローカルの記録を残します。
6. 主要サービスを合意された手順で復旧します。
7. データを照合し、競合を解消し、最終バージョンを確認します。

接続の詳細な図とローカルリストの扱いについては、モバイルインターネットなしでのイベントに関する記事をご覧ください。今回のリハーサルでは切り替えのポイントと逆同期が重要です。誰が指示を出し、オペレーターが何を見て、入場の二重記録をどう防ぐかが鍵となります。

予備系は各ラックが勝手に有効化してはなりません。合意のないローカル判断は複数の「真実」を生みます。モードの決定は責任者一人が行い、演習ログには時刻、理由、適用範囲を記録します。

実行後のベンダー報告書

報告書は、実際に生成された負荷と各ビジネスオペレーションの結果を示さなければなりません。制約事項と修正責任者を別途明記します。平均レイテンシのグラフだけでは不十分です。

発注者には、時間別プロファイル、印刷状態、予備系の動作が必要です。重大な不具合には、元のシナリオによる再実行の結果を追加します。

報告書には以下を含めます：

• システムとシナリオのバージョン；
• テストデータと機材のバージョン；
• オペレーション開始の計画プロファイル；
• 実際に生成されたプロファイル；
• 個々のオペレーションの結果；
• エラーとタイムアウト；
• 「リクエストが多すぎます」の応答とリトライの挙動；
• dropped_iterations とジェネレーターのリソース；
• ワークステーションでの完全なサービス時間；
• 印刷キューと再発行の事例；
• 予備系への切り替えと復旧の結果；
• 不具合の一覧、責任者、再確認の基準。

不具合は再現可能なシナリオと結び付けます。カードには元の条件と手順を残します。そこに期待される結果と、チームが実行時に確認した内容も記載します。

作業を継続するために、影響、暫定措置、責任者を記録します。全体的なアプローチはイベント時のインシデント記録と照合できます。会場オープン前は、不具合をイベントの作業ログとは別に管理します。

「修正済み」というメッセージだけでは指摘はクローズされません。チームは同等の初期条件で同じシナリオを再実行します。結果が変わっていれば、報告書に新しい PASS が記載されます。変わっていなければ、不具合は未解決のまま残るか、明示的に合意された制約として受け入れられます。

発注者向け受け入れチェックリスト

必要なのは、すべての技術的な図表へのアクセスではなく、分かりやすい確認項目をまとめた短いリストです。リハーサルを終える前に、到着プロファイルが再現されたこと、複雑なケースがメインの流れを止めなかったこと、バックアップが実際に有効になっていることを確認してください。重大な不具合ごとに担当者を定め、修正後には結果を記録した上で再実行を行ってください。

1. 到着時間帯、入口、オペレーションの構成が記述されている。
2. 各ルートの基本実行が大きな負荷の前に完了している。
3. 想定される流れと急激なスパイクが別々に実施されている。
4. 実際の強度が計画と一致している、または差異が説明されている。
5. 成功したQRが1回だけ正しく記録される。
6. タイムアウト後の再試行で重複が発生しない。
7. 印刷が実際のプリンターと消耗品で確認されている。
8. 手動のケースは別のレーンに流れ、メインの流れをブロックしない。
9. オペレーターが分かりやすいステータスと次のアクションを確認できる。
10. アクセスを制限した合成データが使用されている。
11. 依存先の障害と復旧が実地で確認されている。
12. 重大な不具合はそれぞれ修正後に再確認されている。

対面でのリハーサルは、イベントの技術リハーサルと同じルールで組み立てると便利です。シナリオ、観察可能な結果、指摘事項の担当者、再確認という流れです。違いは焦点にあり、ここではチーム全員が受付の流れとその依存先だけに注目します。

受け入れは、実際の流れの中でのゲストの全経路、障害発生時、そして復旧後のすべてをカバーする必要があります。単独のスキャナーやフォームだけでは全体像はつかめません。

出典

• Grafana k6: 負荷テストの種類
• Grafana k6: thresholds の基準
• Grafana k6: dropped iterations
• Microsoft Azure Architecture Center: Retry Storm アンチパターン
• Microsoft Azure Architecture Center: Retry パターン
• Zebra DataWedge: バーコード入力とフィードバック
• GS1: 二次元コードの品質と可読性に関するガイドライン
• IETF RFC 6585: HTTP 429 Too Many Requests
• W3C WCAG 2.2: Status Messages
• 連邦法第152-FZ号: 個人データ処理の原則