More than 3 years have passed since last update.

Node.jsの設計をつらつらと概観する

Posted at 2020-03-18

株式会社Global Mobility ServiceでソフトウェアエンジニアのインターンをさせてもらっているShirubaです。グローバルな環境で利用されている社会的サービスの開発の一端を担いたい志ある方は、ぜひ緩くお話ししましょう〜。バックエンドはNode.jsを使っています。🙋‍♂️→ 採用ページ

Node.jsについて色々資料を読んでメモをとったりしていたので、一度まとめておきたくて、この記事を書くことにしました。V8やLibuvなど低レイヤ技術の設計をベースにNode.jsを概観していきます。

Node.jsとは

Node.js公式によるNode.jsの定義は以下です。

Node.js はスケーラブルなネットワークアプリケーションを構築するために設計された非同期型のイベント駆動の JavaScript 環境です。
https://nodejs.org/ja/about/

Node.jsを理解する上で重要な特徴を定義から抽出すると、以下の3つです。

スケーラブル
非同期型
イベント駆動

この3つの特徴については後で触れていきます。

Node.jsの内部構造

画像引用：https://blog.insiderattack.net/event-loop-and-the-big-picture-nodejs-event-loop-part-1-1cb67a182810

Node.jsは、いくつかのモジュールを組み合わせて構成されています。Node.jsを理解する上で重要なのは「V8」と「Libuv」です。この2つが、サーバーサイドでのJavascript実行環境を作っています。（クライアントサイドでは、chrome組み込みのv8とhtml5（イベントループ等を提供）でJavascript実行環境が実現されているそう。）

V8

どうでもいいですが、V8の読み方は「ヴィーエイト」です。謎に「ブイハチ」って読んでた自分を恥じたい。

V8の定義を公式から引用します。

V8 is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. It is used in Chrome and in Node.js, among others. It implements ECMAScript and WebAssembly, and runs on Windows 7 or later, macOS 10.12+, and Linux systems that use x64, IA-32, ARM, or MIPS processors. V8 can run standalone, or can be embedded into any C++ application.
https://v8.dev

V8っていうのは、Javascript Engineを指します。要するに、Javascriptで書かれているソースコードを受け取って、機械語に変換してOS上で実行してくれるのがV8です。
chromeとnode.jsはJavascript EngineとしてV8を採用していますが、それ以外は違います。例えばSafariではV8ではなくJavascriptCoreを採用しています。

ちなみに、EngineだとかRuntimeだとか単語がややこしいのですが、Javascript Engine、 Javascript Runtime、A compiler、Virtual Machineは全てV8を指すと考えて良いそうです。（参考：https://www.youtube.com/watch?v=PsDqH_RKvyc）

また、V8の定義に「ECMAScript」という単語が入っているので定義を引用しておきます。

ECMAScript（エクマスクリプト）は、JavaScriptの標準であり、Ecma Internationalのもとで標準化手続きなどが行われている。
引用：https://ja.wikipedia.org/wiki/ECMAScript

要するに、Javascirptの文法の標準がECMAScriptです。「（Javacsriptで書かれている）ソースコードが何を意味しているのか」を表します。V8が受け取る、Javascriptで書かれているソースコードは極論ただのテキストの塊です。V8は、Javascriptで書かれたソースコードをECMAScriptを用いて解析しています。

V8を理解していなくてもNode.jsのアーキテクチャは理解できるので、V8は後回しにして、この記事の最後で見ていきます。

Libuv

Libuvの定義を引用します。

libuv is a multi-platform support library with a focus on asynchronous I/O. It was primarily developed for use by Node.js, but it’s also used by Luvit, Julia, pyuv, and others.
引用：http://docs.libuv.org/en/v1.x/#overview

非同期I/Oは、OSごとに実現方法が異なります。epollを使うOSがあったり、kqueueを使うOSがあったり。（非同期I/Oについては後述。）そこでepollやkqueueなど低レイヤの技術を抽象化したインタフェースを作って、OSを気にすることなく非同期I/Oを使えるようにしようとして作られたのがLibuvです。

