企業向けサーバーのリスクは、サイトダウンではなく不確実性

複数のサイトを運営している企業では、いずれかのサイトが停止してしまうことが最大のリスクと考えられがちです。特にオンラインストアやビジネスサイトでセールやキャンペーンを実施する際には、サイトの停止は企業にも顧客にも大きな損失をもたらすため、その不安はさらに高まります。

しかし実際には、サイトダウンのリスクはある程度予測・管理することができます。厄介なのは、日々の運用における“先が読めない状態”、つまり不確実性にあります。

不確実性とは、「何かがうまくいかないかもしれない」という漠然とした不安を意味します。例えば、プロモーションで増えたトラフィックをサーバーが処理できるのかわからない、決済が遅い原因が特定できない、あるいはユーザー数の増加に伴ってコストがどの程度膨らむのか見通せないといった状況です。

この不確実性は、多くの場合、サービスの透明性の低さや不十分な情報、あるいは「無制限リソース」といった曖昧な表現の裏に潜んでいます。そもそもITの世界において、制限のないものは存在しません。過度に魅力的なマーケティングの裏には、見えにくい制約が隠れていることがよくあります。

こうした運用上の不確実性は、サイトのパフォーマンスを予測することを難しくし、マーケティング施策の成果を確実なものにできなくします。サーバーの限界を把握しないままプロモーションに多額の費用を投じた結果、アクセス集中によってサイトが極端に遅くなったり停止したりしたらどうなるのか。その結果は明らかで、広告費の無駄、ブランドイメージの低下、そして売上の損失につながります。

予測可能性はビジネス成果に直結します。サイトの挙動を事前に予測できることは、単なる稼働率の保証よりもはるかに重要です。

ビジネスを損なうのはサイトダウンではなく「不確実性」

多くのレンタルサーバーは、「リソース使い放題」や「リソース無制限」といったプランを打ち出しています。しかしITの世界において、本当に無制限なものは存在しません。CPUが処理できるリクエスト数や、データベースへの同時接続数、1秒あたりに実行できるPHPスレッド数など、あらゆるリソースには必ず上限があります。

また、多くのサービスはSLA（サービス品質保証）に基づき、99.999%といった高い稼働率を掲げています。一見安心できる数値に思えますが、稼働率はあくまで一つの指標にすぎず、サイトが実際にどの程度の負荷に耐えられるのかまでは示してくれません。

たとえば、キャンペーンやセールの最中にサイト自体は稼働しているにもかかわらず、同時に多くのユーザーが購入手続きを行った結果、買い物カゴの読み込みに10秒もかかる状況を想像します。技術的には稼働しているため、サービス側は約束を果たしていると言えます。しかし実際には、ユーザーは待ちきれずに離脱し、売上の機会を逃し、広告費も無駄になってしまいます。さらに厄介なのは、IT担当者さえ原因や対処方法を把握できていないケースです。これこそが「不確実性」というリスクになります。

サーバーが「無制限」という言葉を使うとき、それは豊富なリソースを提供しているわけではなく、リソースには限界があるという現実を見えにくくしているに過ぎません。このような透明性の欠　如こそが運用上の不確実性を生み、データに基づいた意思決定を難しくしているのです。

サーバーの限界に達すると何が起こるのか

サイトへのアクセスが急増すると、多くのサービス提供元はサイトを停止させるのではなく、自社のインフラを守るために利用できるリソースを制限します。たとえば、PHPの実行プロセス数を減らすことで、サイトの処理速度を意図的に落とすケースがあります。技術的にはサイトは稼働したままですが、実際にはほとんど使い物にならない状態です。

さらに問題なのは、こうした状況が発生した際に、原因を特定するための十分なデータが手元にないことです。不確実性はここで一気に高まります。サポートに問い合わせても、対応を待つしかない場合が多く、上位の技術担当者に引き継がれるまでに時間がかかることもあります。その間に状況が悪化することもあり、専門的な対応には追加費用が発生する場合も。その結果、時間の浪費や売上の損失、想定外のコストといった問題が連鎖的に発生します。

また、プランの具体的な制限（PHPの同時実行数やメモリ上限など）が把握できていないと、新製品の発表やキャンペーン、繁忙期に向けた広告施策の計画にも支障が出ます。サイトを支える基盤の仕組みが見えないままでは、自社のリソースについて確信を持てず、手探りで判断せざるを得なくなります。

