Elastic and Google: マルチクラウド / ハイブリッドクラウドを実現する Anthos と SRE

1
Elastic and Google:
マルチクラウド / ハイブリッドクラウドを実現する Anthos と SRE
Shinya Yanagihara
Application Modernization Specialist
Google Cloud

2
About me
柳原伸弥
担当領域
● Anthos
● アプリケーション改善
○ コンテナ / K8s
○ サーバーレス
○ Java モダナイゼーション
○ レガシーモダナイゼーション

33
私たちはパートナーをサポートし、
Googleのテクノロジーを用いることで
成功をパートナーと共有していく。
新しい形の OSS コミュニティを育て、
その発展をより確実なものとし、
成長するための受け皿を作っていく
Thomas Kurian,
CEO, Google Cloud

4
Elastic and Google
フリートライアル
elastic.co/google-cloud
Google Cloud 上からの Elastic 利用
(GCP コンソール統合)
Google Cloud 上からの Elastic 利用
(マーケットプレイス統合 )

5
Elastic ソリューションズ
オブザーバリティセキュリティサーチ
Kibana
Elasticsearch
Beats Logstash

6
Elastic オブザーバリティ
オブザーバリティセキュリティサーチ
ログ、メトリクス、トレースを
単一スタックにまとめて提供

7
Elastic Stack とGoogle Cloudを用いたオブザーバビリティ
Serverless
Cloud
Functions
Cloud
Logging
Cloud
Pub/Sub
Logstash
App
Engine
Compute
Engine
Kubernetes
Engine
Cloud
Run
Filebeat
Cloud
Storage
Filebeat
Functionbeat
Filebeat
Functionbeat

8
Elastic オブザーバビリティの特徴
統合された機械学習
統合されたアラート
単一の価格モデル
1つのツールのみを学習・セキュリティ対策・維持…
統合されたダッシュボード
統合されたスキーマ
APM
アップ
タイム
メトリックログビジネス Google
Cloud
AWS
Azure
マルチクラウド

9
マルチクラウド / ハイブリッドクラウドの重要性
Google
Cloud
AWS
Azure
メリット
● 冗長構成による可用性向上
○ BCP 対策
○ DR 対策
● 特定のベンダーに対する依存度の低減
○ ロックイン回避
● 複数環境の並行稼働による自社独自の
サービス提供が可能
マルチクラウド / ハイブリッドクラウドの
検討が増加

10
マルチクラウド / ハイブリッドクラウドの重要性
Google
Cloud
AWS
Azure
デメリット
● 個別最適化
● ツールの乱立
● オペレーションのサイロ化
マルチクラウドを促進するツールが求められている
● オペレーションの観点
● 開発・実行環境の観点

12
Anthos
クラスタ管理
サービス管理
サーバーレス &
App Dev
ポリシー管理運用管理
Google Cloud 他社クラウドエッジオンプレミス
アプリケーションの
モダナイゼーションプラットフォーム
Anthos の導入によりGoogle Cloud に加え
オンプレミスおよび他社クラウドで
以下のモダンアプリケーションに有用な
機能を提供
● Kubernetes
(Google Kubernetes Engine)
● サービスメッシュ
(Anthos Service Mesh)
● GitOpsワークフロー
(Anthos Config Management)
● サーバーレス
(Cloud Run for Anthos)
　など

13
Anthos とオブザーバビリティ
クラスタ管理
サービス管理
App Dev
Anthos が管理している対象サービスの
健全性と性能のオブザーバビリティを提供

14
マルチクラウド / ハイブリッドクラウドの活用
オペレーションの観点
開発・実行環境の観点
準備万端でしょうか？テクノロジー

15
マルチクラウド / ハイブリッドクラウドの活用
テクノロジー
人
プロセス
What [ テクノロジー ] だけではなく、
● Who [人]
● How [プロセス]
を考慮していく事が重要

