← エピソード一覧に戻る Episode 163 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 売れているのに遅くなる罠
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発で地味に見えてかなり危険な論点、ノイジーネイバー対策を扱います。ある顧客の重い使い方が、別の顧客の画面や API を遅くしてしまう、共有基盤ならではの問題です。
ミカ
ミカです。ノイジーネイバーって、すごく大口の顧客が暴れると起きる問題だと思っていました。でもそれだけじゃないんですか。
タカシ
そこが誤解されやすい点です。Microsoft は、1 社の突出負荷だけでなく、複数テナントの普通のピークが重なっても全体容量を超えると説明しています。つまり顧客数が順調に増えた結果としても起こるんです。
ミカ
えっ、それは怖いですね。成長しているからこそ起きる渋滞ということか。単なる性能問題ではなく、成功したときの設計問題なんですね。
Chapter 2 基本 ― ノイジーネイバーは商品設計の問題
タカシ
ノイジーネイバー対策をサーバー増強の話だけで終わらせると失敗します。Microsoft のガイドは、非同期化、クエリ制限、QoS、上位 tier への誘導、単一テナント化まで選択肢に入れています。つまり何を標準で共有し、どこから別料金で分けるかを決める商品設計なんです。
ミカ
なるほど。エンジニアが裏で頑張るだけではなくて、営業が売るプランや利用条件まで一緒に決めないといけないんですね。
タカシ
その通りです。Azure OpenAI のマルチテナント設計でも、共有インスタンスは実装しやすい一方で性能分離が弱く、テナントごとの token usage を追跡して quota と課金を管理すべきだとされています。負荷を測れない SaaS は、公平な料金も公平な保証も作れません。
ミカ
たしかに、誰が混雑を作っているか見えないと、静かな顧客まで同じ値段で我慢させることになりますね。それは不満がたまりそうです。
タカシ
まさにそこです。ノイジーネイバー対策は SLA を守るためだけでなく、上位プランに何を載せるかを明確にするためにも必要です。売るべき価値は高性能そのものより、他社影響を受けにくい予測可能性なんです。
Chapter 3 具体例 ― 429とキューは経営メッセージになる
ミカ
実務のイメージをもっと持ちたいです。実際の SaaS はどうやって守っているんでしょう。やっぱり全部の顧客を一気に止めるんですか。
タカシ
分かりやすいのが Dynamics 365 Business Central です。Microsoft は共有 IO、CPU、メモリを守るため rate limits をかけ、制限超過時は 429 を返し、長時間処理は 10 分で 504 にすると明示しています。全部受けるより、無理な使い方には待ってもらう方が全体品質を守れるわけです。
ミカ
429 ってエラーというより、共有基盤を守るための交通整理なんですね。使う側にも設計の前提を理解してもらう必要があるなあ。
タカシ
そうです。しかも retry を雑に増やすと逆効果になります。大量同期や重い集計を同期 API のまま残すと、渋滞にクラクションを足すようなものです。だから非同期ジョブ化やバッチ化まで含めて設計し直す必要があります。
ミカ
クラクションを足す、分かりやすいです。ユーザーが急いでいるほど、裏側は落ち着いて順番待ちさせないといけないんですね。
Chapter 4 具体例 ― 静かな顧客を先に守る設計
タカシ
もう一つ面白い例が Snowflake です。公式 docs では、同時クエリが多すぎると warehouse に queue が発生し、待ち時間が伸びると説明しています。その対策として、重い workload を別 warehouse に分けるか、multi-cluster warehouse で需要急増時に追加 cluster を自動起動する方法を示しています。
ミカ
しかも cluster を増やすかどうかでコストも変わりますよね。そこはどう考えるんですか。
タカシ
Snowflake はそこも明確で、Standard policy は queue を減らすため追加 cluster を優先し、Economy policy は credits 節約を優先して多少の待ちを許容します。つまり応答保証を売るのか、粗利を守るのかを設定で選んでいる。SaaS のプラン設計そのものですね。
ミカ
同じ機能でも、待たせない保証にお金を払ってもらう発想なんだ。高いプランに何を載せるかが、かなり具体的に見えてきます。
タカシ
AWS の SQS fair queues も示唆的です。1 テナントが backlog を作っても、静かなテナントの dwell time を守るために他の tenant の message を優先返却します。全部を一律制限するのではなく、静かな顧客体験を先に守る公平性制御が価値になるんです。
ミカ
なるほど、うるさい顧客を罰するというより、巻き添えを減らす設計なんですね。たしかにその方が解約を防げそうです。
Chapter 5 クロージング ― プランと隔離レベルを結びつける
ミカ
明日からやるなら、まずテナント別の遅延、エラー率、429 の発生数、重い処理の種類を見える化したいです。誰がどんな渋滞を作っているか分からないと、対策も課金も決められませんね。
タカシ
その上で、重い集計やエクスポートは同期 API から外し、非同期ジョブへ寄せること。さらに、共有標準、優先制御あり、専用リソースあり、くらいの三段階でプランと隔離レベルを対応付けると経営判断がしやすくなります。
ミカ
ノイジーネイバー対策って、裏側の苦労話ではなく、どの顧客にどんな約束をするかを決める仕事なんですね。SaaS の開発と価格設計がここでつながるのか。
タカシ
まさにそうです。共有率だけを追うと、売れているのに体験が崩れる SaaS になります。静かな顧客を守る仕組み、混雑を生む顧客を測る仕組み、そして保証を商品に変える仕組み。この三つをそろえることが、ノイジーネイバー対策の本質です。