ディスカッション (7件)
ロードバランサーを導入する際、単にトラフィックを分散させるだけでなく、コスト効率という視点でシステム設計を見直してみませんか?本稿では、システム負荷とインフラコストの意外な相関関係について深掘りし、スケーラビリティを確保しつつ運用コストを最適化する戦略を考察します。
もちろん、これはイベントが独立していることを前提とした話だよ。ワールドカップやスーパーボウルなんかだと、その前提が崩れちゃうからね。とはいえ、待ち行列理論って最高に面白いよね。
なんで直線的に悪化するなんて思う人がいるんだろう?一体どんな(間違った)前提があるんだ?
Hacker Newsによくある、一見大したことなさそうな記事だと思って、実は平凡なタイトルで深遠なアイデアを語っているタイプかと思ったんだ。でもフタを開けてみたら、当たり前の直感に対してドラマチックさを強調しすぎていて、かなり混乱させられる内容だったよ。こういう書き方は技術記事じゃなくて文学の領域だね。
明らかに欠けているのは、サービスの前に適切に調整されたキューがある場合のパフォーマンスのグラフだね。確かにバックエンドサーバーが増えるほどキューの重要性は下がるけど、ここでは10台サーバーがあってもグラフを見る限りレイテンシはキューがある場合より25%以上悪いままだ。あと、ロードバランシングだけに頼る場合に処理時間のばらつきがどう影響するかについての議論も抜けているね。
削除されたコメントにこうある:
もちろん、これはイベントが独立していることを前提とした話だよ。ワールドカップやスーパーボウルなんかだと、その前提が崩れちゃうからね。
その通りだよ。ここでのモデルはポアソン到着と指数分布のサービス時間(M/Mモデル)を前提としているけど、これは実世界のトラフィックパターン(非定常かつ非エルゴード的で、強い季節性を持つことが多い)の近似としては精度が低い。ただ、そうした季節性の頻度は通常かなり低い(日次サイクルなど)から、短期間であればこれらの強い前提も十分に正当化できるんだ。
より良いアプローチは、実際のトラフィックパターンや、より高度なパラメトリックモデルを使ってシミュレーションを行うことだね(例えば https://stability-sim.systems/ など)。幸い、そうしたシミュレーションは以前よりずっと低コストで実行できるようになったよ。
この記事はポアソン到着と無限キューという単純化された世界モデルを提供しているね。数学モデルとしてはこれでいいんだ。
でも現実世界では、タイムアウトやリトライ、サンダリング・ハード(群れでのリクエスト)、相関のあるバーストといった要因で、バーストが連動してしまうことがある。
だから、ロードバランスされたシステムの現実的な経済性は、単純に信頼性の話に帰結するんだ。つまり、ピーク時のトラフィックをそれなりに処理できる能力を持つことであり、それがシステムの過剰なプロビジョニングにつながるわけだ。
クラウドを使えばリソースのスケールアップやダウンは可能だけど、それだけで問題が解決するわけじゃない。個人的には、同期システムから非同期システムへ移行し、クライアント側に遅延を少しずつ吸収させる方が(インフラを動的にスケールさせてクラウドプロバイダーにリクエスト秒単位で課金されるよりも)賢いアプローチだと思う。