トール・マカベッチのアンサーソング付き

1. ZOZOTOWN の
Cloud Native Journey
～ 旅立ち編 ～
株式会社ZOZOテクノロジーズ
Chief ZOZOTOWN Architect
岡 大勝
Copyright © ZOZO Technologies, Inc.
TOKYO 2019

2. © ZOZO Technologies, Inc.
株式会社ZOZOテクノロジーズ
Chief ZOZOTOWN Architect
岡 大勝
NoOps Japan 主催
アーキテクト（設計屋）
@okahiromasa
2

3. © ZOZO Technologies, Inc.
https://zozo.jp/
・ 日本最大級のファッションショッピングサイト / アプリ
・ 1,200以上のショップ、7,000以上のブランドの取り扱い
（2019年3月末時点）
・ 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着
商品を掲載
・ 即日配送サービス
・ ギフトラッピングサービス
・ ツケ払い など
3

4. © ZOZO Technologies, Inc.
4
2004年 ZOZOTOWN オープン

5. © ZOZO Technologies, Inc.
5
ZOZOTOWNはアーキテクチャを変えずに規模を拡大してきた

6. © ZOZO Technologies, Inc.
6
ZOZOTOWNはアーキテクチャを変えずに規模を拡大してきた
出世しつくした
ワカシ
イナダ
ワラサ
ブリ

7. 7
次はもっと強靱なシステムか？
©TAITO

8. 8
ZOZOTOWN が目指すのは、”スイミー”
100匹やそこら食べられても
サービスに影響しない。スイミー. レオ＝レオニ／作. 谷川俊太郎／訳 1969年出版

9. © ZOZO Technologies, Inc.
9
ZOZOTOWN 疎結合化/自律分散化プロジェクト
●スケーラブル マイクロサービス
●マルチクラウド x インタークラウド
アーキテクチャ設計方針

10. © ZOZO Technologies, Inc.
10
スケーラブル マイクロサービス

11. © ZOZO Technologies, Inc.
11
今のZOZOTOWNは「スケーラブルなモノリス」
2004年

12. © ZOZO Technologies, Inc.
12
今のZOZOTOWNは「スケーラブルなモノリス」
2017年

13. © ZOZO Technologies, Inc.
13
モノリス（密結合システム）のメリット
●新規サービスの開発に適している
○小さな組織（コンウェイの法則）
○理解不足のドメイン（存在しないものの分割は困難）
●性能を向上させやすい
○少ないオーバーヘッド
○シンプルなスケールアップ戦略
●高い運用性
○シンプルなリリース、監視、障害対応

14. © ZOZO Technologies, Inc.
14
ZOZOTOWNのモノリス起因の課題
●運用作業や障害の影響範囲が大きい
●システム全体が特定技術へ依存
●コード量増加による複雑さの増大
●蓄積する Dead Code / Dead Data
●新規メンバーのキャッチアップが困難
●etc..

15. © ZOZO Technologies, Inc.
15
ZOZOTOWNがマイクロサービスを目指す理由
●新しいビジネスチャレンジの基盤
●多様な人材と働き方への適応
●多様化する技術の活用促進
（技術的チャレンジの基盤）
●全体を止めない/全体が止まらない

16. © ZOZO Technologies, Inc.
16
マイクロサービスに向けたアプローチと進捗

17. © ZOZO Technologies, Inc.
17
Monolith to Microservices
Migration Patterns
➢Strangler Application
➢UI Composition
➢Branch By Abstraction
➢Decorating Collaborator
➢Change-Data Capture
➢Parallel Running
http://shop.oreilly.com/product/0636920233169.do

18. © ZOZO Technologies, Inc.
18
Strangler Application Pattern
機能の特定の部分を新しいアプリケーションやサービスに徐々に置き
換えることで、レガシーシステムを段階的に移行する。
レガシーシステムからの機能が置き換えられていくと、新しいシステム
は最終的に古いシステムの機能すべてを置き換え、古いシステムを停止
できる状態になる。
ストラングラーツリー
（絞め殺しのイチジク）
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/strangler
http://bliki-ja.github.io/StranglerApplication/

19. © ZOZO Technologies, Inc.
19
マイクロサービス化の進捗 - 1/4

20. © ZOZO Technologies, Inc.
20
マイクロサービス化の進捗 - 2/4
●SP処理をマイクロサービスに移植
●Strangler Facade 経由でサービスへアクセス可能に

21. © ZOZO Technologies, Inc.
21
マイクロサービス化の進捗 - 3/4

22. © ZOZO Technologies, Inc.
22
マイクロサービス化の進捗 - 4/4
●ROトラフィックのマイクロサービス切替成功(100%)
●ROの残SP移植進行中
（予定）

23. © ZOZO Technologies, Inc.
23
ZOZOTOWNは負荷変動が大きい
（％）

