DevLOVE X 20190623 B CloudNative Sue

Transcript

1. Cloud Nativeと分散システムを軸に これからのITのあり⽅を考えてみる 2019年 6⽉ 23⽇ 須江 信洋 (@nobusue) [DevLOVE

   X: Day2 1-B]

2. ⾃⼰紹介 2 • 須江 信洋（すえ のぶひろ） • Twitter: @nobusue Ø

   約14年JavaEE関連に携わる(1999〜2013) Ø IoTサービス関連Startupで開発から運⽤まで (2014〜2017) • ストリーミングデータ処理、マイクロサービス化、 コンテナプラットフォーム構築/運⽤ Ø Red HatでOpenShift担当Solution Architect(2017/4〜)

3. 3 DXの先にある 「アフターデジタル」

4. DXの先には何があるのか? 4 • オフラインは存在しなくなる ◦ オンラインとオフラインの主従逆転 ◦ モバイルやセンサーの普及によりあらゆる⾏動が データ化 •

   バリューチェーンからバリュージャーニーへ ◦ 顧客接点データを多く持ち、UX改善ループを⾼ 速に回す競争 ◦ データが取れない商品は相対的に価値が低下 • 社会システムがアップデートされる ◦ デジタル化の取り組みが相互に連携 ◦ 点->線->⾯: デジタル世界の住⼈

5. OMOという世界観 5 オンライン オフライン O2O オンライン オフライン ビフォーデジタル アフターデジタル DX

   OMO = Online Merges with Offline or Online-Merge-Offline ICTの役割は部分的 ICTがビジネスの根幹

6. OMO事例: 中国 平安保険「好医⽣」 6 出典) https://trillionsmiles.com/future/good-doctor/ • 無料アプリで以下のサービスを提供 ◦ オンライン問診

   / ドクター予約 / 薬EC / 健康情報 / 歩数計 ◦ 2014年リリース、現在は2億⼈以上のユーザー • 中国の病⼈ライフを劇的に改善 ◦ 医療サービスのレベルがまちまちで、⼤病院に患者が集中 => さらにサービスレベルが悪化する状態だった ◦ アプリで問診 => 受診不要な患者数削減 ◦ ドクター予約 => ⼝コミを参考にでき患者が分散 • 保険会社としてのビジネスモデル転換 ◦ 営業マンは売上ではなく、顧客のアプリ登録数をKPIに ◦ 顧客との⻑期的な関係を強化し、結果的に保険の売上増に

7. バリュージャーニー型ビジネスへ 7 顧客接点はプラットフォーマーが 握る Alipay、WeChatなどの 決済プラットフォーマー (toC, toB, B2B2C, …)

   リテール、モビリティ、飲⾷、旅⾏など各業界の サービサー 製品の改善を続け、より良いモノを提供し続ける メーカー お⾦の消費先(経済圏の体験価値)を提供 モノの提供 製品接点 デジタル接点 リアル接点 GPS接点 体験接点 顧客に寄り添い、⾼頻度に有益なデータの取れる顧客接点を獲得し、データを分析し、顧客体験(UX)の改善 サイクルを⾼速に回すことが重要 =>そのためのエコシステム、俊敏なデジタル基盤をどう整備していくか

8. 8 OMO時代を⽀える ICTに求められること

