【読書メモ】DevOps教科書（part.1）

2016−06−25 DevOps -A Software Architect's Perspective

これ読んだ

DevOps教科書

長いので分割、第1部

---

Oveview

• DevOpsを実践すべきシステムアーキテクトに向けたノウハウ
• 特に重要な章
  • ４章：ビルド・テスト
  • ５章：デプロイ
  • ６章：モニタリング
  • ９章：非機能要件

---

Part1: Background

Chapter1.What Is DevOps?

DevOpsの目標と課題、目標の達成手段は？

DevとOpsの共通目標は？

• デプロイまでの時間を削減すること
• ビジネスアイデアをユーザが利用できる形で届けること

DevOpsがかかえる課題

• 現行に及ぼす影響が大きい
  • チーム構造、アーキテクチャ、運用方法など

DevOpsのトレードオフ

• DevOpsツールのサポートが必要
• ITProとDeveloperの職務分掌
  • 障害解析を開発に任せる、などが必要

---

Part2: Deployment Pipeline

Chapter4. Overall Architecture

DevOpsと相性の良い、マイクロサービスアーキテクチャの説明

Introduction

• DevOps実践が全体構成に及ぼす意味

Conclusion

• チーム間の調整を最小限に抑えるというDevOpsの目標はMSAの採用で実現可能

MSA採用後の新たな課題

• モニタリング
• デバッグ
• パフォーマンス管理
• テスト

Chapter5. Building and Testing

デプロイパイプラインのための、テスト効率化とマージ回数の抑制に向けた問題点

迅速なビルド・デプロイのためには

適切なデプロイパイプラインを作ることが大切

デプロイパイプラインの5ステップ

• プレコミット
• ビルド・インテグレーションテスト
• ユーザ受入/ステージング/性能テスト
• 本番環境

• 通常の本番実行への移行

• フィーチャートグル

  • 本番実行中に特定のコードへのアクセスを禁止する
  • 対象コードが本番稼動したら取り除く

• テスト

  • テストハーネスによって実行されるように自動化
  • テストハーネス？

アーキテクトが考慮すべきこと

• トレース可能で反復可能なように
• 環境依存のパラメータ
• 高セキュリティのパラメータ
• 各ステップで適切な自動テスト

Chapter6. Deployment

デプロイにおける、バージョン一貫性と複数サービス競合についての問題点

デプロイの目標

最小限のユーザインパクトで、本番環境をアップグレードすること

デプロイはAll or Nothingのプロセス

• デプロイ終了後は、すべてのVMがアップグレードされている、または、１台もされていない状態であること

複数のVMへのデプロイ戦略

ブルーグリーンデプロイ

• 論理的な問題は起きない
• 本来必要な数の、倍のVMが必要

ローリングアップグレード

• リソースの使い方は効率的
• 論理的一貫性に課題がある
  • 一時的に別バージョンのサービスを提供
  • バージョンに依存する接続先がいるとアウト
  • 複数のサービス相乗りだと競合する可能性

論理的一貫性の問題の解決方法

• フィーチャートグル
• 上位/下位互換性の確保
• バージョンを意識したコード

ロールバックの考慮

* フィーチャートグルはロールバックをサポートする
* 永続データの扱いは慎重に

• DRによるBCPの考慮
  • 距離の離れたサイトに冗長なデプロイをすることで継続性を確保
  • 複製のアーキテクチャを組み込んでおけば、想定外の障害時も復旧時間が速くなる
• デプロイ管理のためのツール
  • ライトウェイトコンテナとイメージ管理ツール
  • テスト用の小規模で本番によく似た環境へのデプロイが簡単にできる

Part3: Crosscutting Concerns

(横断的な関心ごと)

Chapter9. Oter xxxilities

--

In a nutshell

• トレーサビリティ
• パフォーマンス
• 信頼性
• 反復可能性

Introduction

• デプロイパイプライン以外のプロセスをDevOpsパイプラインとして取り上げる
• ility＝〇〇性
  • 機能がうまく動いているか
  • 必要な時に操作を正確に反復できるか
  • ビジネスコンセプトが生まれてからリリースまでにどれだけの時間がかかったか
  • パイプラインに含まれるツールがどのように相互作用しているか

Conclusion

• ilityの問題は、後付けではなく、早い段階で考慮し、組み込んでおくべき
• それぞれの要素はトレードオフの関係にあるものも存在する
• ニーズを満足させるパイプラインの構築に必要なのは、トレードオフの理解

-	ility	品質を高めるためのテクニック
-	反復可能性	アクティビティのトレースを残す。バージョン管理、パラメータの管理。
-	処理性能	ボトルネックを明らかにするための計測。使っていない環境やリソースの解放。
-	信頼性	様々なエラー率を明確にする。エラー率の高いサービスはミラーリング。実行時間の長期的推移。
-	回復可能性	スクリプトに例外処理を組み込む。
-	相互運用性	安定したIFと柔軟なスクリプト機能を持つツールを選ぶ
-	試験可能性	xx
-	変更可能性	xx