2023年5月にマイクロサービスを放棄してモノリスに切り替えて、驚異的な90%のコスト削減に成功した人が誰か知っていますか?資金難のスタートアップやインディーズプロジェクトではなく、Amazon自身がPrime Videoサービスのためにそうです。毎年マイクロサービスインフラを販売して 数十億ドル を稼ぐ同じAWSが、時には良きモノリスが勝つこともあると認めています。
分散システムの実質的なプレイブックを書いた会社からのこの逆転は、クラウドネイティブコミュニティに衝撃を与えました。Amazonは後に元のブログ記事を削除しましたが、インターネットは決して忘れません。これは後でご覧になることです。
私は5、6年間、 マイクロサービスアーキテクチャの不必要または時期尚早な使用に反対 して声を上げてきました。Amazon Prime Videoがモノリスに戻った後、マイクロサービスをデフォルトとして否定する著名な建築家たちに出会いました。
それでも多くのテック業界では、マイクロサービスが現代のソフトウェアを構築する唯一の方法と見なされています。彼らは会議、ブログ、求人情報を席巻しています。チームは彼らの要件が正当化しているからではなく、明白で(そして履歴書にも良い)選択のように感じられるから採用するのです。「クラウドネイティブ」は「デフォルトでのマイクロサービス」と同義語となり、他のアプローチもフロッピーディスクのように時代遅れであるかのようです。
マイクロサービスは実際に問題を解決 します が、それは大規模に行われます。ほとんどのチームは実際にはその規模で運営していません。
この記事を通じて、業界がほとんど問いかけなくなった疑問について考えてほしいと思います。つまり、 大規模構築においてマイクロサービスはデフォルトの選択肢であるべきなのか?経験豊富な建築家たちのリバーサルストーリーや洞察を見て、トレードオフや代替案を検討します。これらすべてを考慮した後、あなたの問題に本当に複数のマイクロサービスが必要かどうか判断できます。
マイクロサービス:敏捷性と複雑性のトレードオフ
紙面上では、マイクロサービスは印象的に見えます。一つの大きなモノリスではなく、アプリケーションを多くの小さなサービスに分割します。それぞれは任意の言語で書かれ、小規模なチームが所有し、独自のスケジュールで展開できます。容量が増える場合は、負荷がかかっている部分だけをスケールさせることができます。その約束は洗練されています。独立した展開可能性、自律的なチーム、多言語スタック、そして柔軟なスケーリングです。
しかし問題は、すべての裂け目が縫い目を生み出し、その隙間が故障の原因となる可能性があることです。モノリス内部では、関数呼び出しは即座かつ予測可能です。サービス間で、同じ通話はネットワークリクエストとなり、遅くなり、故障しやすく、時には一貫性のないデータを返します。数十(あるいは数百)のサービスがあるため、バージョン管理、スキーマ進化、分散トランザクション、トレーシング、集中ログ、そして強力なCI/CDパイプラインが必要です。
この ガートナー図 はトレードオフを完璧に捉えています。マイクロサービスは、一つのコードベースのシンプルさを複数の複雑さと交換するのです。
大規模(Netflixを思い浮かべてください)なら、そのトレードオフは価値があるかもしれません。しかし、運用上のメリットがコストを上回らないと、チームは製品をまとめるためにデバッグや調整、コードを接着するという大きなコストを支払うことになります。
マイクロサービスは、 異なるビジネス機能が独立したスケーリングと展開を必要とする非常に特定のシナリオで意味を持ちます。例えば、 決済処理 (セキュリティが重要で、ほとんど更新されない)は 、レコメンデーションエンジン (メモリ集約的で常にA/Bテストが行われる)とは根本的に異なります。これらのコンポーネントは異なるスケーリングパターン、展開サイクル、リスクプロファイルを持ち、別々のサービスを正当化します。
マイクロサービスの成功は 、コンウェイの法則 が予測するように、チーム構成に合った明確なビジネスドメイン境界にかかっています。もし組織が自然に自律的なチームに分かれ、それぞれ独自の能力を持つなら、マイクロサービスがうまく機能するかもしれません。(つまり、ほとんどの 「1.5ピザ」 スタートアップは対象外ですよね?)
だからこそ、マイクロサービスはAmazonやUberのような企業で効果的に機能していますが、 必ずしもそうとは限りません。
実際、ほとんどの組織は、専任のサービス所有権、成熟したCI/CD、堅牢な監視、そして何よりも 運用上のオーバーヘッドに見合う規模性という前提条件を欠いています。マイクロサービスを早期に適応させるスタートアップは、しばしば その決断を後悔します。
だから、自問してみてください:
独立したスケーリング問題を解決するためにマイクロサービスを使っているのか、それとも必要な以上の複雑さを招き込んでいるのか?
グレート・マイクロサービスの逆転
皮肉なことに、マイクロサービスから最も恩恵を受ける可能性が高いのはテック大手であるにもかかわらず、多くの同じ企業がマイクロサービスのアーキテクチャを後退させており、その結果は目を見張るものとなっています。
Amazon Prime Video:モノリスによる 90%のコスト削減
2023年5月、アマゾンのエンジニアたちは考えられない事実を認めました。プライムビデオはマイクロサービスを放棄し、モノリスに切り替えたのです。彼らのビデオ品質分析(VQA)チームは、教科書通りの分散システムのように見えるものを構築しました。AWS Step FunctionsとLambdaは、独立したスケーラブルなコンポーネントを通じて数千のビデオストリームを監視していました。紙面上では、サーバーレスの完璧さだった。
しかし実際には、それは大失敗でした。「分散型アプローチは私たちの特定のユースケースであまりメリットがないことに気づきました」と、 現在アーカイブされているPrime Video EngineeringブログのMarcin Kolnyは語っています。彼らの「無限にスケーラブル」なシステムは、オーケストレーションのオーバーヘッドにより 、予想負荷のわずか 5%で崩壊しました 。
修正方法は恥ずかしいほど簡単だった:すべてを一つのプロセスにまとめる。その結果、コスト90%削減され、性能が向上しました。
トゥイリオセグメント: 140 サービスから一つの高速モノリスへ
2018年には、顧客データプラットフォームのTwilio Segmentが、同様の正直な投稿「Goodbye Microservices」で同様の逆転を記録しました。
彼らのシステムは 140+サービスに広がり、運用上の混乱を生み出していた。一時期、3人のフルタイムエンジニアが建設よりも消防活動に多くの時間を費やしていました。彼らはこう認めています。「速く動く代わりに、小さなチームは爆発的な複雑さに巻き込まれてしまった。このアーキテクチャの本質的な利点は負担となりました。速度が急降下するにつれて、欠陥率は爆発的に増加した。」
彼らの解決策は革新的でしたが効果的でした。すべての 140+サービスを単一のモノリスに統合することです。その影響は即座に現れました。かつては1時間かかったテストスイートが、今ではミリ秒で終わるようになりました。開発者の生産性は急上昇し、共有ライブラリへの改善を1年で 46 提供し、マイクロサービス時代の 32 から増加しました。
Shopify:誇大宣伝よりも理性
Shopifyは世界最大級のRuby on Railsコードベースの一つ(2.8M+)を運用しています行)マイクロサービスを追いかける代わりに、明確なコンポーネント境界を持つ単一のコードベースという モジュール式モノリスを意図的に選びました。
Shopifyのエンジニアたちは「マイクロサービスは独自の課題をもたらす」と結論づけ、運用上のオーバーヘッドのないモジュール性を選びました。
これらすべての例から疑問が生じます:
マイクロサービスの先駆者たちでさえ後退しているのに、なぜ私たちはそれを福音のように扱っているのでしょうか?
マイクロサービス熱狂に反対する専門家の声
ソフトウェアアーキテクチャの最も尊敬される声の中には、私たちが尊敬する多くのシステムの背後にいる人々も、マイクロサービスや大規模に繰り返される失敗を繰り返すことに警鐘を鳴らしています。(結局のところ、チアリーダーはゲームをプレイしません。クラウド開発者はめったに大規模に建設しません。)
レールズクリエイター:洗練よりもシンプルさ
Ruby on Railsの創設者であるデイビッド・ハイネマイヤー・ハンソン(DHH)は、建築のトレンドよりもシンプルさを長年提唱してきました。彼のAmazon Prime Videoの逆転分析は率直にこう述べています。
「この理論の現実世界の結果がついに明らかになり、実際にはマイクロサービスがシステムを不必要に複雑化させる最大の誘惑の歌であることは明らかです。」
DHHの「サイレンソング」のイメージは的を射ています。マイクロサービスは優雅さを約束しますが、チームは複雑さの岩に押しつぶされてしまうのです。
マイクロサービス:10年最大の失敗?
元GitHubのCTOであるジェイソン・ワーナーは、マイクロサービスについて遠慮なくコメントしています:
「過去10年の最大のアーキテクチャ上の誤りの一つは、フルマイクロサービスに切り替えたことだと確信しています。」
ワーナーはスケールを理解しています。GitHubはインターネット規模で動作し、HerokuやCanonicalでエンジニアリングを率いてきました。彼の批判は理論的な 助言を超えた実体験であるため、より深く切り通っています。
「世界中の企業の90%は、単にメインのDBクラスターにバックアップやキャッシュ、プロキシを配置したモノリスで済むでしょう。」
GraphQL共同制作者:「やめて」
そして GraphQLの共同開発者、ニック・シュロックがいます。分散型システムを応援する理由があるとすれば、それは彼だろう。代わりに彼はこう言います:
「マイクロサービスは根本的かつ壊滅的に悪いアイデアであり、数十億規模の企業が何もしないまま、彼らが引き起こした被害を封じ込めるだけの存在になるでしょう。」
彼はさらに、マイクロサービスを 組織的なギャンブルと表現しています。
「5年前の組織構造や製品要件に合ったサービスが、永遠に維持しなければならないことになる。今日では、あまり意味が通じない。」
分散システムの問題を解決するためのツールを実際に作った人は、 どうしても使わなければ配布しないで、そろそろ耳を傾ける時かもしれないと言っています。
マイクロサービスのマキシマリズムに疑問を呈する他の声
他のエンジニアリングリーダーもマイクロサービスのマキシマリズムを再考しています。
Uberで、 ゲルゲイ・オロシュは次のように認めました。
「多くのマイクロサービスをマクロサービス(十分な規模のサービス)に移行しています。まさにその通りです。なぜなら、数千のマイクロサービスをテストし維持するのは難しいだけでなく、短期的な解決よりも長期的に問題を引き起こす可能性があるからです。」
Uberは正当なマイクロサービスをまだ運営していますが、 戦いを選んでいます。
KubernetesやGoogle Cloudでの活躍で知られるケルシー・ハイタワーは、CS101でマイクロサービスの期待を打ち破りました。
「モノリスならすべてのマイクロサービスアーキテクチャを凌駕すると賭けてもいい。各サービス間のネットワーク遅延と、各リクエストのシリアライズ・デシリアライズの量を計算すればいいのです。」
その後、彼はこのツイートを削除しましたが、ネットワークの数学は依然としてマイクロサービスを評価しています。
こうした先駆者たち、特に大規模に分散システムを解決した人々が警戒し始めたとき、注目に値します。
ここでの質問です:
GitHubのCTOがマイクロサービスを必要としない企業 90%と考えているなら、あなたの会社もその中 10に含まれると確信していますか?
マイクロサービスの隠れたコスト
マイクロサービスは、チームがしばしば過小評価しがちな隠れたコストのために、このような慎重さを求めます。
運営コスト
モノリスはシンプルです:プロセス中の関数呼び出し。
マイクロサービスはそれをネットワークに置き換えます。すべてのリクエストは現在、マシン間、ロードバランサー、サービスメッシュ、認証層を経由して転送され、さらなる障害点やインフラ要件を生み出しています。突然、サービスディスカバリー(サービス同士の見つけ方)、分散トレーシング(サービス間のリクエスト追跡)、集中型ログ(複数のサービスのログを集約)、そしてサービストポロジーを理解する監視システムが必要になります。
これらはそれぞれ必要ですが、複雑で高価です。データが重複すると追加のストレージが必要です。絶え間ないサービス間通話はネットワークの出口料金を蓄積します。クラウドコストは、ホストするアプリよりも 速くスケールします 。プライムビデオのワークフローは、実際の処理よりもサービス間のSデータ転送のオーケストレーションに多く費や3。
開発者生産性の排水
マイクロサービスでは、難しいのはコードを書くことではありません。分散システムの相互作用を乗り越えることです。
「マイクロサービスのマクロ問題」の中で、Stack Overflowは生産性の重要な負担を特定しています。分散状態は開発者に防御的なコードを書かせ、部分的な障害を常にチェックするというものです。
モノリスでは、開発者は1つのリポジトリ内でコードパスをエンドツーエンドで追跡できます。マイクロサービスでは、1つの機能が4つまたは5つのリポジトリにまたがり、異なる依存関係や展開サイクルを持つことがあります。単一のフィールドを追加するだけで、数週間にわたる調整が発生します。1つのサービスを更新し、その後消費者の採用待ち、APIのバージョン設定、ロールアウトの管理などです。また、異なるチームが異なる技術スタックを使って異なるマイクロサービスを維持することが多く、意図せずに何かを壊すリスクもあります。モノリスでコンパイラが検出できる変更を壊すものは、現在は本番環境での実行時エラーとして表れています。
テストと展開の複雑さ
モノリス統合やエンドツーエンドのテストは、ローカルメモリ上で実行されるため高速です。分散型システムではそのような贅沢は許されません。真の信頼を得るには、複数のサービス境界を越えた統合とエンドツーエンドのテストが必要です。そのため、これらのテストは遅く、より脆く、本番環境に似たステージング環境が必要で、インフラコストを実質的に倍増させ、フィードバックループを遅くします。
多くのチームは テストスイートがボトルネックになって初めてこれに気づきます。デプロイメントオーケストレーションはさらに別の層を加えます。相互依存するサービス間のローリング更新は、契約違反を避けるために慎重な順序付けが必要です。バージョンの互換性不在が頻繁に問題を起こします:サービスAはサービスBとサービスB2連携しています。1 v2と断絶します。2。
失敗した展開はシステムを部分的に更新し、復旧が困難な状態にします。
データ管理と一貫性
マイクロサービスの最も過小評価されている複雑さは、サービス境界を越えたデータの一貫性にあります。
モノリスはACIDトランザクションから恩恵を受けます。つまり、操作が完全に完了するか、完全に失敗するかです。マイクロサービスはそれをサービス間で分割し、 分散サガ (ロールバックロジックを含む多段階ワークフロー)、 最終的な一貫 性(データが遅延後に正確になる)、 または補償ロジック (部分的な故障を元に戻す追加コード)を書く必要があります。かつては単一のデータベーストランザクションだったものが、今ではネットワークのホップ、リトライ、部分的な障害にまたがっています。状態がサービス間で重複すると、不整合な注文や支払いのデバッグは格段に難しくなります。
研究が示すように、データの重複、正確性の課題、トランザクションの複雑さはマイクロサービスシステムにおける最大の課題です。
複利効果
これらの複雑さは増幅します。運用上のオーバーヘッドがデバッグを難しくし、テストが遅くなり、デプロイのリスクが高まり、インシデントが増えます。マイクロサービスは単に複雑さをコードから操作へと移すだけでなく、エンジニアリングのあらゆる部分に課税されます。
体重計が要求しない限り、その税金は利益を上回ることが多いです。
考えてみて下さい：
もしネットワークホップごとに複雑さとコストが増えるなら、あなたのユースケースは本当にその価格に見合うのでしょうか?
マイクロサービスを超えて:より賢いアーキテクチャの代替案
マイクロサービスにデフォルトする前に、分散複雑度税なしで、よりシンプルでよく構造化されたアーキテクチャが同等のスケーラビリティを提供できるかを考える価値があります。注目すべき代替案としては、モジュラーモノリスとサービス指向アーキテクチャがあります。
モジュラーモノリス:分布のない構造
従来のモノリスが絡み合った混乱を招くのに対し、 モジュラーモノリス は明確なモジュールAPIと規律ある分離を通じて厳格な内部境界を強制します。各モジュールは明確に定義されたインターフェースを公開し、チームが独立して作業しながら単一の一貫したシステムを展開できるようにします。
ケント・ベックが 「Monolith -> Services: Theory & Practice」で説明しているように、モジュラー・モノリスは分散ネットワークではなく組織的な規律を通じて結合を管理します。主な違いは、モジュールはマイクロサービスのような明示的な契約を通じて通信するが、ネットワークの遅延や部分的な障害に弱いHTTPリクエストの代わりに高速で信頼性の高い関数呼び出しを使うことだ。
なぜそれが機能するのか?
- より単純な操作:モノリシックなシンプルさを持つマイクロサービスレベルの組織
- より強い一貫性:完全なACIDトランザクション
- デバッグが簡単:追跡可能なシステムが一つで、 ELK の干し草の山からバグを探す必要もありません
- より良いパフォーマンス:関数呼び出しがネットワークホップを上回る
実例を挙げましょう:Shopifyの2。100万行のコードベース8分あたり30TBを処理し、別々のチームがそれぞれ異なるモジュールを所有していますが、すべてが一緒に展開されます。Facebookも同様の運営です。(そして主任建築家 のキース・アダムズは冗談を言 います。マイクロサービスから 説 得されたいなら、彼があなたの役目だと。)
Spring Modulith、Django、Laravel、Rails(Shopifyで大規模に見られる)などのフレームワークの最近の発展により、モジュラーモノリスは今後数年でより広範な支持を得る見込みです。
サービス指向アーキテクチャ:中間の立場
サービス指向アーキテクチャ(SOA)は モノリスとマイクロサービスの中間に位置し、数十から数百の小さなサービスよりも大規模でドメイン駆動型のサービスを優先します。これらのサービスはしばしばエンタープライズサービスバス(ESB)を介して通信し、オーケストレーションのオーバーヘッドを削減しつつ、関心事の分離を維持します。
認証、ユーザー設定、通知を別々のマイクロサービスに分割する代わりに、SOAはそれらを単一の「ユーザーサービス」として統合し、調整を簡素化しつつ自律性とターゲットスケーリングを維持できるかもしれません。SOAは超細粒度の配布オーバーヘッドなしに、エンタープライズレベルのモジュール性を提供します。
なぜそれがうまくいくのか、その理由を説明します:
- 適切な境界:スプロールの代わりにドメインに合わせたサービスが少なくて
- ターゲットを絞ったスケーラビリティ:実際のビジネスドメインに結びついたサービスのスケール
- 実用的複雑性:超細か粒子のオーバーヘッドを避けつつ、モジュール式推論を保持する
SOAは大規模でも効果があることが証明されています。ヨーロッパで 9大きい航空会社であるノルウェージャン・エアシャトルは、 SOAを活用 して複雑な飛行運航の機動性を高めました。クレディ・スイスの SOA展開 は、 2000年代初頭に1日に数百万件のサービス通話を支えていました。
賢く選ぶ:誇大宣伝よりフィット感を重視する
あなたが解決している問題は、あなたのアーキテクチャを正当化するはずです。
私はコンサルティングでよくこの例えを使います。「レモンを切るのに剣は必要ない――ナイフで十分だ」と。そして、時代を超えた知恵が私たちに思い出させるように、シンプルさこそが究極の洗練さです。
おそらく 、あなたはGoogle( Googleレベルのフォールトトレランスは必要ありません)、Amazon(大量の書き込み可能性は必要ありません)、LinkedIn(1日に数十億件のイベントを処理しているわけでもありません)ではありません。ほとんどのアプリケーションはその規模で動作せず、超分散アーキテクチャとは根本的に異なるソリューションを求めます。
ほとんどのシステムでは、よく構造化されたモジュラーモノリス(スタートアップを含む一般的なアプリケーション向け)やSOA(エンタープライズ向け)が、分散複雑度税なしでマイクロサービスと同等のスケーラビリティとレジリエンスを提供します。あるいは、大量のマイクロサービスではなく、十分な規模のサービス(マクロサービス、またはガートナーが提案した ミニサービス)を検討することもできます。
質問する価値があります:
もしよりシンプルなアーキテクチャでも同等のスケーラビリティが得られるなら、なぜマイクロサービスの複雑さを選ぶのでしょうか?
Docker:あらゆるアーキテクチャに対応
Docker はマイクロサービスだけのものではなく、モノリス、SOA、API、イベント駆動型システムなど あらゆるアーキテクチャで非常によく機能します 。本当の利点は、Dockerが一貫したパフォーマンス、より簡単な展開、そしてどんなアーキテクチャアプローチを使っていてもアプリをスケールアップできる柔軟性を提供することです。
Dockerはアプリケーションをクリーンにパッケージ化し、ノートパソコンから本番環境まで一貫性を保ち、依存関係管理を簡素化し、ホストシステムからアプリケーションを分離します。Docker化されたモノリスは、マイクロサービスのオーケストレーションオーバーヘッドを除き、これらすべての利点を提供します。
マイクロソフトのモノリスコンテナ化に関するガイダンスでは 、コンテナのスケーリングは「追加のVMを展開するよりもはるかに速く簡単」であり、1つのサービスでも50個のサービスでも明確にしています。Twilio Segmentは 、コンテナ型モノリスが「より多くのコンテナを稼働させ、需要が落ちたときにそれらを停止することで、環境を水平的に容易に拡大できる」と指摘しました。多くのアプリケーションでは、アプリ全体のスケールアップがまさに必要なことです。
DevOpsに関して言えば、Dockerのモノリスはフルのマイクロサービス構成よりも操作が軽いです。異なるフォーマットの異なるサービスから収集するよりも、同じコンテナから収集する際のログ集約がより簡単になります。監視とデバッグは集中管理されており、トラブルシューティングはサービス境界を越えたリクエストの追跡を避けられます。
ですので、間違いなく考慮する価値があります:
マイクロサービスの複雑さがなくても、Dockerはクリーンな展開、容易なスケーリング、一貫した環境という同じ利点を提供します。では、なぜそのままにしないのでしょうか?
まとめ
数年前、当時8歳だった私の息子が自転車を欲しがっていました。彼は主に私たちのアパートの敷地内を自転車で回り、近くの車線に出ることもありました。ギア21必要なかったのに、あのピカピカのシフターに夢中になってしまった――ギアを変えれば速く走れるなんて想像してみてください!彼は絶対にあの機械的に複雑な美しさ を望んで いた。(星を見上げた子供に反論するのは難しい...あるいは創設者:P)などです。
新しい自転車に乗り始めると、ギアが滑り、チェーンが詰まり、自転車は道路よりも壊れたままの時間の方が長くなってしまいました。結局、私たちはそれを捨てなければなりませんでした。
当時はもっとシンプルな自転車の方が彼に合ったかもしれないと説得できなかったが、この記事が建築的な判断を下す大人たちを説得する助けになるかもしれない。
私たち技術者は複雑なシステムに取り組むのが大好きです。(チェック:すでに「 ギア付きの自転車の何が複雑なんだ?」と考えていましたか?)しかし、動く部品が増えれば増えるほど、壊れやすくなります。複雑さはしばしば解決するよりも問題を生み出します。
私が言いたいのは、マイクロサービスを完全に捨てることではなく、クラウド大手が推し進めているものではなく、実際に自分のニーズに合ったアーキテクチャを選ぶことです(その間に自社の コミットを密かにロールバックしています)。おそらく、モジュラーモノリスやよく設計されたSOAの方がニーズにより良く応え、チームの生産性を高めるでしょう。
では、ここで100万ドルの質問です:
クラウドネイティブの宣伝のためにデザインしますか、それとも自社のビジネス要件に合わせて設計しますか?
本当にマイクロサービスが必要なのでしょうか?
