Compiler Explorerと永続するURLの約束

 (xania.org)
1 ポイント 投稿者 GN⁺ 2025-05-30 | 1件のコメント | WhatsAppで共有
  • Compiler Explorer は当初、すべての状態を URLに直接保存 する方式を採用していた
  • URLが長くなりすぎたため、Googleの goo.gl 短縮URLサービス を導入し、この構造は複数回のリダイレクトを経る複雑さを生んだ
  • 2018年からはURL長の制限問題と保守の難しさにより、独自の S3 と DynamoDB ベースのストレージ を活用する構成へ移行した
  • しかし Google が goo.gl サービスを2025年8月に終了 するため、過去の短縮リンクの永続性を自ら管理しなければならない状況になった
  • 現時点までに 12,000 件を超える レガシーリンクを救出 しており、これは プログラミング知識の保存と持続可能なサービス運営 の重要性を示している

Compiler Explorer リンクの恒久保証と歴史

初期設計方式と goo.gl 導入の背景

  • 2012年、Compiler Explorer はすべてのコンパイラ状態を URLに直接エンコード する構造を導入した
  • 状態情報が増えるほど、URLが過度に長くなる問題が発生
  • URLを短くするため、2014年に Google の goo.gl 短縮サービス を適用
    • goo.gl/abc123 形式の短縮リンクを提供し、クリックすると元の長いURLへリダイレクトした後に状態を復元
  • Stack Overflow が短縮リンクの使用禁止（2016年）を行ったことで、従来方式に制約が生じた
    • 悪意あるリンクを隠せる危険のため、すべての goo.gl ベースのリンクが影響を受けた
  • ユーザーデータを保存したくなかったため、暫定策として godbolt.org/g/abc123 形式の独自パスを作成
    • godbolt.org/g/abc123 にアクセスすると goo.gl/abc123 に再度リダイレクト
    • この過程で最終的に godbolt.org の長いURLへ戻る
    • 複数のリダイレクトが発生し、構造が複雑になる問題があった
  • その後、Google API の利用によってリダイレクト手順の一部を簡略化

独自ストレージ導入とリンク管理

  • 2018年からは URL長の限界 とデータ圧縮の不便さが頻繁に問題となった
  • S3 と DynamoDB を活用した独自ストレージ構造を実装
    • 入力値を ハッシュ化 し、JSON 文書形式 で S3 に保存
    • 短縮リンク（godbolt.org/z/hashbit）にアクセスすると DynamoDB でマッピングを参照
    • ハッシュ値に卑語など不適切な単語が含まれる場合、ランダム要素を加えて回避するチェック機能を実装
    • ハッシュベースのリンクにおける不適切語の問題を解決し、関連バグも経験（例: issue #1297）
  • 現在もなお godbolt.org/g/abc123 形式のアドレスをサポート
  • Google の公式案内にもかかわらず、goo.gl サービスは読み取り専用へ移行しており、2025年8月に完全終了予定
  • goo.gl ベースの短縮リンクは今後解決不能になる予定
  • godbolt.org/g/abc123 形式は 直接管理によって延命可能 なため、これらのリンク構造に対して体系的な救済作業を進めている

レガシーリンクの大規模収集とアーカイブ作業

  • 最近、あらゆる可能なソース（検索、データダンプ、ウェブログなど）からレガシーリンクをクロールし、データベース化を進めた
    • Google Web Search API
    • GitHub API
    • 自前のサーバーログ
    • archive.org の Stack Overflow データダンプ
    • Archive.org に保存されたウェブページデータ
  • 約 12,298 件の短縮リンクの復旧に成功
  • 内部的には goo.gl の代わりに独自リンクデータベースの利用を開始した（関連PR: #7724）
  • 今後も未発見の godbolt.org/g/abc123 リンクを継続的に収集・確保していく予定
  • コミュニティにまだ未登録のリンクがあれば、直接アクセスするか管理者に知らせてデータベース補完を依頼してほしい

