What is Cloud Native ?

CloudNative Days Tokyo 2021 資料

Transcript

1. What is Cloud Native ? Yutaka Ichikawa CloudNative Days Tokyo 2021 Cloud Native Definition DevOps CI/CD Microservices Observability
2. Publications Certification & Community CKA CKAD 2018 2019 Profile Name: Yutaka Ichikawa Twitter/GitHub/Qiita: cyberblack28 Hatena Blog: https://cyberblack28.hatenablog.com/ Slides: https://speakerdeck.com/cyberblack28 Job Principal Cloud Solution Engineer Solutions Architect Cloud Engineering Oracle Corporation Japan 2021 #CNDT2021
3. Agenda • Cloud Native Definition ◦ Cloud Native Computing Foundation（CNCF）につい て ◦ クラウドネイティブとは？ ◦ そもそもクラウドコンピューティングとは？ ◦ クラウドコンピューティングの特性 ◦ クラウドネイティブを実現する道しるべ ◦ 自動化の目的 ◦ 結局のところ、クラウドネイティブとは？ • DevOps ◦ DevOpsとは？ ◦ DevOpsを実現する方法 • CI/CD ◦ これまでのアプリケーション開発 ◦ OS/ライブラリとアプリケーションの分離 ◦ 仮想マシンとコンテナの違い ◦ OS/ライブラリとアプリケーションの統合 ◦ コンテナを支えるオーケストレーション ◦ コンテナアプリケーション開発における CI/CD • Microservices ◦ マイクロサービスの二つの側面 ◦ マイクロサービスの進化と挑戦 ◦ コンテナにおけるマイクロサービスを実現する技術 ◦ ビジネス面におけるマイクロサービス ◦ マイクロサービスの特徴 ◦ マイクロサービスも結局 • Observability ◦ そもそも監視って？ ◦ オブザバビリティの背景 ◦ オブザバビリティとは ? ◦ テレメトリー ◦ オブザバビリティは、クラウドネイティブシステムを支え る
4. Cloud Native Definition
5. Cloud Native Definition Cloud Native Computing Foundation（CNCF）について • The Linux Foundation傘下のプロジェクトの1つ • 2015年に創設された財団 • コンテナ技術の推進と、その進化を取り巻くテクノロジー業界の足並みを揃えることを目的 • 大手クラウド事業者、ミドルウェア企業、ハードウェア製造企業、オープンソース・ソフトウェア企 業、大学、その他非営利団体などが加入
6. Cloud Native Definition 年3回、Europe、China、North AmericaでCNCF主催「KubeCon + CloudNativeCon」を開催 KubeCon + CloudNativeCon North America 2019 San Diego
7. Cloud Native Definition クラウドネイティブとは？ Cloud Native Computing Foundation（CNCF）におけるクラウドネイティブの定義 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、ス ケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービ スメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。
 
 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせるこ とで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 
 
 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダイムの 採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。
 Cloud Native Computing Foundation(CNCF) Cloud Native Definition v1.0 | https://github.com/cncf/toc/blob/master/DEFINITION.md ”拡張性・柔軟性に優れたアプリケーションをクラウドの特性を活かして、 最小限の労力で構築および実行できるようにする”
8. Cloud Native Definition そもそもクラウドコンピューティングとは？ The NIST Definition of Cloud Computingにおけるクラウドコンピューティングの定義 クラウドコンピューティングとはモデルであり、構成変更が可能なコンピューティング資源（例としてネットワーク、サービス、ストレージ、ア プリケーション、サービス）の共有プールを、オンデマンドなネットワークアクセスで可能にする。
 
 それはわずかな管理の手間、もしくはサービスプロバイダとのやりとりによって迅速に準備され、提供される。
 
 このクラウドモデルは可用性を促進するものであり、5つの本質的な性質と、3つのサービスモデル、そして4つのデプロイメントモデルか ら構成される。
 The NIST Definition of Cloud Computing | https://csrc.nist.gov/publications/detail/sp/800-145/final 5つの本質的な性質
 • オンデマンド・セルフサービス
 • 幅広いネットワークアクセス
 • リソースの共有
 • 迅速な拡張性
 • 計測可能なサービス
 3つのサービスモデル
 • Cloud Software as a Service (SaaS) • Cloud Platform as a Service (PaaS) • Cloud Infrastructure as a Service (IaaS) 4つのデプロイメントモデル
 • プライベートクラウド
 • コミュニティクラウド
 • パブリッククラウド
 • ハイブリッドクラウド

