OpenStackは「どこで？」「何のために？」使えばいいのか？：インフラエンジニアが、いま成し遂げなければならないこと（2/3 ページ）

開発側から矢継ぎ早に来る要請、経営からの厳しいコスト削減要求などにスピーディかつ確実に応えながら、ビジネスを支えるためにはクラウドをどこに、どのように適用すれば良いのか？ OpenStackの正しい適用法を解説する。

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

大事なのは標準化を生かす思考

　では、OpenStackやクラウドの前提を踏まえた上で、どのようなシチュエーションで、どのような箇所に、OpenStackの機能である「抽象化による標準化」「判断の自動化」を適用したときに効果が発揮されるのか考えてみましょう。といっても難しいことは考える必要はありません。標準化は大きな範囲で適用してこそ効果を発揮できることに疑問を持つ方はいないでしょう。つまり、OpenStack上でよりたくさんのシステムを標準化して動かしていけばよいのです。この考え方はOpenStackだけではなく、一般的にクラウドを活用する場合にも当然当てはまります。

　図2を見てください。従来手動で行っていた業務をOpenStack上に移行する例を2つのパターンで比較しています。パターンAでは、従来の手順のみを自動化していますが、パターンBではシステム構成の標準化まで行っています。どちらが仕事量を少なくできるかは一目瞭然だと思います。

図2　OpenStackの適用範囲《クリックで拡大》

　APIを活用して自動化を行うには、当たり前ですが自動化の仕組みを作り込む必要が出てきます。パターンAの方式はシステムごとに追加の作り込みが発生してしまい、仕事量が増えてしまう可能性があります。よく「うちのシステムは5年に1回しか構築はやらないから、自動化しても意味ないんだよね」という話を聞きます。まさに、その通りでパターンAのようなやり方で自動化を実現してもほとんど効果はないでしょう。

　パターンBを行えば仕事量を大幅に減らせるというのは、誰でも理解できることだと思います。しかし、実際に検討した際に障壁になるのが、「いや、システム構成は画一的じゃないから、システム構成の標準化は困難では？」、もしくは「要件を無視してシステム構成を標準化すれば無駄が多くなる」という意見です。これを解決するのは簡単です。

　まず「システム構成の標準化が困難」という部分ですが、これは技術的に解決可能です。OpenStackや各種クラウドサービスでは、自動化（テンプレート化）を行うためのオーケストレーション機能が標準や外部ツールとしてサポートされています。OpenStackでは標準で「Heat」というコンポーネントがこの機能を提供します。

参考リンク：OpenStackコンポーネントが担当する機能（＠IT）

　ここで作成できるシステム構成を自動化するテンプレートは、従来のサーバ仮想化のテンプレートに比べてさらに便利になっています。図3に簡単なイメージを示します。

　例えばHeatのテンプレートでは、システムの構成をYAML形式でデータ構造として記述していきます。この中では各役割のサーバの台数を変数として扱うことができるため、システムに応じて与える変数を変化させるだけで多様なシステム構成に対応できるようになります。

　もちろん変数化できるものはサーバ台数だけではなくスペック（フレーバー）など、ほぼ全ての項目を変数化できます。大規模な環境では1つのテンプレートのみで全システムを賄うことは困難ですので、こういったテンプレートを数種用意することになりますが、これだけでも劇的にシステム構築の仕事量を削減できます。

　Heatのテンプレートは人が変数を変えて実行することも可能ですが、「Ansible」などの外部ツールから条件に合わせて変数を自動生成して実行することで、さらなる自動化を実現できます。また、これらの外部ツールを使って複数のテンプレートを連携させることで、より高度な使い方を、より簡単な操作で実行できるようになります。

参考リンク：いまさら聞けないOpenStack〜よく知られた「常識」と知っておくべき「常識」（＠IT）

　このようなテンプレート（データ構造）を作成するには、当然ながらOpenStackの知識が必要であるのに加え、自社のシステムパターンを把握した上で、「何をパラメーター化して何をしないのか」という見極めが重要なポイントになります。この「見極めをした上でテンプレートを作成するスキル」は、今後のITインフラエンジニアに求められる1つの重要な要件となります。

図3　オーケストレーションによる標準化《クリックで拡大》

　そして「無駄が多くなる」という部分では、先に前提として挙げた「リソースは十分に安価になった」という思考が重要になります。確かに標準化することで、ワークロードに応じたきめ細やかな構成のカスタマイズができなくなります。そのため、最大公約数的な要件を満たすために大きめのリソースを割り当てることになり、全体としてリソース消費の無駄が多くなってしまいます。ある程度の無駄は先ほどのテンプレートの変数化で回避できますが完全ではありません。

　ここで考えなければならないのは、「安価なリソースの無駄を削減することに労力を費やすのか」「ある程度の無駄は許容することで、より高額の人件費を削減するのか」という点です。

　システム構成の要件確認から作業までを行うために多大なコストと時間がかかることは、実際にシステム開発に携わる方であれば実感できると思います。今後ますますITが活用され、利用されるリソースが増えていく状況下において、優先すべきはサービス／システム開発の要求に迅速に応えるITインフラであり、わずかな無駄を排除するためにコストを費やすことではありません。

　もちろん無駄をそのままにしておいてよいということはありませんが、この問題には全体最適化が終わった後に、個々の部分最適を行えば良いのです。優先すべき、より重大な「仕事量の削減」を先に解決することが重要なのです。