キャパシティ計画 - yuuk1's Digital Garden

# キャパシティ計画 ## 定義キャパシティ計画(capacity planning)は、アプリケーションやサービスが将来必要とするリソース量を事前に見積もり、上限に達する前に十分な余地を確保しておく計画立案の活動である。『ウェブオペレーション』14章は、これをストレージ専門家にとってデータ保護に次いで2番目に重要な責務と位置づけ、「重要というより義務」であると述べる。著者は常に6か月分の余裕を保つことを自身の運用ルールとしており、正しいキャパシティ計画があれば、支出と運用費を予測でき、データセンタのスペース・電力・サプライチェーンのロジスティクスをより効果的に計画できるとする。この見積もりは通常、アプリケーション側から提示される容量・成長予測・キャパシティ要求のデータに基づいて行われる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3) ## キャパシティ不足が顕在化する経路キャパシティ計画の失敗は、単体の事象としてではなく、複数の要因が重なったときに顕在化しやすい。著者が語る実例では、以下の要因が連鎖した。 - 高価な既製品(NASアプライアンス)から安価な自社製ストレージエンジンへの移行を決定し、移行完了を見込んで既製品の追加購入を停止した。 - サイトが急に人気になり、ファイルのアップロード量が急増した。 - 新ストレージエンジンの検証にバグ由来の遅れが生じ、移行が計画どおりに完了しなかった。 - 既製品の容量を確保するため非同期レプリケーションの頻度を落とさざるを得ず、結果としてRPO(目標復旧時点)を割り込んだ。 - その状態でディスクが故障し、RAIDの再構築が発生して読み取り性能が悪化した。レプリケーション側にも復旧可能なデータがなかった。著者はこの経験から、「ソフトウェア開発のスケジュールだけでなく、急成長に耐えうる十分なキャパシティを常に気にかけなければならない」という教訓を導き、新システムの完成を待つ間の6か月の余裕があれば、もっと容易に乗り越えられたはずだと振り返る。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3) ## ストレージサイジングの要求審査キャパシティ計画の実務は、個々のストレージ要求を審査する場面にも表れる。著者は、技術に詳しい共同設立者・経営幹部・インフラ部門の技術専門家からなる購入審査委員会に参加した経験から、「正確なデータのない要求はすべて却下される」という運用が、根拠のない過大・過小要求を除く効果的なゲートになると述べる。宿題(容量・成長予測・キャパシティ要求の具体化)をしてきたエンジニアと、そうでないエンジニアの差は明確であり、審査を通じて後者も次第に設計とサイジングの勘所を学んでいく。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.4) ## Jainによるキャパシティ計画の定式化(1991) キャパシティ計画(capacity planning)とキャパシティ管理(capacity management)は、本来異なる時間軸を持つ概念として区別される。Jain(1991)は、キャパシティ管理を「現有の計算資源を使って最高の性能を提供すること」、キャパシティ計画を「将来のワークロード需要をコスト効率よく満たすために十分な計算資源を確保すること」と定義し、前者の対応策が使用パターンの調整・構成の再配置・システムパラメータの変更(性能チューニング)であるのに対し、後者の対応策は追加の計算資源の調達であるとする。両者は「計装 → 監視 → ワークロード特性化 → 複数代替案での性能予測 → 最低コスト・最高性能の代替案選択」という共通の5ステップの手順を持つが、キャパシティ管理では詳細なシステム固有のチューニングモデル、キャパシティ計画では待ち行列モデル等の粗くシステム非依存なサイジングモデルが使われる点で異なる(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 9 Capacity Planning and Benchmarking]] §9.1)。 Jainはさらに、キャパシティ計画の実務を難しくする10件の構造的な難所を挙げる。本ページの既存の知見と特に直結するのは、(1) 標準的なキャパシティ定義の不在(最大スループットか、性能目標を満たす最大ユーザ数か)、(2) 性能はキャパシティ計画のごく一部にすぎず機器・設置・保守・人員・床面積・電力・空調のコストがむしろ支配的になりつつあるという指摘である(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 9 Capacity Planning and Benchmarking]] §9.2)。 ## 第33章のボトルネック解析: キャパシティ計画の解析的な道具 9章がキャパシティ計画の共通手順(計装→監視→ワークロード特性化→複数代替案での性能予測→選択)を示すのに対し、33章はそのうち「性能予測」の段階を、確率的仮定を一切置かないオペレーショナル法則(operational laws)だけで実行する具体的な解析手法(ボトルネック解析)を与える。各装置 $i$ のサービス需要 $D_i$(ジョブ1件あたりの総サービス時間)を測定し、需要が最大の装置(ボトルネック装置、$D_{\max}$)を特定するだけで、システムスループットの上界($X \le \min\{1/D_{\max}, N/(D+Z)\}$)と応答時間の下界($R \ge \max\{D, ND_{\max}-Z\}$)という漸近的な上下界が導ける。両者の交点(膝、$N^*=(D+Z)/D_{\max}$)を超える利用者数では系のどこかに確実にキューイングが生じると判定できる。この解析は、待ち行列モデルを完全に解いて厳密な性能曲線を得る(第34〜36章で扱う平均値解析・畳み込みアルゴリズム等)手前の、もっとも軽量な性能予測手段であり、詳細なモデル構築の要否そのものを判断するスクリーニングとして機能する。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] §33.6) ## 第34章の均衡ジョブ限界: ボトルネック解析をさらに絞る道具第33章のボトルネック解析(§33.6)がサービス需要 $D_{\max}$ だけから与える漸近的上下界は、スループットの上界と応答時間の下界という片側の限界にとどまる。第34章§34.4の均衡ジョブ限界(balanced job bounds)は、均衡系(全装置のサービス需要が等しい系)との比較という論法を追加し、装置あたりの平均サービス需要 $D_{avg}=D/M$ をもう1つの尺度として導入することで、スループットの下界・応答時間の上界という反対側の限界も与える。第33章の片側限界が「安全側にどれだけ悪化しうるか(応答時間の下界=最良でもこれ以上速くならない)」しか語らないのに対し、第34章の両側限界は「実際の性能値がどの狭い範囲に収まるか」を示すため、キャパシティ計画のスクリーニング段階でより実用的な精度の見積もりを与える。例34.4(第32章の中央サーバモデル、$D_{CPU}=2, D_A=3, D_B=1, Z=4$)では、$N=20$ で応答時間が下界56.000・厳密解56.016・上界61.068、スループットが下界0.307・厳密解と上界がともに0.333という極めて狭い範囲に収まることが示される。均衡ジョブ限界の計算コストは $D_{avg}=D/M$ という平均を1つ追加で求めるだけであり、詳細な待ち行列モデル(MVA・畳み込みアルゴリズム)を解く前段階のキャパシティ見積もりとして、第33章の片側限界よりコスト対精度で優れる。ただし、端末以外の全装置が固定容量サービスセンターであることを前提とし、端末以外に遅延センターを含む系には適用できない。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 34 Mean-Value Analysis and Related Techniques]] §34.4) ## 横断的知見 - **Jain(1991)の「標準的なキャパシティ定義の不在」という指摘は、本ページが既存3ソースから見出した「headroom型・SLA逆算型・オートスケーリング型」という3つの並立モデルの存在そのものを、30年以上前から構造的に予見していた**: Jainはキャパシティを「最大スループット」と定義する立場と「性能目標を満たす最大ユーザ数」と定義する立場が並存し、標準的なワークロード単位も存在しないと指摘する(§9.2)。14章のheadroom型(安全余裕率)・18章のSLA逆算型([リクエスト/秒/ホスト])・2章のオートスケーリング型(需要への動的追従)は、まさにこの「標準定義の不在」が2011年時点でも解消されていないことの実例であり、Jainの指摘した難所が個別の実務書で独立に異なる解法として現れたと読める。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 9 Capacity Planning and Benchmarking]] §9.2, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.3) - **Jainの「性能はキャパシティ計画のごく一部にすぎない」という指摘は、14章の「6か月分の余裕」という経験則が精緻な性能モデル化を経由しない理由を裏付ける**: Jainは性能モデル化が機器サイジングを助けるにすぎず、設置・保守・人員・床面積・電力・空調のコストがむしろ支配的になりつつあると述べる(§9.2 項目10)。14章のストレージ担当者が精緻な性能モデルでなく「常に6か月分の余裕を保つ」という単純な経験則に頼っていたのは、この非性能コストの支配というJainの指摘と整合する——性能予測の精度を上げるより、コスト全体を見渡した安全余裕の方が実務上優先されるということである。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 9 Capacity Planning and Benchmarking]] §9.2, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3) - **「余裕(headroom)の確保」対「レスポンスタイムSLAから逆算する定量指標」——同じ『キャパシティ』を、資源の希少性と応答品質という異なる出発点から定義する2つの実務モデル**: 14章(ストレージ)は、キャパシティ計画を「常に6か月分の余裕を保つ」という**headroom型**の経験則として語り、逼迫時に何が起きるか(RAID再構築・RPO悪化)という失敗の重大さから重要性を導く。これに対し18章([[Cookpad|クックパッド]])は、キャパシティを「平均200msecでレスポンスできる秒間リクエスト数[リクエスト/秒/ホスト]」という**SLA逆算型**の定量指標として定義し、単純なクエリ性能を測るマイクロベンチマークでなく実トラフィックに基づくマクロベンチマークで計測する。14章のストレージは「壊れたら復旧が困難な有限資源」であるため保守的な余裕を確保する設計に傾き、18章のウェブサーバ群は「負荷テストで測定し足りなければスケールアウトできる複製可能な資源」であるため、レスポンスタイムという上位の品質目標から必要ホスト数を逆算する設計に傾く。資源の性質(壊れると取り返しがつかないか、水平に足せるか)がキャパシティ計画の設計思想そのものを規定していることが、両章を並べることで見えてくる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3-§14.4, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.3) - **どちらの章も「新技術・新環境の検証」だけは例外的に理論値・マイクロな指標を許容する**: 18章は日常のキャパシティ計測では実トラフィックのマクロベンチマークを重視しつつ、「新技術の導入検討時を除いて」単純なクエリ性能のマイクロベンチマークからはフォーカスを外すと明記する。14章の購入審査委員会も、既存システムの日常的なサイジングでは「正確なデータのない要求はすべて却下される」という運用実績ベースの審査を敷く一方、新ストレージエンジンへの移行検討時には(実運用データがまだ存在しないため)見積もりに基づく判断を許容していた(移行完了を見込んで既製品の追加購入を止めた判断)。両章とも、成熟した資源には実測データを要求し、未成熟な新技術には見積もりでの判断を許容するという同じ非対称なポリシーを独立に採用している。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3-§14.4, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.3) - **静的なheadroom(14章)・SLA逆算の定量指標(18章)に続く第3のモデルとして、2章はクラウドによる弾力的なキャパシティ確保を示す**: 14章はストレージという「壊れると復旧困難で単純に水平分割できない」資源に対し6か月分の余裕を事前に確保する静的なheadroom型モデルを取り、18章はウェブサーバ群という「水平にスケールアウト可能な」資源に対しレスポンスタイムSLAから逆算した定量指標([リクエスト/秒/ホスト])でキャパシティを測る。2章(Picnikのクラウドコンピューティング利用)はこの2つのモデルのいずれとも異なり、キャパシティを事前確保も逆算計測もせず、EC2のオートスケーリングによって需要変動そのものにリアルタイムで追従させる**動的モデル**を取る——ServerManagerが1分ごとにキューの状況を調べ、目標稼働率に必要な台数を自動的に増減させる。14章のheadroom型が「事前に十分な余裕を確保しておく」ことでキャパシティ不足を回避するのに対し、2章のオートスケーリング型は「必要になった瞬間に確保する」ことで同じ問題を回避しており、両者は静的な安全余裕と動的な弾力性という対極の戦略である。ただし2章はこの動的モデルが有効なのはレンダーサーバのような疎結合コンポーネントに限られ、密結合なウェブサーバ・データベースサーバは14章的な事前確保(専用ハードウェア)に頼るしかないと明言しており、資源の疎結合度がどちらのモデルを取るべきかを規定する新しい軸を加える。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3-§14.4, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.3, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.1.2, §2.2) - **クラウド側のキャパシティ計画にも、14章と同種の「破局的な逼迫」の実例がある**: 14章はストレージのキャパシティ不足がRAID再構築・RPO悪化という連鎖で顕在化する例を示すが、2章はクラウドストレージ(S3)側でも類似の逼迫が起きうることを示す——Picnikは作成ファイルの75%しか削除しておらず不要ファイルが積み上がったが、実害が見えないため対応を先送りし続け、最終的に「クレジットカードの月額上限に達した」ことで初めて対応を迫られた。14章の逼迫はハードウェア故障という物理的な閾値で顕在化するのに対し、2章の逼迫は課金上限という経済的な閾値で顕在化しており、クラウドのキャパシティ計画では物理的な容量だけでなく支払い上限そのものが新たな制約軸になることを示す。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.1.1) - (本書にはさらにキャパシティ計画を扱いうる章として9章(予期しないトラフィック急増への対応)があり、ingest された際にトラフィック側からの視点をさらに追記する。) - **単発イベント(ローンチ)がもたらす需要の不確実性への対処法は、既存のheadroom型(14章)・SLA逆算型(18章)・オートスケーリング型(2章)のいずれとも異なる第5のモデルを要求する**: 14章のheadroom型は日常的な成長トレンドを前提に「常に6か月分の余裕を保つ」という時間軸の長い静的な余裕確保であり、2章のオートスケーリング型は既に発生した需要変動にリアルタイムで追従する。これに対し[[@2016__OReilly__SRE Book - Chapter 27 Reliable Product Launches at Scale]]が扱うローンチスパイクは、公衆の関心という予測困難な変数に左右され、当初見積りの最大15倍に達した例が示すとおり、事前の静的余裕確保でも事後の自動追従でも捕捉しきれない種類の不確実性を持つ。第27章はこれに対し「一国・一地域から段階的にローンチし確信を積み上げる」という、需要そのものではなく**曝露範囲を段階的に広げることで見積りの誤差を許容範囲に収める**戦略を示しており、14章・2章のいずれも扱わない第5のモデル(段階的曝露によるキャパシティリスク管理)を追加する。さらに第27章は「3つのレプリカ展開でピーク時100%を捌けるなら、メンテナンスや不調に備えて4〜5展開を維持する」という冗長性の観点からのheadroom計算も示すが、これは14章の「6か月分の余裕」のような時間軸の余裕ではなく、同時点での**障害耐性のためのレプリカ数の余裕**であり、両者は「headroom」という同じ語で異なる種類の余裕(時間的対冗長性)を指している。(Source: [[@2016__OReilly__SRE Book - Chapter 27 Reliable Product Launches at Scale]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]]) - **9章が示す「標準的なキャパシティ定義の不在」という難所に対し、33章のサービス需要 $D_i$ は、14章のheadroom型・18章のSLA逆算型・2章のオートスケーリング型がそれぞれ独自に採用してきた尺度(安全余裕率・[リクエスト/秒/ホスト]・目標稼働率)を統一的に記述できる、装置非依存の解析的な単位を提示する**: 既存3ソースの並立モデルは、いずれも「何を単位にキャパシティを測るか」という問いに、資源の性質(壊れると復旧困難か、水平にスケールアウト可能か)に応じた別々の答えを出していた(既存の横断的知見参照)。33章のサービス需要 $D_i=V_iS_i$(訪問比率×サービス時間、単位は時間)は、CPU・ディスク・ネットワークのいずれの装置にも同じ形式で定義でき、$D_{\max}$ が最大の装置がボトルネックになるという結論も装置の種類によらない。これは、9章が指摘した「標準定義の不在」という難所そのものを解消するわけではないが、少なくとも装置横断で比較可能な共通尺度を提供する点で、既存3モデルの一段下にある解析的な基盤にあたる。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 9 Capacity Planning and Benchmarking]] §9.2, [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] §33.2, §33.6, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.3) - **33章の膝($N^*=(D+Z)/D_{\max}$)は、14章の「6か月分の余裕」のような時間軸の経験則や、27章の「段階的な曝露拡大」のような手探りの戦略に対し、いつキューイングが避けられなくなるかを解析的に予告する数値を与える**: 14章のheadroom型モデルは「常に6か月分の余裕を保つ」という時間軸の経験則に依拠し、27章のローンチ戦略は「一国・一地域から段階的にローンチし確信を積み上げる」という、需要そのものではなく曝露範囲を段階的に広げる手探りの対応をとる。いずれも「どこまでの負荷なら安全か」を定量的には示さない。33章の膝 $N^*$ は、装置ごとのサービス需要 $D_i$ と思考時間(またはリクエスト間隔)$Z$ さえ測定できれば、それを超えた瞬間に系のどこかで確実にキューイングが起きる利用者数(またはリクエストレート)を解析的に導く。この数値は、既存3モデルが持たない「安全でなくなる境界」の定量的な特定手段として、既存の経験則・段階的拡大戦略を補完しうる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3, [[@2016__OReilly__SRE Book - Chapter 27 Reliable Product Launches at Scale]], [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] §33.6) - **第33章の膝($N^*$)が「どこで確実にキューイングが起きるか(境界の位置)」を答えるのに対し、第34章の均衡ジョブ限界はその境界に至る途中の各段階で性能がどの範囲にあるか(境界に至る過程の精度)を補う**: 既存の横断的知見が指摘したとおり、33章の膝は既存3モデル(14章のheadroom型・18章のSLA逆算型・2章のオートスケーリング型)にない「安全でなくなる境界」を定量的に特定する手段だったが、それはあくまで単一の閾値(点)であり、その手前の各利用者数 $N$ で性能がどれだけ不確かかは示さない。34章の均衡ジョブ限界は、膝の前後を含む任意の $N$ について、実際の性能値がどれだけ狭い範囲(下界〜上界)に収まるかを両側から挟む値を追加で与える。両者を重ねると、キャパシティ計画のスクリーニングにおいて「境界の位置」(33章)と「境界に至る経路上の各点での精度」(34章)の両方を、詳細な待ち行列モデルを解かずに見積もれるようになることが分かる。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] §33.6, [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 34 Mean-Value Analysis and Related Techniques]] §34.4) ## 未解決の問い - 「6か月分の余裕」という目安は、本章の著者個人の経験則として述べられているにすぎない。ストレージの種類(ブロック・オブジェクト・テープ)やビジネスの成長率によって、適切な余裕期間はどう変わるべきか。 - 新システムへの移行期間中は、旧システムの追加投資を止めてしまう誘因が働きやすい(本章の実例のとおり)。移行期特有のキャパシティリスクをどう管理すべきか。 - キャパシティ計画とRPO(目標復旧時点)はどう相互作用するか。本章の実例では、キャパシティ逼迫がレプリケーション頻度の低下という形でRPOを直接圧迫した。この因果はストレージ以外のリソース(帯域・計算資源)でも同様に成り立つか。 - 購入審査委員会のような「データに裏付けられた要求だけを通す」ゲートは、どの規模の組織から効果を持ち始めるか。小規模組織でも同様の仕組みは機能するか。 - 18章の「[リクエスト/秒/ホスト]」という単位は、水平にスケールアウト可能な資源(アプリケーション・DBサーバ)を前提にしている。ストレージのように「壊れると復旧が困難」で単純に水平分割できない資源に対して、同種の定量的なキャパシティ単位をどう設計すべきか。14章のheadroom型モデルはこの問いへの一つの回答(定量指標でなく安全余裕率で対処する)と読めるが、両者を統一する枠組みは本wikiにまだない。 - 2章のオートスケーリング型モデル(動的追従)と14章のheadroom型モデル(静的余裕)を同一システム内で併用する場合——例えば2章自身が密結合コンポーネントには事前確保、疎結合コンポーネントには動的追従を使い分けているように——切り替えの境界をどう設計・運用するのが良いか。本wikiにはまだこの併用パターンの一般化がない。 - クラウドの支払い上限という経済的な逼迫閾値(2章)は、オンプレミスの物理的な逼迫閾値(14章のディスク故障・RAID再構築)と比べて、検知の難易度・対応の緊急性がどう異なるか。2章の事例では「実害が見えない」ため対応が先送りされ続けたが、これは物理的な閾値(ディスク故障は即座に可視化される)と比べて検知が構造的に遅れやすいことを示唆する。この非対称性はどこまで一般化できるか。 - 第27章の「一国・一地域から段階的にローンチする」戦略は、どの程度の期間・トラフィック水準を観察すれば次段階への拡大が「安全」と判断できるかを具体的には示さない。この判断基準は、既存のheadroom型(14章の6か月ルール)やSLA逆算型(18章の[リクエスト/秒/ホスト])のような定量的な閾値と、どう統合できるか。 - Jain(1991)は「モデル入力(シンクタイム等)が正確には測定できない」という難所を挙げる(§9.2 項目7)。既存3ソースが示すheadroom型・SLA逆算型・オートスケーリング型のいずれも、モデル入力の測定困難さそのものへの対処は明示しない。定量指標に基づくSLA逆算型モデル(18章)は測定困難な入力にどう対処しているか、本wikiにはまだ答えがない。 - Jainの5ステップ手順(計装→監視→特性化→予測→選択)を既存の3モデル(headroom型・SLA逆算型・オートスケーリング型)にあてはめ直すと、それぞれどのステップを省略・簡略化しているか整理されていない。特にオートスケーリング型(2章)は「予測」ステップをリアルタイムのフィードバック制御に置き換えているように見えるが、この対応関係は未検証である。 - 33章のサービス需要 $D_i$・膝 $N^*$ は単一システム(タイムシェアリングシステム)を前提にした解析だが、18章のようなウェブサーバ群([リクエスト/秒/ホスト])や2章のようなオートスケーリング環境(EC2の複数ホスト)にこの解析をそのまま適用できるか、あるいはホスト数を新たな変数として組み込む拡張が必要かは、本wiki内でまだ検証されていない。 - 33章のボトルネック解析は思考時間 $Z$ を持つ対話型(クローズドループ)システムを前提にするが、18章のSLA逆算型モデルが扱う実トラフィックのようなオープンループ的な到着(仮想ユーザ数ではなくリクエストレートを外部から与える環境)では、膝 $N^*$ に相当する解析的な閾値はどう再定義されるか。 ## 関連 - 概念: [[データ保護]](本章の別の主題。キャパシティ逼迫がRPOを圧迫する接点を持つ) / [[事業継続計画（BCP）]] / [[分散ストレージ]] / [[可用性]](レスポンスタイムSLAとキャパシティの接点) / [[ハイブリッドクラウド]](動的追従モデルの詳細) / [[ローンチチェックリスト]](ローンチスパイクの需要予測をチェックリスト項目として扱う上位の実践) / [[ベンチマーキング]](サイジングモデルの検証に使う負荷駆動・ベンチマーク手法) / [[オペレーショナル法則]](33章のボトルネック解析が依拠する法則群を独立に扱う concept) / [[待ち行列理論]] - 実体: [[Anoop Nagwani]] / [[濱崎健吾]] / [[Cookpad]] / [[Picnik]] / [[Justin Huff]] / [[Rhandeev Singh]] / [[Sebastian Kirsch]] / [[Vivek Rau]] / [[Raj Jain]] - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] / [[@2016__OReilly__SRE Book - Chapter 27 Reliable Product Launches at Scale]] / [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 9 Capacity Planning and Benchmarking]] / [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] / [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 34 Mean-Value Analysis and Related Techniques]] - 書籍: [[ウェブオペレーション ―サイト運用管理の実践テクニック]] / [[SRE Book]] / [[The Art of Computer Systems Performance Analysis]] ## 出典 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]](アヌープ・ナグワニ, 「ストレージ」, John Allspaw・Jesse Robbins 編, 角征典訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 14 章, §14.3, §14.4) - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]](濱崎健吾, 「18章日本の料理のインフラ」, 同書, §18.3) - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]](ジャスティン・ハフ, 「Picnikにおけるクラウドコンピューティングの利用とその教訓」, 同書, 2章, §2.1.1, §2.1.2, §2.2) - Rhandeev Singh, Sebastian Kirsch, and Vivek Rau, "Reliable Product Launches at Scale," in *Site Reliability Engineering: How Google Runs Production Systems*, O'Reilly, 2016, Chapter 27. - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 9 Capacity Planning and Benchmarking]](Raj Jain, *The Art of Computer Systems Performance Analysis*, John Wiley & Sons, 1991, Chapter 9, §9.1, §9.2) - Raj Jain, *The Art of Computer Systems Performance Analysis*, John Wiley & Sons, 1991, Chapter 33, §33.2, §33.6. - Raj Jain, *The Art of Computer Systems Performance Analysis*, John Wiley & Sons, 1991, Chapter 34, §34.4.