なぜアーラン

により ロシア 語から 翻訳された 元の記事: smyck.net/2012/04/22/why-erlang



マルチコアプロセッサを搭載したデバイスでこの記事を読む可能性は日々高まっています。だからこそ、誰もが並行性について常に語っています。 WebアプリケーションとバックエンドAPIの同時実行は、htop出力が次の画像のようになるときです。



並行htop



私は最近、素晴らしいRubyカンファレンスに参加しましたが、3、4回の講演で並行性について話しました。 Rubyコミュニティはかなり開かれており、スレッドの使用、 GILをバイパスするためのさまざまなRubyランタイムの使用、より多くのプロセッサの使用 Celluloidなどのライブラリを介したアクターモデルの使用 JRubyを介したAkkaの使用などかなりの可能性が議論されています。



アクターモデルはネットワーク化された並列アプリケーションの作成に適しているようですが、アプリケーションが実装されているランタイム環境がネイティブサポートを持たない場合、問題が発生することがよくあります。 Ruby、Python、およびJavaの実装がありますが、通常の動作を実現するためにすべてを調整する必要があり、必ずしも最高のパフォーマンスが得られるとは限りません。 これは、Erlangがはるかに優れた選択肢である多くの理由の1つですが、まず、アクターモデルを少し調べて、これがなぜうまく機能するのかを理解しましょう。







俳優モデル




表面的な理解のために、ウィキペディアからの素晴らしい引用を以下に示します。



「俳優のモデルは、周囲のすべてが俳優であるという哲学に基づいています。 これはオブジェクト指向プログラミングの哲学に似ていますが、周囲のすべてがオブジェクトであるという点で異なりますが、オブジェクト指向プログラミングでは、プログラムは通常シーケンシャルに実行されますが、アクターモデルでは計算は本質的に時間的に同じです。




以下のような、アクターとオブジェクトの類似性にもかかわらず、モジュール性、カプセル化、メッセージ送信機能。 俳優にはユニークな機能があります-同時に仕事をすることができます。



つまり、他のアクターと状態を共有するためにメッセージを送信することは並行して機能し、非同期相互作用が可能になります。つまり、送信者は受信者からの応答を待つ必要がなくなります。



OOPの世界とのもう1つの大きな違いは、アクターモデルにはグローバルな状態がないため、アクター間で共通のメモリを共有しないことです。 Java、Ruby、Pythonなどの言語では、常にグローバル状態が使用され、スレッドは共有メモリにアクセスできます。 この状況は、ロックまたは状態の競合という形で問題になることが多く、おそらく最大の不便です。



アクターモデルでは、各アクターには独自の内部状態があり、メッセージを通じてのみ配信されます。 このようにして、アクターはその状態にアクセスするためのシリアライザーとして機能し、それによって競合状態を効果的にブロックおよびブロックします。



また、アクターモデルは、不変データの概念を持つ関数型プログラミング言語に非常に適していることにも注意してください。



俳優について読むべきことがたくさんありますが、知っておくべき最も重要なことを指摘します。 一般に、アクターモデルを使用すると、並列アプリケーションの開発がはるかに簡単かつ高速になります。



OK、アーランはどうですか?




まず、私は長年にわたり情熱的なRuby開発者であったと言いたいと思います。 私はこの言語とそのコミュニティが本当に好きです。 しかし、時々、ネットワークアプリケーション、Webアプリケーション、Webサーバー、プロキシなどに関して、目に見えない壁を克服していると感じました。つまり、複数のリクエストを処理したり、重要なタスクを実行したりするアプリケーションすべてです。



アーランはずっと前に私の見解になりましたが、私の象牙の塔とルビーの屋根の高さから、試してみる価値があることを理解するために多くの試みをしました。 概念的には、これは私にとって非常に重要であり、Erlangについて読んだほとんどの人は私に同意するだろうと確信しています。 私は言語の構文にショックを受けたことを認めなければならず、これは私を止めました

この言語を試してみたいという欲求から。 これは私がこの記事を書くきっかけになった大きな間違いだったと思います。できるだけ早くErlangを試してみるべきだということです。



まず、Erlangの説明を1行で説明します。



「Erlangは、並列アプリケーションのアクターモデルに実装された関数型言語です。」



この言語は、通信スイッチ用にエリクソンが開発したものであり、目標は、可用性の高いフォールトトレラントな並列システムの開発を可能にする言語を作成することでした。



ウィキペディアまたはすばらしいサイトですべてについて読むことができます: learnyousomeerlang.com-これらの人は言語を説明する素晴らしい仕事をしました。



WoogaでErlangを使用したケーススタディ




