後期段階のマイクロサービス

May 09 2023

Amazon Prime Video チームのマイクロサービスをモノリスに統合することで、スケールを拡大し、コストを 90% 削減するという取り組みについて読みました。この話にはもっと詳しいことがあると思いますが、同様の話がインターネット上で公開されています。過去 10 年間のマイクロサービスの流行に対する一種の反論です。

Twitter で過ごしたここ数年間を思い出しました。そこでは、トラフィックが増加したにもかかわらず、マイクロサービスの数 (数千) がピークに達し、その後減少し始めました。あらゆる種類のアプリケーションロジックが、何らかのモノリシックな管理プラットフォームに吸収されました。専用のマイクロサービスを作成するという原則は本質的に良いものではなく、ある時点を過ぎると、多くのチームにとっても ROI がプラスになるとは思えませんでした。

マイクロサービスアーキテクチャはコストがかかる場合があります。過去 10 年にわたり、これは大規模なエンジニアリング組織にとって自然なポリシーであるという説が流れてきました。その理由は次のとおりです。

チームは、より広範な組織とそのコードから自律的にサービスを反復処理できます。
より大きなシステムを中断することなく、サービス提供アーキテクチャの小さなコンポーネントを変更できます。
このアーキテクチャにより、独立したサービスを通じて、明確で管理可能なアプリケーションおよび障害ドメインの定義が可能になります。
このアーキテクチャにより、独立して調整可能またはスケーラブルなワークロードが可能になります。

単一または少数のモノリスとは対照的に、小規模なサービス所有チームとその結果としてより広範なエコシステムにオフロードされる作業の複雑さを考慮する必要があります。オフロードされる作業は、組織のテクノロジースタックの成熟度によって異なります。ただし、次のものが含まれる場合があります。

すべてのサービス所有チーム間での運用上の責任とオーバーヘッドの分散

ジョブのスケジューリングと展開ツール、サービス検出、RPC フレームワーク、VM と関連するチューニング、サービスの監視とログからのサービスインフラストラクチャコンポーネントの理解と構成
SLO と SLI の分散定義と開発プロセス、サービス障害と障害処理、バックプレッシャー処理、エラー通知
分散され、調整されていないことが多いキャパシティプランニング、負荷テスト、統合テストの実装と責任

多くのバックエンドサービスと対話するアプリケーションロジックは、多くの場合、一連のオーダーメイドのサービス API 定義、セマンティクス、データモデル、バージョン管理システム、および場合によっては異なるプロトコルをナビゲートします。
エンジニアは、機能的なものを構築するために、全体的なサービスアーキテクチャとトラフィックパターンを理解し、推論する必要があります。
最適ではない、またはボトルネックになったサービス提供パス、分散データのレプリケーションと消費、循環リクエストの依存関係に対する有機的な回避策

推論とランキング、イベント処理、HTTP/内部プロトコル API 変換、データモデルマッピングの問題に対するローカライズされたアプローチ
全体的な断片化とスタック全体での標準維持の困難

問題は、新しいサービスの作成、構築、運用化のプロセスに費用がかかることです。そのサービスを運用サービスアーキテクチャに統合することは困難です。効率的な運用のために別のサービスを調整するために必要な注意。対応するサービスアカウント、可観測性とロギングプロファイル、統合テスト、オンコールローテーション、その他すべてを設定すると、チームのメンテナンスと運用のオーバーヘッドが増えるだけです。ほとんどの組織には、この種の複雑な定型作業のための自動化とエンドツーエンドの足場が不足しています。

このオーバーヘッドは、チームが「 1 つのことをうまくやる」という UNIX にヒントを得たマイクロサービスアーキテクチャの原則に固執する大きな妨げとなります。既存のサービスに新しいユースケースを組み込む方が簡単です。スペクトルの最端では、チームはチームとして責任を負うすべてのものをカプセル化する「マクロ」サービスを運用します。これには、さまざまな製品や機能が含まれる可能性があります。組織再編は比較的頻繁に起こるため、所有権の質は時間の経過とともに低下します。あなたは泥の塊を使って仕事をしています。

マクロサービスの停止は、特定の 1 つの機能セットに限定されるのではなく、過去の組織図に似た、予測不能または無原則なシステム全体に発生します。サイトは、これらのサービスが利用できないことを許容する場合と許容しない場合があります。異種ワークロードに合わせてサービスを最適化することはより困難です。コールパスのもつれを解くことはできません。元同僚がこれを「マイクロリス」と名付けました。

マイクロサービスは、サービスを提供するアーキテクチャにローカルの最適化をエンコードし、奨励します。目標がサービス開発のフェデレーションである場合、サービス提供アーキテクチャの原則に基づいた設計に対してチームに責任を負わせるのは困難です。同様に、依存するサービスのプロパティが特注である場合、バックエンド全体の最適化問題を解決することは困難です。慎重に設計されたサービスアーキテクチャとサポートサービスプラットフォームがなければ、活用するのは困難です。再利用可能な製品プラットフォームのコードは、一連の大規模なサービスや共有ライブラリに分散しています。フロントエンドサービスは通常オーダーメイドです。

マイクロサービスの活用は、コンピューティング層 (サービスジョブやコンテナーのオーケストレーションと実行に関係するもの)、サービスディスカバリ、VM (特定のコンテキストで適用可能)、サービスフレームワーク ( gRPC、Finagle、Rest.Liなど)、および集中開発者ツールで見られます。もちろん、サービスメッシュは、これらの懸念事項の一部をうまくカプセル化します。

これらの問題に対処するもう 1 つの方法は、機能のオーバーヘッドを削減することです。したがって、サービスの実行に伴う繰り返しのインフラストラクチャのオーバーヘッドを削減しようとするのではなく、チームが共通の作業クラスを再実装するコストを削減できます。これが、マネージドプラットフォームが成功する理由です。サービスの作成や運用に費用がかかる場合でも、パブリックまたはプライベートのマネージドプラットフォームにアウトソーシングすることでアプリケーションロジックを薄くできれば、その所有チームの負担が軽減されます。

組織にとって、特定のニーズ、目標、テクノロジースタックの成熟度に基づいて、アーキテクチャのトレードオフを慎重に評価することが重要です。マイクロサービスには特定の利点があります。また、複雑さと運用上のオーバーヘッドも発生し、最初は管理できるように見えますが、時間の経過とともに悪化します。これらの問題に対処しないと、エンドツーエンドの開発プロセスがモノリスで作業するよりも簡単になります。