私がBEAM（Erlang VM）の本を書いた理由

 (happihacking.com)
3 ポイント 投稿者 GN⁺ 2025-06-05 | 1件のコメント | WhatsAppで共有
  • Klarna の中核システムを運用する中で得た実戦経験から、BEAM の15ミリ秒の停止が大規模な決済障害と緊急対応を引き起こした
  • BEAM について信頼できるリファレンスを作るため、10年にわたって本を書き続けた
  • 執筆の過程では、出版社の変更、技術的な問題、何度もの構成変更など、繰り返し挫折と再挑戦を経験した
  • オープンソース化後は、コミュニティのフィードバックと参加、スターの増加、励ましが継続的なモチベーションになった
  • 中核となる内容は BEAM VM の構造と運用 に焦点を当てており、実務エンジニアに実質的な助けとなる構成になっている

BEAM本を書いた動機

ポストモーテム、コーヒー、そして10年の執念

  • Klarna で中核決済システムを運用する中、BEAM のわずか15ミリ秒の停止が数百万件の決済失敗、深夜の緊急会議、CEO の呼び出しにまでつながる状況を繰り返し経験した
  • そうした危機を迅速に解決できる資料の不在が常に心残りであり、次のエンジニアがもっと早く問題を解決できるようにとの思いから The BEAM Book を執筆した

初期の執筆プロセス

始まりと挫折

  • 2012年10月、DocBook ファイル1つと大きな志でプロジェクトを始めた
  • 2週間のコミットの大半は構造作業とメタデータ更新に集中しており、実際の本文はごくわずかだった
  • 11月には AsciiDoc とカスタムビルドスクリプト に移行し、6か月での完成を期待したが、書き直しと構成変更が続き、進捗は非常に遅かった

出版社との協業

  • 2013年、O’Reilly と出版契約を結んだ後、Atlassian Atlas へ移行したが、ファイル消失や章管理の問題が続いた
  • Git の履歴は、不満と構成修正の連続で埋め尽くされている
  • 2015年3月には、ビルドを通すことだけを目的に、章を強制的に分割するなどの苦肉の策も試した
  • 2か月後、契約は静かに解消され、自己嫌悪と安堵が同時に訪れた
  • Pragmatic Bookshelf との2度目の試みも、進捗の遅さとともに中断された
広告

リセットとコミュニティ参加

  • 2017年1月、新しいリポジトリへ massive commit による全面移行（6622ファイル、100万行）が行われたが、書き直しも停滞した
  • 2017年3月、Asciidoctor ベースの非公開 GitHub リポジトリ で再出発し、必要な部分だけをコピーした
  • 2週間後に公開へ切り替えると同時に、外部コントリビューターによる typo 修正、図の追加、ライセンス協力 が活発に行われた

継続的なモチベーションの要素

  • 本質的には、BEAM が本当にどう動くのかを理解したいという個人的な好奇心と欲求が最大の原動力だった
  • コミュニティのフィードバックと提案が執筆意欲を高め、GitHub のスター数の増加が継続的なモチベーション効果を持った
  • “Please continue being awesome” に見られるような励ましの issueも、心理的な支えとして大きかった
  • Erlang や BEAM 関連の学会やカンファレンスで頻繁に引用されるようになり、本の必要性が証明された
  • Twitter などでも継続的な言及と共有が、執筆継続を後押しした

本の構成と主な対象読者

  • 自ら大規模 Erlang システムを設計・運用する中で本当に必要だった部分を中心に記述した
    • スケジューラとプロセス管理: 実運用負荷におけるプロセススケジューリング、優先順位、バランシングの原理
    • プロセスメモリ: ヒープ、スタック、メッセージ、バイナリの管理方式と運用への影響
    • ガベージコレクションとメモリモデル: プロセスごと／グローバル GC の動作方式、メモリリークと参照構造
    • データ表現体系: 整数、浮動小数点数、タプル、バイナリなどの内部タグ付け構造
    • コンパイラと VM の内部構造: コンパイル後に VM 内で実際に命令が実行される流れ
    • トレーシングとデバッグ: dbg、erlang:trace、メッセージやイベントの追跡など
    • 性能チューニング: 実コードのプロファイリング、遅延原因の分析、reduction の理解方法
    • システムアーキテクチャ: ERTS、BEAM VM、サブシステムの統合的な動作原理
  • Erlang/Elixir の実務運用者に非常に実践的な影響があり、散在した資料の代わりとなる信頼できる総合ガイドであることを主な目標としている

