はじめに

こんにちは、SRE部の秋田と鈴木です。ZOZOTOWNのオンプレミスとクラウドの運用・保守・構築に携わっています。

現在、ZOZOTOWNはリプレイスプロジェクトの真っ只中です。そのため、いくつもの壁にぶつかりつつも、それらを1つずつ解決してプロジェクトを進めている状況です。

オンプレミス基盤上で動くWebサーバのリプレイスを行う際に、既存構成では十分なテストを行うことができませんでした。本記事では、その課題をAkamai Application Load Balancerを導入することで解決したアプローチを紹介します。これにより、既存のシステム構成を大きく変更することなく、より柔軟にテストやシステムの変更を加えられるようになりました。

既存構成

ZOZOTOWNのWebサイトは自社で保有しているオンプレミス基盤の上で稼働しています。そのため、ユーザはZOZOTOWNにアクセスする際、まずはCDNであるAkamai Intelligent Edgeにアクセスします。そして、Akamai Intelligent Edgeからオンプレミスで管理している F5社のネットワーク機器であるBIG-IPを通ることでWebサーバに到達します。

既存のZOZOTOWNではWebサーバのメモリ領域にセッション情報を保持しており、ユーザを常に同一のWebサーバに振り分ける必要がありました。なお、セッション情報にはログイン認証情報やカートの情報が含まれています。そのため、今までアクセスしていたWebサーバと異なるWebサーバにアクセスすると、ログアウトしてしまう、カートの中身がなくなる等の影響が発生します。

前述の理由のため、同一のWebサーバへユーザがアクセスするよう、BIG-IPのロードバランサでStickyセッションを用いてアクセスを制御していました。他にも各種Botからのトラフィック等をより詳細に制御するために、BIG-IPのiRuleを用いていました。しかし、既存のiRuleはZOZOTOWNの歴史と共に肥大化しており、運用コストが高くなっていました。

Webサーバがセッション情報を持つステートフルな状態ではスケーリングに手間がかかります。また、iRuleに依存したトラフィック制御は今後の運用で負債になる可能性がありました。Webサーバのクラウド移行や今後のリプレイスの障壁となる前に脱却することが望ましいです。

より詳細な構成は、下記資料で紹介しているので併せてご覧ください。

キャッシュストアのリプレイス計画

弊社では中期目標としてこのセッション情報のリプレイスを掲げ、Amazon ElastiCache（以下、ElastiCache）にリプレイスするプロジェクトを進めてきました。最初の段階ではアプリケーションレイヤーで使用しているキャッシュストアをリプレイスし、ElastiCacheに関するノウハウの蓄積、開発や運用の体制を整備してきました。

次の段階では、既存システムの課題であるWebサーバがメモリ領域に保持していたセッション情報をリプレイスします。しかし、新たに作成した「セッション情報がメモリ領域上にないWebサーバ」と「既存のWebサーバ」を入れ替える際に課題が生じました。

続きはこちら