DevLOVE X 20190623 B CloudNative Sue

Transcript

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

   View Slide

2. ⾃⼰紹介
   2
   ● 須江 信洋（すえ のぶひろ）
   •
   Twitter: @nobusue
   Ø 約14年JavaEE関連に携わる(1999〜2013)
   Ø IoTサービス関連Startupで開発から運⽤まで (2014〜2017)
   • ストリーミングデータ処理、マイクロサービス化、
   コンテナプラットフォーム構築/運⽤
   Ø Red HatでOpenShift担当Solution Architect(2017/4〜)
   

   View Slide

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

   View Slide

4. DXの先には何があるのか?
   4
   ● オフラインは存在しなくなる
   ○ オンラインとオフラインの主従逆転
   ○ モバイルやセンサーの普及によりあらゆる⾏動が
   データ化
   ● バリューチェーンからバリュージャーニーへ
   ○ 顧客接点データを多く持ち、UX改善ループを⾼
   速に回す競争
   ○ データが取れない商品は相対的に価値が低下
   ● 社会システムがアップデートされる
   ○ デジタル化の取り組みが相互に連携
   ○ 点->線->⾯: デジタル世界の住⼈
   

   View Slide

5. OMOという世界観
   5
   オンライン
   オフライン
   O2O
   オンライン
   オフライン
   ビフォーデジタル アフターデジタル
   DX
   OMO = Online Merges with Offline or Online-Merge-Offline
   ICTの役割は部分的 ICTがビジネスの根幹
   

   View Slide

6. OMO事例: 中国 平安保険「好医⽣」
   6
   出典) https://trillionsmiles.com/future/good-doctor/
   ● 無料アプリで以下のサービスを提供
   ○ オンライン問診 / ドクター予約 / 薬EC / 健康情報 / 歩数計
   ○ 2014年リリース、現在は2億⼈以上のユーザー
   ● 中国の病⼈ライフを劇的に改善
   ○ 医療サービスのレベルがまちまちで、⼤病院に患者が集中 =>
   さらにサービスレベルが悪化する状態だった
   ○ アプリで問診 => 受診不要な患者数削減
   ○ ドクター予約 => ⼝コミを参考にでき患者が分散
   ● 保険会社としてのビジネスモデル転換
   ○ 営業マンは売上ではなく、顧客のアプリ登録数をKPIに
   ○ 顧客との⻑期的な関係を強化し、結果的に保険の売上増に
   

   View Slide

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

   View Slide

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

   View Slide

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/ )
   

   View Slide

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

    View Slide

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)
    

    View Slide

12. 従来型とCloud Nativeの⽐較
    12
    従来型アプリケーション クラウドネイティブ
    対象 長期的と安定性 迅速に市場投入
    開発方法 ウォーターフォール アジャイル、DevOps
    チーム編成
    サイロ化したチーム
    「開発」「運用」「テスト」「セキュリティ」
    共同DevOpsチーム
    デリバリーサイクル 長い 短く連続的
    アプリケーションアーキテクチャ
    密結合
    モノリシック
    疎結合
    マイクロサービスとAPI連携
    インフラ
    サーバ中心
    オンプレミス志向
    インフラ依存
    垂直にスケール
    ピーク時に合わせたキャパシティ
    コンテナ中心
    オンプレ/クラウドの双方
    インフラ非依存の移植性
    水平にスケール
    オンデマンドキャパシティ
    

    View Slide

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
    

    View Slide

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ホスト
    = あらゆる環境での可搬性
    

    View Slide

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
    レプリカ数を増やす・減らす
    レプリカ数を⼀定に保つ
    コンテナのデプロイ
    

    View Slide

16. ハイブリッドクラウドとコンテナ
    16
    パブリッククラウドはスモールスタート可能だが、
    リソース利⽤量に応じてコストが発⽣するため、
    コスト効率でオンプレミスと逆転するポイントが
    ある
    パブリッククラウドにはサービス固有の強み・弱みがあ
    り、優位性のあるサービスを選んで使った⽅が効率的で
    あることが多い。
    また、パブリッククラウドで提供されるサービスは汎⽤
    性を重視することが多く、尖ったニーズにマッチしない
    場合がある。
    ● コンテナの可搬性を利⽤し、適材適所のデプロイメントを実現
    ● 5Gの登場によりエッジコンピューティングも視野に
    パブリッククラウド オンプレミス
    機能性の観点
    コスト効率化の観点
    

    View Slide

17. Cloud Nativeな環境では運⽤⾃動化が必須
    17
    IT Operation
    (Manual)
    コンテナやクラスタの運⽤を個別に⾏う時代は終焉
    Kubernetes Operation
    コンテナやクラスタシステムを管理するには、
    管理者の負担が⼤きい
    ● 異常を継続的にチェック
    ● ⼈による障害復旧オペレーション
    ● ⼿動の変更作業
    

    View Slide

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
    

    View Slide

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
    

    View Slide

20. Operatorの存在意義
    20
    ReplicaSet StatefulSet Operator
    k8sリソースタイプ 標準 標準 カスタム(拡張)
    対象アプリケーション ステートレス ステートフル 任意
    Pod名(≒ホスト名) ランダム 名前+連番で固定 Operatorによる
    スケール調整時の
    順序性維持
    考慮しない
    連番順に起動停⽌を⾏
    う
    Operatorによる
    PV(ストレージ)割り当て 全Podで共通 Podごとに個別 Operatorによる
    スケール調整時の
    ソフトウェア固有の処理
    しない しない 実装可能
    ソフトウェア固有の
    運⽤作業の⾃動化
    しない しない 実装可能
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

