ZOZOTOWNにおけるAkamai Application Load Balancerの導入

ogp

はじめに

こんにちは、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サーバにアクセスすると、ログアウトしてしまう、カートの中身がなくなる等の影響が発生します。

Sticky Session

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

既存iRule

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

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

speakerdeck.com

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

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

techblog.zozo.com

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

生じた課題点

Webサーバのキャッシュストアリプレイスを進める上で、下記の課題が出てきました。

  1. カナリアリリースができない
  2. 既存のiRuleが利用できない

 課題1:カナリアリリースできない

既存の構成においてキャッシュストアの設定をデプロイするためには、Webサーバをすべて新規Webサーバに入れ替える「ビッグバンリリース」をする必要がありました。ビッグバンリリースを行う場合、もしもの事故が発生した場合の影響は計り知れません。

ZOZOTOWNのアプリ向けに新規開発された機能は自社開発した「API Gateway」の加重ルーティング機能を用いてカナリアリリースをしています。ZOZOTOWNのWebサーバでも同様に安定したリリース手段が必要でした。

techblog.zozo.com

 課題2:既存のiRuleが利用できない

iRuleの設定は振り分け先のサーバがすべてStickyセッションを「有効化している」、または「すべて無効化している」の2択です。

今回のキャッシュストアのリプレイスでは、新規WebサーバはStickyセッションがないものの、旧WebサーバたちはStickyセッションがあるため、iRuleでは制御できません。そのため、通信するサーバを振り分けられるiRuleとは別の仕組みが必要でした。

Akamai Application Load Balancerの導入

前述の課題を、Akamai Application Load Balancer(以下、ALB)を導入することで解決しました。ALBの詳細は以下のドキュメントをご確認ください。

learn.akamai.com

選定理由

ALBを導入する際に必要な要件は以下の4点でした。

  • 既存構成を変えることなく導入できる
  • なるべく速く導入できる
  • 加重ルーティングができる
  • ヘッダーやパスによるルーティングが可能である

ZOZOTOWNでは、もともとCDNとしてAkamaiを利用していました。そのため、最も簡単かつスピーディに導入できる、十分な機能を持っているALBとしてAkamai ALBを選択しました。

導入後の構成

既存のCDNとオンプレミス基盤の間にALBを配置する構成にしました。

オンプレミス基盤には旧Webサーバ専用のオリジンと新規Webサーバ専用のオリジンを作成します。そして、どちらへ通信を流すか、また流す割合をどうするかはすべてALBで制御します。

トラフィック制御の例を1つ紹介します。各オリジンに流すトラフィック量を制御できるので、下図では旧Webサーバ専用のオリジンには90%、新規Webサーバ専用のオリジンには10%を流す制御をしています。なお、旧Webサーバのオリジンをdc1、 新規Webサーバのオリジンをdc2としています。

カナリアリリース

ALBは加重ルーティング、パスルーティング、ヘッダー等による制御ができます。新規サービスをリリースする際には加重ルーティングとヘッダー制御等を用いて流れる通信量を制御し、カナリアリリースを実現します。

また、今までiRuleを用いて制御していたトラフィックをALBで制御することにしました。下図のように、新たにBot専用のオリジンを作成し、ALBでUserAgentを元にトラフィック制御しています。これにより、既存のiRuleに囚われない制御が可能となりました。下図では、Bot専用のオリジンはdc3としています。

最終的には、Botからの通信はdc3に流し、通常のトラフィックはdc1dc2に設定した割合で流すことが可能になりました。

新規システム構成

導入による効果

ALBの導入・活用により、直近の課題であったセッション情報管理のリプレイスにおいて、カナリアリリースを実現できました。現在は、少しずつ割合を変えながらリリースしている状態です。リリースによっては、エラーを検知して切り戻しが実際に発生し、導入した恩恵を受けられています。

また、ALBに今までトラフィック制御に利用していたiRuleの機能を移しました。ZOZOTOWNの歴史と共に肥大化したiRuleは運用コストが高く、場合によってはiRuleの設定の影響でZOZOTOWNにまったくアクセスできなくなる可能性もありました。そのようなシステムの制御をALBに移したことで以下の2つの効果を得ることができました。

  • AkamaiのStaging環境での事前確認が可能になった
  • トラフィック制御の設定が容易になった

今まで負担となっていたiRuleの運用をなくし、安全かつ正確な運用ができるようになりました。

まとめ

ALBを導入することで既存の構成をほぼ変えることなく、よりモダン、かつ安定感のある環境を整えることができました。

また、導入によって以下の効果を得ることができました。

  • リリース方式の改善
  • 既存構成で運用負荷の高かったシステムからの脱却
  • リプレイスに柔軟に対応できるシステムの実現

今後はALBを用い、さらにリプレイスを加速させていきます。

最後に

ZOZOのシステムは現在リプレイス真っ只中です。一緒にリプレイスへ取り組んでいただける方、興味がある方は以下のリンクから是非ご応募ください。

hrmos.co

また、カジュアル面談も随時実施中です。「話を聞いてみたい」のような気軽な感じで大丈夫です。是非ご応募ください。

hrmos.co

カテゴリー