9. Cloud Native Definition クラウドコンピューティングの特性 オンプレミスでは困難なことが、クラウドコンピューティングは実現できる • オンデマンド・セルフサービス • 幅広いネットワークアクセス • リソースの共有 • 迅速な拡張性 • 計測可能なサービス • 資産保有が不要 • 利便性が高い • リソース調達が早い • 柔軟な拡張性 • 利した分だけ課金
10. Cloud Native Definition クラウドネイティブの道しるべ CNCF Trail Map | https://github.com/cncf/trailmap 1.CONTAINERIZATION | コンテナ化
 仮想マシンとは異なり、環境差異が無く、軽量なイメージで可搬性が高く、リ リースサイクルを速め、機敏さと信頼性を兼ね備えたアプリケーションリリース を実現
 2.CI/CD | 継続的インテグレーション/デリバリー
 ソースコードの変更を契機に、自動的なビルド、テスト、ステージング環境およ び本番環境へのデプロイにつながるCI/CD環境を構築する
 3.ORCHETRATION & APPLICATION DEFINITION | オーケストレーションツールとアプリケーション定義 コンテナ化されたアプリケーションをKubernetes基盤で自律的に運用
 Helmを利用して、マニフェストを効率的に管理
 コンテナ化
 開発自動化
 運用自動化
 ”拡張性・柔軟性に優れたアプリケーションを最小限の労力で構築および実行”
11. Cloud Native Definition 自動化の目的 人的関与を極力減らして向上化
 技術に任せられるものは任せて効率化、
 そして、人にしかできないことに時間やコストを傾ける
 向上したビジネス価値をエンドユーザ様に提供する

12. Cloud Native Definition 結局のところクラウドネイティブとは？ 「CNCFに関連するプロダクト利用 = クラウドネイティブ」
 ではない
 CNCF Cloud Native Interactive Landscape | https://landscape.cncf.io/
13. Cloud Native Definition 人的関与を極力減らしてビジネス価値の向上を目指して、
 それをエンドユーザ様に届けるマインドを持つこと

14. Cloud Native Definition CloudNative Days Fukuoka 2019 『飛び込もうCloud Nativeの世界』 草間一人(@jacopen) | https://speakerdeck.com/jacopen/fei-biip-mou-cloud-nativefalseshi-jie
15. DevOps
16. DevOps DevOpsとは？ 開発（Development）と運用（Operations）が互いに協力し合うことで、 開発・運用するソフトウェア・システムによってビジネス価値を高めるだけでなく、 そのビジネス価値をより確実かつ迅速にエンドユーザに届け続ける概念 Dev Ops
17. DevOps DevOpsを実現する方法 • 「計画、設計、実装、テスト」という開発工程を機能単位の小さいサイクルで繰り返して開発を行う 開発手法 • ウォーターフォールと異なり、仕様変更に強く、プロダクトの価値を最大化することを目的とする • サービスインまでの時間を短縮できる 1.アジャイル開発 企画
 リリース
 リリース
 リリース
 計画
 実装
 設計
 テスト
 計画
 実装
 設計
 テスト
 計画
 実装
 設計
 テスト

