マルチコネクトを使ったAPIクライアントのスケーリング

標準のWhatsApp Business APIクライアントのソリューションは、単一のDockerコンテナ上で動作します。データ通信量を分散し、複数のサーバーでWhatsAppのメッセージの送受信を行いたい場合は、このマルチコネクトソリューションを併用してください。

概要

ハイアベイラビリティの場合、WhatsAppサーバーとメッセージの送受信を行うDockerコンテナは1つのみです。メッセージングトラフィックが単一のDockerコンテナの最大スループットを超えると、メッセージ送信のバックログが発生し、メッセージ配信におけるレイテンシが増加します。マルチコネクトは、WhatsApp Business APIクライアントをスケールアウトするため、シャーディングによって複数のDockerコンテナにデータ通信量を分散します。現時点でサポートしているのは、シャード数が1、2、4、8、16、32の静的シャーディングのみです。ハイアベイラビリティはシャード数1の特殊なマルチコネクトです。

シャード数2のマルチコネクトクラスタ

クラスタ内にWhatsAppサーバーとのメッセージの送受信を同時に行うコアアプリノードが2つ(CoreApp 1とCoreApp 3)存在します。メッセージはすべて受信者ID別にいずれか1つのシャードにのみ属します。

シャーディング

WhatsApp Business APIクライアントではシャーディングによりマルチコネクトを実現します。設定したシャード数に応じて、データベースにシャードマップを保持します。このシャードマップにより受信者ID(WhatsAppユーザーネーム)別にメッセージがどのシャードに属するのかを判定します。シャードを判定するための関数は次のとおりです。

shard_id = hash(recipient-id) % shard-number

シャードはそれぞれ実行中のDockerコンテナ(コアアプリ)に紐付けられています。ウェブアプリはこの関数の戻り値をもとに、どのDockerコンテナにメッセージリクエストを送信すべきかを判断します。X台のマシン障害を許容できるようにするため、シャード数は+ Xに設定することが推奨されます。

上の図のシャード数2のマルチコネクトの場合、シャーディング関数に基づいてメッセージをCoreApp 1とCoreApp 3にルーティングします。CoreApp 2はセカンダリで、電源は入っているもののWhatsAppサーバーには接続されていません。CoreApp 1がshard=0、CoreApp 3がshard=1のメッセージに対応するとします。CoreApp 1がダウンした場合、影響を受けるのはshard=0のメッセージのみです。shard=1のメッセージについては、システムは引き続きCoreApp 3を通じて送受信を行います。ハイアベイラビリティと同様に、Master 1は、CoreApp 1の障害を検出し、shard=0のトラフィックをCoreApp 2にフェイルオーバーします。このフェイルオーバーにはおよそ35秒かかります。

マルチコネクトの設定

ハイアベイラビリティドキュメントに従ってクラスタを設定したら、以下のリクエストでマルチコネクトをオンにしてください。

リクエスト

POST /v1/account/shards
{
    "cc": "country-code",
    "phone_number": "phone-number",
    "shards": 1 | 2 | 4 | 8 | 16 | 32,
    "pin": "pin",
    "cert": "verified-name-cert-in-base64"
}

パラメーター

応答

201 Created   : You successfully changed shard number 
403 Forbidden : You could hit this if server is temporarily unavailable, retry the request should fix it

シャード情報を取得中

リクエスト

GET /v1/account/shards

応答

{
  "account": {
      "shards": number-of-shards 
  }
}

メッセージ送信レート

参照、メッセージ、パフォーマンスを参照してください。

AWSデプロイメントの詳細

テンプレートURL:

• エンタープライズ: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent.yml?versionId=Tvb.Sa6uTwmvj1rSbbpKCmEKz2pyxcLG
• DB: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_db.yml?versionId=3.vthzENa7qUOuZrozcX9hDk9n8.kdTg
• Lambda: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_lambda.yml?versionId=gqIhZaXkX_NylKaPJMDBlQNk9.Pl_34b
• ネットワーク: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh

テンプレートにより、アクティブなコアアプリコンテナインスタンスの作成数を設定することができます。テンプレートは、コアアプリの障害発生時に素早く切り替えられるよう、コアアプリのコンテナインスタンスを1つ余分に作成します。

このテンプレートは、ハイアベイラビリティがオンの場合に、マルチコネクトの環境タイプごとに次の数のインスタンスをデフォルトで作成します。

• 本番稼働: EC2インスタンス: 3、ウェブコンテナ: 3、コアアプリコンテナ: 3、マスターコンテナ: 3
• ステージング: EC2インスタンス: 2、ウェブコンテナ: 2、コアアプリコンテナ: 2、マスターコンテナ: 2

テンプレートは、メモリの利用量に応じてEC2インスタンスを自動スケールするように設定されます。「アクティブ」なコアアプリコンテナインスタンスの数が増加(または減少)すると、メモリの利用量も増加(もしくは減少)します。したがって、より多くのコアアプリインスタンスが作成されると、それに応じてEC2インスタンスが自動スケールされます。しかし、作成可能なEC2インスタンスの最大数には以下の上限があります。

RDSインスタンスサイズ

APIリクエストレートとアクティブなコアアプリインスタンスの数が、データベースへの接続数を決定します。アクティブなコアアプリインスタンスが8つで、APIレートが100メッセージ/秒の場合、約700DBの接続(SSLは無効)と1200DBの接続(SSLが有効)が必要です。一方、アクティブなコアアプリインスタンスが32で、APIレートが250メッセージ/秒の場合、約1700DBの接続が必要です。

現在のリリースでは、アクティブなコアアプリインスタンスが8つ(DB接続暗号化が無効)の場合にはdb.m4.2xlargeを、アクティブなコアアプリインスタンスが32(DB接続暗号化が有効)の場合にはdb.m4.4x.largeを使っています。次の表は、RDSインスタンスクラスの選択と、サポート可能な最大接続数に関するガイダンスを提供するものです。

設定

• テンプレートに設定されたアクティブなコアアプリインスタンスは、コアアプリインスタンスの作成数のみを管理します。作成されたコアアプリインスタンスを有効にするには、シャード設定(マルチコネクトの設定セクションに記載)を使用する必要があります。シャードのデフォルト値は1です。
• コアアプリインスタンスの数が、APIに設定されたシャード数以上であることを常に確認してください。
• シャード数を増やすには:

  • 希望するアクティブなコアアプリインスタンス数に合わせて、スタックを作成または更新します。
  • 作成または更新が終わったら、シャード設定を使用して、その数と同じアクティブなコアアプリインスタンスまたはシャードを有効化します。
  • 注:シャード設定を使用すると、すべてのコアアプリコンテナインスタンスが停止し、自動的に再起動されます。シャード設定が実行されると、約45秒から1分間のダウンタイムが発生します。
• シャード数を減らすには:

  • シャード設定を使用して、アクティブなコアアプリインスタンスまたはシャードを同じ数だけ減らします。
  • すべてのコアアプリインスタンスの再起動が完了したら、アクティブなコアアプリインスタンスの数に合わせてスタックを更新します。
  • 注:スタックを更新すると、現在シャードを提供しているアクティブなコアアプリインスタンスが終了する可能性があります。しかし、稼働中の他のコアアプリインスタンスがすぐに割り当てられます。この手続き中に追加のダウンタイム(最大35秒)が発生する可能性があります。