インフラエンジニアにとってのDevOps – 「若手エンジニアのためのDevOps入門」(1)

みなさま、こんにちは。山本和道(やまもとかずみち)と申します。
フリーランスのエンジニアで、主にWeb系開発やインフラ構築を扱っている者です。また、オープンソース活動としてさくらのクラウド関連ツールの開発を行っています。これまでさくらのクラウド公認CLI「Usacloud」や「Terraform for さくらのクラウド」、「Packer for さくらのクラウド」といったDevOpsを支援する一連のツールを開発してきました。

今回から連載として「DevOps」に焦点を当てた記事をお送りいたします。

第1回	インフラエンジニアにとってのDevOps
第2回	Webアプリでの開発環境構築
第3回	バージョン管理システム
第4回	継続的インテグレーション/デリバリー
第5回	DevOpsのための道具箱: APIを使いこなす
第6回	リリース/構成管理: 概要

この連載の概要
DevOpsとは
従来型の職能別組織の場合のメリット/デメリット
開発側と運用側の連携とは
DevOps = 対立ではなく共通の目的に向けた協調
じゃあDevOpsは実際どうやったらいいの？
DevOpsプロセス全体像とツールチェイン
DevOpsの各プロセスを支援するツール群
ツールがプロセス導入を容易にし促進する
各プロセスでのツール概要
まとめ

この連載の概要

この連載では開発担当者/運用担当者が一体となって価値を創造していく活動、いわゆる「DevOps」について各プロセスでどのような活動を行うのか、それらのプロセスにどういったツールが存在するのかをご紹介いたします。

対象読者は社会人2〜3年目のエンジニアで、チームリーダーとして開発環境やインフラ環境の設計、チーム内で利用するツールの選定/導入/運用を今後担当するような方を想定しています。

これまで開発が中心だったためインフラ/運用側のことは不安という方や、逆に開発のことはよく分からないという方に向けてDevOpsのプロセス全体像やどのようなツールが存在するのかを広く紹介することで実際のツール選定や導入に役立てていただきたいと思っています。
特に筆者の主な業務領域である開発面の紹介を通じて普段インフラ/運用側の業務を担当されている方にも開発からの一連のプロセスを知ってもらいDevOpsへの取り組みに役立てていただければ幸いです。

この連載で扱う内容は以下のようになっています。

インフラエンジニアにとってのDevOps(当記事)
開発環境の知識
ソースコードのバージョン管理と開発フロー
継続的インテグレーション/デリバリー
リリース/構成管理: 概要と基礎知識
リリース/構成管理: インフラレイヤーの構築
リリース/構成管理: OS/アプリケーションレイヤーの構成
サンプルアプリによるCI/CD環境構築の実践
モニタリングとフィードバック

また、これらのプロセスの実践やツール導入/ツール作成を行う際の補助的な知識として各クラウドベンダーなどが提供するAPIの利用方法やプロセスやツールを結びつけるBOTや連携ツールなどについても折に触れて扱う予定です。

それでは早速「DevOps」について概要からご紹介いたします。

DevOpsとは

まずはDevOpsという言葉の定義についてです。

WikipediaではDevOpsについて以下のように説明されています。

DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。ソフトウェアのビルド、テスト、そしてリリースの文化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。
(出典: Wikipedia - DevOps)

Wikipekiaでも触れられていますが、DevOpsという言葉について厳密にこれがDevOpsだ！という定義は存在せず抽象的なものとなっています。そこで当記事ではDevOpsを
「ソフトウェアの品質を確保しつつ迅速/頻繁にリリースを行うことで、フィードバックを取り入れニーズに即したアプリケーションを提供し続けることを目指し、そのために開発側と運用側が連携するというプロセスの全体像」
という位置付けとします。

従来型の職能別組織の場合のメリット/デメリット

私が以前関わっていた企業では、開発部門/運用(インフラ)部門/QA(品質管理)部門など職能別に部門が分かれている企業が多く見受けられました。

