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

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

2015年06月25日 08時00分 公開
[真壁 徹、伊藤雅典Hewlett-Packard]
日本OpenStackユーザ会のWebサイト《クリックで拡大》

 本連載「エンタープライズのための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基盤、アプリケーションを作ると、中途半端なものが出来上がる。注意されたい。

       1|2 次のページへ

ITmedia マーケティング新着記事

news084.jpg

生成AIが生み出す「バーチャル生活者」の声を聴くメリットとは?
博報堂は、独自の大規模生活者調査データベースに生成AI技術を組み合わせて作り出した「...

news038.jpg

生活者の生成AI利用動向 10代後半はすでに5割近くが経験――リクルート調査
テキスト型生成AIサービスの利用経験者の割合は若い年代ほど高く、特に10代後半はすでに5...