サーバーレスデータベースに向けて-方法と理由

こんにちは！私の名前はニコライ・ゴロフです。以前はAvitoで働いていて、6年間データプラットフォームを担当していました。つまり、分析（Vertica、ClickHouse）、ストリーミング、OLTP（Redis、Tarantool、VoltDB、MongoDB、PostgreSQL）のすべてのデータベースに携わっていました。この間、私は多数のデータベースを扱ってきました-非常に異なっていて珍しいものであり、それらの使用の非標準的なケースを扱ってきました。



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



この記事では、RIT ++ 2020オンラインフェスティバルでの私の講演に基づいて、この質問に答えます。レポートのビデオバージョンはYouTubeで入手できます。

2020年の有名なデータベース

2020年ですが、周りを見回して3種類のデータベースを見ました。



最初のタイプは、従来のOLTPデータベース（PostgreSQL、SQL Server、Oracle、MySQL）です。それらはずっと前に書かれましたが、開発者コミュニティに精通しているため、依然として関連性があります。



2番目のタイプ- 「ゼロ」からのベース。彼らは、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のインスタンスの2つのインスタンスを発生させます。外部リクエストはこれらのインスタンスに送信され、そこで処理されます。



写真でわかるように、サーバーの使用方法は異なります。 1つは100％使用され、2つの要求があり、もう1つは部分的にアイドル状態の50％のみです。 3つではなく30の要求が来ると、システム全体が負荷に対応できなくなり、速度が低下し始めます。







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



1つのリクエスト-1つの持ち上げられたコンテナ、1000のリクエスト-1000のコンテナ。そして、鉄のサーバーへの展開はすでにクラウドプロバイダーの仕事です。サーバーレスフレームワークによって完全に隠されています。このコンセプトでは、通話ごとに料金を支払います。たとえば、1日に1回の呼び出しがあり、1回の呼び出しに対して支払い、1分間に100万回の呼び出しがあり、100万回の支払いがありました。またはすぐに、これも起こります。



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



これらすべての拠点に共通する制限は何ですか？これらは、常に使用されるクラウドサーバーまたはアイアンサーバー（または複数のサーバー）のコストです。従来のデータベースを使用するか管理対象にするかは関係ありません。Devopsと管理者がいるかどうかに関係なく、ハードウェア、電力、データセンターの賃貸料は24時間年中無休で支払われます。古典的な基盤がある場合は、マスターとスレーブの料金を支払います。負荷の高いシャードベースの場合、10、20、または30台のサーバーに料金を支払い、常に料金を支払います。



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

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

2020年の質問：データベースもサーバーレスにすることができますか？誰もがサーバーレスバックエンドについて聞いたことがある...しかし、データベースもサーバーレスにしようとしましょう。



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



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



したがって、ロジックの一部でステートレス実行が許可されている場合は、ベースをステートフル部分とステートレス部分に分割してみませんか。

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

ステートフル部分とステートレス部分に分割されたデータベースが実際の例でどのように見えるかを見てみましょう。







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



このスキームでは、慣例により、ETLは1回実行されます。次に、ETLで溢れたデータでデータベースを実行しているサーバーに常に料金を支払う必要があります。これにより、リクエストをスローすることができます。



AWS AthenaServerlessに実装されている代替アプローチを検討してください。ダウンロードしたデータが保存される恒久的な専用ハードウェアはありません。これの代わりに：

• SQL- Athena. Athena SQL- (Metadata) , .
• , , ( ).
• SQL- , .
• , .

このアーキテクチャでは、リクエストの実行プロセスに対してのみ料金を支払います。リクエストなし-費用なし。







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



Athenaの例は、サーバーレスデータベースが数十から数百テラバイトのデータを使用する実際のクエリで機能することを示しています。数百テラバイトには数百のサーバーが必要ですが、それらの料金を支払う必要はありません。リクエストの料金を支払います。各リクエストの速度は、Verticaのような特殊な分析データベースと比較して（非常に）遅いですが、ダウンタイムの支払いはありません。



このようなデータベースは、まれなアドホック分析クエリに役立ちます。たとえば、膨大な量のデータについて仮説をテストすることを自発的に決定した場合です。アテナはこれらの場合に最適です。定期的な問い合わせの場合、このようなシステムは高価です。この場合、特別なソリューションでデータをキャッシュします。

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

