🦖 🌻 👨🏾‍🚀 Zen Erlang [およびElixir-約翻訳者] 🍑 👹 🐩

翻訳者からの紹介

この記事ではErlangについて説明しますが、同じBEAM仮想マシン上で動作する関数型言語であるElixirについても同様に適用できます。 2012年に登場し、現在積極的に開発中です。 Elixirは、Erlangの利点を保持しながら、最も使い慣れた構文に加えて、広範なメタプログラミング機能を取得しました。

翻訳者の詳細

2016年の記事ですが、有効期限のない基本的な概念に関するものです。

私（翻訳者）からの概念とコメントへの参照は角括弧[]

あり、「翻訳者のメモ」でマークされています。

翻訳の一部が、特に用語に関して十分に正しくない場合、またはその他のエラーが発生した場合はお知らせください。喜んで修正します。

テキストの校正と編集にご協力いただいたJan Gravshinに感謝します。

これはGenetecが主催するConnectDev'16カンファレンスでの私のプレゼンテーションの無料のトランスクリプト（または長い言い換え？）です。

001

ここのほとんどの人はErlangでプログラミングしたことがないと思います。聞いたことがあるか、名前を知っているかもしれません。したがって、私のプレゼンテーションはErlangの高レベルの概念にのみ影響し、この言語に出会ったことがない場合でも、仕事やサイドプロジェクトで役立つようになります。

002

アーランに興味を持ったことがあるなら、「クラッシュさせよう」というモットーについて聞いたことがあります。 翻訳者 ]。彼との最初の出会いは、それが一体何なのかと思いました。 Erlangはマルチスレッド実行とフォールトトレランスに優れているはずでしたが、ここではすべてを落とすことを提案します。私が本当に望むシステムの動作の正反対です。この提案は驚くべきことですが、それにもかかわらず、アーランの禅はそれに直接関係しています。

003

ある意味では、Erlangに「Let it Crash」を使用することは、「Blow it up」[ 「 Blow it ！」と同じくらい楽しいです。 -約 翻訳者 ]ロケット科学用。「爆破」はロケット科学でおそらく最後に望むことであり、チャレンジャーの大惨事はこれを鮮明に思い出させます。一方、状況を異なる視点で見ると、ロケットとその推進システム全体が爆発する可能性のある危険な燃料を扱っています（そしてこれは危険な瞬間です）が、宇宙を整理するために使用できるような制御された方法でペイロードを軌道に移動または送信します。

そして、ここでのポイントは実際に制御されています。ロケットサイエンスを、爆発または少なくともそのパワーを適切に制御して、必要な処理を行う方法として検討することができます。次に、同じ角度からクラッシュさせます：フォールトトレランスに関するものです。このアイデアは、広範囲にわたる制御不能な障害ではなく、障害、例外、およびクラッシュを使用可能なツールに変えることです。

004

近づいてくる秋[近づいてくる秋-約。 トランスレータ ]と制御されたアニーリングは、火で火と戦う実際の例です。私の出身地であるサグネ・ラック・サン・ジャンでは、ブルーベリー畑が定期的に管理された方法で燃やされ、成長を刺激し、再開します。かなり頻繁に、森林火災を防ぐために森林の不健康なエリアが火事でクリアされるのを見ることができるので、これは適切な監督と管理の下で起こります。主な目標は、自然の火がさらに広がることがないように、可燃物を取り除くことです。

これらの状況のすべてにおいて、作物や森林を通過する火の破壊力は、作物を癒したり、森林のはるかに大きな制御されない破壊を防ぐために使用されます。

「Let it crash」の意味はまさにそれだと思います。失敗、クラッシュ、例外を利用して、それを管理可能な方法にすると、回避する必要がある恐ろしい出来事をやめ、代わりに大規模な信頼性の高いシステムを組み立てるための強力な構築要素になります。

005

したがって、問題は、障害が破壊的よりも建設的であることを保証する方法になります。 Erlangのこのためのメインチップはプロセスです。 Erlangプロセスは完全に分離されており、分離できないアーキテクチャを備えています（何も共有しません）。他のメモリにクロールしたり、使用するデータを歪めたりして、作業に影響を与えたりするプロセスはありません。これは、100％保証された死にかけているプロセスが問題をそれ自体に保持し、システムに非常に強力な障害分離を提供することを意味するため、優れています。

