Amazon Web Services ブログ

チャネルコーポレーションのアーキテクチャモダナイゼーション：Amazon DynamoDB 活用事例 パート1 動機とアプローチ

(本記事は 2024/11/06 に投稿された How チャネルコーポレーション modernized their architecture with Amazon DynamoDB, Part 1: Motivation and approaches を翻訳した記事です。)

チャネルコーポレーション は、オールインワン AI メッセンジャー「チャネルトーク」を運営する B2B ソフトウェア・アズ・ア・サービス（ SaaS ）スタートアップです。「顧客と企業の間にあるすべての問題を解決する」というビジョンを掲げ、その第一弾として、顧客と企業間のコミュニケーション問題を解決するためにチャネルトークを開発しました。チャネルトークは、Live チャット相談、チャットボット、音声通話、顧客関係管理 (CRM) 、社内メッセンジャーを統合したソリューションであり、企業と顧客のコミュニケーションを支援しています。韓国、日本、米国を含む 22 カ国で 15 万社以上の企業に利用されており、毎月 7,000 万件以上のコールを処理しています。

この二部構成のブログシリーズは、 RDBMS から NoSQL への移行の動機と考慮事項を提示することから始まります。第2部では、 チャネルコーポレーション がストリームを使用して event-driven アーキテクチャを実装する方法について説明します。

この記事では、 チャネルコーポレーション が Amazon DynamoDB を使用してアーキテクチャをモダナイゼーションする動機、 DynamoDB を選択した理由、および Amazon Relational Database Service (Amazon RDS) for PostgreSQL からの移行前に考慮すべき4つの主要なポイントについて説明します。

背景：ビジネス成長と新たな問題の出現

チャネルトーク は当初、チームチャットとユーザーチャットの 2 つのコンポーネントに分かれていました。次のスクリーンショットに示されているチームチャット機能は、チーム内のコミュニケーションをサポートします。

次のスクリーンショットに示されているユーザーチャット機能は、顧客と企業の間のコミュニケーションを助けます。

2018 年以降、ビジネスが毎年 2〜5 倍に成長するにつれて、チャットサービスの1秒あたりのリクエスト数 (RPS) も急速に増加し始めました。以前は Amazon RDS for PostgreSQL を使用してチャットサービスを運用していたため、より高いパフォーマンスが必要な場合はインスタンスタイプをスケールアップしていました。

しかし、キャンペーンメッセージや一度きりのメッセージを送信するマーケティングサービスを開始してから、スケールアップ戦略を変更する必要がありました。キャンペーンメッセージは、顧客が特定のアクションを実行したときにルールに基づいて自動的にメッセージを送信する機能です。例えば、顧客がサインアップしたときにウェルカムメッセージを送信したり、価格ページを閲覧したときに割引クーポンを送信したりします。一度きりのメッセージは、特定の時間にターゲット顧客に一度だけメッセージを送信する機能です。たとえば、現在オンラインの顧客に限定割引クーポンを発行するために使用できます。

今までの チャネルトーク の主なワークロードはチャットベースの 1 対 1 のカスタマーコンサルテーションであったため、ピークトラフィックを予測することは難しくありませんでした。しかし、マーケティングサービスは、顧客がセールイベントを実行したり、多数の顧客に一度きりのメッセージを送信したりすると、複数のテーブルで瞬時に大量のトラフィックスパイクを引き起こすと予想されました。その結果、 チャネルコーポレーション は新しいスケーラブルなデータベースを必要とし、次の 4 つの主要な考慮事項がありました。

  • コスト効率の悪さ – インスタンスベースのサービスはピークに基づいてインスタンスサイズを選択する必要があり、マーケティングサービスは高い変動性を追加すると予想されました
  • テーブル間の負荷の波及 – 特定のテーブルやサービスの高負荷が RDS インスタンス全体のパフォーマンスに影響を与える可能性があります
  • PostgreSQL で行っていた既存の操作を効率的に実行するためのサポート
  • 要件と許容ダウンタイムに合わせた移行戦略の準備

DynamoDB を選択した理由

上記で記述した 4 つの問題を解決することに加えて、 チャネルコーポレーション は次の 3 つの主要な理由から DynamoDB を選択しました。

  • 他の AWS サービスに event sourcing を実装できる能力、一般的なイベント駆動型アーキテクチャパターン
  • 他の AWS サービスとの豊富なインテグレーション
  • ACID トランザクション

4 つの問題を解決するためのアプローチ

マーケティングサービスに関連する最初と第二の問題は、 DynamoDB を選択することで簡単に解決できました。

DynamoDB がオンデマンドキャパシティモードを提供していたため、コスト効率の問題にを柔軟に対応できました。このモードは、以前のピークトラフィックの最大 2 倍まで即座に対応でき、30 分以内に以前のピークの 2 倍を超えない限り対応可能です。また、必要に応じてテーブルを事前にウォームアップすることもできます。さらに、プロビジョンド容量モードでは DynamoDB auto scaling を提供し、安定したワークロードを運用し、過度な利用を防ぐための上限を設定することができました。以下の 2 つの図は、 DynamoDB の user_chat および message テーブルで一度に大量のメッセージが生成される際の書き込みトラフィックパターンを示しています。

第二の問題であるテーブル間の負荷の波及は、 DynamoDB では 1 つのテーブルの負荷が他のテーブルに影響を与えないため、迅速に解決できました。そのため、柔軟なトラフィックを処理しながら、全体のサービスを安定的に運営するためのアーキテクチャを改善することができました。
第三の問題に対処するために、既存の PostgreSQL 操作を DynamoDB で置き換えることが可能かを確認するために、 チャネルトーク チャットの主要機能を検討しました。次のスクリーンショットはこのプロセスを示しています。