前の例では、OLAPタスク（分析）が考慮されました。それでは、OLTPタスクを見てみましょう。



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



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



Auroraには、Aurora Capacity Unit、ACUの概念があります。これは（条件付きで）インスタンス（サーバー）です。特定の各ACUは、マスターまたはスレーブにすることができます。各容量ユニットには、独自のRAM、プロセッサ、および最小ディスクがあります。したがって、1つのマスター、残りは読み取り専用レプリカです。



動作中のこれらのAuroraキャパシティユニットの数は構成可能です。最小量は1または0にすることができます（この場合、要求がない場合、ベースは機能しません）。







ベースがリクエストを受信すると、プロキシフリートはAurora CapacityUnitsを上げ、システムの生産リソースを増やします。リソースを増減する機能により、システムはリソースを「ジャグリング」できます。つまり、個々のACUを自動的に表示し（新しいACUに置き換え）、削除されたリソースの関連するすべての更新をロールアップします。



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



このベースは、アクセスが予測できないシステムに多額の費用をかけないようにするのに適しています。たとえば、MVPまたは名刺マーケティングサイトを構築する場合、通常、安定した負荷は期待できません。したがって、アクセスがない場合、インスタンスの料金は発生しません。会議や広告キャンペーンの後など、予期しない負荷が発生した場合、大勢の人がサイトにアクセスし、負荷が劇的に増加すると、Aurora Serverlessがこの負荷を自動的に引き継ぎ、不足しているリソース（ACU）をすばやく接続します。その後、会議が続き、誰もがプロトタイプを忘れ、サーバー（ACU）が停止し、コストがゼロになります。これは便利です。



このソリューションは、書き込み負荷をスケーリングできないため、安定した高負荷には適していません。これらすべてのリソースの接続と切断は、いわゆる「スケールポイント」の瞬間に発生します。つまり、データベースがトランザクションによって保持されていない時点で、一時テーブルは保持されません。たとえば、1週間の間、スケールポイントが発生せず、ベースが同じリソースで機能し、単純に拡大または縮小できない場合があります。



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

設計によるサーバーレス

Aurora Serverlessは、Serverlessの個々の利点を活用するために、クラウド用に書き直された古いベースです。それでは、元々クラウド用に作成された、サーバーレスアプローチのベース（Serverless-by-design）について説明します。物理サーバー上で実行されることを想定せずに、すぐに開発されました。



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







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



2番目のブロックは、計算用の仮想計算クラスターのセットです（図では-青い円のセット）。



3番目のブロックはS3ベースのストレージシステムです。S3は、AWSの無次元オブジェクトストレージであり、ビジネス向けの無次元Dropboxに似ています。



コールドスタートの仮定の下でスノーフレークがどのように機能するかを見てみましょう。つまり、データベースが存在し、データがデータベースにロードされ、有効なクエリはありません。したがって、データベースへのクエリがない場合は、高速のメモリ内メタデータサービス（最初のブロック）を作成しました。また、テーブルデータが格納されるS3ストレージがあり、いわゆるマイクロパーティションに分割されています。簡単にするために：テーブルに取引が含まれている場合、マイクロロットは取引の日です。毎日、個別のマイクロバッチ、個別のファイルです。また、データベースがこのモードで動作する場合、データが占めるスペースに対してのみ料金を支払います。さらに、シートあたりのレートは非常に低くなっています（特に大幅な圧縮が行われている場合）。メタデータサービスも常に機能しますが、クエリを最適化するために多くのリソースを必要とせず、サービスはシェアウェアと見なすことができます。



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



次に、サービスは計算クラスターの起動を開始します。計算クラスターは、計算を実行するサーバーのクラスターです。つまり、これは1つのサーバー、2つの北、4、8、16、32を含むことができるクラスターです-必要な数だけ。リクエストをスローすると、このクラスターの起動が即座に開始されます。本当に数秒かかります。