Erlangのプロセスも非常に軽量であるため、数千および数千のプロセスが同時に問題なく動作します。アイデアは、余裕がある限りではなく、 必要な数のプロセスを使用することです。オブジェクト指向プログラミング言語があり、いつでも最大32個のオブジェクトを同時に動作させることができると想像してください。プログラムを作成するには、制限が厳しすぎてばかげているという結論にすぐに到達します。多くの小さなプロセスが存在するため、故障のばらつきが大きくなります。サービスに失敗の力を注ぎたい世界では、それは良いことです！

Erlangのプロセスのメカニズムは少し奇妙に見えるかもしれません。 Cでプログラムを作成すると、1つの大きmain()

関数があり、それがすべてを処理します。これは、プログラムへのエントリポイントです。 Erlangにはそのようなものはありません。どのプロセスも主要なものではありません。各プロセスは関数を起動し、この関数main()

この特定のプロセスのmain()

役割を果たします。

今、私たちはミツバチの群れを持っていますが、彼らが何らかの方法で通信できない場合、ハイブを強化するためにそれらを送ることは非常に難しいに違いありません。ミツバチが踊る場所[ ミツバチが踊る -約 翻訳者 ]、Erlangはメッセージングを処理します。

006

メッセージングは、競争の激しい環境で最も直感的なコミュニケーション形式です。彼女は、私たちが手紙を書いてクーリエによって馬に乗って送った日から始まって、ナポレオンのセマフォ[ 光学セマフォ -約 翻訳者 ]イラストに示されています。後者の場合、あなたは単にたくさんの人を塔に送り、彼らにメッセージを与え、彼らは疲れた馬よりも速い方法で長距離にデータを送信するために旗を振る。徐々に、この方法は電信に置き換えられ、それが電話とラジオを変えました。そして今、私たちはこれらすべてのファッショナブルな技術を使って、本当に遠く、本当に速くメッセージを送信します。

特に昔のこのメッセージングの非常に重要な側面は、すべてが非同期であり、メッセージがコピーされたことです。クーリエが帰ってくるのを待っている人は一日中ポーチに立っていなかったし、誰も（私は疑わしい）セマフォの近くに座って答えを待っていなかった。あなたはメッセージを送信してあなたのビジネスに戻りました、そして、時間の経過とともに、誰かが答えが到着したことをあなたに知らせました。

これは良いことです-反対側が反応しない場合、あなたは死ぬまであなたのポーチで立ち往生することはありません。逆に、受信者は、最近到着したメッセージが突然魔法のように消えたり変更されたりするという事実に直面することはありません。メッセージを送信するときにデータをコピーする必要があります。これらの2つの原則により、通信中の障害が歪んだ状態または修復不可能な状態を引き起こさないことが保証されます。 翻訳者 ]。 Erlangは両方を実装しています。

各プロセスには、すべての着信メッセージ用の独自のメールボックスがあります。誰でもプロセスメールボックスに書き込むことができますが、ボックスの所有者のみがそれを調べる機会があります。デフォルトでは、メッセージは受信した順に処理されますが、パターンマッチング[ パターンマッチング -約 翻訳者 ]を使用すると、優先順位を変更し、1種類のメッセージに常にまたは一時的に集中できます。

007

皆さんの中には、私が言うことに奇妙さを感じる人もいます。分離と独立性が非常に優れているため、システムコンポーネントが残りの部分に影響を与えることなく死に、落下することを許していることを繰り返します。しかし、多くのプロセスまたはエージェント間の通信についても言及しました。

2つのプロセスの対話の開始時に毎回、それらの間の暗黙的な依存関係が表示されます。両方を接続するシステムで暗黙的な状態が発生します。プロセスAがプロセスBにメッセージを送信し、Bが応答せずに死亡した場合、Aは応答を永遠に待つか、しばらくしてから通信を拒否できます。 2番目は許容可能な戦略ですが、非常にあいまいです。相手側が死んだか、長時間にわたってビジーであるかは完全に不明であり、コンテキストのないメッセージがメールボックスに到着する可能性があります。

