What is Cloud Native ?

What is
Cloud Native ?
Yutaka Ichikawa
CloudNative Days Tokyo 2021
Cloud Native Deﬁnition DevOps CI/CD Microservices Observability

View Slide

Publications
Certiﬁcation & Community
CKA CKAD 2018 2019
Proﬁle
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

View Slide

Agenda
● Cloud Native Deﬁnition
○ Cloud Native Computing Foundation（CNCF）につい
て
○ クラウドネイティブとは？
○ そもそもクラウドコンピューティングとは？
○ クラウドコンピューティングの特性
○ クラウドネイティブを実現する道しるべ
○ 自動化の目的
○ 結局のところ、クラウドネイティブとは？
● DevOps
○ DevOpsとは？
○ DevOpsを実現する方法
● CI/CD
○ これまでのアプリケーション開発
○ OS/ライブラリとアプリケーションの分離
○ 仮想マシンとコンテナの違い
○ OS/ライブラリとアプリケーションの統合
○ コンテナを支えるオーケストレーション
○ コンテナアプリケーション開発における CI/CD
● Microservices
○ マイクロサービスの二つの側面
○ マイクロサービスの進化と挑戦
○ コンテナにおけるマイクロサービスを実現する技術
○ ビジネス面におけるマイクロサービス
○ マイクロサービスの特徴
○ マイクロサービスも結局
● Observability
○ そもそも監視って？
○ オブザバビリティの背景
○ オブザバビリティとは ?
○ テレメトリー
○ オブザバビリティは、クラウドネイティブシステムを支え
る

View Slide

Cloud Native Deﬁnition

View Slide

Cloud Native Computing Foundation（CNCF）について
● The Linux Foundation傘下のプロジェクトの1つ
● 2015年に創設された財団
● コンテナ技術の推進と、その進化を取り巻くテクノロジー業界の足並みを揃えることを目的
● 大手クラウド事業者、ミドルウェア企業、ハードウェア製造企業、オープンソース・ソフトウェア企
業、大学、その他非営利団体などが加入

View Slide

年3回、Europe、China、North AmericaでCNCF主催「KubeCon + CloudNativeCon」を開催
KubeCon + CloudNativeCon
North America 2019
San Diego

View Slide

クラウドネイティブとは？
Cloud Native Computing Foundation（CNCF）におけるクラウドネイティブの定義
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、ス
ケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプローチの代表例に、コンテナ、サービ
スメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。 
 
これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。これらを堅牢な自動化と組み合わせるこ
とで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。  
 
Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダイムの
採用を促進したいと考えてます。私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。 
Cloud Native Computing Foundation(CNCF) Cloud Native Deﬁnition v1.0 | https://github.com/cncf/toc/blob/master/DEFINITION.md
”拡張性・柔軟性に優れたアプリケーションをクラウドの特性を活かして、
最小限の労力で構築および実行できるようにする”

View Slide

そもそもクラウドコンピューティングとは？
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つのデプロイメントモデル 
● プライベートクラウド 
● コミュニティクラウド 
● パブリッククラウド 
● ハイブリッドクラウド 

View Slide

クラウドコンピューティングの特性
オンプレミスでは困難なことが、クラウドコンピューティングは実現できる
● オンデマンド・セルフサービス
● 幅広いネットワークアクセス
● リソースの共有
● 迅速な拡張性
● 計測可能なサービス
● 資産保有が不要
● 利便性が高い
● リソース調達が早い
● 柔軟な拡張性
● 利した分だけ課金

View Slide

クラウドネイティブの道しるべ
CNCF Trail Map | https://github.com/cncf/trailmap
1.CONTAINERIZATION | コンテナ化 
仮想マシンとは異なり、環境差異が無く、軽量なイメージで可搬性が高く、リ
リースサイクルを速め、機敏さと信頼性を兼ね備えたアプリケーションリリース
を実現 
2.CI/CD | 継続的インテグレーション/デリバリー 
ソースコードの変更を契機に、自動的なビルド、テスト、ステージング環境およ
び本番環境へのデプロイにつながるCI/CD環境を構築する 
3.ORCHETRATION & APPLICATION DEFINITION |
オーケストレーションツールとアプリケーション定義
コンテナ化されたアプリケーションをKubernetes基盤で自律的に運用 
Helmを利用して、マニフェストを効率的に管理 
コンテナ化 
開発自動化 
運用自動化 
”拡張性・柔軟性に優れたアプリケーションを最小限の労力で構築および実行”