Libuvの内部は以下のようにデザインされています。

画像引用：http://docs.libuv.org/en/v1.x/design.html#design-overview

ちなみにNode.jsで使われているイベントループを提供してくれているのもLibuvです。

Node.js Bindings

これは、概念的なものです。

v8やlibuvはc++で書かれている一方で、Node.jsを使ってapplicationを作るときに私たちはjavascriptを用います。これがNode.jsの旨みでもあるのですが、私たちはJavascriptで開発しているのに、内部的にはc++で記述されているv8とかlibuvを利用できるのです。

このJavascriptと他のプログラミング言語の橋渡しをしているのがNode.js Bindingsです。

ちなみにNode.js Bindingsは、「Language Bindings」のことを指しています。ということで、「Language Bindings」の定義をwikipediaから引用します。

In computing, a binding is an application programming interface (API) that provides glue code specifically made to allow a programming language to use a foreign library or operating systemservice (one that is not native to that language).
Binding generally refers to a mapping of one thing to another. In the context of software libraries, bindings are wrapper libraries that bridge two programming languages, so that a library written for one language can be used in another language.[1] Many software libraries are written in system programming languages such as C or C++. To use such libraries from another language, usually of higher-level, such as Java, Common Lisp, Scheme, Python, or Lua, a binding to the library must be created in that language, possibly requiring recompiling the language's code, depending on the amount of modification needed.[2] However, most languages offer a foreign function interface, such as Python's and OCaml's ctypes, and Embeddable Common Lisp's cffi and uffi.[3][4][5]
https://en.wikipedia.org/wiki/Language_binding

Node.js Bindingsについて詳しくは触れませんが、Internals of Node- Advance node ✌️が面白かったです。

コアモジュール

Node.jsには組み込みのコアモジュールというものが存在します。コアモジュールは沢山あるので、それぞれの重要度とかはNode.js徹底攻略 ─ ヤフーのノウハウに学ぶ、パフォーマンス劣化やコールバック地獄との戦い方を参考にされたし。

サーバのアーキテクチャ

Node.jsの内部を雑に見渡したところで、Node.jsの設計を見ていきます。
Node.jsで特徴的なのが、採用しているサーバアーキテクチャです。

サーバーのアーキテクチャには、一般的に「Thread Based」と「Event Driven」があります。Node.jsの採用しているサーバアーキテクチャは「Event Driven」、つまり「イベント駆動型」です。（参考：Server Architectures）

Thread-based

Thread Basedの場合のサーバの典型的なコードは以下のようになる。

