DevOpsのフローとDevOpsの実践に必要な技術

はじめに

みなさんはDevOpsを実践していますか。実践しているとしても、実践していないとしても、何を基準にDevOpsを実践しているか、していないのかを判断したのでしょうか。

実は、何を実現すればDevOpsと呼べるのか、明確な答えはありません。あえて言えば「開発チームと運用チームのコラボレーションを強化し、品質の高いソフトウェアを頻繁にリリースする」というのが最大公約数的なコンセプトであると言えます。しかし、どのような方法でこれらのコンセプトを実現していくのかを具体的に示した資料は多くありません。実際、このコンセプトを実践するためには組織の文化改革が必要となったり、ビジネスのあり方も変える必要が出てきたりと多くのことを考慮しなければならず、組織により対応策が異なってきます。

ただし、組織により対応策が異なるとすると、自分たちがDevOpsを実現するためにすべきことを理解するためには時間がかかってしまいますし、その答えを得られない多能性も十分にあります。そうなるとDevOpsを始めることすらままなりません。日本仮想化技術では文化や組織のあり方からではなく「習うより慣れろ」のアプローチで技術面からDevOpsを実践していくのDevOpsサポートサービスを提供しています。

文化や組織のあり方はもちろん重要ですが、そこで足踏みしているだけでは前に進むことができません。そこで、本連載ではそのような視点から文化や組織の話をいったん切り離し、DevOpsを実現するために必要となる技術を紹介していきます。そして、それらの技術を活用してエンジニアがDevOpsを実践するための環境構築とその運用法について学んでいただきます。

DevOpsの一連の流れと技術

DevOpsでは、よくその一連の流れをインフィニティループで表現されます。機能の企画から開発、ビルド、テスト、デプロイ、リリース、運用、監視、そしてフィードバックがあり、それがまた企画に繋がっていくと言ったループです。DevOpsではこのループを開発チームと運用チームで協力しながら実行し、品質の高いソフトウェアをリリースしていくわけです。

DevOpsのインフィニティループ

このループを回し続けるためには、前述した通り組織の文化やビジネスのあり方を変えるだけでなく、それに加えて適切なツールを利用する必要もあります。DevOpsのループを回すためには何か1つツールを導入すれば良いわけではなく、それぞれのフェーズに合った適切なツールを組み合わせて導入し利用する必要があります。もちろん、適切なツールの組み合わせはそれぞれの状況によって異なり、これが正解という組み合わせはありません。そのため、本連載では日本仮想化技術が支援する案件でよく使われるツールを例に、DevOpsで活用される技術を紹介します。

まずは、全体像を掴むという意味で、今回はDevOpsを実現するための技術を俯瞰的に見ていきます。

実行環境

実行環境は開発するアプリケーションを配置し実行する環境です。DevOpsではターゲットとなるアプリケーションの種類は問いません。しかし最もDevOpsと相性が良いのはコンテナ技術を使ったWebアプリケーションと言えます。そのため、本連載ではコンテナ技術を使用したWebアプリケーションを題材とします。

コンテナ技術は仮想化技術の1つで、軽量かつ高い可搬性が特徴です。コンテナ技術を使うことで開発環境から本番環境まで一貫して同じ環境を使うことができるため、環境依存のトラブルを大幅に減らすことができます。コンテナ技術は仮想化技術の種類を表す言葉で、実際にコンテナを実現するための技術にはいくつか種類があります。最近では「Docker」「Kubernetes」といった技術がデファクトスタンダードとして利用されています。

Dockerはコンテナのイメージを作成し、実行するプラットフォームです。単にコンテナのイメージ作成や実行をするだけではなく、それらを容易に実行するための便利な機能も備えています。

また、Kubernetesは作成された複数のコンテナを管理するオーケストレーションツールです。一般的にシステムは複数のコンテナで構成され、スケーリングなどの観点からコンテナのインスタンスを複数実行します。これらの調整しながら最適な実行環境を作るのがKubernetesの役割です。 そして、これらのコンテナ技術は主にクラウド上で実行されます。AWSやAzure、GCPといったクラウドプロバイダーはこれらのコンテナ技術を利用できる環境が用意されています。

開発環境

開発環境はアプリケーション開発者が利用する環境です。開発環境の定義としては、開発時に開発者が使用する環境全般として捉えていきます。狭義の開発環境の定義ではコードを書くツールという意味もありますが、ここでは広義の開発者が使用する環境全般として紹介していきます。

まず、チームでコードを書く際に欠かせないのがソースコード管理の概念です。最近では分散バージョン管理システムを使ったソースコードの管理が一般的になってきています。分散バージョン管理システムは、単にソースコードのファイルを共有することだけが目的ではありません。複数のメンバーがコーディング作業を並行して実施しながら、開発されたコードが安全に統合されるような仕組みを提供しています。

また、狭義の開発環境である開発ツールも重要な技術です。かつてはテキストエディターでコードを書き、CLIからソースコードをビルドするなど、それぞれの作業で異なるツールを使用するのが一般的でした。しかし、最近ではコードを書くだけではなく、分散バージョン管理やビルドツール、テストツール、デバッグなどのさまざまな作業を1つのツールから実行できる統合的ツールを使用することが一般的です。