執筆プロセスで得た教訓

  • 粘り強さが完璧主義に勝つ。2度の出版中止を経験しても、「未完成のまま」よりは良いという結論に至った
  • 集中と境界設定が重要。執筆時間の確保、通知の遮断、厳格な時間管理が実際の進捗の源になった
  • 公開とフィードバックは質の向上の核心。外部からの校正と励まし、継続的な刺激が大きな助けになる
  • スコープ管理は不可欠。範囲を調整し、難しいテーマ（Dirty Scheduler、JIT など）は後の付録に回した
  • リリース後に反復改善する戦略が重要。BEAM は毎年変化し、生きた Git リポジトリとして継続的に補完できる
  • 本当の締切を設定することが実質的な動機になる。Code Beam Stockholm のイベント前に印刷するという締切が、必要な内容の選別を促した
広告

完成の定義

  • 実際に印刷版を手にした瞬間、ようやく「完成した」という感覚を持てた
  • 断片的なコミットが1冊の実体としてまとまり、現時点ではこれで終わりを宣言できる

参加方法

  • The BEAM Book 1.0 は現在 Amazon で紙の書籍として購入できる
  • 誤字や改善点を見つけた場合や内部構造に興味がある場合は、GitHub リポジトリで star、fork、issue 登録、pull request を活用できる
  • 実際のレビューのほうがアルゴリズムにより強く反映されるため、書評も積極的にお願いしたい
  • 実戦システム中心の BEAM internals ワークショップ も実施可能で、問い合わせは happi@happihacking.com までメールで連絡してほしい

関連記事

