アクセス集中への対策
Webサイトがバーストするアクセスパターンをつかんだところで、次に、アクセスが集中した場合の対策方法をいくつか見ていきましょう。
CDNサービスの活用
まず効果が絶大なのが、Akamaiに代表されるCDN（Contents Delivery Network）サービスの利用です。css、js、gifなどの静的コンテンツをキャッシュすることで、サーバ負荷やネットワーク帯域の圧迫をほぼ回避できます。突発的なアクセス量増加を予測しづらいBtoCサイトでは、利用はもはや必須といえるでしょう。全ページで見たグラフ②-2のような例では特に有効で、静的コンテンツの負荷をオフロード（軽減）できれば、サーバ側のチューニングは動的生成されるコンテンツに注力できます。
また、CDNはユーザから最寄りのエッジサーバからキャッシュコンテンツを配信してくれるため、インターネットのレイテンシに起因したレスポンス遅延の改善も期待できます。
Webサーバ上でのコンテンツ圧縮
最近ではAkamaiなどのCDNでコンテンツのgzip圧縮が可能になってきましたが、Webサーバ上でのgzip圧縮も、アクセス集中による帯域圧迫への対策として有効です。Apacheであればmod_deflateを使って比較的簡単に設定可能ですが、意外と利用されていません。CDNを利用していない場合、即効性が非常に高い対策となります。
ただし、圧縮によりサーバのCPU負荷が多少なりとも上昇するので、サイトリリース後に慌てて性能試験で影響を見る羽目にならないよう、事前の負荷試験でCPUキャパシティの検証までしておくことが必要です。
キャッシュによるDBアクセスの回避
JSPやCGIなどを使ってWebページを動的に生成するAPサーバ（アプリケーションサーバ）では、DBサーバへのアクセスを極力回避するように、キャッシュを保持できる設計にすることが望ましいです。例えば、商品の価格やカタログ情報などのDBデータを数分でもキャッシュとして保持できれば、APサーバの後ろに控えるDBサーバを、アクセス集中から格段に守りやすくなります。Apache Solrなどの検索エンジン（最近はどんなサイトでも必ず持っていますよね）についても同様で、なるべく検索エンジン側でデータを保持するようにするべきです。
ただし、これには情報のリアルタイム性を失うというトレードオフを発生させます。「商品ページで見ていたときと購入画面で商品の価格が違う！」というユーザエクスペリエンス上のデメリットが生じるということです。したがって、業務要件上、お客様から難色を示される可能性が一番高い対策でもあり、エンジニアとしての矜持をかけた渾身の説得が必要になります。エンジニア側がこの調整に負けて、キャッシュがわずか15秒で失効するというサイトも見たことがありますが、思わず「これじゃキャッシュの意味がないよ……」と天を仰いだものです。
なぜこの対策にそこまで気合いを入れるかというと、アクセス負荷がDBサーバにまで行ってしまったら、それはもう負けを意味するからです。ボトルネックになりやすいうえ、WebサーバやAPサーバと違ってスケールアウトしづらいDBサーバは、BtoCサイトの性能において最大の弱点になります。「本丸」であるDBサーバへのアクセスが極力発生しないアーキテクチャとすることが、バースト防止の大方針なのです。
