「Amazonでさえサーバレスやマイクロサービスを理解できない」とDHH氏が主張する一方で、「進化可能なアーキテクチャこそ重要」とAmazonのVogels博士

今回は「「Amazonでさえサーバレスやマイクロサービスを理解できない」とDHH氏が主張する一方で、「進化可能なアーキテクチャこそ重要」とAmazonのVogels博士」についてご紹介します。

関連ワード （採用、最高、設計時等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

Ruby on Railsの作者として知られるDavid Heinemeier Hansson（DHH）氏が自身のブログに5月4日付けで投稿した記事「Even Amazon can’t make sense of serverless or microservices」（Amazonでさえサーバレスやマイクロサービスを理解できない）が話題になっています。

これはAmazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」（Prime Videoの音声映像監視サービスにおけるスケールアップと90％のコスト削減の実現）で紹介された、AWS Lambdaのサーバレスで作られたPrime Videoの監視サービスが想定の5％しかスケールせず、モノリスに作り直したところスケーラブルになり、かつコストが90％も減ったとの内容を引き合いにして、相当の規模でなければマイクロサービスやサーバレスは現実にはシステムを不必要に複雑にするものだと警告した内容です。

DHH氏は翌日、「How to recover from microservices」（マイクロサービスからどうやって回復するか）という記事まで公開しています。

DHH氏がサーバレスとマイクロサービスについての記事を公開した翌日、Amazon.com CTOのWerner Vogels博士は、DHH氏の記事には言及していないもののおそらくは意識して書いたあろう記事「Monoliths are not dinosaurs」（モノリスは恐竜ではない）を自身のブログに投稿しています。

Vogels博士はDHH氏が引き合いに出したPrime Videoの技術部門の記事の1つ前の記事「Shaping live sports publishing traffic through a distributed scheduling system」（分散型スケジューリングシステムによるスポーツ実況中継のトラフィック形成）で、キューを用いた分散システムによってスポーツイベントのライブ配信で予想される爆発的なトラフィックの発生に対応できたことを指摘します。

その上で「there is not one architectural pattern to rule them all」（すべてを支配する1つのアーキテクチャパターンはない）と強調し、システムを定期的に評価し、適切に進化可能なアーキテクチャこそ大事なのだとしています。

二人の識者によるマイクロサービスやモノリスを巡る議論は、おそらく多くの読者にも興味深いものだと思われるので、ここであらためて要点を紹介していきましょう。

Amazon Prime：想定の5％しかスケールしなかった

DHH）氏が投稿した記事「Even Amazon can’t make sense of serverless or microservices」では、冒頭でAmazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」を紹介つつ、その記事の重要な部分を引用しています。DHH氏の記事では途中を省略して引用していますが、ここでは省略せずに引用しましょう。

We designed our initial solution as a distributed system using serverless components (for example, AWS Step Functions or AWS Lambda), which was a good choice for building the service quickly. In theory, this would allow us to scale each service component independently. However, the way we used some components caused us to hit a hard scaling limit at around 5% of the expected load.

私たちは最初のソリューションを、サーバーレスコンポーネント（例えばAWS Step FunctionsやAWS Lambda）を用いた分散システムとして設計したが、これはサービスを迅速に構築するための良い選択だった。理論上、これによって各サービスコンポーネントを独立してスケール可能なはずであったが、一部のコンポーネントの使用方法が要因で、想定した負荷の5%程度でスケーリングが困難になるという限界にぶつかってしまった。

まずはこのAmazon Primeの技術部門が公開した記事について紹介しましょう。

Amazon Primeの技術部門がブログの中で説明しているのは、Amazon Primeの動画配信サービスにおいて、視聴されるすべてのストリームを監視するツールです。マイクロサービスとして開発したもののスケールせず、モノリスに作り直したことで改善したと紹介されています。

監視ツールは、画面のフリーズやブロックエラー、画像と音声の同期ずれといった動画品質に問題が発生した場合にそれを検知し、修復するプロセスに入ることを目的として開発されました。

最初はマイクロサービスで開発されたこの監視ツールは、しかし前述の通りスケーラビリティの問題にぶつかります。