もちろん、コードを書いたらそれで終わりというわけではありません。書いたコードが正しく動作するための検証環境が必要となってきます。検証環境は開発したアプリケーションを動かしてみるだけではなく、スクリプト化されたテストを実行する場合にも使用することがあります。コンテナ技術を使用するシステムでは、本番環境と同じコンテナイメージを作成し、本番と同じ環境でアプリケーションの動作を確認します。

CI/CD

開発者がコードを書いた後、アプリケーションのビルドやテスト、デプロイを自動で行う一連の仕組みが「CI/CD」です。CIは継続的インテグレーション(Continuous Integration)を指し、CDは継続的デリバリー(Continuous Delivery)を指します。CI/CDはDevOpsのループの中ではDevからOpsへの流れの中核的な技術となり、繰り返し行う作業の自動化が目的となります。

CI/CDの中で、アプリケーションの統合を目的としたビルド、テストといった作業を自動化するのがCIです。CIではソースコード管理ツールにコードがプッシュされたり、マージされたりといった操作をトリガーに、CIツールがビルドやテストを自動的に実行します。このCIツールにどのような処理をどういった順番で自動的に実行させるのか定義したものを「CIパイプライン」と呼びます。プロジェクトとしてどのようなCIパイプラインを定義し、運用していくかが、開発プロセスを自動化するための重要な作業となります。

また、統合されたアプリケーションを実行環境にデプロイしていく必要があります。これがCDの役割です。先ほどCDは継続的デリバリーと紹介しましたが、実はもう1つ別の定義があります。それが「継続的デプロイメント(Continuous Deployment)」です。

継続的デリバリーはアプリケーションをリリース可能な状態にまでデリバリーし、最後に実行環境へリリースするのは手動で行う手法です。一方、継続的デプロイメントはアプリケーションを実行環境にリリースするまでを含めて自動化する手法です。どちらを選択するかはアプリケーションの位置付けや、開発プロセスにおける考え方によって変わります。

さらに、アプリケーションをデプロイする方法としても2つの考え方があります。1つはCIパイプラインの中でデプロイまで行ってしまう方法で、もう1つがアプリケーションのパッケージやコンテナイメージの更新を検知して自動的にデプロイを行う方法です。これらは前者を「CIOps」、後者を「GitOps」と呼んでいます。

インフラ構築

先ほど実行環境としてDockerとKubernetes、クラウドについて紹介しました。コンテナは様々な環境で一貫して同じ設定を使えますが、コンテナを実行する環境はそれぞれの目的に応じた設定が必要です。従来であれば、このような環境構築の作業は手順書に則ってエンジニアが手作業で行うことが一般的でした。しかし手作業で環境を構築する場合、いくら手順書に従って作業をしてもヒューマンエラーを防ぐことはできません。そこで最近使用されるようになったのが「IaC(Infrastructure as Code)」という技術です。

IaCはインフラの設定をコード化して管理し、記述されたコードに従って自動的に構築する技術です。そのため、何度作業をしても手作業のようなヒューマンエラーが発生せず、同じ結果になります。また、一度しか構築しないような環境でもIaCはその効果を発揮します。

ヒューマンエラーが発生しないということは、構築した環境に問題がある場合にはコードに問題があります。手作業で構築した場合は手順書に問題があるのか、作業時にヒューマンエラーが発生したのかの切り分けが必要になりますが、IaCを利用している場合はそのコードのみを検証するだけで良くなります。

運用監視

アプリケーションが本番環境にデプロイされたらそれで終わりではありません。運用しているアプリケーションやその実行環境が正しく機能しているかを常に監視する必要があります。これが運用監視です。運用監視の必要性はDevOpsに限らず、どのようなシステムでも同様ですが、DevOpsにおいては「開発チームと運用チームのコラボレーションを強化する」という観点から、従来の運用監視よりも積極的に障害の可能性を検知し、開発チームにフィードバックしていくことが求められます。

まず、監視の観点ではどのコンポーネントをどのメトリクスで監視するかが重要になります。コンポーネントはアプリケーションだけでなく、ネットワークやハードウェア、クラウドのサービスステータスなども対象となります。これらの複数のコンポーネントからログを収集して分析することで監視します。このようなログを分析して管理するには、統合型の監視ツールを使用するのが一般的です。統合型の監視ツールを使うことで、様々なコンポーネントから取得してきた情報を一箇所で分析し、運用状況を判断できます。また最近では障害が発生してからアラートを出すのではなく、障害発生の兆候を掴むことで障害が発生する前に対応するといった積極的な運用監視も行われています。

このような形で運用中のシステムの状態を把握し、問題が発生した、もしくは発生しそうな場合は開発チームにフィードバックし、対応を依頼する必要があります。ただし、なんでもかんでもフィードバックをして対応してもらうわけにもいきません。問題の原因と影響を分析し、対応するものしないもの、開発チームに依頼するもの、運用チームで対応するものといった切り分けを行う必要があります。

残念ながらこの部分に関しては未だに人間の力に頼る必要がありますが、対応するとなった場合には月次ミーティングなどで共有していては「頻繁にリリースする」メリットが消えてしまいます。そこで、イシュー管理ツールやタスク管理ツールを使って発生した問題の情報を即座に共有しつつ、対応を依頼するという方法が採られるようになりました。最近では統合型監視ツールからこのようなイシュー管理/タスク管理ツールと連携して簡単に情報を収集し、フィードバックできるような仕組みもあります。