24. © ZOZO Technologies, Inc.
24
CNCF Cloud Native Definition v1.0
Cloud native technologies empower organizations to
build and run scalable applications in modern,
dynamic environments.
These techniques enable loosely coupled systems
that are resilient, manageable, and observable.
Combined with robust automation, they allow
engineers to make high-impact changes frequently
and predictably with minimal toil.
https://github.com/cncf/toc/blob/master/DEFINITION.md

25. © ZOZO Technologies, Inc.
25
CNCF Cloud Native Definition v1.0
Cloud native technologies empower organizations to
build and run scalable applications in modern,
dynamic environments.
These techniques enable loosely coupled systems
that are resilient, manageable, and observable.
Combined with robust automation, they allow
engineers to make high-impact changes frequently
and predictably with minimal toil.
https://github.com/cncf/toc/blob/master/DEFINITION.md
スケーラブル
アプリケーション
クラウド
プラットフォーム
疎結合システム
自動化
トイルが少なく
頻繁な変更も怖くない日常

26. © ZOZO Technologies, Inc.
26
Aggregate APIs (BFF)
Raw APIs
Standard Traffic
スケーラブルアプリケーションとデータストア
スケーラブルアプリケーション
＝高い回復力を持つ
アプリケーションインスタンス

27. © ZOZO Technologies, Inc.
27
Aggregate APIs (BFF)
Raw APIs
Burst Traffic
スケーラブルアプリケーションとデータストア
●アプリケーションインスタンスだ
けでなく、データストアも動的に
スケールさせたい
●VM(Node)は意識したくない
●数秒でのスケールが理想
アプリケーションは
瞬時にスケール

28. © ZOZO Technologies, Inc.
28
➢軽量なフットプリント/高速な起動（AOT）
➢ステートレス
➢非同期処理
➢冪等性（リトライ性）
➢多様な環境へのデプロイ
（コンテナ/PaaS/サーバレス）
➢分散・非生存を前提としたObservability
（分散トレーシング）
スケーラブルアプリケーションの設計原則

29. © ZOZO Technologies, Inc.
29
マルチクラウド x インタークラウド

30. © ZOZO Technologies, Inc.
30
なぜマルチクラウドなのか
●革新と安定のバランス
●完全なものなどない
（バグやミスの発生が前提）
●技術の進化の多様性への投資
（革新的サービスの積極利用）
●No Boundary 戦略

31. © ZOZO Technologies, Inc.
31
オンプレは安定している。
クラウドは落ちる。
本当か？

32. © ZOZO Technologies, Inc.
32
オンプレは安定している。
クラウドは落ちる。
手を入れない環境は安定している。
人間が変更するから不安定になる。

33. © ZOZO Technologies, Inc.
33
パブリッククラウドの価値は、
全力で革新し続けること。
ZOZOTOWNのクラウドへの期待
安定 ＜ 革新
不具合やトラブルによる停止は大前提
だから、マルチクラウド戦略

34. © ZOZO Technologies, Inc.
34
Same Philosophy, Different Implementation
同じ設計思想を、環境に合わせて実装する
●別クラウドで全く同じ環境は、あえて目指さない
●ヒューマンエラーが前提。
コードもオペレーションも実行環境も分けておく
●実装も運用も最小コストで。
マネージドサービスの利用が前提
●クラウドベンダーの最新＝本気を活用し続ける
●クラウドも人の子。止まることが前提
ZOZOTOWNのクラウド活用方針

35. © ZOZO Technologies, Inc.
35
ZOZOTOWN マルチクラウドの進捗
ZOZOTOWN
オンプレミスシステム
AKS EKS
SQL Database RDS for SQL Server
in PoC

36. © ZOZO Technologies, Inc.
インタークラウド データストア
36
ZOZOTOWN 「No Boundary」戦略
インタークラウド API Gateway
API Caching (JSON CDN) CDN Edge Worker
Global Load Balancing
Serverless/PaaS/Container Serverless/PaaS/Container Serverless/PaaS/Container
インタークラウド
モニタリング/ロギング/トレース
（Observability）
マルチクラウド
CI/CD
分散ネットワークセキュリティ
Multi-
Cloud
Services and Mesh Network
Datacenter

37. 37
ZOZOTOWNのデプロイ先は
「インターネット」
何があっても
インターネットのどこかで動き続けることを目指す

38. © ZOZO Technologies, Inc.
38
ZOZOTOWNは、15年の時を経て
Cloud Native への旅に踏み出しました
皆さんとご一緒できる日を楽しみにしています

40. ZOZOTOWNのCloud Native Journey
真壁 徹
日本マイクロソフト株式会社
クラウドソリューションアーキテクト
2019/7/23
アンサーソング編
Cloud Native Days Tokyo 2019

