Amazon Web Services ブログ

Twilio が Amazon DynamoDB を使用して Messaging Postflight サービスのデータストアをモダナイズした方法

Twilio は、一流ブランドのためにリアルタイムでパーソナライズされた体験を提供するカスタマーエンゲージメント・プラットフォームです。 Twilio は、どんな開発者でも使えるほどシンプルでありながら、世界で最も要求の厳しいアプリケーションを動かすのに十分な堅牢性を備えた API を通じて、世界の通信インフラを仮想化することにより、音声、テキスト、チャット、ビデオなどの通信チャネルを民主化しました。

Twilio は、電話、 SMS 、オンラインチャット、電子メールなどのオムニチャネルをサポートしています。カスタマージャーニーのあらゆる段階で、 Twilio Messaging は、顧客が好むアプリケーションで顧客をサポートします。 Twilio は、プログラミング可能なメッセージング API を使用して、アカウントアクティビティ購入確認や出荷通知について顧客に積極的に通知することができます。

メッセージについての Twilio Messaging データパイプラインのライフサイクルは、2つの状態に分けられます。

  •  Inflight – メッセージのライフサイクルを通じて、イベントは完了するまで様々な Inflight の状態（キュー、送信、配信など）を移行する必要があります。 Twilio Messaging サービスの非同期性により、 Inflight の状態は、システム内のどこかで管理され、永続化される必要があります。
  •  Postflight – Postflight の状態になると、後で検索や分析処理ができるように、メッセージレコードを長期保存する必要があります。

今までは、すべての Twilio Messaging データは、メッセージがライフサイクルのどの段階にあるかにかかわらず、同じデータストアに置かれました。

Twilio Messaging Postflight は、 Twilio のバックエンドシステムで、 Twilio が扱うすべてのメッセージングトラフィック（ SMS 、 MMS 、 WhatsApp などの OTT ）のデータプレーンを提供します。 Postflight API を通じて、ユーザーと社内システムの両方がメッセージログデータの照会、更新、削除を行うことができます。このサービスは、最終的なメッセージの長期保存と検索、多様なクエリパターン、プライバシー、カスタムデータの保持を担っています。

この記事では、Twilio が Amazon DynamoDB を使用して、 Messaging Postflight サービスのデータストアをモダナイゼーションした方法について説明します。 DynamoDB は、あらゆる規模の高性能アプリケーションを実行するために設計された、フルマネージド、サーバーレス、キーバリューの NoSQL データベースです。 DynamoDB は、内蔵セキュリティ、継続的なバックアップ、自動化されたマルチリージョンレプリケーション、インメモリキャッシング、データのインポート/エクスポートツールを提供しています。

このモダナイゼーションにより、Twilio はレガシーアーキテクチャで経験した運用の複雑さと過剰プロビジョニングの課題を解消しました。モダナイゼーション後、Twilio では月に1件程度発生していた処理遅延が、ゼロになりました。レガシーな MySQL データストアでは、2020 年のブラックフライデーとサイバーマンデーのピーク時に 10～19 時間の遅延が発生しました。 DynamoDB では、2021年の同じピーク時に Twilio は遅延ゼロとなっています。 Twilio は、90 ノードあった MySQL データベースをすべて廃止し、年間 250 万ドルのコスト削減を達成しました。

レガシーアーキテクチャの概要

Postflight データストアは、 Twilio のトップアカウントに関連する数百億のレコードのアクセスパターンを処理します。レガシーアーキテクチャは、1日あたり 4 億 5000 万メッセージを処理し、 260 TB のストレージ、ピーク時に 4 万件の書き込みRPS、ピーク時に1万2000件の読み取り RPS を有していました。

Twilio Messaging Postflight は、シャーディングされた MySQL クラスタアーキテクチャを使用して、 260TB の現在および過去のメッセージログデータを処理・保存していました。このアーキテクチャは理論的にはスケーラブルですが、実際の観点からは、顧客トラフィックの急増にシームレスに対応できるほど軽快なものではありませんでした。

レガシーアーキテクチャには、スケールの観点で問題がありました。従来の課題としては、90ノードのクラスタをもつ MySQL の運用管理の複雑さ、トラフィック急増時の高い書き込み競合、データの遅延、オフピーク時の容量の過剰プロビジョニング、ノイジーネイバー問題（大規模な顧客トラフィック急増が書き込み競合を引き起こし MySQL データベースの可用性を低下させる）がありました。

