アクセス集中対策

キャパシティを超えるほどのアクセス集中が発生すると、ユーザーには様々なエラーが返却されることになります。エラーが発生するということは、機会損失が発生するということです。

「504 Gateway Timeout」
サーバー内の処理時間が長すぎる場合に発生します。ELB＋Amazon EC2の構成の場合に、EC2インスタンスからの応答が所定の時間を超過した場合によく見られます。

「503 Server Unavailable」
サーバーサイドのどこかで制限がかけられている状態です。レンタルサーバーの利用中に、アクセス集中が発生すると見かけるエラーです。これは、他のユーザーに影響がでないように、サーバーの手前で強制的にエラーを返却しています。

「500 Internal Server Error」
サーバー内部でエラーが発生しています。なんらかのエラーが原因で、正常に処理が行われなかった可能性があります。

AWSでは、アクセス集中などの高負荷時に有効なサービスが多数用意されています。

「Amazon EC2 Auto Scaling」
負荷状況に応じてEC2インスタンスを増減させ、キャパシティの確保を自動で行います。アクセス集中の検知から実際の拡張完了まである程度時間がかかりますところに注意が必要です。

「Amazon CloudFront」
EC2インスタンスやELBの前段に配置し、静的なコンテンツを高速にキャッシュ配信します。phpなどの動的なコンテンツは無理ですが、画像などの静的コンテンツの処理負荷をオフロードすることが可能です。

「スケールアップ」
手動対応になりますが、短時間でのインスタンスタイプの向上も可能です。ただし、インスタンスタイプの変更時には再起動が必要になります。

アクセス集中対策に有効なサービスを紹介しましたが、使いどころをしっかり押さえる必要があります。誤った使いどころで使ってしまうと、逆に被害が増えてしまう可能性があるので注意しましょう。

使いどころの判断基準は、「ボトルネックに対する対策」になっているか？です。

ボトルネックとは、発生している問題に最も影響している部分のことです。画像の砂時計の砂の落ちる速度を早くしたい、と考えた場合は、ボトルネックになるのは最もくぼんでいる部分になります。くぼんでいる部分の幅を広げることで、砂の落ちる速度を早くすることが可能です。

良かれと思って、底の部分を大きくしたり小さくしたりしても落ちる速度に影響はしません。

それぞれのサービスはどこがボトルネックになったときに有効なのでしょうか？

「Amazon EC2 Auto Scaling」
EC2インスタンスの数を増減させるサービスなので、CPUなどのリソースが不足している場合に有効な手段となります。逆に言うと、RDSなど、EC2インスタンス以外の箇所がボトルネックとなっている場合には効果を発揮しません。

「Amazon CloudFront」
静的コンテンツをオフロードできるので、WEBサーバーの接続数がボトルネックになっている場合に有効な対策です。反対に、アプリケーションの処理負荷が問題の場合は、有効な対策とはなりません。

「スケールアップ」
Auto Scalingと同様に、CPUやメモリなどのコンピューティングリソースが不足している場合に有効です。設定値の問題で、リソースが使い切れていない場合は効果がありません。

不適切な対応をしてしまうと、どうなるでしょうか？

最も影響が少ないパターンは、「効果が一切出ずに、余計な費用がかかる」パターンです。WEBサーバーがボトルネックなところを、DBサーバーの対策を取ってしまうような場合に発生します。利用料金以外は、良い方向にも、悪い方向にも影響を与えません。

最も影響が大きいパターンは、「悪影響が出たうえに、余計な費用がかかる」パターンです。DBサーバーがボトルネックなところを、WEBサーバーの対策を取ってしまうことで、DBサーバーにより大きな負荷がかかってしまうような場合に発生します。このパターンになると、費用を払って自ら被害を拡大させていることになります。最も避けたいパターンです。

このことから、ボトルネックを把握し、ボトルネックに対する対策を実施することが重要ということがわかります。

インフラだけでなく、アプリケーション側でも対策を取ることが可能です。インフラとアプリケーションどちらで対策をとる方が好ましい結果になるでしょうか？

「インフラ」
AWSの登場で、費用さえ許容すれば、インフラキャパシティをほぼ無限に拡張することが可能になりました。インフラは費用をかければかけた分だけキャパシティの向上が可能です。vCPUを4から8にすれば、単純に2倍の効果が期待できます。

「アプリケーション」
アプリケーションは処理内容によって、改善効果（悪化の効果）が大きくなります。2重ループをしている場合、データ量が2倍になれば処理負荷は4倍、データ量が3倍になれば9倍の処理負荷となり、指数関数的に性能が変化していきます。

つまり、可能な限りアプリケーション側で対応することで、最終的にはコストパフォーマンスの高い対策が可能になります。

インフラだけでなく、アプリケーション側でも対策を取ることが可能です。インフラとアプリケーションどちらで対策をとる方が好ましい結果になるでしょうか？

「インフラ」
AWSの登場で、費用さえ許容すれば、インフラキャパシティをほぼ無限に拡張することが可能になりました。インフラは費用をかければか高負荷対策を必要なサイトのインフラを運用するポイントは次の2点です。

・ 闇雲なサービス利用はさける
・ 事前シュミレーションをしっかりと行う

闇雲なサービス利用はさける
サービスを理解せずに、やみくもな利用はさけましょう。たとえば、Auto Scalingであれば、ファイル共有方法、ログ管理、セッション管理方法など、実施のために様々な考慮が必要となります。場合によっては、アプリケーション側の改修が必要になることもあります。

事前シュミレーションをしっかりと行う
ボトルネックに対する対策のみが効果を発揮します。事前に最初に発生するボトルネックを把握することで、適切な対策をピンポイントで取ることが可能です。システムのボトルネックは何になるのか？という観点で、負荷テストを事前に実施しておくのが望ましい対応となります。

ディーネットでは、負荷テストサービスを提供しております。

負荷テストを実施することで、システムのボトルネックの特定を行うことができます。ボトルネックの特定ができるので、高負荷状態になったときに実施すべき対策を事前把握することが可能です。また、対策実施後のボトルネックがどの程度の性能向上した後に発生するかの把握もできるので、万全な事前準備を行うことができます。

対策を実施するときには、適切なサービス理解が必要です。AWSに精通した負荷対策をとることができるエンジニアも多数在籍しております。そのため、ポイントを絞った形で、適切な対策の実施が行えます。

ローンチ前の負荷テストはもちろん、ローンチ後の高負荷時のトラブル再現等も対応しております。

AWSは、インフラの拡張が非常にしやすいパブリッククラウドです。

適切なタイミングで、適切なサービスを利用することで、インフラのキャパシティをほぼ無制限に拡張することが可能です。しかしながら、不適切なタイミングで、不適切な使い方をしてしまうと、システム全体としてのキャパシティが拡張しないばかりか、悪影響を引き起こす可能性があります。

コストパフォーマンスの高い対策を行うためには、事前準備をしっかりと行い、サービスを熟知することが必要です。

WEBサイトの高負荷対策にお悩みなら、ディーネットへご相談ください。