OpenStack導入で先が思いやられる「アンチパターン」ベスト5：エンタープライズのためのOpenStack検討ガイド【第5回】（1/2 ページ）

OpenStack導入で最も重要なのは初期コンセプトを固めることだ。OpenStackを仮想化の延長と考えると失敗する。多くのOpenStack案件に関わってきた筆者が5つのアンチパターンを紹介する。

[真壁 徹、伊藤雅典，Hewlett-Packard]

日本OpenStackユーザ会のWebサイト《クリックで拡大》

　本連載「エンタープライズのためのOpenStack検討ガイド」も残すところ後2回である。連載の仕上げとして、これからOpenStackに取り組むアーキテクト向けに、設計に当たって考えるべきポイントをまとめてみたい。筆者はこれまで多くのOpenStack案件の提案、設計に関わってきたが、問題につながりやすい「アンチパターン」のようなものが見えてきたところだ。今回は「設計前夜」編として、設計に入る前に意識すべき落とし穴を紹介する。

これまでの連載

• 第1回：“オープン”以上の価値がある、OpenStackが企業で歓迎される理由
• 第2回：OpenStackは企業ITで有りか無しか　AWS、VMwareとの違い
• OpenStackで注目の3大機能と開発コミュニティーの実態
• 第4回：

連載インデックス：エンタープライズのためのOpenStack検討ガイド

過去の連載：OSSクラウド基盤 OpenStackの全て

基本思想の間違いは取り返しがつかない

　企業システムにとって取り返しのつかない失敗とは何か。

　バグや障害よりも致命的なもの、それは初期コンセプトの誤りだと筆者は考えている。システムを企画立案する際の目的、位置付け、進め方、力点などの基本思想は重要だ。利害関係者から一度理解、承認を得た後、それは容易に変えることができない。やり直しがきかないのだ。このつらさは、企業システムに関わる読者の多くに共感を得られると思う。

　よって今回は、技術要素に踏み込む前、コンセプト策定時に注意すべきポイントを、記憶に残りやすいアンチパターン形式で紹介したい。

アンチパターン1：なんとなく仮想化基盤の更改先とする

　残念ながらこのパターンにはまる案件は、非常に多い。

　基盤技術はトレンドに大きな影響を受ける。よって、仮想化基盤の老朽化に伴い、話題のOpenStackを更改先として検討するのは自然だ。しかし仮想化基盤と、OpenStackが目指しているクラウド基盤との間には大きなギャップがある。アプリケーションへの影響が比較的小さく、また、設備コスト削減が主目的であった仮想化と、OpenStackには大きな違いがある。OpenStack導入では目的を説明する機会も多くなる。クリアな説明が必要だ。

　仮想化基盤と、OpenStackの目指すクラウド基盤の違いについては、この連載でこれまで解説してきた通りである。OpenStackは、変化の激しいビジネスに追従すべく、機動力あるIT環境を実現するための手段だ。コスト削減も、設備コストにとどまらず、アプリケーション開発プロセスの効率化、自動化によるインフラの運用コストを含め、トータルで考えるべきである。

　逆に言えば、設備コスト削減だけが目的であれば、無理してOpenStackにチャレンジする必要はない。仮想化盤をシンプルに更改した方がよいだろう。もちろん、現状維持で更改後数年、激しいITの変化に追従できるかどうかは別問題であるが。

関連記事

OpenStack導入事例

• サイバーエージェント、ヤフー、楽天が語るOpenStackとの理想的な関係
• PayPalが語るOpenStack新版「Havana」の導入効果

OSSクラウド基盤比較

• 【徹底比較】Eucalyptus、CloudStack、OpenStackの仮想マシン性能
• 機能を徹底比較！　〜Eucalyptus、CloudStack、OpenStack

OpenStackストレージに関する記事

• OpenStackのブロックストレージ「Cinder」の押さえておきたい機能
• OpenStackストレージ、主要5社の差別化ポイントをまとめた

アンチパターン2：インフラ担当者だけで進める

　OpenStackをはじめとするクラウド基盤では、そのポテンシャルを生かすため、アプリケーションをOpenStackに合わせて最適化した方がよいケースがある。オブジェクトストレージの活用やステートレス化などだ。

　よって、インフラ担当者だけでプロジェクトを進めてしまうと、後々アプリケーション開発者へ説明した際に「そんなの聞いていない」と抵抗されてしまいがちである。結果、せっかく作っても、その基盤は使われなくなってしまう。

　筆者の経験では、アプリケーション開発者の課題解決がきっかけで始まったOpenStack導入プロジェクトは成功しやすい。

　アプリケーション開発者は生産性を高めるため、テストやデプロイの自動化、省力化に注目している。その過程でクラウドやOpenStackの特徴である、プログラマブルな基盤を欲しているのだ。「Jenkins」「Chef」「Ansible」「Vagrant」など、アプリケーション開発者から高い支持を得ているツールは、プログラマブルな基盤との組み合わせでその真価を発揮している。

　当たり前の話ではあるが、「誰のためのものか」という問いをないがしろにした基盤は評価されない。基盤と直接向き合う使い手（ユーザー）はアプリケーション開発者である。彼らのメリットを考えなければならない。

アンチパターン3：ペット感覚が抜けない

　クラウドを生かすアプリケーションは「クラウドネイティブアプリ」と呼ばれる。その定義はさまざまであるが、「障害が起こる前提でアプリケーションを作る」は共通した特徴だろう。形あるものは必ず壊れる。基盤の規模が大きくなれば壊れる頻度も多くなる。なので、インフラに過度に期待せず、アプリケーションで可用性を担保しようという考え方だ。

　最近、クラウド技術者の間では「Pets vs. Cattle」という表現が使われていることをご存じだろうか。Petsはペット、Cattleは家畜のことだ。

　Petsは従来型システムである。ハードウェアに人間が記憶できる名前を付ける。可用性はなるべくインフラで面倒をみる。障害時はとことん原因追及をする。ペットのようにかわいがるというわけだ。

　一方でCattleは、ハードウェアには機械的な識別子しか付けない。可用性はアプリケーションで高める仕組みを入れて高める。障害時はスピード重視で即交換。替えが効くという意味で、家畜と表現される。標準化とスピードを求める、クラウドらしい考え方だ。

　よって、Petsの考え方が抜けないままでOpenStack基盤、アプリケーションを作ると、中途半端なものが出来上がる。注意されたい。