プロジェクト哲学とインフラ所有の重要性

  • 今回の事例を通じて、重要なインフラを外部サービス（例: Google）の継続性だけに依存することの危険性 が確認された
  • 短縮リンク管理とバックアップ構造は暫定策であり、完全に永続的なURLを約束するにはサービス全体を自ら管理する必要 がある
  • デジタル考古学のように古いレガシーリンクを救う過程で、一つひとつのリンクが 誰かの知識共有、質問、概念説明の痕跡 であると認識した
  • この保存と保全の行為は、プログラミングコミュニティの歴史のアーカイブ にも直結する
  • 古い Compiler Explorer のリンクを見つけたなら、今からでも一度ずつクリックしてみることが、インターネット上の知識保存に貢献する道だ
  • 今回は サードパーティではなく、自ら制御できるインフラ に依存することで、継続保証の約束を果たせるようになった

Disclaimer

  • 本文は人間が執筆したものであり、リンクの推薦と文法チェックの過程で LLM を活用した

関連記事

1件のコメント

 
GN⁺ 2025-05-30
Hacker Newsの意見
  • 2010年以前は、リンクは永遠に残るという前提が当たり前のように感じられたので、ブラウザのブックマーク機能を積極的に使っていた。しかし時が経つにつれて、多くのブックマークがリンク切れ（linkrot）によって事実上使えなくなるのを経験した。その後、WebページをPDFで保存する習慣がついた。Reader viewが一般化してからは、Reader viewで内容をコピーしてRTFファイルとして保存する方式に変わった
    • 訪問するすべてのページをアーカイブするためにSingleFile拡張機能を使っている。インストールや設定は簡単なほうだが、かなりの保存容量を消費する点には注意が必要だ。例として、Webページのアーカイブディレクトリが1.1TBに達している SingleFile GitHubリンク
    • 公式のWeb Archiveブラウザ拡張機能をインストールすれば、訪問するすべてのページを自動でアーカイブするよう設定できる
    • 私のやり方は、重要な情報や、少なくともそれをどこで見つけられるかを覚えておくことだ。まだ生きているので、この方法もそれなりに有効なのだろう
    • リンクがタイムアウトしたとき、自動でweb.archive.orgに移動してくれるブラウザ拡張機能があるのか気になる
    • WARCフォーマットをWebRecorderと一緒に使う方法がある WARC情報, WebRecorder
  • ArchiveTeamのGoo.glプロジェクトに協力するのは価値のあることかもしれない プロジェクト詳細情報。URL短縮は本当に最悪のアイデアだったと思う URLTeamの説明
    • そのプロジェクトのリアルタイム状況によると、425億件のgoo.gl URLのうち75億件が発見された状態だ リアルタイム状況リンク
    • ArchiveTeamはおそらく「既知の」リンクではなく、Goo.gl短縮URLをブルートフォースしていたのだと思う。Compiler ExplorerのURLの大半、あるいは全部が彼らのデータに含まれているはずで、だから連絡してみるのは良いアイデアだと思う
  • URLが永遠に残るというのは理想的な夢だった。現実には、実際のところ99%のURLは永続的ではない。勝ち目のない戦いを続けるより、インフラは永続的ではないという前提で技術を築いていくべきではないかと思う
    • インフラが永続的ではないという前提で技術を作るのが正しい方向だと思うし、URL短縮サービスをインフラのように使うのも避けるべきだと思う
    • URN（Uniform Resource Name）は、場所に依存せず資源に同一性を与えるために考案された仕組みだ。しかし普及はせず、むしろURL短縮サービスがこの概念を十分に実装できないまま似たことを試みた程度にとどまった URNのWikipedia説明
    • ドメイン名はしばしば所有者が変わるし、永続的に見えるURLでも、時が経てば悪意あるフィッシングリンクに変質することがある
    • URLはネットワーク上で資源の場所を識別するだけで、資源そのものを識別するものではない。だから永続的である必要も、唯一である必要もない。だからこそ「Uniform Resource Locator」という名称なのだ。この問題を認識して、1997年にDigital Object Identifierが発明された
  • リンク短縮サービスをデータベースのように濫用し、後になって大切なリンクをインターネットのあちこちから探し直さなければならない状況には、どこか詩的なものを感じる
    • URL短縮の本来の目的は長いURLを短くすることだ。むしろ問題なのは、短縮URLを通じてスパム・詐欺・違法サイトを隠そうとしてドメインを濫用する人たちだと思う
    • 彼らも単にURLを圧縮するために短縮サービスを使っていたのだと思う。もともと彼らのURL自体がコンパイラの状態を「データベース」のように保持していたのだ
  • https://killedbygoogle.com/、Google Go Links（2010〜2021）は約11年間運営されたのち4年前に終了したGoogleのURL短縮サービスだった。Google Workspaceの顧客はカスタムドメインも使えた
    • 新しい短縮URLをこれ以上作れなくする形でサービスを終了する（“minting new ones”）のは、それほど深刻な問題だとは思わない。既存のURLまで終了させるほうがはるかに不当だと思う。特にGoogleは内部的には一部のアプリで今でもこの機能を使い続けているのだから
  • 「この記事は人間が書いたが、リンク提案と文法チェックはLLMが行った」という文言が二番目に目についた。何か新しいトレンドの始まりを見ているような感じがする
    • 人々がこういう案内文を入れなければならないと感じている現実が興味深い
    • 私としては、そうした案内文の必要性をまったく感じない。コンテンツ自体が自分を証明できるならそれで十分だと思う。もし内容の質が低いなら、それがAI生成であれ人間作成であれ関係ない問題だ。そうした案内文を求める人たちは、おそらく自分で内容を評価する能力がなく、AI生成コンテンツを低品質とみなす一種の代理判断ツールのように扱っているのだろう
  • Googleがあえて読み取り専用版まで終了させようとしているのは意外だ。非公開リンクのリダイレクトを残しておくことに法的リスクを懸念しているのではないかとも思う
    • 内部の正確な事情は分からないが、運用中のサービスが古い、あるいはセキュリティ上脆弱なライブラリやランタイムに依存しているため停止したいのかもしれない。実際、些細なコストであっても最終的にはコスト削減のためにサービス終了を選んでいるように見えるし、企業の善意や過去の約束などは気にしていないような印象だ
  • Googleの社員に頼んで、godbolt.orgへリダイレクトされる短縮URLだけをデータベースから抽出してもらう方法がまったくないのか気になる
  • 正直に言えば、十分な資金を持つ財団が介入しない限り、Compiler Explorerやgodbolt.orgもいつかは永遠ではなくなる運命だ
    • これまでのところ私たちはうまく運営してきた。今週で13周年で、すべてのスポンサーが支援を打ち切ったとしても、あと1年あまり運営できるだけの資金が積み上がっている。最近は財団設立のようなことも考えている。実際の弱点は資金不足ではなく、個人である私が単一障害点になっていることだ
    • その通りだ。今ではCompiler Explorerのリンクが切れる時点は、本当にCompiler Explorer自体が消えるときだけだろう。それまではリンクは生きているはずだ。特にバグレポートに残すCompiler Explorerのリンクは非常に価値があると思う。私もそうしたリンクと一緒にコード自体もレポートに含め、どのコンパイラとバージョンを使ったのかも明記している。Compiler Explorerがすぐ消えるとは思わないが、バグレポートをこうして自己完結的にしておけば、予期しない消失にも備えられる
    • no-hiding定理によれば、情報は永遠に生き残るという冗談を思い出した
  • ドメインの維持にもコストがかかるのに、URLがどうして永遠に残り得るのか分からないと思う。URLの消滅そのものがむしろ良いことなのかもしれない。人類は価値ある情報だけを特別に保存し、残りは自然に歴史の中へ消えていくのだ
    • しかし歴史家は、そうした「ゴミ」データであっても、より多くを欲しがる。そうでなければ、当時の実際の生活や文脈をよりよく理解できないからだ。もしタイムマシンに乗れるなら、1000年後の歴史家たちが、デジタルメディアの消滅によって大半の情報が失われたこの時代をどう見るのか気になる
    • 私も、URLが消滅することには良い面があるという意見に同意する。関連して書いた記事がある インターネットの揮発性について