YugabyteDB 2.17:ミッションクリティカルなアプリケーションをより早く安全に
本記事は、The Distributed SQL Blog にて2022年12月13日に公開された “YugabyteDB 2.17: Faster, Better Protection for Your Business-Critical Apps” を翻訳および一部訳注を追加しております。最新情報は英語版の記事を参照してください。
データ保護は、ビジネスの継続性を確保するために極めて重要です。もし組織がデータ、あるいはその重要な部分を失った場合、その結果は壊滅的なものになります。
データ保護の中核となるのは、データベースのバックアップ、つまりクラスタの外部に保存されたデータの定期的なコピーです。ハードウェアやソフトウェアの障害により、データの一部または全部が失われた場合、最新のバックアップを取得してデータを復元することができます。
企業によってデータ保護の要件は異なりますが、通常は2つの主要な目標として表現されます。
- 復旧時点目標（RPO）とは、災害発生前にデータを復旧させなければならない最も早い時点を指します。言い換えれば、RPOは許容可能なデータ損失の量を示しています。
- 復旧時間目標（RTO）とは、許容できる最大のダウンタイム（システムを作業可能な状態に復元するために必要な最大時間）のことです。
Yugabyteでは、さまざまな組織の目的をサポートするために、バックアップとリストア機能の改善に継続的に取り組んでいます。YugabyteDB 2.17には、”Backup 2.0 “と呼ぶメジャーアップデートが含まれています。
このブログでは、これらの新しいアップデートを詳しく説明し、RPOとRTOを下げるためにこの追加された柔軟性をどのように使用できるかを紹介します。
バックアップ・パフォーマンスの重要性
2.17の新機能に入る前に、YugabyteDBでバックアップがどのように実装されているか、そしてバックアップの作成とバックアップからの復元にかかる時間が、RPOとRTOにどのように関係しているかを確認しましょう。
YugabyteDBのバックアップは、2つのステップで作成されます。
- 分散クラスタ内スナップショットを作成します。これは、すべてのノードとタブレットにまたがるデータの一貫したカットです。
- スナップショットに属するすべてのデータ・ファイルを見つけ、クラウド・オブジェクトストア（AWS S3、GCS、Azure Blob）またはNFSなどのリモート・ロケーションに転送します。
最初のステップはYugabyteDBノード上でローカルに実行され、ほとんどが不変のSSTファイルへのハードリンクの作成で構成されています。物理的なデータ・コピーやその他の操作は必要ないため、スナップショットの作成は非常に高速に行われます。通常、数秒以内に完了します。
YugabyteDB Anywhereで実装されている2番目のステップは、かなり異なります。これは、ネットワーク経由でデータを転送し、転送先で保存するものです。データベースが大きくなればなるほど、より多くのデータを転送する必要があります。したがって、リモート・バックアップの作成にかかる時間は長くなります。
バックアップの作成にかかる時間は、RPOに直接影響するため、非常に重要です。この時間を短縮することで、より頻繁にバックアップを作成することができます。バックアップの頻度が高まれば、RPOも低下します。
復元にかかる時間も、RTOの観点から同様に重要です。データ損失が発生した場合、リモートロケーションからクラスタにデータを転送して、最新のバックアップからリストアすることになります。もちろん、これには時間がかかります。多くの場合、この時間がダウンタイムの最大の要因となるため、この時間を短縮することでRTOを改善できる可能性が高まります。
新しいバックアップ・リストアアーキテクチャ
YugabyteDB 2.17以前は、YugabyteDB Anywhereインスタンスがバックアップとリストアプロセスの管理を完全に担っていました。簡単に言うと、それは複数の並列スレッドにまたがり、各スレッドを使用してSSH経由でタブレットの1つに接続します。また、そのタブレットに属するファイルの転送を調整します。
YugabyteDB Anywhere側で作成できるスレッドの数には制限があります。そのため、特に大規模クラスタや大規模データベースを扱う場合、場合によってはボトルネックになる可能性があります。
このボトルネックを軽減するために、YugabyteDB AnywhereはYugabyteDB 2.17とともに、新しいバックアップ・アーキテクチャを導入しています。ここでは、各ノードがバックアップターゲットに直接データを並列送信することで、バックアップの作成と復元の両方でより優れたレベルの並列処理を実現します。YugabyteDB Anywhereは、このプロセスを集中的に管理する代わりに、これらの機能をYB-Controller（YBC）と呼ばれる特別な内部コンポーネントに委譲しています。これは、クラスタの各ノードのすぐそばで動作するスタンドアロン・プロセスです。
YugabyteDB Anywhereを使用して新しいバックアップを作成したり、既存のバックアップから復元したりする場合、YBCインスタンスの1つに対応するRPCコマンドが送信されます。そしてスナップショットが作成された後、このコマンドが他のインスタンスに転送されます。この時点から、各インスタンスは接続されているノードからのデータコピー、またはノードへのデータコピーに全責任を持つことになります。
最もコストのかかるデータ転送プロセスにおいて、YB-Controllerのインスタンスは他のノードから完全に独立し、単一のローカルノードとのみ通信を行います。さらに、YB-Controllerの数は常にノード数と同じで、クラスタとともにスケールすることを意味します。この分散化により、プロセス全体が非常に効率的になり、より多くのデータをより短時間で転送することができ、CPUやメモリリソースの消費量も少ないか同等になります。
この新しいスケーラブルなアーキテクチャにより、以前のYugabyteDBバージョンと比較して、バックアップとリストアの時間が最大で5倍改善されました。以下は、9ノードのYugabyteDBクラスターに配置された600GBのデータセットに関するテスト結果です。
これらの新機能は、YugabyteDB 2.17にアップグレードした後に作成された新しいクラスタにてデフォルトで有効になります。追加の構成は必要ありません。注：内部的には、YugabyteDB Anywhereはまだ新旧両方の実装をサポートしており、古いバージョンで作成されたバックアップからリストアすることができます。このようなバックアップから復元しようとした場合、システムは自動的に古いメカニズムにフォールバックします。
インクリメンタルバックアップの新機能
YugabyteDB 2.17で導入されたもう1つの大きな機能は、インクリメンタルバックアップです。
インクリメンタルバックアップは、最後のバックアップ（別のインクリメンタルバックアップまたはフルバックアップ）からの差分を表します。この機能により、バックアップを作成するたびにすべてのデータを転送する必要はありません。その代わり、例えば、週に1回フルバックアップを作成し、その後毎日増分バックアップを作成するようなスケジュールを設定することができます。
増分バックアップは、前回のバックアップ以降に変更されたデータのみを保持します。一般に、フルバックアップよりもサイズがはるかに小さくなります（これは特に大きなデータセットに当てはまります）。したがって、増分バックアップを使用することで、バックアップスケジュールを繰り返すたびにネットワーク経由で送信されるデータ量を大幅に減らすことができます。これには主に2つの利点があります。
- より頻繁なバックアップが可能：バックアップの平均サイズを小さくすることで、バックアップの作成にかかる時間も短縮されます。先に述べたように、パフォーマンスが向上すれば、バックアップをより頻繁に作成できるようになり、RPOが低下します。
- バックアップのコスト削減：バックアップのサイズが小さいと、バックアップ・ストレージのディスク容量が少なくて済みますし、そのストレージにバックアップを転送するためのネットワーク・リソースも少なくて済みます。どちらも、データバックアップの維持に必要な金額に大きく影響する要因です。インクリメンタルバックアップは、コスト削減のための素晴らしい方法です。
インクリメンタルバックアップの仕組み
YugabyteDB 2.17は、ファイルレベルのアプローチで増分バックアップを行います。これは、最新のバックアップと新しいバックアップのために作成されたスナップショットのファイルのリストを比較することによってバックアップ間の差分を計算し、これらのファイルの論理的なコンテンツの詳細のチェックは行いません。
このアプローチは、YugabyteDBがLSMストレージをベースにしているため可能です。これはすべてのデータを不変のSSTファイルに保存するため、データが更新されている間、新しいSSTファイルを作成することができますが、既存のファイルは決して変更されません。
アルゴリズムを示すために、簡単な例を見てみましょう。まず、4つのSSTファイルからなるデータベースから始めます。
000010.sst
000011.sst
000012.sst
000013.sstまず、フルバックアップを作成します。そのためには、4つのファイルすべてを指定された場所（s3://backups/my-db/fullとします）にコピーするだけです。また、バックアップに含まれるすべてのファイルとその正確な場所を一覧表示する特別なマニフェスト・ファイルを作成します。したがって、フルバックアップのマニフェストには、次の情報が含まれます。
000010.sst => s3://backups/my-db/full
000011.sst => s3://backups/my-db/full
000012.sst => s3://backups/my-db/full
000013.sst => s3://backups/my-db/fullここで、さらに1つのファイル（000014.sst）が作成されたとします。これで5つのファイルになりました。
増分バックアップを作成するには、次の手順を踏みます。
- 最新のバックアップ（この場合はフル バックアップ）のマニフェストを検索し、最新のファイル リストと比較し、新しく追加されたファイルを特定します。この例では、000014.sst という 1 つのファイルが新たに追加されたリストが作成されます。
- 新しいバックアップの場所を特定します (例: s3://backups/my-db/incremental-1)．
- 新しいファイルのみをその場所にコピーします。
- すべてのファイルとその場所をリストした、新しいバックアップ用のマニフェストを作成します。
インクリメンタル バックアップのマニフェストは次のようになります。
000010.sst => s3://backups/my-db/full
000011.sst => s3://backups/my-db/full
000012.sst => s3://backups/my-db/full
000013.sst => s3://backups/my-db/full
000014.sst => s3://backups/my-db/incremental-1注: 古いファイルでもフル バックアップの場所を指すので、システムは常にその場所を知っています。増分バックアップからの復元を決定した場合、そのバックアップのマニフェストを参照し、マニフェストに記載されているように、異なる場所からすべての必要なファイルを収集します。
すべての増分バックアップに対して、上記のプロセスを繰り返します。したがって、たとえば、データベース内にさらに 2 つのファイルが作成された場合、最新の増分バックアップを作成するためにこれら 2 つのファイルのみが転送され、マニフェストは次のようになります。
000010.sst => s3://backups/my-db/full
000011.sst => s3://backups/my-db/full
000012.sst => s3://backups/my-db/full
000013.sst => s3://backups/my-db/full
000014.sst => s3://backups/my-db/incremental-1
000015.sst => s3://backups/my-db/incremental-2
000016.sst => s3://backups/my-db/incremental-2この場合も、マニフェストには、このバックアップからの復元に必要なすべてのファイルと、それらのファイルの場所が一覧表示され、システムがそれらを見つけることができるようになっています。
ファイルレベルのアプローチの利点は、他の実装と異なり、リストア時間がバックアップ チェーン内の増分バックアップの数に依存しないことです。フルバックアップの頻度を増やさずに増分バックアップの頻度を増やせば、RTOは以前と同じ値になります。これにより、データ保護に対する要求の変化に、より容易に対応できるようになります。
まとめ
大規模かつグローバルに増え続けるデータに対して、DBAは設定された時間枠の中で増大するバックアップに対応するという課題を軽減する必要があります。
このようなニーズに対応するため、YugabyteDB 2.17ではバックアップおよびリストア機構を再構築し、最大5倍のスループットで高速化しました。また、増分バックアップを追加し、最大で20倍の頻度でバックアップを作成できるようになりました。
これらの新機能により、YugabyteDB 2.17はデータベースの近代化に対する重要な問題を取り除くことができます。YugabyteDB 2.17は、レガシーおよび多くの最新データベースにない多くの新しい利点を提供し、開発者の生産性を中核に据えることで、組織を強力に支援します
YugabyteDB 2.17を今すぐ無料でダウンロードし、ご自身でお確かめください。
注： YugabyteDBリリースのバージョン管理基準に従い、YugabyteDB 2.17はプレビュー・リリースです。含まれる新機能は活発に開発中であり、開発およびテスト・プロジェクトに利用可能です。
