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

Google confidential | Do not distribute

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

Etsuji NakaiCloud Solutions Architect at Google2017/02/14 ver1.0

$ who am i

▪Etsuji Nakai

Cloud Solutions Architect at Google

Twitter @enakai00

好評発売中

DevOps を支える隠された視点

そもそも 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

Site Reliability Engineer

▪ Google の運用チームの名称● 開発者と同じスキルセット＋インフラの知識● 運用作業 ＋ 運用効率を改善するためのコード開発● 運用作業は、業務時間の 50% 以下に制限

Google が開発した分散ソフトウェア技術の例

▪全世界のデータセンターで共通化されたインフラの提供

▪スケーラブルで運用効率性の高いアプリケーションを実現する機能を提供

▪インフラを隠蔽して、アプリケーションレベルでの開発／管理に集中

公開論文から読み解くインフラ技術の「思想」▪「謎技術」の実体は、徹底的な合理主義　

▪「技術的制約」に対する恐ろしいほどの洞察力

● この制約を受けいれることが何が可能になるのか？● この制約を打破することで何が可能になるのか？

https://research.google.com/pubs/papers.html http://www.school.ctc-g.co.jp/columns/nakai2/

理想の DevOps を実現するための隠された視点

▪レイヤーごとの責任分界点を明確にすることで、「本質的でない依存関係」をなくして、全体最適化を実現● 無駄な依存関係がないからこそ、インフラ・開発・運用の 3 チームが健全な協力関係を

確立可能に

▪その上で「真に重要な依存関係」に叡智を結集● スケーラブルで運用効率性の高いアプリケーションに

必要なインフラ技術の提供● 運用段階での効率性や安定性、スケーラビリティの確

保を前提としたインフラ／アプリケーションの設計基盤開発

アプリケーション開発

運用

この先生きのこるために・・・

▪インフラを構成するソフトウェアの特性を深く理解して、最適なアプリケーション・アーキテクチャーを見極めることが重要

▪それぞれの技術要素を根本から理解して、システム全体のアーキテクチャーを俯瞰できる能力が必要

https://github.com/GoogleCloudPlatform/gke-gobang-app-example http://www.slideshare.net/strsk/google-container-engine-kubernetes

● 重要なのは、役割ではなく、知識範囲としてのフルスタック

Googleが開発したソフトウェア技術の例

Google が開発した基盤技術の例▪ Borg / Omega

● コンテナを用いたアプリケーション実行基盤● OS レイヤーを隠蔽して、アプリケーションレ

ベルでの管理に集中● リソーススケジューラーによるアプリケーシ

ョンデプロイの最適化

http://research.google.com/pubs/pub44843.htmlhttp://www.hpts.ws/papers/2015/wilkes.pdf

基盤とアプリケーションの明確な責任分界点

Google が開発したデータストア技術の例

▪ Google File System / Colossus● 分散ファイルシステム● 大容量ファイルのシーケンシャルな読み込みと追記処理に特化してチューニング● MapReduce や Bigtable など上位ミドルウェアのバックエンドとして使用

▪ Bigtable● 行単位アクセスに特化した Key-Value ストア（複数行のトランザクションは非対応）● 1つの行の中に複数のカラムファミリーを用意して複数データを保存● 追記処理しかできない GFS の上に高速なデータの書き換え処理を実装！

ユースケースの分析に基づいた機能選定

技術的制約の打破

Google が開発したデータストア技術の例

▪ Megastore● Bigtable をバックエンドとして実装した分散データストア● 複数データセンターにまたがるレプリケーションと「エンティティグループ」単位での

トランザクション（強い一貫性を持ったデータアクセス）● 実質的に無限のスケーラビリティ（レイテンシーは Bigtableより劣る）

▪ Spanner● MegaStore の欠点を克服するために再実装された分散データストア● RDBに類似したテーブル構造と SQL トランザクションを実現● 原子時計による時刻同期システムを用いて、分散データベースにおける性能問題を解決

技術的制約と機能要件の合理的なトレードオフ

技術的制約の打破

Google が開発したデータ処理技術の例

