サーバーレスデータベースへの道 - その方法と理由

こんにちは、みんな！ 私の名前はゴロフ・ニコライです。 以前は、Avito で XNUMX 年間データ プラットフォームを管理していました。つまり、分析データベース (Vertica、ClickHouse)、ストリーミング、OLTP (Redis、Tarantool、VoltDB、MongoDB、PostgreSQL) のすべてのデータベースに取り組みました。 この間、私は非常に異なっていて珍しい、そしてその使用の非標準的なケースを含む多数のデータベースを扱いました。

私は現在ManyChatで働いています。 本質的に、これはスタートアップであり、新しく、野心的で、急速に成長しています。 そして、私が最初に会社に入社したとき、「若いスタートアップは今、DBMS およびデータベース市場から何を得るべきでしょうか?」という典型的な質問が生じました。

この記事では、私のレポートに基づいて、 オンラインフェスティバル RIT++2020, この疑問にお答えします。 レポートのビデオ版は以下から入手できます。 YouTube.

一般的に知られているデータベース 2020

2020 年になり、周りを見渡してみると XNUMX 種類のデータベースがありました。

最初のタイプ - クラシック OLTP データベース: PostgreSQL、SQL Server、Oracle、MySQL。 これらはずっと前に書かれたものですが、開発者コミュニティにはよく知られているため、今でも重要な意味を持っています。

XNUMX番目のタイプは 「ゼロ」からのベース。 彼らは、SQL、伝統的な構造、ACID を放棄し、組み込みのシャーディングやその他の魅力的な機能を追加することで、古典的なパターンから脱却しようとしました。 たとえば、これは Cassandra、MongoDB、Redis、Tarantool などです。 これらすべてのソリューションは、根本的に新しいものを市場に提供したいと考えていましたが、特定のタスクには非常に便利であることが判明したため、ニッチな分野を占めていました。 これらのデータベースを包括的な用語 NOSQL で表します。

「ゼロ」は終わり、私たちは NOSQL データベースに慣れ、私の観点からは世界は次の一歩を踏み出しました。 管理されたデータベース。 これらのデータベースには、従来の OLTP データベースまたは新しい NoSQL データベースと同じコアがあります。 ただし、DBA や DevOps は必要なく、クラウド内の管理されたハードウェア上で実行されます。 開発者にとって、これはどこかで動作する「単なるベース」ですが、それがサーバーにどのようにインストールされ、誰がサーバーを構成し、誰が更新するかなど誰も気にしません。

このようなデータベースの例:

• AWS RDS は、PostgreSQL/MySQL のマネージド ラッパーです。
• DynamoDB は、Redis や MongoDB に似たドキュメントベースのデータベースの AWS 類似品です。
• Amazon Redshift は、管理された分析データベースです。

これらは基本的に古いデータベースですが、ハードウェアを操作する必要がなく、管理された環境で作成されます。

注記。 これらの例は AWS 環境を対象にしていますが、類似したものは Microsoft Azure、Google Cloud、または Yandex.Cloud にも存在します。

これの何が新しいのでしょうか？ 2020年には、そのようなことはありません。

サーバーレスの概念

2020 年の市場で本当に新しいのは、サーバーレスまたはサーバーレス ソリューションです。

通常のサービスまたはバックエンド アプリケーションの例を使用して、これが何を意味するかを説明してみます。
通常のバックエンド アプリケーションをデプロイするには、サーバーを購入またはレンタルし、そのサーバーにコードをコピーし、エンドポイントを外部に公開し、定期的に家賃、電気代、およびデータ センター サービスを支払います。 これが標準的なスキームです。

他に方法はありますか? サーバーレス サービスを使用すると、それが可能になります。

このアプローチの焦点は何ですか。サーバーは存在せず、クラウドで仮想インスタンスをレンタルすることさえありません。 サービスをデプロイするには、コード (関数) をリポジトリにコピーし、エンドポイントに公開します。 次に、関数が実行されるハードウェアを完全に無視して、この関数の呼び出しごとに料金を支払うだけです。