1件のコメント

 
GN⁺ 2025-06-05
Hacker Newsの意見

  • gitリポジトリはこちらで確認可能

  • BEAMをきちんと理解したくて掘り下げ続けてしまうという著者の動機が印象的。こういう情熱が素晴らしい成果物を生むのだと思う。なので即購入を決めた。自分の経験を言うと、出版社から何度も執筆の提案を受けたことはあるが、求める方向性が合わず実現したことはない。たとえば、自分は14歳向けのJava入門書は書きたくなかったし、出版社は自分が深く掘るテーマ（例: classloader）には関心がなかった。個人的な情熱と読者のニーズが交わる部分を、みんなどうやって見つけているのか気になる

    • 3冊書いた経験からすると、自費出版するか、出版社が望む本を書くかのどちらか。出版社ごとに求める本のカラーは違うし、初級者向け実用書に集中しているところが多いので、大衆的でないテーマを書きたいなら自費出版を準備するのが現実的。幸い今は自費出版が簡単になっていて、オンライン販売も可能。つまり、かなりニッチな市場を狙うテーマなら、出版社に期待せず自分で出版と宣伝を担うべきというのが現実
    • 本人が面白い話をしているなら、読者は最終的にそれを理解する方法を見つけるもの。キャリア初期にDon Boxの“Essential .Net”を読んだが、彼も特定の読者層を狙っていた感じではなかった。ただCLRの内部を深く掘り下げた本で、最初に完全に理解するには何度も読み返す必要があった
    • 出版社に必ず依存する必要があるのか、それとも自分で独立して本を書いてもいいのかについて悩む。出版社の名前や付随するメリットのためなのか気になる
    • 教えるという行為が最高の学習法だという点には同意する。高校時代に数学のチューターをして学んだし、本を書く経験も似ている。単なる理解を超えて、根本的な内容を自分のものにする最高の方法
    • 少し自慢っぽいけれど、自分もクライミング向けの筋力トレーニング本を、こうやって掘り下げた末に書くことになった。もともとは自費出版するつもりだったが、最終的には出版社を見つけて少し読みやすく修正した。出版社に直接アプローチしてみるのも一つの方法

  • BEAMとErlang/OTPを触った経験は、この1年で最も良かった開発体験の一つ。Joe Armstrongの“Programming Erlang: Software for a Concurrent World”を使ったが、初心者に強く勧めたい。“Designing for Scalability with Erlang/OTP”も評判が良いが、まだ手をつけられていない。ただ、深さという点では今回の本が圧倒的。BEAMは本当に古代文明が残した異星の技術みたい。ちょうど良いタイミングでこの本が出たので即購入。2度も出版中止になった後でも本を完成させてくれたErik Stenman博士に感心する

    • BEAM/Erlang/OTPでどんなソフトウェアを開発したのか気になる

  • ElixirとBEAMは、ネットワーク中心またはパイプラインの多いシステム構築で最有力の選択肢。何年もプロダクションで毎日使ってきたし、最近のプロジェクトでは選択が簡単ではないものの、継続して動向を追っている。この本の出版に感謝。数年前にプロダクションのElixirでデバッグしていたとき、まさに欲しかった本。既存資料は難しすぎるか、逆に単純すぎるかで物足りなかった

  • BEAM(Erlang virtual machine)の情報はWikipediaリンクで確認可能

    • 本のタイトルにすでにうまく説明されている

  • BEAMはオープンソース分野で最も過小評価されている技術の一つだと思う。例としてwhatsappがある。ElixirとErlangが高並行性プロジェクトでこれほど人気がない理由は謎

    • 自分の職場はErlang専門会社。Erlangの真価は、数百万DAUのような大規模トラフィックにある。Elixirで数千DAUのWebサイトを動かすことはできるが、ErlangとBEAMの本質はそのスケールにある。そういう規模が必要な会社は多くないし、さらに大きな問題はErlangのエコシステム自体がまるで別個のOSのように動くため、環境設定や構成要素がかなり複雑なこと。コンテナやk8sのような他のインフラ技術も不要で、むしろErlang独自のやり方のせいで馴染みにくく感じられる。ぴったり合う状況でErlangを経験すると、一種の魔法のように思える。自分のキャリアのハイライト
    • 結局はマーケティングの影響だと思う。Java、C#、Goは強力な企業支援があるが、Erlangはむしろ企業が足を引っ張るか、技術文書以外にはあまり気を配らない。Elixirは初めて別の言語的なマーケティング（Rubyモデル）に従ったが、参入時期と状況が違う。開発者はBEAMの優秀さに納得するだろうが、それ以外の意思決定者には訴求しにくいのだと思う
    • 投資の差が大きいと思う。Rust、Go、Pythonなどは企業支援によって静的解析、型チェック、開発者体験などに多くの投資が行われたが、Erlang界隈はこうした恩恵を十分に受けられなかったし、大口ユーザーも次第にBEAMの外で直接ソリューションを作るか、移行している
    • 私たちは最近、SquarespaceのWebサイトをPhoenixアプリケーションに置き換えたが、本当に楽しい体験だった
    • 同時に、最も秘密ではない「秘密のソース」でもある。最近はBBCもElixirに移行したので、徐々に人気も上がっていると感じる

  • “Erlang Runtime System(ERS)”は一般的なErlangランタイムを指し、“Erlang RunTime System(ERTS)”はEricsson実装に限定された表現だという説明が良い

    • その定義は別にばかげていないと思う

  • さっそく本を購入した。オンラインで無料で読めるが、少しでも著者を支援したくて購入した

  • Klarnaのような大規模システムをやっていないので実感しにくいが、15msの遅延がポストモーテム案件になるというのは不思議

    • BEAMではマイクロ秒(μs)単位の応答が普通なので、ミリ秒(ms)に跳ねたらすぐ警報が鳴ることもある
    • BEAMシステムではこういう状況は十分あり得る。共有状態を守るためにgen_serverを作ると、これは巨大なミューテックスのようなもの。gen_serverがリクエスト処理に20usかかるとすると、15msの遅延でメッセージキューには750件のメッセージが積み上がる。ここでメッセージキューを非効率なパターンで使うと性能が急落する。BEAMは特定のパターンに対してのみメッセージキューを最適化し、それ以外のパターンではキュー長に応じて処理時間が増える。ライブラリ内部で安全でないreceiveが使われると、予期しない性能低下が起こる。最近BEAMはメッセージキュー問題を補うalias機能を追加したが、多くのライブラリはまだ使っていない。aliasはメッセージ損失防止が目的で、タイムアウトメッセージでキューが汚染されるのを防ぐ。通常、長寿命プロセスはキューをループで回しながら処理する
    • 言及されていた出来事のポストモーテムへのリンクを知っている人がいれば気になる。オンラインでは見つからなかった

  • BEAMに似たVMがあるのか気になる。BEAMがあまりに優れていて競合がないのか、それとも同じくらい作るのが難しいのか知りたい

    • 現代のKubernetesインフラが提供する機能はBEAMと似ていると見ている。今はこうしたインフラで大規模なセルフヒーリングシステムを実装できるし、言語の制約もない。Erlang/Elixir以外にも多様なエコシステム、人材、関心領域がある
    • AtomVMという、IoTなど制約の大きいデバイス向けの別実装もある。BEAMやOTPを他のエコシステムで実装しようとした試みは多かったが、ほとんどはVMレベルではない
    • BEAMが90年代後半から2000年代初頭に登場した当時はかなり独特だった。今では実装方法が違うだけで、同じ問題を多様な言語とツールでうまく解決できる。Erlangコミュニティ特有の「BEAM方式こそ唯一の正解」という姿勢もあるが、2025年には本当に多くの選択肢がある。BEAM互換実装もあるが、たいていはニッチな領域。既存のBEAMインフラに参加する必要がないなら、グリーンフィールドのプロジェクトには現代のエコシステムにあるソリューションのほうが適していると思う。ergoのような小規模プロジェクトもある
    • Dis VMがおそらく最も近く、その次がSmalltalk VM。実際にはBEAMそのものより、OTPが載ることでBEAMが真価を発揮する
    • 実運用で最も近いのはおそらくGo。BEAMは「Erlang系言語」に最適化されたエコシステムで、ElixirやGleamもコア動作はErlangに近い。Goはgoroutineなど並行性においてErlang的なprimitiveを提供するが、OTPのようにアプリケーション構造について明確な見解は持っていない