41. 自己紹介
{
“名前” : “真壁 徹(まかべ とおる)”,
“所属” : “日本マイクロソフト株式会社”,
“役割” : “クラウド ソリューションアーキテクト”,
“経歴” : “大和総研 → HP Enterprise”,
“特技” : “インフラ & オープンソース”,
“備考” : “NoOps Japan Community Supporter”
}

42. アンサーソング
1. スケーラブルなマイクロサービス基盤
2. マルチクラウド

43. マイクロサービス基盤の勘所
何を基盤に期待し、どう設計するか

44. マイクロサービスで
基盤に何を期待するか

45. マイクロサービスの設計パターン
基盤技術を考える前に
マイクロサービスの設計パターン – docs.microsoft.com

46. 基盤で実現するところ
何を基盤に期待するか
マイクロサービスの設計パターン – docs.microsoft.com
• アンバサダー
• サイドカーゲートウェイ

47. ゲートウェイの役割
まとめる、ひきうける、ちらす
ゲートウェイ集約
複数の個々のマイクロサービスへの要求を集約し、コンシューマーとサービスの間のトラフィック
を減らす
ゲートウェイオフロード
SSL/TLS終端やキャッシング、ロギング、認証など共有サービス機能を各マイクロサービスから
ゲートウェイにオフロードする
ゲートウェイルーティング
単一のエンドポイントを使用して要求を複数のマイクロサービスにルーティングする
コンシューマーは多数の個別エンドポイントを管理する必要がない

48. アンバサダー、サイドカーの役割
近くで ひきうける
アンバサダー
監視、ロギング、ルーティング、セキュリティ (TLS など) といった一般的なアプリケーションのタ
スクを、言語に関係ない方法でオフロードする
アンバサダー サービスは多くの場合、サイドカーとしてデプロイされる
サイドカー
アプリケーションのヘルパー コンポーネントを別のコンテナーまたはプロセスとしてデプロイし、
分離とカプセル化を実現する

49. 役割と基盤の関係
役割の実装例
[アンバサダー/サイドカー]
ポッド
Kubernetes Pod
サービスメッシュ
Istio/Consul/Linkerd
[ゲートウェイ]
クラウド API ゲートウェイ
Azure API Management/AWS API Gateway
クラウド L7 フロントエンド
Azure Front Door/AWS CloudFront
OSS ゲートウェイ
NGINX/HAProxy/Kong/Traefik

50. 現状認識
基盤実装の現状
ゲートウェイは成熟期
マイクロサービスに限らず広く使われており、実績も十分なソフトウェアやサービスが多い
サイドカー、アンバサダーは選択肢が多い
Kubernetesが流行っているが、過剰なケースも多々
定義や流行りにこだわらなければ、サーバーレス/PaaS系基盤も選択肢に
ひとつの基盤技術に縛られないほうがいい
サービスメッシュは有望だが過渡期
実装の変化が激しく、現状では期待できる効果よりも労力やリスクが上回りがち
代替手段がある (例: L7 Observability -> 各種APM)

51. Azureでのアーキテクチャー例
強いフロントエンド/ゲートウェイで玄関をまず固め、サービスを追加・置換可能に
and/or
Frontend/Gateway
Services Platform
Azure Front Door
Azure API Management
Azure Kubernetes Service
Service Mesh on
Azure Kubernetes Service
Service
Mesh
Azure Functions
Azure App Service
Static Contents Storage
追
加
・
置
換
可
能

52. Kubernetesクラスターもコマンド1発で作れ
るクラウド時代
状況に合わせて置き換えればいい

53. HSBC PayMe for Business
事例
• モバイルペイメントシステムをマイクロサービスアーキテクチャーで構築
• アプリケーション基盤はKubernetes
• マネージドサービスを活用
• ゲートウェイ パターンを採用(Azure API Management)
• 98%のトランザクションは500ms以下

54. Azure Kubernetes Service

55. Azure Databricks Delta
Azure Databricks

56. マルチクラウドの論点
ベンダーから見た

57. マルチクラウドの実現を左右するもの
論点は、インターフェイスとその仕様の数
標準化仕様
標準化仕様
(OSSコミュニティ)
ベンダ
仕様
実装 実装 実装 実装 実装 実装 実装 実装
ベンダ
仕様
ベンダ
仕様
• IP Networking
• DNS
• Identity
• etc
• Kubernetes
• OpenStack
• Linux
• etc
• IaaS & 導入ソフトウェア
• PaaS
• SaaS
仕様は少ないほうがいい
実装や運用で競争してほしい
ユーザー

58. 標準化と差別化はクラウドベンダー戦略の両輪
そのバランスや力点で色が出る
標準化
(OSSコミュニティ)
差別化
(ベンダ仕様/実装)
• 需要の大きいOSSの
サービス化と提供
• OSSコミュニティへ
の参加と貢献
• ベンダ仕様や実装
のOSS化
土俵に上がる/土俵を作る
選んでもらう
• OSSサービスを支え
る基盤の差別化
• 性能、コスト、信
頼性、etc
• 周辺サービスの充
実

