BEAMはErlangとElixirの実行基盤となっている仮想マシンで、Bogdan/Bjorn's Erlang Abstract Machineの頭文字に由来します。1980年代にスウェーデンのエリクソン社で電話交換機向け言語として開発されたErlangの世代を経て、1990年代後半に当時のメンテナBogumil HausmanとBjörn Gustavssonが現在のBEAMを設計しました。1台のVM内で数十万から百万単位の軽量プロセスを並行動作させ、いずれかが落ちても他へ波及させない設計は、WhatsAppやDiscord、Riakといった大規模システムを支える実装基盤として広く知られています。
この記事の目次
- 軽量プロセスとメッセージパッシング
- Let it crashとスーパーバイザー階層
- ホットコードスワップと分散機能
- 得意分野と検討時の注意点
- まとめ
軽量プロセスとメッセージパッシング
BEAMの最大の特徴は、OSスレッドとは独立したスケジューラ管理の軽量プロセスを大量に走らせられる点です。プロセス1つあたりの初期メモリ消費は数百バイト程度で、必要に応じて自動的にヒープが拡張されます。プロセス間でデータを共有することはなく、すべての通信は非同期メッセージパッシングを介して行われるため、ロックやセマフォといった共有メモリ並行制御に伴う典型的なバグが構造的に発生しにくくなっています。この設計はAlan Kayが提唱したオブジェクト指向の原義に近い形で実装された並行モデルともいわれます。
スケジューラはCPUコア数だけ並走し、リダクションと呼ばれる仮想的な実行ステップ数を単位としてプロセスを公平に切り替えます。1プロセスがCPUを長時間専有することがないため、ソフトリアルタイム性が保たれ、応答時間のばらつきが小さく抑えられます。I/O待ちのプロセスはdirty schedulerと呼ばれる別系統に切り出される仕組みもあり、外部呼び出しがVM全体のレイテンシを破綻させないよう工夫されています。
Let it crashとスーパーバイザー階層
BEAM上での障害対応はLet it crashという思想に集約されます。想定外の状況に陥ったプロセスはその場で停止させ、上位のスーパーバイザープロセスが再起動戦略に従って新しいプロセスを起動し直すという形で、システム全体としての可用性を保ちます。スーパーバイザーはOTPと呼ばれる標準ライブラリ群に含まれ、one_for_one、one_for_all、rest_for_oneなどいくつかの再起動戦略を宣言的に定義できる構造になっています。
この設計は1980年代のエリクソンが電話交換機に求めた「九つの9」、つまり年間停止時間を30秒以下に抑える可用性要件から逆算して生まれた仕組みです。現代のクラウド環境でも、マイクロサービス内部のサブシステム単位で同じ思想を適用することで、ピンポイントの障害が全体ダウンに連鎖しない構造を作りやすくなります。ElixirのPhoenix LiveViewやBroadwayといったフレームワークも、内部的にはOTPスーパーバイザー階層に依存しており、開発者は明示的にツリーを設計するだけで運用に強い土台を得られます。
ホットコードスワップと分散機能
BEAMは稼働中のシステムにコードを差し替えるホットコードスワップを標準でサポートします。モジュールごとに最大2世代の実装を保持でき、新リクエストから新コードを使用しつつ、既存処理は旧コードのまま完了させるという段階的入れ替えが可能です。電話交換機を停止せずに機能改修を続ける必要から生まれた機能で、現代でも金融や通信のリリース時に活用されています。
分散機能もVM組込みで提供されており、複数ノードを名前で接続し、相互にプロセスを呼び出せます。ノード間通信は透過的で、ローカルプロセスへのメッセージ送信と同じ構文で別ノード上のプロセスへ送れるため、アプリケーションコードをほぼ書き換えずに分散システムへ拡張できます。ただし大量ノードを直結すると全結合トポロジが負荷源となるため、現代ではlibclusterなどのクラスタ管理ライブラリと組み合わせ、Kubernetesの環境変数を利用した自動結成が一般的になっています。
得意分野と検討時の注意点
BEAMが得意とするのは、大量の独立した接続を長時間維持するワークロードです。WhatsAppが2014年にFacebookへ買収された時点で、1サーバあたり200万コネクションをErlangで処理していたという事例は象徴的で、チャット、IoTゲートウェイ、リアルタイムゲームのプレゼンス管理など、コネクション指向のシステムで強みを発揮します。ElixirとPhoenixの登場以降は、Webバックエンド一般での採用も現実的な選択肢となりました。
一方で苦手分野もはっきりしています。数値計算や画像処理のような重い演算はBEAMのバイトコード解釈では十分な性能が出ないため、NIFと呼ばれるC言語拡張やNxといったTensor演算ライブラリを介して外部実装に委ねるのが一般的です。また、GC待ちが極端に厳しい超低遅延領域や、シングルスレッド純粋計算性能を最大化したい場面では、C++やRustといった選択肢のほうが適合します。BEAMを選ぶ際は「並行・分散・耐障害性」という強みが要件の中心にあるかどうかを最初に確認しておくと判断が安定します。
まとめ
BEAMは電話交換機の高可用性要件から逆算して設計された数少ない実行基盤で、軽量プロセス、メッセージパッシング、スーパーバイザー階層という三本柱が現代の分散システム設計に直接効きます。ErlangとElixirのどちらを選ぶ場合でも、BEAMという基盤の性質を理解しておくと運用設計が大きく安定します。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント