前回のおさらい
前回は「DevOpsとは何か」ということについて触れました。
fclout.hateblo.jp
DevとOpsが協調された組織としての文化を作るためには、
各メンバーそれぞれへの意識づけが最も大切になってきます。
それを支えるのが以下に提唱される6つのテクノロジーであるというお話でした。
- インフラの自動化
- バージョン管理の共有
- ワンステップのビルドとデプロイ
- フィーチャーフラグ
- メトリクスの共有
- チャットとチャットボット
これは、「DevOps」という考え方を世界で初めて提唱したFlicker社のエンジニアがVelocity 2009で発表しています
今はこれらのテクノロジーは当たり前のものですが、
それぞれどういった技術なのか改めて確認してみましょう。
今回は「インフラの自動化」について触れたいと思います。
インフラの自動化
いわゆるIaC(Infrastructure As Code)です。
今まで手作業で導入・設定・運用・保守していたインフラ部分(HW・OS・PP等)をすべてコード化(プログラム化)させようというものです。
IaCを実現するツール
身近なものだと以下のツールが挙げられます。
- Terraform
- Ansible
- Chef
- Puppet
- CloudFormation(AWS)
いずれもプログラムによってインフラレイヤを自動構築する製品です。
では自動化することでどんなメリットがあるのでしょうか。
それは主にQCD(品質・コスト・納期)に大きく関わってくると言えるでしょう。
インフラの自動化と品質
インフラの自動化は品質向上へ大きく貢献します。
これまではインフラ担当のエンジニアが
パラメータを設計し、構築手順書を作り、それらに従って手作業で構築・設定を行い、試験を実施。
また運用手順書を作り、運用担当へ引き継ぐ(もしくは自分で運用する)のが一般的な流れでした。
作業品質の担保
上記は言ってみればすべてが手作業です。
手作業にはヒューマンエラーものがつきものです。
- パラメータの設計漏れ、設計誤り
- 構築手順書の手順漏れ、手順誤り
- 手順の実施漏れ、実施誤り
- 試験項目の漏れ、誤り
- 試験実施漏れ、実施誤り
- 構築手順書の手順漏れ、手順誤り
- オペレーションの実施漏れ、実施誤り
- etc...
設計書や手順書といったドキュメントに関するエラーは一度拾えば品質が担保されますが、
手順や試験といった作業に関するエラーは、元のドキュメントがどんなに完璧なものでも、人間が実施する限り品質が100%担保されるものではありません。
それは回数が増えれば増えるほどエラーの発生リスクは高くなっていきます。
IaCの利点はそこ(手順や試験)を自動化(コード化)できるところにあります。
手作業と違ってコードの品質がそのまま作業の品質となります。
つまり一度品質が担保されたコードを作ってしまえば、
あとは誰が実施しようが同じクオリティが保てるのです。
これは運用面ではとても素晴らしいことです。
再利用性の向上
コード化すれば簡単かつ確実な再利用ができます。
以下のシーンを考えてみます。
- 「パラメータを変えたい」
- 「製品をバージョンアップしたい」
- 「インフラを更改したい」
従来の場合だと以下の流れでした
- 既存の手順書を修正
- 試験項目の追加
- 手順書もとにシステムに直接変更作業を実施 ※エラーリスク増
- 試験の実施 ※エラーリスク増
しかしコード化してしまえば、
- コードを修正
- コードをコミット
これだけで済みます。
手順は簡潔になり、かつ品質低下のリスクが回避できます。
またCI/CDツール(Jenkins等)と組み合わせれば、リリース頻度を増やせ、さらに再利用性が向上します。
頻度を増やすことで、細かい単位でシステムに変更を加えることができ、インシデントのリスクを下げることができます。
これもシステム全体の品質向上につながります。
バージョン管理が容易
コード化すればバージョン管理ツール(git等)との親和性も高まります。
- いつ
- 誰が
- 何に
- どんな変更をしたのか
が誰でも簡単にわかる他、
前述のCI/CDツールと組み合わせることで環境管理(どの環境がどの断面なのか)が容易になります。
さいごに
品質だけでこれだけのメリットがあることがわかりました。
少し長くなりそうので、残りについては次回にしたいと思います。