多くのチームは、速さを理由にマネージドな RTC または IM サービスから始めます。問題はパブリッククラウドが優れているかどうか(多くの場合優れています)ではなく、データ要件、利用量、統合ニーズが大きくなるにつれて、その提供モデルが適合し続けるかどうかです。
本記事は結論ではなく、比較の方法を提示します。エンジニアリング、財務、セキュリティに対して意思決定を説明する立場のチームの視点で書いています。
2つの提供モデルであり、2つの製品ではない
意味のある比較は、提供モデルの間で行います。
- マネージドサービス:プロバイダーがインフラを運用し、利用者は API と従量課金のキャパシティを利用します。得られるのはスピード、柔軟なスケーリング、成熟したグローバルな拠点です。
- プライベートデプロイ:SDK ベースのソフトウェアを自社環境で運用します。得られるのはデータ管理、カスタマイズ、異なるコスト構造であり、その代わりに運用を引き受けます。
機能一覧は同じモデル内でもベンダーごとに異なります。まずモデルを比較し、次に選択したモデルの中でベンダーを絞り込みます。
見落としやすいコスト項目
従量課金の価格は目に見えます。それ以外は、2年目になるまで見えないことが少なくありません。
| コスト項目 | マネージドサービス | プライベートデプロイ |
|---|---|---|
| コンピュートとネットワーク | 従量課金に含まれる | インフラ、帯域、予約キャパシティ |
| ストレージと保持 | 従量制のストレージ、エグレス課金 | 自社が保有するストレージハードウェアまたはクラウドストレージ |
| エンジニアリング | 統合と設定 | 統合、デプロイ、アップグレード、オンコール |
| 運用 | ベンダーのサポート階層込みで提供 | 監視、キャパシティプランニング、パッチ管理 |
| コンプライアンスと監査 | プロバイダーの証明、責任分界 | 自社の統制、自社の証跡 |
| 切り替えコスト | API/データの移行、再統合 | 他プラットフォームへの移行または撤退 |
さらに2つの項目に注意が必要です。
- エンジニアリング時間は実際のコストです。 プライベートデプロイは一度きりのインストールではなく、所有者を必要とするシステムです。
- 柔軟なスケーリングには価値があります。 ピーク負荷に備えた過剰なプロビジョニングは、ハードウェアが遊んでいる間もコストです。
シンプルな TCO モデル
N か月という定義された期間について、次のように計算します。
- ピーク時と平均の同時接続数、およびストレージの増加を見積もります。
- マネージドサービスを N か月分で価格化します。サポートとエグレスを含めます。
- プライベート案のインフラを価格化します。コンピュート、ストレージ、帯域、ライセンス、現実的な人員配分。
- 双方に統合作業を加えます。
- 双方に移行または撤退のための余裕を加えます。
出力が桁違いに優位な単一の数値になることはまれです。多くの場合、モデルは交差します。マネージドサービスは利用量が少なく変動が大きい場合に安価であり、プライベートデプロイは利用が安定し、大規模で、長期にわたる場合に競争力を持ちます。さらに、コンプライアンス要件がすでにプライベートな環境を強制している場合も同様です。
明示的な前提と感度分析の範囲を用います。単一の点推定による比較は、意思決定ではなく議論を招きます。
データ主権:要件か、選好か
「主権」という言葉はしばしば曖昧に使われます。次の問いに答えることで具体化します。
- どのデータ分類が、どの法域またはネットワークに留まる必要があるか。会議メディア、メッセージ内容、メタデータ、バックアップ、ログは、それぞれ答えが異なる場合があります。
- 誰が、誰の承認のもとでデータにアクセスできなければならないか。
- 監査人に対して何を、どの形式で証明できなければならないか。
- サポート時に何が起きるか。ベンダーのエンジニアはデータにアクセスできるのか、そのアクセスはどのように記録されるのか。
マネージドサービスは、リージョン別のホスティングと契約上のコミットメントによって多くの要件を満たせます。プライベートデプロイがより強い選択肢となるのは、要件が絶対的な場合です。つまり、データを組織が管理しないインフラに置けず、パブリックインターネットを一切経由できない場合です。
実務における責任分界
マネージドサービスでは、プロバイダーがプラットフォームを保護し、利用者が設定、ID、データ利用を保護します。プライベートデプロイでは、ほぼすべてが自社の責任です。この移行は運用モデルを変えます。
- セキュリティアドバイザリは誰が受け取り、誰がパッチを適用するのか。
- メディアやメッセージの停止に対するインシデント対応の責任者は誰か。
- バックアップはどのようにテストされ、誰がリストアするのか。
- 監査時にどのような証跡を提示できるのか。
これらの答えがまだ存在しない場合、プライベート案は安価なのではなく、未完成です。
判断フレームワーク
次の多くが当てはまる場合は、プライベートデプロイを検討します。
- データの配置が選好ではなく厳格な要件である。
- 利用量が安定しており、自社運用の単位経済性が魅力的な規模である。
- メッセージモデル、シグナリング、権限ロジックをカスタマイズする必要がある。
- インフラと運用の能力がある、またはそれを持つパートナーがいる。
- システムが戦略的であり、そのライフサイクルを所有することを正当化できる。
次の多くが当てはまる場合は、マネージドサービスを検討します。
- 製品を素早く検証する必要がある。
- 利用量が少ない、または変動が非常に大きい。
- メディアやメッセージングのインフラ運用に意欲がない。
- グローバルなアクセスとベンダー運用の信頼性を優先する。
- データを許容可能な契約条件と地域条件のもとでホストできる。
契約と撤退の考慮事項
どちらのモデルを選ぶ場合でも、必要になる前に撤退条件を交渉します。
- データのエクスポート形式と期間。
- 予告期間と移行中のサポート。
- 提供される場合のライセンス移転またはソースエスクロー。
- マネージドサービスの場合、エグレス価格とデータ削除の確認。
まとめ
パブリッククラウドの RTC と IM は、最初の選択として適切であることがよくあります。誤りは、その選択を恒久的なものとみなし、要件が変わっても見直さないことです。簡潔で明示的な TCO と主権の評価を年に一度更新するほうが、一度きりの議論よりも有用です。
FeiyanCloud はプライベートデプロイ可能な SDK を提供しているため、どうしても偏りがあります。それでも、この比較を正直に実施することをお勧めします。マネージドサービスのほうが制約に適しているなら、それが正解です。
「Coming soon」または「Roadmap」と表示された機能は、現在のリリースではご利用いただけません。製品の機能と提供状況は、正式なリリースノートに基づきます。