コンテンツに移動
データベース

データベースに実際にかかる費用(TCO)の評価と Cloud Spanner との比較

2023年5月12日
Google Cloud Japan Team

※この投稿は米国時間 2023 年 5 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

組織の技術スタックのモダナイズや、新しい革新的なアプリケーションの開発を検討するときは、どのデータベースを選ぶかが重要となります。

この判断には、費用、セキュリティ、スケーリング特性、セルフマネージドまたはフルマネージド、オンプレミスまたはパブリック クラウドなど、多数の要素が関係してきます。

企業がデータベースを選ぶときは、費用が重要な検討事項となります。それでは、特定のデータベースを使用した場合の「実際の費用」はどのように確認できるのでしょうか。

このブログ投稿では、データベース テクノロジーの総所有コスト(TCO)を評価する簡単なフレームワークを紹介します。データベースを選ぶ際にお役に立つはずです。

5 種類の費用

データベースの管理に関連する費用は、おおまかに 5 つのカテゴリに分けることができます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/spanner-tco-1-costs.max-1700x1700.jpg

ここでは例として、組織がデータベース クラスタを自社管理する場合を考えます。データベース クラスタは、複数のノードを持つ設定と定義します(たとえば、セルフマネージドのシャーディングされた MySQL クラスタ)。ほとんどのシナリオは、パブリック クラウドにあるセルフマネージド データベースにも当てはまります。

1. ハードウェアとライセンスの費用

  • オンプレミスのデータベースの場合、サーバーやストレージ ディスクなど、ハードウェアへの初期投資が必要となります。これ以外に、ハードウェアの計画、購入、導入に関連する間接費もあります。

  • さらに、データベース ソフトウェアのインストール、構成、調整に必要なサービスなどの初期費用もこれに加わります。

  • データベースのクラスタ化やシャーディングを行う場合、特にハードウェア部分とソフトウェア部分が異なるベンダーのものであると、このプロセスはさらに複雑になります。

  • セルフマネージド データベースをパブリック クラウドに置く場合、ピーク時のワークロード需要に応じたサーバーマシンやストレージ ディスクのプロビジョニングも必要となります。このため、データベースの負荷が低い場合でも費用が高くなります。

  • データベース テクノロジーによっては、ライセンス料の支払いが発生します(Microsoft SQL Server のライセンス料など)。

2. 運用費と効率

  • データベースの運用とメンテナンス: データベースの運用に必要な時間とリソースは少なくありません。オペレーティング システムとデータベースのバージョン アップグレード、アップグレード前のテスト、継続的な調整と最適化、セキュリティ パッチの計画と実行が必要です。

    データベースの規模と可用性の SLO によっては、費用がかなり大きくなる可能性があります。たとえば、スケーリングとシャーディングを行う MySQL データベースを自社で管理する場合、運用とメンテナンスに膨大なリソース(費用と人材の両方)が必要となる可能性があります。

  • スケールアップとスケールアウト: データベースを自社で管理されている場合、ブラック フライデー、大晦日、スーパーボウル、新製品の発売などの特別イベントにどのように備えていますか。ハードウェアをオーバープロビジョニングした場合、それはピーク時以外は不必要な費用となります。また、ハードウェアのオーバープロビジョニングはライセンスのオーバープロビジョニングを意味します。プロビジョニングが少なすぎた場合は、ビジネス チャンスを逃すリスクがあります。自社製品が一夜にして成功を収めた場合(モバイルゲームの発売など)、データベースが需要に対応できるか心配することになります。データベースがスケールアップの上限(マシンサイズなど)に達すると、シャーディングを使用してスケールアウトする必要が生じます。この場合、再設計、アプリの変更、運用費、ダウンタイムなどの追加費用が発生します。再設計が必要でなかったとしても、非線形のスケーリングは懸念事項のままです。

  • データの復元性: サーバーやネットワークの障害、熱波やハリケーンなどの自然災害が発生した場合にデータ損失を防ぎ、ビジネス継続性を確保するには、物理的に離れたロケーションやリージョンのデータセンターにわたりデータ レプリケーションを設定することで、データ復元性の計画を立てる必要があります。この設定には、多額の費用(ハードウェア、ソフトウェアのライセンス料、レプリケーション ソフトウェアのライセンス料など)や、継続的メンテナンスの負担が伴います。

  • 地理的展開: ビジネスを異なる地域に展開するとき、データ所在地の要件や、クライアントやアプリケーションのデータベース操作のレイテンシ削減のために、データベースのレプリケーションが必要となる場合があります。この場合、レプリケーションの設定、レプリカ間のデータ同期、スプリット ブレイン問題の防止、障害時のレプリカ復元の処理が、膨大な運用費を発生させます。

  • 効率: 一部の SaaS アプリケーション プロバイダ(クラウドの利用側でもある)は、顧客ごとに 1 つのデータベースをプロビジョニングします。多数の顧客を管理することは、多数の個別データベースを管理することを意味します。これが非効率性を招き、運用費の増加につながります。

