オーバープロビジョニングに別れを: Spanner で費用対効果の高い弾力性を実現する方法

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

データベースに関して、多くの企業はジレンマに直面しています。それは、サービスの品質、レイテンシ、スループットを維持しつつ、費用対効果の高い方法でスケーリングするにはどうすればよいかということです。

特にこれが難しいのは、企業のワークロードではトラフィック パターンが大きく変動することが多いためです。たとえば e コマースやリテール バンキングのアプリケーションのトラフィックは変動し、多くの場合、下図のように日中に利用がピークに達し、夜になると大幅に減少します。

このような変動性に対応するには、パフォーマンスを損なわずにピーク負荷を処理できるデータベース インフラストラクチャが必要です。ピーク負荷を処理するための従来のアプローチは、CPU、RAM、ディスク I/O、ストレージなどのリソースのオーバープロビジョニングです。

オーバープロビジョニングの欠点は、ピーク時以外はリソースのほとんどがアイドル状態のままになり、余計な費用が発生することです。ステートレスなアプリケーション階層とは対照的にデータベースは本質的にステートフルであるため、実際の使用率に沿って都度データベース リソースのサイズを適正化することは、通常は選択肢にはありません。さらに、コンピューティング リソースとストレージ リソースを緊密に結合させると通常はダウンタイムが発生し、可用性や少なくともサービスの品質に影響を与える可能性があります（レイテンシの悪化など）。そのため、データベース サービスは SLA を満たすために、リソースをかなり浪費することになるにもかかわらず、レイテンシとスループットの一貫性を優先する必要があります。

e コマースの例に戻ると、ほとんどのオンライン小売ウェブサイトでは、データベースのオーバープロビジョニングよりも、ユーザーの不満に起因するトラフィックの損失の方が収益に悪影響を及ぼすことがわかっています。それでも、予想されるピーク負荷によっては、平均のリソース使用率が 20% 前後になることも珍しくありません。つまり、割り当てられたリソースの 80% が無駄になっているということです。

オーバープロビジョニングに伴う無駄の削減に Spanner がどのように役立つか

従来のデータベース システムとは異なり、Spanner はコンピューティング リソースとストレージ リソースを切り離します。Spanner のオートスケーラーはこのコンピューティング リソースとストレージ リソースの分離を活用し、ダウンタイムをなくしてレイテンシへの影響を抑えながら、コンピューティング リソースを弾力的に調整します。ワークロード需要に合わせてコンピューティング容量を調整するこの種の動的スケーリングでは、余分な費用をかけずに最適なパフォーマンスを確保できます。

従来のデータベース システムでは、データベース トラフィックの処理に必要なコンピューティング リソースに加え、ストレージ リソースも慎重に考慮する必要があります。Spanner は、従量課金制のストレージ モデルで物事をシンプルにしています。ディスク ストレージと I/O に関して、事前にプロビジョニングしたり事前に支払ったりする必要がありません。さらに、Spanner では有効期間（TTL）機能により、「ホット」な OLTP データベース内で保持する必要のなくなったデータを削除できるため、ストレージの使用率、ひいては費用をビジネスニーズに忠実に追従させることができます。

つまり、Spanner はコンピューティング リソースとストレージ リソースを弾力的に拡大縮小することで、オーバープロビジョニングを不要にします。しかし、ベースラインより一桁多くなるなど、需要の突然な急増があった場合はどうなるのかと疑問に思うかもしれません。次のセクションでは、Spanner のスケールアウト アーキテクチャとプレウォーミングにより、需要の極端な急増に対するガードレールを導入する方法について説明します。

ピークイベントについて

再び小売業界に目を向けると、ピークイベントの身近な例としては、サイバー マンデーやブラック フライデーといった販売促進期間が挙げられます。そうした状況では、サービスの提供を犠牲にしたり、アイドル状態のリソースに過剰に支出したりすることなく、例外的なトラフィックの急増に対応するには、綿密な計画と調整が必要になります。