▪ MapReduce● Map / Shuffle / Reduce の処理モデルに基づいた分散データ処理基盤

▪ FlumeJava● MapReduce を汎化して、より一般的なデータ変換のフローを記述可能にした基盤● 最適化された MapReduce を内部的に生成して実行● バッチ型のデータ処理機能を提供

▪ MillWheel● ストリームデータの処理基盤● Low Watermark（処理済みイベント時刻）を用いた時系列イベントのトラッキング● イベントデータの永続性と処理の一貫性を基盤レベルで保証

制約の受け入れによるスケーラビリティの実現

アプリケーションの開発生産性にフォーカスした機能実装

実装とユースケース

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

（参考） Colossus について

▪ Google File System の後継として開発▪ Google における標準的な分散ファイルシステムとして利用▪詳細情報は未公開

Google File System

▪ Google におけるファイルアクセスのパターンを分析して仕様を決定● 大容量ファイルのシーケンシャルな読み込みと追記処理に特化してチューニング● 他の操作（部分書き換えなど）も可能ではあるが、性能は出ない

▪冗長性の確保などは基盤側で実装● 64MBのチャンクに分割して複数サーバーに複製保存● サーバー障害時は自動的に切り替え

並列データ処理の結果を受け渡し大容量データの受け渡し

http://research.google.com/archive/gfs.html

Google File System

19チャンクサーバー プライマリセカンダリ セカンダリ

データフロー

クライアントクライアント

コントロールフロー

▪データフローを最適化することで書き込み性能を向上● クライアントから複数のチャンクサーバーに対してシリアルにデータ転送● データ受信を開始したチャンクサーバーは、即座に転送を開始● コントロールフローを分離して、チャンクサーバー間のデータ整合性を確保

Bigtable

▪構造化データを保存するための大規模分散 Key-Value ストア● クローラーが収集した HTML ファイル

から、衛星画像ファイルまで大小さまざまなデータを保存

● 行単位でのアトミックな操作● Row Key の辞書順での高速スキャン

http://research.google.com/archive/bigtable.html

Bigtable

▪ Row Key の一定範囲ごとに Tablet に分割にして、分散アクセスを実現● Tablet の実体はバックエンドの GFS に保存（Tabletサーバーが障害停止しても、他のTabletサーバーが引き継ぎ可能）

● イミュータブルな SSTable/memtable と追記型ログファイルの組み合わせにより、 GFS上のファイルに対する追記処理のみで、高速なランダムアクセスを実現

Spanner

▪複数データセンターにまたがった分散データベース● RDBに類似したテーブル構造とトランザクション機能を実現● すべての書き込みデータにタイムスタンプを付与することで、サーバー間でのデータの整合性を確保（TrueTime APIで信頼できる時刻同期の範囲をチェックして、タイムスタンプの値と書き込み間隔を調整）

● 原子時計と GPS を用いたタイムサーバーにより、高精度な時刻同期を実現

http://research.google.com/archive/spanner.html

まとめ

理想の DevOps を実現するための隠された視点

▪レイヤーごとの責任分界点を明確にすることで、「本質的でない依存関係」をなくして、全体最適化を実現● 無駄な依存関係がないからこそ、インフラ・開発・運用の 3 チームが健全な協力関係を

確立可能に

▪その上で「真に重要な依存関係」に叡智を結集● スケーラブルで運用効率性の高いアプリケーションに

必要なインフラ技術の提供● 運用段階での効率性や安定性、スケーラビリティの確

保を前提としたインフラ／アプリケーションの設計

基盤開発

アプリケーション開発

運用

SRE基盤開発チーム

決して「謎技術」ではありません！

Google のインフラを一般開放した Google Cloud Platform

VIRTUAL NETWORK

LOAD BALANCING

CDN

DNS

INTERCONNECT

Management Compute Storage Networking DataMachineLearning

STACKDRIVER

IDENTITY ANDACCESS

MANAGEMENT

CLOUD ML

SPEECH API

VISION API

TRANSLATE API

NATURALLANGUAGE API

Thank you!