Microservice と Container技術 と Entropty
Microserviceは最近様々な、企業で適用されている。
Microserviceは、いわばプログラム間の連携方法に制約をかして、プログラム全体のエントロピーをさげる行為である。
このようなパターンは数多く存在していた、例えば
共通していえるのは、適した抽象化をしながら自由度を下げて、制御しやすいシステムを実現するという事である。 自由度がさがるので、パフォーマンスや表現力をある程度犠牲になるが、一方で制御しやすさをえるわけである。
このようなパターンはシステム以外でも例はある。例えば
- DNA による生物情報の保存
- 機会学習による特徴量削減
これらも同じような考え方に基づいている。表現力を犠牲にはなるが、結果として制御しやすい構造を得る訳である。 DNAは生物の情報としては不完全である。 それをコピーしたから全く同じ人間がそだつわけではない。
ただ次元を落とす事によって、コピーのしやすさや、進化のしやすさ、保存のしやすさといった制御のしやすさの恩恵を得ているのである。
Microserviceはプログラム内の連携を限定されたendpointによるHTTP callのみに制限する等してプログラム全体のエントロピーをさげている。 このようにすることで、我々はたくさんの恩恵を得ている訳である。
一方で、インフラ面からみるとエントロピーは増加してしまう。
モノシリックなApplicationのインフラのパラメーターは少なくすむ。 新規の構築もないし、プロセス数や、サーバー数くらいをコントロールしていればおおまかなニーズは足りる。 急激な負荷がきたらサーバーをふやすというシンプルさである程度の問題は解決できる。 しかしMicroserviceになると、インフラの自由度(エントロピー)は格段にあがってしまう。
パラメーターの数は単純にServiceの数倍される。 それだけのリリース行為があるし、しかも各パラメーターは相互に依存してしまうので、事態はもっと深刻になる。
例えば、リソースを使い切ろうと思ったら CPUボトルネックのapplicationとMemoryボトルネックのapplicationを同じサーバーにいれたいとか、相互に依存度の高いApplicationは同じサーバーにあった方がいいとかそういうった事情によりインフラの自由度は格段にあがるのだ。
このような状況に対応するのはコンテナ技術である。つまり、人手でインフラをサーバー単位で管理するのを辞めてしまい、Application単位(コンテナ)で管理する事とし、各コンテナの依存関係や、実際のサーバーのリソース調整はすべてオーケストレーションツールに任せる(このコンテナ同士はちかくにあるといいな。ちらちら。みたいな)。
もちろんそれをする上で Heroku - 12 Factor App - モダンなサービス運営に必要な12のインフラ的要素 - Qiita
のようなApplication側の制約は発生するがエントロピーがどんどん高くなってカオス化していくインフラを社内独自のシステムをメンテしながら管理するよりは格段に幸せだし、そのようなシンプルさが実現できれば 自然とクラウドを使ったサービスのScaleoutとかも可能である。
コンテナ技術を本番で使うという行為はMicroserviceを実現する上では必須な要件となってくると思う。
それをしない限りインフラのエントロピーがどんどん増加し、管理コストが増加し人々は疲弊してしまう。 というわけで今年はコンテナとそのオーケストレーション周りの動向をおいつつプロダクトを作りたいと思う昨今である。
なむ
