こんにちは！エンジニアの須原です。
今回はw2 ソリューションが大切にしているValueのひとつ、「失敗力」を体現したお話をしたいと思います！
シチュエーションは、某アパレルブランドが運営するECサイトのセール時です。集中アクセス対策としてフロントサイト（以下フロントと略）の負荷を軽減するために施策を行ったのですが、それによって見えた課題もありました。
あらすじ
当初このサイトでは、フロントの描写に時間がかかってしまうことで、セールなどでアクセスが集中した時、Webサーバーにリクエストが滞留してしまう事態が多発していました。
上記問題を解決するために、私はサイトへの訪問者（以下エンドユーザー）単位で描写を行わないデザインに関しては、キャッシュに保持する対応をとりました。
キャッシュに保持することにより、描写スピードは圧倒的に上がります。
キャッシュからデザインを取得するイメージを、絵画で例えてみましょう。
これまでは丁寧にゴッホのヒマワリを手書きで映していたのに対し、版画のように木版を駆使して一瞬で映すことができるようになりました。
差は歴然ですね。
この対応により、Webサーバーの負荷を約20％軽減することができました！
がしかし….
今回のキャッシュにデザインの情報を保持することで、ボトルネックが遷移することを予想ができていなかったのです。
結果、アクセスが集中した際、エンドユーザーはフロントへアクセスすることができませんでした。
フロントが落ちているときは503エラーが出たり、IISでさばききれずに文字化け画面が表示されたりなどなど…
原因はキャッシュにデザインの情報を保持させたことで、キャッシュ管理を行っているサーバーがいっぱいなってしまったことでした。
当時はキャッシュ管理を行っているサーバーのインスタンスを一時的にスケールアップすることで難を逃れることができました。その後、恒久対応としてキャッシュすべきデータの精査、キャッシュ管理を行うサーバーの見直しが行われています。
まとめ
私は今回の経験で、広い視野を持ちシステム構成を頭に入れてからトレースを行うことの重要さを改めて痛感しました。
何か解決したら、新たな問題が発生するという危機管理意識は常に持たないといけませんね。
ちなみに、キャッシュに保持するにあたって利用した技術は、Redisのフラグメントキャッシュです。
なにそれ？と思った方は下記リンクかQiitaなどで是非調べてみてください！！
https://qiita.com/suketa/items/eeae7e2196520323f694
以上、「失敗力」のお話でした。
コメント