Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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)

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Why Kubernetes with Kubernetes Operator? 13 Cloud NativeなIT基盤を構築するテクノロジーはコモデティ化しつつある どんな企業でもDigital Giantのようなパフォーマンスを発揮できる!! App配備 Platform Portability コンテナ サービス 管理 Auto Scaling / Auto Healing オーケストレータ (Kubernetes) Day2 Operation SW固有の運⽤ の⾃動化 Kubernetes Operator

Slide 14

Slide 14 text

コンテナによるアプリケーション可搬性 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ホスト = あらゆる環境での可搬性

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Kubernetes Operatorとは 18 https://www.youtube.com/watch?v=LymzLHRbQdk 運⽤をソフトウェアによって作り込む「SRE(Site Reliability Engineering)」の実装パターン Kubernetes Applications ソフトウェア運⽤の知⾒をコード化し、 パッケージ化したもの Kubernetes APIを拡張するアプリケーシ ョンコントローラーを通じ、スケーリン グ、バックアップ、アップデートなどを 適切に⾏う ・CRD (Custom Resource Definition) ・Custom Controller

Slide 19

Slide 19 text

● 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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

開発者が想定しがちな 分散システムにおける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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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/

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Jaeger: Transaction Trace 29

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

CNCF, CloudEvents and Serverless

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

50 まとめ

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Thank you 52