18. DevOps DevOpsを実現する方法 2.CI/CD（継続的インテグレーション/継続的デリバリー） 
 • ソースコードからアプリケーションとしてビルドするタイミングでテストを行って、完成した成果物 （アーティファクト）を保存するまでの工程を自動化 • 早期にバグを発見、対処できることでアプリケーションの品質を高めることができる仕組み 継続的インテグレーション（CI: Continuous Integration） • 継続的インテグレーションによって生成された成果物（アーティファクト）をステージング環境や本 番環境などの各環境に配置する仕組み • リリース作業を簡素化して、安全、スピード、品質の向上を実現するプロセス 継続的デリバリー（CD: Continuous Delivery）
19. CI/CD
20. CI/CD これまでのアプリケーション開発 物理マシン
 仮想マシン
 仮想マシン（クラウド） 
 コンテナ
 VM 物理サーバでアプリケーションを稼働 
 物理サーバ上に複数の仮想マシンでアプリケーションを稼働 
 クラウドをベースとしたスケーラブルな仮想マシンでアプリケーション を稼働
 物理マシン・仮想マシンもノードとして束ねて、コンテナという小さい 単位でアプリケーションを稼働 

21. CI/CD Developer Code Repository CI/CD Pipeline アプリケーション OS/ライブラリ 開発環境 検証環境 ステージング環境 本番環境 VM Operator Infrastructure Engineer コードをコードリポジトリにコミット /プッシュ
 CI/CDパイプラインによるテス ト、ビルド、デプロイ
 すべて自動化されている場合もあれば、手動で行う場合もあります。 
 物理マシン
 仮想マシン
 仮想マシン（ク ラウド）

22. CI/CD アプリケーション OS/ライブラリ 開発環境 検証環境 ステージング環境 本番環境 VM OS/ライブラリとアプリケーションの分離
 物理マシン
 仮想マシン
 仮想マシン（ク ラウド）
 アプリケーションは物理マシンや仮想マシンの OS/ライブラリ上で稼働 稼働するアプリケーションは 実行環境に依存する 環境差異が原因で他の環境で稼働するけど、 本番環境で稼働しない 等の障害が発生する OSのパッチバージョンが異なる、このライブラリ が無かった、関係ないものがインストールされて いる…

23. CI/CD アプリケーション OS/ライブラリ 物理/仮想マシンにおける、OS/ライブラリのアップデートには 人手や時間を要するため、アプリケーションのリリースに影響 する… ハイパーバイザー
 VMWare Xen/Server KVM ハードウェア
 VMWare Xen/Server KVM 仮想マシン イメージ
 • 仮想マシンイメージが ベンダー製品特有（ベン ダーロックイン）
 • 容量も重い（数ギガ～数十ギガ） 
 • 可搬性が低い

24. CI/CD これまでのアプリケーション開発 
 OS/ライブラリが既に整っている実行環境にアプリケーションをデプロイするという形式 1.アプリケーション • 環境差異による問題が発生
 • OS/ライブラリ側に何かあるとアプリケーションに影響 
 2.インフラ • 仮想マシンイメージがベンダー製品特有（ベンダーロックイン） 
 • 仮想マシンイメージの容量が重く可搬性が低い 
 • 物理/仮想マシンの特性上、OS/ライブラリのアップデートに時間を要して、アプリケーションのリ リースに影響する

25. CI/CD 仮想マシンとコンテナの違い ハードウェア
 ハードウェア ハイパーバイザー
 カーネル 仮想マシン
 仮想マシン
 コンテナエンジン コンテナ
 コンテナ
 カーネル
 カーネル
 ライブラリ
 ライブラリ
 アプリケーション
 アプリケーション
 ライブラリ
 アプリケーション
 ライブラリ
 アプリケーション
 仮想マシン
 コンテナ
 各仮想マシンのカーネル上で実行、 隔離性が高い が、起動が遅く（数分）オーバヘッドが大きい 。
 カーネルを共有しているため、 隔離性は低いが、起 動が高速（数秒）でオーバヘッドが小さい 。

26. CI/CD OS/ライブラリとアプリケーションの統合 1.ビルド（Build） • OS/ライブラリとアプリケーションをパッケージイメージ化 • 技術としてはOSSのため、ベンダーロックインは発生しない • イメージはこれまでの仮想マシンイメージに比べると はるかに軽いので可搬性が高い OS/ライブラリ
 アプリケーション
 OS/ライブラリ
 コンテナイメージ
 ビルド (Build)
