Contentsquareは、プラットフォーム内の多くのユースケースで通知機能を必要としていた。そこで同社は、マイクロサービス・アーキテクチャの一部として、複数のサービスにまたがる汎用的なソリューションを作成。この実装で、開発者はオブザーバビリティを改善し、スケーラビリティの課題を克服する必要があった。
Contentsquareの通知は、パスワードのリセットからAPIクォータの超過に関する重要なアラートまで、あらゆる用途に使用でき、ユーザーの好みに応じて、電子メール、Slack、Microsoft Teams経由で配信される。同社は、パフォーマンスとスケーラビリティの改善が必要になった場合に備えて、通知関連の機能を徐々に展開していくことを選択した。
通知コンポーネント（出典：Contentsquare Engineering Blog）
Contentsquareのプラットフォームはマイクロサービスアーキテクチャを活用しており、通知サブシステムは複数のマイクロサービスで構成されている。Notification Consumerは、Apache Kafkaトピックからのメッセージ処理を担う。Mailer Serviceは、メール通知の配信を処理し、EJSテンプレートエンジンを使用して、事前に設定されたテンプレートに基づいてメールコンテンツをレンダリングする。最後に、Integration ServiceはSlackとMicrosoft Teamsの通知を担当し、SlackのBlock KitまたはMicrosoft TeamsのAdaptive Cardsに基づいてJSONメッセージボディを構成する。Slack ServiceとMicrosoft Teams Service（下図）は、それぞれSlackまたはMicrosoft Teams APIへの通知メッセージの送信を担当する。
SlackとTeamsに通知を送るためのマイクロサービス（出典：Contentsquare Engineering Blog）
ContentsquareのソフトウェアエンジニアであるJoseph-Emmanuel Banzio氏は、通知機能を展開する際のチームの経験をこのように述べている。
私たちは、システムの信頼性を向上させるために、スケールを拡大する過程でいくつかのボトルネックに遭遇しました。注目すべき課題の1つは、Notificationsトピックを作成する前に、マイクロサービス間の通信に単一のKafkaトピックを使用していたことです。これは、リアルタイムアラートのベータ版を立ち上げる前まではうまく機能していました。
通知アラートに専用のKafkaトピックを使うことはもちろん、チームは通知ストレージを最適化し、読み込みのレイテンシーが高くならないようにした。古い通知レコードを削除するためのデータ保持メカニズムも実装した。調査が必要だったもう一つの問題は、一部のユーザーがメールを受信できないことだった。調査を重ねた結果、原因はSPF（Sender Policy Framework）の設定が正しくないことが判明し、セキュリティチームが対処した。
電子メール通知のトラブルシューティングを支援するため、チームは専用の電子メール観測ソリューションを作成。サードパーティの電子メールサービスによって収集された配信イベントを定期的に取得し、Contentsquareのプラットフォーム内に保存した。このアプローチにより、メール通知フローのエンドツーエンドの可視化が実現した。
ロールアウト中、開発者はプラットフォームのオブザーバビリティ向上にも取り組んだ。ログを監視・分析するKibanaダッシュボードと、通知マイクロサービスが使用するクラウドリソースを監視するGrafanaダッシュボードを作成した。さらに、チームは本番Kafkaクラスタのモニタリングを拡張し、リソースの利用率とコンシューマーグループの遅延が許容範囲内であることを確認した。今後、チームはシステム障害時の弾力性の追加に取り組み、ほぼリアルタイムの配信を達成するために、通知配信の適時性改善を計画している。