256bitの殺人メニュー

インフラエンジニアだったソリューションアーキテクトなくわののブログ。こちらのBlogは個人の意見となっていて会社とは全く関係ありません。お約束です。[twitter:@kuwa_tw]めんどくさがりが重い腰を上げて何かをアウトプットすることにどれほどの意味があるのかを試してみたいブログでもある。

本当にDropboxはオンプレ回帰なのだろうか?

おはようございます。やっぱヒノキっぽいんだよなぁ、、、(花粉 ということで鼻ズルズルマンです。

Dropboxはオンプレ回帰した?

最近良く聞きます、Dropboxはオンプレ回帰した、クラウドはコストが高いから最近オンプレに戻る企業が増えている、とか。

一つ一つの記事やツイートをイチイチピックアップはしないですが、とにかくよく聞くわけです。

でも思うんですよね、「そんなわけないのでは?」だってよく考えてみてください、テックが強い組織であればあるほど適材適所でクラウドを使ったほうがいい所も見えてきます。 現代のアーキテクチャクラウドがハマる部分が全くないシステムはありません。一時的なリソース確保と開放、管理のいらないインフラ、様々なサービス。これを利用しないなんてことあるのかな?ってことなわけです。無理にオンプレのみで頑張るのが論理的か?という話かもしれません

Dropboxがオンプレに移設したシステム"Magic Pocket"とは?

よくお話に出るオンプレ回帰の根拠はこれです。

dropbox.tech

このMagic Pocketと呼ばれているSMR(Shingled Magnetic Recording)を使用したストレージシステムにAmazon S3から置き換えたということです。 これはまずDropboxというサービスがストレージをお客さんに貸し出すサービスで、どうしてもストレージを大量にもつ必要があったから、そしてローカルストレージの共有サービスであるためにある程度低いレイテンシが求められたから、です。Dropboxはサービスを高速に拡張するためにS3バックエンドでサービスを開始しました。ですが、ストレージを大量にS3に置くことで問題が出ることは想像に難くはないわけです。まず、一番大きいのはストレージコストだと思います、データ保存自体の料金は必ずしも高いものではないと思いますが、リクエスト料金、そしてEgressのネットワークトラフィック料金については大量にかかるはずです。そしてパフォーマンスです、S3などのRestベースのアプリケーションのオーバーヘッドは通常のブロックデバイスのアクセスに比べるとレイテンシは大きいものとなり、細かいファイルへのアクセスがほとんどと思われるDropboxのオーバーヘッドは積もり積もって大きなものになっていたと想像します。加えてDropboxの人の言葉を借りると「ストレージを社内に持ち込むことで、スタック全体をエンドツーエンドでカスタマイズし、特定のユースケースのパフォーマンスを向上させることができます。」ということなので、各コンポーネントを近い場所に置くことができるとレイテンシに有利ということなのかと想像します。

これらの要件、更に安いギガバイトあたりのコスト、更に低いレイテンシ、達を解決するために恐らく僕らが想像するより大量の集約したオンプレミスと、その中に独自に作り込んだシステムがMagic Pocketなわけです。

dropbox.tech

Magic Pocketについて詳しくはこちらを見ていただければと思います。

じゃあDropboxはオンプレ回帰したのかというと、そうではなく、あくまで解決したかった問題を解決するための手段としてオンプレを選択しただけじゃないかなと思っています。

Dropboxはじゃあパブリッククラウドを使ってない?

Magic Pocketは2015年に稼働しはじめたわけですが、2020年にDropboxはこういった事例をだしています。

aws.amazon.com

34PBのデータレイクをオンプレミスのHadoopからS3上に移設した、という事例です。34PBのデータをS3にただ置くだけで年間いくら掛かるかというと、最適化しないと10億円以上かかります。実際はクラスタとか色々起動するのでそんなものではないと思いますが、ここから34PBは間借りするレベルではなく、これは必要であればクラウドもちゃんと使うよという意思を感じる量ですよね*1

そして次に2023年の記事です

dropbox.tech

これにも”the backend is a Hadoop cluster on top of Amazon Web Services (AWS). ”(バックエンドはAWS上のHadoopクラスタである)と書いてある記事があり、恐らく上記のクラスタであるということが言えるかなと思います。

また、この記事にも、 dropbox.tech

”The Dropbox platform runs on a hybrid cloud infrastructure that encompasses our data centers, global backbone, public cloud, and edge points-of-presence (POPs)”(Dropbox プラットフォームは、当社のデータセンター、グローバル バックボーン、パブリック クラウド、エッジ ポイント オブ プレゼンス(POP)を網羅するハイブリッド クラウド インフラストラクチャ上で実行されます)とありますのでパブリッククラウドとの接続はきちんと持っているようです。

追記

追記の情報もらったので追加

"Alki"というユーザのコールドメタデータを管理するシステムもDynamoDBとS3という構成でかなりキッチリAWSを利用する構成になっているようです。 個人的に2020年でこれ組んでるのめっちゃ熱い

dropbox.tech

www.youtube.com

オンプレ回帰ってなんだろう

ここまで色々見てきましたが、このようにDropboxさんが何をどこまで持っているかわからないですが、まず超大規模と言えるシステムがあり、その中で解決したい問題があり、そのための手段としてオンプレを選択している。ただ必要に応じてパブリッククラウドはもちろん使うという話でした。 要するに、これは単純な判断のなか高いからやっぱりクラウドやーめた!みたいな判断ではなく、まずDropboxという前提ありきの、オンプレ回帰というよりはもっと大きな組織の判断であって、一般的な潮流としてオンプレ回帰を狙うことは殆どにおいてないのではないかと思います。

もちろんクラウドの合う合わないユースケースはあると思います。人件費、データセンタコスト、ネットワークコスト、などなどを鑑みて一部オンプレ、みたいな判断はあると思います。ですが、全面的にクラウドを撤退するという判断は現段階において一般的な判断ではないというのは、システムをオンプレ上に構築し、運用するのにどれくらいのエンジニアが何をする必要があるか、エンジニアを雇う?他の会社にやってもらう?そしてアーキテクチャをきめ、HWの選定をし、購入し、構築をし、運用をします、壊れれば対応をし、改善し続ける、このコストを払うことのできる場合に行える選択だと思うからです。これはただクラウド高いからオンプレにもっていきました幸せ!というシンプルで簡単な話ではないと思います。

クラウドのコストが高いというのであれば何にコストがかかっているのかを明確に、パフォーマンスの課題があるならどこに課題があるのか明確にして、それを解決する手段として何を取るのか、みたいな所から判断をしていくことができるはずです。そしてそれは”オンプレ回帰”でというバズワードのようなものではなく”適材適所の選択”であるべきだと感じました。

適当に書いてみましたが、みなさんの良いクラウド?オンプレ?生活の一助となれば幸いです! ではでは!

*1:EBと比べれば小さいというのはわかりますがw