この記事は一種のプッシュです。Erlangを試してみることをお勧めします。WoogaでのErlangのアプリケーションの話をして、これをやろうとします。



Woogaは、1日あたり何百万人ものアクティブなプレイヤーでソーシャルゲームを作っています。 ゲームは常に、サーバーにゲーム参加者の状態を変更および維持するよう指示します。 一部のゲームはRubyで開発されており、正常に動作します。 私が言ったように、Rubyは本当に良い言語であり、最速ではありませんが、あなたが何をしているのか知っていれば、非常に生産的です。



ユーザー数の観点から見ると、複雑な内部ロジックを持つ最大のゲームは80〜200のサーバーで実行されます。毎秒約5000〜7000のリクエストを処理し、ほとんどすべてのリクエストがゲーム自体のプレーヤーの状態を変更します。 サーバーの数はピーク負荷時に合理的な制限内に保たれますが、当然、この数字は最も印象的なものではありません。



類似のロジックと複雑さを備えた新しいゲームを作成するときが来たとき、私の同僚PaoloはErlangを選択することに決めました。彼はそれが正しい選択だと思いました。 Erlang( Knut )で経験豊富な開発者を雇い、一緒にロジックを実装しました。 現在、このゲームには残りのゲームの約50%のプレイヤーがいて、サービスに必要なサーバーの数は1!です。



ゲームは冗長性のために2つまたは3つのサーバーで提供されますが、1つでも完全に機能します。 ゲームが実際に4つのサーバーを必要とする場合でも、他のゲームよりもはるかに効率的かつ生産的です。



もちろん、彼らは以前のゲームで犯したすべての間違いをすでに知っていましたが、これはErlangの欠如だけでなく、そのようなパフォーマンスの向上を達成し、ロジックの実装に貢献しました。俳優モデルの助けを借りて目標を達成するのは本当に簡単でした



別の言語では、プレーヤーのステータスを保存するWebサーバーを作成しました。つまり、現在叫んでいる各プレーヤーは、Erlang VM内の別々のアクターによってサービスされます。 ゲームを開始するプレーヤーは、自分の状態で俳優を作成します。 その後のリクエストは、彼がプレイしている間、彼が関連付けられている俳優に直接送られます。 したがって、ゲームの状態はメモリに保存されますが、データベースへの呼び出しはすべて除外され、リクエストは処理され、非常に迅速に応答します。



アクターが落ちた場合、一般的な/グローバルな状態がないため、残りのアクターは「生きている」ままです。 プレイヤーがゲームを停止すると、アクターはプレイヤーの状態を永続的なストレージに保存し、ガベージコレクター(GC)はそれをメモリから削除します。 同時に、覚えているように、Erlangのデータは変更されません。これにより、変更が発生して問題が発生するまでプレイヤーの状態を戻すことができます。



それは本当に驚くべきことであり、私はあなたにもっと多くを伝えることができます。 幸いなことに、クヌートとパオロはいくつかの会議で私たちの経験について話し、彼らのスライドをパブリックドメインに入れました。 リンクでそれらを見ることができます:



* www.slideshare.net/wooga/erlang-factory-sanfran

* www.slideshare.net/hungryblank/getting-real-with-erlang



ウーガのその他のアーラン




PaoloとKnutがErlangウイルスで会社全体を感染させた後、Erlangといくつかの追加サービスで新しいゲームを作成しました。 Erlangを学習すればするほど、正しい方法を理解できるようになることを確認できます。 これにより、Rubyカンファレンスでさまざまなライブラリに苦労していた人たちを少し気の毒に思うようになり、Erlangを1つのパッケージで提供する並列アプリケーションを簡単に開発できるようになりました。 20年以上使用されているパッケージ。



新しい言語を学ぶのが難しい部分は、小さなプロジェクトを見つけてそれに参加することです。 本を読むだけで勉強するのはいつも遅く、コードを書き始めると、読んだもののほとんどが忘れられます。 また、奇妙な構文(今は奇妙ではない)は、実際のプロジェクトでErlangを使い始めるのに乗り越えられない障害でした。 したがって、小さなプロジェクトを選択し、Erlangで「遊んで」ください。 後悔しないと思います。



私はアーランを学び、それを発表したので、近い将来に記事を書きたいと思っています。 それまでの間、 learnyousomeerlang.comにアクセスして学習を開始できます。 私を信じてください-これは、現在利用可能なErlangの本よりも良い選択です。



PS:校正をしてくれたElise Huardに感謝します! コメント、記事をよりカラフルにするためのルビー屋根の象牙の塔の画像、または希望があれば、すぐに私に送ってください!



All Articles