最近になって妙に聞くことがあるMicroservicesの話です。
詳しくは、Martin FowlerさんのMicroservicesを読みましょうという話なのですが、幸いQiitaあたりでも探してもらえれば、該当のキーワードで皆さん学べると思いますので、基礎概念については触れません。
まだまだ、私も勉強を進めている所ですので、忌憚の無いご意見をお待ちしています。
ここでは、AWSのLambdaとAzure Service Fabricを比較してみようと思います。Dockerに関しては、今回はあえて割愛をします。
マイクロソフトのMicroservice開発用PaaSが素敵だった件
AWSにおけるマイクロサービス実装? Lambda
言わずもがな、Lambdaは前述の記事である、AWSのサーバレスアーキティクチャがすごそうなので、Azureでできるか考えてみた！でも読んでもらえると良いのだが、いわゆる常駐型ではなく振り分けられた稼働中インスタンスに対して、プロセスを起動しある一定時間許容する事でプロセス管理を行う、稼働中のプロセスのハングアップや高いCPU利用時間の場合に他のプロセスに影響を与えにくい。
メリット
- プロセスは定期的にリサイクル（プロセスが停止、プロセスは再度稼働）するので、プロセスの健全性を保ちやすい
- 常に常駐するわけではないので、CPUやメモリはユーザ同士で共有するモデルを作りやすい
デメリット
- プロセスの起動時間が初回起動の場合は遅い
- ステート（セッション）維持の方法が提供されない
- フェイルオーバーが無い（プロセスが何らかの問題で損失した場合、他のインスタンスでの次のリクエストを待つしかない）
初回のプロセス起動まで最大8000msec(8秒）程度かかるとして、かなり長い時間になる可能性が考えられます。
IoTなどの処理をストリームをLambdaで処理するケースなども見かけるが、Kinesisに大量並列のストリームデータが入ってくる場合、1秒間あたりのコネクションとストリームバッファの量はがどれくらいになるのか？は考慮しないといけない事になります。
初回はタイムアウトなんて話もあってもおかしくは無いので、呼び出せる信頼性については考慮しておかないといけない事項でしょう。
Azureにおけるマイクロサービス実装 Azure Service Fabric
AzureもService Fabricと呼ばれるマイロサービス向けサービスを提供している。どのように動作するのか解説はしていないので、この機会に簡単に解説します。
幸い、Azure Service Fabricについてのスライドが、Apache CassandraのEnterprise版を提供しているDataStax社のスライドから出てきましたので、このスライドの10ページを流用します。
以下の図をじっくり見てください、これはIaaSとAzure Service Fabricでの比較です。
- API1 は薄赤色 6台
- API2 は緑色 9台
- API3は黄色12台
- API4は紫色12台
- API5は水色6台
少々大げさなクラスタですね、45台ものIaaSインスタンスが稼働しています。マイクロサービスにおける可用性や耐障害性を考えると、IaaSだとこうならざる得ないと思いますし、案外現実的な話かもしれません。
Azure Service Fabricの場合で同じ45台考えてみたのが、この右の図面です。
ここでは、赤色の六角形はインスタンスの中で稼働するとあるAPIを返却するプログラムのプロセスで、IaaSの赤色のクラスタと同じAPI1が稼働しているとします。
- API1 は薄赤色 18台 (IaaSは6台）
勘の良い方は気が付くと思いますが、45台のクラスタで18プロセスを分散配置するって事を行っているわけです。IaaSの6台に比べれば、18台が同時にダウンする事は当然ないでしょうし、6台で動くよりも18台で動いてAPI受付してくれる方が良いのは明らかでしょう。
そして、Service Fabricらしい特徴があります。詳細な動作はあえて割愛しますが、右のAzure Service Fabricの下にStatefulって書いてあります。
18台で処理している内の1台のインスタンスがダウンする事を頭の中で想像してみてください。
他の稼働している17台のプロセスのいずれかに
処理の一貫性を維持したままフェイルオーバーします
プロセスがフェイルオーバーするとかちょっと萌えますね、しかも一貫性を保証します。
メリット
- プロセスはフェイルオーバーするので、耐障害性が高い
- マイクロサービス個別にクラスタを用意するのでは無く、クラスタ群を作り、そこに複数のマイクロサービスをデプロイ可能
- プロセスは常駐しているので、起動時間は早い
- プロセスはフォールトドメイン分散させているのでスケールアウト、スケールインしても最小クラスタ台数までなら可用性は維持される
デメリット
- 現在はLinuxで動かない
（任意のLinuxクラスタにデプロイする方法が提供される予定みたいです） - 現在は.NETしかSDKが無く、VSとWindows環境での開発しかできない
（今後、JavaやNode.JSなどもサポートされるみたいなので、他プラットフォームでの開発環境整備に期待） - Azure以外のクラスタに展開できない
（今後、任意のクラスタに展開可能になるので、Service Fabric on AWS、オンプレミス on Service Fabricみたいな事もできそうですね） - インスタンスにデプロイする各プログラムのCPUやメモリなどのコストに対する、キャパシティプランニングが複雑になりがち
インフラエンジニアだった僕の視点から考えるService Fabric
日ごろ私感をブログに書かない私ですが、Service Fabricなどの存在は、インフラエンジニアだからこそ意識しておくべき事と思っています。
今までは、預かったアプリケーションを正しく稼働させ、運用すればよかったわけです、インフラエンジニアはその為にSPOFを把握し、にフェイルオーバークラスタを構築、アプリケーションをインフラで支えてきました。
しかし、Service Fabricによって、そもそもインフラの構築や構成が不要で、プログラマが開発環境から直接クラスタをテンプレートによって展開し、デプロイメントできる環境ができます。
これは、Azure App Service （旧 WebSites）でもそうなのですが、自動でフェイルオーバーし、ダウンする事も無く、且つ自分が構築したIaaSクラスタより耐障害性が高いマルチテナントクラスタ、開発者やユーザーがいとも簡単に入手する時代が来る事はそう遠くない現実の話と考えるべきでしょう。
