OpenStackの構造と内部動作、自分でクラウドを構築する意味とは。QCon Tokyo 2013

2013年5月15日

4月23日に都内で開催されたエンジニア向けのイベント「QCon Tokyo 2013」。ここで「OpenStackによる、実践オンプレミスクラウド」と題してオープンソースのクラウド基盤であるOpenStackでオンプレミスを構築する基本的なノウハウを紹介したのが、NTTデータの伊藤雅典氏。

エンジニアが自分でクラウドを構築する意味として、クラウドで扱う仮想化からネットワーク、ストレージに至る幅広い技術を理解する点にあるとした伊藤氏のセッションのポイントをまとめました。

OpenStackによる、実践オンプレミスクラウド

NTTデータ基盤システム事業本部伊藤雅典氏。

今日の話は「OpenStackによる、実践オンプレミスクラウド」です。私どもとしては、自社で一定以上の処理をする企業は、一定規模のプライベートクラウドを持ちつつバーストの部分を外部クラウドで処理する、というモデルが主流になるのではないか、とこれまでお話ししてきました。

OpenStackを使う意味は幅広い技術の理解

このQCon Tokyoでの講演のお話をいただいたときにも、そうした技術を熱くお話ししようと思っていたのですが、つい最近、ノーチラステクノロジーズがミッションクリティカルなシステムをAmazonクラウドで稼働させたという報道発表がありました。これはかなりの規模の話だと思いますし、その中心にいる神林さん（同社社長の神林飛志氏）が（いつもの（笑））少しあおった感じで「オンプレミスの終わりの始まり」というブログを書かれています。

それでオンプレの話をするのはどうしようかなと思ったのですが、神林さんのブログをよく読むと最後の方に、Amazonでこのシステムを作り上げたチームのエース級の方の言葉として「一筋縄では行きませんよ」、と書いてあります。

私はSIerの人間だからというわけではないのですが、インフラはサービスの根幹だと思います。それを中身がわからないブラックボックスに任せていいのだろうか？というのがオンプレミスのクラウドを自分で作って運用する理由として一点。

それからエンジニアの視点として、OpenStackのようなものでクラウドを作ることは、非常に広範囲の技術を必要とします。それに取り組むことがエンジニア価値の向上という意味もあります。

さきほどのノーチラスさんの一筋縄では行かないという話も、最初は彼らもオンプレミスで作ろうとしていて、そこで苦労されてクラウドへ行かれた。結局、パブリッククラウドでもオンプレミスでもプライベートクラウドでも、幅広く技術を理解して使うべしと、これに尽きるかなと思います。今日お伝えしたいのは端的にいうとこのことだと思います。

では、ここから具体的にOpenStackの紹介をしていきたいと思います。

OpenStackはリッチな機能セット、しっかりしたコミュニティの運営

OpenStackの特徴は、完全にオープンソースで非常にリッチな機能セットを持っているところ。開発コミュニティの管理やユーザーコミュニティの運営がしっかりしているとか、主要ディストリビューションの御三家（Red Hat、Canonical、SUSE）に標準搭載しているなどもあります。

概念図はざっくりこんな感じです。真ん中にあるのがVMを動かすところ、右がAmazon S3のようなストレージで、下に認証、左にはネットワークを担当するコンポーネントやブロックストレージもあります。

機能をコンポーネントに対応するとこうなります。Nova、Glance、Quantum、Cinder、Swiftなど。右側にAmazonに対応する機能を書いていますが、Amazonさんはユーザーの要件をよく見て機能を作っているので、OpenStackでもそういう機能が使いたいねという声が上がって対応する機能が作られたりします。

この4月に最新版のGrizzly（コード名）が出ましたが、大きな新機能は大規模システムに対応しましたねというのと、ネットワークでいろんなベンダーのプラグインが入ったこと、ロードバランサーが使えたり。ダッシュボード機能ではネットワークの新機能に対応するだけではなく、ネットワークトポロジーのグラフィックパネルなども搭載しています。

OpenStackの内部構造と動作

ここからは、テクニカルにOpenStackがどう動いているか、という話です。最新のバージョンのNova（コンピュートサービス）のアーキテクチャはこうなっています。

Novaはコンピュートサービス、Cinderはブロックストレージのサービス、Quantumはネットワークサービス、Glanceは仮想マシンなどのイメージを管理するサービス、KeyStoneは認証サービス。

スタティックなアーキテクチャの話をしたので、これらがどんな風に動いているのか、仮想マシンの起動シーケンスの例を紹介します。

まずユーザーのPCからAPI経由でリクエストが来て、APIは要求の受付だけしてスケジューラにあとはよろしくと要求を投げます。

スケジューラからNova Computeに要求が渡ると、ネットワークの準備をします。ネットワークの論理的な割り当てを行うのがQuantum Serverで、テナントに対応したVLANなどを仮想マシンに割り当てるために、Quantum Agentに要求を出します。

このあと、VMイメージのテンプレートをダウンロードし、VMを生成します。このとき、Quantum Agentが作ったL2のTapをVMの仮想NICにブリッジ接続します。

ここまでの動きは、Linuxのごく基本的な機能、vconfigとかovs-vsctlとかiptablesとか、システムアドミニストレーションをするときに使うコマンドばかりです。

こういうコマンドを幅広く使っているので、さきほど言ったエンジニアの幅を広げる意味で成長につながるのではないかな、というのがエンジニアの皆さんへのメッセージです。

商用システムに向かって

つい最近、本家のコミュニティによるOpenStackの設計から運用、構築のベストプラクティス集大成のドキュメント「OpenStack Operations Guide」が出ました。実際にOpenStackで商用サービスをやっている人たちが、自分たちのベストプラクティスがこうだ、という情報をまとめたわけです。日本の有志で翻訳を行っています。

とはいえ、設計の原則論的な話を少しすると、レガシーな三層Webシステムの高可用性やサイジングなどとほとんど変わりません。サービスの仕様を最初にきちんと設計しないと、あとで破綻しますよと。

私はオープンソースソフトウェアを基本に仕事をしているのでそちらにバイスがかかっていると思いますし、なおかつ所属する会社としてはエンタープライズ系を中心としたお客様を持つSIerなので、そういった立場でのクラウド構築で悩ましいのは、ブロックストレージでこれだ、という答えを持っていないところです。

私たちのお客様はミッションクリティカルの面で厳しいところが多いので、基本は箱物を使うのですが、箱物は信頼性はあるが高価です。一方、オープンソースのCeph RBDやSheepdogは性能や信頼性で最後まで面倒を見切れるかどうか、ここは答えを持っていません。ただ技術者としてはCeph RBDが面白いなと思っていて、自分のサービスで、自分の責任でチャレンジしてよいのであれば挑戦してみたいなと思っています。