Contenu connexe Similaire à Googleのインフラ技術から考える理想のDevOps (20) Plus de Etsuji Nakai (20) Googleのインフラ技術から考える理想のDevOps1. Google confidential | Do not distribute
Google のインフラ技術から考える理想の DevOps
Etsuji Nakai
Cloud Solutions Architect at Google
2017/02/14 ver1.0
2. $ who am i
▪Etsuji Nakai
Cloud Solutions Architect at Google
Twitter @enakai00
好評発売中
4. そもそも DevOps って何でしたっけ?
▪ 開発チームと運用チームが一緒に会議すること?
▪ 開発チームが運用までやっちゃうこと?
▪ 運用チームがコードを書いて開発すること?
https://ja.wikipedia.org/wiki/DevOps
http://itpro.nikkeibp.co.jp/article/COLUMN/20131113/517746/
http://www.atmarkit.co.jp/ait/articles/1307/02/news002.html
8. 理想の DevOps を実現するための隠された視点
▪ レイヤーごとの責任分界点を明確にすることで、「本質的でない依存関係」をな
くして、全体最適化を実現
●
無駄な依存関係がないからこそ、インフラ・開発・運用の 3 チームが健全な協力関係を
確立可能に
▪ その上で「真に重要な依存関係」に叡智を結集
●
スケーラブルで運用効率性の高いアプリケーションに
必要なインフラ技術の提供
●
運用段階での効率性や安定性、スケーラビリティの確
保を前提としたインフラ/アプリケーションの設計
基盤開発
アプリケーション開発
運用
11. Google が開発した基盤技術の例
▪ Borg / Omega
●
コンテナを用いたアプリケーション実行基盤
●
OS レイヤーを隠蔽して、アプリケーションレ
ベルでの管理に集中
●
リソーススケジューラーによるアプリケーシ
ョンデプロイの最適化
http://research.google.com/pubs/pub44843.html
http://www.hpts.ws/papers/2015/wilkes.pdf
基盤とアプリケーションの
明確な責任分界点
12. Google が開発したデータストア技術の例
▪ Google File System / Colossus
●
分散ファイルシステム
●
大容量ファイルのシーケンシャルな読み込みと追記処理に特化してチューニング
●
MapReduce や Bigtable など上位ミドルウェアのバックエンドとして使用
▪ Bigtable
●
行単位アクセスに特化した Key-Value ストア(複数行のトランザクションは非対応)
●
1 つの行の中に複数のカラムファミリーを用意して複数データを保存
●
追記処理しかできない GFS の上に高速なデータの書き換え処理を実装!
ユースケースの分析に
基づいた機能選定
技術的制約の打破
13. Google が開発したデータストア技術の例
▪ Megastore
●
Bigtable をバックエンドとして実装した分散データストア
●
複数データセンターにまたがるレプリケーションと「エンティティグループ」単位での
トランザクション(強い一貫性を持ったデータアクセス)
●
実質的に無限のスケーラビリティ(レイテンシーは Bigtable より劣る)
▪ Spanner
●
MegaStore の欠点を克服するために再実装された分散データストア
●
RDB に類似したテーブル構造と SQL トランザクションを実現
●
原子時計による時刻同期システムを用いて、分散データベースにおける性能問題を解決
技術的制約と機能要件の
合理的なトレードオフ
技術的制約の打破
14. Google が開発したデータ処理技術の例
▪ MapReduce
●
Map / Shuffle / Reduce の処理モデルに基づいた分散データ処理基盤
▪ FlumeJava
●
MapReduce を汎化して、より一般的なデータ変換のフローを記述可能にした基盤
●
最適化された MapReduce を内部的に生成して実行
●
バッチ型のデータ処理機能を提供
▪ MillWheel
●
ストリームデータの処理基盤
●
Low Watermark (処理済みイベント時刻)を用いた時系列イベントのトラッキング
●
イベントデータの永続性と処理の一貫性を基盤レベルで保証
制約の受け入れによる
スケーラビリティの実現
アプリケーションの開発生産性に
フォーカスした機能実装
16. Borg / Omega
▪ Google のデータセンターで稼働するミドルウェア/アプリケーションの多数が
稼働する標準基盤
●
Web Search
●
Gmail, Google Docs
●
Bigtable, MapReduce, FlumeJava, MillWheel
●
Google File System, Bigtable, Megastore
●
分散ビルドシステム
●
Google Compute Engine
●
etc…
▪ OSS として再実装したものが Kubernetes
https://research.google.com/pubs/pub43438.html
18. Google File System
▪ Google におけるファイルアクセスのパターンを分析して仕様を決定
●
大容量ファイルのシーケンシャルな読み込みと追記処理に特化してチューニング
●
他の操作(部分書き換えなど)も可能ではあるが、性能は出ない
▪ 冗長性の確保などは基盤側で実装
●
64MB のチャンクに分割して複数サーバーに複製保存
●
サーバー障害時は自動的に切り替え
並列データ処理の結果を受け渡し大容量データの受け渡し
http://research.google.com/archive/gfs.html
19. Google File System
19
チャンクサーバー プライマリセカンダリ セカンダリ
データフロー
クライアントクライアント
コントロールフロー
▪ データフローを最適化することで書き込み性能を向上
●
クライアントから複数のチャンクサーバーに対してシリアルにデータ転送
●
データ受信を開始したチャンクサーバーは、即座に転送を開始
●
コントロールフローを分離して、チャンクサーバー間のデータ整合性を確保
21. Bigtable
▪ Row Key の一定範囲ごとに Tablet に分割にして、分散アクセスを実現
●
Tablet の実体はバックエンドの GFS に保存( Tablet サーバーが障害停止しても、他の
Tablet サーバーが引き継ぎ可能)
●
イミュータブルな SSTable/memtable と追記型ログファイルの組み合わせにより、 GFS
上のファイルに対する追記処理のみで、高速なランダムアクセスを実現
24. 理想の DevOps を実現するための隠された視点
▪ レイヤーごとの責任分界点を明確にすることで、「本質的でない依存関係」をな
くして、全体最適化を実現
●
無駄な依存関係がないからこそ、インフラ・開発・運用の 3 チームが健全な協力関係を
確立可能に
▪ その上で「真に重要な依存関係」に叡智を結集
●
スケーラブルで運用効率性の高いアプリケーションに
必要なインフラ技術の提供
●
運用段階での効率性や安定性、スケーラビリティの確
保を前提としたインフラ/アプリケーションの設計
基盤開発
アプリケーション開発
運用
SRE基盤開発チーム
決して「謎技術」ではありません!
25. Google のインフラを一般開放した Google Cloud Platform
VIRTUAL NETWORK
LOAD BALANCING
CDN
DNS
INTERCONNECT
Management Compute Storage Networking Data
Machine
Learning
STACKDRIVER
IDENTITY AND
ACCESS
MANAGEMENT
CLOUD ML
SPEECH API
VISION API
TRANSLATE API
NATURAL
LANGUAGE API