OpenStackを使うと、結局何を効率化できるのか?

Webサーバーの増設、物理、仮想、OpenStack環境ではどう変わる?

突然ですが、あなたは企業のインフラ担当で、アプリ開発チームから以下の要望を受けたとします。

今稼働中の社外向けサイトのWebサーバーを増設したいから、前のサーバーと同じ設定で3台ばかりサーバーを用意しておいてくれないかな?

 ここでは、より話を具体的にするため「Webサーバーの増設」という題材を取り上げます。この会社ではサーバーやストレージ、ネットワークといったインフラ環境はインフラ担当者が準備を行い、その後アプリチームに引き渡しを行います。

 この作業を行う場合に、仮想化以前(物理サーバー環境)、サーバー仮想化環境、そしてOpenStack(クラウド)環境という3つの環境では、それぞれにどのような作業が必要でしょうか? この環境間での作業の差を見ていくことで、OpenStackが何を効率化するのか、そしてその効率化は何によってもたらされるのか、という点を理解することができると思います。ALT図1 以上のような「Webサーバーの増設」を行いたいとき、仮想化以前(物理サーバー環境)、サーバー仮想化環境、そしてOpenStack(クラウド)環境では、作業にどのような違いが出てくるのだろうか?

物理環境時代の構築作業

 もし自社の環境が物理サーバーのみで構成されているとしたら、今回のWebサーバーの増設にはどのような作業が必要になるのでしょうか?

 まずサーバーを購入する必要がありますので、要件からスペックを決めて発注を行います。この際に、設置するデータセンターのラックの空き状況や電源容量、ネットワークの要件から搭載先のラックも決めておく必要があります。そしてサーバーが到着したら、データセンターへの搬入を行い、ラックへ搭載し電源容量を考慮した上で電源へ接続しますが、この段階ではまだ電源を入れることはできません。電源を投入する前に、接続するネットワークに合わせて、ネットワークケーブルを結線して事前に割り当てるIPアドレスを決めておく必要があります。

 ここまでの作業が完了したらサーバーの電源をONにして、作業手順書に従いOSをインストールし、各種OS設定(IPアドレスなど)を行った後に、アプリ開発チームへとサーバーを引き渡します。単純にサーバーを準備すると言っても、多数の作業と決め事が必要となることが分かると思います。

サーバー仮想化時代の構築作業

 次に、自社が既にサーバー仮想化の基盤を導入している場合を見てみましょう。

 この場合はサーバーを発注する必要はありません。まず要件から仮想サーバーに割り当てるリソース(vCPU/メモリ/ディスクサイズなど)を決めます。次に仮想化基盤のハイパーバイザーホストのリソース使用状況を確認し、仮想マシンを配置するホストを決めます。そして接続するネットワークで利用するIPアドレスを割り当てて、仮想マシンを作成します。このとき、テンプレートOSなどが準備されていればクローンすることでインストール作業は簡略化できます。最後に起動したOSにネットワークの設定などを行い、アプリチームへの引き渡しを行います。

 復習のために物理環境とサーバー仮想化の環境では、どのような変化が発生しているのか見てみましょう。ALT図2 物理環境とサーバー仮想化環境における作業の違い

 図2を見ると、サーバーのスペック選定や、搭載先のラックの調整、ケーブルの結線といった作業がサーバー仮想化ではなくなっています。これらの作業は実際に物を動かしたり、つなげたりする「物理的」な作業だと言えます。つまりわれわれはサーバー仮想化を導入することで、物理的な作業量を大きく減らすことができます。

 また作業ではありませんが、OSインストールなどの作業を簡略化できたり、ここでは記載されていませんが、稼働率の低いサーバーを仮想化し、1台の物理サーバー上に集約することで物理的な台数を削減することもできます。一言でまとめるなら、われわれはサーバー仮想化を導入することで、「物理」に関連する作業を効率化してきたと言えます。

 ここまでの内容は、今日において広く浸透したサーバー仮想化のメリットをなぞったものですが、少し視点を変えてみましょう。

 図2を見てみると、サーバー仮想化を導入したことによって増えている作業があることに注目してください。それはどのくらいのリソースを仮想サーバーに割り当てるかを決定し、その仮想サーバーをどのハイパーバイザーホストに配置するかを決める作業です。この作業は、現在ハイパーバイザーが消費しているリソースの量と配置する仮想サーバーのリソースという二つの情報から「人の判断」によって実施される作業になります。サーバー仮想化の世界では、物理的な作業が軽減されていますが、「新たに人が判断する必要のある作業が増えた」とも言うことができると思います。

