Amazon DynamoDBに感じた痛み
Amazon Redshiftのプロダクトマネジメント・ディレクターを勤めているEugene KawamotoさんがAmazon DynamoDBが誕生した歴史から、周知し、普及していく過程についてTweetされている。
前半の話、Amazon DynamoDBが分散型KVSとして誕生した過程に関する話は非常に良かった。Amazon DynamoDBの論文は初めて拝見したし、分散型KVSの目的を認識し、来日時のエピソードにほっこりさせられた。
自分として非常に突っかかりを覚えてたのは後半の話になる。こちらではAmazon DynamoDBが既存のKVSでありOSSであり競合であったApache Cassandraに打ち勝ち、シェアを勝ち取っていった過程を説明している。
自分なりに説明を補ってみる。当時の分散型KVSのメインユーザーはアドテク企業(インターネット広告の最適化を行い、広告による利益の追求を行う企業)だった。2010年頃にアドエクスチェンジ市場がちょうど整い、広告単価を最適化することが利潤に直接つながる中、膨大なプラットフォームである広告市場にてシステム規模をスケールできるデータベースが求められていた。個々のユーザーの個人行動や嗜好に合わせた広告を様々な広告ネットワークに出稿するために、ユーザーの属性情報をストレージで管理する必要があったからだ。
その用途に最も最適だったのがKVS(Key-Value Store)であり、当時競合としてOSSのApache Cassandraという巨人がいた。Aamazon DynamoDBはその勢力図を完全に塗り替えてしまう。その理由がアドテク企業の一社だったAdRoll社によりシェアされた、Apache CassandraからAmazon DynamoDBへデータベースをマイグレーションしたことによる大幅なコスト削減報告だった。
- AdRoll社のケーススタディについて
https://aws.amazon.com/jp/solutions/case-studies/adroll-tco/
AdRoll社のCTOであるValentino Volonghi氏によると運用保守費用を83%削減できたという(オンプレミス環境からの移行などデータベース以外の費用も当然含む)。
そのからくりはなんだろうか？
なんてことない、彼らCassandraエンジニアのクビを切ったのだ。ユースケースでは彼らによって浮いた人件費について次のように試算している。
- 原文
AdRoll estimates that it would need at least 20 full-time engineers to effectively manage the physical environment:
- 8 full-time employees on call across four different data centers (two in each location for redundancy)
- 1 product manager for auto-scaling and API management
- 5 engineers to develop and maintain auto-scaling across the infrastructure
- 5 engineers to maintain Cassandra installation instead of DynamoDB
- 1 engineering manager
The overall annual staffing costs, with an average engineering salary of $150,000, would be $3 million.
- DeepLによる翻訳
AdRoll社では、物理的な環境を効果的に管理するために、少なくとも20人のフルタイムエンジニアが必要であると考えています。
- 4つの異なるデータセンターに8人のフルタイム社員を待機させる
（冗長性のために各場所に2人ずつ配置- オートスケーリングとAPI管理を担当するプロダクトマネージャー1名
- インフラ全体のオートスケーリングを開発・維持するエンジニア5名
- 5人のエンジニアがDynamoDBの代わりにCassandraのインストールを維持する
- エンジニアリングマネージャー1名
エンジニアの平均給与を15万ドルとした場合、全体の年間人件費は300万ドルとなります。
AWS Summits 2014でも同様の内容をCTO自ら説明しており、こちらでは年間で浮いた人件費を260万ドルともう少し正確に試算している。
果たして、アドテク企業への影響は劇的だった。AWSの人は高笑いが止まらなかっただろう。AWSの中ではおそらくこの話は当時非常に有名だったのかもしれない。
同じころ、AWS Japanにてソリューションアーキテクトを勤めていた今井 雄太氏も同じ話をしている。こちらでも運用保守のSaaS化による人員削除が成功の鍵だという。
選択肢としてご紹介するのが、CassandraとDynamoDBというAWSのデータベースサービスですね。最終的にAdRollではDynamoDBを導入しているわけですが、その経緯を少し。ちょっと宣伝っぽくなっちゃいますけど（笑）。
たとえば、1000億アイテムをさばくときに、AdRollの計算ではDynamoDBのほうが最終的には安くなったということになっています。あとはCassandraを運用するうえで必要なのが、毎月1500万円分ぐらいのエンジニアリソースが必要でしょうみたいなところをAdRollは計算をして…という経緯もあるのかな、と。個人的な感覚だと、東京だけで、そのシステムを展開するというのであれば、恐らくCassandraの運用というのも、充分できるんじゃないかなと思うんですけれど。AdRollは世界4リージョンのすべてのタイムゾーンの地域に広告を配信してるということになります。ということは24/365でCassandraを面倒見れる人が必要になるわけで。そうすると、費用もそうですけども、そもそもそんな人を24/365で潤沢に雇えるか、みたいなネックもあってDynamoDBが選ばれたのかなと思っています。
先に挙げたAdRoll社のCTOは多大な功績を称えられ、AWS Community Heroを2014年より務めている。
さて、自分はこのTweetに対して闇深wと最初は茶化す感じで感想を述べた。だが、こうやって当時の時代背景について調べる中でだんだん幻肢痛が生じてきた。これはもしかしたら決してトップレベルではないであろう未来の自分にも十分に降りかかる未来なのかもしれない。それを意識した瞬間、ないまぜの意識が混在した。
-
単純に運用保守の高度化により、マンパワーが要らなくなり、さらにはそれを統括するPM、チームリーダーも削減された中に自分がいるかもという恐れ
-
特定のプロダクトに高度に特化した人材が、技術の抽象化によりそのプロダクトを開発しているclosedな人材を残して民主化した結果、行き場をなくしたという寓話への皮肉
後者について、偶然直近で、これに似た話を聞いた。 Seeing like an SRE という内容だ。
ざっくり言えば、ハイ・モダニズムという、都市計画をえらい人が上から頭ごなしに決めたら失敗した事例を元に、高度な技術(この場合はシステムのメトリクス)を持つSREにも、解像度を変えてメトリクスに詳しくない他の人に伝える工夫をも同時にしなければならないという教訓が言えるよねという話だ。
ただし、そのような意識を持ってしても、対話が果たして成功していたかというと微妙であろう。アドテク企業という徹底的な数値化により利潤の拡大が至上命題のような企業で多大な運用費をもってシステムを腹抱えする理由はどこにもない。Apache Cassandra運用辛いというのは人から聞くことは多いし、これだけ運用が嫌われるOSSはApache Kafkaの登場まではずっとApache Cassandraだった。どんなに努力しても...感は薄々思う。
そうか。自分はクラウドベンダーというブラックボックスに全て飲み込まれていく姿を見るのが、単純に癪なのだ。
オンプレミス=>クラウドベンダーという技術選定は、結局は高度な技術を持った人材が自分たちで運用することで得られるフィードバックについて努力すべき説明責任をクラウドベンダーに押し付けてその利益のみを追求する行為だ。それはエンジニアとしてありなのか？そういう行為を続けることが結局はハイ・モダニズムの犠牲になった住人となる道ではないだろうか。
詳説 データベース――ストレージエンジンと分散データシステムの仕組み という本が最近和訳された。データベースとストレージエンジンの内部で利用されている概念を解説した、近年例を見ない書籍である。 本書は、データべースシステムを使ってソフトウェアを構築するすべての人に必携の一冊だ。 とりあえず積んだ。
Discussion