オペレーティングシステム、常駐サービス、余裕を持った現実的な並行処理に必要なメモリを選びましょう。どのタスクがビジーか、並列実行されるか、ユーザーが実際にどのような遅延を経験するかを測定したうえで、CPU を選びましょう。
通常の作業とビジーな作業を別々に記述する
訪問者数だけではサイジングの根拠として弱すぎます。1つのリクエストがキャッシュされたファイルを返す一方で、別のリクエストがレポートを生成したり多数のテーブルをクエリしたりする場合があります。VPS を共有する Web ワーカー、データベース、キャッシュ、キューのコンシューマー、メンテナンスタスクを列挙しましょう。通常の並行処理と、予想される最も混雑する操作を記述しましょう。スケジュールされたエクスポート、パッケージ更新、デプロイも、目に見えないバックグラウンド活動として扱わず、含めましょう。
既存のプロジェクトでは、混雑する時間帯を含む代表的な期間を収集しましょう。リソース使用量とあわせて、応答時間とエラーを記録しましょう。新規プロジェクトでは、現実的なリクエスト形状とデータサイズで小規模なテストを作成しましょう。初期の見積もりは不完全なものになります。有用な目標は、納品後に測定した挙動と比較できる、文書化された出発点を持つことです。
プロセスを追加する前にメモリ予算を構築する
メモリ需要は、システム、常駐アプリケーションサービス、ワーカーごとの使用量、一時的な操作から生じます。ワーカーのフットプリントに計画した並行数を掛けるのは、大まかな計画ツールであり、保証ではありません。共有メモリとキャッシュが合計を複雑にするからです。負荷時の実際のプロセスを観察しましょう。メンテナンスタスクがアプリケーションに残りのすべてのページを奪い合わせることがないよう、十分な余裕を残しましょう。
データベース設定は、予想外にメモリ使用量を増やすことがあります。PostgreSQL は、work_mem がクエリ操作に適用され、複数の操作やセッションが同時に実行されうることを文書化しています。したがって、単独では控えめに見える設定が、システム全体でより大きな影響を持つ可能性があります。データベース自身のガイダンスを読み、現実的な並行処理をテストし、宣伝されているすべてのギガバイトを単一のキャッシュに割り当てるのは避けましょう。
CPU使用率と有用な並列性を区別する
プロセッサ数は、ゲストに提示される実行リソースの数を示すものであり、ソフトウェアがそれらをどれだけ効率的に使えるかを示すものではありません。1つのビジーのスレッドがアプリケーションを制限し、他のコアが静かなままである場合があります。ワーカーを追加すると独立したリクエストには役立ちますが、データベースの競合とメモリ需要も増加させます。コア数を2倍にするとスループットも2倍になると仮定する前に、アプリケーションの並行処理モデルを確認しましょう。
KVM は、独自の仮想ハードウェアを持つ仮想マシンを提供します。しかし、すべての vCPU ラベルが、ホストやプロセッサ世代をまたいで同一のベンチマークになるわけではありません。可能であれば記載されている CPU モデルと割り当て条件を比較し、その後、自分のワークロードでサービスを評価しましょう。アプリケーションに似ていない短い合成スコアから購入判断を下すのは避けましょう。
平均だけでなく、プレッシャーと待機を探す
システムは、平均 CPU 使用率が高くなくても遅く感じることがあります。プロセスはストレージ、メモリ回収、または別のサービスを待っている場合があります。Linux カーネルの Pressure Stall Information は、対応システム上で CPU、メモリ、I/O のストール情報を公開します。これらのシグナルは、通常の使用率メトリクスやアプリケーションのタイミングとあわせて、リソース競合の特定に役立ちます。
メトリクスはまとめて読みましょう。持続的なメモリプレッシャー、スワップ、割り当て失敗、遅いリクエストは、単一のビジーなコンピュートワーカーとは異なる介入を示します。ストレージ待ちは、クエリ変更や別のディスクプロファイルを正当化する場合があります。外部の API 遅延は、ローカルの RAM を追加しても修復されません。どのリソースを増やすかを選ぶ前に、観察された制約を説明しましょう。
| 観察された挙動 | 調査すべき問い | 考えられる次のステップ |
|---|---|---|
| 1つのスレッドがビジーで、余っているコアは静か | この作業は並列実行できるか？ | タスクを改善するか、ワーカー設計を変更する |
| レポート中のメモリプレッシャー | いくつの操作が重なっているか？ | 並行処理を制限するか、テスト済みの余裕を追加する |
| I/O 待ちを伴う遅いリクエスト | どの読み取りまたは書き込みが遅延しているか？ | クエリとストレージの挙動を調査する |
| CPU とメモリが少なく、リクエストが遅い | 依存関係が応答を遅らせているか？ | ダウンストリーム呼び出しを測定する |
明示的な仮定を伴う計画例
2つの Web ワーカー、データベース、1つのキューのコンシューマーを持つ小規模なアプリケーションを想像してみましょう。チームは通常のリクエストとレポート生成タスクの間、これらのサービスを測定します。同時に4つのレポートを許可すると、メモリ需要が急増し、通常のトラフィックが遅延することがわかります。すぐに最大のプランを購入するのではなく、レポートの並行処理を制限し、結果を再度測定します。
調整後のワークロードが依然としてより多くのメモリを必要とするなら、アップグレードは観察された要件に応えるものになります。キューが依然として CPU 律速で、独立したジョブが並行実行できるなら、より多くの実行リソースが適切かもしれません。これらは例示的な判断であり、SwissOctet プランの性能数値ではありません。自分の測定値と制約を選択した構成とともに保管しましょう。
次の測定のために明確な経路を残す
レビューをトリガーする兆候を定義しましょう。応答時間の悪化、繰り返されるメモリプレッシャー、増大するキュー、またはワークロードの変化です。監視は、それ自体が新たなボトルネックにならない程度に軽量に保ちましょう。機能や大規模なデータセットを追加した後は再評価し、本当の問題が無制限のプロセスや遅いクエリである場合に繰り返しアップグレードするのは避けましょう。
SwissOctet の VPS ファミリーは、CPU とメモリの仕様、および選択されたリソースオプションを公開しています。追加オプションを加えた後の最終構成を、請求期間と合計を含めて読みましょう。アップグレードの取り決めは、それに依存する前に稼働中のオペレーターに確認しましょう。有用な VPS サイズとは、測定されたワークロードを適切な余裕と理解可能な次のステップとともに実行できるものです。
実践チェックリスト。
- サービスとメンテナンス作業を棚卸しする。
- 通常時と混雑時の並行処理を測定する。
- 常駐メモリと一時メモリを予算化する。
- CPU の作業が並列実行できるか確認する。
- プレッシャー、使用率、アプリケーションのタイミングを比較する。
- いつ構成を見直すかを定義する。
重要な詳細。
月間訪問者数で VPS をサイジングすべきですか？+
訪問者数は文脈として使い、その後、リクエストの複雑さ、並行処理、データサイズ、バックグラウンド作業を測定しましょう。同じ訪問者数でも異なる負荷を生み出すことがあります。
RAM を増やせば常にサービスは速くなりますか？+
いいえ。メモリが制約である場合や有用なキャッシュを可能にする場合には役立ちますが、すべての CPU、ストレージ、外部依存関係の遅延を解決するわけではありません。
vCPU 数が2倍になると性能も2倍になりますか？+
いいえ。並列性、プロセッサの特性、競合、アプリケーションの設計が、追加容量がどれだけ有用かを決定します。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- Linuxカーネル：Pressure Stall Information docs.kernel.org
- PostgreSQL: リソース消費 www.postgresql.org
- KVMプロジェクト：カーネル仮想マシン www.linux-kvm.org
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。