クラウド時代の構築作業

 本題となるクラウド環境(OpenStack環境)について見ていきます。この例ではサーバー仮想化の時と同様に、すでにOpenStack環境を導入している、もしくはパブリックなOpenStackクラウドを利用している場合を想定します。

 まず作業の全体像を図3へ記載します。ここではサーバー仮想化の場合と対比して記載しています。ALT図3 サーバー仮想化環境とOpenStack環境における作業の違い

 サーバー仮想化で必要だった作業がほとんどなくなり、代わりに新たな作業項目が加わっているのが分かると思います。実際にOpenStack上で行う作業は3つです。

 フレーバーの選択は、OpenStack側に準備されている仮想サーバーのスペック(vCPU数/Mem容量など)のセットから要件を満たすフレーバーを選びます。OpenStackでは細かなスペックを毎回個別に選ぶよりも、あらかじめいくつかのフレーバーを準備しておき、そこから選ばせる方が効率的という思想です。選択肢の幅を狭めて判断を効率化しています。

 次に、作成した仮想サーバーで実行させる設定スクリプトを作成します。例えばパッケージのインストールや、設定ファイルの編集といった内容です。いわゆる設定手順書の内容を、スクリプトやレシピという形式で準備しておき、作成した仮想サーバーの起動時に実行させることができます。このときに作成するスクリプトは、同時に何台でも適用できる上に後で使い回すこともできるので、何台でも全く同じサーバーが作成できるようになります。

 そして最後にサーバーを作成するためのコマンドを実行します。第3回の記事において、似たようなシチュエーションを取り上げているので、そこからコマンドを引用しつつ、引数を少し変更したものが以下のコマンドです。OpenStack環境においては、このコマンドを実行するだけで、物理環境とサーバー仮想化環境で生じていた全ての作業を実行できます。

# nova boot \
  --flavor standard.small \          ←選択したフレーバー
    --image centos6 \                  ←起動するOSイメージ
    --nic net-id=<dmz-net-uuid> \      ←接続するネットワーク1
    --nic net-id=<app-net-uuid> \      ←接続するネットワーク2
    --key-name user-keys \             ←作成する仮想サーバーへ入れ込むキーペア
    --user-data web_server_config.txt \  ←起動時に実行する設定スクリプト
    --num-instances 3 \                  ←作成する仮想サーバー台数
    web-server                           ←仮想サーバーの名前

 図3を見ていただくと、このコマンドによって実にさまざまな作業が簡略化されていることが分かると思います。特に注目してもらいたいのが、物理環境からサーバー仮想化へ進化した際に、新たに発生した「人の判断」の部分がなくなっていることです。他にもIPアドレスの割り当てといった、人が判断していた作業もなくなっています。侵入前/侵入後対策を統合したサービス、軽量な製品が欲しい

 このようにOpenStackを導入することによって「人の判断」をなくす、もしくは減らすことができるようになります。これは、OpenStackが仮想マシンの最適な配置や、アドレスの割り当て、設定の入れ込みといった作業を自動的に行ってくれるようにできているからです。

 また、この作業フローには出てきませんが、ストレージを割り当てる際のボリューム作成と仮想サーバーとの接続といった作業や、仮想ルーターへのルーティング追加といった作業も不要になります。これらの作業も従来であれば人が「判断」して作業されていましたが、OpenStack上では自動化されています。

 このように、OpenStackでは人の判断を必要とする作業を自動化することで、作業のボトルネックを排除するとともに、属人的なミスの可能性をなくすことが可能となります。今回はサーバーを3台増設するという作業ですので、自動化による恩恵は微々たるものです。しかしこれが100台の場合であったり、3台の増設を10回繰り返すような場合には、非常に大きな効果を発揮することは容易に想像できると思います。

 このような性質から、OpenStackは開発とリリースが短いサイクルで繰り返されるインターネットサービスの基盤で好んで採用されます。今日ではネット系企業のみにとどまらず、銀行や製造業などでも活用が進んでいます。これは、非IT業だからといって、ITの活用を社内の業務効率化のみに限定するのではなく、自社ビジネスの付加価値創造のために、積極的なサービス開発を行う企業が増えてきたためです。

