Googleが黙っていられない：我々が作ったマイクロサービスはすべて間違っていた！
Amazon Prime Videoチーム：マイクロサービスを放棄し、モノリスに切り替え
マイクロサービスを放棄したのはGoogle、Amazonだけではない
マイクロサービスの偽りの繁栄：モノリスから「分散モノリス」へ
Googleが新しいマイクロサービスを提案
インフラストラクチャ再考の年
マイクロサービスにとって「逆行」の年。
長らく、大手企業であろうと中小企業であろうと、マイクロサービスはクラウドネイティブなサービスアプリケーションアーキテクチャの事実上の標準とされてきました。しかし2024年、37signalsのDHHがクラウドからの撤退とマイクロサービスの放棄を決意しただけでなく、AmazonやGoogleといったクラウドの巨人たちも、マイクロサービスに革命を起こし始めています。
1 Googleが黙っていられない：我々が作ったマイクロサービスはすべて間違っていた！
「分散アプリケーションを記述する際、従来の考え方ではアプリケーションを独立して展開可能な個別のサービスに分割するとされてきました。このアプローチの意図は良いものでしたが、このようなマイクロサービスベースのアーキテクチャはしばしば逆効果となり、アーキテクチャが達成しようとした利点を打ち消す課題をもたらします。」
今年6月、Googleの従業員グループ（GoogleソフトウェアエンジニアMichael Whittakerが率いる）は、「Towards Modern Development of Cloud Applications」というタイトルの論文を発表し、冒頭から現在のマイクロサービスアーキテクチャに異を唱えました。
論文は、アーキテクチャ的に見て、マイクロサービス自体に根本的な問題があり、境界のない構造であると主張しています。「根本的に、これはマイクロサービスが論理的な境界（コードの書き方）と物理的な境界（コードのデプロイ方法）を混同しているためです。」
したがって、Googleのエンジニアたちは、「マイクロサービス2.0」とも呼べる新しい方法を提案しました。アプリケーションを論理的なモノリスとして構築し、それを自動化されたランタイムに任せることで、ランタイムがアプリケーションのニーズと利用可能なリソースに基づいてワークロードをどこで実行するかを決定します。
新しく提案された構造に基づき、彼らはシステムの遅延を15倍削減し、コストを9倍削減することができました。
「整理されたモジュール化されたコードから始めることで、デプロイアーキテクチャを実装の詳細として扱うことができます。」Googleの開発者アドボケートKelsey Hightowerは、10月にこの取り組みの次のステップについて述べました。
このGoogleのデベロッパーたちは、アプリケーションを個別にデプロイ可能なサービスに分割する方法の欠点が明らかすぎることを発見し、非常に革新的な3つの原則を提示しました：
1、開発者が論理コンポーネントに分割されたモノリシックアプリケーションを作成することを奨励する
2、物理的な分散とモジュール化されたモノリスの実行という課題をランタイムに委ねる
3、アプリケーションをアトミックにデプロイする。
これら3つの指針は多くの利点をもたらし、将来の開発革新への扉を開きます。
2 Amazon Prime Videoチーム：マイクロサービスを放棄し、モノリスに切り替え
偶然にも、同じく6月に、AmazonのストリーミングプラットフォームPrime Videoが発表したある事例研究が風向きを変えました：「私たちはサーバーレスおよびマイクロサービスアーキテクチャを放棄し、モノリシックアーキテクチャに切り替えました。これにより、顧客の運用コストを90%削減し、システム全体の複雑さも簡素化されました。」
モノリシックアプリケーションによるマイクロサービスへの「反撃」がAmazonチームから提示されたことで、この話題は再び技術界で急速に盛り上がりました。
この事例全体を見ると、マイクロサービスとコスト削減・効率向上は必ずしも結びつかないようです。一体どこに問題があったのでしょうか？
Prime Videoチームは、ビデオストリームの品質問題を監視するツールを必要としていました。ビデオの数が膨大だったため、このツールには非常に高い拡張性が求められました。
当初この作業は、AWS Step Functions（サーバーレスオーケストレーションサービス、AWS Lambdaサーバーレスサービス）によってオーケストレートされた一連の分散コンポーネントによって行われ、あっという間にきちんとした監視システムを構築することができました。しかし、Step Functionのスケーリング問題が最大の障害となるとは誰が想像したでしょうか。
具体的に見ると、一つは、ビデオストリームの毎秒ごとに多数の同時AWS Step Functionが必要となり、すぐにアカウント制限に達してしまったこと。二つ目は、AWS Step Functionが状態遷移ごとにユーザーに課金するため、費用が高すぎて手が出せなかったことです。
やむを得ず、Prime Videoはコスト削減とアプリケーションの拡張性向上のためにモノリシックソリューションを検討し始め、度重なる試行錯誤の末、チームは最終的にPrime Videoのインフラ全体を再構築することを決定しました。
Amazonはブログ記事で次のように結論付けています：「マイクロサービスとサーバーレスコンポーネントは大規模に機能するツールですが、全体的にそれらを使用するかどうかは、具体的な状況に応じて決定する必要があります…サービスをモノリスに移行することで、私たちのインフラコストは90%以上削減され、スケーラビリティも向上しました。」
これは、少なくともビデオ監視の分野では、モノリシックアーキテクチャがマイクロサービスやサーバーレス主導のアプローチよりも高いパフォーマンスと、より大きなコスト削減および効率向上をもたらしたことを示しています。
常にクラウドからの撤退とマイクロサービス化への反対を唱えてきたDHH（Ruby on Railsの創設者、David Heinemeier Hansson）は、鋭く指摘しました：「Amazon自身でさえ、マイクロサービスやサーバーレスは『くだらない』と考えている。」
3 マイクロサービスを放棄したのはGoogle、Amazonだけではない
近年、無数の中小規模チームが、メリットとデメリットを比較検討した結果、マイクロサービスの放棄を選択しています。
Uberもその一つです。以前、Uberは非常に小さな要件や機能を達成するためにマイクロサービスを構築しており、一人で構築・保守するマイクロサービスが多数存在することもありました。これらのマイクロサービスの存在は、監視、テスト、継続的インテグレーション/継続的デリバリー（CI/CD）、サービスレベルアグリーメント（SLA）など、Uberにさらなる課題をもたらしました。
マイクロサービスの「落とし穴」にはまった後、Uberチームは新しいサービスに対してより深く検討した計画を立てました。それは、単に一つのことを完遂するのではなく、一つのビジネス機能に貢献させること、そして5～10人のエンジニアが保守を担当することです。彼らはまた、痛い教訓をまとめました：製品を構築するには、適切なタイミングで適切なソリューションを選択すること。
オフィス管理ソフトウェア会社Managed by Qのアプリケーションは、ECSにデプロイされたDjangoモノリスでした。最新の開発手法に追いつくため、彼らはマイクロサービスアーキテクチャに移行しました。しかし、新しいサービスが増えるたびにインフラストラクチャも増え、複数のサービスにまたがる機能開発にはより多くの作業が必要になることにすぐに気づきました。
結果として、マイクロサービスへ移行してから2年後、彼らはマイクロサービスの統合を始めました。いくつかのマイクロサービスはモノリスに統合され、その他はより大きなサービスにまとめられました。彼らは実践を通して、「マイクロサービスが常に正しい選択肢であるとは限らない」という経験を得ました。
マイクロサービスを万能薬だと考えていたものの、結果としてエンジニアリングの費用が大きすぎ、割に合わないものでした。上記の企業における最大の問題は、たった20人のエンジニアがいる環境で数十ものマイクロサービスを実装したことであり、まるで鶏を割くのに牛刀を用いるようなミスマッチ感がありました。
4 マイクロサービスの偽りの繁栄：モノリスから「分散モノリス」へ
「マイクロサービスからの脱却」の事例が増えるにつれ、2005年に提唱された「マイクロサービス」は再評価され、さらには批判の対象となっています。
例えば、冒頭で触れたGoogleのエンジニアたちは、彼らの論文で現在のマイクロサービスアプローチの欠点を挙げました。これには以下が含まれます：
パフォーマンス：ネットワークを介してデータをシリアル化し、リモートサービスに送信することはパフォーマンスを損ないます。アプリケーションが十分に複雑になると、ボトルネックを引き起こす可能性さえあります。
理解と追跡：分散システムでは、マイクロサービス間の多くの相互作用を考慮すると、バグを追跡するのが非常に難しいことはよく知られています。
管理の問題：アプリケーションの異なる部分がそれぞれ独自のスケジュールで更新できることは利点とされています。しかし、これにより開発者は大量のバイナリファイルを管理する必要が生じ、それぞれが独自のリリーススケジュールを持っています。ローカルで動作するサービスを使ってエンドツーエンドテストを実行するのは大変です。
APIの脆さ：マイクロサービス間の相互運用性の鍵は、一度マイクロサービスが構築されると、それが依存する他のマイクロサービスを壊さないようにAPIを変更できないことです。そのため、APIはさらに多くのAPIでしか拡張できず、膨張につながります。
これは、以前に述べられた「過剰設計」の概念と一致しているように見えます。
実際、一部のチームが集中型モノリシックアプリケーションをマイクロサービスに分割する際、最初に領域モデルを確立するのではなく、元のモノリシックアプリケーションの単一のソフトウェアパッケージを業務機能に基づいて複数のいわゆる「マイクロサービス」パッケージに分割する傾向がありました。しかし、これらの「マイクロサービス」内のコードは密結合であり、論理的な境界が不明確であるため、本質的にはモノリシックアーキテクチャパターンであり、単なる「表面的な繁栄」を実現しただけで、望む結果は得られませんでした。
Sam Newmanが著書「マイクロサービス構築」で述べているように、アーキテクチャは特定の前提条件を満たす必要があり、さもなければ過剰設計になる可能性があります。
5 Googleが新しいマイクロサービスを提案
業界には、マイクロサービスアーキテクチャを依然として支持する意見があります。「マイクロサービスはそれに見合った規模が必要だ。」「もし最終的にある規模でこれを実行するとわかっているなら、最初から異なる方法で構築するかもしれません。しかし問題は、その方法を知っているか？どのような規模で運用するつもりなのか？ということです。」
実際、多くのアプリケーション、特に内部アプリケーションでは、開発コストがランタイムコストを上回ることがよくあります。
Googleの論文はまさにこの問題を解決します。プログラミングモデルとデプロイモデルを分離することで、開発者はより楽になり、同時にランタイムインフラストラクチャがこれらのアプリケーションを実行する最も費用対効果の高い方法を見つける「賭け」ができるようになります。
Googleの研究者たちが記したように：「すべての実行責任をランタイムに委ねることで、我々のソリューションはマイクロサービスと同じ利点を提供しながら、より高いパフォーマンスと低いコストを実現できます。」
6 インフラストラクチャ再考の年
今年は多くのインフラストラクチャの再考が行われ、マイクロサービスだけが疑問視されたバブルではありませんでした。例えば、クラウドコンピューティングもまた精査されました。
6月には、BasecampとHeyメールアプリケーションを同時に運営する37signals社が、デルのサーバーを購入し、クラウドから撤退しました。これは、数十年にわたる古いものを捨てて新しい物語を受け入れるという伝統を打ち破るものです。
David Heinemeier Hanssonはブログ記事で次のように説明しています：「これはよくあるクラウドマーケティングのフレーズです。操作がはるかに簡単になり、ほとんど誰もオペレーターを必要としないでしょう。」「（しかし現実は）私は一度も見たことがありません。37signalsも、大手インターネット企業の人々も見たことがありません。クラウドにはいくつかの利点がありますが、通常は運用担当者の数を減らすことにはなりません。」
もちろん、DHHはレーシングドライバーであり、ベアメタルを好むかもしれません。しかし、この賭けを支持する多くの賛同者もいます。今年の後半、Oxide Computersは新しいシステムを発表し、他の企業にも同様のサービスを提供したいと考えています。それは、クラウドワークロードを自社のデータセンターでより費用対効果高く実行することです。
さらに、クラウドの請求期限が迫っている状況では、この感情はさらに強まっているようです。2023年、KubeCostのような企業に目を向けてクラウド支出を管理する組織が増えるにつれて、FinOpsは注目されるようになりました。あるDataDogの顧客が6500万ドルのクラウド監視料金を受け取ったというニュースも、業界の無数の人々を再び驚かせました。
数十億の収益を生み出す組織にとって、6500万ドルの可観測性費用は価値があるかもしれません。しかしアーキテクトにとっては、過去10年間に下されたエンジニアリング上の決定によって生じた技術的負債に直面し、今こそ調整の決断を下すべき時かもしれません。
もちろん、マイクロサービスも例外ではありません。
参考リンク：
https://thenewstack.io/year-in-review-was-2023-a-turning-point-for-microservices/