このアプローチを写真で説明してみます。


クラシックな展開。 一定の負荷を伴うサービスを行っております。 物理サーバーまたは AWS のインスタンスの XNUMX つのインスタンスを作成します。 外部リクエストはこれらのインスタンスに送信され、そこで処理されます。

写真からわかるように、サーバーは均等に処分されていません。 100 つは 50% 使用されており、リクエストは 30 つあり、XNUMX つは XNUMX% のみ (部分的にアイドル状態) です。 リクエストが XNUMX 件ではなく XNUMX 件到着すると、システム全体が負荷に対応できなくなり、速度が低下し始めます。

サーバーレス展開。 サーバーレス環境では、このようなサービスにはインスタンスやサーバーがありません。 加熱されたリソースの特定のプールがあります。これは、関数コードがデプロイされた、準備された小さな Docker コンテナです。 システムは外部リクエストを受信し、それぞれのリクエストに対してサーバーレス フレームワークがコードを含む小さなコンテナを生成します。この特定のリクエストを処理してコンテナを強制終了します。

1000 つのリクエスト - 1000 つのコンテナが生成され、XNUMX リクエスト - XNUMX のコンテナ。 また、ハードウェア サーバーへの展開はすでにクラウド プロバイダーの作業になっています。 これはサーバーレス フレームワークによって完全に隠蔽されます。 このコンセプトでは、すべての通話に対して料金を支払います。 たとえば、XNUMX 日に XNUMX 件の電話があり、XNUMX 件の通話料を支払いましたが、XNUMX 分あたり XNUMX 万件の電話があり、XNUMX 万件の通話料を支払いました。 または、すぐにこれも起こります。

サーバーレス関数を公開するという概念は、ステートレス サービスに適しています。 また、(状態) ステートフル サービスが必要な場合は、サービスにデータベースを追加します。 この場合、状態の操作に関しては、各ステートフル関数は単にデータベースに書き込み、データベースから読み取りを行うだけです。 さらに、記事の冒頭で説明した XNUMX つのタイプのいずれかのデータベースから。

これらすべてのデータベースに共通する制限は何ですか? これらは、常時使用されるクラウドまたはハードウェア サーバー (または複数のサーバー) のコストです。 従来のデータベースを使用しているかマネージド データベースを使用しているか、Devops と管理者がいるかどうかは関係なく、ハードウェア、電気代、データセンターのレンタル料を 24 時間年中無休で支払います。 クラシックベースがある場合は、マスターとスレーブの料金を支払います。 高負荷のシャード データベースの場合は、7、10、または 20 台のサーバーに対して料金を支払い、継続的に支払います。

コスト構造における永久予約サーバーの存在は、以前は必要悪であると認識されていました。 従来のデータベースには、接続数の制限、スケーリングの制限、地理的に分散されたコンセンサスなど、他の問題もあります。特定のデータベースでは何らかの方法で解決できますが、すべてを一度に解決できるわけではなく、理想的ではありません。

サーバーレスデータベース - 理論

2020 年の質問: データベースをサーバーレスにすることも可能ですか? サーバーレス バックエンドについては誰もが聞いたことがあるでしょう...データベースをサーバーレスにしてみませんか?

データベースはステートフル サービスであり、サーバーレス インフラストラクチャにはあまり適していないため、これは奇妙に聞こえます。 同時に、データベースの状態は非常に大きくなり、ギガバイト、テラバイト、分析データベースではペタバイトに及ぶこともあります。 軽量の Docker コンテナーでこれを起動するのはそれほど簡単ではありません。

一方、ほとんどすべての最新のデータベースには、トランザクション、整合性調整、プロシージャ、リレーショナル依存関係、および多数のロジックなど、膨大な量のロジックとコンポーネントが含まれています。 かなり多くのデータベース ロジックの場合、小さな状態で十分です。 ギガバイトとテラバイトは、クエリの直接実行に関与するデータベース ロジックのごく一部によってのみ直接使用されます。