少し視点を変えてみます。もし海運会社であれば、船に積めるコンテナの数は正確に把握しているものです。あるいは製造業であれば、1時間あたりの生産数を把握しているのが当然です。このように、多くの業界では処理能力は明確に把握されています。しかし、サーバーサービスでは、サイトがどれだけの負荷に耐えられるのかといった処理能力を明確に示さないことが少なくありません。たとえば、利用可能なPHPの同時実行数が分からなければ、キャンペーン中に何件の同時購入処理に対応できるのかを正確に見積もることはできません。

ROIという見えにくい指標

ROI（投資利益率）は、投資に対してどれだけの利益が得られたかを示す指標で、次の式で求められます。

ROI =（投資の最終価値 − 投資コスト）/ 投資コスト

ROIを正しく算出するには、投資によってどれだけの成果を生み出せるか、つまり処理能力やキャパシティを把握している必要があります。たとえばインフラに20万円を投じていても、その上限が分からなければ、その支出が適切なのか、無駄があるのか、それとも不足しているのかを判断することはできません。

問題はインフラコストだけにとどまりません。仮に、1秒あたり100件の処理が必要になるようなトラフィックを見込んで、広告に20,000ドルを投資したとします。しかし、そのアクセスを受け止めるインフラがその一部しか処理できない場合、投資の価値は大きく損なわれてしまいます。このような状況ではROIを見積もること自体が難しく、データに基づいた意思決定もできなくなります。

一方で、インフラの仕組みや制限が明確であれば、1秒あたりに処理できるPHPの同時実行数や、決済処理にかかる時間、処理可能なトランザクション数などを把握できます。これにより、投資の成果をより正確に見積もり、根拠のあるROIを算出して経営判断に活かすことが可能になります。

このように考えると、サーバーは単なる固定費ではなく、運用状況を把握し、最適化できる「戦略的に活用できる基盤」へと変わります。過剰なリソース確保や、曖昧な見積もりに頼ることなく、根拠を持って計画や投資を進められるようになります。

Kinstaでは、こうした不確実性を排除しながら、適したプランを選択することができます。必要以上に高額なプランを選ぶ必要はなく、サイトやビジネスの成長に合わせて柔軟にスケール可能です。

勘や当て推量に頼らない意思決定へ：Kinstaで不確実性を解消

不確実性を解消するために必要なのは、実現不可能な約束を並べるサービスではありません。重要なのは、判断の根拠となる明確な指針を示してくれるパートナーです。

Kinstaでは、仕組みが見えないままの運用はありません。透明性の高い構成と明確な技術仕様により、勘や当て推量に頼るのではなく、データに基づいて投資の収益性を判断できる環境を提供しています。

PHPスレッド：実際の処理能力を示す指標

PHPスレッド数は、キャッシュされていないリクエストを処理するための専用プロセス数を意味します。単にページのHTMLを生成するだけでなく、サイト上で行われるさまざまな処理を支えています。

具体的には、次のような場面で使用されます。

• 訪問者が買い物カゴに商品を追加したり、プロフィールを更新したりする際の処理とデータベースの更新
• WordPressによる予約投稿の公開やメール送信、在庫同期などのバックグラウンド処理
• 決済処理やCRMへのデータ送信、外部APIとの通信など、外部サービスとの連携処理
• キャッシュされていないページの表示に伴うデータベースへの問い合わせと応答処理

PHPの同時実行数が不足すると、自動更新のような軽い処理でもリソースを使い切ってしまい、買い物客が買い物カゴから先に進めなくなるといった問題が発生する可能性があります。この数を把握できていなければ、適切な投資判断や運用計画を立てることはできません。

Kinstaでは、WordPressサイトごとに利用可能なPHPの同時実行数を明確に把握できます。

隠れた制限のないKinstaのサーバープラン

Kinstaでは、サイトのコンテナに割り当てられたリソースを正確に把握できます。PHPスレッドの数はもちろん、CPU数やメモリ容量、利用可能なデータセンター、各プランの仕様など、必要な情報が明確に示されています。

また、ブログ、ドキュメント、変更履歴、ニュースレターなどの情報も継続的に更新されており、サイトの運用を最適化し、ビジネス戦略を的確に立てるための情報を常に確認できるようになっています。

