（チケット、新商品発売、予約、数量限定商品など）何らかの「タイムリミットのある商品」を販売しているなら、サイトの拡張性について議論したことがあるはずです。その議論は通常、次の2つの結末のいずれかになります。プラットフォームの刷新か、あるいは何かを急ごしらえで追加して、うまくいくことを願うか、のどちらかです。
どちらもあまり良い解決策とは言えません。一方は高価で、時間がかかり、リスクも伴います。もう一方は、通常は販売開始の1週間前に、やむを得ず導入された点在する個別ソリューションの寄せ集めです。
3つ目の選択肢があります。これは当初から当社の製品に搭載されていた機能です。この機能を刷新し、本日よりコントロールパネルでご利用いただけるようになりました。
まずはリバースプロキシを導入しました。そして、それが静かに成功を収めていくのを見守りました。
最初のCrowdHandlerはリバースプロキシでした。任意のWebサイトを指定するだけで、コードの統合を一切必要とせず、迂回不可能なキューが構築できました。プラグインもSDKも不要。必要なのはDNSだけでした。
2021年にセルフサービス型のSaaSとして再リリースした際、それは従来のやり方のように見えました。 自社でCDNを運用するクライアントが増えており、すでにエッジ環境が整っている場合、そこにワーカーを配置する方が、その前に別のプロキシを連ねるよりも効率的です。そこで、当社はエッジおよびSDK統合の製品群を提供し、ユーザーが自社のスタックに適したものを選べるようにしました。高速かつバイパス不可能なソリューションを求めるユーザーのために、DNS実装も引き続きラインナップに残しました。
そして、いつの間にか、これは私たちが運用する中で最も信頼性の高い機能の一つとなりました。この機能はインフラストラクチャの内部ではなくその前に配置されるため、サーバー側でユーザーの確認やリダイレクトを行う負荷は一切かかりません。また、長年にわたり蓄積してきたスケーラビリティに関する知見は、お客様のコードベースではなく、私たちのレイヤーに組み込まれています。ほとんどのWordPressサイトにとって、これは当社のWordPressプラグインよりも優れた統合ソリューションです。そのように聞こえることは承知しています。
セットアップでは、すでに何かが手元にあることを前提としています
オンボーディングは、3つのステップからなるガイド付きフローです。具体的には、「証明書の発行」、「オリジンの設定」、「CrowdHandlerの有効化」です。
また、非常に一般的なケース――つまり、当社のDNS実装を別のリバースプロキシ（多くの場合、Imperva）の背後で稼働させる場合――にも対応できるよう改良しました。既存のWAFやセキュリティ層の上に当社のソリューションを積み重ねて導入する場合、その設定は3件目のサポートチケットが届くのを待つことなく、最初の画面から自動的に認識されるようになっています。
ウィンドウをキャッシュする。レジをキューに入れる。
これが肝心なものです。
どのサイトも、実際には2つのサイトから成り立っています。マーケティングコンテンツはすべての訪問者に対して同一であり、一度キャッシュされればほぼコストをかけずに拡張可能です。一方、取引プロセス（カート、決済、予約など）はユーザーごとに異なり、データベースへの負荷が高く、真の意味での拡張性は決してありません。これらを1つのものとして扱うと、両方の最悪な側面を引き継ぐことになってしまいます。
Appceleratorでは、コントロールパネルからURLレベルでその制限を設定できるようになりました。動作ルールを設定するだけで、ランディングページは訪問者に最も近いAWSのPOPから配信されます。キューチェックも、待ち時間も、オリジンサーバーへの往復通信も不要です。ほとんどの場合、ページは自社のサーバーでは到底実現できないほどの速さで表示されます。
購入や予約のプロセスに進むと、キューに登録され、それらのページは必然的にキャッシュされずに配信されます。
単純なことのように聞こえるかもしれません。マーケティング関連の課題とトランザクション関連の課題を分離することこそが、スケーラブルなWebアーキテクチャの要であり、多くのチームは、セール開催中の午前10時といったタイミングで、痛い目に遭って初めてその重要性を学ぶものです。ここでの違いは、プラットフォームの再構築プロジェクトを行う代わりに、リバースプロキシとコントロールパネルを活用することで、もともとそのような設計でなかったサイトに対しても、事後的にこの手法を適用できるという点にあります。
「待ち行列」は目に見える機能であり、「スケーラビリティ」こそが製品そのものです。
私たちを「キューの専門家」と捉えていただければ、Appceleratorはキューをインストールするためのより簡単な方法のように見えるでしょう。まさにその通りです。
しかし、セールもなければ行列もできていないような普段の日には、このサービスがどのような働きをしているか見てみましょう。キャッシュ可能なコンテンツを、世界中のAWSエッジロケーションから配信します。これらのロケーションはすべて、オリジンよりもユーザーに近い場所に位置しています。サーバーには一切届かないトラフィックを吸収し、サイトのパフォーマンス状況をリアルタイムで把握しています。そして、トランザクション処理経路に負荷がかかった瞬間、即座にアクセス量を調整する準備が整っています。
すべてが1つのレイヤーを通じて処理されるため、各部分が互いに連携して機能します。キャッシュにより、オリジンにかかる負荷が軽減されます。オリジンの負荷が軽くなれば、より高いトランザクションレートを維持できます。トランザクションレートが高ければ、キューへの処理速度が速くなり、待ち時間が短縮されます。あるいは、利用者が少ない日には、キューがまったく発生しないこともあります。 その一方で、同じレイヤーが重要な経路の応答時間を監視しているため、需要が急増した場合でも、受け入れ率は計画会議で誰かが推測した数値ではなく、その時点でサイトが実際に処理できる能力を反映したものになります。
実際に有効にしているもの
バイパス不可能なキュー。キャッシュすべきコンテンツに対するCDNレベルのキャッシュ機能。必要に応じてキューで保護されたトランザクション。継続的なパフォーマンス測定。コードの統合は不要。
DNSを当社に設定するだけで、本来あるべきアーキテクチャが、現在実際に使用しているアーキテクチャの前に適用されます。オリジンサーバー側では、この処理が行われていることを認識する必要はありません。CMSにプラグインを導入する必要もありません。開発者も、DNSの変更を承認する以外に関与する必要はありません。
本日、生放送です
Appceleratorは、コントロールパネル内のドメインのデプロイ設定に追加されました。
弊社のWordPressプラグインをご利用中の方、あるいは「技術的なプロジェクトになりそう」という理由で適切な統合を先延ばしにしてきた方は、ぜひ10分ほどお時間を割いてみてください。また、どのURLをキャッシュとキューのどちら側に割り当てるべきか判断するのに手助けが必要な場合は、 ぜひご相談ください。私たちも喜んでご相談に乗ります。
これらすべてを試すきっかけとなるようなセールや新商品発売、キャンペーンなどが予定されていますか？ CrowdHandlerに無料で登録しましょう。