したがって、アイデアは次のとおりです。ロジックの一部でステートレス実行が許可されている場合、ベースをステートフル部分とステートレス部分に分割してはどうでしょうか。

OLAP ソリューションのサーバーレス

実際の例を使用して、データベースをステートフル部分とステートレス部分に分割するとどうなるかを見てみましょう。

たとえば、分析データベースがあります。: 外部データ (左側の赤い円柱)、データベースにデータをロードする ETL プロセス、およびデータベースに SQL クエリを送信するアナリスト。 これは古典的なデータ ウェアハウスの運用スキームです。

このスキームでは、ETL は条件付きで XNUMX 回実行されます。 次に、クエリを送信する先を確保するために、ETL で満たされたデータを含むデータベースが実行されるサーバーに対して常に料金を支払う必要があります。

AWS Athena Serverless に実装された代替アプローチを見てみましょう。 ダウンロードされたデータが保存される永続的な専用ハードウェアはありません。 これの代わりに：

• ユーザーは SQL クエリを Athena に送信します。 Athena オプティマイザーは SQL クエリを分析し、クエリの実行に必要な特定のデータをメタデータ ストア (メタデータ) で検索します。
• オプティマイザは、収集したデータに基づいて、必要なデータを外部ソースから一時ストレージ (一時データベース) にダウンロードします。
• ユーザーからの SQL クエリは一時ストレージで実行され、結果がユーザーに返されます。
• 一時ストレージがクリアされ、リソースが解放されます。

このアーキテクチャでは、リクエストを実行するプロセスに対してのみ料金が発生します。 リクエストはありません - 費用はかかりません。

これは実用的なアプローチであり、Athena Serverless だけでなく Redshift Spectrum (AWS 内) にも実装されています。

Athena の例は、サーバーレス データベースが数十、数百テラバイトのデータを含む実際のクエリで動作することを示しています。 数百テラバイトには数百台のサーバーが必要ですが、サーバーに対して料金を支払う必要はありません。リクエストに対して料金を支払います。 各リクエストの速度は、Vertica のような特殊な分析データベースと比較して (非常に) 低速ですが、ダウンタイム期間に対する料金は発生しません。

このようなデータベースは、まれな分析用のアドホック クエリに適用できます。 たとえば、膨大な量のデータに対して仮説をテストしようと自発的に決めるときです。 Athena はこのような場合に最適です。 定期的なリクエストの場合、このようなシステムは高価です。 この場合、何らかの特殊なソリューションでデータをキャッシュします。

OLTP ソリューションのサーバーレス

前の例では、OLAP (分析) タスクについて説明しました。 次に、OLTP タスクを見てみましょう。

スケーラブルな PostgreSQL または MySQL を想像してみましょう。 最小限のリソースで通常のマネージド インスタンス PostgreSQL または MySQL を起動しましょう。 インスタンスがさらに多くの負荷を受けると、追加のレプリカに接続し、読み取り負荷の一部を分散します。 リクエストがなく、負荷もない場合、レプリカはオフになります。 最初のインスタンスがマスターで、残りはレプリカです。

このアイデアは、Aurora Serverless AWS と呼ばれるデータベースに実装されています。 原理は単純です。外部アプリケーションからのリクエストはプロキシ フリートによって受け入れられます。 負荷の増加を確認して、事前にウォームアップされた最小限のインスタンスからコンピューティング リソースを割り当てます。接続は可能な限り迅速に行われます。 インスタンスの無効化も同様に行われます。

Aurora には、Aurora キャパシティ ユニット、ACU の概念があります。 これは (条件付きで) インスタンス (サーバー) です。 特定の各 ACU はマスターまたはスレーブになることができます。 各キャパシティ ユニットには、独自の RAM、プロセッサ、および最小限のディスクがあります。 したがって、XNUMX つはマスター、残りは読み取り専用レプリカです。

実行されているこれらの Aurora キャパシティ ユニットの数は、構成可能なパラメーターです。 最小数量は XNUMX または XNUMX です (この場合、リクエストがない場合データベースは機能しません)。

