Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

ZOZOTOWNのCloud Native Journey

23.569 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

ZOZOTOWNのCloud Native Journey

  1. 1. ZOZOTOWN の Cloud Native Journey ~ 旅立ち編 ~ 株式会社ZOZOテクノロジーズ Chief ZOZOTOWN Architect 岡 大勝 Copyright © ZOZO Technologies, Inc. TOKYO 2019
  2. 2. © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ Chief ZOZOTOWN Architect 岡 大勝 NoOps Japan 主催 アーキテクト(設計屋) @okahiromasa 2
  3. 3. © ZOZO Technologies, Inc. https://zozo.jp/ ・ 日本最大級のファッションショッピングサイト / アプリ ・ 1,200以上のショップ、7,000以上のブランドの取り扱い (2019年3月末時点) ・ 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商品を掲載 ・ 即日配送サービス ・ ギフトラッピングサービス ・ ツケ払い など 3
  4. 4. © ZOZO Technologies, Inc. 4 2004年 ZOZOTOWN オープン
  5. 5. © ZOZO Technologies, Inc. 5 ZOZOTOWNはアーキテクチャを変えずに規模を拡大してきた
  6. 6. © ZOZO Technologies, Inc. 6 ZOZOTOWNはアーキテクチャを変えずに規模を拡大してきた 出世しつくした ワカシ イナダ ワラサ ブリ
  7. 7. 7 次はもっと強靱なシステムか? ©TAITO
  8. 8. 8 ZOZOTOWN が目指すのは、”スイミー” 100匹やそこら食べられても サービスに影響しない。スイミー. レオ=レオニ/作. 谷川俊太郎/訳 1969年出版
  9. 9. © ZOZO Technologies, Inc. 9 ZOZOTOWN 疎結合化/自律分散化プロジェクト ●スケーラブル マイクロサービス ●マルチクラウド x インタークラウド アーキテクチャ設計方針
  10. 10. © ZOZO Technologies, Inc. 10 スケーラブル マイクロサービス
  11. 11. © ZOZO Technologies, Inc. 11 今のZOZOTOWNは「スケーラブルなモノリス」 2004年
  12. 12. © ZOZO Technologies, Inc. 12 今のZOZOTOWNは「スケーラブルなモノリス」 2017年
  13. 13. © ZOZO Technologies, Inc. 13 モノリス(密結合システム)のメリット ●新規サービスの開発に適している ○小さな組織(コンウェイの法則) ○理解不足のドメイン(存在しないものの分割は困難) ●性能を向上させやすい ○少ないオーバーヘッド ○シンプルなスケールアップ戦略 ●高い運用性 ○シンプルなリリース、監視、障害対応
  14. 14. © ZOZO Technologies, Inc. 14 ZOZOTOWNのモノリス起因の課題 ●運用作業や障害の影響範囲が大きい ●システム全体が特定技術へ依存 ●コード量増加による複雑さの増大 ●蓄積する Dead Code / Dead Data ●新規メンバーのキャッチアップが困難 ●etc..
  15. 15. © ZOZO Technologies, Inc. 15 ZOZOTOWNがマイクロサービスを目指す理由 ●新しいビジネスチャレンジの基盤 ●多様な人材と働き方への適応 ●多様化する技術の活用促進 (技術的チャレンジの基盤) ●全体を止めない/全体が止まらない
  16. 16. © ZOZO Technologies, Inc. 16 マイクロサービスに向けたアプローチと進捗
  17. 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. 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. 19. © ZOZO Technologies, Inc. 19 マイクロサービス化の進捗 - 1/4
  20. 20. © ZOZO Technologies, Inc. 20 マイクロサービス化の進捗 - 2/4 ●SP処理をマイクロサービスに移植 ●Strangler Facade 経由でサービスへアクセス可能に
  21. 21. © ZOZO Technologies, Inc. 21 マイクロサービス化の進捗 - 3/4
  22. 22. © ZOZO Technologies, Inc. 22 マイクロサービス化の進捗 - 4/4 ●ROトラフィックのマイクロサービス切替成功(100%) ●ROの残SP移植進行中 (予定)
  23. 23. © ZOZO Technologies, Inc. 23 ZOZOTOWNは負荷変動が大きい (%)
  24. 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. 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. 26. © ZOZO Technologies, Inc. 26 Aggregate APIs (BFF) Raw APIs Standard Traffic スケーラブルアプリケーションとデータストア スケーラブルアプリケーション =高い回復力を持つ アプリケーションインスタンス
  27. 27. © ZOZO Technologies, Inc. 27 Aggregate APIs (BFF) Raw APIs Burst Traffic スケーラブルアプリケーションとデータストア ●アプリケーションインスタンスだ けでなく、データストアも動的に スケールさせたい ●VM(Node)は意識したくない ●数秒でのスケールが理想 アプリケーションは 瞬時にスケール
  28. 28. © ZOZO Technologies, Inc. 28 ➢軽量なフットプリント/高速な起動(AOT) ➢ステートレス ➢非同期処理 ➢冪等性(リトライ性) ➢多様な環境へのデプロイ (コンテナ/PaaS/サーバレス) ➢分散・非生存を前提としたObservability (分散トレーシング) スケーラブルアプリケーションの設計原則
  29. 29. © ZOZO Technologies, Inc. 29 マルチクラウド x インタークラウド
  30. 30. © ZOZO Technologies, Inc. 30 なぜマルチクラウドなのか ●革新と安定のバランス ●完全なものなどない (バグやミスの発生が前提) ●技術の進化の多様性への投資 (革新的サービスの積極利用) ●No Boundary 戦略
  31. 31. © ZOZO Technologies, Inc. 31 オンプレは安定している。 クラウドは落ちる。 本当か?
  32. 32. © ZOZO Technologies, Inc. 32 オンプレは安定している。 クラウドは落ちる。 手を入れない環境は安定している。 人間が変更するから不安定になる。
  33. 33. © ZOZO Technologies, Inc. 33 パブリッククラウドの価値は、 全力で革新し続けること。 ZOZOTOWNのクラウドへの期待 安定 < 革新 不具合やトラブルによる停止は大前提 だから、マルチクラウド戦略
  34. 34. © ZOZO Technologies, Inc. 34 Same Philosophy, Different Implementation 同じ設計思想を、環境に合わせて実装する ●別クラウドで全く同じ環境は、あえて目指さない ●ヒューマンエラーが前提。 コードもオペレーションも実行環境も分けておく ●実装も運用も最小コストで。 マネージドサービスの利用が前提 ●クラウドベンダーの最新=本気を活用し続ける ●クラウドも人の子。止まることが前提 ZOZOTOWNのクラウド活用方針
  35. 35. © ZOZO Technologies, Inc. 35 ZOZOTOWN マルチクラウドの進捗 ZOZOTOWN オンプレミスシステム AKS EKS SQL Database RDS for SQL Server in PoC
  36. 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. 37 ZOZOTOWNのデプロイ先は 「インターネット」 何があっても インターネットのどこかで動き続けることを目指す
  38. 38. © ZOZO Technologies, Inc. 38 ZOZOTOWNは、15年の時を経て Cloud Native への旅に踏み出しました 皆さんとご一緒できる日を楽しみにしています
  39. 39. ZOZOTOWNのCloud Native Journey 真壁 徹 日本マイクロソフト株式会社 クラウドソリューションアーキテクト 2019/7/23 アンサーソング編 Cloud Native Days Tokyo 2019
  40. 40. 自己紹介 { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “インフラ & オープンソース”, “備考” : “NoOps Japan Community Supporter” }
  41. 41. アンサーソング 1. スケーラブルなマイクロサービス基盤 2. マルチクラウド
  42. 42. マイクロサービス基盤の勘所 何を基盤に期待し、どう設計するか
  43. 43. マイクロサービスで 基盤に何を期待するか
  44. 44. マイクロサービスの設計パターン 基盤技術を考える前に マイクロサービスの設計パターン – docs.microsoft.com
  45. 45. 基盤で実現するところ 何を基盤に期待するか マイクロサービスの設計パターン – docs.microsoft.com • アンバサダー • サイドカーゲートウェイ
  46. 46. ゲートウェイの役割 まとめる、ひきうける、ちらす ゲートウェイ集約 複数の個々のマイクロサービスへの要求を集約し、コンシューマーとサービスの間のトラフィック を減らす ゲートウェイオフロード SSL/TLS終端やキャッシング、ロギング、認証など共有サービス機能を各マイクロサービスから ゲートウェイにオフロードする ゲートウェイルーティング 単一のエンドポイントを使用して要求を複数のマイクロサービスにルーティングする コンシューマーは多数の個別エンドポイントを管理する必要がない
  47. 47. アンバサダー、サイドカーの役割 近くで ひきうける アンバサダー 監視、ロギング、ルーティング、セキュリティ (TLS など) といった一般的なアプリケーションのタ スクを、言語に関係ない方法でオフロードする アンバサダー サービスは多くの場合、サイドカーとしてデプロイされる サイドカー アプリケーションのヘルパー コンポーネントを別のコンテナーまたはプロセスとしてデプロイし、 分離とカプセル化を実現する
  48. 48. 役割と基盤の関係 役割の実装例 [アンバサダー/サイドカー] ポッド Kubernetes Pod サービスメッシュ Istio/Consul/Linkerd [ゲートウェイ] クラウド API ゲートウェイ Azure API Management/AWS API Gateway クラウド L7 フロントエンド Azure Front Door/AWS CloudFront OSS ゲートウェイ NGINX/HAProxy/Kong/Traefik
  49. 49. 現状認識 基盤実装の現状 ゲートウェイは成熟期 マイクロサービスに限らず広く使われており、実績も十分なソフトウェアやサービスが多い サイドカー、アンバサダーは選択肢が多い Kubernetesが流行っているが、過剰なケースも多々 定義や流行りにこだわらなければ、サーバーレス/PaaS系基盤も選択肢に ひとつの基盤技術に縛られないほうがいい サービスメッシュは有望だが過渡期 実装の変化が激しく、現状では期待できる効果よりも労力やリスクが上回りがち 代替手段がある (例: L7 Observability -> 各種APM)
  50. 50. 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 追 加 ・ 置 換 可 能
  51. 51. Kubernetesクラスターもコマンド1発で作れ るクラウド時代 状況に合わせて置き換えればいい
  52. 52. HSBC PayMe for Business 事例 • モバイルペイメントシステムをマイクロサービスアーキテクチャーで構築 • アプリケーション基盤はKubernetes • マネージドサービスを活用 • ゲートウェイ パターンを採用(Azure API Management) • 98%のトランザクションは500ms以下
  53. 53. Azure Kubernetes Service
  54. 54. Azure Databricks Delta Azure Databricks
  55. 55. マルチクラウドの論点 ベンダーから見た
  56. 56. マルチクラウドの実現を左右するもの 論点は、インターフェイスとその仕様の数 標準化仕様 標準化仕様 (OSSコミュニティ) ベンダ 仕様 実装 実装 実装 実装 実装 実装 実装 実装 ベンダ 仕様 ベンダ 仕様 • IP Networking • DNS • Identity • etc • Kubernetes • OpenStack • Linux • etc • IaaS & 導入ソフトウェア • PaaS • SaaS 仕様は少ないほうがいい 実装や運用で競争してほしい ユーザー
  57. 57. 標準化と差別化はクラウドベンダー戦略の両輪 そのバランスや力点で色が出る 標準化 (OSSコミュニティ) 差別化 (ベンダ仕様/実装) • 需要の大きいOSSの サービス化と提供 • OSSコミュニティへ の参加と貢献 • ベンダ仕様や実装 のOSS化 土俵に上がる/土俵を作る 選んでもらう • OSSサービスを支え る基盤の差別化 • 性能、コスト、信 頼性、etc • 周辺サービスの充 実
  58. 58. 多くのクラウドプラットフォームベンダーは マルチクラウドを推進しているわけではない でも、OSSへのコミットメントが強ければ 結果的にそうなる
  59. 59. マイクロソフトのアプローチ お客様のマルチクラウド志向にいかに応えるか
  60. 60. アプローチは2つ 1. OSSコミュニティの中で作っていく 2. インターフェイスを抽象化する
  61. 61. 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
  62. 62. インターフェイスを抽象化する① OSSコミュニティで抽象化レイヤーを作っていく 標準化仕様 (OSSコミュニティ) ベンダ 仕様 ベンダ 仕様 ベンダ 仕様 標準化 仕様 標準化 仕様 標準化 仕様
  63. 63. Apps Tooling Ecosystem …and more Service Mesh Interface Routing Telemetry Policy Kubernetes Service Mesh Interface サービスメッシュは実装先 行で混乱気味 サービスメッシュが持つべ き基本機能を定義し、API を標準化する その上で実装やそれ以外の 付加価値で競争すればいい OCI/CNIと同じアプローチ
  64. 64. インターフェイスを抽象化する② 開発者に支持されているOSSの Azure向けプラグイン開発やコンテンツ拡充 標準化仕様 (OSSコミュニティ) Azure 仕様 ベンダ 仕様 ベンダ 仕様 標準化 仕様 標準化 仕様 標準化 仕様 プラグ イン
  65. 65. HashiCorp社との協業 Terraform、Vault、Consulなど人気のOSSを Azureで使いやすく 2017年からの協業契約を延長 マイクロソフト社員も開発に参加
  66. 66. インターフェイスを抽象化する③ AzureのサービスでOSSや他ベンダ仕様も抽象化する Azureサービス ベンダ 仕様 ベンダ 仕様 ベンダ 仕様 標準化 仕様 標準化 仕様 標準化 仕様 標準化 仕様 標準化 仕様 標準化 仕様
  67. 67. フロントエンド集約 Azure Front Door IP Anycastを使ったグローバル負荷 分散サービス CDN、DDoS保護、WAFも統合 バックエンドはAzureの外(他クラ ウド、オンプレミス)でも可 Office 365やXBOX Liveで得たノウ ハウと基盤をサービス化 InternetInternet /* /search/* /statics/*
  68. 68. 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・コ ミュニティ仕様がエコシステム を形成しつつある • 他クラウドでもインストルメン ト化やメトリックのエクスポー トを共通化できる
  69. 69. クラウドのコスト管理を統合 Azure Cost ManagementでAzureとAWSのコスト管理を一元化 • コストの可視化 • 予算のと閾値定義、アラート通知
  70. 70. まとめ
  71. 71. Cloud Nativeを盛り上げていきましょう ZOZOさん、岡さん、そしてみなさん マルチクラウド、ウェルカムです クラウド全体の盛り上がりが重要 マイクロソフトはコミュニティで作る/つなげるに注力します 開発者のニーズとエコシステムを注視し、OSSへ積極的にコミット Cloud Native界隈では特にパッケージング、コントロール、開発ツール周りに注力 選んでいただけるよう、実装と運用、インターフェイス抽象化で頑張る オープンに盛り上げていきましょう わたしたちを支えてくれるコミュニティに コードだけでなく、経験を共有して貢献
  72. 72. 濃密バージョン 振り返りイベントします Ask Us Anything! 質問タイムあり https://microsoft-events.connpass.com/event/140348/
  73. 73. アンケートへの ご協力 お願いいたします
  74. 74. © Copyright Microsoft Corporation. All rights reserved.

×