【入門編】HHVMのコードキャッシュ（Repo Authoritative Mode）の仕組みと運用上の注意点 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

こんにちは！Hack言語の世界へようこそ。
他の言語からHackを学び始めると、「PHPによく似ているのに、なぜこんなにも厳格なんだろう？」と驚く瞬間がたくさんありますよね。でも、その厳格さの裏側にある「HHVM（HipHop Virtual Machine）の圧倒的な爆速エンジン」の仕組みを知ると、Hackを書くのが何倍も楽しくなりますよ。

今回は、本番環境運用では避けて通れない「Repo Authoritative Mode（リポジトリ権限モード）」と、その心臓部である「コードキャッシュ」の仕組みについて、裏側のアーキテクチャまで深掘りしていきましょう。

ここをクリアすれば、あなたもHackの本番運用におけるエリートエンジニアの仲間入りです。一緒にバッチリマスターしていきましょう！

—

1. そもそもHHVMとコードキャッシュはどう動いているのか？

通常の開発環境（デバッグモード）では、HHVMは私たちが書いたHackのソースコード（`.hack` や `.php`）をその場で読み込み、バイトコードにコンパイルして実行しています。これはいわゆる「JIT（Just-In-Time）コンパイル」の恩恵を受ける動的な挙動ですが、ファイル変更の監視や動的な解釈のために、どうしてもオーバーヘッドが生じます。

しかし、トラフィックが爆発する本番環境では、そんな無駄なオーバーヘッドは許されません。そこで登場するのが、Repo Authoritative Modeです。

概念図：Repo Authoritative Modeのイメージ

[ 開発時の世界 ]
ソースコード (.hack) ──> HHVMが毎回動的に解釈・JIT ──> 実行 (少し遅い・柔軟)

[ 本番時の世界 (Repo Authoritative Mode) ]
ソースコード (.hack) ──事前コンパイル──> 単一の巨大バイナリ (hhbc) ──> HHVMのメモリ直結 (爆速・イミュータブル)

本番環境では、デプロイのビルドプロセスにおいて、すべてのソースコードを事前にHHVM用のバイトコード（HHBC）にコンパイルし、一つの巨大な「HHBCリポジトリファイル（通常は `hhvm.hhbc`）」にまとめ上げます。

HHVMはこのファイルを起動時にメモリへ直接マッピング（mmap）し、ディスクへのファイルアクセスや動的なパース処理を完全に排除して実行します。これが、Hackが他の動的言語の追随を許さない圧倒的なスループット叩き出せる秘密です。

—

2. 実際の運用：リポジトリのビルドと設定

Repo Authoritative Modeを有効にするには、HHVMの起動オプション（`server.repo.authoritative = true`）を設定し、事前にビルドしたバイトコードファイルを指定します。

ステップ1: バイトコードの事前コンパイル（ビルド時）

CI/CDパイプラインの中では、以下のようなコマンドでソースコードをバイトコードに変換します。

ソースコードをコンパイルして、hhvm.hhbcというバイナリを生成する
hhvm –hphp -v All.NoFC=true \
-t hhbc \
-o /var/www/releases/v1.0/hhvm.hhbc \
— \
-3 /var/www/releases/v1.0/src/

ステップ2: 本番用設定ファイル（config.hdf または .ini）

本番サーバーのHHVM設定では、このファイルを読み込むように厳格に指定します。

; config.hdf (または .ini) の設定例
hhvm.server.port = 8080
hhvm.repo.authoritative = true
hhvm.repo.central.path = /var/www/releases/v1.0/hhvm.hhbc

このモードに入ると、HHVMは「ファイルシステム上に新しいPHP/Hackファイルが存在しても、完全に無視する」ようになります。セキュリティ面でも、実行中のコードが後から書き換えられるリスク（ファイルインジェクション等）を物理的にシャットアウトできるため、非常に堅牢です。

—

3. 陥りやすい罠：「あれ、コードを直したのに反映されない！？」

Repo Authoritative Modeを導入した開発現場で、もっともよくある初心者のミス（そして絶望ポイント）がこれです。

> 「GitHubのコードを修正して `git pull` したのに、何度アクセスしても古い挙動のままなんです……！」

なぜこの現象が起きるのか？

先ほど説明した通り、Repo Authoritative Modeが有効なHHVMは、ディスク上の `.hack` ファイルを一切見に行っていません。見ているのは、ビルド時に固められた `hhvm.hhbc` というバイナリだけです。

そのため、単にソースコードを上書きしただけでは、HHVMは古いバイトコードをメモリ上で実行し続けます。

正しいデプロイメントの作法（ゼロ・ダウンタイム・デプロイ）

Hackの本番環境では、ファイル単位の更新ではなく、「アトミックな（不可分の）ビルドと切り替え」が必要です。

1. 新しいリビジョンを別のディレクトリにチェックアウトする。
2. その場で `hhvm –hphp` を実行し、新しい `hhvm.hhbc` を生成する。
3. HHVMプロセス、またはシンボリックリンクを新しいリビジョンへと安全に切り替える（グレースフルリスタート）。

この一連の流れを自動化しておくことが、Hackマスターへの第一歩です。

—

4. Hack型システムとRepo Authoritative Modeの相乗効果

ここで少し、Hackの厳格な静的型システムの話をしましょう。
Hackには、次のような強力な型チェックの仕組みがあります。

<<__EntryPoint>>
async function main_async(): Awaitable {
// 厳格な型チェックがコンパイル時に完了している
$userId = 42;
C\echo(get_user_greeting($userId));
}

function get_user_greeting(int $id): string {
return “Hello, Hack User #”.$id;
}

通常の言語では、こうした型や関数の依存関係を、リクエストが来るたびにエンジンがパースして解決しようとします。しかし、Repo Authoritative Modeを使っているHHVMでは、すべての型の整合性チェックや最適化が「ビルド時」に完全に解決された状態でバイナリに焼き込まれています。

そのため、本番環境のリクエスト処理においては、型の検証コストが実質「ゼロ」になり、C++やRustのコンパイル済みバイナリに匹敵する極限のパフォーマンスを発揮できるのです。

—

まとめ

いかがでしたでしょうか？今回はHHVMの裏側を支える「Repo Authoritative Mode」とコードキャッシュの仕組みについて解説しました。

Repo Authoritative Mode は、本番環境でディスク上のコードを無視し、事前コンパイルされた `hhvm.hhbc` を直接メモリにマッピングする爆速運用モードである。
デプロイ時は、単なるファイルの更新ではなく、バイトコードの再ビルドとアトミックな切り替えが必要不可欠。
この仕組みを理解することで、Hackの厳格な型システムが「なぜこれほどまでに速いのか」の本質が見えてくる。

ここをしっかりと押さえておけば、大規模なトラフィックを捌くHack製Webアプリケーションの運用も怖くありません。
明日からの開発やデプロイ設計に、ぜひこの知見を活かしてくださいね。あなたのHackライフを、これからも応援しています！