この組織形態においてはそれぞれの担当領域ごとに責任分界点があり、基本的には開発部門が開発/テストしたものをQA担当部門によるチェック(テスト)を通し、実際の運用部門に引き渡すという流れとなります。

従来型の職能別組織における、そのメリット／デメリットを以下にまとめます。詳細は次項で解説いたします。

<メリット>

部門ごとに担当/責任範囲が明確
担当者は自部門の業務に集中/特化できる
担当範囲についてのスキルに特化できる
部門内に閉じて最適化できる

<デメリット>

部門間の調整オーバーヘッドがかかる(= 顧客への価値提供までの時間増)
部門ごとの達成指標(KGI/KPI)が対立しがち
部門をまたがる問題の解決にも調整が必要

開発側と運用側の連携とは

従来型の職能別組織においては、それぞれの部門が各々の担当領域に注力できる、部門内で業務が閉じるために全体最適する場合と比べて最適化が行いやすい、担当領域が明確なため担当者に求める知識/スキルが定義しやすい(= 教育しやすい)といったメリットがあります。

もちろん逆にデメリットもあります。例えば部門間の調整に余計な時間を取られるといったものです。開発側の担当者がアプリケーションの機能要請によりWebサーバの設定ファイルなどインフラの変更を行いたい場合、運用部門に対して依頼/作業申請をして許可をもらう/結果を報告/結果を受けてQA部門が再チェックして本番投入といったプロセスが必要だったりすると、実際に本番環境に反映されるまでに時間がかかってしまうといった具合です。

そのほか、担当領域ごとに達成すべき指標(KGI/KPI)の方向性が異なる/対立することもあります。

例えば開発部門では短い期間で多数の機能をバグが少ない状態で提供すること、運用部門では安定稼働のために稼働率やアクシデント/インシデント発生数を減らすことを指標とした場合、迅速にデプロイしたい開発側と安定した運用のために変更は極力少なくしたい運用側とで対立してしまうということもあるでしょう。（もちろん実務ではここまで単純化した指標とせず、より上位レベルのKGI/KPIに合わせ部門間で調整したKGI/KPIを用いることが多いと思います。あくまで説明のためのイメージです。）

また、問題発生時の責任の所在についても揉めることが多い部分です。例えばアプリケーションのパフォーマンスが思ったほど出ないという問題ではどの部門が担当することになるのでしょうか？仮に開発側が調査したとして、調査の結果運用側にも問題があることが発覚した場合は調査工数はどちらの部門が負担するのでしょうか？部門の独立性が高いほど複数の部門にまたがる問題の解決には調整オーバーヘッドがかかることになります。

DevOps = 対立ではなく共通の目的に向けた協調

従来の職能型組織でも、全体的な企業としての目的は顧客(等)に対して価値を提供するという共通のものであるはずです。共通の目的を達成するため、部門ではなく組織としてもっと広い目でプロセスや評価基準などを設計することでお互いの協調を促すことが可能なはずで、その取り組みこそがDevOpsと呼べると思います。

もっと砕いて言うと、開発側から見て「インフラ側がもう少しアプリのことを考えて設定してくれればいいのに」とか、運用側から見て「アプリ側がこういう機能を用意してくれれば楽なのに」といった思いを実際に行動に移し組織的に取り組むことがDevOps活動の根本的な考え方/行動と言えるでしょう。

じゃあDevOpsは実際どうやったらいいの？

実際のプロセス構築やツール導入は組織の体制や成熟度などによって方法は様々ですが、まず重要な点としては「共通の目的を持つ」ことがあると思います。

DevOpsの場合は「ニーズに即したアプリケーションを提供し続ける」ことが大きな共通の目的となるかと思います。まずは部門間調整に起因するリードタイム削減など、部門横断的に共通の目的/指標を定義した上で達成のためのプロセスに落とし込むという作業が必要となります。