ベースがリクエストを受信すると、プロキシ フリートは Aurora CapacityUnits を増加させ、システムのパフォーマンス リソースを増加します。 リソースを増減できる機能により、システムはリソースを「ジャグリング」することができます。つまり、個々の ACU を自動的に表示し (新しい ACU と置き換えて)、取り消されたリソースに対して現在のすべての更新をロールアウトします。

Aurora Serverless ベースは読み取り負荷をスケーリングできます。 しかし、ドキュメントにはこれが直接述べられていません。 マルチマスターを持ち上げることができるように感じるかもしれません。 魔法はありません。

このデータベースは、アクセスが予測できないシステムに多額の費用を費やすことを避けるのに最適です。 たとえば、MVP を作成したり、名刺サイトをマーケティングしたりする場合、通常は安定した負荷は期待できません。 したがって、アクセスがない場合、インスタンスの料金は発生しません。 予期せぬ負荷が発生した場合 (たとえば、カンファレンスや広告キャンペーンの後、大勢の人がサイトにアクセスして負荷が大幅に増加した場合)、Aurora Serverless が自動的にこの負荷を引き受け、不足しているリソース (ACU) を迅速に接続します。 その後、カンファレンスが終了し、誰もがプロトタイプのことを忘れ、サーバー (ACU) が暗くなり、コストがゼロに下がります。これは便利です。

このソリューションは書き込み負荷を調整しないため、安定した高負荷には適していません。 これらすべてのリソースの接続と切断は、いわゆる「スケール ポイント」、つまりデータベースがトランザクションや一時テーブルによってサポートされていない時点で発生します。 たとえば、XNUMX 週間以内にスケール ポイントが発生しない可能性があり、ベースは同じリソースで動作し、単純に拡張または縮小できなくなります。

魔法はありません。通常の PostgreSQL です。 ただし、マシンの追加と切断のプロセスは部分的に自動化されています。

設計によるサーバーレス

Aurora Serverless は、サーバーレスの利点の一部を活用するためにクラウド用に書き直された古いデータベースです。 ここで、もともとクラウド用に書かれた、サーバーレス アプローチのベースであるサーバーレス バイ デザインについて説明します。 物理サーバー上で動作することを想定せずにすぐに開発されました。

このベースはスノーフレークと呼ばれます。 XNUMX つのキーブロックがあります。

XNUMX つ目はメタデータ ブロックです。 これは、セキュリティ、メタデータ、トランザクション、クエリの最適化の問題を解決する高速なインメモリ サービスです (左の図を参照)。

XNUMX 番目のブロックは、計算用の仮想コンピューティング クラスターのセットです (図では青い円のセットがあります)。

3 番目のブロックは、S3 に基づくデータ ストレージ システムです。 SXNUMX は AWS の無次元オブジェクト ストレージで、ビジネス向けの無次元 Dropbox のようなものです。

コールドスタートを想定して、Snowflake がどのように動作するかを見てみましょう。 つまり、データベースが存在し、データはそこにロードされますが、実行中のクエリはありません。 したがって、データベースへのリクエストがない場合は、高速なインメモリ メタデータ サービス (最初のブロック) が起動されます。 また、テーブル データが保存される S3 ストレージは、いわゆるマイクロパーティションに分割されています。 簡単にするために、テーブルにトランザクションが含まれている場合、マイクロパーティションはトランザクションの日になります。 毎日が個別のマイクロパーティション、個別のファイルです。 データベースがこのモードで動作する場合、料金はデータが占有するスペースに対してのみ発生します。 さらに、座席あたりの料金は非常に低くなります（特に大幅な圧縮を考慮すると）。 メタデータ サービスも常に動作しますが、クエリを最適化するために多くのリソースは必要なく、このサービスはシェアウェアと見なすことができます。

ここで、ユーザーがデータベースにアクセスして SQL クエリを送信したと想像してみましょう。 SQL クエリは、処理のために直ちにメタデータ サービスに送信されます。 したがって、リクエストを受信すると、このサービスはリクエスト、利用可能なデータ、ユーザー権限を分析し、すべてが問題なければ、リクエストを処理するための計画を作成します。

