マイクロサービスのメリット・デメリット ~ 議論し尽くされていることを再考してみる ~
はじめに
マイクロサービスを幾つか開発した過程で、マイクロサービスのメリット・デメリットを自分自身の言葉で再考してみました。 おそらく、書籍・他の方の記事で散々言及されていることと繰り返しになってしまうと思います。それでも、自分の体験として残しておきたいので記事化することとしました。
マイクロサービスにすることで生まれる変化
マイクロサービスにすることで起きる変化は、サービスごとに実行環境ができる分離 / プロセスの分離（処理の独立性の向上）の２つかなと思っています。 メリット・デメリット双方が生まれます。
サービスごとに実行環境ができる分離 / プロセスの分離（処理の独立性の向上）
サービスごとに実行環境が異なります。また、サービスごとにプロセスが独立します。
下記のような変化が起こります。
- サービスごとに技術を選定する
- サービスごとにプログラムが分離
- サービスごとに個別のデプロイをする
- サービスごとにコンピューティングリソース・スケーラビリティを選定する
- サービス間の通信がインターフェイスのみに依存して疎結合になる
- 他のサービス処理が完了するまでの待機が不要になる
メリット：
サービスごとに最適な技術を選定できる
サービスごとに最適な技術を選定できます。例えば、機関システムはphpで実装していたが、一部のマイクロサービスは機械学習のライブラリを利用したいから、pythonで実装したいというケースなどがあります。
チームの独立性が向上する
ブログラムが分離されているため、他のサービスの改修やデプロイタイミングの影響は受けません。なのでサービスごとに、完全に分離した開発プロセスを担保することできます。
サービスごとにコンピューティングリソース・スケーラビリティを最適化
サービスごとに必要なリソースを分離できます。モノリシックな場合は、重たい処理に準拠したリソースが求められます。ただし、処理によっては垂直スケールを求めないサービスもあるはずです。サービスに応じて、最適なリソースを分配することでリソースの最適化が可能です。
単一障害点を回避できる
特定の処理によってインフラに障害が発生した場合に、サービスごとにリソースが分離していれば特定サービスのみに障害を閉じ込めることが可能です。
サービス改修コストが下がる
疎結合な関係になっていることで他のサービスはカプセル化されます。他サービスについてはインターフェイスしか把握せず、ビジネスロジックは把握しません。つまり、特定サービスのロジックのみを変更する場合にはインターフェイスが変わらないのであれば、リクエスト側の改修は不要です。
デメリット：
複数サービスを同じタイミングでデプロイする難易度が上がる
サービスの更新において、互換性が担保されていない場合には同タイミングでのデプロイが求められます。完全にリソースが異なるので、同タイミングでデプロイすることが難しくなります。
インフラ管理のオーバーヘッドが増加する
純粋にインフラリソースが増えます。マイクロサービス毎にリソースが増えるので管理する工数が増えてしまいます。 管理するインフラが増えるのでインフラコストが増える可能性もあります。ただし、モノリシック環境にて不必要にスケーリングしている場合にはインフラコストの削減ができることもあるでしょう。
データ一貫性を確保する難易度が上がる
マイクロサービスでは、データが各サービスごとに分散されるため、ACIDトランザクションのような一貫性の保証が難しくなります。
例えば、ユーザーが「商品購入 → 在庫更新 → 支払い確定」という処理を実行した場合、モノリシックでは単一のデータベースでトランザクションを管理できますが、マイクロサービスでは 分散トランザクション の仕組みを考慮する必要があります。
DBトランザクションの管理でデッドロックが起きる可能性が上がる
複数のマイクロサービスが同じデータを異なるタイミングで操作すると、 デッドロックの発生リスクが高まります。
複数DBストアの管理オーバーヘッドが上がる
マイクロサービスごとにDBを管理するアーキテクチャを取るケースがあります。 その場合には、管理・費用の両面でコストが増加する可能性が高まります。
ログ・監視の難易度が上がる
マイクロサービスでは、サービスが分散するため、従来のモノリシックなログ管理とは異なり「全体のログを横断的に追う必要がある」 という課題が発生します。ユーザーにとっては一連の処理だとしても、インフラとしては別々のインフラリソースに分散しています。 一連の処理の中で問題が発生した場合に、どのサービスが問題なのかを横断的に管理する難易度が上がります。
Discussion