その見返りに、Erlangはこの問題を解決する2つのメカニズムを提供します：モニターとリンク[ リンク-約。 翻訳者 ]。

モニターとは、オブザーバーになることです。プロセスを監視することにし、何らかの理由でプロセスが停止した場合、メッセージが受信トレイで何が起こったかを通知します。これに対応し、見つかった情報に基づいて決定を下すことができます。 2番目のプロセスでは、これをすべて行ったことを知ることはありません。したがって、あなたがオブザーバーであればモニターはかなり良いです。 翻訳者 ]またはパートナーのステータスを管理します。

リンク[ リンク-約 トランスレータ ]-双方向性であり、1つの作成により、両方の関連プロセスの運命が結合されます。プロセスが停止すると、それに関連するすべてのプロセスは終了コマンドを受け取ります。 翻訳者 ]。このチームは、他の人を殺します[ 関連-約。 翻訳者 ]プロセス。

モニターを使用して障害を迅速に検出でき、バインディングをアーキテクチャ設計として使用して、障害が全体に広がるように複数のプロセスを組み合わせることができるため、これはすべて非常に興味深いものになります。独立したビルディングブロックが相互に依存するようになるたびに、これをプログラムに追加し始めることができます。これは、システムが誤って不安定で部分的に変更された状態にクラッシュするのを防ぐため便利です。接続は開発者を保証します。何かが壊れた場合、それは完全に壊れて空白のシートを残し、演習に参加しなかったコンポーネントには影響しませんでした。

この図では、安全ロープで結ばれた登山者の画像を選択しました。登山者が互いに接続している場合、彼らは悲惨な位置にいることに気付くでしょう。 1人のクライマーがスライドするたびに、チームの他のメンバーはすぐに死亡します。ビジネスを行うには良い方法ではありません。

代わりに、Erlangでは、一部のプロセスを特別なものとして指定し、 trap_exit

パラメーターでマークすることがtrap_exit

ます。その後、通信を介して送信された終了コマンドを受信し、メッセージに変換できます。これにより、彼らはトラブルシューティングを行い、場合によっては故人の仕事を完了するために新しいプロセスをダウンロードすることができます。登山者とは異なり、このタイプの特別なプロセスでは、パートナーシッププロセスの低下を防ぐことはできません。これはパートナー自身の責任であり、たとえばtry ... catch

構造を使用して実装されます。出力をキャッチするプロセスには、別のメモリで再生して保存する機会はまだありませんが、共同死を避けることができます。

これは、監督者を作成する重要な機会になりつつあります。すぐにそれらに到達します。

008

スーパーバイザーに移る前に、私たち自身の利益のためにドロップを使用するシステムを正常に準備できる残りのいくつかの成分を見てみましょう。それらの1つは、プロセススケジューラの動作に関連しています。私が言及したい本当のケースは、アポロ11号の月面着陸です[ アポロ11-約。 翻訳者 ]。

アポロ11号は1969年に月に行ったミッションです。画像では、バズ・アルドリンとニール・アームストロングが搭乗している月面モジュールが見えます。写真は、コマンド・モジュールに残ったマイケル・コリンズによって撮影されたと思います。

月面着陸の途中で、モジュールはApollo PGNCS（一次ガイダンス、航法および制御システム）[ Apollo PGNCS-約 翻訳者 ]。制御システムは、慎重に計算されたサイクル数で複数のタスクを実行しました[ CPU-約。 翻訳者 ]各。また、NASAは、プロセッサを容量の85％以下で使用し、15％を無料で使用する必要があることも発見しました。

宇宙飛行士は、ミッションを中断しなければならない場合に備えて、信頼できるバックアップ計画を望んでいたため、コマンドおよびサービスモジュールをオンにして会議のレーダーを残しました。これにより、CPUの残りの電力が適切にロードされました。 Buzz Aldrinがコマンドを入力し始めるとすぐに、輻輳に関するメッセージが表示され始め、実際には、利用可能なコンピューティング能力を超えました。システムがこれから外れていたら、おそらくその仕事をすることができなかったでしょう、そして、すべては2人の死んだ宇宙飛行士で終わっていただろう。