次に、サービスはコンピューティング クラスターの起動を開始します。 コンピューティング クラスターは、計算を実行するサーバーのクラスターです。 つまり、これは、1 台のサーバー、2 台のサーバー、4、8、16、32 台のサーバーを必要な数だけ含めることができるクラスターです。 リクエストをスローすると、このクラスターの起動がすぐに始まります。 本当に数秒かかります。

次に、クラスターが開始された後、リクエストの処理に必要なマイクロパーティションが S3 からクラスターへのコピーを開始します。 つまり、SQL クエリを実行するには、XNUMX つのテーブルから XNUMX つのパーティションが必要で、XNUMX 番目のテーブルから XNUMX つのパーティションが必要だと想像してください。 この場合、すべてのテーブル全体ではなく、必要な XNUMX つのパーティションのみがクラスターにコピーされます。 だからこそ、すべてが XNUMX つのデータ センター内にあり、非常に高速なチャネルで接続されているため、転送プロセス全体が非常に迅速に行われます。巨大なリクエストがない限り、数秒で、ごくまれに数分で完了します。 したがって、マイクロパーティションがコンピューティング クラスターにコピーされ、完了すると、SQL クエリがこのコンピューティング クラスター上で実行されます。 このリクエストの結果は XNUMX 行、複数行、または表になる可能性があります。これらはユーザーに外部に送信されるため、ユーザーはダウンロードしたり、BI ツールに表示したり、その他の方法で使用したりできます。

各 SQL クエリは、以前にロードされたデータから集計を読み取るだけでなく、データベースに新しいデータをロード/生成することもできます。 つまり、たとえば、新しいレコードを別のテーブルに挿入するクエリである可能性があり、これによりコンピューティング クラスター上に新しいパーティションが作成され、単一の S3 ストレージに自動的に保存されます。

ユーザーの到着からクラスターの立ち上げ、データのロード、クエリの実行、結果の取得までの上記のシナリオでは、立ち上げられた仮想コンピューティング クラスター、仮想ウェアハウスの使用時間に対する料金が支払われます。 料金は AWS ゾーンとクラスターのサイズによって異なりますが、平均して 16 時間あたり数ドルです。 32 台のマシンからなるクラスターは 5 台のマシンからなるクラスターの 10 倍の費用がかかりますが、XNUMX 台のマシンからなるクラスターは依然として XNUMX 倍の費用がかかります。 リクエストの複雑さに応じて、XNUMX 台または XNUMX 台のマシンのオプションが利用可能です。 ただし、料金が発生するのはクラスターが実際に実行されているときの分だけです。リクエストがないときは手を離し、XNUMX ～ XNUMX 分間待機すると (構成可能なパラメーター)、自動的に停止するためです。リソースを解放して自由になります。

完全に現実的なシナリオは、リクエストを送信すると、比較的 XNUMX 分以内にクラスターがポップアップし、さらに XNUMX 分カウントされ、その後シャットダウンに XNUMX 分かかり、最終的にこのクラスターの XNUMX 分間の操作料金を支払うことになるというものです。何ヶ月も何年も続くわけではありません。

最初のシナリオでは、シングルユーザー設定で Snowflake を使用して説明しました。 ここで、実際のシナリオに近い、多数のユーザーがいると想像してみましょう。

多数のアナリストと Tableau レポートが、データベースに多数の単純な分析 SQL クエリを絶えず攻撃しているとします。

さらに、データを使って途方もないことを実行し、数十テラバイトを操作し、数十億行、数兆行のデータを分析しようとしている創意に富んだデータ サイエンティストがいるとします。

上記の XNUMX 種類のワークロードについて、Snowflake を使用すると、容量の異なる複数の独立したコンピューティング クラスターを構築できます。 さらに、これらのコンピューティング クラスターは独立して動作しますが、共通の一貫したデータを使用します。