3. 人件費

データベースのメンテナンス作業や管理の複雑さが増すと、データベース維持のために、より多くのエキスパートが必要となります。場合によっては、こうした費用がインフラストラクチャ全体(ハードウェア)の費用をはるかに上回ることもあります。

4. サービス停止の費用

  • 直接的な減収: これは明らかです。ビジネスが正常に稼働していなければ、直接的な減収の原因となります。部分的なデータベースの停止でも減収につながる場合があります。

  • 運用の手間: データベース関連の障害が発生した場合、組織にどの程度の手間がかかりますか。待機、対処、緩和、インシデントの事後検証の実施、防止策の導入には、どの程度のリソース数が必要ですか。

  • 契約: ビジネス クリティカルなワークロードによっては、システム停止やアプリケーション ダウンタイムに、契約上や規制上の影響がある場合があります(株式市場、銀行など)。

  • ブランドの信用問題: データベースのメンテナンス時間枠やデータベースの停止(低可用性)が原因でビジネスが停止した場合、信頼性や可用性が低いブランドとみなされるリスクを負うことになります。

  • 機会損失: 社内のリソースを、コアビジネスをサポートする拡張機能や新機能の開発に生かさずに、データベースや関連インフラストラクチャの管理のみに投入していませんか。  

5. 生産性の費用

  • 本番環境への移行期間: 本番環境への移行期間を最適化するために適切な CI / CD パイプラインはありますか。本番環境への移行プロセスの一環として、それぞれ異なるデータベース インスタンスを使用する複数の開発環境、本番前環境、ステージング環境を設定する必要がありますか。複数の環境を維持する時間と費用、変更を本番環境に適用するための最適化されていない(データベースに依存する)時間はどの程度ですか。スキーマ変更を適用する際の計画と準備にどの程度の労力が必要ですか。

  • 低いパフォーマンス: アプリケーションのパフォーマンスが最高になるようにデータベースを最適化していますか。データベースが適切に調整されていなかった場合、アプリケーションのパフォーマンスが低くなり、リソースが無駄になります。

  • アプリケーション開発のスピード: 組織で使用しているデータベースでは、アプリケーションを短期間で開発し、リリースすることが可能ですか。迅速な開発のために開発者のマシン(またはノートパソコン)にダウンロードできる、データベースのローカルコピーはありますか。データベースはわかりやすいインターフェースを備えていて、効率的な開発作業が可能ですか。

  • 複雑化: 複雑なデータベースのデプロイ作業のために、開発者の多大な労力が必要になっていませんか。優秀な開発者を、コアビジネスの差別化よりも、データベースのスケーリングや信頼性に関する課題の解決に割り振る必要が生じていませんか。

ビジネス上のメリットの判断

アプリケーションを開発するときに、使用しているデータベースがイテレーションを促進し、変更内容を本番環境に迅速に展開できるものかを考えてみましょう。本番環境へのコードのデプロイにかかる時間によって、新しいアプリケーション / 機能のリリースやイノベーションの実現にかかる時間が変わってきます。

企業が MySQL クラスタを自社で運用する例について考えてきましたが、上述のリストは他にも多くの状況に当てはまります。データベースを選択するときは、総所有コスト(TCO)に目を向けることが重要です。上述のポイントを確認するために、Google Cloud のマネージド データベース サービスの一つである Cloud Spanner とその TCO を見ていきましょう。

Cloud Spanner の概要

Cloud Spanner はクラウド専用として構築されたリレーショナル データベース サービスであり、分散型、グローバルにスケーラブル、強整合性といった特徴があります。リレーショナル データベースの構造により SQL のメリットをもたらすだけでなく、通常は非リレーショナル データベースが持つ水平方向のスケーラビリティも備えているため、ユーザーは両者のメリットを享受できます。この組み合わせは、行、データセンター、リージョン、大陸の間で高パフォーマンスのトランザクションと強整合性を実現するよう設計されています。最大 99.999% の可用性が SLA で保証され、エンタープライズ グレードのセキュリティが確保されています。データベース インフラストラクチャ、シャーディング、レプリケーション、フェイルオーバーは完全に Spanner により管理され、計画的ダウンタイムは生じないため、ユーザーはアプリケーションの開発やイノベーションの実現に専念できます。

Spanner の TCO

Cloud Spanner の経済効果に関する Enterprise Strategy Group の調査では、データを Cloud Spanner でホストした場合の費用は、オンプレミス サーバーを使用した場合と比較して 78% 低く、他のクラウド データベースを使用した場合と比較して 37% 低いと結論づけています。
https://storage.googleapis.com/gweb-cloudblog-publish/images/spanner-tco-2-savings.max-1700x1700.jpg

