PaaS、Docker、OpenStack――すでにここまで実現できる“変化に強い”インフラの作り方：特集：国内DevOpsを再定義する（3）（2/3 ページ）

[編集部,＠IT]

DevOpsに不可欠な、インフラの「仕組み」を整理する

編集部　では高頻度でサービスを改善していくR＆D的な開発を行う上で、インフラの運用アプローチは今後どうあるべきなのでしょうか？ さまざまなテクノロジが出てきていますが、ここであらためて整理いただけますか？

中井氏　まず、Dockerによるアプリケーション実行環境のイメージ化が大きな役割を果たします。

参考リンク：アプリ開発者もインフラ管理者も知っておきたいDockerの基礎知識（＠IT）

　開発の世界では、アジャイル開発やCIツールにより、アプリケーションを継続的に拡張／改修していくことが可能になりました。しかしながら、完成したアプリケーションを継続的に本番環境にデプロイするのは簡単ではありません。図1に示した「開発と運用の越えられない壁」は、現場のエンジニアであれば、誰もが感じたことがあるでしょう。

図1　DevOpsを阻む「開発と運用の越えられない壁」

　この壁の背後には、ドキュメントのやり取りを含めた複雑なプロセスや人手を介した作業が隠されています。この壁を乗り越えて、本番環境のアプリケーションを迅速、かつ、安全にアップデートしていくには、アプリケーションデプロイにおける手作業を徹底的に排除して、自動化していく必要があります。

編集部　それを実現するプロセスとしてCD（Continuous Delivery／継続的デリバリ）が必要となるわけですね。

参考リンク：継続的デリバリ／デプロイを実現する手法・ツールまとめ（＠IT）

中井氏　一般的な企業システムの運用を振り返ると、本番環境のアプリケーションをアップデートするのは、手順書の作成とレビューから始まる「一大イベント」でした。しかも、どれほど念入りに準備しても、必ず、次のような事態が発生します。

1. バージョンアップしたアプリケーションがうまく動かず、開発チームに対応策を問い合わせる
2. バージョンアップの手順が間違っていることが判明して、その場で新しい手順を試してみる
3. アプリケーションに必要なライブラリのバージョンが古いことが分かり、ライブラリのアップデート作業を開始する
4. 必要なバージョンのライブラリがどうしてもインストールできず、その場でアプリケーションの設定を変更し始める
5. 翌日の朝になってもバージョンアップが終わらない

　これは少しばかり誇張された例ですが、実際のところ、このやり方には、どこに問題があるのでしょうか？ それは、開発者が「アプリケーションをビルド／テストする手順」と「本番環境にアプリケーションを導入する手順」が切り離されていることです。

　CIを行っているプロジェクトであれば、テストサーバーへのアプリケーションの導入／テストは自動化されていますが、Dockerのコンテナーイメージを利用すれば、ここでテストされた「確実に動作する環境」をイメージ化して、そのまま本番環境に展開することができます。つまり、バージョンアップのたびに手順書を作成して、手作業でデプロイする必要がなくなるのです。このようにして、アプリケーションのバージョンアップを「一大イベント」から、「簡単で安全な作業」に変えることが、DevOps実現のカギになると言えます。

　Dockerを利用したDevOpsの環境は、概念的には図2のように表現できます。開発済みのアプリケーションをイメージ化して、専用のレジストリで共有しておき、それを本番環境に自動配信していきます。本番環境に必要なのは、Dockerが導入されたサーバーだけです。OpenStackなどのIaaS基盤があれば、このようなサーバーを追加することも自動化できるので、「新規アプリケーションの本番環境を新たに設計／構築する」という手作業はもはや不要になります。

図2　Dockerを利用したDevOpsのインフラ環境（概念図）

編集部　Webサービス系企業では、このような仕組みを独自に作り上げている例もありますね。

中井氏　そうですね。例えば、米グーグルが膨大な数のコンテナーでアプリケーションを自動配信しているのは有名な話です。ここで重要なのは、コンテナーの数ではなく、その配信が自動化されているという点です。Webサービスとして提供されるアプリケーションは、知らない間に新機能が追加されていることがあります。これは、複数のコンテナーで並行稼働するアプリケーションを、新バージョンへと順番に切り替えていく仕組みを用いているからでしょう。

「アプリケーションの開発とデプロイ、運用を統一的なプロセスで連携することがDevOpsの本質ですから、インフラの構築／管理もそのような視点で捉える必要がある」

　最近では、このような仕組みを実現するためのOSSも充実してきました。米グーグルのエンジニアが中心となって開発している「Kubernetes」を利用すると、複数のDockerサーバーを束ねて、イメージの配信を自動化することが可能になります。あるいは、米レッドハットが開発する「OpenShift」では、Kubernetesの機能をベースに、イメージの開発部分を支援する機能を追加することで、図2と同等の環境をワンストップで構築することも可能です。DevOpsを安全に実現するインフラのテクノロジは急速に進展しているのです。

参考リンク：グーグル主導のDockerコンテナー管理フレームワーク「Kubernetes」にマイクロソフトやレッドハットが参加（＠IT）

　このような環境では、開発、テスト、サービスの3種類の環境を統合的に管理することが可能になります。性能要件やセキュリティ上の理由で、環境ごとにサーバーやネットワークを分離する必要はあるでしょうが、少なくとも、それぞれの環境を個別に設計して、別々のチームが構築／管理する必要はありません。アプリケーションの開発とデプロイ、運用を統一的なプロセスで連携することがDevOpsの要件ですから、インフラの構築／管理もそのような視点で捉えるべきでしょう。

「変化に強いインフラ」で、DevOpsを支える手段はさまざま

　ちなみに、コンテナー技術の話をしていると、「コンテナーはハイパーバイザーの代替であり、仮想マシンやIaaS基盤は不要になる」という議論を耳にすることもありますが、これはまったくの誤解です。Dockerにおけるコンテナーの役割は、「イメージ化されたアプリケーションの実行環境を提供すること」です。よって、OpenStackなどを利用して、Dockerが稼働する仮想マシンを自動構築した後、その上でコンテナーを活用するといった合わせ技は積極的に活用するべきでしょう。

　最近のOpenStackには、ベアメタルサーバーをプロビジョニングする機能もあります。ハイパーバイザーのオーバーヘッドを排除したい場合は、OpenStackを用いて、KubernetesやOpenShiftの環境をベアメタルサーバー上に自動構築するという方法も考えられます（図3）。

図3　OpenStackとDocker／Kubernetes／OpenShiftを組み合わせた構成

　パブリッククラウドとプライベートクラウドの使い分けには、さまざまな議論がありますが、どのような環境でも利用できるのが、コンテナーの強みです。環境をイメージ化することで、クラウド間でのアプリケーションの移動も容易になります。

　このように、真の意味で変化に強いインフラを用いて、DevOpsという新しいプロセスをどのように実現するのか、今まさに、インフラからボトムアップの視点でDevOpsを考えるタイミングがやってきたと言えるのではないでしょうか。ただし、ツールだけに注目するのではなく、それらを用いて実現するべきプロセスへと視点を広げることが大切なことは言うまでもありません。