Googleのインフラ技術から考える理想のDevOps

Googleのインフラ技術から考える理想のDevOps

1. 1. Google confidential | Do not distribute Google のインフラ技術から考える理想の DevOps Etsuji Nakai Cloud Solutions Architect at Google 2017/02/14 ver1.0
2. 2. $ who am i ▪Etsuji Nakai Cloud Solutions Architect at Google Twitter @enakai00 好評発売中
3. 3. DevOps を支える隠された視点
4. 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
5. 5. Site Reliability Engineer ▪ Google の運用チームの名称 ● 開発者と同じスキルセット＋インフラの知識 ● 運用作業 ＋ 運用効率を改善するためのコード開発 ● 運用作業は、業務時間の 50% 以下に制限
6. 6. Google が開発した分散ソフトウェア技術の例 ▪ 全世界のデータセンターで共通化されたインフラの提供 ▪ スケーラブルで運用効率性の高いアプリケーションを実現する機能を提供 ▪ インフラを隠蔽して、アプリケーションレベルでの開発／管理に集中
7. 7. 公開論文から読み解くインフラ技術の「思想」 ▪ 「謎技術」の実体は、徹底的な合理主義　 ▪ 「技術的制約」に対する恐ろしいほどの洞察力 ● この制約を受けいれることが何が可能になるのか？ ● この制約を打破することで何が可能になるのか？ https://research.google.com/pubs/papers.html http://www.school.ctc-g.co.jp/columns/nakai2/
8. 8. 理想の DevOps を実現するための隠された視点 ▪ レイヤーごとの責任分界点を明確にすることで、「本質的でない依存関係」をな くして、全体最適化を実現 ● 無駄な依存関係がないからこそ、インフラ・開発・運用の 3 チームが健全な協力関係を 確立可能に ▪ その上で「真に重要な依存関係」に叡智を結集 ● スケーラブルで運用効率性の高いアプリケーションに 必要なインフラ技術の提供 ● 運用段階での効率性や安定性、スケーラビリティの確 保を前提としたインフラ／アプリケーションの設計 基盤開発 アプリケーション開発 運用
9. 9. この先生きのこるために・・・ ▪ インフラを構成するソフトウェアの特性を深く理解して、最適なアプリケーシ ョン・アーキテクチャーを見極めることが重要 ▪ それぞれの技術要素を根本から理解して、システム全体のアーキテクチャーを 俯瞰できる能力が必要 https://github.com/GoogleCloudPlatform/gke-gobang-app-example http://www.slideshare.net/strsk/google-container-engine-kubernetes ● 重要なのは、役割ではなく、知識範囲 としてのフルスタック
10. 10. Google が開発した ソフトウェア技術の例
11. 11. Google が開発した基盤技術の例 ▪ Borg / Omega ● コンテナを用いたアプリケーション実行基盤 ● OS レイヤーを隠蔽して、アプリケーションレ ベルでの管理に集中 ● リソーススケジューラーによるアプリケーシ ョンデプロイの最適化 http://research.google.com/pubs/pub44843.html http://www.hpts.ws/papers/2015/wilkes.pdf 基盤とアプリケーションの 明確な責任分界点
12. 12. Google が開発したデータストア技術の例 ▪ Google File System / Colossus ● 分散ファイルシステム ● 大容量ファイルのシーケンシャルな読み込みと追記処理に特化してチューニング ● MapReduce や Bigtable など上位ミドルウェアのバックエンドとして使用 ▪ Bigtable ● 行単位アクセスに特化した Key-Value ストア（複数行のトランザクションは非対応） ● 1 つの行の中に複数のカラムファミリーを用意して複数データを保存 ● 追記処理しかできない GFS の上に高速なデータの書き換え処理を実装！ ユースケースの分析に 基づいた機能選定 技術的制約の打破
13. 13. Google が開発したデータストア技術の例 ▪ Megastore ● Bigtable をバックエンドとして実装した分散データストア ● 複数データセンターにまたがるレプリケーションと「エンティティグループ」単位での トランザクション（強い一貫性を持ったデータアクセス） ● 実質的に無限のスケーラビリティ（レイテンシーは Bigtable より劣る） ▪ Spanner ● MegaStore の欠点を克服するために再実装された分散データストア ● RDB に類似したテーブル構造と SQL トランザクションを実現 ● 原子時計による時刻同期システムを用いて、分散データベースにおける性能問題を解決 技術的制約と機能要件の 合理的なトレードオフ 技術的制約の打破
14. 14. Google が開発したデータ処理技術の例 ▪ MapReduce ● Map / Shuffle / Reduce の処理モデルに基づいた分散データ処理基盤 ▪ FlumeJava ● MapReduce を汎化して、より一般的なデータ変換のフローを記述可能にした基盤 ● 最適化された MapReduce を内部的に生成して実行 ● バッチ型のデータ処理機能を提供 ▪ MillWheel ● ストリームデータの処理基盤 ● Low Watermark （処理済みイベント時刻）を用いた時系列イベントのトラッキング ● イベントデータの永続性と処理の一貫性を基盤レベルで保証 制約の受け入れによる スケーラビリティの実現 アプリケーションの開発生産性に フォーカスした機能実装
15. 15. 実装とユースケース
16. 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
17. 17. （参考） Colossus について ▪ Google File System の後継として開発 ▪ Google における標準的な分散ファイルシステムとして利用 ▪ 詳細情報は未公開
18. 18. Google File System ▪ Google におけるファイルアクセスのパターンを分析して仕様を決定 ● 大容量ファイルのシーケンシャルな読み込みと追記処理に特化してチューニング ● 他の操作（部分書き換えなど）も可能ではあるが、性能は出ない ▪ 冗長性の確保などは基盤側で実装 ● 64MB のチャンクに分割して複数サーバーに複製保存 ● サーバー障害時は自動的に切り替え 並列データ処理の結果を受け渡し大容量データの受け渡し http://research.google.com/archive/gfs.html
19. 19. Google File System 19 チャンクサーバー プライマリセカンダリ セカンダリ データフロー クライアントクライアント コントロールフロー ▪ データフローを最適化することで書き込み性能を向上 ● クライアントから複数のチャンクサーバーに対してシリアルにデータ転送 ● データ受信を開始したチャンクサーバーは、即座に転送を開始 ● コントロールフローを分離して、チャンクサーバー間のデータ整合性を確保
20. 20. Bigtable ▪ 構造化データを保存するための大規模分散 Key-Value ストア ● クローラーが収集した HTML ファイル から、衛星画像ファイルまで大小さま ざまなデータを保存 ● 行単位でのアトミックな操作 ● Row Key の辞書順での高速スキャン http://research.google.com/archive/bigtable.html
21. 21. Bigtable ▪ Row Key の一定範囲ごとに Tablet に分割にして、分散アクセスを実現 ● Tablet の実体はバックエンドの GFS に保存（ Tablet サーバーが障害停止しても、他の Tablet サーバーが引き継ぎ可能） ● イミュータブルな SSTable/memtable と追記型ログファイルの組み合わせにより、 GFS 上のファイルに対する追記処理のみで、高速なランダムアクセスを実現
22. 22. Spanner ▪ 複数データセンターにまたがった分散データベース ● RDB に類似したテーブル構造とトランザクション機能を実現 ● すべての書き込みデータにタイムスタンプを付与することで、サーバー間でのデータの 整合性を確保（ TrueTime API で信頼できる時刻同期の範囲をチェックして、タイムス タンプの値と書き込み間隔を調整） ● 原子時計と GPS を用いたタイムサーバーにより、高精度な時刻同期を実現 http://research.google.com/archive/spanner.html
23. 23. まとめ
24. 24. 理想の DevOps を実現するための隠された視点 ▪ レイヤーごとの責任分界点を明確にすることで、「本質的でない依存関係」をな くして、全体最適化を実現 ● 無駄な依存関係がないからこそ、インフラ・開発・運用の 3 チームが健全な協力関係を 確立可能に ▪ その上で「真に重要な依存関係」に叡智を結集 ● スケーラブルで運用効率性の高いアプリケーションに 必要なインフラ技術の提供 ● 運用段階での効率性や安定性、スケーラビリティの確 保を前提としたインフラ／アプリケーションの設計 基盤開発 アプリケーション開発 運用 SRE基盤開発チーム 決して「謎技術」ではありません！
25. 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
26. 26. Thank you!