さらに、クラスターの開始後、マイクロパーティションがS3からクラスターにコピーされます。これは、要求を処理するために必要です。つまり、SQLクエリを実行するには、1つのテーブルから2つのパーティションが必要で、2番目のテーブルから1つのパーティションが必要であると想像してください。この場合、必要な3つのパーティションのみがクラスターにコピーされ、すべてのテーブルが全体としてコピーされるわけではありません。そのため、すべてが1つのデータセンターのフレームワーク内にあり、非常に高速なチャネルで接続されているため、ポンピングプロセス全体が非常に迅速に実行されます。 ..。したがって、マイクロパーティションは計算クラスターにコピーされ、完了すると、この計算クラスターでSQLクエリが実行されます。このクエリの結果は、1行、複数行、または1つのテーブルになります。これらは、ユーザーに送信されます。ダウンロードしたり、BIツールに表示したり、その他の方法で使用したりできるようにします。



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



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



シナリオは非常に現実的です。リクエストをスローすると、クラスターがポップアップします。比較的言えば、1分で、さらに1分、次に5分でシャットダウンし、最後にこのクラスターの7分間を支払いますが、数か月や数年はかかりません。



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



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



さらに、データを使って巨大なことを実行し、数十テラバイトを操作し、数十億行から数兆行のデータを分析しようとしている独創的なデータサイエンティストがいるとしましょう。



上記の2種類の負荷の場合、Snowflakeを使用すると、容量の異なる複数の独立した計算クラスターを持ち上げることができます。さらに、これらの計算クラスターは独立して動作しますが、共通の一貫したデータを使用します。



多数の軽いクエリの場合、通常はサイズがそれぞれ2台の2〜3個の小さなクラスターを作成できます。この動作は、特に自動設定を使用して実現できます。つまり、「スノーフレーク、小さなクラスターを育ててください。負荷が特定のパラメータを超えて大きくなる場合は、同様の2番目、3番目を上げます。負荷が落ち着き始めたら、余分な負荷を消します。」そのため、何人のアナリストが来てレポートを見始めても、誰もが十分なリソースを持っています。



同時に、アナリストが眠っていて、誰もレポートを見ていない場合、クラスターは完全に消滅する可能性があり、あなたはそれらの支払いをやめます。



同時に、（データサイエンティストからの）重いクエリの場合、条件付き32マシンごとに1つの非常に大きなクラスターを発生させることができます。このクラスターも、巨大なリクエストが実行されている分と時間に対してのみ請求されます。



上記の機能により、2つだけでなく、より多くの種類の負荷（ETL、監視、レポートの実体化など）をクラスターに分割できます。



スノーフレークをまとめましょう。ベースは、美しいアイデアと実行可能な実装を組み合わせたものです。 ManyChatでは、Snowflakeを使用してすべてのデータを分析しています。例のように3つのクラスターはありませんが、サイズの異なる5から9のクラスターがあります。条件付きの16マシン、2マシンがあり、一部のタスクには超小型の1マシンもあります。それらは負荷をうまく分散し、私たちが多くを節約することを可能にします。



ベースは、読み取りと書き込みのワークロードを正常にスケーリングします。これは、読み取りの負荷だけを引いた同じ「オーロラ」と比較して、大きな違いであり、大きなブレークスルーです。 Snowflakeを使用すると、これらの計算クラスターでワークロードをスケーリングおよび書き込むことができます。つまり、前述したように、ManyChatでは複数のクラスターを使用します。データのロードには、主にETLに小規模および超小規模のクラスターが使用されます。また、アナリストはすでにETLの負荷の影響をまったく受けない中規模のクラスターに住んでいるため、非常に迅速に作業できます。



したがって、ベースはOLAPタスクに適しています。同時に、残念ながら、OLTPワークロードにはまだ適用できません。第一に、このベースは円柱状であり、その後のすべての結果を伴います。次に、アプローチ自体は、要求ごとに、必要に応じて計算クラスターを作成し、データをこぼしてしまいます。残念ながら、OLTPワークロードの場合は十分な速度ではありません。OLAPタスクの待機秒数は通常ですが、OLTPタスクの場合は許容できず、100ミリ秒の方が適切であり、さらに10ミリ秒の方が適切です。

結果

サーバーレスデータベースは、データベースをステートレス部分とステートフル部分に分割することで可能になります。与えられたすべての例で、ステートフル部分は比較的言えば、マイクロパーティションをS3に格納し、ステートレスはオプティマイザーであり、メタデータを処理し、独立した軽量として発生する可能性のあるセキュリティ問題を処理することに注意してください。ステートレスサービス。



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



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



おもしろいと思います。サーバーレスは未来です:)