SimilarWeb が Couchbase から Amazon DynamoDB に移行し、70％ 節約した方法

今回は AWS ソリューションアーキテクトの Leonid Koren、および AWS シニアテクニカルアカウントマネージャーの Ziv Shenhav との共同著作による、SimilarWeb のソフトウェア開発者 Doron Grinzaig 氏のゲストブログ投稿です。

NoSQL データベースはスケーラブルで適応性があり、高機能のデータベースを必要とする現代のモバイル、ウェブ、ゲーム用アプリケーションに最適です。しかしながら、NoSQL データベースは分散型の性質を持つため、特に大きな規模になると管理が難しく、多くのリソースとかなりの注意が必要になります。SimilarWeb は数年の間、2 つの Couchbase クラスターを運用していましたが、コストと運用オーバーヘッドは高くついていました。そのため SimilarWeb は、安定性の向上とコストおよび運用オーバーヘッドの削減を目指して、Amazon DynamoDB に移行したのです。DynamoDB は完全マネージド型のデータベースサービスで、現在では複数の AWS リージョンで SimilarWeb の顧客にデータを提供している信頼性の高いデータベースの 1 つです。

このブログ投稿では、SimilarWeb が DynamoDB への移行を決めた理由を詳しく説明します。移行プロセスについて説明し、コスト削減に役立った最適化の方法についても解説します。

SimilarWeb について

SimilarWebは、デジタル世界全体の動向に関する洞察を提供するマーケットインテリジェンス企業です。何千にもおよぶ顧客が同社の洞察を基に、マーケティング戦略の改善、販売促進、さらに投資に関する重要な決定を下しています。重要な意思決定に SimilarWeb が関わっていることが、データを効果的に収集かつ利用し、最終的にはユーザーに提供する SimilarWeb の能力を証明しています。

SimilarWeb はさまざまなソースから大量の生データを継続的に収集し、取り込みます。Cloudera クラスター (Apache Spark を実行している) を使って、これらのデータを並び替えて構造化します。データを Apache HBase クラスターにロードし、Amazon S3 ベースのデータレイクに保存します。過去にはデータの一部を Couchbase クラスターに取り込んでいましたが、後に DynamoDB に移行しました。このブログ記事はこの移行に焦点を当てています。

移行後、SimilarWeb は HBase と DynamoDB のデータを使用して、2 つの AWS リージョンから顧客に洞察を提供しています。SimilarWeb のマルチリージョン対応アーキテクチャの詳細については、「This is My Architecture」のこちらの動画をご覧ください。

SimilarWeb が Couchbase から DynamoDB に移行した理由

Couchbase は対話型アプリケーション用に最適化された、分散型で非リレーショナルのドキュメント指向データベースです。移行前における Couchbase の役割は HBase から来る静的データを、より頻繁に変化する動的データで補強することでした。

Amazon DynamoDB は信頼性の高いパフォーマンスを、あらゆる規模で提供できる非リレーショナルデータベースです。これは完全管理型マルチリージョンのマルチマスターデータベースで、レイテンシーは 1 桁台のミリ秒単位という安定性を持ちます。さらに、ビルトインのセキュリティ、バックアップとリストア、およびメモリ内キャッシュも提供します。

SimilarWeb は Couchbase のデプロイに伴う課題がいくつかあったため、DynamoDBへの移行を決めました。

運用オーバーヘッド

Couchbase クラスターの維持にはかなりのオーバーヘッドを追加し、さらに特別な経験や知識を必要としました。サーバーとデータベースへのパッチ適用、アップグレード、モニタリング、データベースの高性能維持など、継続的なメンテナンスのために貴重な時間を消費します。Couchbase クラスターを 2 つの AWS リージョンで維持することで、運用オーバーヘッドがさらに増加しました。

一方 DynamoDB は完全マネージド型サービスのため、SimilarWeb のソフトウェアエンジニアたちはデータベースの運用とインフラストラクチャの管理と保守ではなく、ビジネスをイノベーションすることに集中できるようになります。

ご利用状況

2 年半の間に少なくとも 10 回は、SimilarWeb の Couchbase データベースが部分的あるいは完全に停止することがありました。Couchbase から DynamoDB に移行してから 10 か月、SimilarWeb のデータベースは 100 パーセントのアップタイムとなっています。

パフォーマンス

データセットが大きすぎて RAM に収まらないため、Couchbase から安定した応答時間を得るのに苦労していました。その結果、Couchbase の利点を活用できていませんでした。一方 DynamoDB ではクエリ応答時間が短縮され、安定性が向上します。

以下の 2 つのグラフは、SimilarWeb のサーバーから見た Couchbase と DynamoDB の平均応答時間を示しています。グラフに表示されているクエリには、複数のキーに対するリクエストが含まれています。

グラフ 2 の DynamoDB の場合の約 13 ミリ秒と比べて、グラフ 1 の Couchbase の場合、ベースラインのレイテンシーは約 18 ミリ秒と長いことが分かります。

さらに、DynamoDB のグラフ (グラフ 2) は Couchbase よりもベースラインからの偏差が小さく、スパイクが少ないことを示しています。

