【ニュース解説】大規模クラウド障害が浮き彫りにした音楽業界の脆弱性：.(dot)anyが分散型ホスティングで情報発信を守る理由

目次

1. 開場30分前の渋谷、スマートフォンの画面から消えたチケットQRコード
2. 一つの基盤に寄りかかった公式サイトが沈黙するまで
3. .(dot)anyの公演情報を静的ファイルとして複数の場所に残す設計案
4. 【実践ケース】ツアーファイナル告知ページを多重化して公開する4つの手順

開場30分前の渋谷、スマートフォンの画面から消えたチケットQRコード

これから描くのは、実際の障害報告に基づく再現ではありません。公演運営の段取りを考えるために私が組み立てた、想定上の場面です。

渋谷のライブハウス前、開場30分前。階段の手すり沿いに並んだファンが、一斉にスマートフォンを掲げ直します。チケット画面が回り続けて止まらない人がいれば、ログインに失敗したと首を振る人もいます。QRコードだけが表示されない人もいます。隣の誰かが公式タイムテーブルを確認しようとしても、そちらも開きません。

受付担当がまず確かめるのは、会場の通信状況です。次にチケット提供元の障害告知、最後に公式サイトの別配信先へと、順に当たっていきます。このとき、読み込みの停止、ログイン失敗、QRコードの取得失敗は別々の症状として記録しておく必要があります。三つを「つながらない」の一言でまとめてしまうと、後から原因をたどれなくなるからです。

遠く離れたクラウドの障害が渋谷の入場列まで届く経路は、ある程度は想像できます。共有している認証基盤や配信元が止まり、チケット表示と公式ページの取得が失敗し、受付の確認作業が膨らむ。ただし、二つのサービスが同時に止まったという事実だけで、同じクラウドが原因だと断定はできません。その判断は、提供元の障害報告で依存先が確認できてから下すものです。

見落とされやすいのが、SNSとの接続です。SNSのAPIで公式サイトの告知欄に投稿を取り込んでいる場合、取得制限や認証の失効がそのままサイト内の告知も空白にします。バンドとファンを結ぶ回線が、知らないうちに外部プラットフォームの都合に左右されているわけです。

一つの基盤に寄りかかった公式サイトが沈黙するまで

冗長化を検討するとき、最初にやるべき作業はサーバー台数を数えることではありません。閲覧に至るまでの依存関係を一枚に書き出すことです。

書き出す項目は、ドメイン登録、権威DNS、TLS証明書、配信基盤、CMS、データベース、画像やフォントの取得元です。並べてみると、別々に契約したつもりのサービスが同じ基盤に戻ってくる経路が見えてきます。同じリージョンに仮想サーバーを足しても、リージョン共通のネットワークやデータベースへの依存は消えません。別ホスト名でミラーを立てた場合も、権威DNSが共通ならそのDNSは共通依存として台帳に残します。

動的CMSがエラーを返す理由

WordPressのような動的CMSは、リクエストのたびにアプリケーションの実行枠とデータベース接続を消費します。ツアー発表の直後にアクセスが集中したり、バックエンドが遅延したりすると、接続待ちが積み重なります。その結果、ゲートウェイ側が502や504を返すことがあります。各ステータスの意味はRFC 9110に定義されています。

少人数の運営で引ける現実的な線

インディーズの運営体制で大規模な冗長化システムを組むのは、費用の面でも保守の面でも難しいのが実情です。保守費用には配信料金に加えて、ドメイン更新、証明書更新、公開失敗の通知先、ミラーの内容確認まで含まれます。

だからこそ、守る範囲を狭く決めます。まず公演情報の静的な退避先と、その復旧手順を保守対象に定める。請求と障害通知を受け取る担当者を決め、管理画面に入れなくなった場合に備えて、復旧に必要な情報を別の場所に保管しておきます。

.(dot)anyの公演情報を静的ファイルとして複数の場所に残す設計案

先にお断りしておくと、ここで述べる構成を.(dot)anyが導入済みだと示す資料はありません。藤田昂平、tatsu、AtsuyuK!の活動を伝える公式サイトに向けた設計案としてお読みください。

考え方の中心は、ライブ日程とディスコグラフィーを公開時に静的HTMLへ変換しておくことにあります。静的生成では、CMSやデータベースへのアクセスがビルドの時点に集約されます。公開済みページを閲覧する経路からそれらが外れるので、バックエンドが止まっても既存のページは読めます。その効果を得るには、HTMLだけでなくCSS、必要な画像、会場案内も同じ配信単位に含めておかなければなりません。

