モノリシックとマイクロサービスの比較 メモ

概要

自社でコンテナを使ったマイクロサービスについての記事を作成する取り組みがあり、
その過程で物知りっくとマイクロサービスの比較について記事を出している人がいたので便乗してみようと考えをまとめてみました。
以前あったAWS Innovate2021の内容の受け売りだったししますが・・・

システムの構成

• モノリシックの例
  

• モノリシックなシステムはすべてのサービスが一つの塊として存在している

• 後述のマイクロサービスのようにサービス間の連携は不要のためサービス間の連携がボトルネックになることはない

• ただし変更する際にはシステムすべてを変える必要がある

• マイクロサービスの例
  

• 各サービスごと別に分かれている

• サービス間を連携させるためにひと工夫が必要で状況によっては情報のやり取りがボトルネックになることも

• 以下の点で基本的にモノリシックなものより有利になる

  • 変更容易性
    • 変更する際はサービス単位で変更を行うことができるので変更範囲が小さくできる
  • 俊敏性
    • 各サービスごとに処理が分かれているためそれぞれ別に処理を走らせることができる
  • 拡張性
    • 水平拡張が可能なためインスタンスのタイプでの頭打ちなどはない
  • 回復性
    • 問題が起こってもサービスだけに限ることができる
  • 影響範囲の局所化
    • 前述のとおりサービスが分かれているため影響もそこで抑えられる
  • デプロイ時間の短縮
    • 全体をデプロイする必要はないため基本的に早くなる

モノリシックからマイクロサービスへの移行手順

• モノリシックからマイクロサービスに切り替える場合以下のアプローチが考えられます
  • 一気に作り変える
    • 現在動いているシステムをとめて一気にタイミングを決めて切り替える場合に取る手順です
    • 中身を個別に切り出すことができないけどマイクロサービスに切り替えたい場合に思い切って実施することができる
  • 段階的に切り分ける
    • クライアントとサーバの間にAPIGateWayを配置しサーバ側を徐々に切り替える手順です。
    • 切り替える際にアプリをコンテナにしたりサーバレスにしたりそこは状況に応じて設定します。
    • 徐々に切り替えていき最終的に古い部分を削除することで切り替えを完了します。

サービスを切り出す時に検討すること

• サービスとして切り出す際にはやみくもに切り出すのではなく以下の観点で切り出していくことがよさそうです。
  • 分解のし易さが高い
  • 分解によって得られる価値が高い
• 逆に分解しづらいところは分解せずにあえてそのままで進めるという方法の方がよさそうです。
• また得られる価値が低い場合は投入するコストに見合わないため辞めておくのがよさそうです。
• マイクロサービス化する際にはサービスごとに独立できること(変更を行った際に別のサービスも修正する必要があるようなケースは避けるべき)
• AWSであればサービス間の結合を疎結合にさせるため以下のサービスを活用していくことを考える
  • Amazon SNS
  • Amazon SQS
  • AWS Lambda

最後に

ひとまずモノリシックとマイクロサービスについての簡単な比較とモノリシックからマイクロサービスに切り替えるときの進め方を記述してみました。もうちょっと具体例をあげられるようになったらつづきを記載してみようかと思います。