OpenStackで激変するシステム開発・運用 “抽象化”が実現する「究極の自動化」とは：特集：OpenStack超入門（3）（1/3 ページ）

前回はOpenStackの活用ポイントと、今後のシステム開発・運用に与える影響――特に自動化にフォーカスして紹介した。今回は日本OpenStackユーザ会 会長の中島倫明氏が、「OpenStackによる自動化の仕組みと実施法」を分かりやすく解説する。

[中島倫明，日本OpenStackユーザー会 会長/伊藤忠テクノソリューションズ株式会社]

「80％の自動化」と「100％の自動化」はまったく違う

　前回「いまさら聞けないOpenStack 〜よく知られた「常識」と知っておくべき「常識」の解説にもあるように、現在も多くのシステムにおいて「全体の80％前後の自動化」は実現可能だといえます。

　数値で見ると「80％でも十分じゃないか？」という気になりますが、「100％の自動化が実現された環境」と、「80％止まりの環境」の間には越えがたい溝が存在しています。なぜならば、たった20％であっても人間が行う作業の質は、作業を行う人間のスキル、モチベーション、その作業を行う背景（緊急度、重要度など）といったものに大きく左右されるからです。どんなに完璧な手順書があっても、作業者はそれを読み間違えるかもしれませんし、実施したつもりでスキップしてしまうかもしれません。

　このような不確定な要素を持つ作業の精度を上げるために、二重チェック、手順書レビューといった関連作業が積み重なり、結果として膨大な工数が必要となります。これは手動の割合が10％でも、5％でも人手が介入する以上、あまり事情は変わりません。今後、ITを活用した企業の競争力確保が進む中で、このような運用体制を続けていくとどうなるのか、それは火を見るより明らかだと思います。

　では、われわれはどうしていけば良いのでしょうか？ この一つの答えとして「OpenStack」があります。OpenStackはこれまで人手の介入が不可欠であった、ITインフラに関連する作業を自動化するための機能を提供してくれます。今回は、この自動化をOpenStackがどのように実現しているのかを詳しく見ていくことにしましょう。

OpenStackの自動化を支える考え方

　初めに答えを書いてしまうと、OpenStackが実現する自動化は、“抽象化”によって支えられています。この抽象化にはさまざまな要素が含まれ、仮想化もその要素の一つです。

　よくOpenStackの話を初めて聞いた人が、「あぁ、OpenStackってサーバー仮想化のOSS版なんですね」という“誤解”をしてしまうケースがあります。確かにOpenStackとサーバー仮想化は、典型的なユースケースの一つのパターンとして存在するため、このように理解してしまうのも無理はないのですが、実はOpenStackにとってのサーバー仮想化は、森の中の木の1本であり、本質的な部分ではありません。

　では、OpenStackは何をしてくれるソフトウェアなのでしょうか？ ここで、OpenStackを横のレイヤーに分割して機能ごとに見るのではなく、縦に分割してみます。するとOpenStackが持つ機能は3つに分類することができます。

1. 論理的なITインフラのデータモデルを定義する
2. データを操作する標準的手段を提供する
3. データを現実世界へ落とし込むための機能を提供する

　何やら急に話が難しくなってしまいましたが、この話は現在のインフラ、つまりOpenStackがない状態のインフラと対比して考えていくと分かりやすいと思います。図1を見ながら以下の説明を読んでみてください。

図1　OpenStackの抽象化《クリックで拡大》

1.論理的なITインフラのデータモデルを定義する

　まず「論理的なITインフラのデータ構造を定義する」というのは、いわばITインフラの設計書のことです。インフラエンジニアの皆さまであれば、「このサーバーのNICの1番目と、このスイッチの5番ポートを接続して」という図を、「Microsoft Excel」や「Microsoft PowerPoint」で書いたことがあると思います。これまでの設計図では、それを描くエンジニアによって設計書に記載される粒度は異なっていたと思います。例えばAさんが書く設計書には、配置するサーバーが接続するVLAN IDまで書かれているのに、Bさんが同じものを作ると書かれていない、といった具合です。

　OpenStackでは、このような差を排除するために、設計書の内容を厳密なデータ構造として定義して、データベースで管理します。このデータ構造を使って設計図を描くことで、均一で理想的な設計図を描くことができるのです。

2.データを操作する標準的手段を提供する

　次に、「データを操作する標準的手段を提供する」というのは、設計書を描くための手段を提供する、というイメージです。例えば、Aさんは設計書を書くときにサーバーを「○」で表し、ネットワーク機器を「△」、ストレージを「□」としています。しかし、Bさんはサーバーを「△」、ネットワークを「□」、ストレージを「◇」とするかもしれません。さらにこれらの接続を表すのに、Aさんは「直線・破線」でつなぎ、Bさんは「曲線・二重線」でつなぐということがあるかもしれません。

　これではせっかく厳密なデータ構造が定義できても、意味がありません。そのため、OpenStackでは、理想的な設計図を描くための統一的手段が提供されています。それがOpenStackのAPIです。このAPIを使って、設計図を描くことで、誰がどのように操作しても同じ結果が得られるようになります。

3.データを現実世界へ落とし込むための機能を提供する

　ここまでの内容は、OpenStackが定義するデータ構造と、そのデータの操作についての話なので、ここでいくら理想的な設計図を描いても、現実世界には何も影響がありません。通常のインフラでも、設計書を元にインフラ構築の作業が必要になりますが、ここはその実作業を担当する機能になります。いわば作業手順書で、OpenStack上で定義されたインフラ設計図を、現実の機器やソフトウェアへ反映する機能です。

　OpenStackではこの機能を、ドライバーやプラグインという形で提供しています。一部を紹介すると、サーバー仮想化にはKVM/libvirt用ドライバーやXen用ドライバー、ネットワークであればOpen vSwitch用や商用スイッチ用、ストレージであれば、「Ceph」や「Gluster」といったOSS向けのものから商用ストレージ用ドライバーといったように、実に多数のドライバーやプラグインが存在しています。現実世界のインフラは多種多様ですので、OpenStackで環境を作る際はこのドライバーに何を選択し、どう組み合わせて利用していくのかがポイントとなります。

　つまり、OpenStackの抽象化とは、「設計書の書き方」「設計書」「設計書から作られる手順書」だということになります。これらが抽象化されることで初めてインフラの自動化が可能となります。先に記載した「OpenStackはサーバーの仮想化の延長ではない」というのはここから来ています。サーバー仮想化は、OpenStackが持つドライバーやプラグインの一つなのです。

　また、ここでいう“抽象化”という言葉は「インフラの標準化」と言い換えることができます。標準化によって手順の煩雑さが解消され、効率化が可能となることは皆さまも既にご存じだと思います。そのインフラの標準化をとことん追求し、プログラムからの自動操作さえも可能としてしまうレベルまで引き上げたのがOpenStackなのです。