27. CI/CD 2.シップ（Ship） • イメージをレジストリに保存 • レジストリからコンテナプラットフォームへ共有 OS/ライブラリ
 コンテナイメージ
 プッシュ (Push) OS/ライブラリ
 イメージレジストリ
 プル (Pull) OS/ライブラリ
 コンテナプラットフォーム OS/ライブラリ
 シップ(Ship) イメージ共有
28. CI/CD 3.ラン（Run） • コンテナイメージをベースにコンテナを起動 OS/ライブラリ
 コンテナプラットフォーム ラン（Run） コンテナイメージ
 コンテナ
 OS/ライブラリ
 コンテナプラットフォーム上でイメージからコンテナを起動して、アプリケーションを稼働。 コンテナイメージもプラットフォームもベンダー技術に依存しないため、ベンダーロックインも無い。
29. CI/CD コンテナアプリケーション開発
 OS/ライブラリとアプリケーションを統合して、軽量イメージ化して、コンテナプラットフォームにコンテナと してデプロイする形式 1.アプリケーション • OS/ライブラリとアプリケーションが一つに統合されているため、環境差異による問題が起きにくい 
 2.インフラ • 仮想マシンイメージと仕組みが異なり、OSSベースでベンダーロックインもなく、軽量で可搬性が高 い
 • OS/ライブラリのアップデートも容易なため、リリースサイクルを速め、スピード（Agility）が向上 

30. CI/CD コンテナを支えるオーケストレーション 
 Kubernetesは、Google社内のコンテナーオーケストレーションシステムである Borgからインスパイアさ れて開発されたOSSのコンテナーオーケストレーション。 読み方：クーバーネーティス、クーバネティス、クバネティス等 略称：K8s（Kubernetes） 8文字 現在は、CNCF(Cloud Native Computing Foundation)で管理され、多数の企業が参加するコミュニ ティで開発。
31. 主な役割
 実現
 CI/CD Kubernetesの主な役割と実現 • コンテナのスケジューリング 
 • ローリングアップデート 
 • オートスケーリング 
 • 死活監視
 • コンテナの自動修復 
 • サービスディスカバリ 
 • ロードバランシング 
 • 頻繁なアプリケーションのデプロイ を可能にするシ ステム基盤
 • 無停止によるリリース、高可用 なシステム基盤 
 • 負荷に応じた伸縮自在なシステム基盤 

32. CI/CD YAML Kubernetesクラスタ 宣言的オペレーション マニフェストファイル Controller Reconciliation loop 登録 監視 コンテナ管理 （作成・削除） Controller内のReconciliation loop（調整ループ）と呼ばれる、 あるべき理想の状態へ収束させるループ処理を実行。 Controllerがあるべき理想の状態へ収束
33. CI/CD Reconciliation loop Observe 現在の状態を確認
 Analyze あるべき理想の状態と現在の状態 
 との差分を分析
 Act 分析した差分に対する処理を実行 

34. CI/CD Kubernetesクラスタ あるべき理想の状態 Controller Reconciliation loop 宣言的オペレーション 指定された 「replicas: 3」 のPod数を維持すること Observe Analyze Act
35. CI/CD Kubernetesクラスタ あるべき理想の状態 Controller Reconciliation loop 宣言的オペレーション （例）起動しているPodが2個の場合 Observe Analyze Act Observe 理想:3 現状:2
36. CI/CD Kubernetesクラスタ あるべき理想の状態 Controller Reconciliation loop 宣言的オペレーション （例）起動しているPodが2個の場合 Observe Analyze Act Analyze 理想状態と比較して、Podが1個足りない
37. CI/CD Kubernetesクラスタ あるべき理想の状態 Controller Reconciliation loop 宣言的オペレーション （例）起動しているPodが2個の場合 Observe Analyze Act Act 「image: nginx:1.21.0」のPodを作成
38. CI/CD Kubernetesは分散処理基盤
 Virtual Machine BareMetal Kubernetes Container
