ノード：小規模なスケーリングと一般的なスケーリング

過去数週間にわたって、私は、 BankSimpleの最初のバージョンを実装するためにどのテクノロジーを使用するかについて考えるために、見つけることができる自由な時間をすべて使ってきました 。 私はこの言語に関する本の共著者であるという事実のために、多くの人々はおそらく私がすぐにScalaを好んだと思いますが、エンジニアリングの問題の解決にはまったく異なる方法でアプローチします。 各問題には適切な一連のテクノロジーが適用されており、開発者のタスクはそれらの使用の必要性を正当化することです。



（ちなみに、ScalaはBankSimpleに非常に適している可能性があります。多くのサードパーティJavaコードを統合する必要があるためですが、これはブログにとってはまったく異なるトピックであり、ほとんどの場合、完全に異なるブログ）。



Hacker Newsで最も話題になっているテクノロジーの1つは、 V8仮想マシンでイベント駆動型JavaScriptアプリケーションを開発および実行するための環境であるNodeです。 プロジェクトの技術選択の一環として、ノード評価を実施しました。 昨日、Nodeに関する一般的な懐疑論を表明しました。この環境の作者であるRyan Dahlは、自分の考えをより詳細に表現する ように頼みました。 それで、私は進めています。



もちろん、私はほとんどの人がかつて見せることなく（オリジナルでは、 くびれなしで）低レベルCについてより多くを知っている良い男であり優秀なプログラマーであるライアンの信用を傷つけるという目標はありません。 ここでは、Nodeを中心に急速に成長している愛好家のコミュニティについては説明していません。 一緒に仕事をするのが大好きなツールを見つけて、それを使って成長を目指しているなら、これはあなたにもっと力を与えてくれます。



むしろ、この記事の目的は、Nodeプロジェクト用に設定された2番目のタスクをNodeがどの程度満たすかを調査することです。これは、いくつかのアプリケーションにとって重要だと思われるタスクです。

Nodeは何のために作成されますか？

NodeホームページのAboutセクションは次のとおりです。

「ノードの目標は、スケーラブルなネットワークアプリケーションを構築する簡単な方法を提供することです。」

以下のいくつかの段落で説明します。

「何もブロックされていないため、プログラミングの専門家でさえ[Node]で高速システムを作成することはできません。

それでは、スケーラブルなネットワークプログラムを作成する簡単な方法を提供するのがNodeの目標なのか、それとも非エキスパートプログラマーが「高速システム」を開発できるようにするのか。



これらの目標は関連しているように見えるかもしれませんが、実際には非常に異なっています。 理由をよりよく理解するために、私は「小さなスケーリング」と「一般的なスケーリング」を区別する必要があります。

小さなスケーリング

小規模のシステムでは、一般に、すべてが機能します。



最新の機器の力は、たとえば、利用可能な最も遅いプログラミング言語の1つを使用して何千人ものユーザーをサポートするWebアプリケーションを作成できることです。 、使用状況などに関係なく など...原則として、利用可能なすべてのアンチパターンを適用し、その結果として実行可能なシステムを取得できます。これは、ソリューションの選択肢が不十分であっても機器が効果的に機能するからです。



これは実に素晴らしいことです。 これは、私たちが好きなテクノロジーを使用して、考えずにプロトタイプを作成できることを意味します。これらのプロトタイプは、予想よりもよく機能することがよくあります。 さらに良いことに、交通渋滞に巻き込まれた場合、それを回避するのは簡単です。 前進するということは、数分かけて問題について考え、以前に使用したものよりもわずかに高いパフォーマンス特性を持つ実装テクノロジーを選択する必要があることを意味します。



ここで、Nodeは完全に適合すると思います。



Nodeを使用する人を見ると、彼らは主に、 制限されたパフォーマンス特性と呼ばれる動的言語で作業するWeb開発者です。 Nodeをアーキテクチャに追加するということは、これらの開発者が並行性を持たず、比較的良好な並行性に移行するために実行時にアプリケーションのパフォーマンスが非常に制限されているという事実に由来することを意味します。 これらの開発者は、アプリケーションの苦痛な部分を削除しました。これは、非同期実装により適していて、Nodeで書き直して先に進みました。



