Google Cloud Spanner、Amazon DynamoDBの半額で利用可能に
(cloud.google.com)- Google Cloudは、Cloud Spannerの価格を据え置いたままスループットを最大50%高め、ノードあたりのストレージ容量を2.5倍に拡大し、多くのワークロードでAmazon DynamoDB比で半額のコストになると発表
- 改善後もSpannerは、強い外部整合性、1桁ミリ秒のレイテンシ、実質的に無制限のスケーリング、99.999%の可用性SLAを維持
- ノードあたりのストレージ容量は4TBから10TBに増加し、ユーザーは増えた上限に関係なく、引き続き実際に使用したストレージ分のみ料金を支払う
- アップデートは一部のリージョン／マルチリージョンのインスタンス構成で先行提供され、残りの構成とストレージ容量のアップグレードは今後数か月かけて適用される
- 顧客は再プロビジョニング、ダウンタイム、ユーザー側の対応なしに現在の料金で改善効果を受けられ、月額65ドルから本番向けインスタンスを開始するか、90日間の無料トライアルを利用できる
Cloud Spannerの価格性能比の改善
- Google CloudはCloud Spannerの価格を変えずにスループットを最大50%向上させ、ノードあたりのストレージ容量を2.5倍に拡大
- この改善により、多くのワークロードでSpannerをAmazon DynamoDBの半額で利用できるとしている
- Spannerは高いスループットと実質的に無制限のスケーリング、1桁ミリ秒のレイテンシ、99.999%の可用性SLA、強い外部整合性セマンティクスをあわせて提供
- すべてのSpanner顧客に今後数か月以内に適用され、再プロビジョニング、ダウンタイム、ユーザー側の対応は不要
コンピュートとストレージの変化
- コンピュート面ではスループットが50%改善され、リレーショナルワークロードとキー・バリューワークロードでコスト効率が高まる
- ストレージ面では、Spannerの1ノードが収容できる容量が従来の4TBから10TBに増加
- 容量上限が増えても、実際に使用したストレージ分のみ料金を支払う
- Spanner環境を最適化する柔軟性が高まる
- 同様のワークロードを基準に、SpannerはAmazon DynamoDBよりも1ドルあたりの読み取りスループットが最大2倍高いとしている
性能特性と適用ワークロード
- Spannerは同一リージョン内の複数のアベイラビリティゾーンにまたがり、強い整合性の読み取りと書き込みに対して予測可能な1桁ミリ秒のレイテンシを提供
- 使い慣れたSQL、メンテナンスによるダウンタイムなし、99.999%の可用性SLAも提供し、リレーショナルデータだけでなく読み取り中心のキー・バリューワークロードにも適している
- Google社内ではAds、Gmail、PhotosなどのサービスでSpannerを使用
- AmazonのPrime Dayブログ記事によると、DynamoDBはピーク時に毎秒1億2,600万クエリを処理
- Spannerはピーク時に毎秒30億クエリを処理し、管理中のデータは12エクサバイトを超えるとしている
顧客事例と提供スケジュール
- Uberは、Spannerがミッションクリティカルな運用の重要な構成要素であり、スケーラビリティと低い運用コストに価値があるとしている
- Spanner導入前のデータ管理フレームワークは多くの監督と運用作業を必要とし、複雑さと支出が増えていた
- シャーディングや結果整合性といった従来の回避策は開発速度の障壁になっていた
- Spanner導入後は運用コストが簡素化され、信頼性が改善し、同じ価格でより優れたスループットと性能を得られた
- CERCはスループットとノードあたりストレージ容量の増加により、運用効率を改善
- 価格性能比の改善は現在、一部のリージョンおよびマルチリージョンのインスタンス構成で利用でき、残りの構成にも順次適用される
- ストレージのアップグレードは今後数か月かけて展開される
- ユーザーは90日間の無料トライアルを利用するか、月額65ドルから本番対応インスタンスを開始できる
1件のコメント
Hacker Newsのコメント
最近、インフラをGCPからAWSへ移行した。Kubernetesクラスタ、ロードバランサ、ストレージ、Lambda、KMSまで全部移した。
Googleは、自分の履歴書作りをしたいスタートアップのように技術スタックを運用している感じで、未成熟な部分・ハック・文書化されていない機能があまりにも多かった。GKEを使っていると新しいバージョンや機能が次々出てきて、Google側の欠陥のせいでインフラに入れていた重要な回避策を何度も手直しし続けなければならなかった。
インフラチームの時間は、半分がGoogleの問題に備えることに、もう半分が本来予定していたインフラ作業に使われるような状態で、終わりがなかった。AWSへ移行した後は、3つのKubernetesクラスタで請求額がGCP時代の**60%**程度になった。
AWSサポートは信じられないほど良く、Googleサポートはひどかった。2020年に報告したバグが最近、何の対応もないままstaleとして閉じられたが、APIが変わりすぎて今ではもう意味もない、というような扱いだった。毎月の請求日のたびに、他社ならずっと上手にやっている仕事ができない開発者たちにお金を払っている事実を思い出させられたし、まったく恋しくない。
ヨーロッパでビデオゲーム関連の仕事をしているが、UbisoftにいたときのAWSの印象は非常に悪かった。Tencent/Sharkmobに移った後、業界標準なのでAWSを好きになろうと努めたが、大半はLambda関数で覆い隠した一貫性のないゴミのように感じた。
こうした奇妙な落とし穴を午前3時案件と呼んでいた。午前3時に対処する気力のない問題だからだ。スタジオを説得してGCPへ切り替え、今でもその決断にとても感謝している。
一方、GCPよりシェアがはるかに大きいAzureはひどく、全体として完全にめちゃくちゃだ。サポート費用を払ってもエンジニアリング担当者につながるのは難しく、AWSは素晴らしい。
Enterprise Supportを使っているので担当者たちがSlackチャンネルに入っており、TAMも良い。Route53の担当者が必要ならその週に通話が設定されるし、EKSの機能要望もその日の午後にはプロダクトマネージャーと話せる。Azureは土台からして大混乱だ。
AWSサービスを開発していたとき、顧客サポートの電話を直接受けていて、仲介者はいなかった。技術者同士が直接話し、その場で顧客に約束することもあったし、顧客がこちらの仕事をプロジェクト管理することもあった。
彼らがGAEと話してみると、実際に自分たちが見ていたダウンタイムはGAEのダウンタイムと相関していた。しばらくGAEの稼働率は良くなったが、うちも今はAWSを使っている。
一方でGCPサポートはF評価で、どんなレベルの助けでも受けるには、ほとんど懇願しなければならない感じがする
「Amazon Prime Day のブログによれば、DynamoDB はピーク時に秒間1億2600万クエリを処理する。一方 Spanner はピーク時に秒間30億クエリを処理し、20倍以上高く、12エクサバイト以上のデータを管理する」という比較は、正確には公正に見えない
Amazon の秒間1億2600万クエリは、Prime Day を処理する Amazon 関連サービスが DynamoDB にかけた負荷であって、AWS 全体ではないと読める
より公正に比較するなら、Google のサービスが Cloud Spanner にかけたピーク負荷を共有すべきで、GCP 全体と Google 内部の非 GCP インフラで動くすべての Spanner サービスを合算すべきではない
Photos、Gmail、Ads が GCP インフラに大きく依存していると言うなら強い信頼のシグナルになるが、私にとっては新情報だ。特にこの記事では普段は「Cloud Spanner」と言っているのに、Gmail、Ads、Photos について述べるときだけ「Spanner」と表現していて、これらが Cloud Spanner インフラを使っているのか、自前インフラで Spanner を動かしているのか分かりにくい
Amazon では実質的にすべてのサービスが AWS 上に構築されており、確かな信任投票のように見えるが、GCP は歴史的に Google 内部サービスではずっと使われてこなかったという印象があった
“DynamoDB powers multiple high-traffic Amazon properties and systems including Alexa, the Amazon.com sites, and all Amazon fulfillment centers. Over the course of Prime Day, these sources made trillions of calls to the DynamoDB API. DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 126 million requests per second.”
Amazon はこの点を非常に明確にしていた。Google がこの数字をそうした前提なしに使ったのだとしたら、完全に卑劣で不誠実な比較だ。この記事を書いた人には誠実さが足りないように見える
https://www.youtube.com/watch?v=268jdNwH6AM
ブログには “Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.” とある。だが Google 内部の Spanner と GCP Spanner は区別される。Google のサービスが Spanner を使っているからといって、必ずしも GCP を使っているという意味ではない
ただし私の理解では、Spanner と GCP Spanner は Borg と Kubernetes の関係よりもはるかに近い
AWS 全体の使用量をすべて合算したとしても、Prime Day における Amazon 自身の使用量が秒間1億2600万クエリなら、DynamoDB が Spanner を超えるかはかなり疑わしい
「Database as a Queue」で検索してみれば雰囲気が分かる。実際、AWS でリレーショナルデータベースを使うのは本当に難しく、チームが例外を得るには CEO 承認まで必要になるほどで、DDB の堅牢さを示している
多くのプロジェクトでは、今でも Postgres のほうが両者より安い。どちらも使ったことがあるが、Spanner や DynamoDB を使うより、プロジェクトを Postgres/CockroachDB に合わせる作業のほうをずっと好む
Spanner と DynamoDB には落とし穴がはるかに多く、突然のコスト急増、ベンダーロックイン、その他の問題もある。AWS、GCP、Azure、Oracle Cloud、Kubernetes オペレーターによるデプロイまで Postgres は非常によくサポートされているので、ただ Postgres を使えばいい
Postgres をきちんと運用できるなら、当然使うべきだ。すべてのデータを1台のマシン上の Postgres に入れられるなら、グローバルにスケール可能な P 級データベースを使う理由はない
何百万件ものメッセージがあり、「関係」がほとんどないチャットアプリを作るなら、Postgres を使うべきなのか、何らかの NoSQL 系を使うべきなのか、本気で気になる
分散関数と Lambda 上のコードを扱っていると、SQL の接続管理が悪夢になり、リクエスト漏れがあちこちで発生した
PostgreSQL は素晴らしいし、私は Google で働いているが100%同意する。うまくいかなくなるまでは、ただ PG を使えばいい。Spanner と DynamoDB の領域に入って初めて、こうした議論に意味が出てくる
完全に別物だが少し安いものなら、何でも「ただ使え」と言えてしまう。例えば GitHub リポジトリにレコードをコミットとして保存すれば無料で、小さなプロジェクトには十分安いだろうが、同じものではない
GCP Spannerは「月額65ドルから」だが、AWSの無料枠は「25GBのデータストレージ、250万件のストリーム読み取りリクエスト」などを提供している
https://aws.amazon.com/dynamodb/pricing/
グラフ上ではいつか線が交差するのだろうが、Googleの見出しは誤解を招くように思う
教育目的でないなら、小さなプロジェクトで使う理由はほとんどなく、Spannerの顧客は、たとえばCockroachDBでも足りないようなところだ。そこまで巨大でないデータベースならPostgreSQLで十分
最近は1か月で1億人以上のユーザーに到達するアプリケーションも多く、50 QPSを扱うような状況ではない。さらにDynamoDBのバイト境界も見落としている。1KBをたった1バイトでも超えると、読み取りユニット2個分が課金される
「Googleも入門向けの割引を提供すべきだ」という主張は非常に妥当だが、実際の製品が高いのか安いのかを示すものではない
個人プロジェクトやサイドプロジェクトでSpannerを触ってみたいが、本番運用に耐えるインスタンスは月額65ドルから始まる。DynamoDBならリクエスト単位課金で、月額ほぼ0ドルで運用できる
ただしリクエスト単位課金も無料枠内に収まっている場合だけ無料だ。上限を確認する必要があり、超えればもう無料ではない
CRDBのアーキテクチャは本質的に内部ではSpannerに近い
https://www.cockroachlabs.com/get-started-cockroachdb/
以前はGoogle製品がかなり好きだったので、気持ちは複雑だ。Gmailにはかなり縛られているし、GCPですでにいろいろ動かしている
だが、Googleがサービスを突然終了することに、だんだん痛い目を見てきた感覚もある。すべてのドメインをGoogle Domainsに置いて便利に使っていたのに、最近突然Squarespaceに売却され、その会社とは取引したくない
Google Pixelを使い、Google Podcastsアプリも使っていたが、これも終了してYouTube Musicに移行されると聞いた。YouTube Musicは試したが本当に嫌いなので、代替を探さなければならない
長期的には些細なサービスかもしれないが、重要なサービスを再びGoogleに任せるのは不安だ。時間をかける前に「いつかGoogleがCloud Spannerを売却したり終了したりしたらどうなるのか。そのとき困るのか」と自問してしまう
ドメイン登録は規制や評判の面で地雷原になり得るが、コンテンツ配信を含む他のクラウド製品も同じだ。まだGoogle Cloudサービス終了の大きなパターンを示しているとまでは言いにくいが、少なくとも黄信号は点いた
Google製品の終了は腹立たしいが、Google Cloudの製品・サービスとは関係がない。Google Cloudには有料顧客がいるので、製品・サービスの終了を突然発表するとは思わない
Google DomainsはGoogleの製品であり、Google側の対応製品はGoogle Cloud顧客向けに提供されるGoogle Cloud Domainsだ
「あらゆる規模、あらゆる業界の組織がデジタルトランスフォーメーションを加速し、AI主導のイノベーションを推進しようとするニーズが高まっている」とは、Googleはどうしてこうなったのか
Spannerにノード単位ではなく作業単位で課金するオンデマンド版がなければ、多くのユースケースでDynamoDBと比較するのは難しい
平均処理量はピークよりずっと低いので、Spannerでコスト削減が見込めるのかは疑わしい
ただし開発はDynamoDBよりSpannerのほうがはるかに簡単そうだ
Googleにはサービス料金を大幅に引き上げた前歴がある。ベンダーロックインは危険だ
他のサービスでもあったのかは気になる。AWSに大きく後れを取る2位または3位のビジネスクラウドサービスでは、その可能性はずっと低そうに見える
古い例ではあるが、料金を下げた事例も知っている: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
私の知る限り、AWSはたとえばサービス価格を下げることしかしていない
Droplet に Postgres DB を載せれば、ほぼ無料に近く、性能もかなり良い
月65ドルなら Hetzner で非常に強力なサーバーも手に入る。クラウド商品のメニューという狂った藪をかき分けて進まなければならないが、一度見て、むしろ Linux 管理の基礎を身につけて一生使い回したほうがいいと判断した
Postgres と Spanner を比較するのは、配送バンと列車を比較するようなものだ。列車には常に、より高い固定費がかかる
Linux 管理は有用なスキルだが、自分の Linux 管理能力が Dynamo、S3、Spanner のようなクラウドシステムの信頼性・可用性・拡張性に対抗できるわけではない
時間のあまりにも多くが、他では大して意味を持たない サービスごとの設定やトラブルシューティングに費やされる
1GB のストレージ、1KB の項目サイズ、書き込み10万回、読み取り10万回を1か月使うと、DynamoDB オンデマンドでは 0.39ドル。書き込みと読み取りをそれぞれ100万回に増やしても1.63ドル。強い整合性のある読み取りを使うと1.75ドル、トランザクション書き込みまで使うと3.00ドルになる