多数の軽いクエリの場合は、2 ～ 3 個の小さなクラスター (それぞれ約 2 台のマシン) を発生させることができます。 この動作は、特に自動設定を使用して実装できます。 そこであなたは、「スノーフレーク、小さな塊を育ててください。」と言います。 負荷が特定のパラメーターを超えて増加した場合は、同様の XNUMX 番目、XNUMX 番目のパラメーターを上げます。 負荷が軽減され始めたら、過剰な負荷を消してください。」 そのため、何人のアナリストが来てレポートを見始めても、誰もが十分なリソースを持っています。

同時に、アナリストが眠っていて誰もレポートを見ない場合、クラスターは完全に暗転し、料金の支払いを停止する可能性があります。

同時に、(データ サイエンティストからの) 重いクエリの場合は、32 台のマシンに対して XNUMX つの非常に大きなクラスターを構築できます。 このクラスターにも、巨大なリクエストがそこで実行されている分と時間に対してのみ料金が発生します。

上で説明した機会により、2 種類だけでなく、より多くの種類のワークロードをクラスター (ETL、モニタリング、レポートの実体化など) に分割することができます。

スノーフレークについてまとめてみましょう。 このベースには、美しいアイデアと実行可能な実装が組み合わされています。 ManyChat では、Snowflake を使用してすべてのデータを分析しています。 例のように 5 つのクラスターはありませんが、サイズの異なる 9 から 16 のクラスターがあります。 従来の2台、1台のほか、作業によっては超小型のXNUMX台もございます。 それらは負荷をうまく分散し、大幅な節約を可能にします。

データベースは読み取りおよび書き込みの負荷を適切にスケーリングします。 これは、読み取り負荷のみを担っていた同じ「Aurora」と比較すると大きな違いであり、大きな進歩です。 Snowflake を使用すると、これらのコンピューティング クラスターを使用して書き込みワークロードを拡張できます。 つまり、前述したように、ManyChat ではいくつかのクラスターを使用しており、小規模および超小規模クラスターは主にデータのロードのための ETL に使用されます。 また、アナリストはすでに中規模のクラスターに住んでおり、ETL 負荷の影響をまったく受けないため、非常に高速に作業します。

したがって、データベースは OLAP タスクに最適です。 ただし、残念ながら、OLTP ワークロードにはまだ適用できません。 まず、このデータベースは列形式であり、その後のすべての結果を伴います。 第 100 に、必要に応じてリクエストごとにコンピューティング クラスターを起動し、そこにデータを大量に送り込むというアプローチ自体が、残念ながら OLTP の負荷に対してまだ十分に高速ではありません。 OLAP タスクで数秒待機するのは正常ですが、OLTP タスクでは許容できません。10 ミリ秒、または XNUMX ミリ秒の方がさらに良いでしょう。

合計

サーバーレス データベースは、データベースをステートレス部分とステートフル部分に分割することで可能になります。 上記のすべての例で、比較的言えば、ステートフル部分は S3 にマイクロパーティションを保存し、ステートレス部分はオプティマイザーであり、メタデータを操作し、独立した軽量ステートレス サービスとして発生する可能性のあるセキュリティ問題を処理することに気づいたかもしれません。

SQL クエリの実行は、Snowflake コンピューティング クラスターのようなサーバーレス モードでポップアップし、必要なデータのみをダウンロードし、クエリを実行して「終了」できるライトステート サービスとして認識することもできます。

サーバーレスの実稼働レベルのデータベースはすでに使用可能であり、機能しています。 これらのサーバーレス データベースは、OLAP タスクを処理する準備がすでに整っています。 残念ながら、OLTP タスクでは制限があるため、微妙な違いを伴いながら使用されます。 一方で、これはマイナスです。 しかし、一方で、これはチャンスでもあります。 おそらく読者の中には、Aurora の制限なしに OLTP データベースを完全にサーバーレスにする方法を見つける人もいるでしょう。

面白いと思っていただければ幸いです。 サーバーレスは未来です 🙂

出所： habr.com