CliqerのリアルタイムをCloudflareから移行した理由（それでも私たちがファンであり続ける理由）

2026年9月24日18時42分（UTC）、私たちはCliqerのすべてのライブ接続をCloudflare WorkersとDurable Objectsから自社の専用サーバーへ移行しました。エッジを試しましたが、今回はうまくいきませんでした。Cliqerをお使いの方にとって、作業の仕方は何も変わりません。変わるのはその裏側です：ルームが誰にも説明できない理由で再起動することは、もうありません。

この記事は、その理由を率直にお伝えするものです。同時に感謝の気持ちでもあります。私たちは今もCloudflareの顧客であり、彼らが作るものの心からのファンだからです。

私たちが作ろうとしていたもの

Cliqerはライブツールです。発表者がスマートフォンをタップすると、別の大陸にあるかもしれないスクリーン上でスライドが進みます。通話参加者がショーに加わり、ホストがソースを切り替え、ステージ上ではタイマーがカウントダウンします。これらはすべてWebSocketの上で動いています：長時間維持される接続で、決して途切れてはいけません。途切れれば、それは観客の目の前で起こるからです。

Durable Objectsは完璧に合っているように見えました。各ルームには、自身のソケットとストレージを保持するシングルスレッドのオブジェクトが割り当てられ、Cloudflareのネットワーク上で動作します。管理するサーバーもなく、スケーリングを計画する必要もありません。5月下旬にはすべてのルームがその上で動いており、6月にはレガシーのCliqer v1ブリッジも加わりました。

何がうまくいかなかったのか

説明のつかない再起動

Durable Objectはプラットフォームによっていつでも再起動される可能性があり、再起動すると保持しているすべてのWebSocketが閉じられます。この点を確認するために調べたある24時間分のログでは、**再起動を生き延びたソケットはゼロでした。**ただの1つもです。

再起動がまれであれば問題ありません。しかし、まれではありませんでした：

• すべてのルームを保持していたリスボンのオブジェクトでは、5日間で21回の再起動があり、そのうち4回は1時間のうちに発生しました。メモリ不足もCPU上限もなく、プラットフォーム内部のエラーがいくつかあっただけで、私たちからのデプロイもありませんでした。
• 私たちはそれを移動させました。Durable Objectsは最初に作成された場所にとどまるため、移動とは再作成して、より良い場所に配置されることを祈ることを意味します。最初の試みではマドリード、次はアムステルダムに配置されました。
• アムステルダムでも再起動は続き、2時間から16時間ごと、平均で約8.7時間ごとに発生しました。
• 9月になっても、レガシールームを担うオブジェクトは何のきっかけもなく1日に2回から5回再起動していました。9月8日18時53分には、すべてのレガシー接続が同じミリ秒のうちに切断されました。デプロイもなく、ステータスページにインシデントの掲載もありませんでした。

皆さまにとって、そのひとつひとつが、プレゼンリモコンが反応しなくなったり、通話参加者が消えたり、本番の最中にアプリが再接続中と表示したりする瞬間でした。

タイムアウトしてルームをリセットしたストレージ

9月7日から10日にかけて、*「Durable Object storage operation exceeded timeout which caused object to be reset」*というエラーメッセージを4つのオブジェクトで8回確認しました。ある再接続の試みは、失敗するまでに44.5秒待たされました。数ミリ秒で済むはずのストレージ読み取りが、ルームごと道連れにしたのです。

デプロイのたびにすべてのルームが再起動

これはドキュメントに記載されており、妥当なものです：Workerの新しいバージョンをリリースするとそのDurable Objectsが再起動し、再起動すれば接続が閉じられます。8月19日から21日にかけて、ライブのお客様ルームにおける**再接続の44%**が同期した波となって発生し、ある1日には私たち自身のリリース3回がすべてのルームを切断しました。そのうち1回は本番の最中でした。

そこで私たちはソケットを専用のWorkerに分離し、変更されたすべてのファイルを調べて、どのデプロイがルームに触れてよいかを判断するツールを作りました。これは機能しました：次のウェブサイトのリリースでは、5人のホストがライブ中でもルームイベントはゼロでした。ただし、リアルタイムのコードを変更すれば、依然として全員が再起動されることに変わりはありませんでした。

ライブショーで私たちを悩ませた微妙な挙動

• **16分間の沈黙。**8月4日、43のソケットが接続されたままなのに、どのルームにもメッセージが1件も届きませんでした。エッジがルームに代わってハートビートに応答し続けていたため、どのクライアントも異常に気づかず、誰も再接続しませんでした。原因は、導入したばかりのプラットフォーム機能と、私たち自身の管理処理の組み合わせでした。同じ週のうちに元に戻しました。
• **ゴーストホスト。**クローズイベントがスリープ中のオブジェクトに届く保証はないため、退出したホストが何時間も接続中に見えることがありました。
• **4時間固まったままのキャッシュURL。**8月、Workerの前段にあるキャッシュレイヤーが、デスクトップアプリが起動時に確認する唯一のURLで固まってしまいました。アプリは起動できませんでした。同じURLに無意味なパラメーターを付けると、1秒で応答が返ってきました。

