【自分用メモ】マイクロサービスの概要を読んで
google様が素晴らしいドキュメントを公開しているので忘れないように自分用メモ。
自分のコメントはこの色で記述しています。
直接ドキュメントを読むことをおすすめします。
cloud.google.com
モノリシックアプリケーション
モノリシックアプリケーションは、さまざまなモジュールが 1 つのプログラムに結合される単一層ソフトウェアアプリケーション
モノリスの長所
モノリシックアーキテクチャは、アプリケーションを構築するための従来のソリューション
- ツールを使用して、モノリシックアプリケーションのエンドツーエンドのテストを実装できる
- モノリシックアプリケーションのデプロイは、パッケージ化されたアプリケーションをサーバーにコピーするだけでできる
- モノリシックアプリケーションのすべてのモジュールがメモリ、容量、リソースを共有するため、ロギング、キャッシュ、セキュリティなど、横断的な問題に単一のソリューションで対応できる
- モノリシックアプローチでは、モジュールが直接相互を呼び出すことができるため、パフォーマンスが向上しやすい
モノリスの課題
複雑なモノリスでは、ビルド、デバッグ、論証が次第に困難になる(めっちゃ、わかる)
- 異なるモジュールでリソース要件が競合している場合、スケーリングが難しくなる
- すべてのモジュールが同じプロセス内で実行されるため、メモリリークなどのモジュールのバグにより、システム全体がダウンする可能性がある
- 新しいフレームワークと言語を採用する場合、モノリシックアプリケーションは、より複雑になる。例えば、新しいフレームワークを使用するようにアプリケーション全体を書き換えると、そのフレームワークが著しく改善されていても、時間の面でもお金の面でもコストがかかる
マイクロサービスアプリケーション
マイクロサービスは、それぞれが独自のアーキテクチャとビジネスロジックを持つミニアプリケーション
- アプリケーションとデータベース間の関係が大幅に変化する
- 1 つのデータベースを他のサービスと共有するのではなく、各サービスで要件ごとに最適なデータベースを用意することを推奨
- サービスごとに 1 つのデータベースがある場合、データに対するすべてのリクエストは共有API ではなくサービス API を経由するため、サービス間の疎結合が発生する
マイクロサービスの長所
モノリスの課題である複雑さの問題に対処できる
全体的な機能は同じだが、マイクロサービスを使用して、アプリケーションを管理可能なチャンクやサービスに分割
各サービスには、RPC またはメッセージドリブンのAPIの形式で明確に定義された境界がある
- 個々のサービスで開発時間が短縮され、把握と保守が容易になる
- 自律型チームは個々のサービスを個別に開発できる
- プロダクトの技術的能力ではなく、ビジネス境界を中心にマイクロサービスを編成できる
- 開発からテスト、デプロイ、メンテナンス、モニタリングに至るまで、割り当てられたソフトウェアのライフサイクル全体にわたって単一の独立したチームを編成できる
- 開発者は異なるプログラミング言語で各マイクロサービスを作成し、多言語で記述されたアプリケーションを作成できる
- マイクロサービスごとに最も効果的な言語を使用すると、アプリケーションをより迅速に開発し、アプリケーションを最適化してコードの複雑さを軽減し、パフォーマンスと機能を向上させることができる
- 機能をモノリスから切り離すことにより、独立したチームによるマイクロサービスの独立したリリースが可能になる
- 独立したリリースサイクルで、チームの開発スピードと製品化までの時間を改善できる
- マイクロサービスアーキテクチャでは、各サービスを個別にスケーリングできる
- 容量と可用性の制約を満たす各サービスのインスタンスを大量にデプロイできる
- サービスを個別にスケーリングすると、システム全体の可用性と信頼性が向上する
マイクロサービスの課題
- アプリケーションが分散システムであることで生じる複雑さ
- デベロッパーは、サービス間通信メカニズムを選択して実装する必要があるサービスで、アップストリームサービスの部分的な障害と使用不能性も処理する必要がある
- 異なるマイクロサービス間でトランザクションを管理する必要がある(分散トランザクション)
- 複数のビジネスエンティティを更新するビジネスオペレーションは一般的であり、通常、すべてのオペレーションが適用されるか、すべてが失敗するかのアトミックな方法で適用される
- 単一のデータベーストランザクションで複数のオペレーションをラップすると、アトミック性が保証される
- マイクロサービスベースのアプリケーションでは、ビジネスオペレーションが複数の異なるマイクロサービスに分散される可能性があるため、さまざまなサービスが所有する複数のデータベースを更新する必要がある
- 障害が発生した場合、さまざまなマイクロサービスの呼び出しの失敗または成功を追跡し、状態をロールバックすることが重要
- 最悪のシナリオでは、障害による状態ロールバックが正しく行われない場合、サービス間にデータの不一致が生じる可能性がある
- マイクロサービスベースのアプリケーションの包括的なテストは、モノリシック アプリケーションのテストよりも複雑
- マイクロサービスベースのアプリケーションのデプロイは、モノリシックアプリケーションのデプロイよりも複雑
- マイクロサービスアーキテクチャでは、モニタリングとアラートを行うサービスが増えるため、運用のオーバーヘッドが増加する
- マイクロサービス アーキテクチャでは、サービス間の通信が増えるため、より多くの障害点が生じやすい
- モノリシックアプリケーションを、小規模なアプリケーションサーバークラスタにデプロイする必要がある
- マイクロサービスベースのアプリケーションでは、複数の言語や環境でビルド、テスト、デプロイ、実行を行う個別のサービスが多数存在する場合がある
- これらのサービスはすべて、フェイルオーバーと復元力のためにクラスタ化する必要ある
- マイクロサービス アプリケーションを製品化するには、高品質のモニタリングとオペレーションのインフラストラクチャが必要
- マイクロサービスアーキテクチャでサービスを分割すると、アプリケーションでより多くの機能を同時に実行できる
- モジュールは分離サービスとして実行されるため、サービス間のネットワーク呼び出しのためにレスポンス時間にレイテンシが発生する
- すべてのアプリケーションがマイクロサービスに分割できるほどの大きさであるわけではない
- リアルタイムのデータの高速ストリームを処理する必要があるアプリケーションなどはコンポーネント間の緊密な統合が必要
- サービス間に通信レイヤが追加されると、リアルタイム処理が遅くなる可能性がある
- サービス間の通信を事前に考えておくと、サービス境界を明確にマークする際に役立つ分析情報を得ることができる
- マイクロサービスのベストプラクティスでは、サービスごとのデータベースが必要になる
- アプリケーションのデータモデリングを行う際に、サービスごとのデータベースがアプリケーションに適合するかを確認する必要がある
- マイクロサービスアーキテクチャを実装する際には、ボトルネックの特定、障害の検出と防止、診断のサポートを行なえるように、環境のインストルメンテーションとモニタリングを行う必要がある
- マイクロサービス アーキテクチャでは、各サービスに個別のアクセス制御を行っている
- セキュリティを確保するには、環境内でも API を使用する外部アプリケーションからも、各サービスへのアクセスを保護する必要がある
- 同期サービス間通信により、アプリケーションの可用性が低下するのが一般的
- 非同期でメッセージベースの通信を実装すること推奨
モノリシックアプリケーションをマイクロサービスに移行するタイミング
- すでにモノリスを正常に実行している場合、マイクロサービスを採用するのはチームにとって大きな投資費用となる
- マイクロサービスの基本的性質はチームによって実装方法が異なる
- マイクロサービス アプローチが目標を達成する最良の方法であると思われる場合は、まずモノリスから 1 つのサービスを抽出し、それを開発、テスト、本番環境でデプロイすることがいい
感想
- どっちも複雑だけど、どっちの複雑性を取るかみたいな話だなと