View Slide

自動化の目的
人的関与を極力減らして向上化 
技術に任せられるものは任せて効率化、 
そして、人にしかできないことに時間やコストを傾ける 
向上したビジネス価値をエンドユーザ様に提供する 

View Slide

結局のところクラウドネイティブとは？
「CNCFに関連するプロダクト利用 = クラウドネイティブ」 
ではない 
CNCF Cloud Native Interactive Landscape | https://landscape.cncf.io/

View Slide

人的関与を極力減らしてビジネス価値の向上を目指して、 
それをエンドユーザ様に届けるマインドを持つこと 

View Slide

CloudNative Days Fukuoka 2019
『飛び込もうCloud Nativeの世界』草間一人(@jacopen) | https://speakerdeck.com/jacopen/fei-biip-mou-cloud-nativefalseshi-jie

View Slide

DevOps

View Slide

DevOps
DevOpsとは？
開発（Development）と運用（Operations）が互いに協力し合うことで、
開発・運用するソフトウェア・システムによってビジネス価値を高めるだけでなく、
そのビジネス価値をより確実かつ迅速にエンドユーザに届け続ける概念
Dev Ops

View Slide

DevOps
DevOpsを実現する方法
● 「計画、設計、実装、テスト」という開発工程を機能単位の小さいサイクルで繰り返して開発を行う
開発手法
● ウォーターフォールと異なり、仕様変更に強く、プロダクトの価値を最大化することを目的とする
● サービスインまでの時間を短縮できる
1.アジャイル開発
企画  リリース  リリース  リリース 
計画 
実装 
設計 
テスト 
計画 
実装 
設計 
テスト 
計画 
実装 
設計 
テスト 

View Slide

DevOps
DevOpsを実現する方法
2.CI/CD（継続的インテグレーション/継続的デリバリー）
 
● ソースコードからアプリケーションとしてビルドするタイミングでテストを行って、完成した成果物
（アーティファクト）を保存するまでの工程を自動化
● 早期にバグを発見、対処できることでアプリケーションの品質を高めることができる仕組み
継続的インテグレーション（CI: Continuous Integration）
● 継続的インテグレーションによって生成された成果物（アーティファクト）をステージング環境や本
番環境などの各環境に配置する仕組み
● リリース作業を簡素化して、安全、スピード、品質の向上を実現するプロセス
継続的デリバリー（CD: Continuous Delivery）

View Slide

CI/CD

View Slide

CI/CD
これまでのアプリケーション開発
物理マシン 
仮想マシン 
仮想マシン（クラウド）  
コンテナ 
VM
物理サーバでアプリケーションを稼働
 
物理サーバ上に複数の仮想マシンでアプリケーションを稼働
 
クラウドをベースとしたスケーラブルな仮想マシンでアプリケーション
を稼働 
物理マシン・仮想マシンもノードとして束ねて、コンテナという小さい
単位でアプリケーションを稼働
 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

CI/CD
OS/ライブラリとアプリケーションの統合
1.ビルド（Build）
● OS/ライブラリとアプリケーションをパッケージイメージ化
● 技術としてはOSSのため、ベンダーロックインは発生しない
● イメージはこれまでの仮想マシンイメージに比べると
はるかに軽いので可搬性が高い
OS/ライブラリ 
コンテナイメージ 
ビルド
(Build)

View Slide

CI/CD
2.シップ（Ship）
● イメージをレジストリに保存
● レジストリからコンテナプラットフォームへ共有
コンテナイメージ 
プッシュ
(Push)
イメージレジストリ 
プル
(Pull)
コンテナプラットフォーム
OS/ライブラリ  シップ(Ship)
イメージ共有

View Slide

CI/CD
3.ラン（Run）
● コンテナイメージをベースにコンテナを起動
ラン（Run）
コンテナイメージ  コンテナ 
コンテナプラットフォーム上でイメージからコンテナを起動して、アプリケーションを稼働。
コンテナイメージもプラットフォームもベンダー技術に依存しないため、ベンダーロックインも無い。

View Slide

CI/CD
コンテナアプリケーション開発 
OS/ライブラリとアプリケーションを統合して、軽量イメージ化して、コンテナプラットフォームにコンテナと
してデプロイする形式
1.アプリケーション
● OS/ライブラリとアプリケーションが一つに統合されているため、環境差異による問題が起きにくい
 
