なぜ、DevOpsの実践にツールが必要となるのか

DevOpsとは

DevOpsは開発(Dev)と運用(Ops)が“いい感じ”にコラボレーションすることで開発サイクルを高速に回すための考え方や仕組みのことです。

DevOpsの考え方を最初に提唱したのはFlickrのスタッフが発表したこちらのスライド「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」であると言われています。このスライドでは「開発と運用の関係性」や「どのようにコラボレーションしていくのか」が書かれています。冒頭で「“いい感じ”に」と表現したのは、誰が何をするとDevOpsであるかという定義はなく、お互いリスペクトし合って協力しましょうという曖昧な言葉だからです。

開発サイクルとは「コーディング → テスト → パッケージング → デプロイ → モニタリング → フィードバック → コーディング → …」というループのことを言います。「DevOps」で検索すると8の字の無限ループが必ず出てくるので、図を見てもらう方が理解が早いかもしれませんね(図1)。

図1：開発サイクルの図

開発サイクルを高速に回すことで、いったい何が起こるのでしょうか。

例えば、1つの機能を開発しているとしましょう。コーディングが完了したらテスト、デプロイと続き、顧客へと提供されていきます。顧客は新機能を即座に試し、機能改善やバグなどのフィードバックを通知します。そのフィードバックを受けて再度コーディングからサイクルが回っていきます。1つの機能を繰り返し修正し顧客に提供することで、顧客のニーズとのミスマッチを防ぎ価値を高めていきます。

このように、小さな機能を開発サイクルに載せて何度も繰り返し開発していく手法を「アジャイル開発」といいます。これを実現するには、DevOpsのようなサイクルを回すための仕組みが必要なのです。

DevOpsにツールが必要な理由

先に紹介した「10+ Deploys Per Day」のスライドと内容が重複してしまいますが、DevOpsとツールの関係性について解説します。

元々、開発と運用は「Dev vs Ops」でした。開発はアプリケーションに機能を追加することが仕事なので、頻繁に変更を加えたいと考えています。一方で運用はサービスを安定稼働させるため、アプリケーションや実行環境に変更を加えることを嫌います。変更を加えたことでサービスが停止するかもしれないからです。

では「Dev vs Ops」を「Dev and Ops」に変えるには、どうすれば良いでしょうか。それには「変更のリスクを下げ、障害が発生しても復旧する能力を高める」ことです。変更のリスクを下げるにはアプリケーションのテストが確実に実施され、デプロイが容易でなければなりません。また、復旧する能力を高めるには問題を検知し、ロールバックや問題の特定が容易でなければなりません。これらを自分達で作り上げていくのはとても大変です。アプリケーションを開発している場合ではありません。

そこで、DevOpsではツールが必要不可欠となってきます。例えば、1,000台以上のサーバーを手動で管理するのは非現実的ですよね。1つのバグのせいで1,000台を手動で入れ替えなければならなくなったら、と考えるとゾッとします。また、そのバグを出してしまった人は精神的に辛い思いをすることでしょう。これでは、とても安心してデプロイできません。

別の例えで、ソースコードの管理を想像してください。コピー＆ペースト、またはファイルのリネームやコピーに頼っていたらどうでしょうか。バージョン管理がされていなければ、どの変更でバグが生じたのか分かりません。複数人で開発している場合は、それぞれの変更を1つに統合することも難しいでしょう。これらを効率的に管理運用するため、DevOpsではあらゆる作業でツールを使用するのです。

DevOpsに必要なツール

DevOpsでは「CI/CD」「コンテナ」「クラウド」「IaC」といったツールを上手に連携させることで煩わしい作業を自動化し、開発・運用それぞれの作業負荷を軽減します。つまり、開発は開発業務に、運用は運用業務に専念できるようになります。

ここで、各ツールがどのような機能を持つのか、簡単に見ていきましょう。

CI/CD

CIは「Continuous Integration」(継続的インテグレーション)、CDは「Continuous Delivery」(継続的デリバリー)の略です。

継続的インテグレーションとは、複数人で開発しているソースコードを継続的に統合(インテグレーション)することをいいます。統合するにしても、バグのあるコードを統合するわけにはいきません。必ずテストやビルドが必要です。つまり、CIでテストやビルドを自動化することで開発者の手間を省き、かつ品質を担保しようというのが狙いです。

また、継続的デリバリーとは、変更のあったソースコードを継続的にビルドし、成果物をデプロイ可能な状態にしておくことをいいます。コンテナであればレジストリに、パッケージであればリポジトリにプッシュするところまでが継続的デリバリーです。

同じくCDと省略されるもので「Continuous Deployment」(継続的デプロイメント)という考え方もあります。これはデプロイまでを自動化します。例えば、開発環境などでは変更を即座に反映して動作確認をしたいことがありますよね。そのようなときに使います。

コンテナ

アプリケーションの動作に必要な全ての依存関係を1つにパッケージングしたものです。ここでいうコンテナとはアプリケーションを動かすことに特化した「アプリケーションコンテナ」を指します。コンテナはビルドが簡単で、起動が早く、環境にも依存しないため、テスト・ビルド・デプロイを繰り返す開発手法に向いています。また、コンテナを効率的に管理・運用するためにKubernetesやマネージドコンテナオーケストレーションもDevOpsには必要な構成要素となっています。

クラウド

パブリッククラウドの「AWS」「Google Cloud」「Azure」やプライベートクラウドの「OpenStack」を指します。クラウドはボタン1つでリソースを確保でき、また、APIが公開されているため自動化を容易にします。DevOpsでは自動化が重要になってきますので、オンプレよりも相性が良いと言えるでしょう。

IaC

「Infrastructure as Code」の略で、インフラを手作業で構築するのではなく、コードを使って管理運用するための手法です。クラウドを管理するためにもIaCが使われます。インフラをコードで管理することにより、環境毎に差が生れにくくなります。一切の手作業を排除すれば、同じ環境をいくつでも構築できます。

本連載のゴール

本連載では、実際に筆者が使用しているツールを題材に、DevOpsを実践するためのツールの使い方について解説していきます。DevOpsの構成要素を1つずつ構築していき、連載を通してDevOpsの開発サイクルが回せるようになるところを目指します。

図2：DevOpsにおける開発プロセスの例

なお、本連載で使用するツールとしてはOSSを選定しています。基本的に無料、または条件によっては無料で使えるものを取り上げて解説していきますので、安心して実践できると思います。

おわりに

今回は、これから始まる本連載の前提知識として「DevOpsとは何か」「DevOpsにツールが必要な理由」などを解説しました。次回からは、早速ツールのセットアップ方法や実際の使い方について解説していきます。1つのツールにつき数回にわたって深掘りしながら解説していきます。実際に手を動かしながら学習していくハンズオン形式になっていますので、ぜひご期待ください!