以下の表では、各Kinstaプランに含まれるデフォルトのPHP設定や同時実行数、スレッドあたりのメモリ量を確認できます。

プラン	プールサイズ	スレッド数	スレッドあたりのメモリ
Single 35k 訪問数 Single 20GB 帯域幅	512MB	2	256MB
Single 65k 訪問数 Single 40GB 帯域幅	1GB	4	256MB
Single 125k 訪問者数 Single 65GB 帯域幅	1.5GB	6	256MB
Single 315k 訪問者 Single 125GB 帯域幅	1.5GB	6	256MB
Single 500k 訪問数 Single 250GB 帯域幅	2GB	8	256MB
Single 750k 訪問数 Single 500GB帯域幅	2GB	8	256MB
Single 125k 訪問数 Single 750GB 帯域幅	5GB	10	512MB
Single 190k 訪問数 Single 1125GB 帯域幅	6GB	12	512MB
Single 250k 訪問数 Single 1500GB 帯域幅	7GB	14	512MB
Single 315k 訪問者 Single 1875GB 帯域幅	8GB	16	512MB
WP 2	512MB	2	256MB
WP 5	1GB	4	256MB
WP 10	1GB	4	256MB
WP 20	1.5GB	6	256MB
WP 40	1.5GB	6	256MB
WP 60	4GB	8	512MB
WP 80	5GB	10	512MB
WP 120	6GB	12	512MB
WP 150	7GB	14	512MB
Agency 20	3GB	6	512MB
Agency 40	3GB	6	512MB
Agency 60	4GB	8	512MB

ただし、PHPスレッド数や各プロセスに割り当てられるメモリ量は固定ではありません。特定の要件がある場合は、MyKinstaの「サイト」＞（サイト名）＞「情報」画面の「PHPパフォーマンス」セクションの「変更」をクリックして、PHPパフォーマンスアドオンを利用して各サイトの設定を調整できます。

専用サーバーをご利用の場合でも、こちらの手順に従ってPHPスレッド数やメモリ割り当てを変更することが可能です。

Kinsta APMで処理時間を可視化

決済処理にかかる時間を把握するには、組み込みのアプリケーションパフォーマンス監視（APM）ツールが便利です。Kinstaでは、New Relicなどの外部サービスを利用することなく、WordPressサイトのPHP処理におけるボトルネックを特定し、各処理にかかる時間を確認できます。

このAPMツールはすべてのプランに標準搭載され、PHPの処理、MySQLのクエリ、外部へのHTTPリクエストなどに関する詳細な情報が表示されます。

サイト監視を有効にすると、以下4つのタブで収集されたデータを確認できるようになります。

• トランザクション：全体の処理時間や、処理に時間のかかっているトランザクションを確認
• WordPress：プラグインやフックの実行時間など、WordPress固有の処理に関する情報を表示
• データベース：データベースクエリの実行時間や詳細を確認
• 外部：外部サービスへのHTTPリクエストの詳細を確認

買い物カゴなどの処理にかかる平均時間を把握できれば、ユーザーに快適な決済体験を提供するために必要なPHPスレッド数をより正確に見積もることができます。前述のとおり、サイトの表示が速いほど必要な同時実行数は少なくなり、結果としてコストの削減とユーザー体験の向上につながります。

こうした理由から、パフォーマンスの高い環境を提供し、サイト最適化を支援できるサービスを選ぶことが重要です。Kinstaでは、高速なクラウド基盤に加え、すべてのプランでCloudflareとの統合を標準で利用できます。これにより、高性能なCDNを通じて、訪問者に最も近い場所から静的コンテンツを配信できます。さらに、Cloudflareのエッジキャッシュにも対応しており、HTMLページ全体をキャッシュすることで、オリジンサーバーへの負荷の大部分をエッジ側にオフロードできます。

Kinstaはサーバー負荷の軽減、必要なPHPスレッドの削減、帯域使用量の最適化を実現し、高速で快適に動作するサイトを構築するための基盤とツールを提供します。

必要なPHP同時実行数の考え方

サイトに割り当てられているPHPの同時実行数と、決済処理にかかる平均時間が分かれば、1秒あたりに処理できるリクエスト数を見積もることができます。

PHPの同時実行数 ÷ 平均処理時間 ＝ 1秒あたりの最大リクエスト数

この考え方を理解するために、2つのケースを見てみましょう。

---

