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

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

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

OpenStackの自動化例

　では最後に、従来の環境とOpenStackを使った場合で、運用にどのような差が出てくるのかを簡単に紹介します。あなたが会社のインフラ担当で、こんな依頼を受けたとします。

新しいサービス用に、サーバーを同じ設定で10台ばかり準備してほしいんだけど、お願いできる？ 明日までに。

　従来であればフザケルナです。必要なサーバーを調達し、ラックの空き状況や電力を調べ、搬入の手続きを行い、接続先のネットワークを調整し、ネットワーク担当にスイッチからのケーブルを引いてもらい、必要であればルーティングを入れ込んでもらい、購入した機器に合わせた手順書を作成し、搬入されたサーバーにOSをインストールし、必要な運用ツールを入れ込み、これでようやく引き渡しです。予算がある前提でも2〜3カ月は必要になるでしょう。

　仮に仮想化基盤が既にあったとしても、割り当てる物理ホストをどうするのか、接続するネットワークをどう作るのか、IPアドレスをどうするのか、このようなさまざまな判断要素があるので、事前に作業手順をレビューしたりと作業前にさまざまな調整事が生じます。

　しかし、OpenStackの環境が社内にある場合は、あなたはこんな感じで環境を準備できます。

# neutron net-create new-network
# neutron subnet-create new-network 10.0.0.0/24
# nova boot --flavor standard.small --image centos6 \
  --nic net-id=<new-netowkr-uuid> --key-name app-user-key \
  --user-data my_company_default_app.txt \
  --num-instances 10 \
  new-app-server

　コマンドを3回実行して終了です。新サービス用に新しいネットワークを作成し、そこに10台のサーバーを作成しています。環境にも依存しますが、10分もあれば確実に10台のサーバーが全く同じ設定で作成されます。

　サブネットの重複やIPアドレスの割り当てという問題もOpenStack側で解決してくれるため、人が判断する量が極端に少なくなります。また、OpenStackの裏側に存在するさまざまな機器のことも気にする必要はありません。これらは全てOpenStackの抽象化によって吸収され、ドライバーやプラグインが実際の作業を行ってくれるからです。この程度の作業であれば、直接ユーザーにOpenStackのダッシュボードやAPIを解放して、テナント割り当て、セルフサービスで実施してもらうことが可能です。

　さらに、この後でこのサービスが本番に突入し、その後にサービスのバージョンアップをする必要が発生するケースを考えてみます。皆さまの環境でもシステムのバージョンアップというのは十分に想定できるケースだと思います。この時にもOpenStackは従来の運用を大きく変えてくれます。

　図4を見てください。従来であれば、本番中のサービスをバージョンアップするにはさまざまな準備と、長時間のサービス停止が必要になります。万一、動作確認がうまくいかず切り戻しが必要となってしまうと、一大作業です。一方で、OpenStackの例を見てください。隣に同じ環境を準備して、そちらで新規にアプリを設定してリリースしています。これはサービスの停止時間も最小に抑えられ、何よりも失敗時のリスクが大幅に低減します。

図4　サービスのバージョンアップ作業例。従来の環境とOpenStack環境ではここまで違う《クリックで拡大》

　インチキのように見えるかもしれませんが、平行環境を用意して作業するというのは、昔からある方法でありながら、あまりこの方法が採られることはありません。なぜOpenStackではこのような運用が可能なのでしょうか？ また、なぜ従来の環境では難しいのでしょうか？

　それは環境を準備するコストが主な要因となります。新しいインフラ環境を準備するには多大な工数を必要とすることは既にお話ししたと思います。単に余分なリソースを準備しておけばいいわけではなく、それを利用可能な状態にするための工数が、本番環境を設定した場合と同じだけ必要になってしまいます。つまりコスト的に現実的ではないのです。

　しかし、OpenStackでは、最初の環境を用意するに使った3つのコマンドを、いくつか引数を変えてもう1度実行すれば、全く同一の環境が隣に簡単に作れてしまいます。このような手法は、ブルーグリーンデプロイメントと呼ばれ、ネット系企業を中心にバージョンアップを頻繁に行う環境で既に行われています。現在、OpenStackを採用するネット系企業が増えていますが、このように自社サービスの運用を効率化する事を目的しています。

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

OpenStackに求められるエンジニアのスキル

　OpenStackが実現する抽象化されたインフラ上では、インフラエンジニアが行う作業の考え方や方法が大きく変わっていきます。先の例では「本番環境を使い捨て」しています。操作の例でも、コマンドの直接利用を紹介しましたが、ここをChefやPuppet、Ansibleといったさまざまなツールと連携させることで、もっと高度で大規模な環境も容易に構成することが可能となります。さらに、OpenStackのAPIはコマンドだけではなく、他のプログラムからも操作することが可能ですので、プログラムと連携し自律的に動作するインフラを作ることすら可能となります。

　従来のインフラエンジニアはサーバーやストレージ、ネットワークなどの分野に特化し、さまざまな機器の特性や操作方法を熟知することで、自分の価値を高めてきました。しかし、OpenStack上では全てが抽象化・標準化されてしまい、このような方法だけでは自分の価値を高めることができません。

　では、どうしたら良いのでしょうか？――一つのキーワードとして、Infrastructure as a Codeがあります。抽象化されたインフラをプログラムのソースコードのように自在に操り、サービスやシステムの特性に合わせて、大量に・素早く・確実に供給していく技術です。

　とかくインフラエンジニアにはプログラムを書くことに一線を引いてしまう方が多いですが、OpenStackをきっかけにそういった垣根を取り払い、ぜひ新しい領域にチャレンジしてはいかがでしょうか。

著者プロフィール

中島　倫明（なかじま　ともあき）

日本OpenStackユーザ会会長（2012〜）

一般社団法人クラウド利用促進機構 技術アドバイザーを務めつつ、国内でのOpenStack／クラウドの普及・啓蒙・人材育成を行う。普段は伊藤忠テクノソリューションズに勤務し、オープンソースソフトウェア（OSS）を中心としたクラウド技術の企画・開発を主な業務としている。2014年5月『オープンソース・クラウド基盤 OpenStack入門』（共著／監修：中井悦司、KADOKAWA/アスキー・メディアワークス刊）を執筆。

特集：OpenStack超入門

スピーディなビジネス展開が収益向上の鍵となっている今、ITシステム整備にも一層のスピードと柔軟性が求められている。こうした中、オープンソースで自社内にクラウド環境を構築できるOpenStackが注目を集めている。「迅速・柔軟なリソース調達・廃棄」「アプリケーションのポータビリティ」「ベンダー・既存資産にとらわれないオープン性」といった「ビジネスにリニアに連動するシステム整備」を実現し得る技術であるためだ。 ただユーザー企業が増えつつある一方で、さまざまな疑問も噴出している。本特集では日本OpenStackユーザ会の協力も得て、コンセプトから機能セット、使い方、最新情報まで、その全貌を明らかにし、今必要なITインフラの在り方を占う。

特集：OpenStack超入門〜日本OpenStackユーザ会と追究する「攻める」ITインフラの在り方