39. CI/CD Kubernetes is becoming the Linux of the cloud by Jim Zemlin （The Linux Foundation）
40. CI/CD Multi-Cloud to Multi-Kubernetes Cloud Native to Kubernetes Native
41. CI/CD コンテナアプリケーション開発における CI/CD 1.CIOps Push型 ソースコードが更新されるたびに CIパイプラインが稼働して、アプリケーションテスト、コンテナイメージビ ルド、コンテナイメージプッシュ、 CDパイプラインによるデプロイ。 開発環境 検証環境 ステージング環境 本番環境 物理マシン
 仮想マシン
 仮想マシン（ク ラウド）
 VM コンテナプラットフォーム OS/ライブラリ
 OS/ライブラリ
 Operator Infrastructure Engineer Developer Code Repository CI/CD Pipeline Build Ship Run CIパイプラインによるテスト、ビル ド、イメージプッシュ コンテナプラットフォーム へのデプロイ OS/ライブラリ 
 OS/ライブラリ 
 イメージ共 有 コードをコードリポジトリにコミット/プッシュ 
 Code,Dockerfile,manifest Image Registry CI CD
42. CI/CD 2.CIOpsにおけるセキュリティリスクと管理の煩雑化 Developer Code Repository CI/CD Pipeline Image Registry Dev/Staging/Prod Read Read/Write Read/Write Read Read/Write Image Pull apply Kubernetesクラスタが増えるたびにセキュリティ 含めた設定や権限管理も増えるため、管理が煩 雑となる。
 Kubernetesクラスタ外部での権限管理となるため、セキュリティリスクがある。
43. CI/CD 3.マニフェストの再現性 Developer Code Repository CI/CD Pipeline Image Registry Dev Image Pull 1.パイプラインの実行順序が保証されるとは限ら ず、適用されたクラスタ状態が想定と異なること に。
 Staging Prod 2.ロールバックするにも、マニフェストの更新履歴 を追うなど、迅速性に欠けてしまう。 

44. CI/CD 4.GitOps Pull型 Kubernetesクラスタ内に配置されたGitOpsオペレーターがConfigリポジトリを定期的にポーリングし て、更新を検知して更新内容をKubernetesクラスタに反映する仕組み。 開発環境 検証環境 ステージング環境 本番環境 物理マシン
 仮想マシン
 仮想マシン（ク ラウド）
 VM コンテナプラットフォーム OS/ライブラリ
 OS/ライブラリ
 Operator Infrastructure Engineer Developer Config Repository CI Pipeline Build Ship Run コンテナプラットフォーム へのデプロイ OS/ライブラリ 
 OS/ライブラリ 
 Image Registry Code Repository GitOps オペレター CI CD ① Code Change & Git Push ④ Pull Request Merge ② Image Build & Test & Image Push ③ Pull Request ⑤ Polling & Sync イメージ共有 Code Dockerfile manifest
45. CI/CD 5.GitOpsのメリット • マニフェストファイルをGit管理 ◦ デプロイ先に対して「誰が、何時、何」を変更したのかを履歴で追える ◦ デプロイ先をいつでも前の状態に戻すこと（ロールバック）ができる ◦ プルリクエストによるレビュー・マージプロセスを通すことで組織ガバナンスを適用できる • 自動化 ◦ 手動コマンドによるヒューマンエラーの排除 ◦ 運用コストの軽減
46. CI/CD 6.コンテナアプリケーション開発における CI/CDが目指すところ コンテナの可搬性（Portability）とスピード（Agility）を持ち合わせ、 品質および生産性の高いアプリケーション開発を実現 これまで時間やコストを要していた箇所の改善、
 より良いビジネスロジックに時間やコストを傾ける
 リリースサイクルを速め、
 エンドユーザ様に最高品質のサービスを提供
 エンドユーザ様の満足度、企業収益、ビジネス価値の向上につながる 

