WhatsApp Business Platform > On-Premises API > Guides > Set up & Maintain Your API Client

データとデータベースを管理する

このドキュメントでは、WhatsApp Business APIクライアントに関連したさまざまな種類のデータとデータベースを管理する方法について説明します。

ボリューム

ボリュームは、Dockerコンテナによって生成および使用されるデータを保持するメカニズムとして望ましい手段です。WhatsApp Business APIクライアントには、メディア用のDockerボリュームが1つ必要です。このボリュームは、インストール中にdocker-composeコマンドを実行すると自動的に作成されます。

Dockerボリュームでは、リモートホストやクラウドプロバイダにボリュームを保存することがサポートされています。メディアボリュームは、既存の任意のデータセンターファイルシェアソリューション上に設定できます。メディアボリュームに対する読み取り/書き込みアクセス権限が、すべてのWebappコンテナおよびCoreappコンテナに付与されていることを確認してください。ボリュームを参照するパスを表示したり編集したりするには、docker-compose.ymlファイルを編集します。

名前	説明
メディアボリューム	着信メディアファイルと発信メディアファイルを格納しますデフォルトではコンテナ内の`/usr/local/wamedia/`にマウントします

環境変数

WhatsApp Business APIクライアントでは、データを格納するためにMySQLまたはPostgreSQLを使うことができます。

データベースの設定は、WhatsApp Business APIクライアントをインストールする際に、db.envファイルの中で次の環境変数を設定することにより構成できます。これらの環境変数は、CoreappとWebappがデータベースに接続する際に使われます。

データベース設定	環境変数
`database_engine`	`WA_DB_ENGINE`
`hostname`	`WA_DB_HOSTNAME`
`port`	`WA_DB_PORT`
`username`	`WA_DB_USERNAME`
`password`	`WA_DB_PASSWORD`
`database_name_prefix`	`WA_DB_NAME_PREFIX`
`connection_idle_timeout`	`WA_DB_CONNECTION_IDLE_TIMEOUT`

WA_DB_NAME_PREFIX — WhatsApp Business APIクライアントのインストール時に作成されるすべてのデータベースのプレフィックスとして使うことができます。これは、WhatsApp Business APIデータベースの複数セットを同じデータベースホスト上で実行するために使うことができます。
WA_DB_CONNECTION_IDLE_TIMEOUT (MySQLでのみサポート) — Coreapp起動時にこの環境変数(ミリ秒単位)を設定することにより、MySQLデータベースのアイドルタイムアウトを設定できます。アイドル状態のまま、設定された時間が経過したデータベース接続は、MySQLサーバーによって閉じられます。

データベース管理

WhatsApp Business APIクライアントに関連付けられたデータベース管理に関する推奨事項について説明します。

懸念事項おすすめ

懸念事項	おすすめ
大規模データベースにアップグレードする	大規模データベースと見なされるのは、`messages`表に200万以上の行があるものです。アップグレードする間、データベースの安定性を維持するために、`/services/message/gc`エンドポイントの使い方に関する以下の推奨事項をご利用ください。
API呼び出しベースのガベージコレクション	データベースのクリーンアップを統合依存にします。理想としては、ほとんどのビジネスではデータベースのクリーンアップは避けるべきです。ビジネスでは、次のようにして、WhatsApp Business APIを使ってデータベースガベージコレクションを実行することをおすすめします。積極的なクリーンアップを有効にするためのAPIリクエストを発行する前に、受信メッセージに既読マークを付けるようにします。 `/services/message/gc`エンドポイントを、24時間に1回、ダウンタイム(発信メッセージ量が少ない時間)に使うようおすすめします。 1,000万行を超える`messages`表については、確実にコールバック通知でエラーがなくなるようにするにはAPIリクエストを何度も発行する必要があるかもしれません。詳しくは、サービスのドキュメントをご覧ください。

大規模データベースにアップグレードする

大規模データベースと見なされるのは、messages表に200万以上の行があるものです。
アップグレードする間、データベースの安定性を維持するために、/services/message/gcエンドポイントの使い方に関する以下の推奨事項をご利用ください。

API呼び出しベースのガベージコレクション

データベースのクリーンアップを統合依存にします。理想としては、ほとんどのビジネスではデータベースのクリーンアップは避けるべきです。
ビジネスでは、次のようにして、WhatsApp Business APIを使ってデータベースガベージコレクションを実行することをおすすめします。
- 積極的なクリーンアップを有効にするためのAPIリクエストを発行する前に、受信メッセージに既読マークを付けるようにします。
- /services/message/gcエンドポイントを、24時間に1回、ダウンタイム(発信メッセージ量が少ない時間)に使うようおすすめします。
- 1,000万行を超えるmessages表については、確実にコールバック通知でエラーがなくなるようにするにはAPIリクエストを何度も発行する必要があるかもしれません。

詳しくは、サービスのドキュメントをご覧ください。

ログローテーション

ログローテーションスクリプトは、CoreappコンテナおよびWebappコンテナ内にパッケージ化されています。

Webapp

Webappコンテナ内のログローテーションスクリプトが行うことは、次のとおりです。

logrotateユーティリティを使います
ウェブログ、アクセスログ、エラーログの最新の30個のファイルを保持します
サイズが20MBを超える場合にのみローテーションします
ローテーションログファイルを圧縮します
古いログファイルを/var/log/whatsapp/archiveにアーカイブします

Coreapp

Coreappコンテナ内のログローテーションスクリプトが行うことは、次のとおりです。

社内スクリプトを使います
最新の30個のファイルを保持します
サイズが15MBを超えると、自動的にローテーションします
ローテーションログファイルを圧縮します
古いログファイルを/var/log/whatsapp/archiveにアーカイブします

Coreappにおいて新規ログファイルが作成されるのは、ログファイル1個当たりのサイズが15MBを超える場合のみです。古いログファイルは、自動的には削除されません。

クリーンアップスクリプトの推奨事項

Webapp、Coreapp、マスター(マルチコネクトセットアップの場合)のすべてのコンテナに対してログローテーションを実行するため、下記のクリーンアップスクリプトを定期的に(毎日など)実行することをおすすめします。ホスト上にcronjobを構成し、cronjobが実行中のすべてのWhatsApp Business APIコンテナに対して、ピーク時間を避けて実行されるようにすると最適です。クリーンアップスクリプトを定期的に呼び出すことで、ログファイルの使うディスクスペースを常に管理することができます。

docker exec your-container-name /opt/whatsapp/bin/cleanup.sh

詳しくはこちら

WhatsApp Businessプラットフォーム | クラウドAPI | オンプレミスAPI | ビジネス管理API