ブログではその1つ目の理由はオーケストレーション管理だと指摘。ちなみに、AWS Step FunctionsとはAWSのサービスを用いて分散アプリケーションを開発するための開発ツールです。

The main scaling bottleneck in the architecture was the orchestration management that was implemented using AWS Step Functions. Our service performed multiple state transitions for every second of the stream, so we quickly reached account limits.

アーキテクチャの主なスケーリングボトルネックは、AWS Step Functionsを使用して実装されたオーケストレーション管理だった。私たちのサービスは、ストリームの1秒ごとに複数の状態遷移を行うため、すぐにアカウントの限界に達したのだ。それに加えて、AWS Step Functionsは状態遷移ごとにユーザーに課金された。

また、コンポーネント間の画像データ受け渡しもコスト増要因だと説明されました。

The second cost problem we discovered was about the way we were passing video frames (images) around different components. To reduce computationally expensive video conversion jobs, we built a microservice that splits videos into frames and temporarily uploads images to an Amazon Simple Storage Service (Amazon S3) bucket. Defect detectors (where each of them also runs as a separate microservice) then download images and processed it concurrently using AWS Lambda. However, the high number of Tier-1 calls to the S3 bucket was expensive.

2つ目のコスト問題は、動画フレーム（画像）を異なるコンポーネント間で受け渡しする方法についてである。動画変換という計算量の多いジョブを減らすために、動画をフレームに分割してAmazon S3のバケットに一時的にアップロードするマイクロサービスを構築した。そして欠陥検出器（それぞれ別のマイクロサービスとして実行される）が画像をダウンロードし、AWS Lambdaを使って同時並行的に処理する。しかし、S3バケットへのTier-1コール数が非常に多いせいでコストがかかっていた。

こうした分析の結果、マイクロサービスによるアプローチからモノリスなアプリケーションへと作り直すことが決断されます。

We realized that distributed approach wasn’t bringing a lot of benefits in our specific use case, so we packed all of the components into a single process. This eliminated the need for the S3 bucket as the intermediate storage for video frames because our data transfer now happened in the memory. We also implemented orchestration that controls components within a single instance.

私たちは、このような分散型のアプローチでは私たち固有のユースケースにおいては大したメリットがないことに気づき、結局すべてのコンポーネントを1つのプロセスにまとめた。これにより、ビデオフレームの中間ストレージとしてS3バケットを使用する必要がなくなり、データ転送がメモリ上で行われるようになった。また、単一のインスタンス内のコンポーネントを制御するオーケストレーションも実装した。

これによってスケールしやすくなり、しかもコストも90％削減されることになったのです。

DHH氏：マイクロサービスに警戒せよ

DHH氏のブログに戻りましょう。DHH氏はこのAmazon Primeの監視ツールの例を引き合いにして、これがマイクロサービスの現実だと指摘しました。

That really sums up so much of the microservices craze that was tearing through the tech industry for a while: IN THEORY. Now the real-world results of all this theory are finally in, and it’s clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse.

これが一時期、理屈の上ではテクノロジー業界を席巻してきたマイクロサービスという流行の大部分を示している。そして今、その理屈が現実世界ではどうなったのかが明らかになったのだ。現実では、マイクロサービスがシステムを不必要に複雑にする、おそらくは最大の警告であることは明白だ。そしてサーバーレスは事態をさらに悪化させるだけだ。

DHH氏は、Amazon.com全体のような大規模であればサービス指向のアーキテクチャは理にかなっているものの、それ以外では有害だと指摘します。

In many ways, microservices is a zombie architecture. Another strain of an intellectual contagion that just refuses to die. It’s been eating brains since the dark days of J2EE (remote server beans, anyone??) through the WS-Deathstar nonsense, and now in the form of microservices and serverless.

多くの点で、マイクロサービスはゾンビアーキテクチャだ。つまり、死なない伝染病の一種なのだ。奴らはJ2EEの暗黒時代（リモートサーバービーンズを覚えている人は？）から、デススターのようなナンセンスなWebサービスの時代を経て、今はマイクロサービスやサーバーレスの形になって脳みそを食らっているのだ。

J2EEからWebサービスを経て、マイクロサービスは3度目の分散アーキテクチャの流行であるとの記述は、DHH氏が筋金入りの論者であることを感じさせます。