47. CI/CD クラウドネイティブにおけるコンテナアプリケーション開発は、銀の弾丸ではない 実際に開発するアプリケーションの特性、組織体制、チーム体制、コスト、教育など 基盤・開発・運用の観点からしっかりと見据えて適材適所に検討する必要がある
48. Microservices
49. Microservices マイクロサービスの二つの側面 マイクロサービスには、「開発組織・文化の側面」と「技術の側面」の二側面がある。 1.開発組織・文化の側面 開発組織の成長に伴うチーム、人員が増加しても、小規模なチーム開発と同様の素早いプロダクト開 発を維持する。 2.技術の側面 マイクロサービスは、個々に開発された複数の小さなサービスを連結させて、設計と運用を実現するソ フトウェアのアーキテクチャ。
50. Microservices マイクロサービスの進化と挑戦 チームが小さい場合
 • 一つのアプリケーションに機能を集約して開発 
 • 速度と開発品質の面で合理的 
 チームが大きい場合
 • コミュニケーションコストの増加 
 • 20人以上になるとチーム破綻へ 
 会議に限らず、開発チーム人数においても理想は “ Two Pizza Rule ” “会議の参加者が多いほど、生産性は低下する。これを解決するために、参加メンバーを2枚のピザを分け合える人数に抑える。” 
 https://landing.directorpoint.com/blog/amazon-two-pizza-rule/
51. Microservices マイクロサービスの前段として組織の細分化 100人を一つにして開発するよりも、主要な機能を10個に分けて機能ごとに10人のチームを10個作って 開発した方が効率的。
 100人で開発
 10人のチームを10チーム作って開発

52. Microservices 組織の分散化による課題 大きいチームとしての課題を解消しきれない 
 コミュニケーションコストの増 加
 チーム裁量の低下
 曖昧な責任範囲

53. Microservices 技術においても組織の分散化に合わせて分散化を進める この開発手法がマイクロサービス 
 • 小さいチームが自律的に機能することで、全体としてのプロダクト開発スピードを向上 
 • 各チームでデプロイサイクルが独立しているので、要件に沿って自由にリリース可能 
 • チームごとにパフォーマンス要件の異なるアプリケーションをスケーリング可能 
 • 機能増加と共にチームと人員もスケールすることで、アプリケーションと組織が同時に成長 

54. マイクロサービスの9つの特徴 Microservices マイクロサービスにおけるガイドライン 
 • サービスによるコンポーネント化
 • ビジネス機能に基づいたチーム編成
 • プロジェクトではなく製品として捉えて開発運用
 • インテリジェントなエンドポイントシンプルなパイプ
 • 非中央集権的な言語やツールの選択
 • 非中央集権的なデータ管理
 • ITインフラの自動化（Infrastructure as Code）
 • 障害、エラーを前提とした設計
 • 先進的な設計
 James Lewis/Martin Fowlerの"Microservices" | https://martinfowler.com/articles/microservices.html
55. Microservices 2018年にメルカリがマイクロサービスアーキテクチャを採用して、組織、サービス、そして企業としても 拡大を目指し、継続中。 https://www.itmedia.co.jp/enterprise/articles/1810/11/news049.html
56. Microservices モノリスからマイクロサービス アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション モノリス マイクロサービス
57. Microservices そして、モダナイズ クラウドネイティブ技術を利用したマイクロサービス Virtual Machine / BareMetal Kubernetes
58. Microservices コンテナにおけるマイクロサービスを実現する技術 Service Mesh App Proxy Pod Container Container アプリケーションとプロキシ機能の分離 
 アプリケーションプロセスごとに専用のプロキシを配置して、 そのプロキシにネットワーク周りの仕事をまかせます。 
 プロキシ機能の中央管理 
 Control Plane App Proxy App Proxy App Proxy App Proxy プロキシ機能は大量になるのでコンフィグレーションの管理 コストが増加。中央にプロキシ機能の管理するコントロール プレーンを配置して効率的に管理。 

