世界を動かす技術を、日本語で。

2025年のコンパイラエクスプローラーの仕組み

概要

  • Compiler Explorer の仕組みと運用の詳細解説
  • 年間 9,200万回 のコンパイル実績、81言語・3,000以上のコンパイラバージョン対応
  • セキュリティ対策 とリソース管理の工夫
  • AWS・自動スケーリング ・コスト管理の現状
  • 今後の課題と展望

Compiler Explorerの裏側

  • Compiler Explorer は、元々C++17の有効化を上司に納得させるためのプロトタイプからスタート
  • 現在は 年間9,200万回、週あたり 180万回 のコンパイル実績
  • 81のプログラミング言語3,000以上のコンパイラバージョン を同時運用
  • サービスの成長とともに、運用も複雑化

コンパイルリクエストの流れ

  • Monacoエディタ (VS Codeと同じエディタ)でコード入力
  • CloudFront とロードバランサ経由でリクエスト送信
  • ロードバランサが適切なクラスタ・インスタンスを選択
  • サーバーがリクエストをキューイング(1インスタンスあたり最大2件同時処理)
  • nsjail でコードをサンドボックス化し、コンパイラを実行
  • 出力結果をフィルタ・整形し、 JSONレスポンス で返却
  • ブラウザでアセンブリ表示

オートスケーリング

  • 負荷に応じてクラスタ内のインスタンス数を自動調整
  • CPU負荷 を基準にシンプルなスケーリングを実施(AWS標準機能活用)

セキュリティ対策

  • インターネット経由で 任意コード実行 を許容しているため、セキュリティリスクが高い
  • 過去には Docker隔離の不備シンボリックリンク攻撃 など深刻なインシデントも発生
  • 現在は nsjail による強固なプロセス隔離を導入
    • Linuxネームスペース 全種利用
    • リソース制限 (ファイルハンドル、メモリ、20秒タイムアウト)
    • ファイルシステムの分離、nosymfollowでシンボリックリンク対策
  • 2種類のnsjail設定 で「プログラム実行」と「コンパイル処理」を分離運用

4TBに及ぶコンパイラ管理

  • 4TB超 のコンパイラ・ライブラリをPython・シェルスクリプトで管理
  • GCC 1.27(1987年製) など、極めて古いバージョンもサポート
  • 一度公開したコンパイラバージョンは 原則永久保存、リンク切れ防止へのこだわり
  • 管理ツール
    • bin/ce_install :S3等からコンパイラ・ライブラリを/opt/compiler-explorerへインストール、squashfsイメージ生成
    • bin/ce :各環境へのデプロイ管理、ローリングアップデート対応

squashfsによるストレージ最適化

  • 各VMに全コンパイラを直接インストール不可、 Amazon EFS (NFS型共有ストレージ)を利用
  • NFSの レイテンシ問題 を回避するため、主要コンパイラは squashfsイメージ 化してマウント
  • Boost等の巨大ライブラリもこの方式で効率的に運用

毎晩の自動ビルド

  • GitHub Actions と自作インフラで、主要コンパイラを 毎晩自動ビルド・インストール
  • orchestrationは compiler-workflows リポジトリのcompilers.yamlで管理
  • gcc-builderclang-buildermisc-builder 等で多様なビルドに対応
  • ビルド・インストールのタイミングは「有機的」に運用、今後の改善課題
  • 4,724バージョン81言語 対応のビジュアル化もAPI経由で動的生成

Windows/ARM/GPU対応

  • Linux x86-64 だけでなく、 Windows(MSVC)ARM64NVIDIA GPU にも対応
    • WindowsはLinux中心インフラとの統合に苦労、セキュリティ知見も強化中
    • ARMはネイティブ実行、GPUはNVIDIA協力でドライバ・ツールチェーン整備
  • すべて AWS us-east-1リージョン で運用
  • 地理的な遅延は CloudFrontエッジキャッシュ で一部緩和

モニタリングとコスト管理

  • Grafana agentPrometheusLokiCloudWatch で可視化・監視
  • パブリックダッシュボード でリアルタイム統計公開
  • コスト圧縮は課題、 スポットインスタンス や多層キャッシュ(ブラウザ・インスタンスLRU・S3)で効率化
  • 月額コストはおよそ 3,000ドル、Patreon・GitHubスポンサー・法人スポンサーの支援で運営

今後の展望

  • 現行システムは課題解決の積み重ね で進化
    • nsjail導入は攻撃対策
    • 毎晩ビルドは手動更新の負担軽減
    • マルチアーキテクチャ対応はユーザ要望に応じた拡張
  • 今後も「使いやすさ」「安全性」「拡張性」を追求

備考 本記事はLLM支援のもとで執筆されました。詳細は末尾参照。

