マイクロサービスに関する個人的なメモ

Posted at 2019-05-14

自社でマイクロサービスの導入を検討してて、色々調べたり下記のイベントで話を聞いた内容を元に個人的にまとめてみました。

マイクロサービスとは？

1つの事業を構成する各機能(例:ログイン、通知、認証、etc)を、機能単位で独立したサービスとして実装したもの。

エンジニア組織のスケールに伴い、多数のチームで一つのモノリスシステムを扱うにはリリース調整や品質保証などの本質的でない部分のコストが増加してしまう。

マイクロサービスの場合、モノリスとは異なり他チームとの調整にかかる手間が少なく、品質についてもモノリスより限定された範囲のみを保証すれば良いのでテストがしやすいため、リリース調整や品質保証などのコストを抑えつつ、本質的な機能の開発に注力できるようになる。

そのため、組織の拡大を見据えて、マイクロサービスを導入する企業が増えてきている。

リリース単位が小さくなりリリースサイクルが早まる=改善が速くなる
- テスト範囲が小さくなるのでテストの実行速度も上がる
チームメンバーがプロダクトに対するオーナーシップ(当事者意識)を持ちやすくなる
- フィードバックループが回しやすくなる
認証などの共通機能をマイクロサービス化することにより再利用性が向上する
- 新規のプロダクトが増える場合などに恩恵あり
コミュニケーションコストの改善(マイクロチームになった場合)
- 関心と責務の範囲がサービス内で閉じられるので他サービスとの調整コストが不要
サービスごとの最適技術適用
- リソース、セキュリティレベル等に応じて得意な技術を選択することができる
一時的なアクセスの集中などにたいして必要な部分だけを最適な形でスケール可能
モノリスに比べ、本質的な部分の開発にかけられる工数が増える
- リリース調整や品質保証などのコストが抑えられるため
一つのチーム内でアプリケーションの実装だけでなくインフラも含めた管理ができる（共通基盤チームがない場合）
- アプリケーション以外の改善手段も選択肢として選択しやすくなる
- アプリケーション以外も触る機会ができ、エンジニアの育成のつながる

分散トランザクション管理
- 課金サービス、ポイントサービス等で別れてた際のトランザクションの管理
  - どっちかのサービス失敗したらもう一方のサービス戻すとかの仕組みが必要
- サービス内でトランザクションが完結される(できる)なら考慮せずに済む
運用管理の複雑化
- CI/CDや自動化による効率化にかけるコストが必要
- なるべく共通の運用管理手法をサービスで共有した方がいい
  - サービスごとの最適技術適用とは相反するが
  - コンテナクラスタだとやりやすい
- サービス分割の単位誤ると運用管理コストだけ増えて死ぬ
障害解析のコスト
- 障害箇所の特定のためにサービスをまたがることも
- モニタリング、ロギング重点
マイクロチーム化によりチーム間の関係が疎になる
- 担当しているサービス以外の修正に関してはやりづらくなる
マイクロサービス間通信コストによるパフォーマンス低下
チーム数、サービス数が増えるため統制のコストが発生
機能によっては開発するやりがいが失われる
- 限定的な部分にのみ関わることになり、ビジネスへ貢献できているかがわかりづらくなる可能性がある

モノリスなシステムからデータストアなどを切り出してマイクロサービスを作る場合、一度データストアを切り出してしまうとロールバックが難しいため、事前のデータモデリングに時間をかけて慎重に設計した後で切り分けたほうが良い

例えば、これ以上の成長が難しい、これ以上の機能拡充が見込めないようなビジネスの奥行きがない事業の場合、マイクロサービスに分割したからと言ってそのメリットを享受しづらい

モノリス→マイクロサービスへの移行にはエンジニアの工数等のコストがかかる
そのコスト分がすぐにビジネスへ還元されるわけではないため、マイクロサービスへの移行時にはその目的と長期的に見た際のビジネスへの貢献などを説明した上で、ビジネスサイドからの同意を得る必要がある
- ただ、新規機能で試す場合は同意いらないかも
マイクロサービスの改善速度を最大化する際には組織（エンジニア以外も含む）もマイクロサービスに合わせる必要があるため、その場合にもビジネスサイドの協力は必須