BtoC向けのインフラ構築について

勉強会のメモ

大手が手掛けるBtoCのWebサービスだと、オープン時やセールなどといった、特殊イベントのアクセス数が予想しづらい。

このため、アクセス想定数と実際の数に開きがあると、サーバーダウンなどの事態を招く。

サーバーダウンなどの事態を招くとSNS炎上などで、風評被害を受けやすくなる。

また、緊急対応に対応時間を多く割かなければならない。

アクセス数や商品データといった、Webサービス側で提供するテーブルデータ規模などを想定して、サーバースペックなどの算定を行う。

この場合、アクセス規模を大まかにでも把握しておくことが肝要である。

非機能要件、リスク概要をしっかりと客先に説明し、規模に関してはしっかりと確認しておく必要がある。

また、目先のランニングコストでスペック選定を行うのではなく、将来性を見据えなければならない。

〇対策

・Webサービス開始前の性能検証

オープン時と同一データでレスポンスタイムの検証や負荷試験の実施

※オープン後は本番環境と同一データの検証環境を用意する

　→これにより追加開発時に性能劣化の気づきが得られる

・クライアントとイベントスケジュールの共有のルール化

セッション制限、キャッシュ対策、スペックアップやスケールアウトなど

　→事前の作業計画が可能

これにより、事前に作業やインフラ変更の金額提示ができ持ち出しコストも抑えることが可能。

〇インフラ設計のポイント

頻繁にアクセスされるページやある程度データ反映に時間が空いてもよくて、アクセス負担を効率よく減らせるページ（例：TOPや商品ページ）のページキャッシュ

※Webサーバーへのリクエストを減らすことができるため、ある程度までスペックを増強せずアクセス増加に耐えることができる可能性あり

・LoadBalancer

初期導入しておくことでアクセス増加時の対策は取りやすい。

例：流量制限、エラーページの振り分け

・共有DBのメモリ

共有DBの利用に際しては、現状のメモリ使用量などのリソースの空き状況の確認は必要

※ほかに共用DBを使用しているサービスでレスポンス遅延が発生する

・非機能要件定義

IPA機能要求グレード参照

メモってこ！