9. 9 OMOを⽀えるDigital Integration Hub (DIH)アーキテクチャ • ガートナー社が提唱する、顧客体験の向上とデジ タル変⾰を⽀援する新しいアーキテクチャパラダ イム •

   SoRのデータを⾼いスケーラビリティでAPI経由 でアクセスする • DIHは低いレイテンシー、スケールアウト可能、 ⾼パフォーマンスのデータストアで、複数のSoR システムを統合するアプリケーションアーキテク チャ [DIHのゴール] • フロントのAPIサービスのワークロードがバック エンドのシステムに⾏かない • APIサービスの実装が複雑な連携にならない • バックエンドのデータソースとフロントエンドの APIサービスを分離 • これにより⼤規模、⾼スループット、低遅延のフ ロントエンドAPIサービスを実現する このアーキテクチャはオーストラリアの 最⼤投資銀⾏であるマッコーリー銀⾏の アーキテクチャをCase Studyとしている (出処：https://www.linkedin.com/pulse/digital-integration-hub-turbocharges-your-api-strategy-pezzini/ )

10. なぜ時代は分散システムへ向かうのか? 10 Photo by Jared Brashier on Unsplash Photo by

    Cibi Chakravarthi on Unsplash Monolithic System Distributed System

11. OMOの実装戦略: Cloud Native Application 11 Cloud Native ≠ (Public/Private) Cloudを使うこと

    Cloud Native = (Public/Private) Cloudに適応した設計哲学 Design for Failure インフラに変更や障害が発生しても安定して稼働し続 ける Always on サービスを継続的に提供できる 計画停止や障害停止をゼロに近づける Autonomous / Self tuning サービスレベルを自動的に最適化できる CI/CD サービスを迅速かつ継続的に改善できる (Core concepts from https://www.manning.com/books/cloud-native-patterns)

12. 従来型とCloud Nativeの⽐較 12 従来型アプリケーション クラウドネイティブ 対象 長期的と安定性 迅速に市場投入 開発方法 ウォーターフォール

    アジャイル、DevOps チーム編成 サイロ化したチーム 「開発」「運用」「テスト」「セキュリティ」 共同DevOpsチーム デリバリーサイクル 長い 短く連続的 アプリケーションアーキテクチャ 密結合 モノリシック 疎結合 マイクロサービスとAPI連携 インフラ サーバ中心 オンプレミス志向 インフラ依存 垂直にスケール ピーク時に合わせたキャパシティ コンテナ中心 オンプレ/クラウドの双方 インフラ非依存の移植性 水平にスケール オンデマンドキャパシティ

13. Why Kubernetes with Kubernetes Operator? 13 Cloud NativeなIT基盤を構築するテクノロジーはコモデティ化しつつある どんな企業でもDigital Giantのようなパフォーマンスを発揮できる!!

    App配備 Platform Portability コンテナ サービス 管理 Auto Scaling / Auto Healing オーケストレータ (Kubernetes) Day2 Operation SW固有の運⽤ の⾃動化 Kubernetes Operator

14. コンテナによるアプリケーション可搬性 14 LAPTOP Container Application OS dependencies Guest VM Linux

    BARE METAL Container Application OS dependencies Linux VIRTUALIZATION Container Application OS dependencies Virtual Machine Linux PRIVATE CLOUD Container Application OS dependencies Virtual Machine Linux PUBLIC CLOUD Container Application OS dependencies Virtual Machine Linux Linuxコンテナ(Docker) + Linuxホスト = あらゆる環境での可搬性

15. スケーリング Podの管理・監視 デプロイ管理 コンテナオーケストレーション基盤(Kubernetes) 15 複数ノードのコンテナランタイムを統合し、単⼀の巨⼤なコンピューティングリソース として扱う、スケーラブルなコンテナクラスタ実現のためのミドルウェア Node1 Pod 1

    Node2 Pod 2 Node3 Master Node1 Pod 1 Node2 Pod 2 Node3 Node1 Pod 1 Node3 Pod 2 Node2 Node1 Pod 1 Node2 Node3 Node1 Pod 1 Node3 Pod 2 Node2 Pod 2 Pod 2 レプリカ数を増やす・減らす レプリカ数を⼀定に保つ コンテナのデプロイ

16. ハイブリッドクラウドとコンテナ 16 パブリッククラウドはスモールスタート可能だが、 リソース利⽤量に応じてコストが発⽣するため、 コスト効率でオンプレミスと逆転するポイントが ある パブリッククラウドにはサービス固有の強み・弱みがあ り、優位性のあるサービスを選んで使った⽅が効率的で あることが多い。 また、パブリッククラウドで提供されるサービスは汎⽤

    性を重視することが多く、尖ったニーズにマッチしない 場合がある。 • コンテナの可搬性を利⽤し、適材適所のデプロイメントを実現 • 5Gの登場によりエッジコンピューティングも視野に パブリッククラウド オンプレミス 機能性の観点 コスト効率化の観点

17. Cloud Nativeな環境では運⽤⾃動化が必須 17 IT Operation (Manual) コンテナやクラスタの運⽤を個別に⾏う時代は終焉 Kubernetes Operation コンテナやクラスタシステムを管理するには、

    管理者の負担が⼤きい • 異常を継続的にチェック • ⼈による障害復旧オペレーション • ⼿動の変更作業

18. Kubernetes Operatorとは 18 https://www.youtube.com/watch?v=LymzLHRbQdk 運⽤をソフトウェアによって作り込む「SRE(Site Reliability Engineering)」の実装パターン Kubernetes Applications ソフトウェア運⽤の知⾒をコード化し、

    パッケージ化したもの Kubernetes APIを拡張するアプリケーシ ョンコントローラーを通じ、スケーリン グ、バックアップ、アップデートなどを 適切に⾏う ・CRD (Custom Resource Definition) ・Custom Controller

19. • Containerized(?) • Cloud storage ready • Replicated • Backup

    • Automated updates • Containerized • Container storage ready • Replicated • Backup • Automated updates • Enhanced observability • Customization • Local development • Fully Open Source • Any Kubernetes • Certified on OpenShift • Containerized 19

20. Operatorの存在意義 20 ReplicaSet StatefulSet Operator k8sリソースタイプ 標準 標準 カスタム(拡張) 対象アプリケーション

    ステートレス ステートフル 任意 Pod名(≒ホスト名) ランダム 名前+連番で固定 Operatorによる スケール調整時の 順序性維持 考慮しない 連番順に起動停⽌を⾏ う Operatorによる PV(ストレージ)割り当て 全Podで共通 Podごとに個別 Operatorによる スケール調整時の ソフトウェア固有の処理 しない しない 実装可能 ソフトウェア固有の 運⽤作業の⾃動化 しない しない 実装可能

21. OperatorHub.io 21 https://operatorhub.io/ すでに多くのソフトウェアがKubernetes対応を進めている

22. 22 OMO時代の アプリケーション アーキテクチャ

23. 開発者が想定しがちな 分散システムにおける8つの前提 Source: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing Service Service Library Library 1. ネットワークは安定している

    2. 遅延はゼロである 3. 帯域は無限である 4. ネットワークはセキュアである 5. トポロジーは変更されない 6. 1⼈の管理者がいる 7. 通信コストはゼロである 8. すべてのネットワークは均質である 23

24. 実際の分散システムでは Source: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing Service Service 1. ネットワークは詰まる 2. ネットワークの遅延でアプリが遅くなる 3.

    運⽤者がアプリログを漁って遅延箇所を探る 4. 開発者が通信を暗号化する仕組みを組み込む 5. サービスのIPやDNS名が変わる 24

25. Service Mesh「層」という概念 2 5 サービス間通信とPod/Containerを切り離す ＝ Mesh層で設定可能にする ＝ 開発者は考えなくて良い IaaS層

    オーケストレーション層 Mesh層 アプリケーション層 •サービスの発⾒、ルーティング •サービスの認証 •アクセス数制限 •ロードバランス •リトライ、サーキットブレイク •Blue/Green、カナリアリリース •リクエストのトレース •サービスのメトリクス •エラー時の挙動確認

26. Service Mesh(Istio)のユースケース 26 • (マイクロ)サービス基盤の運⽤を効率化 ◦ 通信にまつわる⾯倒を回避/動作不良を抑⽌ ◦ 監視機構の統合 ◦

    透過的な暗号化とアクセス制御、証明書管理 • CI/CDの促進 ◦ インテリジェントルーティング ◦ ポリシーベース制御 • デバッグ/テスト⽀援とChaos Engineering ◦ 分散トレース ◦ Fault Injection ◦ Dark Launch(Mirroring)

27. POD ENVOY SERVICE POD ENVOY SERVICE POD ENVOY SERVICE Pilot

    Mixer Auth データに基づき、ル ーティングルール、 ポリシー、トレーシ ングデータの収集な ど Jaeger プロキシにデータを 設定する、プロキシ が使うデータを管理 する SERVICE MESH (Istio) アーキテクチャ 27 => SMI(Service Mesh Interface)によって標準化が提案されている https://smi-spec.io/

28. POD SERVICE A ENVOY POD SERVICE B ENVOY POD SERVICE

    C ENVOY discovers service relationships and process times, transparent to the services SERVICE A SERVICE B SERVICE C 210 ms 720 ms 930 ms DISTRIBUTED TRACING WITH ISTIO & JAEGER 28

29. Jaeger: Transaction Trace 29

30. OpenTracing • 分散システムにおけるトレースの標準化(CNCF) ◦ 複数⾔語に対応 ◦ 複数のトレーサー(ソフトウェア/SaaS)に対応 ◦ ベンダーニュートラル •

    分散トレースのモデルを定義 ◦ https://opentracing.io/docs/best-practices/instrumenting-your-application/ • アプリケーションやフレームワークが安⼼して使える 「分散トレースの抽象化層」を提供 ◦ JavaにおけるLog4Jのようなもの ◦ OpenTelemetry: OpenTracingとOpenCensusとの統合 => デファクトへ 30 https://opentracing.io/

31. IstioとOpenTracing/Jaegerの関係 • OpenTracing ◦ Istioにおける分散トレースのインターフェースとして利⽤ • Jaeger ◦ Istioにおける分散トレースの実装のデファクト ◦

    他のトレーサに差し替えも可能 • 透過的なトレース ◦ Envoy経由のRESTは⾃動的にトレースの対象となる ◦ より粒度の細かいトレースを取得する場合にはOpenTracingのAPIを利⽤ した実装が必要 31

32. Build / Pipelines ソースコードからjar/zipや コンテナなどのアーティフ ァクトをビルドするための プラガブルモデルを提供 Serverless: Knative Overview

    Serving コンテナ化したアプリケ ーションをイベント・ドリ ブンモデルで実行、不要時 に完全停止可能 Eventing アプリケーションをキック するイベントのコンシュー マー/プロデューサーに対 する共通インフラを提供 "...Kubernetesを拡張し、どこでも実行可能な、モダンでソースコード中心のコンテナベースアプリケー ションを構築するためのビルディングブロックを追加". 32

33. Serving https://github.com/knative/docs/tree/master/serving

34. Build https://github.com/knative/docs/tree/master/build

35. Eventing • https://github.com/knative/docs/tree/master/eventing • https://github.com/knative/eventing-sources

36. CNCF, CloudEvents and Serverless

37. CloudEventsとは? • Open Hybrid Cloud環境における「イベント」を抽象化 ◦ CNCFでホストされており、ベンダーから中⽴ ◦ 特定のプロトコルやペイロード(例: AWS

    SQS)に依存しない形でイベ ント処理が実装できる ◦ データの相互運⽤性を確保するために、イベントのメタデータ(スキー マ)を定義するための仕様が決められている ◦ さまざまな実装系に対して、イベントのバインディング(具体的なペイ ロードやプロトコルとの対応づけ)の定義が拡充されてきている ◦ 軽量

38. CloudEvents情報まとめ • Project ◦ https://cloudevents.io/ • 仕様 ◦ https://github.com/cloudevents/spec •

    Blog ◦ CloudEventsの紹介、そしてServerlessな世界はこ れからどこへ向かうのか

39. 39 データから価値を ⽣み出すための仕組み

40. OMOの基盤:「超⼤量データのリアルタイム処理」 40 • Cloud Nativeメッセージバス ◦ スケーラブルでハイパフォーマンスな分散処理 ◦ 無停⽌ ◦

    多様なクライアントに対応 • リアルタイム/オンデマンドデータ解析 ◦ 必要なときに⾃由に試⾏錯誤可能なワークベンチ ◦ ストリームデータをリアルタイム処理可能 • Cloud Nativeストレージ ◦ S3互換APIを備えたストレージ(Hadoopエコシステムの活⽤) ◦ 必要なときに必要なだけの容量を確保 ◦ コストパフォーマンスに優れる

41. Cloud Nativeメッセージバス: Apache Kafka l LinkedInがEvent Trackingのため に開発した、超⾼スループットな 分散メッセージブローカー p

    現在はConfluent社主導でOSS として開発が進められている p アドテクやIoTなど応⽤分野が 広がっている https://kafka.apache.org/ 41

42. 42 Use cases: Kafka導⼊前 Logging Application Application Web Microservice s

    Monitoring Analytics Application Application Application

43. 43 Use cases: Kafka導⼊後 Application Web Microservice s Monitoring Analytics

    Application Application Apache Kafka

44. Strimzi(AMQ Streams) • Managed Kafka on Kubernetes/OpenShift ◦ コンピューティングリソースの⾃動的な割当と管理 ◦

    Kafka as a Service ◦ DevOpsの開発と運⽤のツールと⽂化を取り⼊れられる ◦ Kafkaアプリケーション開発の⾼速化 • Kubernetes Operatorによる導⼊と管理 ◦ 宣⾔的なクラスタおよびトピックのコンフィグレーション ▪ Operatorは指定された設定に従い、現在の状態の差分を検出して、クラスタとトピック に対して⾃動的に必要なコマンドを発⾏する ▪ 実現したいことそのものを記述し、具体的な操作はOperatorに任せる(コマンドツール 等で操作しない) ◦ Day2オペレーションの⾃動化 ▪ Brokerの障害対応やスケールアウトなどをOperatorに任せる 44 http://strimzi.io

45. Strimzi: Cluster Operator Zookeeper/Kafka Brokerの⾃動構成 引⽤：http://strimzi.io/docs/master/ 45

46. • AI/ML as a Service on Kubernetes/OpenShiftの リファレンスアーキテクチャ • クラウドネイティブ:

    AI for the Hybrid Cloud • OpenDataHub.io: コミュニティ主導 Open Data Hub

47. • 汎⽤の分散ストレージ • RESTful ゲートウェイ • S3 / Swift 互換

    • 汎⽤分析エンジン • ⼤量データ処理 • Kubernetes上で稼働 • マルチユーザー Jupyter • データサイエンティ ストや研究者向け Available Now at OpenDataHub.io • Open Data Hubの⼀部 • すぐに利⽤可能な構成 済みAIモデルのセット Open Data Hub AI Library Community of Components

48. Available Now at OpenDataHub.io • モニタリングとアラー トのツールキット • 時系列の数値データを 記録

    • 問題の診断に利⽤ • すべてのメトリクス を分析可能なプラッ トフォーム • メトリクスに対する クエリーや可視化、 アラート • MLモデルを簡単に Kubernetesにデプロ イ • モデルをREST / gRPCで公開 • モデルのライフサイ クル全体の管理 • Jupyterプラグイン • 時系列データやテー ブルなどを対話的に 処理 • Sparkと統合 Community of Components

49. Fraud Detection(不正検知) Demo on OPEN DATA HUB

50. 50 まとめ

51. OMO時代にはKubernetesが常識となる =>Cloud Nativeと分散システムに取り組むべき まとめ 51 • DXの先にある「アフターデジタル」 • OMO時代を⽀えるICTに求められること •

    OMO時代のアプリケーションアーキテクチャ • データから価値を⽣み出すための仕組み

52. Thank you 52