2万人の参加者が一つの会場に集まる時、ゲートで読み込み中のスピナーが表示されることほど、避けたい事態はありません。しかし、スタジアムや展示会場のアクセス制御システムを、静かなオフィスビルと同じように扱ってしまうと、まさにそれが起こります。高密度な環境では、ネットワークは「当たり前にあるもの」ではなく、「リスク」となります。数千の同時接続によってセルラータワーは過負荷に陥り、会場のWiFiはパンクし、バックホール回線は飽和します。もしゲートの認証が、バッジの有効性を判断するためにクラウドAPIへの呼び出しに依存しているなら、それは自らの入場フローに対してDoS攻撃を仕掛けているようなものです。インターネットは途切れ、ゲートは停止し、群衆は滞留します。解決策は、より高速な接続ではありません。会場内のローカルなイントラネット上で完全に動作する、エッジコンピューティング・アーキテクチャなのです。
接続の罠
高密度な会場では、クラウドファーストなソフトウェアの標準的な前提が崩れます。基調講演が行われているコンベンションセンターは、コーヒーショップとは違います。数千台のスマートフォンが同じマクロタワーを奪い合います。会場独自のニュートラルホストDASも容量限界に達することがあります。たとえ有線のバックホールであっても、アップストリームプロバイダーによる帯域制限や、数ブロック先での工事による光ファイバーの切断などの影響を受ける可能性があります。
このような混乱の中で、一般的な認証フローは次のようになります。バッジをリーダーにかざすと、リーダーがUUIDをクラウドAPIに送信し、クラウドデータベースがチケットの種別を検証し、APIが解錠コマンドを返します。この往復通信は、調子の良い日であれば200ミリ秒ほどで終わるかもしれません。しかし、負荷がかかると数秒に膨れ上がるか、あるいは完全に失敗します。一つのゲートにおける3秒の遅延は、単なる苛立ちで済みます。しかし、40のゲートすべてでそれが起きれば、数千人がオープニングアクトを見逃すだけでなく、最悪の場合、ボトルネック地点での群衆密度が危険なレベルに達することになります。アーキテクチャは、WANが不安定であることを前提とし、それに対処できるように設計しなければなりません。
真実のソースとしてのローカルエッジ
エッジコンピューティング・システムはこのモデルを逆転させます。資格確認のたびに遠くのサーバーに問い合わせるのではなく、コンピューティングとデータストレージを会場のローカルネットワーク内に配置します。これは、AV室にある堅牢な産業用PCであったり、売店の下にある小さなクラスターであったり、あるいは回転ゲート自体に組み込まれたゲートウェイであったりします。決定的な特徴はシンプルです。ゲートはインターネット越しではなく、建物内のマシンと通信するのです。
開場前に、エッジノードは参加者プロファイルの完全な同期を受け取ります。すべてのバッジID、すべてのアクセス権限、すべてのVIPフラグ、そしてすべてのマルチデイパスのルールが、ローカルメモリまたは高速なローカルSSDに格納されます。このデータセットは、期限切れになるキャッシュではありません。イベント期間中、運用上の「真実のソース（Source of Truth）」となるものです。WANがまだ生きている間に直前の登録が行われた場合、更新メッセージがエッジキューにプッシュされ、ローカルインデックスにマージされます。WANが切断されても、ゲートはそれを感知することすらありません。
ゲートロジックの動作
ローカルデータが配置されることで、ゲートの意思決定チェーンは短く、確定的になります。
ローカルメモリからの取得。 リーダーはバッジを検知すると、ローカルのプロファイルストアに問い合わせます。このルックアップは、インターネットの速度ではなく、RAMやNVMeの速度で実行されます。DNS解決も、遠くのロードバランサーへのTLSハンドシェイクも、独自のトラブルを抱えているかもしれないCDNへの依存もありません。
ローカルでの権限検証。 エッジノードは、クラウドに許可を求めることなく、ゲート固有のルールを適用します。「このバッジはゲート7Aで有効か？」「フロアへのアクセス権があるのか、それとも一般入場のみか？」「時間による制限はあるか？」といったすべてのルール評価は、プロセス内で完結します。また、直近のスキャン履歴をローカルの台帳として保持することで、同じバッジで二度入場することを防ぐアンチパスバック（anti-passback）ロジックを強制することも可能です。
ハードウェアリレーを即座に作動させる。 検証が通過すると、エッジノードはリレーを作動させます