運用環境とテスト環境の分離

運用オーバーヘッドとコストの削減のために SimilarWebは、運用環境とステージング環境の両方で同じ Couchbase クラスターを使用しました。この状況だと、テストが運用ワークロードに影響を与える可能性がありました。DynamoDB では各テーブルに独自のプロビジョンド容量があるため、1 つのテーブルに対して実行されるクエリは他のテーブルに対して実行されるクエリに影響を与えません。

費用

Couchbase クラスターではトラフィックのスパイクをサポートしようと、過剰にプロビジョニングが行われました。一方 DynamoDBでは書き込み容量と読み取り容量が、テーブルごとに別々に定義されます。DynamoDB Auto Scaling を使用すれば、手動あるいは実際の使用状況に基づき、これらの容量を調整できます。SimilarWeb はこの機能を利用し、必要な容量に対してのみ支払いを行い、データベースコストを 70％ 以上削減しています。

SimilarWeb がこのコスト削減を達成した詳細については、次のセクションをご参照ください。

DynamoDB への移行

SimilarWeb では 2 つの AWS リージョンの日次および月次のテーブルに、何億ものレコードをすばやく入力する必要がありました。このセクションでは、SimilarWeb がどのようにコストを認識していたかを解説します。

動的な書き込み要件と読み取り要件の処理

SimilarWeb では書き込み容量と読み取り容量を別々にスケーリングするよう DynamoDB を設定し、それぞれのワークロードに合わせて最適化していましたが、これは Couchbase ではできませんでした。たとえば、DynamoDB テーブルにデータを挿入する日次および月次のジョブでは、テーブルは極めて高い書き込みスループットの処理を要求されます。別なときには、データベースに対して書き込みは実行されず、読み取りワークロードにのみテーブルを使用します。

そこで SimilarWeb はスクリプトを使用し、DynamoDB テーブルのプロビジョニング済みの書き込み容量を動的に調整する機能を使用しています。このスクリプトではデータ挿入中は書き込み容量を増やし、挿入が完了するとすぐに最小容量まで減らします。この場合 Auto Scaling を使用しません。プロビジョニング済みの書き込み容量を、テーブルに対して行われた書き込み数の急激な変化に対応するのに十分な速さでスケーリングできないためです。けれどもオンデマンドモードを使用するようにテーブルを切り替えることが可能なため、自動的に書き込みをスケーリングすることができ、心配はありませんでした。ただし、書き込みワークロードのアクセスパターンは極めて安定しているため、プロビジョニングモードとそれらのスクリプトはより費用効果が高く、書き込みと読み取りを別々に制御することもできます。

実際の使用状況に基づいて容量を自動的にスケーリングするために、SimilarWeb はテーブルの読み取り容量の Auto Scaling が可能となります。DynamoDB のバーストキャパシティーは最後の 5 分間の未使用のプロビジョニング済み容量を利用することで、突然のトラフィックの急増に対応します。

Amazon EMR を使用して、複数の AWS リージョンの DynamoDB にデータを挿入する

何百万ものクライアントがデータを取り込み、処理し、変換すると、そのデータは Amazon S3 ベースのデータレイクに保存されます。DynamoDB に移行する前は、日次および月次の抽出、変換、取り込み (ETL) プロセスで Couchbase にデータを挿入しており、そのためウェブサイトからのクエリを処理することが可能でした。

Amazon S3 から DynamoDB に大量のデータを迅速に挿入するために、SimilarWeb は Amazon EMR を使用しました。これは分散方式でデータ挿入を容易にする、マネージド Hadoop フレームワークを提供するものです。また emr-dynamodb-connector オープンソースライブラリを使用することで、Amazon EMR の Hadoop、Hive、Spark が DynamoDB とやりとりできるようになりました。

2 つの AWS リージョンからのトラフィックを処理するレイテンシーとデータ転送コストの増加を回避するため、データは両方のリージョンの DynamoDB テーブルに常駐し、各リージョンでローカルにクエリされます。SimilarWeb は DynamoDB のグローバルテーブルを使用することで、リージョン間でデータをレプリケートするためのマルチリージョン、マルチマスターデータベースソリューションを提供することも可能でした。しかし SimilarWeb では、代わりに各リージョンでのリージョナル DynamoDB テーブルを使用することを選択しました (この記事の後半でその理由を説明します)。

DynamoDB にデータを取り込むために、us-east-1 と us-west-2 のリージョンに日次または月次テーブルと、プロビジョニング済みの書き込み容量ユニット (WCU) 、および読み取り容量ユニット (RCU) の Auto Scaling を作成します。両リージョンで Amazon EMR クラスターを起動し、各クラスターに Hive ジョブを送信して新しいテーブルにデータを入力します。

データの取り込みが完了すると、新しいテーブルの WCU はテーブルの最小書き込み容量である 1 に減少します。その後 Amazon EMR クラスターを終了し、アプリケーションが古い DynamoDB テーブルから新しい DynamoDB テーブルに切り替わります。SimilarWeb は古いテーブルをバックアップ用に日または月単位で保持し、新しく取り込まれたデータに問題があった場合にすぐに元のテーブルに戻すことができるようにしておきます。古いテーブルの読み取り容量は 1 に減り、2 日または 1 ヶ月以上経った古いテーブルは削除されます。

