マイクロサービスとオプション性

タレブの反脆弱性をネタに今度はマイクロサービスを語ってみる。今回も思考実験である。大まかにはオプション性について議論する。もっとも、タレブの言うように「鳥の飛び方を人が解説する」ような話なのであまり信じないように。

オプション性

オプション性というのは「投資をすることで将来に利得を確率的に得る」という話と理解している。オプション性には負のオプション性と正のオプション性がある。負のオプション性は将来起こりうる損害・破綻に対するリスクヘッジを行うこと、正のオプション性とは偶然利益を得る可能性を投資によって拡大することである。

マイクロサービス

ざっくりいうとサービスを分割することで開発効率や開発速度を上げようって話がマイクロサービスだ。Netflixなんかの例だとビルドに１日かかるようになって素早さを失ったので分割しましたという話だし、cockpadもそんな話をしていた気がする。そうするとまぁそんな話なのだが....

分割するとだけ説明すると所謂Service-Oriented-Architectureとどう違うの？昔からあったよね？という話になりがちだが、「素早さ」の基準が１ランクあがってるのとクラウドを使い倒す色々なハックが組み合わさって別の世界観になっているという理解をしている。何故こんな事をするのか、何が可能にするのか、世界観をオプション性を軸に考えてみる。まずは正のオプション性から。

正のオプション性

マイクロサービスでは各ビジネスドメインを預かるチームがそれぞれの都合とスピードで機能をリリースすることを期待する。そうするとリリース回数が増える。リリース回数が増えると「良いことが起きる確率」が上がる。単純にはそう考えられる。

モノリシックな巨大アプリケーションでは思い切った挑戦や試行をする機会が限られる。良いことはリリースをするタイミングでしか起きない。いろんな制約に縛られることもあるだろう。マイクロサービスでは試行回数があげられる。リリースが増える。そして、試行の結果は観測される。結果の観測とマイクロサービスはワンセットだろう。ビッグデータ解析等も含めてウェブのUX向上について知見が溜まりつつあり、クラウドでを活用できる昨今、試行回数を増やし、観測し、挑戦できる状況を増やすことは正のオプション性を高める方向に働く。マイクロサービスは正のオプション性をシステムに取り込む事を可能にする。

しかし良いことがおきる確率と悪いことがおきる確率は同じじゃないか？

負のオプション性

APIで互いに通信する独立したチーム...というと悪い予感しか働かない。互いがDOSアタッカーであり信用ならない。モノリシックでは時間をかけてテストし、リスクを０に近づけてリリースするのが方法論だろう。リリース前に三ヶ月テストとかね。

リスクヘッジの能力を高めることでリスクを吸収しつつリリースを継続することができる。ロールバックもそうだし、Blue-Greenデプロイメントやカナリアデプロイメントなどもそうだし、UX悪化を素早く知るのも、スケールアウトも、サーキットブレイカーもそうだろう。そういった技術を組み込むことでリスクに対してしなやかに対応し、負のオプション性を獲得するシステムがマイクロサービスなのではないか。わざわざ分割してなんで面倒な手続きをするのかと思う人もいるだろうがこれができないと試行回数が上がらない。

オプション性を軸にした世界観

計画的に物事を進めるのはそれはそれで大事だが1.0の価値をもたらす計画が1.0以上に化ける可能性は少ない。

「何かが起こる」事を期待して試行回数を増やす、そのためのリスクヘッジのハックと評価と計画がマイクロサービス的世界観なんじゃないか。

まぁ自分で実践してないので浮ついた話だが。