2.インフラ
● 仮想マシンイメージと仕組みが異なり、OSSベースでベンダーロックインもなく、軽量で可搬性が高
い 
● OS/ライブラリのアップデートも容易なため、リリースサイクルを速め、スピード（Agility）が向上
 

View Slide

CI/CD
コンテナを支えるオーケストレーション
 
Kubernetesは、Google社内のコンテナーオーケストレーションシステムである
Borgからインスパイアさ
れて開発されたOSSのコンテナーオーケストレーション。
読み方：クーバーネーティス、クーバネティス、クバネティス等
略称：K8s（Kubernetes）
8文字
現在は、CNCF(Cloud Native Computing Foundation)で管理され、多数の企業が参加するコミュニ
ティで開発。

View Slide

主な役割  実現 
CI/CD
Kubernetesの主な役割と実現
● コンテナのスケジューリング  
● ローリングアップデート  
● オートスケーリング  
● 死活監視 
● コンテナの自動修復  
● サービスディスカバリ  
● ロードバランシング  
● 頻繁なアプリケーションのデプロイを可能にするシ
ステム基盤 
● 無停止によるリリース、高可用なシステム基盤  
● 負荷に応じた伸縮自在なシステム基盤  

View Slide

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

View Slide

CI/CD
Reconciliation loop
Observe
現在の状態を確認 
Analyze
あるべき理想の状態と現在の状態
 
との差分を分析 
Act
分析した差分に対する処理を実行
 

View Slide

CI/CD
あるべき理想の状態
Controller
Reconciliation loop
指定された「replicas: 3」のPod数を維持すること
Observe
Analyze
Act

View Slide

CI/CD
Controller
Reconciliation loop
（例）起動しているPodが2個の場合
Observe
Analyze
Act
Observe 理想:3 現状:2

View Slide

CI/CD
Controller
Reconciliation loop
Observe
Analyze
Act
Analyze 理想状態と比較して、Podが1個足りない

View Slide

CI/CD
Controller
Reconciliation loop
Observe
Analyze
Act
Act 「image: nginx:1.21.0」のPodを作成

View Slide

CI/CD
Kubernetesは分散処理基盤 
Virtual Machine
BareMetal
Kubernetes
Container

View Slide

CI/CD
Kubernetes is becoming the Linux of the cloud
by Jim Zemlin （The Linux Foundation）

View Slide

CI/CD
Multi-Cloud to Multi-Kubernetes Cloud Native to Kubernetes Native

View Slide

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/ライブラリ  
イメージ共
有
コードをコードリポジトリにコミット/プッシュ
 
Code,Dockerﬁle,manifest
Image
Registry
CI
CD

View Slide

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クラスタ外部での権限管理となるため、セキュリティリスクがある。

View Slide

CI/CD
3.マニフェストの再現性
Developer
Code
Repository
CI/CD
Pipeline
Image
Registry
Dev
Image Pull
1.パイプラインの実行順序が保証されるとは限ら
ず、適用されたクラスタ状態が想定と異なること
に。 
Staging Prod
2.ロールバックするにも、マニフェストの更新履歴
を追うなど、迅速性に欠けてしまう。  

View Slide

CI/CD
4.GitOps Pull型
Kubernetesクラスタ内に配置されたGitOpsオペレーターがConfigリポジトリを定期的にポーリングし
て、更新を検知して更新内容をKubernetesクラスタに反映する仕組み。
物理マシン  仮想マシン 
仮想マシン（ク
ラウド） 
VM
OS/ライブラリ  OS/ライブラリ 
Operator
Infrastructure
Engineer
Developer
Config
Repository
CI
Pipeline
Build Ship
Run
へのデプロイ
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

View Slide

CI/CD
5.GitOpsのメリット
● マニフェストファイルをGit管理
○ デプロイ先に対して「誰が、何時、何」を変更したのかを履歴で追える
○ デプロイ先をいつでも前の状態に戻すこと（ロールバック）ができる
○ プルリクエストによるレビュー・マージプロセスを通すことで組織ガバナンスを適用できる
● 自動化
○ 手動コマンドによるヒューマンエラーの排除
○ 運用コストの軽減

View Slide

CI/CD
6.コンテナアプリケーション開発における
CI/CDが目指すところ
コンテナの可搬性（Portability）とスピード（Agility）を持ち合わせ、
品質および生産性の高いアプリケーション開発を実現
これまで時間やコストを要していた箇所の改善、 
より良いビジネスロジックに時間やコストを傾ける 
リリースサイクルを速め、 
エンドユーザ様に最高品質のサービスを提供 
エンドユーザ様の満足度、企業収益、ビジネス価値の向上につながる
 