レガシーデータストアは、以下のような属性と要件を持っていました。

  • 1つの MySQL テーブルに書き込み、各レコードは 1KB 未満である。データは Kafka メッセージングバスから MySQL データベースに取り込まれる。
  • MySQL データベースのローカライズには、新しいリージョンに新しいクラスターを作成する必要がある。
  • 1 秒間に 1000 ～数万回の書き込みがあり、急激に増えることがある。
  • データは数ヶ月間データベースに保持される。
  • アクティブな顧客が最低 100 万人いる。
  • データは数分以内に顧客からアクセスできることが期待される。
  • 書き込みトラフィックが 85 ％、読み出しトラフィックが 15 ％。
  • MySQL クラスタは、1つのプライマリクラスタと各シャード用の 3 つのレプリカで構成されている。
  • アカウントベースのシャーディングを利用している。
  • MySQL クラスタは、複数の Amazon Elastic Compute Cloud（Amazon EC2）I3en クラスタを使用している。
  • MySQL データベースには、現在約 1000 億件のレコードが格納されている。

Twilio Messaging のデータパイプラインでは、 Apache Kafka のトピックにメッセージが書き込まれます。中間サービスがメッセージを変換し、別のサービスがメッセージを MySQL データベースに挿入します。

次の図は、レガシーアーキテクチャを表しています。

Twilio は、レガシーな自己管理型 MySQL データストアのスケーリングと維持に関して、以下のような課題に直面していました。

  • MySQL のシャーディングデザインは、 Amazon EC2 上で動作する複数の自己管理クラスタから構成されていた。
  • アカウントベースのシャーディングは、大口顧客、特にノイジーネイバーからのトラフィックの急増に敏感であった。
  • シャード分割は、ライブトラフィックへの影響を考慮すると、時間がかかるうえリスクが高い。
  • 顧客トラフィックの大きなスパイクは、データベース障害を防ぐためにシャード全体の処理速度のスロットルを必要としている。これは、シャード上のすべての顧客にデータの遅延を引き起こし、サポートチケットの増加、顧客の信頼喪失の原因となる。
  • データベース・クラスターをピーク時の負荷に合わせてプロビジョニングすることは、ほとんどの時間帯で容量が低く使用されるため、非効率的であった。

以下のセクションでは、ストレージ層として DynamoDB を選択するに至った設計上の考慮事項と、データ処理パイプラインの構築、スケーリング、 DynamoDB への移行に関わるステップを説明します。

AWSプロフェッショナルサービスは、適切な目的の AWS データベースを特定するために、Twilio Postflight ワークロードのアクセスパターンをレビューし、ユースケースに基づいて DynamoDB が適していることを示しました。AWS プロフェッショナルサービスは、AWS クラウドを使用する際にお客様が望むビジネス成果を実現するための支援を行うグローバルな専門家チームです。

ソリューションの概要

Twilio Messaging が DynamoDB を選んだ理由は、以下の通りです。

  • Postflight のクエリパターンを、ソートされたキーバリューストアのレンジクエリに変換することができる。
  • DynamoDB は、Twilioの数百ミリ秒の要件を満たす低レイテンシのルックアップとレンジクエリをサポートしている。
  • DynamoDB は、予測可能なパフォーマンスとシームレスなスケーラビリティを提供している。 DynamoDB のパーティションは、1つで 3,000 個の 読み取り容量ユニット (RCU)と 1,000 個の 書き込み容量ユニット (WCU)を提供できるが、優れたパーティションキー設計により、水平スケーリングによって最大スループットは実質的に無制限となる。詳しくは「 Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance (Part 1: Loading) 」を御覧ください。
  • DynamoDB は、ユーザーのトラフィックに基づいてプロビジョニングされたスループット容量を動的に調整できる Auto Scalingキャパシティ管理機能を備えており、 Twilio はレガシー MySQL データベースに関連するピークワークロードに対してオーバープロビジョニングする必要がない。
  • DynamoDB はサーバーレスであり、自己管理型の MySQL と比較して運用の複雑さがない。 DynamoDB では、ハードウェアのプロビジョニング、セットアップと設定、レプリケーション、ソフトウェアのパッチ適用、クラスタのスケーリングについて心配する必要がなくなる。

DynamoDB がレガシー MySQL クラスターの代替データベースとして Twilio の要件を満たすためには、以下の成功基準を満たす必要がありました。

  • ベーステーブルへの書き込みトラフィックを100,000リクエスト/秒（ RPS ）に拡張し、レイテンシを数十ミリ秒にできること。
  • 1,000RPS の範囲内のクエリを、妥当なレイテンシーで提供できること。
  • ベーステーブルからインデックスへの書き込みが1秒以下のレイテンシーでレプリケートされること。