この案では、二つの仕組みを分けて考えます。一つはエッジ配信で、閲覧経路を複製する役割を担います。もう一つは分散型ストレージで、生成物そのものを保持します。

エッジ側でオリジン停止時にキャッシュから応答させるには、保存済みオブジェクトがあるか、鮮度はどうか、再検証の条件は何か、配信サービスの設定はどうなっているかを確認します。根拠となる仕様は、HTTPキャッシュを扱うRFC 9111と、stale-if-errorを定義するRFC 5861です。ストレージ側でコンテンツアドレス方式を使う場合は、生成物の識別子を公開記録に残し、複数の保持先で永続保持を設定します。独立した取得経路からHTMLと画像を読み出し、ビルド成果物のSHA-256ハッシュと照合します。

注意: この設計で守れるのは、公演時刻、会場への経路、物販案内といった公開情報に限られます。決済、ログイン、チケットQRコードの発行や有効性確認は外部APIに依存するため、別系統として扱います。個人別のチケット画面や注文情報は、公開キャッシュにも分散型ストレージにも置きません。

守るべき境界は受付のQRコードの手前にあります。ファンが会場までたどり着くための本文を残すこと。設計の優先順位は、そこに置いています。

【実践ケース】ツアーファイナル告知ページを多重化して公開する4つの手順

ここからは、ツアーファイナルの告知ページ一枚を題材に、作業を生成、複製、切り替え設定、遮断試験の4段階で進めます。原則は一つです。各配信先で別々にビルドすることはせず、一度生成した同一の成果物を配り、更新時刻とハッシュで一致を確認します。

1. 告知ページを静的HTMLとして生成する。公演日、開場・開演時刻、会場住所、最寄り出口からの道順、主催者が公開を認めた連絡先を本文に書き出します。地図は外部の埋め込みに頼りきらず、掲載権限のある案内図と文章による道順も同梱します。ページには生成日時とタイムゾーンを表示します。
2. 主系と副系へ同じ成果物を配る。同一リポジトリから生成した成果物を、主系CDNと、それとは異なる基盤の副系ホスティングへ自動配布します。両方で本番ホスト名を受け付ける設定とTLS証明書を事前に用意し、退避用URLも公開前に疎通を確認します。最後に成功した成果物は、運営担当が手元で取得できる場所にも保存します。
3. DNSの切り替えを設定する。ヘルスチェックと連動したDNSフェイルオーバーを組みます。試験用の設定例は、監視間隔30秒、連続3回の失敗で異常判定、TTLを300秒とするものです。これは製品の既定値でも復旧の保証でもありません。TTLはDNSレコードのキャッシュ時間を表すだけなので、短くしても自動では切り替わりません（定義はRFC 1035、全体の構造はDNSおよびコンテンツ配信の基本構造（RFC 1034）を参照）。
4. 主系を遮断して試験する。検証用ホスト名で主系への通信を遮断し、権威DNSの応答、再帰リゾルバーの応答、スマートフォンでの表示を順に確認します。

コツ: 合格条件は疎通確認だけでは足りません。公演当日に必要な本文と画像が実際に表示されることまでを合格条件にします。

手順4の記録は、次の形でそのまま書き写せば使えます。

• Wi-Fiで新規アクセスし、告知本文、会場案内図、物販案内、更新日時を照合する
• 携帯回線でも新規アクセスし、同じ4項目を照合する
• 主系を遮断した時刻を記入する
• ヘルスチェックが異常と判定した時刻を記入する
• 端末で副系の表示を確認した時刻を記入する
• 主系への通信を戻し、復帰後の表示を同じ4項目で照合する

要点: 三つの時刻を別々に残しておくと、「切り替えに時間がかかった」という印象を、DNS、判定、端末キャッシュのどこで時間を使ったかという事実に置き換えられます。

例えば、主系を遮断した後、携帯回線で副系の告知ページを開き、会場の住所、開演時刻、道順を確認できたとします。案内図も表示され、更新日時とハッシュが保存済みの成果物と一致すれば、公演案内の退避を確認できます。この場合、チケットQRコードの表示は未確認でも、会場までの道順は主系なしで読めています。