たとえ綿密な計画を立てても、ピークイベントでは、すでにオーバープロビジョニングされている容量では対応できないレベルで、需要の急増が起きる可能性があります。もちろん、ピークイベントのために年間を通じてリソースをオーバープロビジョニングすると、費用が非常に高くなります。そのため、予測可能なピークイベントに直面している組織は、事前に容量をデプロイするプロセスを導入しています。

従来のデータベース システムでは、このプロセスはどのようになるでしょうか。必要となる大まかな手順を下図に示します。

ピークイベントに至るまでの手順:

• ステップ 1: 予想されるイベントを計画し、調整します。ビジネスチーム（マーケティングなど）と緊密に連携し、正確な需要予測を行って、それに応じて IT チームが準備できるようにする必要があります。

• ステップ 2: サービスを一時的に停止します。部分的に運用できるようにするために、ガードレール（リードレプリカを有効にするなど）を導入することもあります。

• ステップ 3: CPU と RAM を追加でプロビジョニングします。このステップでは、予想される急増を処理するためにコンピューティング パワーとメモリを増やします。

ピーク後の手順:

• ステップ 4: サービスを再びオフラインにします。

• ステップ 5: 余分な CPU と RAM をデプロビジョニングし、日常業務の容量に戻します。

• ステップ 6: システムを再起動します。

もちろん、ダウンタイムを最小限に抑える方法はあります。組織によっては、ミラーリングしたデータベース インスタンスをプロビジョニングし、対象のピークイベントの前後でトラフィックをルート変更しているケースもあります。

しかし、ダウンタイムの有無にかかわらず、上記のアプローチは全体的に多大な労力を要し、追加の費用とリスクが生じます。

• 来ることのないピークを予測してリソースを大幅にオーバープロビジョニングすると、費用が高くつきます。

• 逆に、予測が不正確なせいでアンダープロビジョニングになり、パフォーマンスが低下して収益に影響を与えたり、顧客に不満を抱かせたりするおそれもあります。

• 想定の範囲を超える予想外の急増（クチコミによる急増など）が発生して、全面的なサービス停止につながることもあります。

Spanner のポリシー: 常時適切に対応

対照的に、Spanner では弾力的なコンピューティング モデルと自動スケーリングを組み合わせているため、サービスの健全性やユーザー エクスペリエンスを損なうことなく、トラフィックの大幅な急増を適切に対応できます。ほとんどの場合、Spanner インスタンスは大規模なリリースの調整や容量の計画を必要としません。また、たとえ必要な場合であっても、ユーザーは煩雑なアップグレード手順を実施せずに済みます。

Spanner には、データを自動的にシャーディングし、基盤となるリソースを適切にスケーリングして、サービスの品質が低下しないようにするメカニズムが組み込まれています。しかし、Spanner インスタンスがトラフィックの急増に遭遇することなく、かなりの期間にわたって定常状態にある場合には、パフォーマンスの低下を避けるためにウォームアップ手順が必要になることがあります。これは、トラフィックの大幅な急増が予想される新サービスのリリース イベントでは特にあてはまります。Spanner のプレウォーミングについて詳しくは、こちらの記事をご覧ください: Cloud Spanner のウォームアップ ツールとベンチマーク ツールでアプリケーションのリリースを簡単に

まとめ

コンピューティング リソースとストレージ リソースを分離し、自動スケーリングを利用することで、Spanner は変動するトラフィック パターンに動的に対応します。高需要のピークに応じてスケールアウトし、無駄を防ぐためにスケールバックすることで、費用を最適化しながら一貫したパフォーマンスを実現します。そのため Spanner は、予想外のトラフィックの急増や計画済みのイベントへの対応に適しています。企業はアイドル状態のリソースに過剰な支出をすることなく、信頼性の高いサービスを提供できるようになります。

Spanner の独自性や使用例について詳しくは、こちらをご覧ください。また、90 日間無料で、あるいは月額わずか 65 米ドルで、中断を伴う再構築やダウンタイムなしでビジネスの成長に合わせて拡張できる、本番環境対応のインスタンスをお試しください。

ー Spanner、シニア スタッフ ソリューション アーキテクト Szabolcs Rozsnyai

ー Spanner、シニア スタッフ ソリューション アーキテクト Karthi Thyagarajan