CrowdHandlerでは、よく最初にこう尋ねられます。「『One In, One Out』に対応していますか？」その答えは、「はい、対応しています……しかし、ほとんどのユーザーにはお勧めしません」です。
これまでの経験から、単に適切な流入レートを設定するだけで、「1つ入れば1つ出す」方式よりも効率的にトラフィックを管理できることがわかっており、これは当社のクライアントの大多数にとって最適な解決策です。
残念ながら、多くのウェブサイト運営者は「はい、『One In, One Out』に対応しています」という説明は聞くものの、そのアドバイスの後半部分まで耳にすることがありません。彼らにとって、「One In, One Out」という概念はあまりにも理にかなっているため、これ以外の方法でトラフィックを管理することなど想像すらできないのです。そこで、彼らは「One In, One Out」の設定を確認してサイトを公開します……しかし、その結果、キューが溜まり、ユーザーから待ち時間に関する苦情が寄せられることになるのです。
では、「1人入ったら1人出る」というルールには、一体何が問題なのでしょうか？
問題は、私たちの多くが理解している「ワン・イン、ワン・アウト」という単純な公式が、ウェブサイトのトラフィックやユーザーの行動経路という現実とは一致しない点にある。「ワン・イン、ワン・アウト」という閾値は、無関係であるばかりか、問題を引き起こす可能性もある。
関係がない？ さて、ユーザー収容能力が1000人で、1分間に100人のユーザーを受け入れているウェブサイトがあるとしましょう。平均的なユーザージャーニーが10分かかることがわかっているため、ユーザー数が0人の状態から開始した場合、10分で収容能力に達すると予想されます。その後、「1人入れば1人出る」という仕組みが多くの人が想定している通りに機能すれば、計算式は単純な1000÷10となります。 最初の100人のユーザーが10分目に利用を終了し、その時点で次の100人のユーザーを受け入れ、というように繰り返されることが予想されます。
代数の授業でしっかり聞いていた人なら、この時点で、容量1000という変数が相殺されてしまっていることに気づいたかもしれません。流入率を100に設定するだけで、まったく同じ効果が得られます。
しかし、「1人入れば1人出る」という考え方は、このシナリオにおいて単に無関係というだけではありません。むしろ、積極的に問題を引き起こすものです。というのも、この単純な「1人入れば1人出る」という式は、セッションのタイムアウトとチェックアウトの処理能力という2つの重要な要素を無視しているからです。
問題1：セッションのタイムアウト
さて、平均的なユーザージャーニーには10分ほどかかるかもしれません。しかし、かなりの数のユーザーは結局チェックアウトに至らないでしょう。また、たとえチェックアウトしたとしても、その事実が把握できない可能性があります（チェックアウト失敗の追跡を設定していない限り）。そこで、ユーザーセッションを放置して、将来的にキャパシティに悪影響を及ぼす可能性を避けるため、タイムアウトを設定しています。
CrowdHandlerのデフォルトのセッションタイムアウトは15分です。つまり、すべてのユーザーについて、最後の操作から15分間は順番が保持されます。これにより、ユーザーは閲覧中に一息ついたり、緊急のメールに返信したり、別のサイトで簡単に価格比較を行ったりした後でも、最初からやり直すことなく、再び待ち行列に戻ることができます。
したがって、この15分を考慮すると、実際の平均ユーザージャーニーは25分となります。 先ほどの式に戻ると、1000/25 ということは、1000 人のユーザーに対して「1 人の入室につき 1 人の退室」を強制している場合、実効処理率は 1 分あたりわずか 40 人の入退室に過ぎないことを意味します。当初の計算を用いれば、3000 人の待ち行列は 30 分後に解消され、待ち時間の中央値は 15 分になると予想されます。 しかし、セッションタイムアウトを考慮すると、最初の1000人のユーザーは最初の10分間でキューから離脱し、その後、残りの2000人のユーザーは1分あたり40人のペースでキューから離脱していくため、50分かかります。したがって、キュー全体が空になるまで実際には1時間かかり、待ち時間の中央値は30分となります。つまり、2倍の時間がかかります。
「あっ！」とあなたは思うでしょう。「でも、最初の1000人のユーザーを1分あたり100人ずつ入れるつもりはない。処理レートを最大化し、『1人入ったら1人出す』方式だけに頼って、最初の1000人のユーザーを1分以内にすべて受け入れ、処理能力を最大限に引き出すんだ」。 しかし、これは2つの理由から悪い考えです。まず第一に、このモデルシナリオにおいて、「One In, One Out」を採用した場合、最初のチェックアウト済みセッションの有効期限が切れ始める25分間、キューに残っている2000人のユーザーは全く先に進めなくなります。それらのユーザーは、順位が全く動かない状態と、ひどい待ち時間の見積もりを目の当たりにすることになるでしょう。 まさに、あなたが避けようとしているようなユーザー体験です。さらに、「One In, One Out」のしきい値設定においてセッションタイムアウトを慎重に考慮していない限り、解消されないキューに加え、長期的には実際にチェックアウト数も減少することになります。
問題2：チェックアウト処理能力
この問題は、別の誤解に起因しています。それは、「One In, One Out」の設定を負荷テストの結果に基づいて行っていることです。
負荷テストでは、トラフィックを徐々に増加させる傾向があります（CrowdHandlerでレートを設定する場合と同じです！）。また、多くの場合、日常的なトラフィックをモデル化しており、購入するよりも閲覧している訪問者の方が多いと想定されています。しかし、製品リリース時や新商品発売といった繁忙期には、チェックアウトの割合は通常のトラフィックよりもはるかに高くなります。ユーザージャーニーの開始時に投入したユーザーのほとんどが、 earliest opportunity でチェックアウトを行うと想定すべきです。
多くの点において、サイトが処理できると想定される同時接続ユーザー数は重要ではありません。重要なのは、1分あたりに処理できるチェックアウトや取引の件数です。多くのサイトは1000人の同時接続ユーザーに対応できるかもしれませんが、1分あたり1000件のチェックアウトを処理できるサイトはごくわずかです。 「1人同時接続、1人退出」の設定を同時接続ユーザー数に基づいて行うと、セールやサイト公開時に発生する実際の取引数の急増に対応できず、モデルシナリオの10分目に発生するチェックアウトの急増により、サイトがダウンする可能性が高くなります。これは、1分目に1,000人のユーザーを同時に接続させてしまった場合に特に当てはまります。
わかりやすい例えとして、収容人数が1000人であるにもかかわらず、レジが10台しかない実店舗を挙げることができます。この店舗は1000人の顧客を余裕をもって収容できますが、1分間に効率的に処理できる注文は10件のみです。一度に1000人の顧客を入場させると、長い列ができ、取引が滞って進展が見られないため、顧客は苛立ちを募らせることになります。 オンラインでも同じことが言えますが、リスクは長い行列ができることだけでなく、サーバーがダウンしてしまうことにもあります。
正しいやり方
「One In, One Out」の問題を軽減する一つの方法は、セットアップ時にいくつかの複雑な計算を行うことです。これには、例えば、「One In, One Out」の処理能力の増強、セッションタイムアウト設定の短縮、セッションとチェックアウトの比率の算出、「チェックアウト時にセッションを破棄する」オプションが有効になっていることの確認、および実際のユーザー行動時間の算出などが含まれます。
実際、お客様が「One In, One Out」の設定を誤って行い、セールスに悪影響を及ぼしているのを見て、私たちはとても悲しくなりました。そこで、これらの計算を行い、推奨事項を表示するチェック機能を追加しました：
一部のお客様――つまり、同時セッション数がアプリケーションにとって真に重要な指標であり、負荷テストの結果をすべて把握していると確信しており、セッションタイムアウトの最適な設定や、それが「One In, One Out」のしきい値に与える影響を明確に理解しているお客様――にとっては、こうした計算は理にかなっているかもしれません。もしあなたがそのようなお客様であれば、心から敬意を表します。
しかし、ほとんどのお客様にとって、答えはもっと単純です。理論上の限界値や信頼性の低い負荷テストに基づく複雑な計算は忘れて、ユーザー体験に真に影響を与える指標に焦点を当てるべきです。成功の鍵は、仮定上の同時接続ユーザー数ではなく、実証済みのピークスループットを理解することにあります。
ほとんどのサイトにおいて、これは流入率を、持続可能な最大チェックアウト率よりわずかに高い数値に調整することを意味します。（良い目安としては、1時間で正常に処理できた注文の最大数を60で割り、その結果よりわずかに高い数値に流入率を設定することです。）これにより、サイトへの訪問者の流れがスムーズになります。
まずは控えめな設定から始め、その後パフォーマンスを注意深く監視してください。キューが長くなってきてもサイトの健全性が完全に維持されている場合は、いつでも処理速度を上げることができます。この際、CrowdHandlerの「Autotune」機能が役立ちます。
まとめると：実績のあるパフォーマンスに焦点を当てる
キュー管理戦略としては理にかなっているように聞こえるかもしれませんが、「1入れば1出る（One In, One Out）」という考え方を単純化して理解すると、実際の実行における現実的な要因が考慮されません。計算が仮定、つまり信頼性の低い、あるいは非現実的な指標に基づいているため、長い待ち時間、顧客の不満、チェックアウトの失敗といった問題が生じることがよくあります。
したがって、私たちはこの仕組みを支持はしていますが、その意味を正確に理解しないまま「One In, One Out」のしきい値を設定することは避け、同時接続ユーザー数といった指標よりも、チェックアウト率に注力することをお勧めします。実績のあるパフォーマンスと、サイトの実際の制限に焦点を当てることで、すべてのユーザーにとってのユーザー体験を向上させることができるでしょう。