16
Site Reliability Engineering (SRE)
テクノロジー
人
プロセス
SRE
Google が実践している
「ソフトウェア開発者による運用」

17
SRE と DevOps
<<interface>>
DevOps
SRE
class SRE implements DevOps {
….
}
● DevOpsは理論
● SREは実践

18
SRE と DevOps
<<interface>>
DevOps
SRE
エラーの発生を
前提とする
組織のサイロを削
減する
段階的に
変更する
ツールと自動化を
活用する
全てを
計測する
ポストモーテム
SLOs /
Error Budgets
CI / CD /
Canary
トイルの自動化
トイルの測定 /
信頼性
人 / 文化
心理的安全性
非難しない
コラボレーション
プロトタイプ
MVP
デザイン思考
変化の心理
適切な
ゴール設定
データドリブン意
思決定

19
SRE によるシステムオペレーション
SRE ≠ System Admin
SRE = Software Engineer
オペレーション (運用) を
ソフトウェアエンジニアリングの問題と同様
に扱い信頼性の向上を実践する
● 作業効率を重視する
○ ツールの活用
○ 自動化の導入
● システム運用に最適かつ高信頼性の
アーキテクチャを検討・導入
○ 開発初期から実践

20
システムの信頼性
信頼性 ≠ 可用性

21
システムの信頼性
信頼性
● 可用性
● 保守作業時間
● 保守作業頻度
● セキュリティ
対策
　など

22
「信頼性」の共通認識
イノベーション安定性
● サービスの安定性
● イノベーションのスピード
バランスが重要
「システムの信頼性」のゴールのために
「信頼性」の定義が必要
SLO (Service Level Objective : サービスレベル目標 )
SLO を満たしている = 信頼性ある状態
SLI
　　　　(Service Level Indicator : サービスレベル指標 )
　　　　　サービスレベル計測のための指標
システムの運用・開発など関わる人全ての合意が必要
信頼性の共通認識としての SLO

23
Service Level Objective ( SLO )
SLO
サービスレベル目標
● ユーザーがサービスを利用する上で
重要な観点を考慮した数値目標
○ ユーザーがサービスを正常に
利用できている範囲
● 観点や目標値はユーザー目線を重要視
● メトリクスは分布として扱い、
平均値ではなくパーセンタイルを推奨
ユーザーに対する理解を深めて
継続的に目標値を見直し
より良いSLOを模索することが大切

24
SLO に対するサービスダウン時間
可用性
(%)
障害時間
年間四半期 30日間
90% 36.5 days 9 days 3 days
95% 18.25 days 4.5 days 1.5 days
99% 3.65 days 21.6 hours 7.2 hours
99.5% 1.83 days 10.8 hours 3.6 hours
99.9% 8.76 hours 2.16 hours 43.2 minutes
99.99% 52.6 minutes 12.96 minutes 4.32 minutes
99.999% 5.26 minutes 1.30 minutes 25.9 seconds

25
SLO < 100% の考え方
可用性
(%)
許容される障害時間
年間四半期 30日間
90% 36.5 days 9 days 3 days
95% 18.25 days 4.5 days 1.5 days
99% 3.65 days 21.6 hours 7.2 hours
99.5% 1.83 days 10.8 hours 3.6 hours
99.99% 52.6 minutes 12.96 minutes 4.32 minutes
99.999% 5.26 minutes 1.30 minutes 25.9 seconds
従来のサービスレベルの考え方
● サービスダウンタイムの発生時間
● 可用性 100 % を満たせていない
SLO の考え方
● エラーは発生しうるもの
○ 100 % は困難
● サービス改善やセキュリティ対策による停
止時間が発生しうる
○ 100 % 可用性目標による柔軟性の
欠如が発生
● ダウンタイム許容時間
● サービス改善時間
エラーバジェット

