BEAMの本 なぜ私は書いたのか？
引用元：https://news.ycombinator.com/item?id=44179257
BEAMの本のGitHubリポジトリのリンクだよ。https://github.com/happi/theBeamBook
BEAMをちゃんと理解したくて書き続けたって話、超共感する！表面的な説明じゃなく、本質的なロジックを追うのって大事だよね。そういう情熱が素晴らしい成果につながるんだな。この本、その理由だけで買っちゃう。俺もこれまで何度も出版社から声かけられたけど、ニッチなテーマ（クラスローダーとか）だと話がまとまらなくてね。自分の好きなことと読者が求めてることの交差点、どうやって見つけるのかマジで知りたいわ。
出版社に頼る必要ってあるのかな？自分一人で書くのはダメなの？やっぱブランドとか他のメリットがあるからなのかな。
セルフ出版は前よりずっと簡単になったけど、Packtみたいなショボい出版社でさえ、すごいネットワークやマーケティング力があるんだよね。俺のスキルセットにはマーケティングとか、ターゲット読者がいるか調べることは含まれてないし。もし誰にも読まれない本を書くなら、ジャーナルやブログで十分だし。本は一大事業だから、誰も読まないのはさすがに凹むわ。
誰かStripe Press booksの次に来るような、協力型のセルフサービスみたいな仕組みを作るべきだね。
ちょっと宣伝になっちゃうけど、俺がクライミングのストレングストレーニングの本を書いたのも、まさにこの通り！興味があることをひたすら掘り下げていったんだ。最初はセルフ出版するつもりだったけど、興味を持ってくれる出版社が見つかってね。読みやすくするために多少の変更は必要だったけど、自分から出版社にアプローチしてみるのも案外いけるかもよ。
本を3冊書いた経験から言うとね、セルフ出版するか、出版社が求めるものを書くかだよ。出版社によって欲しがるものは違う。「21分で学ぶAI with Python」みたいなのが欲しいところもあれば、「Java Class Loadersの深くて暗い秘密」みたいなニッチなものが欲しいところもある。O’Reillyは技術的なニッチな分野には一番だね。他の多くの出版社は、部数が出る初心者向けを狙ってる。幸いセルフ出版はどんどん簡単になってるし、色々なサイトでオンライン販売も楽だから、タダで配る必要もない。でもまあ、これといった魔法の公式はないんだよ。もし本当にニッチなものを書きたいなら、出版社が興味を持ってくれるなんて期待しないこと。セルフ出版して自分でプロモーションする覚悟が必要だよ。
協力型／セルフサービス？それってどういう意味？
いや、よく分かんないんだけど、全体的な質を保つためにキュレーションは委員会がやるとか？でも、著者としては申請とか編集者、フィードバック、出版（これがセルフサービスの部分かな）がめっちゃ簡単、みたいな。正直一番大変なのはやっぱりマーケティングだよね。良い本って、文章だけじゃなくてカバーとかも大事だし。
それ、俺の経験と同じだわ。最近出した本（5冊目）なんて、出版社のミッションに95%ぐらい合ってたのに、結局見捨てられたんだ。その断られた後、もう他の出版社に当たる気力なんてなくて、自分でやったよ。最初はLeanPubで出して、それからAmazon（紙の本とKindle）、Apple、Kobo、Googleって広げていった感じ。
自己宣伝って言ってるけど、本の名前教えてよ。30年以上クライミングやってて、トレーニング方法の進化を見てきたから、あなたの詳しい本読んでみたいんだよね。
BEAMをちゃんと理解したくて書き続けたんだね。表面じゃなくて深いロジックを追うの大事だよね。教えるのが一番勉強になるってのはわかるよ。高校で数学教えてて実感したな。本を書くのも同じで、学んだことを書いて人に伝えるのが理解を深めるのに最高なんだよ。
昔の本は紙の時代で自己出版なんて無理だったな。今は商業的なの以外は自己出版考えるだろうね。自己出版でどれくらい売れたの？自分でマーケティングした？それともLeanPubとかAmazonに置いて、検索から来るの待っただけ？ニッチだと量は出ないけど、その市場の分は全部取りたいよね。
mainstreamよりはニッチかな。でもLinkedInとかにフォロワーたくさんいるし、数千人規模のメーリングリストや有料購読者もいるんだ。これで生活できるほどじゃないけど、ゼロじゃないよ。出版後のブログはほとんどこの本のサポートのためだし。5冊中2冊は出版社から出したけど、それはそれで勉強になって感謝してるよ。
出版社がやってくれるのは、マーケティングとリーチ
紙の本の金銭的リスク
編集とかの制作サービスだね。これらが自分でできるか、他の人に頼めるなら（例えばフリーランスのエディターを雇うとか）、自己出版の方が利益になるからいいんじゃないかな。
The Physiology of Climbingだよ。今週末にでも無料であげるから、フィードバックちょうだい！正直、具体的なトレーニング方法を教えるんじゃなくて、読者が自分で考えられる知識の基盤を与えたかったんだ。だからキャンパスボードやれじゃなくて、パワーは最大筋力とは別に鍛えるんだよ、みたいな説明にしたかったんだよね。
キュレーションは委員会で品質保ってるけど、著者は応募とかフィードバックとか出版が楽だって話、pragprog.comはそういう感じだね。僕はそこの委員だけど詳しいことは知らないや。でもpragprog.comで出した著者はみんな良い経験だって言ってたよ。元の記事の人は2回目の出版がうまくいかなかった理由を全然書いてなかったから、そこ詳しく知りたいな。
本の名前教えてもらえませんか？DMか返信で。お願いします！
確かに、キュレーションは出版物とかブランドにとって大事な機能だよね。元の記事の引用にあるように、委員会でやって全体的な品質を保ってるんだよ。
これってさ、日々の業務に集中する人と、そうじゃない人がいて、みんなが楽に協力できるビジネスモデルの話だよね。情報を広めるのが一番大変だけど、結局これって今の経済をもう一回作ったってことじゃん？
出版社と組む一番いいとこは編集者だと思うんだ。開発編集者、技術編集者、校正チームがいると本がマジで洗練されるし、レイアウトや印刷の細かい作業も自分でやらなくていい。
本によっては出版社の流通網がマジ役立つ。Barnes and Nobleとかで自分の本を棚から取れるの最高だし、信頼性も増す。
ただ経済的な理由だけで書いてるなら（おすすめしないけど）、少数の読者向けに自費出版しても、多数向けに出版社から出しても稼ぎはだいたい同じ。自費出版で読者を増やせれば比較にならないけどね。
出版社がAmazonからもっといい条件引き出せるか分かんないけど、AmazonのKindle Direct Publishingって、$9.99超えると電子書籍のロイヤリティ率が70%から30%に下がるのが嫌なんだよね。$19.99で売りたい技術書とかだとすごくやりにくい。
あと、著作権侵害もひどいし、Amazonはあまり対策してない。出版社の方が対策するリソースあるんじゃないかな、たぶん。
自分は何か知ってるって思い込みやすいけど、実際は表面的な理解だけで内部を本当に分かってないことってよくある。serializationのプロセスが宙ぶらりんのポインタを暴き出すんだ。
普通の人は”トイレの仕組み”を知ってるつもり。水が入って貯水槽満たし、レバー引くと便器に流れ、排水溝に流れるって。
でも詳しく説明って聞くと、貯水槽が溢れない仕組みとか、常に水が漏れない仕組みとか、溢れず排水もされずに流せる仕組みとか、実は知らないって気づくんだ。
＞ 1. マーケティングとリーチ
理論上はそうだけど専門知識は少ないかも。技術書の場合、出版社の編集者は実際技術者じゃない。昔はそうでも今のプログラマーに何が重要か現役エンジニアみたいには分かってないんだ。
＞ 2. 紙媒体の経済的リスク
print-on-demand前はリスクあったけど今はそんなにない。オフセット印刷が高品質って議論もあるけど、俺のAmazon PODより印刷品質悪い大手教科書あるし。
＞ 3. 制作サービス（編集とかアートワーク）
これはマジ超重要、同意。でも外部委託多いし、自分でフリーランサー見つけられるなら、大した価値は加えないよ。
ブログ記事によると、著者は出版が遅れて複数の出版社に断られちゃったんだって。それで、本をオープンソースにして、自分で出したんだよ。
去年BEAMでErlang/OTPを学んだのは最高の経験だったよ。”Programming Erlang”（初心者におすすめ）や”Designing for Scalability with Erlang/OTP”も聞いたけど、深さは今回の本がダントツ！
BEAMってホント、エイリアンテックみたいで、この本のタイミングは最高だったね。すぐに買ったよ。Dr. Erik Stenmanさん、2回キャンセルされたのに続けてくれてありがとう！
今のところほとんどおもちゃのプロジェクトだけどね。一番複雑なのは（開発中の）MMOゲームのバックエンド（https://github.com/Dr-Nekoma/lyceum）かな。あとは自分で書いた便利なライブラリがいくつかあるよ（https://github.com/dont-rely-on-nulls/migraterl）。
BEAMってオープンソースの中でも一番過小評価されてる技術かもね。例はWhatsApp。
ElixirとErlangが高並行なプロジェクトでもっと人気が出ないのがマジで謎だよ。
＞なぜElixirとErlangが高並行プロジェクトで人気がないのか謎だ
Erlangの会社で働いてるけど、役に立つのは大規模スケール、何百万DAUとか必要だからだよ。BEAMは独特のOSみたいで、ERTS、epmd、Rebarとか設定がマジ複雑。（IMHO）コンテナとかk8sもErlang独自のやり方でやってるからいらないか、使うべきじゃない。適切なユースケースで動いてるのを見ると、ホント黒魔術みたい。これで働けたのはキャリアのハイライトだったね。
＞なぜElixirとErlangが高並行プロジェクトで人気がないのか謎だ
1) 普通の言語でも一台でかなり高並行を扱えるようになってきた。
2) BEAMの実装が長らく一つしかなく、ドキュメントもほぼ無くて移植がめっちゃ大変だった。
3) マジックはErlangじゃなくてOTPだよ。それに考え方を変える必要があるし、OTPの抽象化は他の言語でもできる！
4) ScalaがErlangの人気を奪ったと思う。Erlangは今頑張ってるね。
もっとコメントを表示（1）
1.そうだね、でもOTPって唯一マトモな並行処理フレームワークだよ。なんでみんな真似しないのか未だにわかんない。
2.そうだね。
3.OTPの抽象化をやってて、特にグリーンレッドのプリエンプティブスケジューラまで実装してる言語は知らないな。
4.ありうるけど、ScalaとErlangで悩んでる会社は見たことないかも。
正直、マーケティングが一番の理由だと思う。Joseはポーランドに住んでてめっちゃ活動的だったから、Rubyの会社がたくさんElixirに移ったんだよ。
あと、去年Gleamが1.0を超えて、BEAMは関数型プログラミングの”フレーバー”も色々選べるようになったよ。Erlang/OTP（30年近く戦場で試されたエイリアンテック！）、Web開発がすごいElixir、MLっぽい言語が好きならGleam。BEAMネイティブのLISPならLFEも良いね。
Elixir Liveviewを使ってみたけど、環境構築が超大変でDockerが必須だったんだ。開発環境と本番環境で全然合わなくて、Dockerじゃないとクリーンな環境を作れなかった。
結局、資金が尽きてプロジェクトはダメになっちゃって、Elixirのセットアップがわかる人もいなくなって、今じゃデモするのすら無理。環境設定がちょっとでも違うとエラー吐きまくるからさ。
環境構築の難しさで言えば、Pythonより難しい言語はこれくらいかも（まぁ、Gradleとかモバイル開発系は論外だけど）。PythonならminicondaとかvenvでDockerなしでも大体いけるのに。
Node, NPMも面倒だけど、エラーと格闘すればいつかは動く。俺の経験だと、バックエンドはPHPかPerlかC、フロントは素のJavaScriptかElmって感じだけど、そっちの方が何十年って単位で見るとメンテナンスしやすい気がするね。
Elixir Liveviewのいい点を言えば、めちゃくちゃスムーズなSPAが作れたこと。使う側からしたらすごく使いやすくて見た目も最高だったんだけど、根本のメンテナンスが一番キツかった。
GleamにOTPがあればいいのにって、マジ思うわ！
Elixirも最近は新しい言語サーバーとか、すごくありがたい型チェックとか、ツール類が充実してきてるね。
Elixirって、始める上でのとっつきにくさをかなり和らげてくれてるし、「あれ？なんでこうなるの？」みたいな変な挙動（「ごっちゃ」って言うらしい）もほんの少ししかないんだよ。関数に引数を渡す時に値が書き換わらない（イミュータブル）ってのは、他の言語から来ると戸惑うかもだけど、正直それは「主流」って言われてる言語の方の問題なんじゃない？
俺から言わせてもらうと、BEAMってのは一つのスタックで色んなもの（インフラ、プロセス再起動、キャッシュ、キュー、DBとか）を全部やろうとしすぎて、あちこちから色々漏れてる感じがするんだ。Erlangとしか動かないから、「全部乗るか、何も乗らないか」みたいなセットアップになって、すごく制限が多いと思う。
KubernetesとかはBEAMがやってることの多くを、もっと上手に、しかもどの言語でもできるようにやってる。Erlangの中に組み込まれてるキューやDBもあるけど、業界標準のものと比べると劣るし、やっぱりErlangでしか使えないのがネック。
Elixirはね、少なくともここ5、6年はセットアップとか設定、デプロイが結構簡単だったよ。Erlangについては分かんないけどさ。
無知でごめんね、これってGleamのOTPのことじゃないの？
https://github.com/gleam-lang/otp
C++とそのライブラリを使えば、Erlangができる並行処理の全てを、もっと速くできるんだよ。それがErlangが今でもニッチな分野に留まってる一番の理由じゃないかな。
たぶんこれって純粋にマーケティングの問題だと思うんだよね。
他の言語（Java, C#, Goとか）は巨大な企業がバックについてて、成功させようと必死じゃん。Erlangの元々の持ち主だった会社は、むしろ最初潰そうとしたし、それ以降も技術情報以外には冷たい感じだった。
Elixirが出てくる2014年まで、そんなに派手なマーケティング資料なんて見なかったし、ElixirもRuby方式（開発者向けアピール）だけど、2004年のRailsが出てきた時代とは全然状況が違うんだよ。
開発者はBEAM系の良さを理解できることが多いけど、派手な見せ方がないと、MBA層みたいな決定権を持ってる人たちを説得するのが難しいんだと思う。
ごめん、無知で聞くんだけど、これってGleamのOTPのことじゃないの？
https://github.com/gleam-lang/otp
Erlangを選ぶ規模の会社なんて少ないんだよ。多くの人がこの現実を受け入れてくれたらなって思うんだ。
小規模でもErlangはすごく良かったよ。IoTとかクラウドに使ったんだけど、supervisor treeの自己修復機能で超安定。k8sみたいに複雑な設定もいらなかったしね。
いろんな言語でErlangみたいなプロセス作ろうとしてるけど、結局本家のErlangプロセスには敵わないんだよね。やっぱすごいよ。
Erlangは90年代後半までOSSじゃなかったし、あんまり宣伝もされなかった。Elixirはすぐ出てきたね。ErlangとElixirが良いのは、他の言語みたいに並行処理が後付けじゃなくて最初から考えられてるところだよ。
OTPもすごいけど、BEAMがたくさんのプロセスをうまく捌ける能力もヤバいよね。どっちも魔法みたい。
何でも好きなもので作れるけど、それがいつも正解とは限らないんだ。C++で直接Webアプリ作る人が少ないのには、ちゃんと理由があるんだよ。
みんな最高のエンジニア雇いたいって言うけど、結局は一番レベル低い人に合わせちゃうんだよ。「数週間で新しい言語覚えられないバカなエンジニア雇っちゃったらどうすんの？」とかさ、延々そんな感じ。
俺も「投資ギャップ」って思うよ。RustとかGo、Pythonとかには超デカい後ろ盾がいて、静的解析とか型チェック、開発者の使いやすさにめっちゃ投資してるじゃん。でもErlangのエコシステムにはそういう愛があんまりなくて、デカいユーザーは他の技術に移ったり、BEAMの外で何か作ったりしがち。
正直、色々な機能が混ざってるのが一番のメリットだね、少なくとも俺にとっては。Erlangは人気争いには負けたけど、これ（俺の場合はElixir）を使うと、フロント、バックエンド、DB、キャッシュ、サービスディスカバリ、負荷分散、コンテナ化、オーケストレーションなんかを全部別々のツールでやるのが当たり前じゃない、並行世界に来たみたいなんだ。本当は全部一つのランタイムに組み込まれたプラットフォームに行けたかもしれないのにね。Erlangを説明するなら、「DjangoをGunicornで動かすPythonの競合じゃなくて、Linux上でKubernetesのDockerコンテナで動き、サービスメッシュ経由で通信して、ディスクに永続化されたRedisにデータを保存する、Python+Django+Gunicornの全部の競合」って感じかな。多くの点で、このスタックの一番上だけErlangに置き換えても、前より悪くなるだけだよ。
悲しいことに、Erlangルネサンスはコンテナ化＋オーケストレーション＋分散システムのブームより数年遅かったから、どれだけ良かったか（悪かったか）はもう分からないな。まあ、C’est la vie（人生ってそんなもんさ）。
昨日SquarespaceのウェブサイトをPhoenixアプリに置き換えたんだけど、めっちゃ快適だったよ！
”Elixirは過去5～6年くらい、設定もデプロイもかなり簡単だった”って言う兄弟コメントがいたと思ったら、”Elixirは環境構築、Pythonより難しい唯一の言語だった”って言う人もいて、この違いはすごいね。どっちの言ってることも間違ってないんだろうけど、文字通り（この書き込み時点で）隣同士にあるこの対比を見るのは面白い。
Nix（オプションでNixOS）みたいなものが、全部の部品のドキュメント化とか連携に役立つのかな？
どんな環境問題に困ってたの？うちはmise/asdfを使ってErlang/Elixirのバージョン管理してるよ。DBだけメンテナンス楽にするためにコンテナ化した。
開発体験なら、公式が出るまでElixir LSよりNextLS/Lexicalをおすすめする。そこそこ規模のあるElixirアプリならコンパイルがずっと速いはずだよ。
https://elixir-lang.org/blog/2024/08/15/welcome-elixir-langu…
うん、でもGleamはErlangの実装をラップしてるんじゃなくて、OTPを自分で実装してるから、まだ”ベータ”段階だと思う。有名なActorアーキテクチャを使うには、Gleamでotpパッケージをインポートしないといけないんだ。
「Erlang Runtime Systemという言葉は、Ericssonによる特定の実装であるErlang RunTime Systemまたは通常ERTSと対比して、あらゆるErlang Runtime Systemという一般的な考え方を指すために使おうと思う」って定義、いいね！
ElixirとBEAMは、ネットワーク系とかパイプライン処理が多いシステムを作るのに、俺の歴代で一番好きな選択肢だよ。プロダクションで何年も毎日使ってた。最近のプロジェクトには売り込みにくい（だいたい間違った判断になる）けど、できるだけ追いかけるのは楽しんでる。
この本を書いてくれてありがとう！数年前、プロダクションのElixirをデバッグしてた時に、これが本当に欲しかったんだ。既存の学習資料は難解で退屈だったり（か、簡単すぎて浅かったり）したから。
Klarnaみたいな規模の仕事をしたことはないけど、15msでポストモーテム（事後検証）のイベントになるって、すごく短い時間だね！
うん、小さく見えるけど、BEAMって普通マイクロ秒で動くんだよ。それがミリ秒に「吹っ飛ぶ」と、そりゃ警告が出るのも無理ないよね。
数百万回の呼び出しで、1回あたり15ミリ秒余計にかかるってなると、マイクロ秒で調整されたシステムは壮大に詰まるよ。負荷が増えなくても、キューは何千倍も長くなっちゃうんだから。
もっとコメントを表示（2）
このやり取りを見て、システムが使う「自然な」単位でメトリクスを報告するのがいかに大事か改めて思ったよ。慣れてない人でも直感的に規模感が掴めるし、単位変換が苦手な人にも優しい。プロでも混乱を防げるしね。
BEAMシステムだとこれ簡単に起きるんだ。例えば共有状態にアクセスしたい時、それを保護するためにgen_serverを作る。これは巨大なmutexみたいなもん。gen_serverはメッセージキューに来たリクエストを処理する普通のBEAMプロセスなんだ。通常20マイクロ秒で処理できるとしよう。15ミリ秒一時停止すると、メッセージキューに750件溜まっちゃう。これだけだと大障害にならないかもだけど、処理の中でメッセージキューを「unsafe」な方法で使ってると、BEAMは一致するメッセージを探すためにキュー全体を検索しちゃうんだ。特定のパターン（gen rpcスタイルとか）は最適化されるけど、unsafeなパターンでキューにバックログができると、システムのスループットは破壊されるよ。なぜなら、メッセージ処理時間はキューの長さに依存し、キュー長はメッセージ処理時間に依存するから。
さらにたちが悪いのは、コードに明示的な｀receive｀ステートメントがなくても、ライブラリがunsafeなreceiveを使ってたら燃えちゃうこと。BEAMは代替のメッセージキュー機能「alias」（https://www.erlang.org/doc/system/ref_man_processes.html#pro…）も追加したんだけど、多くのライブラリはまだ使ってないみたい。これはキューを「lost」メッセージから守るもので、aliasがないとタイムアウトでプロセスメールボックスが処理されないメッセージで汚染されて、大きなキューがスループット低下を引き起こす問題につながることがあるんだ。ただし、通常、長期間稼働するプロセスはキューのメッセージを処理するループを持ってるよ。
＞通常20マイクロ秒で処理できるとしよう。
じゃあ、OSとかスレッドがハングしたら？ハードウェアの問題とかでも？クリティカルパスが単一のmutexでブロックされるのは、問題のレシピに見えるんだけど、何か見落としてる？
ハードウェアの問題は起きるけど、単純な故障なら復旧早い。厄介なのはNICキューの一部が止まるとか、ECCエラー多発でCPU容量が激減するとか、システムは遅いのに接続を維持してトラフィックを引き付けちゃう場合だね。でもOSやスレッドのハングは経験上避けられる。BEAMシステムをOSプロセス数少なく運用すれば問題起こりにくい。15ミリ秒の一時停止の話に戻ると、それは連鎖的な停止の原因か結果か中間かもしれない。何か遅くなると他も遅くなるし、バックログが閾値を超えると回復できないプロセスもある。WhatsAppではこれに対処するためにいくつかハックがあったよ。A) gen_server集約フレームワークで、ハック版の優先度メッセージを使ってワーカーがリクエストの古さを判定してドロップする。B) イントロスペクション機能でプロセスのメールボックスにあるメッセージを全部ドロップするハックがあって、時々cronで自動化してた… 100万件とかメールボックスにあると処理しきれないから、全部ドロップするのが回復への最速経路だったんだ。C) メールボックスがすごく大きいときはガーベージコレクションの実行頻度を減らすように調整した—これは今off-heap mailboxesで対処されてると思うけど、GCがメールボックスを何度もチェックして、それがすごく大きいと、最終的にGC時間がスループットを上回って追いつけなくなる回復不能なサイクルを引き起こすことがあったんだ。D) プロセス統計を追加して、蓄積・排出率を見て、排出にかかる時間を推定したり、プロセスが排出できないか監視したりできるようにしたよ。
＞cronで自動化してた…
メールボックスのメッセージ全部ドロップするとどうなるの？遅い速度で処理されるの？それとも裏で処理されるの？それとも全部ポイしちゃうの？情報失われるのって良くない気がするんだけど。詳しく知りたいな！
Nuked（消去）さ、それが唯一の確実な方法なんだ。キューにあるメッセージを気にしなかったわけじゃなくて、多すぎて処理できないからゴミ箱行きなんだ。この戦略はリードには有効だけど、ライトにはあまり向かない。あと、mnesiaプロセスのキューはバックログが酷くても捨てちゃダメだよ…そういうやつにはバックプレッシャーをかける方法を見つけないと—例えば、大量のキューに送られる前にライトでエラーを出すフラグとかね。主にこれはリクエスト/レスポンスの文脈で起きてるんだ。クライアントとしてフロントエンドに接続して認証BLOBを送ると、フロントエンドはそれを認証デーモンに送ってチェックしてもらう。もし認証デーモンが合理的な時間内にフロントエンドに応答できない場合、フロントエンドはクライアントを切断しちゃうんだ。だから、認証デーモンが古いメッセージを見ても意味がない。バックログが溜まりすぎて回復できなくなったら、我々の失敗でクライアントは接続に問題抱えてるわけだけど、回復への最速経路は現在進行中のリクエストを全部捨てて新しく始めることなんだ。シナリオによっては、プロセスがバックログを認識してて、メッセージを一つずつ受け入れてドロップしようとしても、バックログに追いつくほど速くないこともある。回復不能なバックログにいる時間が長ければ長いほど、バックログは悪化するんだ。だって、クライアントが起きてくる通常負荷に加えて、試して失敗したクライアント全部がリトライしてくるからね。障害が十分長ければ、クライアントが接続できなくて、他のクライアントを起こすようなメッセージを送らなくなるから、負荷が少し落ちる効果はあるけど、それが起こるのは一部のシャードで大きなバックログを抱えてるだけだと、そんなに大きくないんだ。
ユーザー側のクライアントがちゃんと作られてたら、ユーザーかクライアント自身がアクションが効かなかったことに気づいて、また試すもんだよ。電話が予期せず切れたり、クリックしたボタンが反応しなかったりした時に多くの人がやるみたいにね。多くの場合、一部のトラフィックが無駄になっても大した問題じゃないんだ。正確に全部を正しい順序で処理しようと必死になって、結果として全ユーザーのサービスを低下させたり、システム全体をダウンさせたりするよりはマシだよ。
何をしたいかによるけど、ブロックが起きる場所を変える方法もあるよ。例えば、こういう記事が参考になるかもね: https://blog.sequinstream.com/genserver-reply-dont-call-us-w…
BEAMの並行処理はgen_server (実質mutex) とかETSテーブル (https://www.erlang.org/doc/apps/stdlib/ets) くらいしか良い方法がないのが問題の一部だね。だから、可能ならETS (他の言語でいうConcurrentHashMapみたいなやつ) を使うか、共有状態をシャーディング／レプリケーションして並列アクセスするのが普通の解決策だと思うよ。あんまり変わらない読み取り専用データにはpersistent term (https://www.erlang.org/doc/apps/erts/persistent_term.html) っていうのもあるよ。
＞ BEAMシステムでは簡単だ
ちょっと待って… Erlangで書けば勝手にスケールすると思ってたんだけど！
Erlangを使うと、たくさんの難しいことが可能になり、トリッキーなことが簡単になり、簡単なことがトリッキーになるんだ。
魔法の粉なんてないよ。うまく使えばいい感じに組み合うものがたくさんあるだけで、システムを予測する方法を学んでいれば予測可能な形で壊れるだけさ。
すぐ買っちゃった。オンラインで無料で読めても、こうすれば作者を少しサポートできるかなと思って。
＞ Issue #113 - “これからも最高でいてください。” 絵文字入りの、通りすがりの励まし（2018年8月）は、モチベーションが落ちるたびに今でも頭に浮かぶよ。
これ、心が温まるね。インターネットはネガティブなことや人を惨めにするって悪名高いけど、こんな小さなポジティブな瞬間でも、長く影響を与えて何年も記憶に残るんだね。
これは自分の人生にも応用できるよ。誰かが良いことをしたら、大げさにせず伝えるんだ。ほとんどの人は感謝して、やる気が出るかも。シンプルだけどやらない人が多いね。もちろん頻度で価値は下がるから、本物であること、やりすぎないことが大事。GitHubでスター、Issue trackerで👍、HNでアップボートとか簡単なことが良いものが続く原動力になるんだ。
僕はGitHubでOSSをメンテしてるんだけど、コードを使った人から時々連絡が来るのは、いつもその日のハイライトだよ。