対処するために作ったもの

この4か月間で、私たちはプラットフォームの問題を皆さまから隠すために約18個の独立した仕組みを作りました：より高速なハートビート、ゴーストホストの掃除、起動のたびにストレージから再構築されるレジストリ、アプリが再開できるよう再起動後も維持されるID、独立したソケット用Worker、161ファイルを対象とするデプロイ分類ツール、配置のやり直し、リレーの監視機構、ルームごとのシャーディングと、それに伴うシャード横断の座席台帳です。

そのうち3つは、解決するよりも多くの問題を引き起こしたため、後に削除しました。そして、回避策を加えるたびに可動部品が増えていきました。ルームを複数のオブジェクトに分散させた結果、誤ったシャードに応答する暴走ルーム、再配置ループから抜け出せない視聴者、シャードをまたいで回避できてしまう座席上限が生まれました。どれも修正しましたが、私たちはCliqerを作る代わりに、プラットフォームを回避するための開発に時間を費やしていたのです。

公平を期すために

この数か月に起きた接続切れのすべてがCloudflareのせいだったわけではありません。私たちは確認しました：

• **個々の再接続の86%**は、単一のデバイスが自身のネットワークによって切断されたものでした：企業のプロキシ、会場のWi-Fi、長時間接続を嫌うファイアウォールなどです。だからこそ私たちは8月、デスクトップアプリに企業ネットワークへの対応を導入しました。
• 一部の波は私たち自身のデプロイによるもので、いくつかは私たち自身のデバッグツールが原因でした。
• 私たちは再起動についてサポートチケットを一度も提出しませんでした。これは私たちの落ち度です。

Durable Objectsは見事な技術であり、多くのワークロードにとってまさに最適です。ただ、観客の目の前で決して途切れてはならないルームは、いつでも再起動しうるプラットフォームにとって最悪のケースだったのです。私たちはリアルタイム処理のためにエッジを試し、今回はうまくいきませんでした。これはこのワークロードに対する評価であり、エッジそのものに対する評価ではありません。

今、ルームを動かしているもの

Cliqerのリアルタイム処理は現在、自社の専用サーバーで動いています。これらのサーバーはウェブサイト、API、すべてのWebSocketを提供し、ローカルデータベースに支えられながら、すべてのルームを直接保持しています。トラフィックは引き続きCloudflareのネットワークを経由するため、同じ保護と同じアドレスがそのまま維持されます。

なくなったもの：

• 裏側からの再起動はありません。プロセスは、私たちが止めると決めるまで動き続けます。
• 配置のくじ引きも、ルームをリセットするストレージのタイムアウトもありません。
• シャーディングもありません。1つのルーム、1つの場所、1つの信頼できる情報源です。

正直にお伝えしていること：

• **アップデートをリリースすると、接続は一度だけ再接続されます。**新しいバージョンが古いバージョンの隣で起動し、ほぼ瞬時に引き継ぎます。アプリは約1秒で同じIDのまま再接続し、それまでの状態から作業を続けます。リハーサルでは、4,757件のウェブリクエストが切り替えをまたいで処理され、失敗は1件もありませんでした。
• 私たちのサーバーはヨーロッパにあります。中身が見えない何百もの拠点よりも、完全に理解しているマシンを運用したいと考えています。

速度も向上

私たちは自社側ですべてのAPIリクエストの所要時間を記録しているため、ラボテストではなく実際のトラフィックを使って、移行前の1週間と移行後の数日間を比較できます。

最も遅いリクエストは、さらに大きく改善しました。ダッシュボードのブランディング読み込みのうち最も遅い1割は1.7秒から0.5秒未満に短縮され、最も遅いリレー認証情報の取得は7倍速くなりました。

最大の変化は、最初に体感できる部分です。旧プラットフォームでアイドル状態だったリアルタイム接続は、起動を待つ間、開くまでに約1.2秒かかっていました。自社サーバーでは、毎回約0.14秒で開きます。北米からcliqer.ioを1分ごとにチェックしている独立した稼働監視ツールでも同じ結果が出ています：1回のチェックあたり、移行前は約750 ms、移行後は約380 msです。

ルーム内では、クリックはもともと高速で、それは今も変わりません。変わったのはその周辺のすべてです：アプリの起動、発表者ページの読み込み、アカウント情報の取得。すべてがより速く、毎回同じように応答します。

Cloudflareが今も担っていること

多くのことを、喜んで任せています：

Cloudflareのオブザーバビリティと分析機能があったからこそ、この記事にある診断の大部分が可能になりました。私たちは今も顧客であり、今もおすすめしています。

接続が切れたらお知らせください

私たちの約束はシンプルです：今後、接続が切れたときには、突き止められる理由があります。本番の最中にCliqerが再接続するのを見かけたら（その場でのスライドがフリーズしたときの対処法はこちら）、私たちからのメールのいずれかに返信するか、アプリからチャットを開いてください。すべて拝読しています。そして今なら、その理由を実際にお伝えできます。