前回、設計時の落とし穴として「枝葉の技術にこだわり過ぎる」アンチパターンを紹介した。先進的、魅力的なネットワークやストレージ技術を使いたくなる気持ちは理解できる。だが、それが前提になってしまうと、全体のバランスを大きく崩すことが多い。

• 前回の記事「OpenStack導入で先が思いやられる「アンチパターン」ベスト5」

　では、どのような順で検討を進めるべきだろうか。筆者は下図のステップをおすすめする。

《クリックで拡大》

　では、順に見ていこう。

ステップ0：コンセプト策定

　まずは、OpenStack基盤をなぜ作るか、そのコンセプトを固める。これは前回説明した通りだ。くどいようだが、設備コスト削減だけが目的ならば従来型の仮想化でよい。OpenStackを導入する狙いを明確にしよう。

　また、これも前回の繰り返しになるが、コンセプト策定にアプリケーション開発者の参画と、ディスカッション、意識合わせは欠かせない。というのも、次のステップ以降でそれが重要なインプットとなるからだ。将来的なビジネス要件を考慮し、どのようなアプリケーション、基盤、開発・運用プロセスが必要になるかを議論すべきだ。

　アプリケーションが王様、インフラはお城である。お城は王様のためにある。

　なお、可能であれば、この時点で意欲ある少数のメンバーをアプリケーション、インフラ双方のチームから集め、プロジェクト化すると理想的だ。発想と実行を制限しないよう、従来業務との兼任はしない方が、うまくいく場合が多い。

　そして、このタイミングで、おおまかにユーザー、市場動向を確認しておくといい。ベンダーからの情報だけでなく、中立的な情報があるといいだろう。「OpenStack Foundation」が公開しているユーザーサーベイなどが役立つ。

ステップ1：ハイパーバイザー検討

　コンセプトが固まったら、まず実施すべきはハイパーバイザーの検討だ。

　なぜ真っ先に検討すべきなのか。それはアプリケーションの制約を最も受けやすいからだ。例えば、商用アプリケーションやミドルウェアによっては、動作環境としてOSのみならずハイパーバイザーを指定するものがある。ハイパーバイザーを指定するソフトがビジネス上必要であれば従わざるを得ない。

　現状、OpenStackのハイパーバイザーとして実績が多いのは「KVM」である。エンタープライズにおいては、次いで「VMware ESXi」だろう。VMware ESXiを選択する背景には、前述のソフトウェアサポートの制約がある。VMware ESXiは実績がある分、サポートするソフトウェアが多いからである。

　手戻りがない手順を、と言っておいて恐縮であるが、ここでコンセプト策定に戻り、再調整しても良いと筆者は考える。ハイパーバイザーを制約するソフトウェアを止め、他に置き換えられないか、大胆に検討するためだ。ハイパーバイザーを指定するようなソフトウェアを使い続けることで、可搬性は大きく狭まる。将来に禍根を残さないよう見直しをおすすめする。もっとも、この記事で事前に理解できた読者の皆さまに、手戻りはないかもしれないが。

　なお、同一コントロールプレーン下でのハイパーバイザーの混在は、現状、技術的な難易度が高い。その大きな理由はネットワーク仮想化技術にある。例えばKVMでは「Open vSwitch」や「Linux Bridge」を活用、拡張した実装が主流だ。一方VMware ESXiでは、「VMware NSX」やアプライアンスVMによるものが多い。VXLAN、VLANなどテナント分離技術も多様である。混在したい場合は、それらが組み合わせで動くかどうか、十分な情報収集と検証をおすすめする。もし混在にこだわって複雑度とコストが増すようであれば、それぞれ別のコントロールプレーンで運用した方が合理的だろう。

ステップごと：全体整合性チェック、ディストリビューション検討

　検討結果を俯瞰し、これまでの検討内容と整合性がとれているかチェックする。この作業は、ハイパーバイザー選定後だけでなく、全てのステップで実施してほしい。

　OpenStackに対応するハイパーバイザー、ネットワーク技術、ストレージ技術は多くある。だが、それらの全ての組み合わせが動くとは限らない。

　OpenStackをソースから組み上げるのであれば各ステップで情報収集と検証を行う。また、ディストリビューションを使う場合は、そのステップで選定した技術がサポートされるかを確認する。ステップを経るごとに、候補は絞られてくるはずだ。