はじめに
本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day22 の記事です。 弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。
弊社でのインシデント対応を直接お見せすることは難しいですが、マルチテナントSaaSにおいて、抑えるべきポイントをいくつかご紹介できればと思います。
テナント識別可能なアラートの仕組みを用意する
アラートはいわゆるメトリクス監視系のアラートを用意することになるでしょう。ここは基本的には一般的なプラクティス通りなので、割愛しますが、AWSでいえば推奨のアラートを公式が用意しているため、こちらを活用すればよいでしょう。
さてマルチテナントという観点では、テナント識別をできる状態にしておくことが重要になります。単一のアラートだけでは「どのテナントで問題が発生しているのか」を特定するために追加の調査が必要となり、初動対応が遅れる原因となります。
Qastにおいては、エラーについてSlackで通知するよう設定していることを、Day 19で紹介しました。
また、サブドメインで分割されているため、どのテナントでエラーが発生しているかをDatadog APMを利用することで、フィルタリング/集計することができます。これにより、エラー発生時にどのテナントが影響を受けているかを即座に把握でき、迅速な対応につながります。
さらに、テナント識別が可能な監視体制を構築することで、
- 特定テナントのみに影響するパフォーマンス劣化を早期発見できる
- テナント別のエラー率やレイテンシをトラッキングし、傾向分析が可能になる
- 大口顧客など、ビジネスインパクトの大きいテナントを重点的に監視できる
といったメリットを得ることができます💪
顧客の影響範囲を明確にする
全テナントへ影響が発生するような事象も発生しますが、マルチテナントSaaSにおいては、特定のテナントでのみ発生する場合があります。先ほど紹介したように、「どのテナントで影響があったか」を明確にする必要が生じます。
インシデント発生時点でオンライン/オフライン問わず、カスタマーサクセスの部門などでは、コミュニケーションが発生している場合もあり、適切なフォローを入れるかを判断することが必要になることもあります。
特にチャットサポート時間帯にインシデントが発生した場合、リアルタイムで顧客からの問い合わせが入る可能性が高く、カスタマーサクセスやサポートチームへの迅速な情報共有が求められます。また、SLAなどを締結している場合は、契約上の義務として影響範囲の報告や補償の検討など、ビジネスサイド側にも即座に情報を連携する必要があります。
インシデント振り返りをする
発生したインシデントに対して、振り返りを行うこと、いわゆるポストモーテムを実施することも重要でしょう。ポストモーテムの目的は、誰かを責めることではなく、組織として同じ問題を繰り返さないための学びを得ることにあります。
実際フォーマットも世の中には多く存在しており、下記のような解説記事を参考にしてみることもおすすめです。
さて、マルチテナントSaaSにおけるポストモーテムでは、特に以下の点を意識して振り返りを行うとよいでしょう。
テナント依存の問題かシステム全体の問題か
特定のテナントのデータ量や利用パターンに起因する問題なのか、システム全体の設計に起因する問題なのかを明確にします。前者であれば、テナントごとのリソース制限やクォータの見直しが必要かもしれません。後者であれば、アーキテクチャレベルでの改善が必要になるでしょう。
検知から復旧までのタイムライン
どの時点で問題が発生し、いつ検知され、どのように対応が進んだかを時系列で整理します。特にマルチテナント環境では、「最初に影響を受けたテナント」と「最後に復旧したテナント」の間にタイムラグがある場合もあり、その理由を明確にすることが重要です。
影響範囲の特定プロセス
どのようにして影響を受けたテナントを特定したか、そのプロセスに改善の余地はなかったかを振り返ります。テナント識別の仕組みが機能したか、追加で必要な監視項目はないかなどを検討します。
さいごに
テナントを識別できる状態をつくることで、マルチテナントSaaSにおけるインシデント対応の調査のしやすさは大きく異なります。もちろんインシデントをゼロにすることはできません。どれだけ注意深く開発・運用していても、予期せぬ問題は必ず発生します。
しかしながら、振り返りを実施し、次の改善につなげることで、より強靭なシステムとチームを作り上げていきましょう。