59. Microservices マイクロサービスの特徴 マイクロサービス・アーキテクチャ 大規模なシステムを疎結合な複数のサービスの組み合わせで実現する設計方式 
 • アップデートの容易性 
 • スケールの容易性
 • 高可用性
 サービスA
 サービスB サービスC サービスF サービスE サービスD サービスA
 サービスB サービスC サービスF サービスE サービスD システムA
 システムB

60. Microservices アップデートの容易性 
 • 他のサービスへの影響を極小化した形で、アップデート対象のサー ビスのみをアップデート可能 
 • 高頻度にサービスのアップデートが可能 
 スケールの容易性
 • 他のサービスに影響を与えることなく、必要なサービスのみをス ケールアウト可能
 • 使用するリソースを最適化 
 高可用性
 • サービスが独立しているため、障害の影響を極小化 
 • 残ったサービス群でサービス提供を継続していくことが可能 
 アップデート 
 スケール
 障害
 障害影響なし

61. Microservices ビジネス面におけるマイクロサービス 顧客向け 新ビジネス 創造 社内業務 効率化 社外 社内 ビジネス 創造 業務効 率化 ビジネスには進化のスピードと品質が求められる • サービスの早期リリース 
 • 市場の動向/反応を早期フィードバックして対応 
 • サービス停止による機会損失をなくす 
 システムは変化するビジネス要件に合わせ短い時間で 高頻度にリリースすることが求められる • アプリの変更をすぐに本番環境に適用 
 • 変化を許容できるシステムを構築 
 • 停止時間の短縮と運用作業の効率化 
 高頻度かつ即時に本番反映 可能なアプリケーションが必要
62. Microservices マイクロサービスも結局 マイクロサービスには文化的側面と技術的側面があり、 
 その調和の最終的に目指すところは？ 
 速く、正確に高品質なサービスを提供して、 
 エンドユーザ様の満足度、企業収益、ビジネス価値の向上 
 これまで学んできたクラウドネイティブの意義と同じ！ 

63. Observability
64. Observability Monitoring = 監視、観察して記録する
 そもそも監視って？
65. Observability 何のために、監視、観察して記録する？
66. Observability • サービスやアプリケーションの健全性を確認 
 • 障害やトラブルの原因調査
 • キャパシティ分析
 • サービス利用者の行動分析
 技術、運用、ビジネスなど多岐にわたる 

67. Observability サービスやシステムを利用するユーザに影響を与えないため

68. Observability サービスやシステムの利用者が、問題なく利用できる、
 「安定稼働している状態」を維持する！
 

69. Observability • より良い方法で、システムの稼働状況を把握できている状態 
 • システム運用において、判断に必要となる情報を取得できている状態 
 • 迅速に障害やトラブルに対応できる状態 
 監視の意義
 これまでもこれからも、こうした本質は変わらない 

70. Observability オブザバビリティの背景
 これまでのシステム
 User Operator 従来のWeb3層モデルのようなシンプルな構成のシステムであれば、比較的容易に障害を調査すること が可能。
 LB/Web/App/D Bなどそれぞれの コンポーネントを 追いやすい
 Web
 Application
 Database
 LB

71. Observability 分散システム
 User 分散システムのような小さなサービスが疎結合するようなシステムでは、構成が複雑となり障害発生個 所や原因追求が困難であり、まして人の手で行うことは非現実的。 
 それぞれのコンポーネ ントを追うのは非現実 的 LB
 Operator
72. Observability 右図にあるような分散システムでは、大量のサービ スが連携して、一つのシステムとして成り立ってい るため、障害が発生した際の検知など、これまでの ように容易にはいかない…
 『Adoption of Cloud Native Architecture, Part 2: Stabilization Gaps and Anti-Patterns』 https://www.infoq.com/articles/cloud-native-architecture-adoption-part2/
