概要
- 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-builder、 clang-builder、 misc-builder 等で多様なビルドに対応
- ビルド・インストールのタイミングは「有機的」に運用、今後の改善課題
- 4,724バージョン ・ 81言語 対応のビジュアル化もAPI経由で動的生成
Windows/ARM/GPU対応
- Linux x86-64 だけでなく、 Windows(MSVC)、 ARM64、 NVIDIA GPU にも対応
- WindowsはLinux中心インフラとの統合に苦労、セキュリティ知見も強化中
- ARMはネイティブ実行、GPUはNVIDIA協力でドライバ・ツールチェーン整備
- すべて AWS us-east-1リージョン で運用
- 地理的な遅延は CloudFrontエッジキャッシュ で一部緩和
モニタリングとコスト管理
- Grafana agent、 Prometheus、 Loki、 CloudWatch で可視化・監視
- パブリックダッシュボード でリアルタイム統計公開
- コスト圧縮は課題、 スポットインスタンス や多層キャッシュ(ブラウザ・インスタンスLRU・S3)で効率化
- 月額コストはおよそ 3,000ドル、Patreon・GitHubスポンサー・法人スポンサーの支援で運営
今後の展望
- 現行システムは課題解決の積み重ね で進化
- nsjail導入は攻撃対策
- 毎晩ビルドは手動更新の負担軽減
- マルチアーキテクチャ対応はユーザ要望に応じた拡張
- 今後も「使いやすさ」「安全性」「拡張性」を追求
備考 本記事はLLM支援のもとで執筆されました。詳細は末尾参照。