NEM
https://nem.io/
bootstrap
https://github.com/tech-bureau/catapult-service-bootstrap
はじめに
catapultのバージョンがElephant1(Loxodonta africana)まで来ました。次のFがリリース候補版になるようで、また、NEM2としての機能はこのElephantでほぼ全て搭載されているということもあり、bootstrapを使ってcatapultを触り始めた人も増えてきたように思います。
ただ、例えばbootstrapを使ってローカル上にネットワークを作る場合、非同期的に動くいくつものプログラムが吐き出すログを読むのはかなり辛い作業になるでしょう。
今回は、主にAPIノード上で動くいくつかのプログラムの関係を理解することを目標にこの記事を書きます。
これを理解することで、例えばbootstrapによって作られたDockerの各コンテナが吐き出すログを読む時にその意味を推測しやすくなったり、自分でネットワークを作ってみる時に設定ファイルの中身とその意味を推測しやすくなるでしょう。
これを書いている時点でのcatapultのバージョン
0.5.0.1(Elephant)
全体図
上記の図が主にAPIノードの中で動くプログラム（+クライアント）とそれらの関係を表したものになります。（上記図を見て全てを理解した人はこれより下を読む必要はありません。）
図中上部の点線より下がAPIノードだと思ってください。ただし、クライアントはウォレット等のアプリケーションになるので、ここだけはAPIノードの中にあるわけではありません。
図の中で登場するcatapult.server,catapult rest,catapult.brokerはそれぞれ非同期的に動きます。勿論、catapult restと通信をするクライアントも非同期的に動いています。
また、catapult.server,catapult rest,catapult.brokerの3つ（実際にはmongoDBも）は、それぞれ別のプログラムであり、必ずしも同じインスタンス上にある必要がありません。それらは 「自分が直接関わっているものが正しく動いていれば問題ない。自分の仕事をするだけ。」 なので (非同期的に動いているというのはそういうこと) 、容易に分解することが出来ます。
実際、catapult-service-bootstrapでは、それらはそれぞれ別々のコンテナ上で動いており、ディレクトリを共有することなどで上手く連携して稼働するようになっています。
// bootstrap起動時のログ（抜粋）
Creating docker_api-node-broker-0_1 ... done
Creating docker_db_1 ... done
Creating docker_peer-node-0_1 ... done
Creating docker_peer-node-1_1 ... done
Creating docker_api-node-0_1 ... done
Creating docker_rest-gateway_1 ... done
boostrapでは 2つのPeerノード と 1つのAPIノード が動く構成になっていますが、上記を見れば分かるとおりAPIノードはapi-node-broker-0_1,db_1,api-node-0_1,rest-gateway_1,という4つのコンテナが連携することで動いています。
bootstrapでは他にもいくつものコンテナが立ち上がりますが、それらはネットワークを立ち上げるために各種設定用だと思って問題ないと思います。
以下、catapult.server,catapult rest,catapult.brokerをそれぞれ詳しく見ていきます。
catapult.server
catapult.serverはP2Pネットワークに繋がり、ブロックチェーンの同期を行います。また、catapult restから新しいトランザクションを受け取って検証したり、catapult restからのリクエストによってはノード自身が持っている情報を提供したりします。
また、データを格納するディレクトリにspoolというディレクトリを作り、そこにブロックが進む毎に更新される情報を記録していきます。
catapult.broker
version0.4.0.1(Dragon)から登場したcatapult.brokerは、catapult.serverがspoolディレクトリ内に記録したデータを元に、mongoDBに記録します。また、catapult restにトランザクションが認証されたことや新しいブロックが発生したことなどを伝えます。これは、クライアントがWebsoketを利用した時に使われるものです。
上記でcatapult.brokerが、 「version0.4.0.1(Dragon)から登場した」 と書きましたが、これは元々catapult.server(api extensions)に含まれているものでした。ただ、mongoDBへの書き込みに時間がかかることがAPIノードが同期する時のボトルネックになるということで、version0.4.0.1からは別のプログラムとして分離されました（下記参照）。
ちなみに、ZeroMQは、非同期でメッセージを送り合いたい時にすごく便利で高性能なヤツだと思ってください。
catapult rest
catapult restは私達がウォレット等を使って直接通信する相手になります。
catapult restはcatapult.brokerがデータベース（mongoDB）に記録してくれた情報を読み取ったり、catapult.serverからノードの情報を貰ったりしながら、クライアントのリクエストに答えます。クライアントから受け取った新しいトランザクションをcatapult.serverに渡すのも、このcatapult restの役割です。
また、クライアントがWebsocketを利用してブロックチェーンの監視をしているときに、catapult restはクライアントが欲しがっている通知を、catapult.brokerから受け取って通知します。
クライアント
クライアントは、ウォレットやエクスプローラなどのアプリのことです。
最後に
以上がAPIノードの中で動くプログラム（+クライアント）の役割とそれらの関係ですが、色々なプログラムがそれぞれ非同期的に連携してひとつのノードを作っていることが分かるかと思います。
これらが分離していることには大きなメリットがあり、例えばcatapult restに修正を入れたいと考えた時に、現状一つのノードの中にP2Pの役割とAPIサーバーの役割を抱えているNEM1ではノード自体の更新をする必要があるのに対し、NEM2(catapult)では分離されているcatapult restの部分だけを更新すれば良いことになります。これがネットワークの堅牢さに貢献することは容易に想像がつくと思います。
その反面として、外から見た時に複雑に見えてしまいますが、NEM2として一般に向けてリリースされる時には、扱いやすいよう適切にパッケージされるのだろうと考えています。
いろいろURL貼っておく
Githubリポジトリ
https://github.com/nemtech
NEM Developer center
https://nemtech.github.io
この記事に書いてあることはこの辺の内容とかぶる
https://nemtech.github.io/ja/concepts/node.html
https://nemtech.github.io/ja/server.html
NEM slack 疑問やバグの疑いのあるものは一度ここに投げるのが吉(日本語のチャンネルもあるよ)
https://join.slack.com/t/nem2/shared_invite/enQtMzY4MDc2NTg0ODgyLTFhZjgxM2NhYTQ1MTY1Mjk0ZDE2ZTJlYzUxYWYxYmJlYjAyY2EwNGM5NzgxMjM4MGEzMDc5ZDIwYTgzZjgyODM
その他もろもろリンク集
https://github.com/mijinc0/my-catapult-docs/blob/master/reverse_lookup.md