Movatterモバイル変換

Google confidential | Do not distributeGoogle のインフラ技術から考える理想の DevOpsEtsuji NakaiCloud Solutions Architect at Google2017/02/14 ver1.0

$ who am i▪Etsuji NakaiCloud Solutions Architect at GoogleTwitter @enakai00好評発売中

DevOps を支える隠された視点

そもそも DevOps って何でしたっけ？▪ 開発チームと運用チームが一緒に会議すること？▪ 開発チームが運用までやっちゃうこと？▪ 運用チームがコードを書いて開発すること？https://ja.wikipedia.org/wiki/DevOpshttp://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.htmlhttp://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 として再実装したものが Kuberneteshttps://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 System19チャンクサーバープライマリセカンダリセカンダリデータフロークライアントクライアントコントロールフロー▪ データフローを最適化することで書き込み性能を向上●クライアントから複数のチャンクサーバーに対してシリアルにデータ転送●データ受信を開始したチャンクサーバーは、即座に転送を開始●コントロールフローを分離して、チャンクサーバー間のデータ整合性を確保

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 PlatformVIRTUAL NETWORKLOAD BALANCINGCDNDNSINTERCONNECTManagement Compute Storage Networking DataMachineLearningSTACKDRIVERIDENTITY ANDACCESSMANAGEMENTCLOUD MLSPEECH APIVISION APITRANSLATE APINATURALLANGUAGE API

Movatterモバイル変換

Change Language

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

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

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

More from Etsuji Nakai

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