ErlangとWeb
Webは並行である
あなたがウェブサイトにアクセスする場合には同時平行性が発生します。
いくつかの接続が開かれ、リクエストは開かれた接続を通って送信されます。
そしてウェブサイトが画面に表示されます。
使用しているブラウザの設定に応じて、サーバーと4つか8つの接続を確立します。そしてこれは多すぎるわけではありません。
しかし接続について考えてみてください。
あなたはサーバーへアクセスしているただ一人の人ではありません。
何百、何千とまではいきませんが、同時に同じサーバーへ何百万もの接続を行うことができます。
今日でさえ、製造に使用されるシステムの多くはC10K問題(1万同時接続)を解決していません。
次のステップに到達するためにC100K問題を解決しようとしていますが、まだまだ解決にはほど遠い状態です。
一方、Erlangは数百万の接続を扱うことには問題はありません。
執筆時点では予備のメモリとCPUで実際に稼動しているアプリケーションがのった単一のサーバー上に200万人以上の接続を処理することができるErlangで書かれたアプリケーションサーバーを持っています。
ウェブは並列です、そしてErlangは並列製のために設計された言語であるため完全にマッチしています。
もちろんさまざまなプラットフォーム上にて数百万の接続を超えてスケーリングする必要があります。
これはErlangの組み込み配布メカニズムがいかされる場所でしょう。
1台のサーバーで足りない場合には、より多くのサーバーを追加してください！Erlangはローカルのプロセスや、非常に迅速にサーバーの追加の必要性が生じた場合にも、あなたのサーバー群のプロセスへと通信するために今までと同じコードを使用し拡張することができます。
Webには大きなユーザーベースがあり、Erlangのプラットフォームは分散環境で動作するように設計されているため完全にマッチしています。
確かにあなたの好きな言語で大量の同時接続を処理するためのソリューションを見つけることもできます...しかしこれらのソリューションは今後数年の間に破壊されるんじゃないでしょうか。それはなぜでしょうか？
第一にサーバーはこれ以上、単一で速くはならないので、より多くのコアとメモリを乗せることになります。
あなたのアプリケーションが複数のコアとメモリを適切に使用することができる場合にはコアとメモリを増やすことは有効です、そしてErlangはその領域において他の言語よりも抜きん出ています。
第二に、今日ではコンピューターとネットワークは常に接続状態です(近い未来にはあなたの腕時計、ゴーグル、自転車、車、冷蔵庫などのデバイスがインターネット上の色々なアプリケーションと接続することとなるでしょう)
そんな状態になったとしても唯一、Erlangだけは対処する準備ができています。
Webはソフトリアルタイムです。
ソフトリアルタイムは何を意味するのかっとあなたは考えますか？
それは我々の操作が可能な限り迅速に行われ、Webアプリケーションの場合には、我々がデータを高速に通信したいことを意味しています。
比較ですが、ハードリアルタイムは同様の意味を持つだけではなく、ハードによる時間制約があり、Nミリ秒以下で実行する必要があり、もしも遅延するならばシステムは完全に失敗したこととなります。
ユーザーはそんなに愚かではありません、ユーザーはユーザー自身が許せる範囲内の遅れでデータを取得したいと思っています、そして彼らは何かしらの情報を送信し長くても2、3秒後には登録できることを望みます、さもなければ彼らはデータがうまく通信できているかについて心配し始めます。
操作を実行するための時間がかかることによってサービスの品質が悪いとみなされるため、Webはソフトリアルタイムなのです。
Erlangはソフトリアルタイムシステムです。
それは常に公正に、一度に少しのプロセスを実行します。そしてしばらくして別のプロセスに変更し、他の全てのリソースを盗むような単一のプロセスを防ぎます。
これはErlangの動作が安定した低遅延を保障することを意味します。
ErlangはソフトリアルタイムWebが要求する保障を提供しています。
Webは非同期です
HTTPは動機通信だったためWebは同期型でした。
今まではあなたがリクエストを送信し、そのレスポンスを待っていました。
今は違います。
XmlHttpRequestが使われ始めてから全てが変わりました。
これはクライアントがサーバへの非同期呼び出しを実行できます。
その後にWebsocketが登場し、サーバとクライアントの両方が完全に非同期に他のエンドポイントにデータを送信することができるようになりました。
データはフレーム内に含まれ、レスポンスの必要はありません。
Erlangのプロセスは同じように動作します。
Erlangはメッセージ内に含まれる互いのデータを送信し、応答を必要とせずに実行を続けます。
Erlangは新しいメッセージを待って非アクティブに多くの時間を費やす傾向があり、一方が受信したときにErlangのVMは喜んでそれらを有効にします。
非同期通信は予想できないタイミングでくるかもしれません、新しいメッセージを待って常に準備ができている確実なプロセスまでデータを渡すかもしれません、必要とする動作を実行するためにシステムの必須の部分を起動させることもあるかもしれません、そのためErlangにとってWebsocketフレームを受信することが得意であることを想像するのは至極簡単です。
より最近のWeb技術は当然Websocketだけではなく、SPDYやHTTP/2.0のような完全非同期プロトコルもあります。
リクエストとレスポンスの概念はもちろん持っていますが、クライアントやブラウザ間の間で何を送信することができ、レスポンスが完全に異なる順序にて受信することもできます。
Erlangは自然な非同期と長年にわたってVMで開発されてきた偉大なエンジニアリングによって本当によいものとなってきています。
Erlangが非同期のWebを扱うのにとてもよいものであるというのは当然のことなのです。
Webは同時にどこにでも存在する
Webは私たちの生活の非常に重要な部分まではいりこんできています。
私たちはコンピューターを使用して携帯電話として使ったり、お風呂でタブレットを使って時間をつぶしたりなど、常時Webにアクセスしています。そしてこれは自宅のすべての装置から常に接続がされ、他のデバイスでアクセスするために接続が切断されてしまうわけではありません。
すべてのデバイスは常に接続状態です。
そしてあなたが求めるコンテンツにアクセスできるようにする選択肢の数であり、ユーザーは問題が発生したときに固執しない傾向があります。
今日ユーザーはアプリケーションを使用し続けていて、多くの問題が発生すると他のアプリケーションへと移っていきます。
上記にもかかわらず開発者がWebアプリケーションを構築するために使用する製品を選ぶときに、彼らの唯一の関心事は「それは速いのか？」とほんの一握りの同時接続にて「Hello World」を送信する最速の合成ベンチマークを見回して探しています。
本当に開発者が自分自身に尋ねなければならないことは「中断することなく、ユーザーにサービスを提供することができますか？」であり、そして開発者は二つの選択肢があることに気づくでしょう。
今使っているソリューションが最善であること期待するか、Erlangを使用することを選ぶかです
Erlangはフォールトトレランスのために構築されています。
他の言語でコードを記述するときは、全ての戻り値を確認し予期しない問題を回避するために、戻り値に応じて対策しなければなりません。
運が良ければ重要な自体を見逃すことはありません。
Erlangのコードを記述する場合、成功条件をチェックし、すべてのエラーを無視することができます。
エラーが発生した場合はErlangのプロセスがクラッシュし、特別なプロセスはスーパーバイザーに呼ばれて再開します。
Erlangの開発者はこのように未処理のエラーについて恐れる心配がないですし、ユーザーにエラー内容のフィードバックを与えればシステムが肩代わりしてくれるためエラーのみに集中することができます。
これは開発者がはるかに少ないコードの記述量ですみ、そして夜に幸せに寝ることができる利点を持っています。
Erlangのフォールトトレランス指向設計は常に存在し続け利用可能なWebのための最良の選択肢であり、1つの要素でもあります。
2つめの要素はErlangの組み込みディストリビューションです。
それは全体のサーバがダウンする、またはデーターセンターが同じように大きな障害が発生した場合に、ディストリビューションは大きな障害を処理するためのフォールトトレランスシステムを構築するための重要な部分です。
フォールトトレランスとディストリビューションは今日重要であり、Webの将来に不可欠となります。
Erlangには準備ができています。