また、プロセスに落とし込むためにはプロセスの全体像を把握しておくことが必要不可欠です。全体のプロセスを把握しておくことで、個別のツール導入に際してもどの部分を担当するのかが明確になりツール選定や設定などに役立つと思います。

前述のWikipediaのページにDevOpsで用いられるツールの全体像を示した「DevOpsツールチェイン」の図が記載されていますのでここに引用しておきます。

(引用元: Wikipedia - DevOps)

この図を元にDevOpsで「ニーズに即したアプリケーションを提供し続ける」ためのプロセス/ツールの全体像についてご紹介いたします。

DevOpsプロセス全体像とツールチェイン

先ほどの図ではDevOpsのプロセスを以下のように分けています。

1. Plan(計画)

どのようなアプリケーションを製造するかという要件を決めるプロセスです。インフラや監視/モニタリングなどの各プロセス実装の設計についてもここで行うことが多いでしょう。

2. Create(製造)

コーディングなどを行ういわゆる開発を行うプロセスです。

3. Verify(検証)

主にテストプロセスです。アプリケーションが要件に即しているかの検証を行います。

4. Package(梱包)

アプリケーションを運用環境に配置するために必要なファイルや設定ファイルなどをまとめる(パッケージング)プロセスです。

5. Release(リリース)

アプリケーションを運用環境に配置するプロセスです。インフラの調達やデータ投入などのアプリケーションを動かすための設定なども含まれます。

6. Configure(設定)

アプリケーションが運用環境で安定して稼働し続けられるようにインフラの設定やアプリケーションのパラメータチューニングなどを行うプロセスです。

7. Monitor(監視)

アプリケーションが期待通りに動いているか、実際に稼働した結果を収集/保存するプロセスです。サービスの死活だけでなく、アクセス数や応答時間などのパフォーマンス指標の収集も行います。

8. Plan(フィードバック)

1.に戻ります。この時にユーザーからのフィードバックや各プロセスでの問題点、Monitorプロセスで得た指標を元に要件を再度練り直します。

Planから始まり、開発〜テスト〜デプロイ〜運用〜監視を経て再度Planに戻り、以後このプロセスを繰り返していく循環形式となっています。このプロセスを迅速に回すことで、施策をとりあえず試してみてフィードバックを得て改善/方向転換を行うといったトライ&エラーを行えるようになります。

それぞれのプロセスはシンプルに見えますが、実際にはこれらのプロセス導入は簡単ではありません。迅速にプロセスを回すことを考えると各プロセスにあまり時間を取られるようであっては困りますし、急いで開発することで許容できない範囲まで品質が落ちることも避けなければなりません。

例えばPackageについて取り上げると、迅速にプロセスを回すことで頻繁なソースコードの改修や差し戻しが発生することとなります。そうなった場合、人力で(例えばエクセルでのソースコード管理台帳などを利用して)ソースコードの整合性を保ったままパッケージングすることは面倒な作業となるでしょう。

もちろんこれらの作業は人力で行う必要は必ずしもなく、ツールをうまく使うことでプロセス導入が容易になります。

DevOpsの各プロセスを支援するツール群

近年DevOpsのプロセス実現のために、各プロセスをサポートしてくれる様々なツールが登場しています。DevOpsという言葉が使われる機会が増えてきている背景にはこれらのツールが存在するからという理由もあります。

例えば開発プロセスで言えば統合開発環境(IDE)や複数人の同時作業が可能なエディタ、開発用サーバを提供するvagrant、アプリケーションを環境ごとパッケージングして提供するDockerなどがあります。またテストプロセスにおいては自動テストのためのツールや様々なデバイスの仮想環境を提供してくれるサービスやCI/CDを行うためのツール/サービスが、パッケージプロセスにおいては前述のDockerやソースコードのバージョンを管理するgitやgitを活用したワークフローを構築できるGitHub/GitLabなどがあります。後続プロセスについても同様に様々なツールが存在します。

ツールがプロセス導入を容易にし促進する