59. 多くのクラウドプラットフォームベンダーは
マルチクラウドを推進しているわけではない
でも、OSSへのコミットメントが強ければ
結果的にそうなる

60. マイクロソフトのアプローチ
お客様のマルチクラウド志向にいかに応えるか

61. アプローチは2つ
1. OSSコミュニティの中で作っていく
2. インターフェイスを抽象化する

62. OSSコミュニティの中で作っていく
Cloud Nativeの文脈で、マイクロソフトが特に注力するプロジェクト
Packaging
& distribution
Scalability
& control
Kubernetes
developer tooling
Helm
CNAB
Virtual Kubelet Open Policy Agent
Draft
Brigade
VS Code Kubernetes Extensions
Duffle
Containerd
KEDA Service Mesh Interface

63. インターフェイスを抽象化する①
OSSコミュニティで抽象化レイヤーを作っていく
標準化仕様
(OSSコミュニティ)
ベンダ
仕様
ベンダ
仕様
ベンダ
仕様
標準化
仕様
標準化
仕様
標準化
仕様

64. Apps Tooling Ecosystem
…and more
Service Mesh Interface
Routing Telemetry Policy
Kubernetes
Service Mesh Interface
サービスメッシュは実装先
行で混乱気味
サービスメッシュが持つべ
き基本機能を定義し、API
を標準化する
その上で実装やそれ以外の
付加価値で競争すればいい
OCI/CNIと同じアプローチ

65. インターフェイスを抽象化する②
開発者に支持されているOSSの Azure向けプラグイン開発やコンテンツ拡充
標準化仕様
(OSSコミュニティ)
Azure
仕様
ベンダ
仕様
ベンダ
仕様
標準化
仕様
標準化
仕様
標準化
仕様
プラグ
イン

66. HashiCorp社との協業
Terraform、Vault、Consulなど人気のOSSを Azureで使いやすく
2017年からの協業契約を延長
マイクロソフト社員も開発に参加

67. インターフェイスを抽象化する③
AzureのサービスでOSSや他ベンダ仕様も抽象化する
Azureサービス
ベンダ
仕様
ベンダ
仕様
ベンダ
仕様
標準化
仕様
標準化
仕様
標準化
仕様
標準化
仕様
標準化
仕様
標準化
仕様

68. フロントエンド集約
Azure Front Door
IP Anycastを使ったグローバル負荷
分散サービス
CDN、DDoS保護、WAFも統合
バックエンドはAzureの外(他クラ
ウド、オンプレミス)でも可
Office 365やXBOX Liveで得たノウ
ハウと基盤をサービス化
InternetInternet
/*
/search/*
/statics/*

69. Observability標準化
トレーシング/メトリック/ロギング
Azure Monitor
Azure
Resource
OMS(*)
Agent
Application Insights &
Backend
Log Analytics &
Backend
Azure
SDK
Metrics &
Backend
APP APP APP
VM
OpenCensusOpenTelemetry(**)
Prometheus Exporter(***)(*)いまはAzure Monitorの先行サービス名を維持
(**)コミュニティで仕様作成中なので、将来の対応
(***)Azure Monitor for containersで対応
Telegraf
• スケーラブルなバックエンドを
自前で構築維持するのは大変
• マネージドサービスで楽をする
• OpenCensus/OpenTelemetry/Te
legraf/PrometheusなどOSS・コ
ミュニティ仕様がエコシステム
を形成しつつある
• 他クラウドでもインストルメン
ト化やメトリックのエクスポー
トを共通化できる

70. クラウドのコスト管理を統合
Azure Cost ManagementでAzureとAWSのコスト管理を一元化
• コストの可視化
• 予算のと閾値定義、アラート通知

71. まとめ

72. Cloud Nativeを盛り上げていきましょう
ZOZOさん、岡さん、そしてみなさん
マルチクラウド、ウェルカムです
クラウド全体の盛り上がりが重要
マイクロソフトはコミュニティで作る/つなげるに注力します
開発者のニーズとエコシステムを注視し、OSSへ積極的にコミット
Cloud Native界隈では特にパッケージング、コントロール、開発ツール周りに注力
選んでいただけるよう、実装と運用、インターフェイス抽象化で頑張る
オープンに盛り上げていきましょう
わたしたちを支えてくれるコミュニティに
コードだけでなく、経験を共有して貢献

73. 濃密バージョン 振り返りイベントします
Ask Us Anything! 質問タイムあり
https://microsoft-events.connpass.com/event/140348/

74. アンケートへの ご協力 お願いいたします

75. © Copyright Microsoft Corporation. All rights reserved.