Hackerたちの意見

俺だけかな?HNに何か問題がある気がする。https://ibb.co/0RwqjZvP

面白いバグだね。もう少しリフレッシュしたら、サイトが利用できないってメッセージが出たよ。今は直ったみたい。

クライアント側のエラーかもしれないけど、ホームページにこの投稿のリンクが3つもあるよ。

このツールはCompiler Explorerって呼ばれてるけど、godbolt.orgでホストされてるんだよね。同じものがcompliler-explorer.comにもあるけど、最初のドメインはもう引退させた方がいいんじゃない?リンクの劣化を防ぐために、名前のあるドメインにリダイレクトすればいいのに。

ほとんどの人は「Godbolt」って呼んでるからね。

俺を含めて、知ってるほとんどの人は「godbolt」って呼んでて、compiler explorerって言う人は少ないよ。他のどこでホストされてるかは知らなかった。

Compiler Explorerに行きたいときは、まず「godbolt」って打って、ブラウザが履歴から正しい項目を出してくれたらEnterを押すんだ。「compiler-explorer.com」って長いしね(全部打ちたい場合は)。

面白いことに、彼はポッドキャスト「Two’s complement」でこの問題について話してるんだよね。特に「The future of compiler explorer」ってエピソードで。下のコメント者たちが言ってる通り、彼の名前がこのツールと強く結びついてるってことだね。彼がプロジェクトに関わってることについて、面白いことをたくさん言ってるから、ここにソースを残しておこうと思った。

Godboltの名前はすごく象徴的で、$WORKではローカルホストのCompiler Explorerがgo/godboltショートカットの下にあるよ。

クライアントサイドをwasmでコンパイルするのはどう?完全に、または部分的に?実現可能かな?考えたことある?

彼らが使っているコンパイラの中には(msvc)、オープンソースでなくてwasmで動かすことができないものもある。全てのコンパイラツールチェーンをwasmに移植するのは、途方もない作業になるだろうね。

それは、各コンパイラをwasmにコンパイルすることを意味するけど、それがサポートされているかはわからない。さらに、コンパイルに必要なヘッダーファイルやその他のファイルを取得するための仮想ファイルシステムを作るという課題もある。追記:結果のバイナリを実行することもできないし。

ざっくり言うと:* 現在、Compiler Explorerのコストは月約3000ドル(AWS、監視、エラー用のSentry、Grafana、その他の経費込み)。 * セキュリティ/アイソレーションのためのnsjail * 3.9テラバイトのコンパイラ、ライブラリ、ツール * 最大30以上のEC2インスタンス(EC2インスタンスは仮想マシン) * 4,724のコンパイラバージョン * 保存されたショートリンク1,982,662件(最近では約14,000件のex-goo.glリンク) * 週に180万回のコンパイル もし計算が合ってれば、約3回のコンパイル/秒で、コストは1回のコンパイルあたり0.0004セント。面白いね。もし誰かがCompiler Explorerのコストの大まかな見積もりを聞いてきたら、少なくとも桁が違うって言っちゃうだろうな。重いCPU/I/O/ネットワークに依存してるに違いないし、これはクラウド利用にとって最悪のシナリオだよね。これとlichess(https://news.ycombinator.com/item?id=41922928#41928953)を見れば、かなりの負荷を安く処理できるってことがわかる。

$3,00015 そのカンマの位置、めっちゃ変だね。これが何の数字を表しているのかわからない(だって、月3ドルなんてありえないと思うし)。

彼らのEC2コストとその他のコストの内訳を見てみたいな。もし本当にやりたければ、単一のベアメタルマシンがかなりのコスト削減につながると思う。でも、月3000ドルは意外とスリムだね!

  1. あなたのブラウザがアセンブリをレンダリングして、「おお、このコンパイラは賢いな!」って思うんだ。違うよ。「おお、名前がぴったりなMr. Godboltはマジで凄い!」って思うんだ。

どれだけの開発者がCompiler Explorerを使ってるかは全然わからないんだ。追跡機能をわざと入れてないから。でも、少なくとも数千人はいると思う。これ、かなり少なく見積もってるよね :D

なんでそう言うの?サイトはブックマークしてるけど、使ったことはないんだ。コードがコンパイルできればそれで満足だから。アセンブリを掘り下げて1%のパフォーマンス向上を探す人はあんまりいないと思う。だから、このツールが役に立たないって言ってるわけじゃないけど、どのくらい使ってるの?

どれくらいコンパイラがクラッシュするのか気になるな。テストケースがめっちゃ多いね。

作者さんへ: コンパイラのビルドを公開する予定はあるの?

もうすでに無料で手に入るよ。「infra」リポジトリとce_installツールをチェックしてみて。あとはS3のURLをいじってみてもいいよ。