プッシュ通知は、モバイル アプリを持つすべての人にとって重要なマーケティング ツールです。
緊急メッセージを携帯電話に送信して、ユーザーと通信するための最良の方法です。
モバイル アプリは、ユーザーにプッシュ通知を送信できます。これは、アプリが開いていなくてもスマートフォンに表示される短いポップアップ メッセージです。
これらのアラートには、リマインダー、更新、割引などを含めることができます。
ユーザーの目を引くように作成されています。 タイトル、メッセージ、画像、および URL はすべて、プッシュ通知の可能なコンポーネントです。 絵文字、ロゴ、その他のものもそれらの一部にすることができます.
Apple OS や Google Android などのオペレーティング システムには、プッシュ通知用のさまざまなインターフェイスがあります。
プッシュ通知は、エンゲージメントの促進、アプリの使用率の向上、コンバージョンへの影響などに使用できます。
オプションは本当に無限です。
モバイル デバイスのプッシュ通知 (モバイル デバイスのプッシュ通知とも呼ばれます) は、電子メール、SMS、オンライン プッシュ通知などのチャネルの使用を多くの特別な利点で補うことができます。
この投稿では、通知サービスの簡単な説明と、その目的、高レベルの設計、特別な機能などに関する情報を受け取ります。
DevOps Tools Engineer試験のObjective
製品からユーザーへのメッセージをさまざまなチャネルで効率的に配信できる通知サービスを開発する
要件:
- Sending API: 認可されたエンドポイントを発行して、バックエンドとマイクロサービスが通知の配信を開始できるようにします。
- 互換性のあるチャネル: メール、テキスト メッセージ、プッシュなど、API を発行するチャネルへのアラートの配信をサポートします。
- ユーザーの設定: ユーザーが各チャネルと通知のユーザー設定を選択できるようにします。
- ダウンストリーム サービスのコンプライアンスに関する制限: email または SMS サービスが調整または停止されました。
- スケーラブル: (理論上) 無限の水平スケーリングを許可します。
高レベルのアーキテクチャ
あなたのコードが誰かに通知することになっているとしましょう:
- POST /send エンドポイントは、コードによって呼び出されます。 利用可能なチャネルごとに、要求には受信者の userId、通知のタイプ、およびその内容が含まれます。
- OAuth2 Client Credentials Flow は、リクエストを認証するために /send エンドポイントによって使用されます。
- 次に、ユーザーの通知選択がデータベースから要求されます。 プリファレンスは、ユーザーが特定のチャネルと通知を購読しているかどうかを示します。
- データベースから、メールアドレスや電話番号などのユーザーの特徴を読み取ります。
- このエンドポイントは、ユーザーの特性、チャネル、およびチャネル固有のコンテンツを含むメッセージ オブジェクトを作成します。 ただし、非アクティブ化されたチャネルは含まれません。 その後、メッセージはファンアウト サービスに配信されます。
- 着信メッセージは、ファンアウト サービスを介してジョブ キューに配布されます。 ただし、メッセージで指定されていないチャネルのジョブ キューを無視するために、フィルタリングが行われます。
- 各チャネルには、プロセッサとワーク キューがあります。 プロセッサはタスクを実行し、トランザクション メールや SMS サービスなどの適切なサービスを要求します。
主要なアーキテクチャ要素
投稿/送信済み
お気づきかもしれませんが、このエンドポイントへのリクエストには、userId のみが含まれており、電子メール アドレスも電話番号も含まれていません。 これにより、通知サービスをユーザーに対して匿名のままにすることができます。
スケーラビリティを確保するために、エンドポイントは ロードバランサ.
通常のユーザー向け認証では、エンドポイントを保護できません。
要求を送信するサービスはソフトウェア自体であるため、サーバー間通信に使用される OAuth2 クライアント資格情報フローと呼ばれる個別の認証方法を利用する必要があります。
アプリケーションは、さまざまな場所で通知を提供します。 send 関数は、ロードバランサーの背後にあるエンドポイントとして実装することで、新しいコードベースやビルド ワークフローなど、ほぼどこでも利用できます。これにより、独立してスケーラブルであることが保証されます。
PUT/ユーザー設定
非常にスケーラブルなキーと値のペアまたは NoSQL データベースを使用します。 レコードを次のようにフォーマットします: KEY: サンプル ユーザー ID: サンプル通知 ID、値: ["email", "state: true," "SMS", "state: false," channel: "email", "email", state : 真実
レコードに「偽」の値が存在する場合、送信エンドポイントは、ファンアウトに配信されるメッセージから対応するチャネルを除外します。 チャネルのレコードがない場合、ユーザーは自分の好みを明示的に示していません。 このシナリオではデフォルトに同意する必要があります。
ユーザーは、UI と、標準の認証手順によって保護された通常のエンドポイントを使用して、ユーザー設定データベースのデータを変更できます。
通知設定を変更するオプションを提供しないと、ユーザーはイライラし、アラートをスパムとして指定するか、サイレントにする必要があります。 その結果、ユーザー エクスペリエンスがさらに損なわれ、電子メールまたは SMS 配信サービスがアカウントを停止する可能性があります。
扇形に広がります
ファンアウトはメッセージをコピーし、別の場所に配布します。 手頃な価格で非常にスケーラブルです。 AWS で SNS を使用します。 Azure で Pub/Sub を使用し、Google Cloud Platform でトピックとサブスクリプションを使用します。
除外されたチャネル ジョブ キューに無意味なメッセージが送信されるのを防ぐために、ファンアウト キューとワーク キューの間のフィルタリングを構成できます。 たとえば、AWS SNS では、「channels」フィールドに「email」値がある場合にのみ、E メール ジョブ キューがファンアウト メッセージを取得するように指定できます。
必要なジョブ キューに同じメッセージを送信するコードを作成できたとしても、ファンアウトの方が効率的であり、必要なコーディングも少なくて済みます。 ファンアウトは、キューを追加および削除する便利さも提供し、チャネルを拡張および再編成できるようにします。
ジョブ処理
メッセージは、ジョブ プロセッサによる処理待ちのキューに格納されます。 また、手頃な価格で非常にスケーラブルです。 ジョブ プロセッサは、ジョブ キューからのメッセージを処理するコードです。 キュー内のメッセージの量に応じて、スケーリングできます。
ジョブ プロセッサは、適切なプロバイダーに対して API 呼び出しを行い、トランザクション メール サービスを介してこのシナリオで通知を配信する必要があります。
電子メール、SMS、および同様のメッセージ配信プロバイダーの大半は、送信するメッセージの量と能力について厳しい要件を設けています。 さらに、これらを検討し、適切な手順を徹底的に設定する必要があります。 AWS SES からの終了を回避する方法についてのアドバイスを次に示します。
ジョブ プロセッサの最大数を定義して、配信サービスのレート キャップを超えないようにすることができます。
さらなる改善
これらのアイテムの束を一目で見ることができます。
- スケーラブルなアプリ内通知サービスを提供するには、独自の API やテーブルなどが必要です。
- 開封/クリック レポートの収集と表示
- コードから通知の内容を削除し、製品および設計チームがコードを変更せずにアラートを視覚的に変更できるようにする
- コードを変更することなく、チームはダッシュボードを使用して特定のチャネルの通知を有効または無効にすることができます。
プッシュ通知のメリット
- ユーザー インタラクションの向上: 更新や新鮮な素材は、ユーザーの関心を維持します。
- コミュニケーションの可視性を高める: 人々がアクティブでないときでも、メッセージがすぐに受信されるようにします。 緊急の通知を送信し、ユーザーにスムーズなエクスペリエンスを提供します。
- リテンションを維持する: はっきりと見えるプッシュ通知を使用して、ユーザーが戻ってくるよう促します。 顧客をウェブサイトやアプリに呼び戻すことで、ユーザーの維持率を高め、チャーンを減らすことができます。
- コンバージョンの強化: アプリ内の特典、プロモーション、割引、またはその他の提供物に関するプッシュ キャンペーンを作成することで、売り上げを伸ばすことができます。
- 企業の規模を拡大する: コミュニケーション アプローチは、対象者の拡大に合わせて拡大する必要があります。 顧客ベースが拡大するにつれて、プッシュ通知は顧客と連絡を取り合うための効果的な方法です。
- ユーザー エクスペリエンスをつなげる (UX): トランザクション アラートを消費者に提供して情報を提供し、スムーズなクロスチャネル エクスペリエンスを提供することで、カスタマー ジャーニー全体の摩擦を減らすことができます。
まとめ
結論として、スケーラブルなプッシュ通知サービスのアーキテクチャに関する知識を得ました。 また、すべての主要なクラウド サービス プロバイダーが提供するツールを調べて、これらに基づいて通知できるようにしました。
プッシュ通知システム アーキテクチャの概要を説明するために最善を尽くしましたが、舞台裏ではさらに多くのことが行われています。
この情報がお役に立てば幸いです。
コメントを残す