この記事を参照している方は、どこかのサイトを表示しようとして下記エラー「Service Temporarily Unavailable（通称503エラー）」が出力されているからでしょう。
Service Temporarily Unavailable 503エラー（以下503エラーと呼ぶ）とは何か、対策はどうしたら良いのかを当記事で紹介いたします。
解説動画
目次
- はじめに
- 503エラーとは
- 503エラーが出るロジック
- 503エラー対策詳細
・対策その１：サーバーにお金をかける
・対策その２：リクエスト数を少なくする
・対策その３：クライアントキャッシュ
・対策その４：CDNを導入する
- 共用・専用サーバー選定の目安
- 最後に
はじめに
今回は大きくわけて2タイプの方が当記事を読んでいただいていると思っています。
【A】どこかのサイトを表示しようとして503エラーがでている方
【B】自身が運営しているサイトに503エラーがでている、もしくは503エラーが頻発し困っている方
503エラーは、Webサイトに多くの人からアクセスが集中し、Webサイトが一時的に閲覧できない状態です。他にもWebサイトがメンテナンス中で503エラーを出すサイトもありますが、昨今の場合はほとんどがアクセス集中により、サイト閲覧がしにくい状態のことです。
例えていうと、かわいいネズミがいる人気テーマパークも、お正月、クリスマスなどに来場者が集中するため入場制限をします。Webの世界でもアクセスが集中すると503エラーを出し、閲覧できる人数を制限しています。
503エラーの対策ですが、【A】の「どこかのサイトを表示しようとして503エラーが出力され、サイトが閲覧できないユーザー」は、特に何もすることができませんので、当記事の「いいね」ボタンを押してから、そっと当記事を閉じ、しばらく経ってからアクセスしてみてください。
【 B】の「自身が運営しているサイトに503エラーが出るまたは、頻発している」場合は、503エラーがでないよう対策をする必要があります。
まずは、503エラーが何かを知り、その対策を説明していきたいと思います。
503エラーとは
503エラーとは、HTTPステータスコードです。
HTTPステータスコードとは、普段何気なくWebサイトを表示していますが、コンピュータ同士はHTTPプロトコルを使って通信し、お互いの状態をステータスコードにより正常に処理されたどうかをチェックしています。このステータスコードはHTTP/1.1の仕様にて取り決められています。
503エラーとはステータスコードが出力したエラーコードで、Webサーバーへの同時アクセス数の制限をこえた場合や、Webサーバーがメンテナンス中などにより、リクエストに応答できない場合に出力されるエラーコードです。
Webサーバーがリクエストに応答できないということは、Webサイトが表示できないということです。アクセスが集中し「Webサイトが落ちている」という現象はこちらをさします。
503エラーが出るロジック
アクセスが集中するとWebサーバーは503エラーを出力します。これはどのような現象なのかもう少し具体的に見ていきたいと思います。
今回はテスト用にサーバースペックが発揮できないようにチューニングしたWebサーバー1台と、テスト用のWebサイトを用意しました。
まずCSSファイル8個、画像8枚を読み込んだサイトを表示します。
画面右下に出ていますが、このページをロードするのに31秒かかりました。この時、パソコンとWebサーバー間は何をしているのでしょうか。
単純にWebサイトを表示するだけでも裏側では下記の工程を得て画面を表示しています。
Step1：閲覧者が、WebサイトのデータリクエストをWebサーバーに送る
Step2：リクエストに応じてWebサーバーがデータを用意
Step3：Webサーバーが結果を返答
Step4：結果を受信したクライアントPCが、送られて来たデータを元にサイトを表示。
さらに今回はCSSファイル8個、画像8個を取得していますので、合計16個のデータ取得リクエストをサーバーに送っています。
リクエストを受けたWebサーバーは、リクエストに応じてデータをクライアントにリターンしますが、リクエストが多すぎるとサーバーに負荷がかかり、サーバーがダウンしてしまいます。
サーバーがダウンしないためにも、1Webサイトあたり同時に受けられるリクエスト数を各ホスティング会社は制御しています。例えばこの受けられるリクエスト数を上げて同じページにアクセスしてみます。
すると同じページが154ms(0.15秒)で表示されるようになりました。
ユーザーのアクセス数が多くなると、リクエスト数も多くなり、多くのリクエストが待機します。この待機状態の数や、待機時間の長さを元に、各サーバー会社はサーバーがダウンする前に503エラーを出しています。
503エラー対策詳細
503エラー対策は事前に対策をしておくのが、もっとも重要です。
現状503エラーが出力されてしまい、このページを閲覧している方の手段としては、アクセス過多がおさまるのを待つか、サーバー会社に問い合わせ、同時接続数などの設定を変更してもらうなどが考えられます。
同時接続数などの設定値は、各社によって変更できる、できないなどあると思いますが、一旦相談してみると良いでしょう。
（弊社CPIでもコールセンターにお問い合わせいただきますと、スタッフが相談させていただきます。CPIサポート）
それと冒頭で紹介したエラー画面が表示されているのであれば、503エラーページを制作会社に作ってもらうなどが考えられます。
では、事前対策として503エラーが頻発しないようにどうしたら良いかを下記で紹介いたします。
対策その１：サーバーにお金をかける
まず一つ目の対策はWebサーバー側で処理できる同時アクセス数を増やすことです。
例えば共用型サーバーを借りていて、月額500円のプランを借りているのであれば、1つ上の月額1,000円のプランに変更したり、専用サーバーに変更したりすることです。(サーバーの種類については「今さら聞けないサーバーの種類」の記事を参照ください)
一般的にWebサーバーの月額費が増えることで、ホスティング会社もサーバーの筐体にかけられるコストも上がり、より良い筐体を用意することができます。より良い筐体にWebサイトが乗ることで、さばけるアクセス数も上がります。
例えていうなら5万円で買ってきたパソコンと、20万円で買ってきたパソコンは、処理速度が早いのはどちらですか？と聞かれたら、もちろん皆さんは20万のパソコンと答えるでしょう。
対策その２：リクエスト数を少なくする
WebサイトにアクセスしたときにCSS、JS、画像ファイルなど１つのファイルに1つのリクエスト（セッション）が必要です。このリクエスト（セッション）数を少なくすることもとても重要です。例えば今回は8つのCSSと8つの画像をロードしています。8つのCSSを一つにまとめ、汎用的によく使う画像パーツなどはCSSスプライトでまとめておくなどが効果的です。
試しにテストページを1つのCSS、1つの画像に変更すると、107ms（0.1秒）になりました。
対策その３：キャッシュ対策
Webサーバーにアクセスしてきたときにサーバーがクライアントの要求に対してすばやく応答することができれば、それだけ処理できる同時アクセス数を増やすことができます。
どこでキャッシュを持たせるかなんですが、大きく分けると3通りあります。
- クライアントPCにキャッシュを置く
- リクエスト送信時のクライアントPCから、ウェブサーバーの間にキャッシュを置く
- ウェブサーバーの内部にキャッシュを置く
少し長くなりそうですが、一つずつ見ていきましょう。
クライアントのPC上にキャッシュを置くですが、クライアントのブラザで設定ができるのと、HTTPヘッダ情報にキャッシュを指定することでできます。前者はクライアントの設定によるので割愛します。
HTTPヘッダにキャッシュコントロールの記述を入れる。
HTML4.xまで
下記コードを<head>〜</head>間に追加する必要があります。
<meta http-equiv="Pragma" content="Private"> <meta http-equiv="Cache-Control" content="Private"> <meta http-equiv="Expires" content="Fri, 31 Dec 2014 23:59:59 GMT">
※この設定はユーザー側にキャッシュを置くため、コンテンツ配信側で制御がきかなくなることから、一般的には「no-cache」を指定することが多いです。
Expiresは、キャッシュの有効期限で、RFC1123の日付フォーマットで指定しなくてはならない。
HTML5から
htmlタグにmanifest属性を含めます。
<html manifest="example.appcache">
レンタルサーバーなどではMIMEタイプ（text/cache-manifest）を、.htaccessに追加します。
.htaccess
AddType text/cache-manifest .appcache
マニフェストファイル
example.appcache
CACHE MANIFEST #20160506:v1.001 index.html css/test.css img/test.jpg NETWORK: *
1行目：CACHE MANIFEST
2行目：#はコメントアウトですが、日付やバージョン番号を記載するのが一般的です。キャッシュしているファイルが更新された場合、マニフェストファイルを更新する必要があります。その際にバージョン番号や日付を変更し、クライアントPCに再キャッシュを促します。マニフェストファイルの更新が無い場合はCSS、JSファイルなどの再キャッシュは行われません。
4行目以降よりキャッシュさせたいファイルを記述します。
NETWORKセクションに列挙したファイルやURLはキャッシュを利用しません。
HTML5以降では、MANIFESTを利用しページをキャッシュさせます。キャッシュを行うことで、オフラインでもページを閲覧できるようになります。
対策その４：CDNを導入する
クライアントPCから、ウェブサーバー間にキャッシュを置く方法も有効的です。CDNの導入は下記業者などのCDN（Contents Delivery Network）を導入するのが手軽でてっとり早いでしょう。
下記の図はクライアントPCとウェブサーバー間にキャッシュサーバーが置かれた一例です。静的なコンテンツはキャッシュサーバーから取得し、それ以外の動的コンテンツなどはウェブサーバーから取得する例です。
クラウド型のCDNの場合、アクセス数が増えるシーズンや、日によって申し込むことが可能です。
たとえば普段はさほど良いサーバーを契約していなく、2日後に会社のプロダクトが発表され、多くのアクセスが予想される場合。CDNを申し込むことで、急なアクセス過多にも対応することが可能となります。
さらに、Incapsulaの例でいうとパフォーマンスの設定で、静的コンテンツだけをキャッシュさせるか、動的コンテンツを含めてキャッシュするかの設定を行うことが可能ですので、サイトの特性に合わせたキャッシュ方法を設定することが可能です。
ウェブサーバーの内部にキャッシュを置くですが、こちらは色々な方法があります。
例えば、CMSを利用しているとしましょう。一般的なCMSは、ページのリクエストがあると、Webサーバーが画像などの静的ファイルと、記事などの動的コンテンツを用意します。この間にApacheから、CMSにリクエストを行い、CMSはPHPでリクエストを処理、PHPから動的コンテンツが格納されているMySQLにアクセスしデータを取得します。
リクエストがある度に準備しているこの動作をキャッシュします。
WordPressであれば、キャッシュ対策用のプラグインをインストールするもの有効な手段です。「WordPress キャッシュ対策」などで検索をすると様々な情報を得ることができます。
Drupalであれば、管理画面から、「環境設定 > パフォーマンス」からキャッシュの設定をすることができます。
以上のように様々な方法で503エラーの対策を行うことが可能です。
他にも細かく言うと対策は色々とあります。「サイトパフォーマンス 最適化」などで検索すると多くの情報を得ることが出来ますので、気になる方は見てみるのも良いとおもいます。
共用・専用サーバー選定の目安
503エラー対策の１つとして、サーバーにお金をかけると書かせていただきましたが、できるだけサーバーにはお金かけたく無いというのが心情ではないでしょうか。
弊社の場合共用型サーバーの場合 3,800 円（税別）/月〜、専用サーバーの場合 9,000 円(税別)/月額～です。もちろん専用サーバーの方が503エラーになりにくいです。
※サーバーの種類が分からない方はこちらの記事を参照ください。（今さら聞けないレンタルサーバーのサービス種類を分かりやすく解説しました）
では、各社で共用型サーバー、専用型サーバーがあるが、どちらを選定したら良いか迷うところです。そこで一つの目安にしていただきたいのが下記の数値です。
※この数字はあくまでも目安です。数値を保証するものではありません。
※各社により設定差や、筐体差があるため、大体の基準とお考えください。
月間のページビューによる目安
弊社（CPI）のサーバーログを確認したところ、PV数が多いサイトで「100,000PV / 月」程度でした。負荷状況を見ながら、それ以上のユーザーには専用サーバーへの乗り換えなどを弊社ではご案内しています。
弊社の実績上、共用型サーバーの場合「100,000PV / 月」くらいのアクセス数を見込めるのであれば専用サーバーを検討した方が良いでしょう。
ここでアレ？と思ったかたもいるのではないでしょうか。
記事の前半ではリクエスト数が多くなると、サーバーに負荷がかかり、503エラーをリターンすると説明いたしました。1時間に100,000PV のアクセス集中があった場合にも503エラーは出ます。
１ヶ月ならして「100,000PV / 月」のアクセスがある場合は良いですが、あまり現実的ではありません。
同時接続数による目安
そこで参考になるのが同時接続数です。同時接続数は最大で何人同時にサーバーに接続するかという数値です。
この数値も選定の目安にすることができます。
同時接続数の求め方は下記公式で割り出すことができます。
「PV / 1h サイト表示時間 3600 = 同時接続数」
PV / 1h算出方法
Googleアナリティクスなどで、一旦2年分程度のデータを表示し、一番アクセスが多かった日を確認します。データ表示日を、一番アクセスが多かった日に設定し、1時間あたりのページビュー数を確認します。
ここでは「53072/1h」が一時間あたりのアクセス数です。
サイト表示時間算出方法
Chromeブラウザで該当サイトを表示し、画面上で右クリックし「検証」を選択します。画面下か、右に検証用画面が出力されますので、「Network」を選択します。Network画面の下方に「Load: 3.81s」とサイト表示時間が出力されます。
これを公式に代入すると同時接続数を求めることができます。
50000 3.8 3600 = 52.7
52.7という数値が求められました。
もちろん各社により、どれくらいの同時接続をさばけるかは違ってきますが、だいたい20〜30以上を目処に専用サーバーの検討をした方が良いでしょう。あくまでも目安ですが、ギリギリのサーバーを借りるのではなく、余裕を持ったサーバー選定をお勧めします。
最後に
キャッシュ対策は、様々な方法があり、様々な弊害もあります。例えばページを頻繁に更新するサイトなどの場合、ページを更新しても、すぐに反映されないなどがあり不向きな場合もあります。一番手軽に行えるのがサーバーをワンランク上のサーバーにすることです。
弊社のShared Plan ACE01は共用型の中では、比較的アクセスをさばけるよう設計されています。是非一度弊社のサーバーも検討ください。
弊社の専用サーバーですと、こちらの記事にどれくらいのアクセスがさばけるかの検証結果が載っていますので参考にしてみてください
「CPIの専用サーバー(CHM01)の実力を試してみた」