シナリオ1：低速なサーバー環境と最適化が施されていないサイト

PHPスレッドが10あり、決済に2秒かかる場合

計算：10 ÷ 2 = 5リクエスト/秒

---

シナリオ2：高速なサーバー環境と最適化が施されているサイト

PHPスレッドが10あり、決済に0.5秒かかる場合

計算：10 ÷ 0.5 = 毎秒20リクエスト

---

帯域幅の大小に関係なく、シナリオ1では6人目のユーザーが同時に決済を開始した時点で処理が滞り始めます。一方、シナリオ2では、毎秒最大20件のリクエストに対応できます。これが、最適化された高速なサイトと、ビジネスに適していない環境で運用されているサイトとの違いです。

リソースの分離：ノイジーネイバーの影響を排除

従来の共用レンタルサーバーや一部のVPSでは、同じサーバー上で複数のサイトがリソースを共有しています。そのため、自サイトの処理能力に対する不確実性に加えて、他のサイトの利用状況にも影響を受けるというノイジーネイバー問題が発生します。

Kinstaでは、すべてのサイトが独立したソフトウェアコンテナ上で動作します。このコンテナには、Linux、NGINX、PHP、MySQLといった、サイトの運用に必要なすべてのリソースが含まれています。つまり、各サイトは完全に分離された環境で動作しており、同一アカウント内の他のサイトを含め、リソースが共有されることはありません。

Kinstaでは、各コンテナにはデフォルトで12個のCPUと8GBのRAMが割り当てられます（各ステージング環境には1個のCPUと8GBのRAM）。

5大陸にまたがる27箇所のデータセンター（日本国内は東京・大阪の2拠点）から選択でき、全プラン標準のCloudflare統合によりサイトが保護されます。

1. Johannesburg, South Africa (af-johannesburg-1)
2. Batam, Indonesia (ap-batam-1)
3. Melbourne, Australia (ap-melbourne-1)
4. Mumbai, India (ap-mumbai-1)
5. Osaka, Japan (ap-osaka-1)
6. Seoul, South Korea (ap-seoul-1)
7. Singapore,Singapore (ap-singapore-1)
8. Sydney, Australia (ap-sydney-1)
9. Tokyo, Japan (ap-tokyo-1)
10. Montreal, Canada (ca-montreal-1)
11. Toronto, Canada (ca-toronto-1)
12. Amsterdam, Netherlands (eu-amsterdam-1)
13. Frankfurt, Germany (eu-frankfurt-1)
14. Madrid, Spain (eu-madrid-1)
15. Milan, Italy (eu-milan-1)
16. Paris, France (eu-paris-1)
17. Stockholm, Sweden (eu-stockholm-1)
18. Zurich, Switzerland (eu-zurich-1)
19. Jerusalem, Israel (il-jerusalem-1)
20. Riyadh, Saudi Arabia (me-riyadh-1)
21. Santiago, Chile (sa-santiago-1)
22. Sao Paulo, Brazil (sa-saopaulo-1)
23. London, United Kingdom (uk-london-1)
24. Ashburn, VA (us-ashburn-1)
25. Chicago, IL (us-chicago-1)
26. Phoenix, AZ (us-phoenix-1)
27. San Jose, CA (us-sanjose-1)

曖昧な約束に頼らないサーバー選びを

オンラインビジネスのサーバー選びで重要なのは、99.99%といった稼働率の高さそのものではなく、サイトがどれだけの負荷に耐えられるのか、その仕組みやリソースがどれだけ明確に示されているかです。

運用上の不確実性は、気づかないうちにコストを押し上げる要因です。スケーリングの判断を難しくし、マーケティング施策の効果を不安定にし、ITチームに常に余計な負担をかけます。

こうした不確実性を解消するには、サイトの処理能力を正確に把握できる環境が不可欠です。たとえば、PHPの同時実行数が明確に示されていること、リソースが分離された環境で運用できること、そしてパフォーマンスをリアルタイムで確認できる仕組みが整っていることが重要になります。

Kinstaなら、在庫や財務を管理するのと同じように、サイトの処理能力やリソースを具体的な数値で把握しながら運用できます。「無制限のリソース」という言葉に惑わされるのではなく、現実的な指標に基づいて、ビジネスの成長に合わせた判断ができる環境を選びましょう。KinstaのWordPress専用マネージドクラウドサーバーをぜひ一度お試しください。