そしてこのゾンビアーキテクチャが死の淵から戻ってこないように警戒すべきだと読者に呼びかけて、記事を終えています。

All you can do is recognize when they rise from the dead once more, and keep your retorical shotgun locked and loaded.

あなたにできることは、彼らが死から再び蘇るのを警戒し、ショットガンを構えて銃弾を装填したままにすることだけです。

Vogels博士：進化可能なアーキテクチャが重要

このDHH氏の刺激的な記事の翌日に、Amazon.com CTOであるWerner Vogels博士は自身のブログに記事「Monoliths are not dinosaurs」を公開しています。

タイトルこそ「Monoliths are not dinosaurs」（モノリスは恐竜ではない）と、DHH氏に同調したようになっていますが、冒頭の画像のキャプションにVogels博士の本音が表れているようです。

Building evolvable software systems is a strategy, not a religion. And revisiting your architectures with an open mind is a must.

進化可能なソフトウェアシステムの構築は戦略であり、宗教ではだめだ。そして、オープンマインドでアーキテクチャを見直すことが欠かせない。

Vogels博士はまず、ソフトウェアは実行しながら得られる知見もあるので、後から進化可能なアーキテクチャが大事だと指摘します。

Software is quite different, once we are running our software, we may get insights about our workloads that we did not have when it was designed. And, if we had realized this at the start, and we chose an evolvable architecture, we could change components without impacting the customer experience.

ソフトウェアは（現実の建物のアーキテクチャとは）全く違う。ソフトウェアを実際に動かしてみると、設計時にはなかったワークロードに関する知見を得ることができるだろう。そして、最初にその知見に気づかなくとも、進化可能なアーキテクチャを選んでいれば、顧客体験に影響を与えることなくコンポーネントの変更が可能なのだ。

その上で、DHH氏が引き合いに出したAmazon Primeの技術部門が書いた記事の、さらに1週間前に書かれた別の記事「Shaping live sports publishing traffic through a distributed scheduling system」（分散型スケジューリングシステムによるスポーツ実況中継のトラフィック形成）を紹介しました。

ここでは、スポーツのライブ中継のような爆発的なトラフィックの問題を、Amazon SQSを中心とした分散スケジューリングシステムを開発することで解決したことが説明されています。

この記事に続いてVogels博士は、DHH氏が引き合いに出したAmazon Primeの監視ツールに関する記事も紹介しました。

これによって、Amazon Primeのシステムの中で、ある処理では分散処理を新たに開発することで問題を解決し、別のソリューションではモノリスで作り直すことで問題を解決するという、いずれにせよ既存のシステムに対して新たなアーキテクチャを採用することで問題を解決した2つのケースを紹介したのです。

そしてVogels氏は次のように説きます（Vogles氏が太字にしたところは引用中でも太字にしました）。

There is no one-size-fits-all. We always urge our engineers to find the best solution, and no particular architectural style is mandated. If you hire the best engineers, you should trust them to make the best decisions.

すべてに適合する万能のものなどない。だから私たちは常にエンジニアに最適なソリューションを見つけるよう促しており、特定のアーキテクチャスタイルが強制されることはない。最高のエンジニアを雇用するのなら、彼らが最善の決定を下すことを信頼する必要があるのだ。

アーキテクチャとは設計時に決めたものをずっと固定するのではなく、定期的に見直すものであり、進化可能であることこそ大事だと、Vogels氏は記事を結んでいます。

Evaluating your systems regularly is as important, if not more so, than building them in the first place. Because your systems will run much longer than the time it takes to design them. So, monoliths aren’t dead (quite the contrary), but evolvable architectures are playing an increasingly important role in a changing technology landscape, and it’s possible because of cloud technologies.

Now, go build!

システムを定期的に評価することは、最初にシステムを構築することと同じくらい、あるいはそれ以上に重要だ。なぜなら、システムは設計にかかる時間よりもはるかに長く稼働するからだ。つまり、モノリスは死んでない（むしろその逆だ）。そうではなく、変化するテクノロジー環境において進化可能なアーキテクチャがますます重要な役割を果たしているのであり、クラウドテクノロジーのおかげでそれが可能になったのだ。

Now, go build!（注：ここはあえて訳しません：-）