【TECH BLOG】ZOZOTOWNにおける段階的なIstioサービスメッシュ化戦略

はじめに

こんにちは、SRE部 ECプラットフォーム基盤SREブロックの亀井です。

ZOZOTOWNのマイクロサービスプラットフォーム基盤（以下、プラットフォーム基盤）ではサービス間通信におけるトラフィック制御・カナリアリリース実装のため、Istioによるサービスメッシュを導入しました。現在は初期段階としてBFF機能を司るZOZO Aggregation APIとその通信先サービス間へ部分的に導入しています。

ZOZO Aggregation APIについては、以前に三神が紹介しているので、そちらの記事をご参照ください。

その後、Istioによる一貫したトラフィック制御・カナリアリリース実装を目的とし、プラットフォーム基盤全体へサービスメッシュを拡大しました。本記事ではその取り組みを紹介します。

なお、本記事はプロダクション運用中サービスのサービスメッシュ移行という運用目線の内容です。Istioの概要や選定理由などサービスメッシュ導入の背景にご興味がある方は、以前川崎が執筆した記事をご参照ください。

サービスメッシュ導入後の課題

ZOZO Aggregation APIと通信先サービスが部分的にサービスメッシュ化された状態を下図に示します。

「ZOZO Aggregation API → サービス」間はサービスメッシュ化され、Istioによるトラフィック制御・カナリアリリースが実装されました。しかし、プラットフォーム基盤全体ではサービスメッシュの導入は部分的であり、下図の様にサービスによってトラフィック制御・カナリアリリース手法に差異が生まれていました。サービスによって「設定が異なる」または「複数の設定を持つ」状態となっており、運用負荷が高く、二重にリトライが行われるなどの設定不備によるミスが起きやすい状況にありました。