まず、レーダーに既知のハードウェアの問題があり、その周波数が制御コンピューターの周波数と一致しなかったために過負荷が発生しました。これにより、通常よりもはるかに多くのサイクルの「窃盗」が発生しました。 NASAの人々はバカではなく、このような重要なミッションのために実生活でテストされていない新しいテクノロジーを使用する代わりに、実績のあるコンポーネントを再利用しました。しかし、もっと重要なのは、彼らが優先スケジューリングを思いついたことです。

これは、このレーダー、またはおそらく入力されたコマンドがプロセッサーに過度の負荷をかけると、タスクが殺され、優先度が高く、本当に必要な重要なものにCPUサイクルが与えられることを意味します。 1969年でした。今日では、協調的なディスパッチのみを提供し、それ以上の機能を提供しない言語やフレームワークがさらに多くあります。

Erlangは重要なシステムに使用されるべき言語ではありません。ソフトリアルタイムの制約のみを考慮に入れています-約。 翻訳者 ]、および厳密なリアルタイムの制限ではないため、このようなシナリオに使用することはお勧めできません。しかし、Erlangは予防的な計画を提供します[ 彼女は先制的なスケジューリングです。 翻訳者 ]およびプロセスの優先順位付け。つまり、開発者またはシステム設計者は、フリーズを防ぐために、コンポーネント（使用するライブラリを含む）に必要なCPU負荷を絶対に全員が慎重に計算することに注意する必要はありません 。彼らは単にそのような力を得ることができません。また、必要なときにいつでも重要なタスクを実行したい場合は、提供することもできます。

これは深刻なまたは頻繁な要求のようには見えず、人々は依然として並列プロセスの協調スケジューリングのみに基づいて本当に成功したプロジェクトをリリースしますが、それは確かに非常に価値があります。他の人の間違いから、そしてあなた自身の間違いからあなたを守るからです。また、自動負荷分散、「悪を罰する」または「良いを奨励する」プロセス、またはより多くのタスクを持つプロセスに高い優先順位を割り当てるなどのメカニズムへの扉を開きます。これらすべてにより、最終的にシステムは負荷や予期しないイベントに十分適応できるようになります。

009

まともな復元力を確保するための一部として説明したい最後のコンポーネントは、ネットワークで機能することです。長期的な活動を念頭に置いて開発されたシステムでは、複数のコンピューターで迅速に実行できることが不可欠な要件になります。主にユーザーに影響を与える障害を補うことができないため、金色の車でチタンのドアの後ろにロックされた場所に座りたくありません。

遅かれ早かれ、2台のコンピューターが必要になります。そのため、故障中にシステムの一部を展開したい場合、2台目、場合によっては3台目の障害に耐えることができます。

イラストの飛行機-F-82ツインマスタング[ F-82ツインマスタング -約 翻訳者 ]、第二次世界大戦中に、他のほとんどの戦闘機が単にカバーできなかった距離で爆撃機を護衛するために設計された航空機。彼は2つのキャビンを持っていたため、パイロットはシフトでデバイスを制御できました。適切なタイミングで、1人のパイロットが飛行機を操縦し、2人目のパイロットが迎撃機の役割でレーダーを制御できるように、責任を分割することができました。現代の航空機にはまだ同様の機能があります。彼らには無数の重複システムがあり、多くの場合、乗務員は飛行中に眠ります。そのため、必要に応じて、誰かがすぐに航空機の制御を引き継ぐ準備ができています。

プログラミング言語または開発環境に関しては、それらのほとんどは分散作業の可能性なしに設計されていますが、サーバースタックを開発する場合、複数のサーバーで作業する必要があることは明らかです。それでも、ファイルを使用する場合は、標準ライブラリにこのためのツールがあります。ほとんどの言語が提供できる最大値は、ソケットサポートまたはHTTPクライアントです。