Twilio Messaging のリードアーキテクトは、 AWS プロフェッショナルサービスの協力を得て、 DynamoDB が Twilio のパフォーマンスとレイテンシの要件を満たすことを確認するために負荷テストを実施しました。AWS プロフェッショナルサービスは、パフォーマンスツールの Locust を使用してテスト環境を構築し、複数のアプリケーションから DynamoDB に取り込む合成ランダムワークロードを生成し、書き込みトラフィックを迅速にスケールアップさせました。

AWS プロフェッショナルサービスは、レガシーな MySQL データ構造から派生した DynamoDB データモデル（スキーマ設計）を見直し、パーティションごとのスループット制限に達することなく、ピークトラフィック要件に対してシームレスに拡張できることを確認しました。

パーティションキーの設計には、範囲検索による KeyConditions クエリーのサポートと、書き込みホットスポットを保護するための合成パーティションキーサフィックスが含まれています。計算されたサフィックスを使用したシャーディングも推奨されます。デフォルトでは、 DynamoDB テーブルのすべてのパーティションは、3,000 RCU と 1,000 WCU の全容量を提供するように努めます。ワークロードに単調増加しないソートキーがある場合、 アクセス頻度の高い項目を分離することで、書き込みシャーディングなしで、単一のパーティションキーに追加の容量を提供できます。また、他にも、書き込みシャーディングを使用して、低いカーディナリティのパーティションキーに追加の容量を提供することができます。

AWSプロフェッショナルサービスは、負荷テストを通じて、DynamoDB が Twilio の要件を満たすために拡張できることを確認しました。AWSとTwilioは負荷テストの結果を確認し、その結果が Twilio の成功基準に合致していることを確認しました。

下図は、 EC2 i3en インスタンス上で動作していた Twilio Messaging Postflight のマルチノード、セルフマネージド MySQL データストアを、 DynamoDB に置き換えたソリューションです。

まとめ

この記事では、 Twilio が 90 ノードの MySQL クラスタを DynamoDB でモダナイゼーションし、データ処理の遅延をゼロにすることで、運用の複雑さやオーバープロビジョニングの課題を取り除き、コストを大幅に削減する方法をご覧いただきました。

既存および新規のワークロードをモダナイゼーションし、 AWS の目的別データベースを使用することで、コスト効率が高く、完全に管理され、信頼できるデータストアを使用して、スケールでのパフォーマンスの利点を得ることができます。目的別データベースを使用したセルフサービスによる移行、 AWS プロフェッショナルサービスおよびパートナー、Database Freedom 移行プログラムの3つのオプションのいずれかを使用して、移行を支援することを検討します。

翻訳は Solutions Architect 塚本が担当しました。原文はこちらです。

著者について


ND Ngoka
AWSのSr.ソリューションアーキテクト。ストレージ分野で18年以上の経験を持つ。AWSのお客様がクラウド上で弾力的でスケーラブルなソリューションを構築するのを支援している。趣味はガーデニング、ハイキング、そして機会があれば新しい場所を探索すること。

 
 


Nikolai Kolesnikov
プリンシパル・データ・アーキテクトで、データエンジニアリング、アーキテクチャ、分散アプリケーション構築の分野で20年以上の経験を持つ。Amazon DynamoDBとKeyspacesを使用して、AWSのお客様が拡張性の高いアプリケーションを構築するのを支援しているほか、Amazon Keyspaces ProServeの移行作業をリードしている。

 
 


Greg Krumm
AWSのSr.DynamoDB Specialist SA。AWSの顧客がAmazon DynamoDB上で高可用性、スケーラブル、高性能なシステムを構築するのを支援している。家族との時間を大切にし、ポートランド周辺の森でハイキングを楽しんでいる。

 
 


Vijay Bhat
TwilioのPrincipal Software Engineerで、コミュニケーションプラットフォームを支えるコアデータバックエンドシステムに携わっている。機械学習と分析アプリケーションのための高性能データシステムを大規模に構築した深い経験を持ち合わせている。Twilio入社前は、Lyftでマーケティングオートメーションとインセンティブプログラムシステムを構築するチームを率い、Facebook、Intuit、Capital Oneでコンサルティングを担当した経験もある。仕事以外では、2人の幼い娘と遊ぶこと、旅行、ギターの演奏を楽しんでいる。