73. Observability Observability might mean different things to different people. 可観測性は、人によって意味が異なる場合があります。 
 『 Distributed Systems Observability』 https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ オブザバビリティとは？ Observability（可観測性）は、人によってまたはシステムによって基準、観点、解釈の仕方が違うもの なので、本セッションの内容も一例と捉えてください。 

74. Observability クラウドネイティブにおけるオブザバビリティ クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、ス ケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービ スメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。
 
 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせるこ とで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 
 Cloud Native Computing Foundation(CNCF) Cloud Native Definition v1.0 | https://github.com/cncf/toc/blob/master/DEFINITION.md クラウドネイティブの文脈では、Observability（可観測性）は、 クラウドネイティブなシステムを実現するまたは支える一要素
75. Observability Kubernetes上のPod(コンテナ)を例に考えてみると、決められた Nodeに決められたPod(コンテナ)が稼 働するとは限らないため、これまでの監視方法とは違うアプローチが必要となる。 Kubernetes Operator Node状況、Kubernetes Cluster状況（Podなど）、ア プリケーション、データベース など色々ある
76. Observability • 人またはシステムによって基準・観点は異なる 
 • クラウドネイティブなシステムを実現するまたは支える一要素 
 • 従来のシステムとは異なるアプローチが必要（分散システム、コンテナなど） 
 オブザバビリティとは？
 この本質も不変！！
 • より良い方法で、システムの稼働状況を把握できている状態 
 • システム運用において、判断に必要となる情報を取得できている状態 
 • 迅速に障害やトラブルに対応できる状態 

77. Observability Telemetry Observabilityを実現する3要素 Telemetryの各要素が連携して、Observabilityを実現させることが重要 Telemetry システムの状態を収集後、付加情報を付与し て数値に変換したもの コンポーネント間を跨ぐイベントまたはトラン ザクションの因果連鎖の指標 正常・異常動作など、システムにより生成されるテキ ストデータ Logs Metrics Traces
78. Observability Observabilityを実現する主なツール Prometheus & Grafana Grafana Loki EFK Jaeger Zipkin Open Telemetry この他に、ベンダー製品や クラウドベンダーサービス もある Metrics Logs Traces
79. Observability The CNCF End User Technology Radar The CNCF End User Technology Radarは、CNCFエンドユーザーコミュニティに代わって、クラウド ネ イティブテクノロジーを評価するためのガイド。 1.最も一般的に採用されているツールはオープン ソース 2.可観測性の領域に統合はない 3.PrometheusとGrafanaはほぼ一緒に利用 最も「採用」票を獲得した 3つのツール（Prometheus、Grafana、Elastic）と 最も合計票を獲得した 5つのツール（Prometheus、Grafana、Elastic、 Jaeger、OpenTelemetry）はすべてオープンソース。 多くの企業が複数のツールを使用。企業の半数は 5つ以上のツールを使 用しており、3分の1は10以上のツールを使用した経験がある。 回答者の3分の2は、これら2つのツールを組み合わせて使用 。これは当 然だが、高い相関関係は注目に値する。 『The CNCF End User Technology Radar Observability, September 2020』 https://radar.cncf.io/2020-09-observability
80. Observability 速く、正確に高品質なサービスを提供して、 
 エンドユーザ様の満足度、企業収益、ビジネス価値の向上 
 オブザバビリティは、クラウドネイティブシステムを支える 
 提供だけではなく、常にユーザエクスペリエンスを損なうことが無いよう維持、 
 そして、障害やトラブルが発生した場合も速く、正確に対応できる体制も維持する！ 

81. What is Cloud Native ?
82. 人的関与を極力減らしてビジネス価値の向上を目指し、それをエン ドユーザ様に届けるマインドを持つ 速く、正確に高品質なサービスを提供し、エンドユーザ様の満足 度、企業収益、ビジネス価値の向上 提供だけでなく、常にユーザエクスペリエンスを損なうことが無いよ う維持、障害やトラブルが発生した場合も迅速に対応できる体制を 維持
83. Thank you !!