これは素晴らしい。 このような結果は、「高速システムを開発できる」「エキスパートプログラマーよりも少ない」というNodeの2番目の目標に完全に一致します。 ただし、一般的にスケーリングとは関係がなく、より広い意味で使用されます。

一般的なスケーリング

かなりの割合のシステムでは、魔法の弾丸はありません。



システムが実行する必要のある作業の滝に直面している場合、どのテクノロジーもそれをすべて改善することはできません。 大規模に作業するときは、かみそりの端に沿って移動し、適切に適用された技術、開発方法、統計分析、組織内コミュニケーション、インテリジェントエンジニアリング管理、機器とソフトウェアの高速で信頼性の高い操作、警戒監視などの協調ダンスを形成します。 スケーリングは困難です。 実際には、拡張する能力は、外に出て行くだけではダウンロード、コピー、購入、または盗むことはできないものの、競争上の大きな利点です。



Nodeの主な目標である「スケーラブルなネットワークプログラムを簡単に作成する方法を提供する」という私の批判です。 基本的に、スケーラブルなものを作成する簡単な方法があるとは思いません。 人々は軽い問題を簡単な解決策と混同しています。



非常に制限の厳しい技術の一部からわずかに制限の少ない技術の端にコードを移動することによって解決するのが簡単で便利な問題がある場合、幸運を考えてください、しかしそれはスケールで作業することを意味しません。 Twitterは、 Rubyの自己記述メッセージキューなどのサービスの一部がScalaにアップロードされたときに簡単に勝利しました。 それは素晴らしかったが、小規模にスケーリングされた。 Twitterは、テクノロジーを選択する以上の意味があるため、全体としての規模を拡大するのは依然として難しい戦いです。

成長ノード

私に関しては、小さなスケーリングから一般的なスケーリングへの移行の過程で、開発者と共にNodeを成長させるのは難しいと思います（いいえ、「コールバックが大量のスパゲッティコードになる」とは言いませんが、非同期システムの開発者にとって実際に苦痛な点だからです。



Nodeアーキテクチャの大胆な決定は、 すべての操作がファイルI / Oまで非同期であることであり、ソフトウェアでこの論文を実装する際の一貫性と明快さに対するRyanのコミットメントを賞賛します。 システムのワークロードを深く理解しているエンジニアは、Nodeモデルが適切であり、無期限に有効で効果的な場所を見つけることができます。 Nodeの長期的かつ成熟した展開はまだ見られていないため、これはわかりません。 私が取り組んできたシステムのほとんどは、常に変化しています。 ワークロードは変化しています。 使用するデータはシステムで変更されます。 以前は非同期ソリューションとしてうまく適合していたものが、マルチスレッドソリューションによって突然より良く機能するようになり、またはその逆、あるいは他の予測できない完全な変更に出くわしました。



Nodeに深く没頭している場合、問題とソリューションをモデル化する1つの方法で、並列性を実現する方法の1つにこだわっています。 ソリューションがイベントモデルの基礎に適合しない場合、ヒットします。 一方、いくつかの異なる並列化アプローチ（ JVM 、 CLR 、C、C ++、 GHCなど）を実装できるシステムを使用している場合、システムの進化に応じて並列性モデルを変更する機会があります。



現時点では、Nodeの主要な前提-イベントは必然的に高いパフォーマンスを意味する-は依然として疑問です。 カリフォルニア大学バークレー校の研究者は、「実行フローには、高い同時実行性、低いオーバーヘッド、および単純な同時実行性モデルのサポートなど、イベントモデルの強みがあることを発見しました 。」 以前の研究に基づく後の研究では、イベントとパイプラインモデルのアプローチは同等に優れており、ソケットをブロックすると実際にパフォーマンスが向上することが示されています。 Javaの産業界では、 ノンブロッキングI / Oが必ずしもスレッド化よりも優れているとは限らないことが定期的に示唆されています。 スキャンダラスな見出し「なぜストリームが悪いアイデアなのか」でこの主題について最も引用されたドキュメントの1 つでさえ、高性能サーバーのストリームを放棄すべきではないという結論で終わります。 並列性の点ですべての人に等しく適合するソリューションはないことを指摘しました。