最終的にはツールの導入が目的ではなく、DevOpsの各プロセスを導入することで「ニーズに即したアプリケーションを提供し続ける」ことこそが目的となりますが、ツールを導入することでプロセス実現が容易になりプロセス導入を促進する面もありますので、どのプロセスにどのようなツールがあるのかを把握して置くことはプロセス設計面からも大事だと思います。

各プロセスでのツール概要

各プロセスで利用するツールのうち、本連載で取り上げる予定のツールについてのご紹介いたします。
今回は主にWebアプリの開発を行う場合を想定してツールを選択しています。実際に本連載を参考にツール選定を行う際はアプリケーションの特性に合わせてツールの選定を行う必要があります(例えばモバイルを対象とする場合、各種デバイスのエミュレーションを提供するサービスを利用するなど)が、ツールが違ってもプロセスの全体像は変わりませんので本連載で扱うツールについての知識は十分活用できるものだと思います。

なお、各ツールは複数のプロセス範囲をカバーするものも多数あるため、プロセスと必ずしも1対1で紐づかない点にご注意ください。

開発環境

開発環境に関するツールとしてはIDEやエディタ、コンパイラやライブラリ管理/タスクランナーなど多岐に渡ります。
本連載ではDevOpsに焦点を当てるため、後続プロセスとの連携と密接に関わる部分として開発用サーバ関連のツールを中心に扱います。

Vagrant(開発者それぞれのマシン上に開発用サーバを構築)
Docker(アプリケーションと実行環境のパッケージング)

バージョン管理

ソースコードのバージョン管理ツールやバージョン管理ツールを利用したワークフローについて扱います。

git(バージョン管理システム)
GitHub + GitHub Flow

継続的インテグレーション/デリバリー

いわゆるCI/CDを行うためのツール/サービスを扱います。

Jenkins(オンプレミスのサーバにインストールして使う形式)
TravisCI(CI/CDを提供するSaaS)

リリース/デプロイ/構成管理

インフラの構築や、一歩進んでコードによるインフラ(Infrastructure as Code)実現のためのツールを扱います。

Packer(ゴールデンイメージの作成)
Terraform(クラウドなどに対しインフラ構築)
Ansible(サーバのプロビジョニング)

本連載では扱いませんが、この分野では大量のデータの投入や加工、本番稼働中のデータの移行といった作業が必要になる場合もあります。
もちろんそれらをサポートするツールも存在しますので必要に応じて調査してみてください。

監視/モニタリング

サービスの死活監視やシステムのパフォーマンス測定などのためのツールを取り上げます。

多数のツールがあるため、監視/メトリクス収集/インシデント管理/イシュートラッキング/ロギング/アクセストラッキングなどの各分野のツールを広く薄く取り上げる予定です。

その他/合間を埋めるツール

DevOpsツールの構築に欠かせない、クラウドベンダーの提供するAPIを使うためのツールや、プロセスの自動化/円滑化に欠かせないチャットツールなどについて扱います。

curlコマンド(APIの利用方法について)
slack(チャットツール)
slack BOT(プロセス自動化や属人性を排するためのBOT作成)

各ツールの詳細については以降の連載で随時扱います。

まとめ

当記事ではDevOpsの入門として従来型組織がどのような問題を抱えているか、DevOpsでそれらの問題をどう解決するか、DevOps導入にあたりどのようなツールがあるのかについて概要を扱いました。

DevOps = 開発側と運用側が協調して「ニーズに即したアプリケーションを提供し続ける」ことを目指す
従来型組織では開発側と運用側は対立しがち
DevOps導入には共通の目標を持ち、目標達成のためにプロセスに落とし込む必要がある
DevOpsプロセスはPlanから始まる循環構造、この循環を早く回すことを目指す
DevOpsプロセスを支援/導入を促進してくれる様々なツールがある

次回以降の連載では各プロセスにどのようなツールがあるのか、ツールを用いることでどのようなことができるのかを順にご紹介していきます。

以上です。