24. 実際の分散システムでは
    Source: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
    Service
    Service
    1. ネットワークは詰まる
    2. ネットワークの遅延でアプリが遅くなる
    3. 運⽤者がアプリログを漁って遅延箇所を探る
    4. 開発者が通信を暗号化する仕組みを組み込む
    5. サービスのIPやDNS名が変わる
    24
    

    View Slide

25. Service Mesh「層」という概念
    2
    5
    サービス間通信とPod/Containerを切り離す
    ＝ Mesh層で設定可能にする ＝ 開発者は考えなくて良い
    IaaS層
    オーケストレーション層
    Mesh層
    アプリケーション層
    ●サービスの発⾒、ルーティング
    ●サービスの認証
    ●アクセス数制限
    ●ロードバランス
    ●リトライ、サーキットブレイク
    ●Blue/Green、カナリアリリース
    ●リクエストのトレース
    ●サービスのメトリクス
    ●エラー時の挙動確認
    

    View Slide

26. Service Mesh(Istio)のユースケース
    26
    ● (マイクロ)サービス基盤の運⽤を効率化
    ○ 通信にまつわる⾯倒を回避/動作不良を抑⽌
    ○ 監視機構の統合
    ○ 透過的な暗号化とアクセス制御、証明書管理
    ● CI/CDの促進
    ○ インテリジェントルーティング
    ○ ポリシーベース制御
    ● デバッグ/テスト⽀援とChaos Engineering
    ○ 分散トレース
    ○ Fault Injection
    ○ Dark Launch(Mirroring)
    

    View Slide

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/
    

    View Slide

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
    

    View Slide

29. Jaeger: Transaction Trace
    29
    

    View Slide

30. OpenTracing
    ● 分散システムにおけるトレースの標準化(CNCF)
    ○ 複数⾔語に対応
    ○ 複数のトレーサー(ソフトウェア/SaaS)に対応
    ○ ベンダーニュートラル
    ● 分散トレースのモデルを定義
    ○ https://opentracing.io/docs/best-practices/instrumenting-your-application/
    ● アプリケーションやフレームワークが安⼼して使える
    「分散トレースの抽象化層」を提供
    ○ JavaにおけるLog4Jのようなもの
    ○ OpenTelemetry: OpenTracingとOpenCensusとの統合 => デファクトへ
    30
    https://opentracing.io/
    

    View Slide

31. IstioとOpenTracing/Jaegerの関係
    ● OpenTracing
    ○ Istioにおける分散トレースのインターフェースとして利⽤
    ● Jaeger
    ○ Istioにおける分散トレースの実装のデファクト
    ○ 他のトレーサに差し替えも可能
    ● 透過的なトレース
    ○ Envoy経由のRESTは⾃動的にトレースの対象となる
    ○ より粒度の細かいトレースを取得する場合にはOpenTracingのAPIを利⽤
    した実装が必要
    31
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

36. CNCF, CloudEvents and Serverless
    

    View Slide

37. CloudEventsとは?
    ● Open Hybrid Cloud環境における「イベント」を抽象化
    ○ CNCFでホストされており、ベンダーから中⽴
    ○ 特定のプロトコルやペイロード(例: AWS SQS)に依存しない形でイベ
    ント処理が実装できる
    ○ データの相互運⽤性を確保するために、イベントのメタデータ(スキー
    マ)を定義するための仕様が決められている
    ○ さまざまな実装系に対して、イベントのバインディング(具体的なペイ
    ロードやプロトコルとの対応づけ)の定義が拡充されてきている
    ○ 軽量
    

    View Slide

38. CloudEvents情報まとめ
    ● Project
    ○ https://cloudevents.io/
    ● 仕様
    ○ https://github.com/cloudevents/spec
    ● Blog
    ○ CloudEventsの紹介、そしてServerlessな世界はこ
    れからどこへ向かうのか
    

    View Slide

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

    View Slide

40. OMOの基盤:「超⼤量データのリアルタイム処理」
    40
    ● Cloud Nativeメッセージバス
    ○ スケーラブルでハイパフォーマンスな分散処理
    ○ 無停⽌
    ○ 多様なクライアントに対応
    ● リアルタイム/オンデマンドデータ解析
    ○ 必要なときに⾃由に試⾏錯誤可能なワークベンチ
    ○ ストリームデータをリアルタイム処理可能
    ● Cloud Nativeストレージ
    ○ S3互換APIを備えたストレージ(Hadoopエコシステムの活⽤)
    ○ 必要なときに必要なだけの容量を確保
    ○ コストパフォーマンスに優れる
    

    View Slide

41. Cloud Nativeメッセージバス: Apache Kafka
    l LinkedInがEvent Trackingのため
    に開発した、超⾼スループットな
    分散メッセージブローカー
    p 現在はConfluent社主導でOSS
    として開発が進められている
    p アドテクやIoTなど応⽤分野が
    広がっている
    https://kafka.apache.org/
    41
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

46. ● AI/ML as a Service on Kubernetes/OpenShiftの
    リファレンスアーキテクチャ
    ● クラウドネイティブ: AI for the Hybrid Cloud
    ● OpenDataHub.io: コミュニティ主導
    Open Data Hub
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

50. 50
    まとめ
    

    View Slide

51. OMO時代にはKubernetesが常識となる
    =>Cloud Nativeと分散システムに取り組むべき
    まとめ
    51
    ● DXの先にある「アフターデジタル」
    ● OMO時代を⽀えるICTに求められること
    ● OMO時代のアプリケーションアーキテクチャ
    ● データから価値を⽣み出すための仕組み
    

    View Slide

52. Thank you
    52
    

    View Slide