実際、禁忌がなければ、並行性へのハイブリッドアプローチの採用は前進しているようです。 ペンシルバニア大学のコンピューター科学者たちは、ストリームとイベントの組み合わせが両方の世界の最高を提供することを発見しました。 Scala EPFLチームは、 Actorsがスレッドベースのプログラミングとイベントベースのプログラミングを1つのきちんとしたわかりやすい抽象化に組み合わせていると主張しています。 現在GoogleのGoプログラミング言語プロジェクトに携わっているBell Labsの元従業員であるRuss Coxは、スレッドとイベントの議論は無意味であると主張してさらに一歩前進します （これはすべて、システムのスケーラビリティの分散にさえ影響しないことに注意してください;スレッドは1台のコンピューター用のデザイン、1つのプロセッサー用のイベント、デザイン;マシン間での作業の分散については簡単な方法で説明していません;ところで、これはErlangに含まれており、急成長しているシステムを看護しているなら、それについて考える必要があります）。



ステートメント：経験豊富な開発者は、スレッドとイベントの混合物を使用し、アクターや実験的にはSTMなどの代替アプローチを使用します。 彼らにとって、「非ブロッキングは高速であることを意味する」という考えは、少なくとも少し馬鹿げているように聞こえますが、これはスケーラビリティの神話を指します。 スケーラブルなソリューションを提供するために多額のお金を払う人は、夜間にNodeを使用してシステムを必死に書き換えません。 彼らはいつもやっていたことをします。測定、テスト、性能テスト、熟考、問題に関連する科学文献の研究です。 これは一般的にスケーリングする必要があるものです。

おわりに

作業時間の投資については、非同期アプローチと他の並列化モデリング手法を柔軟に組み合わせることができるシステムに基づいています。 ハイブリッド同時実行モデルは、Nodeアプローチほど単純でクリーンではありませんが、より柔軟になります。 BankSimpleはまだ初期段階ですが、小規模でのスケーリングという楽しい課題に直面します。この初期段階ではNodeが賢明な選択になるかもしれません。 しかし、全体としてスケーリングする必要がある場合は、さまざまなオプションが用意されており、状況に左右されずに大幅に書き換えられる可能性はありません。



Nodeは、愛好家のコミュニティ、付随する鞭、そして明るい未来を持つ素晴らしいコードです。 これは、主に動的言語のユーザーから来た世代のWeb開発者が特にアクセスできる方法で、早期スケーリングの問題に対する即時解決策を提供する「統合テクノロジー」として、理にかなっています。 Nodeは二次的な目標を達成していると思われ、ネットワーク指向のタスクを解決する必要のある経験の浅い開発者から受け入れられる生産性を引き付けます。 Nodeは特定のタイプのプログラマーにとって非常に便利で楽しいものであり、簡単に作業を開始できることは否定できません。 Nodeコミュニティの人々は、他の有名なWebケージ、パッケージマネージャー、テストライブラリなどに触発されたホイールを発明しているため、後悔していません。 プログラマーの各コミュニティは、初期のことを再考し、独自の標準に導きます。



Nodeの方が適している理由と、それよりも少ない理由がわかった後、重要なタスクには万能薬がないことを覚えておくことが重要です。 Nodeと厳密に非同期のイベントを使用するアプローチは、一般的なスケーリングを伴う一連のテクノロジーとテクニックの非常に早い段階にあると考えるべきです。



一般的なソリューションに注意してください。 誰もがホットな新技術について話すことができますが、これらの技術が使用される規模で実際に働いて、さまざまな熊手を通過する人はほとんどいません。 通常、数字や科学的研究が不足している人は、長い間役立ってきたツールや方法を扱うのに忙しい。 時間を新しいテクノロジーに投資する場合は、それらを学び、成長する準備をしてください。おそらく、自分自身が制限されていることに気付いたら、船から離れることになります。



これは簡単ではありません。