[画像引用：https://www.slideshare.net/NodejsFoundation/nodes-event-loop-from-the-inside-out-sam-roberts-ibm]

acceptというシステムコールを通して接続されたコネクションをpthread_createで別のスレッドに渡して、別のスレッドでそのコネクションを処理させます。メインスレッドは、acceptでのブロッキング状態にすぐに戻り、ユーザーからの新しい接続に備えるという流れです。

つまり、ユーザーからのコネクション1つにつきスレッドを1つ作成して、そのスレッドでコネクションに対応しているという訳です。これだとスレッドの無駄使いだし、コンテキストスイッチも発生してしまいます。

このサーバアーキテクチャを図で表すと以下のようになります。

[画像引用：[Node.jsデザインパターン第2版](https://www.amazon.co.jp/Node-jsデザインパターン-第2版-Mario-Casciaro/dp/4873118735)]

Idle timeも多くなってしまっていることが分かります。このサーバアーキテクチャで出現した問題が「c10k問題」。c10k問題はThe c10k Problemを参考されたし。

wikipediaからc10k問題の定義を引用しときます。

C10K問題（英語: C10K problem）とは、Apache HTTP ServerなどのWebサーバソフトウェアとクライアントの通信において、クライアントが約1万台に達すると、Webサーバーのハードウェア性能に余裕があるにも関わらず、レスポンス性能が大きく下がる問題である。
引用：https://ja.wikipedia.org/wiki/C10K問題

またまた引用します。

preforkモデルのApatchでは、クライアントの接続要求から始まる一連の処理を各プロセスで１接続ずつ処理します。そのため大量の接続を同時に処理するにはその分だけプロセス（またはスレッド）を起動しなければなりません。これでも複数の接続を並行して処理することはできますが、あまり大量のプロセスを起動するとプロセス間コンテキストスイッチのオーバーヘッドが大きくなって性能が劣化します。これがC10K問題の本質です。
引用：　nginx実践入門

このc10k問題を解決するのが、非同期I/Oであり、非同期I/Oを用いたサーバアーキテクチャである「Event-Driven」（イベント駆動型）です。

Event-Driven

イベント駆動型のサーバアーキテクチャを理解するためには、まず「非同期I/O」を理解する必要があります。

非同期I/O

Unixには、以下の5種類のI/Oモデルが存在します。

ブロッキングI/O
非ブロッキングI/O
I/Oの多重化（selectとpoll）
シグナル駆動I/O（SIGIO）
非同期I/O（Posix.1のaio_関数群）

Node.jsで使われているのは「非同期I/O」です。

画像引用：[Unix Network Programming](https://www.amazon.co.jp/Unix-Network-Programming-Addison-Wesley-Professional/dp/0131411551/ref=dp_ob_title_bk)

処理をカーネルに任せ、処理が完了したらカーネルが元のスレッドに通知をよこすというI/Oモデルです。ちなみによく聞く「ノンブロッキングI/O」は以下のようなI/Oモデルです。

画像引用：[Unix Network Programming](https://www.amazon.co.jp/Unix-Network-Programming-Addison-Wesley-Professional/dp/0131411551/ref=dp_ob_title_bk)

図から分かるように、アプリケーション側からカーネルに「データの準備が完了したか」を尋ねる作業をループで繰り返す必要があり、リソースが勿体無いので、イベント駆動型では非同期I/Oモデルが採用されています。

この非同期I/Oモデルを用いることで実現されるのが「イベントループ」です。通知を発生させるイベントを常にループ文で監視していることから「イベントループ」です。また、このおかげでユーザーからのコネクションをシングルスレッドで処理することが可能になります。

画像引用：[Node.jsデザインパターン第2版](https://www.amazon.co.jp/Node-jsデザインパターン-第2版-Mario-Casciaro/dp/4873118735)

リアクタパターン

このイベントループを用いたイベント駆動型モデルは、リアクタパターンと呼ばれます。（非同期I/Oを用いたイベント駆動型モデルなので、プロアクタパターンと呼ぶのだろうか。「Node.jsデザインパターン第2版」に沿って、ここではリアクタパターンと呼ぶことにします。）

リアクタパターンの定義は以下。

リアクタパターンではI/Oの処理はいったんブロックされる。監視対象のリソース（群）で新しいイベントが発生することでブロックが解消され、この時、イベントに結びつけられたハンドラ（コールバック関数）に制御を渡すことで呼び出し側に反応（react）する。
引用：Node.jsデザインパターン第2版

Node.jsでは、非同期処理を使う場合、イベントにコールバックを持たせて、イベントが終了したものからコールバックを実行しています。ちなみに、Javascriptの関数は第1級オブジェクトなので、関数にコールバック関数を持たせるのが非常に容易です。

リアクタパターンを図で表すと以下のようになる。

画像引用：[Node.jsデザインパターン第2版](https://www.amazon.co.jp/Node-jsデザインパターン-第2版-Mario-Casciaro/dp/4873118735)

Node.jsでは、ここで説明した「イベント駆動型」モデルが採用されています。ただ、注意したいのは、Node.jsで用いられているイベントループのデザインはこれとは少し異なるということです。

まずNode.jsでは、非同期I/Oを使っている処理もありますが、内部的にスレッドプールを使っている処理もあります。そして2つにNode.jsではイベントキューが複数存在するということです。全てのイベントのハンドラが同一のイベントキューに入れられていくのではなく、イベントの種類に応じて積まれていくイベントキューが異なります。

Libuvが提供する非同期処理のアーキテクチャ

Node.jsで用いられる「イベントループ」を提供しているのがLibuvです。ここではLibuvが提供する以下の概念について見ていきます。

Event Loop
Handles
Requests
Thread Pool

イベントループ

イベントループの定義を公式から引用します。

The event loop is what allows Node.js to perform non-blocking I/O operations — despite the fact that JavaScript is single-threaded — by offloading operations to the system kernel whenever possible.
Since most modern kernels are multi-threaded, they can handle multiple operations executing in the background. When one of these operations completes, the kernel tells Node.js so that the appropriate callback may be added to the poll queue to eventually be executed.
引用：The Node.js Event Loop, Timers, and process.nextTick

先ほど紹介したように、「非同期I/O」を可能にするのが「イベントループ」です。ちなみに、イベントループはNode.jsのメインスレッドで、ひたすらクルクル回っています。（ループ文）

メインスレッドを止めてしまうようなタスク（I/Oに関するタスクなど）を入れてしまうと、その処理に時間を食ってしまい、そこでイベントループが止まってしまい、他の処理ができなくなります。そのため、そういった処理に関しては、カーネル内のマルチスレッドを使った非同期I/Oモデルに処理を依頼する訳です。そして依頼したI/O処理が完了したら、登録しておいたハンドラ（コールバック関数）を実行する訳ですが、このハンドラはqueueに入って、メインスレッド（イベントループが回っているスレッド）で順次実行されていきます。この挙動によって、Node.jsの非同期I/Oでは、「競合状態」を気にせずに開発することができます。

Node.jsのイベントループは、いくつかのフェーズから構成されています。このフェーズごとの挙動は、ここでは省略させてもらいます。イベントループに関する分かりやすかった図を載せておきます。

[画像引用：https://drive.google.com/file/d/0B1ENiZwmJ_J2a09DUmZROV9oSGc/view]

この図内の「黄色いJSの箱」の部分を詳細に見ると以下のようなループになっています。

[画像引用：https://drive.google.com/file/d/0B1ENiZwmJ_J2a09DUmZROV9oSGc/view]

Node.jsのサーバを開始する際にも、イベントループが利用されています。公式ドキュメントの、Node.jsを使ったサーバーを作るためのコードを引用します。


const http = require('http');

const hostname = '127.0.0.1';
const port = 3000;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

server.listenで内部的にepollなど非同期I/Oが用いられています。ハンドラは、arrow関数の部分ですね。tcp connectionをacceptした時のコールバックとしてアプリケーションが非同期に実行されるようにコードが書かれています。

HandleとRequest

イベントループ内で処理されるタスクはHandleオブジェクトとRequestオブジェクトの２種類存在します。

Handleは長期間存在することができるオブジェクトで、I/Oが発生していない時でもイベントループを維持します。Requestは短期間存在するオブジェクトで、I/Oが発生している時のみイベントループを維持します。

イベントループは、アクティブなHandlesもしくはRequestsがなければ止まります。

スレッドプール

Node.jsはイベント駆動型のサーバアーキテクチャを採用していることからも、よく「シングルスレッド」だと表現されます。しかしここで注意しておきたいのですが、Node.jsは処理によって、内部的にスレッドプールを使った並行処理を行なっています。

ここから動画「The Node.js Event Loop: Not So Single Threaded」から画像を大量拝借しています。（すごく分かりやすかった。）

例えばCPU intensiveな処理であるcryptモジュールを使ったコードを見てみます。