テーブル作成のスピードアップ

DynamoDB で日次または月次のテーブルを作成するには、まずデフォルトのキャパシティユニットを含むテーブルを作成してから、使用する WCU と RCU を割り当てることによってテーブルを更新します。SimilarWeb はこのプロセスに、1 時間以上かかることがあることに気付きました。そこで代わりにテーブル作成コマンドに容量ユニットの値を含めることで、テーブル作成時間を数秒に短縮しました。

これほどの大幅な時間削減ができた理由は、DynamoDB のデータ分割の方法にあります。デフォルトの容量ユニットで空のプロビジョニング済み容量テーブルを作成すると、そのテーブルに単一のパーティションが割り当てられます。このため、テーブルの RCU と WCU の更新時にパーティションが分割されます。テーブルの再分割は、作成時にテーブルを事前に分割する場合に比べて処理が遅くなります。

データベースコストの削減

DynamoDB にはさまざまな容量モデルがあるため、いろんなユースケースに対応できます。このセクションでは、SimilarWeb が特定のユースケースに最適な容量モデルをどのように選択し、それらがどのように追加コストを最適化したかを説明します。

DynamoDB のキャパシティーモードと SimilarWeb が選んだキャパシティーモード

プロビジョンドまたはオンデマンドの 2 つのキャパシティーモードがあり、DynamoDB テーブルにはそのいずれかかがあります。テーブルを作成すると、2 つのモードのどちらかを選択する必要があります (同じテーブル内でモードを混在させることはできませんが、24 時間ごとにモードを変更できます)。

プロビジョンドキャパシティーモードでは、データベースに必要な読み取り容量と書き込み容量でテーブルをプロビジョニングできます。Auto Scaling を使用して、必要に応じ DynamoDB で容量をスケーリングすることもできます。プロビジョンドキャパシティモードの詳細については、「プロビジョニングモード」 (「Amazon DynamoDB 開発者ガイド」にある) をご参照ください。DynamoDB 用にリザーブドキャパシティーを購入することもでき、未リザーブドのプロビジョン済み容量を大幅に節約できます (最大 77％)。

オンデマンドキャパシティーモードでは、DynamoDB がテーブルで実行された読み取りおよび書き込みの数で正確に請求します。オンデマンドキャパシティモードの詳細については、「オンデマンドモード」 (「Amazon DynamoDB 開発者ガイド」にある) をご参照ください。

SimilarWeb の顧客アクティビティが読み取りを起動します。読み取りにはスパイクがたまにあるかもしれませんが、時間が経つにつれて安定したベースラインを使用するようになっていきます。SimilarWeb は読み取り容量用に、リザーブドキャパシティーを購入しました。これらはトラフィックの漸進的な変化を処理する Auto Scaling と、ランダムなスパイクを処理するためのバーストキャパシティーに依存しています。書き込みに関しては、ユースケースを非常にすばやく変更し、かつ費用を節約するためのスクリプトでスケーリングを管理します。

その他のコスト削減方法

SimilarWeb のワークフローは 2 つの AWS リージョンからのデータを提供する必要があるため、グローバルテーブルを使用して一方のリージョンにデータを書き込み、もう一方のリージョンにデータをレプリケートすることを検討しました。グローバルテーブルで使用するレプリケート済み書き込み容量ユニット (rWCU) は、通常の WCU よりもコストがかかります。テーブルへの書き込みはテーブルが作成された後に一度だけ行われるため、書き込みの競合を解決するようなグローバルテーブル機能は必要ありません。そこでソリューションのコストを削減するため、SimilarWeb は両方のリージョンで通常のテーブルを使用することにしました。その結果、データは各リージョンの Amazon EMR クラスターから別々に取り込まれました。

SimilarWeb は Amazon EMR クラスターでスポットインスタンスを使用し、さらにコストを削減しました。さらに Apache Airflow を使用することで、Amazon EMR クラスターを一時的に ETL ジョブの間だけスピンアップおよびスピンダウンしました。

結論

この記事では、SimilarWeb が Couchbase から DynamoDB に移行した方法について解説しました。その過程で、データベースコストが 70％ 以上削減し、パフォーマンスが向上し、運用オーバーヘッドも削減しました。

著者について

Doron Grinzaig 氏は SimilarWeb の「プラットフォーム」R&D グループに所属するソフトウェアエンジニアで、ビッグデータのダイジェスト、変換と取り込み、提供に取り組んでいます。

Leonid Koren はアマゾン ウェブ サービスのソリューションアーキテクトです。 AWS のお客様と協力して、セキュアで回復力があり、かつスケーラブルで高性能なアプリケーションをクラウドに展開するのを支援しています。

Ziv Shenhav はアマゾン ウェブ サービスのシニアテクニカルアカウントマネージャーです。エンタープライズサポートのお客様と協力して、コストの最適化、オペレーショナルエクセレンス、セキュリティ、コンプライアンスなどを支援しています。