New Relicを使用したマルチテナントSaaSアプリケーションの監視

サービスとしてのソフトウェア（SaaS）ビジネスの多くは、コストと運用オーバーヘッドを管理しやすくするためにマルチテナントアーキテクチャーを活用しています。マルチテナントアーキテクチャーとは、ソフトウェアのシングルインスタンスがマルチテナントのワークロードを処理するものです。実際には、テナントは顧客であることが多いですが、ワークロードを分割したままの状態にするのに合理的な他の境界である場合もあります。マルチテナントアーキテクチャーには、サポートおよび保守するサービスインスタンスが少なくて済むなどの運用上の利点がありますが、多くの課題もあります。これらのシステムを正常に運用するには、テナントの使用状況を理解し、運用上の問題を診断する適切な監視機能を持つことが重要です。

マルチテナントシステムの運用面での課題は何ですか?

うるさい隣人の問題

マルチテナントシステムの共有性質により、1つのテナントの動作がシステム全体のパフォーマンスに影響を与え、ひいては他のテナントにも影響を与える場合があります。これらの問題を軽減できる設計手法はありますが、必ず発生します。これらの問題を迅速に診断できることは、問題のない顧客のサービスを回復し、サービスレベル契約（SLA）の目標を達成する上で最も重要です。

このようにして現れる一般的な問題には、異常に大量のトラフィックを送信するテナント、異常なエラー状態を引き起こすテナント操作、予期しない方法でリソースを消費するその他の異常なテナント動作などがあります。テナント識別子によってテレメトリーデータをファセット化できるため、オペレーターはこの種の問題を迅速に特定し、措置を講じることができます。

たとえば、遅いリクエストがスレッドを占有するためにスレッドプールが枯渇しているサーバーアプリケーションを考えてみましょう。New Relic APMエクスペリエンスでは、次のようなものが表示される場合があります。

遅いリクエストが多く、実行可能なスレッドがほとんどないことがわかります。

この問題の原因は何ですか？

ソリューション

1. アプリケーションにカスタムインストゥルメンテーションを追加します。1つのアプローチは、New Relic Javaエージェントを使用してAPMトランザクションイベントにカスタムアトリビュートを追加することです。これは次のようになります

カスタムアトリビュートをテレメトリーに追加する方法の詳細については、こちらをご覧ください。

2.   更新されたアプリケーションをデプロイします

3.   Query Builderや、Errors Inboxや分散トレーシングUIなどのカスタムアトリビュートによる表示やフィルタリングを可能にする、その他のNew Relic機能でデータを探索します

4.    オプションで、カスタムクエリ用のダッシュボードを作成して、後で簡単に参照できるようにすることができます。ベストプラクティスは、このようなダッシュボードを作成し、サービスランブックからリンクすることです。ダッシュボード構築の詳細については、こちらをご覧ください

必要なインストゥルメンテーションができたので、次のようなクエリを作成すると、特定のテナントが大量の作業バッチを送信し、それが多くのスレッドを拘束し、アプリケーションの本来あるべき応答性を妨げていることがわかります。

テナントによる操作を追跡するメトリクスを作成することも可能です。メトリクスはイベントのようにサンプリングされないため、特定の種類のクエリがより精度の高い結果になるという重要な利点があります。当社のAPMおよびモバイルエージェントは、カスタムメトリックの作成をサポートします。それに関するドキュメントはこちらをご覧ください。もう1つのオプションは、New RelicメトリクスAPIを使用して、テナントIDとその他の重要なテナント属性をディメンションとして持つディメンションメトリクスを作成することです。

メトリクスを作成するときに考慮すべき重要な点は、作成するデータセットのカーディナリティの制限です。カーディナリティは通常、セット内の固有の要素の数として定義されます。つまり、このブログ記事のコンテキストでは、メトリクスを作成できるテナントIDの数に制限があります。これが問題となる場合、1つのアプローチは、一定の閾値を超えるテナントに対してメトリクスの作成を制限することです。メトリクスのカーディナリティに関連する概念をより深く理解するには、こちらで詳細情報を参照してください。カーディナリティ制限の現在の制限を確認するには、このドキュメントを参照してください。

うるさい隣人の問題について詳しくは、こちらをご覧ください。

エンドユーザーの診断以外の問題

同様に、当社のブラウザ、モバイル、APM機能はテレメトリーへのユーザーIDの追加をサポートしているため、上記システムのテナント使用に関する問題を診断したのと同じ方法で、個々のユーザーによって引き起こされた問題を追跡できます。たとえば、BrowserエージェントAPIのsetUserId関数を使用して、エンドユーザーの識別子をJavaScriptErrorイベントなどのテレメトリーデータに追加できます。このイベント属性は、エラーのユーザーへの影響を追跡するErrors Inboxの機能などの機能を強化します。

エラー原因の診断

テナントIDを追跡するインストゥルメンテーションを追加したので、New RelicのErrors Inboxを利用して、テナントの動作がシステム内のエラー原因となっているかどうかを判断できます。Errors Inboxは、アプリケーション内のエラーを優先順位付けするための強力なツールです。非常に便利な機能の1つは属性プロファイル機能です。この機能には、エラーグループの詳細を表示する際に、プロファイルの表示ボタンをクリックするとアクセスできます。次のようなプロファイルは、シングルテナントが不釣り合いな数のエラーを引き起こしていることを示しており、さらなる調査が必要です。

一方、「その他」の割合が非常に高い場合は、テナントの動作がエラー原因である可能性を除外できます。

リソース使用率の理解

どのテナントがリソースを消費し、サービスの提供コストに影響を与えていますか？Amazon Elastic Container ServiceやKubernetesなどのコンテナオーケストレーションシステムの人気の高まりに伴い、アプリケーションの負荷の変動に応じてスケールアップ/スケールダウンを処理するための、自動スケーリング設定が非常に一般的になってきています。ただし、クラウドではスケーリングには経済的なコストがかかるため、どの顧客の行動がスケールアウトイベントのコストを引き起こしているかを診断できることが重要です。この情報を使用すると、適切なシステム制限を設定したり、ビジネスモデルを調整したりして、ビジネスにかかるコストが生み出している収益と一致していることを確認できます。

上記の手法を利用して、サービスをインストゥルメントし、顧客の使用パターンを評価するのに役立つクエリを構築できます。たとえば、次のようなクエリは、クエリAPIエンドポイントの特定のセットに対するスループットのスパイクがどこから発生しているかを診断するのに役立ちます。

次のクエリは、別のサービスのバッチ処理リソースを各顧客にどの程度割り当てることができるかを示します。

ベストプラクティスは、うるさい隣人の問題を軽減するだけでなく、企業が従量課金制モデルを利用していない分野のコストを制御するために、テナントの使用制限を実装できることです。制限を調整し、顧客の使用状況への影響を評価するには、上記のテレメトリーが非常に役立つことがわかります。

まとめ

この記事では、テレメトリーデータを強化し、New Relicの力を活用してマルチテナントソフトウェアシステムの機能に関するインサイトを得るための、シンプルかつ強力なテクニックを説明しました。テナントIDによってテレメトリーをファセットする機能は、うるさい隣人の問題をデバッグしたり、顧客の使用パターンを把握しようとしているオペレーターにとって不可欠なツールとなります。これらのインサイトを使用すると、オペレーターはインシデントの影響を最小限に抑えるだけでなく、システムを改善して、運用のパフォーマンス、回復力、コスト効率を向上させることができます。New Relicは、テナントデータを取得して分析するための強力なツールを提供します。実際、当社は自社のビジネス運営に毎日使用しています。