チャネルトーク チャットの主な機能は次のように抽象化されます

  • Chat room (Chat) – チャットルームにはメッセージがあります。
  • Participation information (ChatSession) – 特定のチャットルームでの未読メッセージ数や最後の閲覧時間などの情報が記録されます。

Participation information における未読メッセージ数は ChatBadge と呼ばれます。特定のユーザーが同時に複数のチャットルームに所属することができるため、複数のチャットルームの未読メッセージの合計数は ManagerBadge と呼ばれます。
これらのコンポーネントには別々に動作する 2 つの要件があります：

  • 原子性 – 各チャットルームでメッセージが発生する際、送信者以外の受信者に対して ChatBadge がアトミックに増加します。
  • カウント – 各チャットルームで発生したすべての ChatBadge の合計が ManagerBadge になります。

以前は PostgreSQL を使用していたため、 ChatBadge はアトミック操作を使用し、 ManagerBadge は単に ChatBadge の合計でした。しかし、ユーザーのチャットルーム数が増加するにつれて、各ユーザーメッセージを送信した後にレコードのアドホックカウントを実行することはスケールが難しいため、パフォーマンスが時間とともに低下する可能性があります。この問題を解決するために、 DynamoDB トランザクションを使用することに決定しました。次のスクリーンショットはテーブル設計変更前の属性を示しています。

次のスクリーンショットは、テーブル設計変更後の属性を示しています。

特定のチャットルームでメッセージが作成されると、送信者を除く各参加者に対して次の操作が実行されます：

  • 参加者の ChatBadge を増加させる UpdateItem を作成します。
  • 参加者の ManagerBadge を増加させる UpdateItem を作成します。
  • TransactWriteItems API を使用して 2 つの UpdateItem 操作を処理します。

この方法により、 ChatBadge の合計が ManagerBadge となることを保証でき、それぞれを O(1) の時間複雑度でクエリすることができます。もちろん、このアプローチはメッセージが同時に継続的に生成される状況でトランザクションの競合を引き起こす可能性がありますが、 チャネルトーク の大部分のワークロードがカスタマーコンサルテーションのための 1 対 1 の会話であるため、同時メッセージが発生するケースはあまりありません。さらに、大量のメッセージが同時に発生する場合には、それらを処理する手順があります。

次の図に示すように、競合が発生した場合、exponential backoff 再試行戦略を使用します。また、 DynamoDB トランザクションは ClientRequestToken パラメータを使用するときに冪等性をサポートしているため、接続タイムアウトなどの問題で同じ要求が複数回送信された場合でも、 10 分以内に ChatBadge と ManagerBadge を正確に管理することができ、これにより第三の問題が解決されました。

最後に、移行は早朝に API サーバーを停止して行われました。 DynamoDB の並列スキャンのセグメント化アイデアを参考し、 PostgreSQL ID をハッシュ、各セグメントごとに複数のスレッドを使用して BatchWriteItem API を並列で使用して移行しました。

結論

DynamoDB は、ほぼ無制限のスループットとストレージ、スキーマの柔軟性、event-driven アーキテクチャを可能にする DynamoDB Streams 、および複数のテーブルに対する ACID トランザクションを提供します。 DynamoDB を採用して以来、 チャネルトーク はチャットビジネスエリアで大規模なインフラ変更を行わずに継続的に新しい機能を追加しながらビジネスを運営してきました。DynamoDB を使用することで次のような主要な利点を得ました。

  • インフラストラクチャやコード構造を改善することなく、新しい機能を継続的に追加することができました。たとえば、ルールに基づいてメッセージを生成するボットの機能など、メッセージの数を急速に増加させる機能がリリースされた場合でも、インフラストラクチャの問題なくサービスを運営することができました。
  • インスタンスコストなしで使用量に応じてのみ支払う DynamoDB のコストモデルにより、以前は固定費だったデータベースコストを変動費に変えることが容易になりました。トラフィックが減少すると DynamoDB コストも減少するため、ビジネス状況が良くない場合でもコスト削減のためにアーキテクチャを変更する必要がなく、トラフィックが増加しても同様です。
  • ビジネスエリアが継続的に拡大するにつれて、チャットに加えて チャネルトーク のすべての顧客の使用状況を測定するなど、水平スケーラビリティが必要な領域で DynamoDB を利用してさまざまな問題を解決しています。

シリーズの第 2 部では、 DynamoDB だけでは解決できなかった部分を他のサービスと統合して解決する方法について説明します。

著者について


TaeHun (Clsan) Yoon は コンピュータエンジニアリングの分野で経験豊富なプロフェッショナルである Channel Corp の最高技術責任者（ CTO ）として革新的なソリューションを牽引しています。チャット体験の向上に注力し、 TaeHun と彼のチームは顧客が直面するさまざまな課題の解決に尽力しています。

Changsoon (CS) Kim は、 Channel Corp の DevOps エンジニアです。開発と運用の間の問題を効率的に解決することに関心を持っています。


Sungbae Park は、 AWS スタートアップチームのアカウントマネージャーであり、 AWS SaaS TFC （Technical Field Communities）のレギュラーメンバーです。現在、 B2B ソフトウェアスタートアップが AWS で成長し成功するのを支援することに注力しています。以前は、 MSP 、 SI 、 ISV パートナーと共に相互成長を促進するパートナーデベロップメントマネージャーとして働いていました。

Hyuk Lee は、韓国に拠点を置くシニア DynamoDB スペシャリストソリューションアーキテクトです。彼は Amazon DynamoDB の機能を使用して顧客のアーキテクチャをモダナイゼーションするのを支援することが大好きです。