View Slide

CI/CD
クラウドネイティブにおけるコンテナアプリケーション開発は、銀の弾丸ではない
実際に開発するアプリケーションの特性、組織体制、チーム体制、コスト、教育など
基盤・開発・運用の観点からしっかりと見据えて適材適所に検討する必要がある

View Slide

Microservices

View Slide

Microservices
マイクロサービスの二つの側面
マイクロサービスには、「開発組織・文化の側面」と「技術の側面」の二側面がある。
1.開発組織・文化の側面
開発組織の成長に伴うチーム、人員が増加しても、小規模なチーム開発と同様の素早いプロダクト開
発を維持する。
2.技術の側面
マイクロサービスは、個々に開発された複数の小さなサービスを連結させて、設計と運用を実現するソ
フトウェアのアーキテクチャ。

View Slide

Microservices
マイクロサービスの進化と挑戦
チームが小さい場合 
● 一つのアプリケーションに機能を集約して開発
 
● 速度と開発品質の面で合理的
 
チームが大きい場合 
● コミュニケーションコストの増加
 
● 20人以上になるとチーム破綻へ
 
会議に限らず、開発チーム人数においても理想は “ Two Pizza Rule ”
“会議の参加者が多いほど、生産性は低下する。これを解決するために、参加メンバーを2枚のピザを分け合える人数に抑える。”  
https://landing.directorpoint.com/blog/amazon-two-pizza-rule/

View Slide

Microservices
マイクロサービスの前段として組織の細分化
100人を一つにして開発するよりも、主要な機能を10個に分けて機能ごとに10人のチームを10個作って
開発した方が効率的。 
100人で開発  10人のチームを10チーム作って開発 

View Slide

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

View Slide

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

View Slide

マイクロサービスの9つの特徴
Microservices
マイクロサービスにおけるガイドライン
 
● サービスによるコンポーネント化 
● ビジネス機能に基づいたチーム編成 
● プロジェクトではなく製品として捉えて開発運用 
● インテリジェントなエンドポイントシンプルなパイプ 
● 非中央集権的な言語やツールの選択 
● 非中央集権的なデータ管理 
● ITインフラの自動化（Infrastructure as Code） 
● 障害、エラーを前提とした設計 
● 先進的な設計 
James Lewis/Martin Fowlerの"Microservices" | https://martinfowler.com/articles/microservices.html

View Slide

Microservices
2018年にメルカリがマイクロサービスアーキテクチャを採用して、組織、サービス、そして企業としても
拡大を目指し、継続中。
https://www.itmedia.co.jp/enterprise/articles/1810/11/news049.html

View Slide

Microservices
モノリスからマイクロサービス
モノリスマイクロサービス

View Slide

Microservices
そして、モダナイズ
クラウドネイティブ技術を利用したマイクロサービス
Virtual Machine / BareMetal
Kubernetes

View Slide

Microservices
コンテナにおけるマイクロサービスを実現する技術
Service Mesh
App Proxy
Pod
Container Container
アプリケーションとプロキシ機能の分離  
アプリケーションプロセスごとに専用のプロキシを配置して、
そのプロキシにネットワーク周りの仕事をまかせます。
 
プロキシ機能の中央管理  
Control
Plane
App Proxy App Proxy
App Proxy App Proxy
プロキシ機能は大量になるのでコンフィグレーションの管理
コストが増加。中央にプロキシ機能の管理するコントロール
プレーンを配置して効率的に管理。
 

View Slide

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

View Slide

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

View Slide

Microservices
ビジネス面におけるマイクロサービス
顧客向け
新ビジネス
創造
社内業務
効率化
社外
社内
ビジネス
創造
業務効
率化
ビジネスには進化のスピードと品質が求められる
● サービスの早期リリース  
● 市場の動向/反応を早期フィードバックして対応  
● サービス停止による機会損失をなくす  
システムは変化するビジネス要件に合わせ短い時間で
高頻度にリリースすることが求められる
● アプリの変更をすぐに本番環境に適用  
● 変化を許容できるシステムを構築  
● 停止時間の短縮と運用作業の効率化  
高頻度かつ即時に本番反映
可能なアプリケーションが必要

View Slide

Microservices
マイクロサービスも結局
マイクロサービスには文化的側面と技術的側面があり、
 