金融サービス、医療、小売、ゲーム、通信、テクノロジーなど、さまざまな業種のお客様が、Cloud Spanner に移行することでデータベースの TCO を削減しています。たとえば ShareChat は、17 のインデックスを含む 120 のテーブルを AWS DynamoDB から Spanner に移動して、非リレーショナル ワークロードの費用を 30% 削減しました。また、別のお客様である Kochava は、数百個の MySQL データベースで実行されていたリレーショナル ワークロードを少数の自動スケーリングされる Spanner インスタンスに統合することで費用の大幅削減を達成しています。

Cloud Spanner データベースの総コスト

Cloud Spanner を使って運用した場合の一般的なデータベース費用を見ていきましょう。

ハードウェアとライセンス
Spanner を使用した場合、ハードウェアのオーバープロビジョニングや高額のライセンス料の支払いが不要になります。データベースのコンピューティング容量とストレージ容量は従量課金制です。Spanner のオートスケーラーを使用すれば、データベースのコンピューティング容量のスケールアップやスケールダウンを柔軟に行い、費用を大幅に削減できます。

運用費と人件費
Spanner は、Google Cloud が提供するフルマネージドのクラウド データベース サービスであるため、管理にかかる時間を短縮し、アプリケーションの開発や顧客への付加価値提供のために、より多くの時間を割けるようになります。バックアップの作成や復元は非常に簡単で、パッチやアップグレードは不要です。スキーマの変更はダウンタイムなしで展開できるうえ、セキュリティも組み込まれています。

効率
Spanner では、複数のセルフマネージド データベースを 1 つのインスタンスに統合し、効率的に管理できます。

ノードの費用
Spanner は 90 日間の無料トライアルが可能です。また、正確性テストや開発向けのダウンロード可能なエミュレータも完全に無料で利用できます。最初は毎月 $65 で始め、その後は確約利用割引を購入することで費用をさらに最大 40% 削減できます。

スケーリング
最初は処理ユニット 100 個(最小サイズ)で始め、ノード数無制限まで増加できます。Spanner は、アプリケーションの成長に合わせてダウンタイムなしでオンデマンドでスケールできるため、事前に容量を予約するためにオーバープロビジョニングを行う必要はありません。

お客様からは、Cloud Spanner によってビジネスのアジリティを高め、データを有効に活用して既存顧客へのサービスを改善し、新たな収益源を開拓できたと報告を受けています。Spanner では、データベースを 1 つのリージョンに置くか、世界各地の複数のリージョンに置くかを柔軟に選ぶことができ、ステイル読み取りや強整合性読み取りを行うこともできます。

セキュリティ
Spanner は、クライアント ライブラリを介した転送中データの暗号化と、Google が管理する暗号鍵を使用した保存データの暗号化をデフォルトで提供しています。Spanner 向け CMEK サポートにより、暗号鍵は完全な管理が可能です。CMEK でデータベースのバックアップを保護することもできます。Spanner は VPC Service Controls サポートを提供し、コンプライアンス認定と必要な承認を受けているため、ISO 27001、ISO 27017、ISO 27018、PCI DSS、SOC 1、SOC 2、SOC 3、HIPAA、FedRAMP を遵守する必要があるワークロードに使用できます。

可用性
Spanner のマルチリージョン構成では、SLA で 99.999% の可用性が保証され、メンテナンスの時間枠や計画的ダウンタイムは生じません。ゾーン障害やリージョン障害が発生した場合、復旧は RPO が 0(データ損失なし)で自動的に行われ(介入は不要)、ビジネス継続性も損なわれません。

レプリケーション
データはすべて Spanner 内のすべてのレプリカに自動的に複製され、ノードの費用に含まれます。

整合性
Spanner はグローバルで外部整合性を保証します。従来の RDBMS 環境では、トランザクションや結果整合性を処理するアプリケーション ロジックを開発者が構築していました。Spanner では強整合性、スケーリング、トランザクションを含むリレーショナル セマンティクスが提供されているため、開発者はわかりやすいコードを容易に記述できます。

少ない TCO でアプリケーションを変革

まとめると、組織は複雑なデータベース管理システムを使用して、ビジネス運営に欠かせないデータやインサイトへのアクセスを確保しています。しかし、こうしたデータベースの維持管理は、総所有コスト(TCO)の観点から見たときに問題となる場合があります。金融サービス、小売、ゲーム、医療など、さまざまな業種のお客様が、少ない TCO でアプリケーションをモダナイズし、変革するために、Cloud Spanner データベースを選択しています。ぜひ無料トライアル インスタンスで Cloud Spanner をお試しください。


- エンジニアリング ディレクター Pritam Shah
Google Cloud、プロダクト マネージャー Shambhu Hegde
投稿先