InfoQの「Evolution of a Backend for a Streaming Application」は、ドイツのストリーミングサービス Joyn のバックエンドが、どうやって“火の車”状態から立て直されたのかを語るプレゼンだ。
話しているのは Daniele Frasca さん。ざっくり言うと、「最初はかなり苦しい構成だったけど、AWSベースのserverlessへ段階的に移行して、可用性・スケーラビリティ・デプロイ速度を改善していった」という内容である。
これ、かなり現場感が強い話で面白い。きれいな理想論ではなく、**“どうにかしてマシにする”ための改善の積み重ね**が中心なのが良い。現実のシステムって、だいたいこういう地味な改善の連続なんだよな、と思う。
プレゼンの冒頭で語られるのは、昔のアーキテクチャのしんどさだ。
構成としては、Kafkaのtopicを購読するworkerがいて、データを変換してDBに保存する。そして別にGraphQL APIがあり、フロントエンドから大量に叩かれる。構造そのものが即ダメというより、**“ちゃんと作れば成立するが、実際にはそうなっていなかった”**という感じだ。
問題はこんなところにあった。
このあたり、かなり共感する人は多いのではないか。技術的負債というとコード品質が注目されがちだけど、実際には構成そのものが負債になっているケースも多い。しかもそれは、コードを少し直すだけでは片付かない。
結論からいうと、チームは serverless に寄せていった。
ここでのserverlessは「サーバーがない」という意味ではなく、サーバーの面倒をかなりAWSに任せて、開発者はアプリの中身に集中しやすくするという考え方だ。運用の細かいことを自前で抱え込まなくてよくなるのが大きい。
Danieleさんは、serverlessを「かっこいいから」選んだわけではないと明言している。理由はもっと実用的で、本当に大事なコードに集中するためだという。ここはとても大事な視点だと思う。流行で採用するのではなく、苦しみを減らすための選択としてserverlessを使う。これが筋がいい。
AWSのmanaged servicesを使うことで、次のような問題をかなりAWS側に寄せられる。
つまり「落ちにくく、伸びやすい」土台を自前で全部作らないで済むわけだ。
地味だけど、かなり重要なのがこれだ。
もともとのデプロイには 1時間半 かかっていたが、改善後は 数分 になったという。
これは単なる“便利”ではなく、開発速度そのものを変える。デプロイに1時間半かかると、人はどうしても変更に慎重になるし、改善のサイクルも鈍る。逆に数分なら、試して直してまた試す、という流れが作りやすい。
個人的には、ここは本当に侮れないと思う。
システム改善というと「障害が減りました」が注目されるけれど、デプロイが速くなること自体が、チームの学習速度を上げる。これが長期的に効く。
このプレゼンの面白いところは、単に“スケールしました”で終わらないことだ。むしろ難しいのは、データの一貫性だった。
ストリーミングサービスでは、ユーザーが見た情報が別画面でも正しく見えることがとても大事だ。たとえば、あるページで動画が見えていたのに、詳細ページに行ったら表示されない、というのはかなり印象が悪い。技術的には「データの整合性が取れていない」状態だが、ユーザーには単に「このアプリ、信用できない」と映る。
ここで登場するのが Hub and Spoke pattern だ。
簡単に言うと、中心となるHubにデータの正本を寄せて、そこから周辺のSpokeへ配る考え方だ。
これにより、サービスごとに勝手なデータを持ちすぎてズレる問題を減らしやすくなる。
要するに、「みんな好き勝手に真実を持つ」のをやめて、真実の置き場所を絞るイメージだ。
もちろん、これで全てが魔法のように解決するわけではない。でも、データの由来を整理するだけでも、運用はかなり楽になるはずだ。
次に出てくるのが cell-based isolation だ。
これは、システム全体をひとまとめにせず、独立した“cell”に分ける考え方だ。あるcellで障害が起きても、他のcellに被害が広がりにくい。つまり blast radius（爆風範囲） を小さくする。
この発想はかなり現実的だと思う。
大きくて強い単一システムを目指すと、1つのミスが全体に波及しやすい。反対に、適度に分割しておけば、失敗しても被害を限定できる。
ストリーミングみたいに利用者が多く、24時間止めにくいサービスでは、こういう設計が効く。
「全部を完璧に守る」のではなく、「壊れても全滅しない」に寄せる。かなり実務的で、好きな考え方だ。
もう1つの大きなテーマが、multi-region active-active だ。
ここで少し補足すると、
つまり、片方が落ちてももう片方でサービス継続できる構成だ。強い。ただし、当然コストも設計難易度も上がる。
Danieleさんたちは、最初から完璧な形を作ったのではなく、サービスごとに active-active と active-passive を使い分けている。
ここが実に現実的だ。全部を最高レベルの冗長化にすると、たしかに強いが高い。逆に、そこまで不要なものに重装備をすると費用対効果が悪い。なので、**“どこまで守るか”をサービス単位で変える**のが賢い。
プレゼンの説明でも、可用性・スケーラビリティ・低コストを全部同時に満たすのは難しい、という前提がはっきり語られている。これはその通りで、管理側がよく「全部ほしい」と言うけれど、現実にはトレードオフがある。そこをちゃんと共有するのもアーキテクトの仕事だと思う。
このプレゼンを見ていて強く感じるのは、アーキテクチャ改善は“一発逆転”ではないということだ。
最初の構成がダメだったから全部作り直した、という単純な話ではない。実際には、
という順番で、少しずつ改善している。
この「少しずつ」が重要だと思う。
巨大システムの改善って、理想設計を一気に入れ替えるより、壊れ方を減らしながら進める方が強いことが多い。現場はロマンよりも連続性。そこをきちんとやっている話だった。
率直に言うと、これは「serverless万歳」の話ではないのが良い。
むしろ、苦しい状況を現実的に改善するためにAWSを使いこなした話として見るとかなり学びが多い。
特に印象に残ったのは次の3点だ。
ストリーミングサービスは、ユーザーが「見たい」と思った瞬間に動かないと致命的だ。だからこそ、裏側の設計がそのままサービスの価値になる。
このプレゼンは、その現実をかなり生々しく教えてくれる内容だったと思う。
