Downloaded 45 times
![役割と基盤の関係
役割の実装例
[アンバサダー/サイドカー]
ポッド
Kubernetes Pod
サービスメッシュ
Istio/Consul/Linkerd
[ゲートウェイ]
クラウド API ゲートウェイ
Azure API Management/AWS API Gateway
クラウド L7 フロントエンド
Azure Front Door/AWS CloudFront
OSS ゲートウェイ
NGINX/HAProxy/Kong/Traefik](https://image.slidesharecdn.com/cndt2019zozotowncloudnativejourneyfinal-190723092047/85/ZOZOTOWN-Cloud-Native-Journey-49-320.jpg)
Uploaded byHiromasa Oka
ZOZOTOWN の Cloud Native Journey
2019/7/23 に開催されたCloud Native Days Tokyo 2019 の登壇資料です。Microsoft真壁さんとの共同登壇です。
More Related Content
![[CT10] CTO とチョークトーク！ 私たちがクラウド時代/AI時代に求める技術者](https://cdn.slidesharecdn.com/ss_thumbnails/ct10-170605022914-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to ZOZOTOWN の Cloud Native Journey
![[旧版] ゼンアーキテクツ「ものづくり」五つの掟](https://cdn.slidesharecdn.com/ss_thumbnails/zen-no-okite-five-things-180603232029-thumbnail.jpg?width=640&height=640&fit=bounds)
ZOZOTOWN の Cloud Native Journey
- 1. ZOZOTOWN の Cloud NativeJourney ～ 旅立ち編 ～ 株式会社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.
- 8.
- 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.
- 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.
- 43.
- 44.
- 45.
- 46. 基盤で実現するところ 何を基盤に期待するか マイクロサービスの設計パターン – docs.microsoft.com •アンバサダー • サイドカーゲートウェイ
- 47.
- 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.
- 51. Azureでのアーキテクチャー例 強いフロントエンド/ゲートウェイで玄関をまず固め、サービスを追加・置換可能に and/or Frontend/Gateway Services Platform Azure FrontDoor Azure API Management Azure Kubernetes Service Service Mesh on Azure Kubernetes Service Service Mesh Azure Functions Azure App Service Static Contents Storage 追 加 ・ 置 換 可 能
- 52.
- 53. HSBC PayMe forBusiness 事例 • モバイルペイメントシステムをマイクロサービスアーキテクチャーで構築 • アプリケーション基盤はKubernetes • マネージドサービスを活用 • ゲートウェイ パターンを採用(Azure API Management) • 98%のトランザクションは500ms以下
- 54.
- 55. Azure Databricks Delta AzureDatabricks
- 56.
- 57. マルチクラウドの実現を左右するもの 論点は、インターフェイスとその仕様の数 標準化仕様 標準化仕様 (OSSコミュニティ) ベンダ 仕様 実装 実装 実装実装 実装 実装 実装 実装 ベンダ 仕様 ベンダ 仕様 • IP Networking • DNS • Identity • etc • Kubernetes • OpenStack • Linux • etc • IaaS & 導入ソフトウェア • PaaS • SaaS 仕様は少ないほうがいい 実装や運用で競争してほしい ユーザー
- 58. 標準化と差別化はクラウドベンダー戦略の両輪 そのバランスや力点で色が出る 標準化 (OSSコミュニティ) 差別化 (ベンダ仕様/実装) • 需要の大きいOSSの サービス化と提供 • OSSコミュニティへ の参加と貢献 •ベンダ仕様や実装 のOSS化 土俵に上がる/土俵を作る 選んでもらう • OSSサービスを支え る基盤の差別化 • 性能、コスト、信 頼性、etc • 周辺サービスの充 実
- 59.
- 60.
- 61.
- 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.
- 64. Apps Tooling Ecosystem …andmore Service Mesh Interface Routing Telemetry Policy Kubernetes Service Mesh Interface サービスメッシュは実装先 行で混乱気味 サービスメッシュが持つべ き基本機能を定義し、API を標準化する その上で実装やそれ以外の 付加価値で競争すればいい OCI/CNIと同じアプローチ
- 65.
- 66.
- 67.
- 68. フロントエンド集約 Azure Front Door IPAnycastを使ったグローバル負 荷分散サービス 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.
- 73. 濃密バージョン 振り返りイベントします Ask UsAnything! 質問タイムあり https://microsoft-events.connpass.com/event/140348/
- 74.
- 75. © Copyright MicrosoftCorporation. All rights reserved.