イマドキの「Docker力」を身につけるPLAID式チュートリアル

<html><head></head><body>こんにちは、プレイドの @nashibao です。今回は少し前に話題になった <a href="https://metaparticle.io/tutorials/javascript/" target="_blank" rel="noreferrer">Metaparticle</a> というプロジェクトについて紹介します。
<code>Metaparticle</code>は <code>a standard library for cloud native applications on Kubernetes.</code>と唄っていますが、要はjava/javascript/goなどのapplication code上にdocker/k8sのInfrastructure/Orchestrationのうち、Applicationとして関心がある部分は組み込んでしまおう、というプロジェクトです。
多機能のサービスを開発していると、様々なところで有限のベストプラクティス（ただし単一では無い）に沿ったDistributed Programmingをして堅牢性や冗長性を高めたり負荷分散をしたくなります。
ただ、これらを実現したいと考えて設計/実装をするのは多くはApplicationエンジニアですが、Infrastructure/Orchestrationの様々なツールがその間に横たわっていて機動性が失われてしまいます。
<h1 id="CloudのThread/ProcessとしてのContainer">CloudのThread/ProcessとしてのContainer</h1>
Threadは扱いやすいです。パフォーマンス等を考えて様々なパターンを駆使して劇的にApplicationのパフォーマンスを上げることができます。
Processは？そこまで隔たりはありません。プレイドで好んで使っているNode.jsでいえば <a href="https://nodejs.org/api/cluster.html" target="_blank" rel="noreferrer">Cluster</a> moduleを使うだけです。
<pre><code class="hljs">const cluster = require('cluster');
if (cluster.isMaster) {
 // master
 cluster.fork();
} else {
 // worker
}
</code></pre>
ThreadもProcessもどちらもworkerへの分散には色々なパターンがあって、それらを使うと並列性が高いプログラムを容易にかけます。iOSの<code>NSOperationQueue</code>などその代表ですが、各言語に様々なパターンがあります。そしてこれはApplicationエンジニアの手元にあって自由に設計できます。
Containerは？yamlの世界、kubectlの世界です。Applicationエンジニアの手元にあるように見えて遠くに行きがちです。PortとVolumeがコントロールされていて、古き良きPubsub/Queueやmessaging用の各ツール（zeromqは好きだ）を使って自由に協調はできますが、言語が異なる他のPlatformというものが邪魔をします。
<h1 id="Language idiomatic cloud">Language idiomatic cloud</h1>
分散性をある程度ラップしつつ、コントローラブルにするアプローチは昔からあって、例えば <code>MapReduce</code> があります。<code>Metaparticle</code>と目的は似ているがPipeline状のData処理に特化している所が異なります。<code>PySpark</code>を使うとlambda関数を単にローカルで動かしているのと同じように見えます。<code>Google Dataflow</code>や<code>Apatch Beam</code>もまま似てる。
Microservice流行りで、<a href="https://aws.amazon.com/jp/lambda/" target="_blank" rel="noreferrer">AWS Lambda</a>や <a href="https://cloud.google.com/functions/" target="_blank" rel="noreferrer">Cloud Functions</a> のような便利なツールが出てきてるので <a href="https://github.com/pywren/pywren" target="_blank" rel="noreferrer">pywren</a>のように、それらをwrapしちゃえば良くね？みたいなアプローチもあります。
<pre><code class="language-python hljs"> def my_function(b):
 x = np.random.normal(0, b, 1024)
 A = np.random.normal(0, b, (1024, 1024))
 return np.dot(A, x)

 pwex = pywren.default_executor()
 res = pwex.map(my_function, np.linspace(0.1, 100, 1000))
</code></pre>
サイトに書いてあるコードそのままだけれど、中が同一スレッドだろうが、別プロセスだろうがAWS Lambdaだろうが同じようなマナーで書けます。
<h1 id="Metaparticle">Metaparticle</h1>
<code>Spark</code>や<code>pywren</code>はかなり抽象化されていて、やれることも制限されますが（その代わりパフォーマンスに焦点がある）、<code>Metaparticle</code>はもう少し自由度に焦点があります。つまりdocker/k8sのconfigへcompileするためのメタ言語のようなものです。
<pre><code class="hljs">const mp = require('@metaparticle/package');

mp.containerize(
	{
 	ports: [8080],
 	replicas: 4,
		 runner: 'metaparticle',
		 repository: 'docker.io/docker-user-goes-here',
		 publish: true,
		 public: true
	},
	() =&gt; {
		// closure for each workers
	}
);

</code></pre>
これだけです。これを素で使っても良いけれど、先ほどいった有限のパターンについては <code>standard library</code>なので当然提供する。sharingなら
<pre><code class="hljs">const http = require('http');
const os = require('os');
const mp = require('@metaparticle/package');

const port = 8080;

const server = http.createServer((request, response) =&gt; {
	console.log(request.url);
	response.end(`Hello World: hostname: ${os.hostname()}\n`);
});

mp.containerize(
	{
		ports: [8080],
		shardSpec: {
			shards: 3,
			"urlPattern": "\\/users\\/(.*)[^\\/]"
		},
 repository: 'docker.io/your-docker-user-goes-here',
 publish: true,
 public: true,
		runner: 'metaparticle',
	},
	() =&gt; {
		server.listen(port, (err) =&gt; {
			if (err) {
				return console.log('server startup error: ', err);
			}
			console.log(`server up on ${port}`);
		});
	}
);
</code></pre>
だし、electionなら
<pre><code class="hljs">var mp = require('@metaparticle/sync');

var election = new mp.Election(
 // Name of the election shard
 'test',
 // Event handler, called when a program becomes the leader.
 () =&gt; {
 console.log('I am the leader');
 },
 // Event handler, called when a program that was leader is no longer leader.
 () =&gt; {
 console.log('I lost the leader');
 });

election.run();
</code></pre>
という感じです。上に書いたように、ここは有限のパターンがそれなりにあるので、それらが今後作られていくのだろうと思うが今の所ほぼ上の二つくらいしか書かれてないw
<h1 id="感想">感想</h1>
thread/processとのアナロジーなどからContainerが扱いやすくなることについて書きましたが、<code>metaparticle</code>自体はdynamicにcluster/podを変更するわけではありません。scriptでdynamicに変更できるようになると、より上記のアナロジーがハマり、k8sに乗っかったままかなり柔軟に分散プログラムが書けると思ったりします。 
プレイドでも下手にクラスタ管理や組込済みの単純なオートスケールを使うより、nodeのgcp/api経由でインスタンス数の増減をさせるやり方をやってみたりしつつ、なんか違うな、と思ったりしていますw
今回は<code>a standard library for cloud native applications on Kubernetes.</code>な<code>Metaparticle</code>を紹介しました。個人的にはこのアプローチの先にDistributed Programmingの桃源郷があるのかもしれないし無いかもしれないと思っています。
CXプラットフォーム「<a href="karte.io">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。詳しくは<a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">こちら</a>（Wantedly）をご覧ください。
</body></html>

こんにちは、プレイドの @nashibao です。今回は少し前に話題になった [Metaparticle](https://metaparticle.io/tutorials/javascript/) というプロジェクトについて紹介

Kubernetes to Metaparticle. 分散プログラミングへの新しいアプローチ