自動化 vs 人の管理

 さて、ここまでの説明では、OpenStackを使うと仮想マシンの配置やIPアドレスの割り当て、ネットワーク接続、ストレージ接続といった、従来は人が判断して作業していた項目をプログラムに任せることになるという話をしてきました。こういった話を聞くと、

いやいや、心配でプログラムに任せておけないよ

今まで手動で管理していたから、これからも手動で管理したい

 と感じてしまい、OpenStackに抵抗を感じてしまう方もいると思います。

 ですが、考えてみてください。本来、計算機の仕事は「人間の代わりに仕事を行う」「人間には不可能な速度で計算を行う」ということであり、それが計算機の存在理由であるはずです。計算機の歴史とは、人間の作業をいかに計算機に代替させるかへの挑戦でした。

 振り返れば、メインフレーム上でタイムシェアリングやメモリを緻密に割り当てていたエンジニアにとって、全てのリソース管理をカーネルが自動的に行うオープンシステムには抵抗があったと思います。また、ディスクシステムをRAIDや論理ボリュームマネジャーに任せることに不安を感じたエンジニアの方もいると思います。

 しかし、現代のシステムでは、CPUのタイムシェアリングやメモリ割り当て、ディスク管理、ボリューム管理といった過去に人手で行われていた作業のほとんど全てがソフトウエア側に委ねられるのが当たり前になっています。OpenStackはこのような自動化の考え方が、仮想マシンやネットワーク、ストレージの「管理」という領域まで引き上げられてきたということです。

※この背景には、第3回で説明した「抽象化」によってこれまで人が意識する必要があった、物理層が隠蔽(いんぺい)できるようになったことがあります。ご興味があればこちらも併せて読んでみてください。

 当然、ソフトウエアでの制御は人間のような柔軟性がなく融通が効かないため、人がきめ細かな決め事をした場合に比べ、局所的には効率が落ちる面もあります。また、一度使ったシステムをほとんど変更なしに3~5年間使い続けるという状況では判断をする回数自体が少なくいため、OpenStackが有効に働かないケースもあります。一方で、アジャイルに代表される短いサイクルで開発とリリースを繰り返すシステムやサービスの運用にOpenStack基盤を活用すれば、人の判断がボトルネックにならない自動化の仕組みは強力な効率化を実現してくれます。

 少し視点を変えてみると、ハードウエアのコモディティ化が進行し、リソースの単価が劇的に安価になった現在において、図2の右側に表されるような「人の判断」に対して高額な人件費を費やし続けるというのは、コストの面から見てもひどくアンバランスです。

 当たり前の話ですが、OpenStackはただ導入すればコストが下がり、運用が簡素化され、クラウド時代に最適なシステムが構築できる、という魔法の技術ではありません。重要なのは技術の特性と自社ビジネスで必要とされるITシステムの特性を正しくマッチングし、最適な環境を提供していくことです。