Zendeskのような単一のプラットフォームが、10万社を超える企業に、それらの企業が互いのデータを決して目にすることなく、同時にサービスを提供できるのか疑問に思ったことがあるなら、それはマルチテナンシーについて質問していることになります。このアーキテクチャパターンは、最新のSaaSのバックボーンであり、それを理解することで、ビジネスに適したソフトウェアを選択する際に、より良い意思決定を行うことができます。
Zendeskのマルチテナントアーキテクチャがどのように機能するのか、なぜそれが重要なのか、そしてそれがカスタマーサポート業務に何を意味するのかを詳しく見ていきましょう。
マルチテナントSaaSアーキテクチャとは？
マルチテナンシー（Multi-tenancy）とは、単一のソフトウェアインスタンスが複数の顧客（「テナント（tenant）」と呼ばれる）にサービスを提供するアーキテクチャアプローチです。アパートのようなものだと考えてください。誰もが同じ建物に住んでいますが、各アパートはプライベートで安全です。大家は建物を一度メンテナンスするだけで、すべての居住者が改善の恩恵を受けます。
マルチテナントSaaS環境では：
- 1つのコードベースがすべての人に対して実行されます アップデートは一度行われると、すべての顧客に同時に適用されます。
- データは論理的に分離されます 各テナントのデータは分離されており、他のテナントはアクセスできません。
- リソースは共有されます コンピューティング能力、ストレージ、ネットワーク容量はすべてのテナントにサービスを提供します。
- コストは分散されます インフラストラクチャの費用は、顧客ベース全体に分散されます。
これは、各顧客が個別のインフラストラクチャ上で実行されるソフトウェアの専用インスタンスを取得するシングルテナントアーキテクチャとは対照的です。シングルテナントのセットアップは、最大限の分離を提供しますが、コストと複雑さが大幅に高くなります。
マルチテナンシーが重要なのは、SaaSビジネスモデルを可能にするからです。それがなければ、クラウドソフトウェアはほとんどの企業にとって法外に高価になるでしょう。共有インフラストラクチャはコストを抑え、継続的なデプロイメントは、顧客が準備ができ次第改善を受けられることを意味します。
eesel AIでは、Zendeskのようなマルチテナントプラットフォームと統合して、チームが既存のインフラストラクチャからより多くのものを得られるように支援しています。当社のAIチームメイトは、お客様の情報を安全に保つために同じ分離原則を尊重しながら、ヘルプデスクデータから学習します。
Zendeskがマルチテナンシーを実装する方法
Zendeskは、大規模な規模で運営されています。このプラットフォームは、1日のピーク時に毎秒25万件のリクエストを処理し、世界中で10万社を超える企業にサービスを提供しています。このインフラストラクチャを構築および維持するには、いくつかの難しいエンジニアリング上の問題を解決する必要がありました。
技術的な基盤
ZendeskはRuby on Railsで構築されていますが、アーキテクチャは初期の頃から大幅に進化しています。エンジニアリングチームは、インフラストラクチャを「パーティション分割され、高度にシャーディングされている」と説明しています。これは、データとトラフィックが多数のサーバーに分散され、単一のポイントがボトルネックになるのを防ぐことを意味します。
同社はこれらの教訓を痛いほど学びました。Rackspaceのデータセンターでの初期の頃、1つの顧客に対するDDoS攻撃がすべての人に影響を与えました。その経験が彼らの「フェイル・スモール（fail small）」哲学を形作りました。何かが壊れた場合、可能な限り最小限の数の顧客に影響を与えるべきです。
設計による信頼性
Zendeskは、「トラブルフリー可用性（Trouble Free Availability）」を99.95%で測定しています。この指標には、サードパーティのサービス障害が含まれています。彼らは、いくつかのコア原則を通じてこれを実現しています。
コア機能は特別な扱いを受けます。 Zendeskは、特定の機能を非常に重要であると定義しており、それらを壊すことは製品全体がダウンしているのと同じです。チケットの作成が典型的な例です。顧客がチケットを作成できない場合、他の何が機能していても、Support製品は事実上利用できません。
あらゆるレベルでのパーティショニング。 インフラストラクチャは、AWSアベイラビリティーゾーンと同様のパーティショニングを使用します。1つのパーティションの障害が他のパーティションに漏れることはありません。これは、データベース、アプリケーションサーバー、およびネットワークセグメントに適用されます。
カオスエンジニアリング。 チームは、システムをテストするために意図的に障害を発生させる毎月の「ゲームデー」を実施します。自動修復が機能すること、および必要に応じてページングが発生することを確認します。
大規模なAIと機械学習
Zendeskのマルチテナンシーの最も興味深い側面の1つは、パーソナライズされた機械学習モデルをどのように処理するかです。顧客によってサポートチケットの意味が異なります。小売会社のチケットは、医療提供者のチケットとはまったく異なります。
Zendeskは、AWS SageMaker Multi-Model Endpoints（MME）を使用してこれを解決しました。顧客のAIモデルごとに個別のエンドポイントを実行する代わりに、数千のモデルを単一のエンドポイントにロードします。リクエストが届くと、システムはそれを適切なモデルにルーティングします。
このアプローチにより、専用エンドポイントと比較してコストが90%削減されました。トレードオフは、個々のモデル管理の制御が少なくなることですが、彼らのユースケース（推奨マクロ、インテント検出）では、節約する価値があります。
マルチテナントアーキテクチャパターン
すべてのマルチテナントアーキテクチャが同じではありません。選択するアプローチは、分離、カスタマイズ、およびコストの要件によって異なります。主なパターンは次の3つです。
シングルアプリケーション、シングルデータベース
これは最も簡単なアプローチです。すべてのテナントが同じアプリケーションコードベースとデータベースインスタンスを共有します。データ分離は、テナントID列を使用して行レベルで行われます。
メリット：
- 構築と保守が最も簡単
- インフラストラクチャコストが最も低い
- アップデートの最速デプロイメント
- 監視とデバッグが最も簡単
デメリット：
- テナントごとのカスタマイズが制限される
- 「うるさい隣人」のリスク（1つのテナントの過度の使用が他のテナントに影響を与える）
- 厳格なコンプライアンス要件を満たすのが難しい
- データベーススキーマの変更はすべての人に影響を与える
ほとんどのSaaSスタートアップは、迅速に動けるようにここから始めます。Zendeskは、より洗練されたパターンに進化する前に、このアプローチのバリエーションから始めた可能性があります。
複数のデータベース、1つのアプリケーション
このパターンでは、テナントはアプリケーション層を共有しますが、独自のデータベースを取得します。各データベースには、そのテナントのデータのみが含まれています。
メリット：
- より良いデータ分離
- コンプライアンス要件（GDPR、HIPAA）を満たすのが簡単
- 特定のテナントのニーズに合わせてデータベースを最適化できる
- 必要に応じて、単一のテナントを簡単に移行できる
デメリット：
- より複雑なデータベース管理
- スキーマ移行は多数のデータベースで実行する必要がある
- リソース使用率が低い
- 一貫したパフォーマンスを維持するのが難しい
このアプローチは、厳格なデータ要件を持つエンタープライズ顧客がいる場合に適していますが、運用上の複雑さが増します。
ハイブリッドおよび仮想モデル
最新のアーキテクチャでは、これらのアプローチを組み合わせて使用することがよくあります。コンテナ化と仮想化により、基盤となるインフラストラクチャを共有しながら、特定のテナント専用の環境を作成できます。
メリット：
- テナントごとの柔軟な分離レベル
- 専用リソースを備えた「プレミアム」層を提供できる
- コストとカスタマイズのバランスが取れている
- 多様なコンプライアンスニーズを満たすのが簡単
デメリット：
- 構築と運用が最も複雑
- 高度なオーケストレーションが必要
- 過剰にプロビジョニングすると高価になる可能性がある
Zendeskの現在のアーキテクチャには、3つのパターンのすべての要素が組み込まれている可能性があります。彼らのパーティショニング戦略は、ほとんどの顧客に対して論理的な分離を使用していることを示唆していますが、最大のエンタープライズアカウントに対して専用リソースを提供している可能性もあります。
カスタマーサポートにおけるマルチテナンシーのメリット
サポートプラットフォームを選択する場合、これらがなぜ重要なのでしょうか？マルチテナントアーキテクチャは、具体的なメリットをもたらします。
コスト効率。 共有インフラストラクチャは、顧客あたりのコストが低いことを意味します。Zendeskの価格は、Support Teamプランの場合、エージェント1人あたり月額19ドルから始まります。その価格帯は、インフラストラクチャコストが顧客ベース全体に分散されている場合にのみ可能です。
スケーラビリティ。 マルチテナントシステムは、比例的なインフラストラクチャの増加なしに新しい顧客を追加できます。新しいテナントはそれぞれ、同じ共有リソースを使用します。これが、SaaSプラットフォームが非常に急速に成長できる理由です。
より迅速なイノベーション。 単一のコードベースを使用すると、すべての顧客が新機能をすぐに利用できます。「バージョンアップグレード」を待ったり、移行を調整したりする必要はありません。ZendeskがAIエージェントの改善をリリースすると、すべての顧客が恩恵を受けます。
組み込みの信頼性。 マルチテナントアーキテクチャでは、設計上、冗長性とフェイルオーバーが必要です。テナントを分離するのと同じパーティショニングにより、単一障害点がサービス全体を停止させることも防ぎます。
AI/MLの実現。 最新のAI機能（検索拡張生成（RAG）など）は、マルチテナントアーキテクチャでより効果的に機能します。システムは、各テナントのデータをプライベートに保ちながら、すべてのテナントにわたるパターンを学習できます。これが、eesel AIがデータ境界を尊重しながら、パーソナライズされた支援を提供できる理由です。
課題とZendeskがそれらにどのように対処するか
マルチテナンシーには課題がないわけではありません。Zendeskが一般的な問題にどのように対処するかを次に示します。
「うるさい隣人」の問題
1つのテナントが異常な負荷を生成すると（たとえば、フラッシュセールによりサポートチケットが急増するなど）、同じインフラストラクチャ上の他のテナントのパフォーマンスに影響を与える可能性があります。
Zendeskは、以下を通じてこれに対処します。
- レート制限 単一のテナントがシステムを圧倒するのを防ぎます。
- リソースクォータ テナントごとのCPU、メモリ、およびデータベース接続の上限。
- パーティショニング 負荷の高いワークロードを特定のインフラストラクチャセグメントに分離します。
- 自動スケーリング 必要に応じて自動的に容量を追加します。
データ分離とセキュリティ
マルチテナンシーの最大の懸念事項は、テナントが互いのデータにアクセスできないようにすることです。テナント間でデータを漏洩させるバグは壊滅的です。
Zendeskのセキュリティ対策には、以下が含まれます。
- 行レベルのセキュリティ テナント境界のデータベースレベルでの強制。
- 厳格なアクセス制御 すべてのレイヤーでの認証と承認。
- 暗号化 保存時のAES-256暗号化、転送時のTLS 1.2+。
- 定期的な監査 SOC 2 Type II、ISO 27001、およびその他の認証。
- バグ報奨金プログラム 外部のセキュリティ研究者がシステムをテストします。
彼らのトラストセンターには、政府機関の顧客向けのFedRAMP認証や医療機関向けのHIPAAコンプライアンスなど、これらの対策が詳しく記載されています。
カスタマイズ vs. 標準化
すべてのテナントは、サポートエクスペリエンスを自社のブランドに合わせたいと考えています。ただし、無制限のカスタマイズを許可すると、コードベースが保守できなくなります。
Zendeskのアプローチは、コードのカスタマイズではなく、広範な構成です。
- カスタムチケットフィールドとフォーム
- 構成可能なワークフローと自動化
- テーマ可能なヘルプセンター
- 統合のためのアプリマーケットプレイス
- カスタム開発のためのAPIアクセス
これにより、数千もの一意のコードブランチを維持する複雑さなしに、顧客に柔軟性を提供します。
コンプライアンス要件
業界が異なれば、データの取り扱いに関する要件も異なります。医療機関にはHIPAAが必要です。ヨーロッパの企業にはGDPRコンプライアンスが必要です。金融サービスには独自の規制があります。
Zendeskは以下を提供します。
- データ所在地オプション データの保存場所を選択します（米国、EU、オーストラリア、日本）。
- HIPAAコンプライアンス ビジネスアソシエイト契約およびAdvanced Complianceアドオンで利用可能。
- GDPRサポート データ処理契約、削除権、データポータビリティ。
- 監査ログ すべてのアカウント変更を追跡します（エンタープライズプラン）。
マルチテナントとシングルテナントのサポートソリューションの選択
ほとんどの企業は、カスタマーサポートにマルチテナントSaaSを選択する必要があります。各アプローチが理にかなっているのは次の場合です。
次の場合にマルチテナントを選択します。
- より低いコストとより迅速なデプロイメントを希望する場合
- 標準機能がニーズを満たしている場合
- 継続的なアップデートと改善を重視する場合
- 専用のDevOpsリソースがない場合
- 迅速にスケールする必要がある場合
次の場合にシングルテナントを検討します。
- SaaSでは満たせない厳格なデータ所在地要件がある場合
- コードレベルでの深いカスタマイズが必要な場合
- 専用インフラストラクチャを管理するリソースがある場合
- 規制要件で共有環境が禁止されている場合
大多数の企業にとって、Zendeskのようなマルチテナントプラットフォームは、機能、コスト、および信頼性の最適なバランスを提供します。Zendeskを使用している10万社を超える企業には、厳格なセキュリティ要件を持つ企業が含まれており、最新のマルチテナントアーキテクチャがほとんどのコンプライアンスニーズを満たすことができることを示唆しています。
AIでマルチテナントサポートプラットフォームを強化したい場合は、eesel AIがZendeskと統合して、同じセキュリティと分離原則を尊重しながら、自律的なチケット解決を提供します。
マルチテナントカスタマーサポートの開始
サポートプラットフォームを評価している場合、またはマルチテナントSaaSへの移行を検討している場合は、次の実用的なアプローチをお勧めします。
要件を評価します。 スケール、コンプライアンスニーズ、およびカスタマイズ要件を正直に評価することから始めます。ほとんどのチームは、実際に必要なカスタマイズの量を過大評価しています。
実績のあるプラットフォームを検討します。 Zendeskのマルチテナントアーキテクチャは、大規模な規模で実証されています。99.95%の可用性目標と包括的なコンプライアンス認証により、ほとんどの企業にとって安全な選択肢となっています。
AIチームメイトを検討します。 eesel AIのような最新のAIツールは、マルチテナント環境内で動作し、ルーチンサポートタスクを自動化します。当社のAIは、既存のチケットとヘルプセンターから学習し、応答を起草したり、チケットを自律的に解決したりします。
移行を計画します。 シングルテナントまたはオンプレミスソフトウェアから移行する場合は、段階的な移行を計画します。パイロットチームから始めて、結果を測定し、徐々に拡大します。
小さく始めて、反復処理します。 初日にすべての機能を実装する必要はありません。コアチケットから始めて、チャネル（チャット、音声）を追加し、チームが慣れてきたらAIと自動化を重ねます。
マルチテナントSaaSは、セルフホストの代替製品よりも優れた価値、信頼性、およびイノベーションを提供するため、カスタマーサポートソフトウェアのデフォルトの選択肢となっています。その仕組みを理解することで、情報に基づいた意思決定を行い、投資を最大限に活用できます。