26
Service Level Indicator ( SLI )
SLI
サービスレベル指標
● サービスの品質を決める計測可能な指標
● ユーザー視点での指標の利用を推奨
● 良いイベント数 / 全体のイベント数の
形式で定義することを推奨
SLI の種類計測内容
可用性応答に成功したリクエスト比率
レイテンシしきい値より高速なリクエスト比率
品質過負荷時の正常レスポンス比率
新鮮さしきい値より直近に更新されたデータ比率
正確性正常結果を出力した入力値の比率
SLI 例

27
Error
Budget
エラーバジェット (エラーに対する予算)
● ユーザーが不満を感じ始めるまでの一定期間に
サービスで累積できるエラーの量
○ ユーザーの忍耐度
○ 許容可能な信頼性低下の妥協点
● 100 % - SLO = エラーバジェット
エラーバジェット　　イノベーションの時間
改善や予防など攻めのオペレーション

28
100%
99.9%
100% - “SLO” = エラーバジェット
● 自由に使ってよい時間
● 新機能のリリースや機能改善などに活用
● SRE と開発チームの共通の予算

29
エラーバジェット導入効果
● エラーバジェット
● SLO
● SRE と開発チームに共通なインセンティブ
● 開発チームがエラーバジェットを通して
システム運用への意識を持つ
○ リスク管理
○ 品質管理
○ システム稼働時間

30
SLO / SLI / エラーバジェット
SLI
SLO
Error
Budget継続的な
改善

31
Elastic Observability による SLO / SLI
Elastic
Observability
Logs
Metrics
Uptime
APM
システムやサービスからのメッセージをキャプチャし
正確性を管理
インフラストラクチャのリソース使用率を測定し
飽和状態を管理
アプリケーション内部のイベントをキャプチャし
レイテンシと品質を管理
サービスエンドポイントにハートビートを送信し
可用性を管理
Kibana
● アラート
● アクション

32
(再掲) Anthos とオブザーバビリティ
クラスタ管理
サービス管理
App Dev
Anthos が管理している対象サービスの
健全性と性能のオブザーバビリティを提供

33
Anthos Service Mesh によるオブザーバリティ
Service A Service B
Envoy Envoy
HTTP, gRPC, TCP
mTLS
Anthos GKE Single Cluster
Data Plane
Tra c Director
構成情報 TLS 証明書テレメトリ
Mesh CA
Managed
Observability
GA GABeta
Google 管理コントロールプレーン
Google が管理するコントロールプレーンで
Istio 互換のコンポーネントを提供
以下の機能を実現
● トラフィック管理
● セキュリティ
● オブザーバリティ
○ サービスの依存関係可視化
○ メトリクス収集
○ SLO を用いたサービスレベル監視

34
Anthos Service Mesh による依存関係可視化

35
Anthos Service Mesh によるメトリクス収集

36
Anthos Service Mesh による SLO の構成
SLI のメトリクス種別を選択
観測のための閾値を設定
コンプライアンス期間の設定
(SLI 目標達成の判定のための期間)
ウィザード形式で SRE の手法を用いた SLO の定義が可能

37
Anthos Service Mesh によるサービスレベル監視

38
Elastic Stack と Anthos によるオブザーバビリティ
https://cloud.google.com/solutions/partners/
monitoring-gke-on-prem-with-the-elastic-stack
https://github.com/elastic
/examples/tree/master/GKE-On-Prem

40
マルチクラウドアプリケーション & オブザーバリティ
テクノロジー
人
プロセス
SRE チーム
SRE 手法
● Elastic Stack
● Anthos
真のマルチクラウド活用

42
Thank You
Shinya Yanagihara
Google Cloud

Elastic and Google: マルチクラウド / ハイブリッドクラウドを実現する Anthos と SRE

More Related Content

What's hot

Similar to Elastic and Google: マルチクラウド / ハイブリッドクラウドを実現する Anthos と SRE

More from Elasticsearch

Recently uploaded

Elastic and Google: マルチクラウド / ハイブリッドクラウドを実現する Anthos と SRE