その調和の最終的に目指すところは？
 
速く、正確に高品質なサービスを提供して、
 
エンドユーザ様の満足度、企業収益、ビジネス価値の向上
 
これまで学んできたクラウドネイティブの意義と同じ！
 

View Slide

Observability

View Slide

Observability
Monitoring = 監視、観察して記録する 
そもそも監視って？

View Slide

Observability
何のために、監視、観察して記録する？

View Slide

Observability
● サービスやアプリケーションの健全性を確認
 
● 障害やトラブルの原因調査 
● キャパシティ分析 
● サービス利用者の行動分析 
技術、運用、ビジネスなど多岐にわたる
 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Observability
分散システム 
User
分散システムのような小さなサービスが疎結合するようなシステムでは、構成が複雑となり障害発生個
所や原因追求が困難であり、まして人の手で行うことは非現実的。
 
それぞれのコンポーネ
ントを追うのは非現実
的
LB 
Operator

View Slide

Observability
右図にあるような分散システムでは、大量のサービ
スが連携して、一つのシステムとして成り立ってい
るため、障害が発生した際の検知など、これまでの
ように容易にはいかない… 
『Adoption of Cloud Native Architecture, Part 2: Stabilization Gaps and Anti-Patterns』
https://www.infoq.com/articles/cloud-native-architecture-adoption-part2/

View Slide

Observability
Observability might mean diﬀerent things to diﬀerent people.
可観測性は、人によって意味が異なる場合があります。
 
『 Distributed Systems Observability』
https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/
オブザバビリティとは？
Observability（可観測性）は、人によってまたはシステムによって基準、観点、解釈の仕方が違うもの
なので、本セッションの内容も一例と捉えてください。
 

View Slide

Observability
クラウドネイティブにおけるオブザバビリティ
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、ス
ケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプローチの代表例に、コンテナ、サービ
スメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。 
 
これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。これらを堅牢な自動化と組み合わせるこ
とで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。  
Cloud Native Computing Foundation(CNCF) Cloud Native Deﬁnition v1.0 | https://github.com/cncf/toc/blob/master/DEFINITION.md
クラウドネイティブの文脈では、Observability（可観測性）は、
クラウドネイティブなシステムを実現するまたは支える一要素

View Slide

Observability
Kubernetes上のPod(コンテナ)を例に考えてみると、決められた
Nodeに決められたPod(コンテナ)が稼
働するとは限らないため、これまでの監視方法とは違うアプローチが必要となる。
Kubernetes
Operator
Node状況、Kubernetes
Cluster状況（Podなど）、ア
プリケーション、データベース
など色々ある

View Slide

Observability
● 人またはシステムによって基準・観点は異なる
 
● クラウドネイティブなシステムを実現するまたは支える一要素
 
● 従来のシステムとは異なるアプローチが必要（分散システム、コンテナなど）
 
オブザバビリティとは？ 
この本質も不変！！ 
● より良い方法で、システムの稼働状況を把握できている状態
 
● システム運用において、判断に必要となる情報を取得できている状態
 
● 迅速に障害やトラブルに対応できる状態
 

View Slide

Observability
Telemetry
Observabilityを実現する3要素
Telemetryの各要素が連携して、Observabilityを実現させることが重要
Telemetry
システムの状態を収集後、付加情報を付与し
て数値に変換したもの
コンポーネント間を跨ぐイベントまたはトラン
ザクションの因果連鎖の指標
正常・異常動作など、システムにより生成されるテキ
ストデータ
Logs
Metrics Traces

View Slide

Observability
Observabilityを実現する主なツール
Prometheus & Grafana
Grafana Loki EFK
Jaeger Zipkin Open Telemetry
この他に、ベンダー製品や
クラウドベンダーサービス
もある
Metrics
Logs
Traces

View Slide

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

View Slide

Observability
速く、正確に高品質なサービスを提供して、
 
エンドユーザ様の満足度、企業収益、ビジネス価値の向上
 
オブザバビリティは、クラウドネイティブシステムを支える
 
提供だけではなく、常にユーザエクスペリエンスを損なうことが無いよう維持、
 
そして、障害やトラブルが発生した場合も速く、正確に対応できる体制も維持する！
 

View Slide

What is Cloud Native ?

View Slide

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

View Slide

Thank you !!

View Slide

What is Cloud Native ?

What is Cloud Native ?

cyberblack28

More Decks by cyberblack28

Other Decks in Technology

Featured

Transcript