クラウドネイティブのトレンド考察 / Cloud Native Trend

Presentation slides for Customer study session
技術アドバイザー
Date: 2019/10/03

Transcript

1. クラウドネイティブのトレンド考察 Yoichi Kawasaki @yokawasa Presentation Slides – 2019.10.3
2. 川崎 庸市 / Yoichi Kawasaki @yokawasa https://github.com/yokawasa クラウドネイティブ＆NoOps愛好家、NoOps Japanコミュニティー運営者、時間外プログラマー。 過去にKラボラトリ、ヤフー株式会社にて主にインターネットサービスの基盤プラットフォーム開発 のソフトウェアエンジニア、マイクロソフトにてエンタープライズ検索コンサルタント、Azure専門 のソリューションアーキテクト等を経験。 CKA, CKAD資格保有
4. CNCF Cloud Native Definition v1.0 Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. 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. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor- neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. https://github.com/cncf/toc/blob/master/DEFINITION.md Cloud Native の定義（CNCFによる定義）
5. 能力 エクスペリエンス 技術 アーキテクチャ クラウドネィテブ アプリケーション
6. コンピューティングの進化とアーキテクチャのトレンドの変化 1970 1980 1990 2000 2010 2020
9. 経済産業省 IT人材の最新動向と将来推計に関する調査結果 (平成28年6月10日) http://www.meti.go.jp/policy/it_policy/jinzai/27FY/ITjinzai_report_summary.pdf
11. コンテナ＆サーバレス のトレンド
12. From Docker.inc : https://docs.docker.com/get-started/#images-and-containers ホストOS上に配置されたライトウェートで高速に動作する分離された層 最終的にホストOS上の1プロセスとして実行されているアプリ コンテナー化 仮想化
13. マイクロサービスアーキテクチャでは、アプリが比較的 小規模の独立したサービスで構成され、複数コンテナを 連携させる必要がある。よって、複数コンテナを管理す るオーケストレーション機能が重要な役割を担う (Kubernetes, Docker Swarm, etc)
14. Layer 1 Layer 2 Layer 3 Layer 4 Layer 5 Layer 6 Layer 7 参考: Gabe Monroy on Twitter: "Strata of the Container Ecosystem https://twitter.com/gabrtv/status/539805332432637952 https://trends.google.co.jp/trends/explore?date=today%205- y&q=Kubernetes,Mesosphere,Docker%20Swarm
15. Kubernetes（クーバネティス） Master VM Master VM Master VM Worker Node Worker Node Worker Node Worker Node Worker Node Worker Node kubectl apiserver Web UI etcd scheduler Controller manager kubelet kube proxy Container LB CLIコマンド ダッシュボード 永続化データ保持のためのKVS 認証、CRUD操作 Podのノード割り当て 各種コントローラー ノードごとの Pod管理 Service VIPアドレスのルーティング 外部からの アクセス 全ての操作はapiserver経由 API Container runtime kubelet kube proxy Container ノードごとの Pod管理 Service VIPアドレスのルーティング Container runtime https://kubernetes.io/docs/concepts/overview/components/
16. https://kubernetes.io/
17. DeploymentとReplicaSetの仕組みで、ノードの障害やアプリのクラッシュ等で Podが足りなくなった際に自動的にPodが追加される DeploymentはReplicaSetを管理し、ReplicaSetはPodを指 定数(Replica数)に調整・管理を行う仕組。 Podがレプリカ数より足りない場合はPodを追加し、多 い場合はをPodを削除する Deployment ReplicaSet Pod A Pod B Pod C Deployment ReplicaSet Pod A Pod B Pod C Pod C
18. Deployment ReplicaSet V1 Pod Pod Pod Deployment ReplicaSet v1 Pod Pod ReplicaSet V2 Pod Deployment ReplicaSet V2 Pod Pod Pod
19. Docker＆Kubernetesのモメンタム IDC Japan社 2018年 国内クラウドインフラストラクチャに関するユーザー動向調査結果 https://www.idcjapan.co.jp/Press/Current/20180614Apr.html Dockerの導入状況に関するユーザー調査結果（調査年別） 41%
20. https://twitter.com/jbeda/status/993978919907770368 https://twitter.com/jbeda/status/993978924890640388 Kubernetesは複雑 https://thenewstack.io/has-kubernetes-already-become-too-unnecessarily-complex-for-enterprise-it/ “When we started with YAML we never intended it to be the user-facing solution,” Beda wrote. “We saw it as ‘assembly code.’ I’m horrified that we are still interacting with it directly.
21. コンテナ年表 2013 Docker 登場 2008 LXC 2014 2015 2016 2017 2018 Google k8s発表 CNCF 設立 2013.3 2014.6 k8s1.0 2015.7 Docker Swam発表 2014.12 Mesosphere DC/OS発表 2016.4 Docker k8sサポート 宣言 2017.10 k8s1.10 2018.3 EKS, AKS がGA 2018.6 k8s標準時代 コンテナ群雄割拠 ( Docker & Kubernetesフォーカス )
22. CNCF (Cloud Native Computing Fundation) • コンテナ運用環境の標準化 • Container network interface (CNI) • Container Storage interface (CSI) • k8s認定プログラムの実施により標準Kubernetesの普及を推進
23. 標準化により拡大・成熟するコンテナエコシステム
24. Pod Phase, restartPolicy Liveness & Readiness Probe Rolling Update Horizontal Pod Autoscaler Cluster Autoscaler
25. Open Service Broker • Rook • NATS • その他多数 Operators： etcd, HPA, PVC, MySQL, Postgres, Mongodb, Redis, Jaeger, Envoy, Kafka, Prometheus, etc. StatefulSet DaemonSet Service Catalog
26. • Helm • Draft • Skaffold • Spinnaker • Jenkins X
27. Logging Observability Tracing Visualizatio n Monitorin g 豊富な選択肢 標準化 Observability構成要素
29. Serverless＝サーバが無い Serverless＝サーバを管理する必要がない
30. Serverless computing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment. Serverless computing does not mean that we no longer use servers to host and run code; nor does it mean that operations engineers are no longer required. Rather, it refers to the idea that consumers of serverless computing no longer need to spend time and resources on server provisioning, maintenance, updates, scaling, and capacity planning. Instead, all of these tasks and capabilities are handled by a serverless platform and are completely abstracted away from the developers and IT/operations teams. As a result, developers focus on writing their applications’ business logic. Operations engineers are able to elevate their focus to more business critical tasks. A serverless computing platform may provide one or both of the following: 1. Functions-as-a-Service (FaaS), which typically provides event-driven computing. Developers run and manage application code with functions that are triggered by events or HTTP requests. Developers deploy small units of code to the FaaS, which are executed as needed as discrete actions, scaling without the need to manage servers or any other underlying infrastructure. 2. Backend-as-a-Service (BaaS), which are third-party API-based services that replace core subsets of functionality in an application. Because those APIs are provided as a service that auto-scales and operates transparently, this appears to the developer to be serverless. https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview スケーリングされ、使った分だけ課金 • Functions-as-a-Service (FaaS) • Backend-as-a-Service (BaaS)
31. 2014 2015 2016 2017 2018 AWS Lambda 2014.11 Google Cloud Functions Azure Functions 2016.2 2016.3 IBM Cloud Functions Serverless Framework 2015.10 2016.12 OpenWhisk (OSS) by IBM Fn Project (OSS) by Oracle 2017.10 Serverless Whitepaper by CNCF 2018.2 2019 2018.12 Oracle Function 2018.7 Knative by Google
32. Tech Adoption 2019 https://www.infoq.com/about-infoq CHASM
33. MartinFowler.com - Serverless Architecture https://martinfowler.com/articles/serverless.html
36. Service Meshとは？ Data Plane Control Planeからの設定やポリシー内容 を元にプロキシを通じて の機能を提供 Envoyproxy Blog: Service mesh data plane vs. control plane https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc Control Plane Data Planeと独立してMesh全体の Data Planeに設定・ポリシーを伝達 させる役割 ① Control PlaneとData Planeで構成
37. • Pilot: • Mixer: • Citadel: https://istio.io/docs/concepts/what-is-istio/
38. Service Meshとは？ ② ネットワーク抽象化レイヤー
39. Pod Pod Pod サーキット ブレーカー パターンの実装 https://docs.microsoft.com/ja-jp/dotnet/standard/microservices- architecture/implement-resilient-applications/implement-circuit-breaker-pattern Pod Pod Pod Pod Pod Pod 要求が一定回数失敗する場合そ のインスタンスを一時的に利用 不可にする
40. Pod Pod Pod Pod Pod Pod Pod Pod Pod 要求が一定回数失敗する場合そ のインスタンスを一時的に利用 不可にする Service Breaker用Destination Ruleの設定 (Istio) https://istio.io/docs/tasks/traffic-management/circuit- breaking/ Service Meshの設定
41. Service Mesh機能を提供する代表的なソフトウェア https://github.com/istio/istio https://github.com/linkerd/linkerd https://www.consul.io/ https://www.envoyproxy.io/
42. Discovery & Load Balancing round robin, random, weighted least request Traffic Splitting A/B testing, canary rollouts, staged rollouts Traffic Control Handling Failures circuit breakers, timeouts, and retries Fault Injections delays or abort Rate Limiting Distributed Tracing Collecting Logs & Metrics Service Graph Authentication Policy Mutual TLS Authentication Istio RBAC https://istio.io/docs/concepts/what-is-istio/
43. 特定プラトフォームに依存しない、マルチクラウド、マルチプラット フォーム化の動きが活発化しており、 • 可搬性確保、アーキテクチャの柔軟性確保、ベンダーロックイン、特定クラウ ドのサービス・アーキテクチャへの極度の依存の回避が主な目的 • テクノロジーの進化と標準化の結果でもある
44. OSS Serverless Platform OSS Serverless Framework Public Cloud
45. https://www.pulumi.com/serverless/ https://github.com/pulumi/examples/blob/master/azure-ts- functions/index.ts
46. Kubernetes Service Mesh アプリのライフサイクルの抽象化 (マルチ〇〇) Knative - https://github.com/knative/docs コンテナ運用基盤の抽象化 ネットワークの抽象化 アプリライフサイクルの抽象化 アプリライフサイクルの抽象化の動き は今後一層高まっていくでしょう
47. コンテナ運用基盤 の抽象化 ネットワーク の抽象化 アプリライフサイクル の抽象化 • コードのビルド • パッケージング • リクエスト受信 • ルーティング • スケール • イベントソースの 抽象化 • コードの発火 https://knative.dev/docs/serving/ https://knative.dev/docs/eventing/ https://knative.dev/docs/build/
48. Kubernetes-based Serverless • Knative • KEDA • Virtual Kubelet
49. https://github.com/kedacore/keda • KubernetesのHPA (Horizontal Pod Autoscaler)は全PodのCPUやメモリ消費率 でスケールを調整するのが基本動作 • KEDAはRabbit MQ 、Kafka Streaming、 Azure Storage Queue、Azure Service Bus Queueなど非HTTPなイベントに連動した Podのスケール調整ができるのが特徴 • KEDAがZeroスケールイン・アウトして、 それ以外はHPAがスケールイン・アウト Storage Queue ServiceBus Queue Kafka RabbitMQ HPA KEDA 1->N or N->1 0->1 or 1->0 … K E D A
51. 正しい選択をするためのヒント
54. (アジリティ) 開発・デプロイの迅速性、生産性 (責任範囲)
55. • 責任範囲は広いものの自由度を優先したいならばオンプ レ、IaaS。 • 過去のノウハウを比較的踏襲しやすい • CaaS、PaaS、FaaSはレベル差はあるものの分散システム の複雑さを高レベルに抽象化されている（回復性、弾力 性、セキュリティ対策などさまざまな能力が組み込み済 み） • 学習カーブや制約度合い、アーキテクチャ・運用方式の 変更最適化に伴うコストの考慮が必要
58. Open Service Broker Rook, NATS,その他多数 Operators（etcd, HPA, PVC, MySQL, Postgres, Mongodb, Redis, Jaeger, Envoy, Kafka, Prometheus, etc） StatefulSet DaemonSet Service Catalog
59. CosmosDB SQL Database Azure Database for MySQL Azure Database for PosgreSQL
62. 要件 内容例 可用性 回復性、稼働率、RTO(目標復旧時間) 、RPO(回復ポイント目標) 性能・拡張性 ユーザ数、RPS、目標レスポンス速度、成長に応じた拡張 運用保守性 バックアップ、計画停止、運用監視、障害時対応、運用自動化 移行性 移行時期、並行稼働有無、システム展開方式、移行データ量 セキュリティ コンプライアンス、リスク分析、通信制御、認証、不正検知・追跡・ 監視 情報処理推進機構（IPA）の非機能要件グレード 非機能項目（大項目）と、内容例
63. • 開発運用体制の充実度 • スキルレベル・経験 • 納期までの時間 • 経済力 • 既存システム資産 • サポータビリティ （商用サポート、SLA、 etc.） • etc
64. 既存 アプリ APP モダン マイクロサービス クラウドネイティブ アプリ モダン メソッド CI/CDの実装 自動化 モダン インフラ クラウド移行 VM / コンテナー (Lift & Shift) アプリの コンテナー化 コンテナーで アプリ再設計
66. • 本当にマイクロサービス化する必要はありますか？ • 本当にKubernetesが必要ですか？ • それ全部FaaSで実現するのですか？ • もっとシンプルな方法はないですか？
67. Wrap Up
69. https://devlove.doorkeeper.jp/events/98173