エンタープライズのためのOpenStack検討ガイド【第5回】

OpenStack導入で先が思いやられる「アンチパターン」ベスト5（1/2 ページ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エンタープライズのためのOpenStack検討ガイド

この連載の記事をもっと見る

この記事の著者

関連記事

• 

  サイバーエージェント、ヤフー、楽天が語るOpenStackとの理想的な関係

• 

  PayPalが語るOpenStack新版「Havana」の導入効果

• 

  機能を徹底比較！　～Eucalyptus、CloudStack、OpenStack

• 

  クラウドに興味を持つ者全てが望む「オープンソース連係」

新着ホワイトペーパー PR

• 製品資料
  [株式会社うるる] 「入札市場」攻略ガイド：効率的に落札するためのポイントを徹底解説
• 製品資料
  [株式会社うるる] 入札情報に特化した「販路拡大」「効率化」のためのサポートツールとは？
• 市場調査・トレンド
  [株式会社うるる] 公共入札に成功する企業と失敗する企業の「5つの違い」
• 製品資料
  [日本ビジネスシステムズ株式会社] 専門家が教える、Microsoft 365の「テナント統合／分離」を成功に導く秘訣
• 製品資料
  [rakumo株式会社] Microsoft 365での情報埋没を防ぐ、社内ナレッジを資産化する情報ポータル活用