What is Cloud Native ?
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Share
Embed
Transcript
83 slides
-
What is Cloud Native ? Yutaka Ichikawa CloudNative Days Tokyo
2021 Cloud Native Definition DevOps CI/CD Microservices Observability -
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 -
Agenda • Cloud Native Definition ◦ Cloud Native Computing Foundation（CNCF）につい
て ◦ クラウドネイティブとは？ ◦ そもそもクラウドコンピューティングとは？ ◦ クラウドコンピューティングの特性 ◦ クラウドネイティブを実現する道しるべ ◦ 自動化の目的 ◦ 結局のところ、クラウドネイティブとは？ • DevOps ◦ DevOpsとは？ ◦ DevOpsを実現する方法 • CI/CD ◦ これまでのアプリケーション開発 ◦ OS/ライブラリとアプリケーションの分離 ◦ 仮想マシンとコンテナの違い ◦ OS/ライブラリとアプリケーションの統合 ◦ コンテナを支えるオーケストレーション ◦ コンテナアプリケーション開発における CI/CD • Microservices ◦ マイクロサービスの二つの側面 ◦ マイクロサービスの進化と挑戦 ◦ コンテナにおけるマイクロサービスを実現する技術 ◦ ビジネス面におけるマイクロサービス ◦ マイクロサービスの特徴 ◦ マイクロサービスも結局 • Observability ◦ そもそも監視って？ ◦ オブザバビリティの背景 ◦ オブザバビリティとは ? ◦ テレメトリー ◦ オブザバビリティは、クラウドネイティブシステムを支え る -
Cloud Native Definition Cloud Native Computing Foundation（CNCF）について • The Linux
Foundation傘下のプロジェクトの1つ • 2015年に創設された財団 • コンテナ技術の推進と、その進化を取り巻くテクノロジー業界の足並みを揃えることを目的 • 大手クラウド事業者、ミドルウェア企業、ハードウェア製造企業、オープンソース・ソフトウェア企 業、大学、その他非営利団体などが加入 -
Cloud Native Definition 年3回、Europe、China、North AmericaでCNCF主催「KubeCon + CloudNativeCon」を開催 KubeCon + CloudNativeCon
North America 2019 San Diego -
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 ”拡張性・柔軟性に優れたアプリケーションをクラウドの特性を活かして、 最小限の労力で構築および実行できるようにする” -
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つのデプロイメントモデル • プライベートクラウド • コミュニティクラウド • パブリッククラウド • ハイブリッドクラウド -
Cloud Native Definition クラウドコンピューティングの特性 オンプレミスでは困難なことが、クラウドコンピューティングは実現できる • オンデマンド・セルフサービス • 幅広いネットワークアクセス •
リソースの共有 • 迅速な拡張性 • 計測可能なサービス • 資産保有が不要 • 利便性が高い • リソース調達が早い • 柔軟な拡張性 • 利した分だけ課金 -
Cloud Native Definition クラウドネイティブの道しるべ CNCF Trail Map | https://github.com/cncf/trailmap 1.CONTAINERIZATION
| コンテナ化 仮想マシンとは異なり、環境差異が無く、軽量なイメージで可搬性が高く、リ リースサイクルを速め、機敏さと信頼性を兼ね備えたアプリケーションリリース を実現 2.CI/CD | 継続的インテグレーション/デリバリー ソースコードの変更を契機に、自動的なビルド、テスト、ステージング環境およ び本番環境へのデプロイにつながるCI/CD環境を構築する 3.ORCHETRATION & APPLICATION DEFINITION | オーケストレーションツールとアプリケーション定義 コンテナ化されたアプリケーションをKubernetes基盤で自律的に運用 Helmを利用して、マニフェストを効率的に管理 コンテナ化 開発自動化 運用自動化 ”拡張性・柔軟性に優れたアプリケーションを最小限の労力で構築および実行” -
Cloud Native Definition 結局のところクラウドネイティブとは？ 「CNCFに関連するプロダクト利用 = クラウドネイティブ」 ではない CNCF Cloud
Native Interactive Landscape | https://landscape.cncf.io/ -
Cloud Native Definition CloudNative Days Fukuoka 2019 『飛び込もうCloud Nativeの世界』 草間一人(@jacopen)
| https://speakerdeck.com/jacopen/fei-biip-mou-cloud-nativefalseshi-jie -
DevOps DevOpsを実現する方法 • 「計画、設計、実装、テスト」という開発工程を機能単位の小さいサイクルで繰り返して開発を行う 開発手法 • ウォーターフォールと異なり、仕様変更に強く、プロダクトの価値を最大化することを目的とする • サービスインまでの時間を短縮できる 1.アジャイル開発
企画 リリース リリース リリース 計画 実装 設計 テスト 計画 実装 設計 テスト 計画 実装 設計 テスト -
DevOps DevOpsを実現する方法 2.CI/CD（継続的インテグレーション/継続的デリバリー） • ソースコードからアプリケーションとしてビルドするタイミングでテストを行って、完成した成果物 （アーティファクト）を保存するまでの工程を自動化 • 早期にバグを発見、対処できることでアプリケーションの品質を高めることができる仕組み 継続的インテグレーション（CI:
Continuous Integration） • 継続的インテグレーションによって生成された成果物（アーティファクト）をステージング環境や本 番環境などの各環境に配置する仕組み • リリース作業を簡素化して、安全、スピード、品質の向上を実現するプロセス 継続的デリバリー（CD: Continuous Delivery） -
CI/CD これまでのアプリケーション開発 物理マシン 仮想マシン 仮想マシン（クラウド） コンテナ VM 物理サーバでアプリケーションを稼働
物理サーバ上に複数の仮想マシンでアプリケーションを稼働 クラウドをベースとしたスケーラブルな仮想マシンでアプリケーション を稼働 物理マシン・仮想マシンもノードとして束ねて、コンテナという小さい 単位でアプリケーションを稼働 -
CI/CD Developer Code Repository CI/CD Pipeline アプリケーション OS/ライブラリ 開発環境 検証環境
ステージング環境 本番環境 VM Operator Infrastructure Engineer コードをコードリポジトリにコミット /プッシュ CI/CDパイプラインによるテス ト、ビルド、デプロイ すべて自動化されている場合もあれば、手動で行う場合もあります。 物理マシン 仮想マシン 仮想マシン（ク ラウド） -
CI/CD アプリケーション OS/ライブラリ 開発環境 検証環境 ステージング環境 本番環境 VM OS/ライブラリとアプリケーションの分離 物理マシン
仮想マシン 仮想マシン（ク ラウド） アプリケーションは物理マシンや仮想マシンの OS/ライブラリ上で稼働 稼働するアプリケーションは 実行環境に依存する 環境差異が原因で他の環境で稼働するけど、 本番環境で稼働しない 等の障害が発生する OSのパッチバージョンが異なる、このライブラリ が無かった、関係ないものがインストールされて いる… -
CI/CD アプリケーション OS/ライブラリ 物理/仮想マシンにおける、OS/ライブラリのアップデートには 人手や時間を要するため、アプリケーションのリリースに影響 する… ハイパーバイザー VMWare Xen/Server KVM
ハードウェア VMWare Xen/Server KVM 仮想マシン イメージ • 仮想マシンイメージが ベンダー製品特有（ベン ダーロックイン） • 容量も重い（数ギガ～数十ギガ） • 可搬性が低い -
CI/CD これまでのアプリケーション開発 OS/ライブラリが既に整っている実行環境にアプリケーションをデプロイするという形式 1.アプリケーション • 環境差異による問題が発生 • OS/ライブラリ側に何かあるとアプリケーションに影響
2.インフラ • 仮想マシンイメージがベンダー製品特有（ベンダーロックイン） • 仮想マシンイメージの容量が重く可搬性が低い • 物理/仮想マシンの特性上、OS/ライブラリのアップデートに時間を要して、アプリケーションのリ リースに影響する -
CI/CD 仮想マシンとコンテナの違い ハードウェア ハードウェア ハイパーバイザー カーネル 仮想マシン 仮想マシン コンテナエンジン コンテナ
コンテナ カーネル カーネル ライブラリ ライブラリ アプリケーション アプリケーション ライブラリ アプリケーション ライブラリ アプリケーション 仮想マシン コンテナ 各仮想マシンのカーネル上で実行、 隔離性が高い が、起動が遅く（数分）オーバヘッドが大きい 。 カーネルを共有しているため、 隔離性は低いが、起 動が高速（数秒）でオーバヘッドが小さい 。 -
CI/CD OS/ライブラリとアプリケーションの統合 1.ビルド（Build） • OS/ライブラリとアプリケーションをパッケージイメージ化 • 技術としてはOSSのため、ベンダーロックインは発生しない • イメージはこれまでの仮想マシンイメージに比べると はるかに軽いので可搬性が高い
OS/ライブラリ アプリケーション OS/ライブラリ コンテナイメージ ビルド (Build) -
CI/CD 2.シップ（Ship） • イメージをレジストリに保存 • レジストリからコンテナプラットフォームへ共有 OS/ライブラリ コンテナイメージ プッシュ (Push)
OS/ライブラリ イメージレジストリ プル (Pull) OS/ライブラリ コンテナプラットフォーム OS/ライブラリ シップ(Ship) イメージ共有 -
CI/CD 3.ラン（Run） • コンテナイメージをベースにコンテナを起動 OS/ライブラリ コンテナプラットフォーム ラン（Run） コンテナイメージ コンテナ OS/ライブラリ
コンテナプラットフォーム上でイメージからコンテナを起動して、アプリケーションを稼働。 コンテナイメージもプラットフォームもベンダー技術に依存しないため、ベンダーロックインも無い。 -
CI/CD コンテナアプリケーション開発 OS/ライブラリとアプリケーションを統合して、軽量イメージ化して、コンテナプラットフォームにコンテナと してデプロイする形式 1.アプリケーション • OS/ライブラリとアプリケーションが一つに統合されているため、環境差異による問題が起きにくい 2.インフラ •
仮想マシンイメージと仕組みが異なり、OSSベースでベンダーロックインもなく、軽量で可搬性が高 い • OS/ライブラリのアップデートも容易なため、リリースサイクルを速め、スピード（Agility）が向上 -
CI/CD コンテナを支えるオーケストレーション Kubernetesは、Google社内のコンテナーオーケストレーションシステムである Borgからインスパイアさ れて開発されたOSSのコンテナーオーケストレーション。 読み方：クーバーネーティス、クーバネティス、クバネティス等 略称：K8s（Kubernetes） 8文字 現在は、CNCF(Cloud
Native Computing Foundation)で管理され、多数の企業が参加するコミュニ ティで開発。 -
主な役割 実現 CI/CD Kubernetesの主な役割と実現 • コンテナのスケジューリング • ローリングアップデート
• オートスケーリング • 死活監視 • コンテナの自動修復 • サービスディスカバリ • ロードバランシング • 頻繁なアプリケーションのデプロイ を可能にするシ ステム基盤 • 無停止によるリリース、高可用 なシステム基盤 • 負荷に応じた伸縮自在なシステム基盤 -
CI/CD YAML Kubernetesクラスタ 宣言的オペレーション マニフェストファイル Controller Reconciliation loop 登録 監視
コンテナ管理 （作成・削除） Controller内のReconciliation loop（調整ループ）と呼ばれる、 あるべき理想の状態へ収束させるループ処理を実行。 Controllerがあるべき理想の状態へ収束 -
CI/CD Kubernetesクラスタ あるべき理想の状態 Controller Reconciliation loop 宣言的オペレーション 指定された 「replicas: 3」
のPod数を維持すること Observe Analyze Act -
CI/CD Kubernetesクラスタ あるべき理想の状態 Controller Reconciliation loop 宣言的オペレーション （例）起動しているPodが2個の場合 Observe Analyze
Act Analyze 理想状態と比較して、Podが1個足りない -
CI/CD Kubernetesクラスタ あるべき理想の状態 Controller Reconciliation loop 宣言的オペレーション （例）起動しているPodが2個の場合 Observe Analyze
Act Act 「image: nginx:1.21.0」のPodを作成 -
CI/CD Kubernetes is becoming the Linux of the cloud by
Jim Zemlin （The Linux Foundation） -
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 -
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クラスタ外部での権限管理となるため、セキュリティリスクがある。 -
CI/CD 3.マニフェストの再現性 Developer Code Repository CI/CD Pipeline Image Registry Dev
Image Pull 1.パイプラインの実行順序が保証されるとは限ら ず、適用されたクラスタ状態が想定と異なること に。 Staging Prod 2.ロールバックするにも、マニフェストの更新履歴 を追うなど、迅速性に欠けてしまう。 -
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 -
CI/CD 5.GitOpsのメリット • マニフェストファイルをGit管理 ◦ デプロイ先に対して「誰が、何時、何」を変更したのかを履歴で追える ◦ デプロイ先をいつでも前の状態に戻すこと（ロールバック）ができる ◦ プルリクエストによるレビュー・マージプロセスを通すことで組織ガバナンスを適用できる
• 自動化 ◦ 手動コマンドによるヒューマンエラーの排除 ◦ 運用コストの軽減 -
Microservices マイクロサービスの進化と挑戦 チームが小さい場合 • 一つのアプリケーションに機能を集約して開発 • 速度と開発品質の面で合理的 チームが大きい場合
• コミュニケーションコストの増加 • 20人以上になるとチーム破綻へ 会議に限らず、開発チーム人数においても理想は “ Two Pizza Rule ” “会議の参加者が多いほど、生産性は低下する。これを解決するために、参加メンバーを2枚のピザを分け合える人数に抑える。” https://landing.directorpoint.com/blog/amazon-two-pizza-rule/ -
Microservices 技術においても組織の分散化に合わせて分散化を進める この開発手法がマイクロサービス • 小さいチームが自律的に機能することで、全体としてのプロダクト開発スピードを向上 • 各チームでデプロイサイクルが独立しているので、要件に沿って自由にリリース可能
• チームごとにパフォーマンス要件の異なるアプリケーションをスケーリング可能 • 機能増加と共にチームと人員もスケールすることで、アプリケーションと組織が同時に成長 -
マイクロサービスの9つの特徴 Microservices マイクロサービスにおけるガイドライン • サービスによるコンポーネント化 • ビジネス機能に基づいたチーム編成 • プロジェクトではなく製品として捉えて開発運用
• インテリジェントなエンドポイントシンプルなパイプ • 非中央集権的な言語やツールの選択 • 非中央集権的なデータ管理 • ITインフラの自動化（Infrastructure as Code） • 障害、エラーを前提とした設計 • 先進的な設計 James Lewis/Martin Fowlerの"Microservices" | https://martinfowler.com/articles/microservices.html -
Microservices コンテナにおけるマイクロサービスを実現する技術 Service Mesh App Proxy Pod Container Container アプリケーションとプロキシ機能の分離
アプリケーションプロセスごとに専用のプロキシを配置して、 そのプロキシにネットワーク周りの仕事をまかせます。 プロキシ機能の中央管理 Control Plane App Proxy App Proxy App Proxy App Proxy プロキシ機能は大量になるのでコンフィグレーションの管理 コストが増加。中央にプロキシ機能の管理するコントロール プレーンを配置して効率的に管理。 -
Microservices マイクロサービスの特徴 マイクロサービス・アーキテクチャ 大規模なシステムを疎結合な複数のサービスの組み合わせで実現する設計方式 • アップデートの容易性 • スケールの容易性
• 高可用性 サービスA サービスB サービスC サービスF サービスE サービスD サービスA サービスB サービスC サービスF サービスE サービスD システムA システムB -
Microservices アップデートの容易性 • 他のサービスへの影響を極小化した形で、アップデート対象のサー ビスのみをアップデート可能 • 高頻度にサービスのアップデートが可能
スケールの容易性 • 他のサービスに影響を与えることなく、必要なサービスのみをス ケールアウト可能 • 使用するリソースを最適化 高可用性 • サービスが独立しているため、障害の影響を極小化 • 残ったサービス群でサービス提供を継続していくことが可能 アップデート スケール 障害 障害影響なし -
Microservices ビジネス面におけるマイクロサービス 顧客向け 新ビジネス 創造 社内業務 効率化 社外 社内 ビジネス
創造 業務効 率化 ビジネスには進化のスピードと品質が求められる • サービスの早期リリース • 市場の動向/反応を早期フィードバックして対応 • サービス停止による機会損失をなくす システムは変化するビジネス要件に合わせ短い時間で 高頻度にリリースすることが求められる • アプリの変更をすぐに本番環境に適用 • 変化を許容できるシステムを構築 • 停止時間の短縮と運用作業の効率化 高頻度かつ即時に本番反映 可能なアプリケーションが必要 -
Observability • より良い方法で、システムの稼働状況を把握できている状態 • システム運用において、判断に必要となる情報を取得できている状態 • 迅速に障害やトラブルに対応できる状態
監視の意義 これまでもこれからも、こうした本質は変わらない -
Observability オブザバビリティの背景 これまでのシステム User Operator 従来のWeb3層モデルのようなシンプルな構成のシステムであれば、比較的容易に障害を調査すること が可能。 LB/Web/App/D Bなどそれぞれの コンポーネントを
追いやすい Web Application Database LB -
Observability 右図にあるような分散システムでは、大量のサービ スが連携して、一つのシステムとして成り立ってい るため、障害が発生した際の検知など、これまでの ように容易にはいかない… 『Adoption of Cloud Native Architecture,
Part 2: Stabilization Gaps and Anti-Patterns』 https://www.infoq.com/articles/cloud-native-architecture-adoption-part2/ -
Observability Observability might mean different things to different people. 可観測性は、人によって意味が異なる場合があります。
『 Distributed Systems Observability』 https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ オブザバビリティとは？ Observability（可観測性）は、人によってまたはシステムによって基準、観点、解釈の仕方が違うもの なので、本セッションの内容も一例と捉えてください。 -
Observability クラウドネイティブにおけるオブザバビリティ クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、ス ケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービ スメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせるこ とで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。
Cloud Native Computing Foundation(CNCF) Cloud Native Definition v1.0 | https://github.com/cncf/toc/blob/master/DEFINITION.md クラウドネイティブの文脈では、Observability（可観測性）は、 クラウドネイティブなシステムを実現するまたは支える一要素 -
Observability • 人またはシステムによって基準・観点は異なる • クラウドネイティブなシステムを実現するまたは支える一要素 • 従来のシステムとは異なるアプローチが必要（分散システム、コンテナなど）
オブザバビリティとは？ この本質も不変！！ • より良い方法で、システムの稼働状況を把握できている状態 • システム運用において、判断に必要となる情報を取得できている状態 • 迅速に障害やトラブルに対応できる状態 -
Observability Observabilityを実現する主なツール Prometheus & Grafana Grafana Loki EFK Jaeger Zipkin
Open Telemetry この他に、ベンダー製品や クラウドベンダーサービス もある Metrics Logs Traces -
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
cyberblack28
inariku
muziyoshiz
yappli_developers
kobayashiyorimitsu
smt7174
ykimi
nagix
comi190327
demaecan
sergicalsix
takuyay0ne
akashhashmi
sachag
yeseniaperezcruz
szymonslowik
sergeychernyshev
tapps
eileencodes
samtorres
rkendrick25
aemeredith
jcasabona
chikuwait
