Teams sometimes need lower latency, lower costs (especially as they scale) or the ability to run their applications somewhere other than AWS. Amazon DynamoDB が 2012 年に導入されて以来、多くのチームが Amazon DynamoDB に切り替わった理由を理解するのは簡単で、特に組織が AWS エコシステムにすでに根ざしている場合に始めるのは簡単です。 しかし、時間の経過とともに、特にワークロードのスケールとビジネス要件が進化するにつれて、欠点が生じます。チームには時には遅延、コスト(特にスケールするにつれて)、またはアプリケーションをAWS以外の場所で実行する能力が必要です。 3つのチームがDynamoDBを離れることを促した課題を探ってみましょう。 複数のクラウドの柔軟性とコスト削減 Yieldmo は、ML で最適化されたオークションベースのシステムを使用して、リアルタイムで出版社と広告主を結びつけるオンライン広告プラットフォームです。 彼らは当初、DynamoDBにプラットフォームを構築しましたが、DynamoDBは信頼性の高いものでしたが、それらが成長するにつれて重大な制限が現れました。テクニカル共同創設者兼Chief ArchitectのTodd Colemanが説明したように、彼らの主な懸念は二重でした:コストの拡大と地理的制限。 DynamoDBの代替案を探索しながら、スピード、スケーラビリティ、信頼性を維持し、コストを削減し、クラウドベンダーの独立性を確保するオプションを見つけることを希望していました。 Yieldmoは最初にDynamoDBと滞在し、キャッシュレイヤーを追加することを検討しました。しかし、キャッシュは地理的な遅延の問題を解決できませんでした。 彼らはまた、スピードとクロスクラウドのサポートを提供するAerospikeを調査しました。しかし、Aerospikeのメモリインデックスには、Yieldmoの小規模なデータオブジェクトの数を扱うために、非常に大きな、高価なクラスターが必要でした。 そして、ScyllaDBのDynamoDB互換性のあるAPI(Alternator)はゲームを変えた。 トッド氏は「ScyllaDBはクロスクラウド展開をサポートし、管理可能なサーバー数を必要とし、競争力のあるコストを提供しました。 移行プロセスは慎重に計画され、既存の Kafka メッセージ列アーキテクチャを活用してデータの整合性を確保し、2 つの概念証明テスト (POC) を実施しました:最初は、1 つのテーブルで 28 億のオブジェクト、次にすべての 5 つの AWS リージョンで。 結果は印象的でした。トッドは、「当社のデータベースコストは、DynamoDBの予約容量価格でさえ半分に削減された」と述べ、コストの節約に加えて、Yieldmoは異なるクラウドプロバイダーに展開するための柔軟性を獲得しました。 結論から言えば、トッドは「当初の懸念の1つは、DynamoDBの証明された信頼性から離れることだった。しかし、ScyllaDBは優れたパートナーだった。彼らのチームは、クラスターの監視を提供し、潜在的な問題について警告し、継続的なメンテナンスの面でスケーリングが必要なときに私たちにアドバイスを提供しています。 Yieldmoから聞く より良いパフォーマンスと低コストのGCPへの移行 モバイル広告技術の主要なプレーヤーであるDigital Turbineは、年間収益が5億ドルで、DynamoDBの実装でますます課題に直面していました。移行の主な動機は、買収後のGoogle Cloud Platformでの標準化であったが、既存のDynamoDBソリューションは、規模の両方でパフォーマンスとコストの懸念を引き起こしていた。 「あなたがスケールするにつれて少し高価になる可能性があります」と、デジタルタービンのプラットフォームアーキテクチャの副社長ジョセフ・ショッターは説明しました。 「私たちはいくつかのパフォーマンスの問題を発見していました。DynamoDBとのすべてのインタラクションの90%は読み取り操作でした。 デジタルタービンは、移行を可能な限り速く、リスクが低いようにする必要があり、これはアプリケーションの再構築を最小限に抑えることを意味しました。Shorterによると、主な懸念は「私たちはプラットフォームを根本的に再構築することなく、少なくとも同じパフォーマンスと価値を維持しながら、移行を進めることができるとしたら、それは会社全体を崩壊させることになるからです。 いくつかのオプションを評価した後、Digital Turbine は ScyllaDB に移行し、すぐに改善を達成しました。 「20%のコスト差は、あなたが何を話しているかに関係なく大きな数字です」ショッター氏は「さらに拡大する計画を考えると、それはさらに重要になります」と述べた。 コストの節約を超えて、彼らは「スクリラDBのクラスターをほとんど触れていない」とし、比例的なコスト増加なしでさらなる成長の余地があることを示唆しました。 「Digital Turbine」 High Write Throughput with Low Latency 低コスト 世界最大のメディアストリーミングサービスのユーザーステータスおよびカスタマイズチームは、DynamoDB を使用して数年を経ており、既存の 2 つの使用ケースを再構築していたため、データベースの変更の時期が来たのか疑問に思った。 休止/再開:ユーザーがショーを視聴し、それを休止している場合、彼らはどこからでも、どのデバイスからでも、どこからでも、休止した場所を回収することができます。 見る状態:同じデータを使用して、ユーザーが番組を見たかどうかを決定します。 以下はシンプルな建築図です。 クライアントは30秒ごとに、ショーの更新されたプレーヘッドポジションでハートバットを送信し、それらのイベントをデータベースに送信します。Edge Pipeline はユーザーと同じ地域のイベントをロードし、Auth Pipeline は、会社が提供する5つの地域のイベントを組み合わせます。最後に、データを取得し、再生をサポートするためにクライアントに戻さなければなりません。 このアーキテクチャをサポートするための2つの主な技術要件は以下の通りでした。 優れたユーザーエクスペリエンスを確保するために、システムは低遅延の読み込みとトラフィックの増加に基づいてスケール化する能力を備えた高可用性のままにしなければならなかった。 膨大なインフラストラクチャ設定や DBA 作業を回避するためには、AWS サービスとの簡単に統合する必要があります。 これらのボックスをチェックすると、チームは全体的なコストを削減することを望んでいました。 「当社の既存のインフラストラクチャでは、DynamoDBとElasticacheのさまざまなクラスターにデータが広がっていたので、これらをより低コストのシステムに組み合わせることができるシンプルなものを本当に欲しかった」とバックエンドエンジニアは説明した。 具体的には、以下のようなデータベースが必要でした。 多地域サポートは、このサービスが5つの主要な地理地域で普及したためです。 アップデートには厳格なサービスレベルの合意(SLA)はありませんでしたが、システムはイベントタイムスタンプに基づいて条件付けのアップデートを実行する必要があります。 78K を超える読み込みを 1 秒間に P99 の遅延が 10 ～ 20 ミリ秒で処理する能力. 使用例には単純なポイント クエリのみが含まれていた; インデックス、パーティション、複雑なクエリパターンなどのものは主な懸念ではなかった。 約10TBのデータと成長の余地 なぜDynamoDBから移行するのか? バックエンドエンジニアによると、「DynamoDBは私たちの技術的要件を完璧にサポートすることができたが、データのサイズと高い(書き込みが重い)スループットを考慮して、DynamoDBを継続することは、火に金を投げ込むようなものだった」と述べた。 書くパフォーマンスとコストの要求に基づいて、彼らはScyllaDBを探索することにしました。コンセプトの証拠として、彼らは6つのAWS i4i 4xlargeノードを持つScyllaDB Cloudテストクラスターをセットアップし、クラスターを3億レコードでプレロードしました。 これらの低い遅延と大幅なコスト削減(50%以上)は、DynamoDBを離れることを説得しました。 ScyllaDB のパフォーマンスに焦点を当てた設計(Seastar フレームワークに基づいて構築され、C++ を使用し、NUMA に注意を払い、無意識のドライバーを提供するなど)は、メンテナンスの時間とコストを削減するのに役立ちます。 Incremental Compaction Strategyは、書き込み強化を大幅に減らすのに役立ちます。 柔軟な一貫性レベルと複製要因により、Auth および Edge パイプラインを別々にサポートできます。例えば、Auth はクローム一貫性を使用し、Edge はデータの重複性と高いスループットのために「1」の一貫性レベルを使用します。 彼らのバックエンドエンジニアは、「データベースを選ぶのは難しい。あなたは機能だけでなくコストも考慮する必要があります。 「当社のケースでは、高いパフォーマンスと遅延要件のために、DynamoDBサーバーレスは素晴らしい選択肢ではありませんでした。また、ハードウェアの役割を過小評価しないでください。 もっと学ぶ あなたのチームは次ですか? チームが考えている場合 で、 to explore. 登録する あなたの使用例、SLA、技術要件、そしてあなたが最適化したいものについてもっと話すために、ScyllaDBが適合しているかどうか、そして、もしそうであれば、アプリケーションの変更、データモデリング、インフラストラクチャなどに関して移行が意味するものについて教えてください。 DynamoDB からの移行 ScyllaDBはオプションかもしれません。 技術相談会 ボーナス:ここでは、ScyllaDBがDynamoDBとどのように比較されているかを簡単に見ていきましょう。 書かれた by : : ギルヘルム・ダ・シルバ・ノグエイラ そして フェリペ・カーデネティ・メンデス . 書かれた by ギルヘルム・ダ・シルバ・ノグエイラ フェリペ・カーデネティ・メンデス
