今年の３月頃、Amazon Prime のテックブログでストリーミング監視システムのマイクロサービスをモノリスに作り替えて90%コストを削減した記事が投稿され、ソフトウェア業界に波紋を呼びました。この記事の真相はなんだったのか、我々が学ぶべきことはなんだったのかについて書きます。
ことの経緯
問題の記事はこちら。
火種となったのはこの記事の副題です。直訳すると
”分散マイクロサービスアーキテクチャからモノリスアプリケーションへの移行により、高いスケーリング、信頼性向上、コスト削減を実現しました”
といった具合でしょうか。
この記事が公開されるやいなや、業界に衝撃が走りました。なぜならあれほどマイクロサービスやサーバレスを推していたAmazon(AWS)が、モノリスに乗り換えたというのですから。
一部の人は”それみたことか”という反応を示しました。代表的な記事はDHH(RoRの作者)の”Amazonもサーバーレスやマイクロサービスを使いこなせない” です。この出来事を痛烈に批判しています。
記事の解説
が、実際のところどうなのでしょうか。この記事の内容を解説してみます。
Amazon Primeチームが刷新したストリーミング品質監視システムは、視聴データをリアルタイムでモニタし、画質低下時に改善処理をトリガーするものです。 Detectorというコンポーネントが映像/音のバッファーを受け取り、MLで品質を解析し、問題があれば別システムに通知する仕組みです。
このシステムは2つの課題がありました。
- 検知システムのボトルネック。DetectorはStep function(Lambda functionをオーケストレーションする仕組み)で行われていたのですが、処理限界にヒットしてしまいました。またStep functionはステートの遷移ごとに課金されるのでリアルタイム処理だとどんどん高くなります。
- バッファのキャッシュコスト。バッファを生成する映像変換はCPUコストを使うため、別システムにして処理後のデータをS3(ストレージ)に保管しそれをモニタするようにしていました。S3はアクセス数で課金されるため、リアルタイムに近い大量のアクセスは非常に高コストになります。
そこでチームは解決策として、Step functionなどをなくし、すべての処理を1つのシステムに統合しました。画像処理も同じインスタンス内で行うようにしたので、キャッシュ機構が不要になり、90%のコスト削減のみならず、システムがシンプルになりました。
ただしシステム上スケールアップしかできなくなったので、lambda functionをストリームの最初におき複数のインスタンスでオーケストレーションできるようにし、スケールアウトにも対応できるようにしました。
ここまでが記事の内容でした。
この記事はなんだったのか?
冷静に読み解いていくと分かる通り、サーバーレスやマイクロサービスをやめたわけではないです。システム図を見ても分かる通り、Lambda functionは使われているし、このシステム自体もマイクロサービスの一部だと想像できます。
この記事は、 ”ストリーミング監視にとって効率良いシステムに書き換えた” という話に過ぎないのです。しかし副題につられて、多くの人が脊髄反射的に反応したのでした。(ちなみに英語ではこういう記事をClick baitと言います)
この記事と出来事の教訓
この出来事からの教訓はなんでしょうか。まず、 システム設計に銀の弾丸は存在しない ということです。世の中には様々な設計手法があり、トレンドもあります。ただ、あらゆる機能/非機能要件をみたす設計は今のところ存在しないです。例えばスケーラビリティを重視してコストを度外視する設計もありえます。
しかし重要なことは、 事業にあった設計は存在すること です。今回のストリーミング監視という用途においては、モノリスが一番最適な設計であったということで、その判断を下した開発チームは素晴らしいと思います。
技術者としては、技術要素にとらわれることなく、常に学び続け、どう活かせるかを引き出しにいれておくことが大事なのかと考えます。
この記事について Today I learned FM でも話しているので、よかったら聞いてみてください!
