クラウド開発の準備状態を診断する５＋１つの質問（設計編）
経営者的にみるとクラウドの技術というのは、これさえ用意すればコストは削減できるしパフォーマンスはアップ、しかもダウンタイムまで少なくできるという打ち出の小槌に映っていますが、個人的にはクラウドは設計手法のパラダイムシフトが必要なため、開発者に日ごろから学習機会を与えているような会社でなければ成功の可能性は低いのではないかと思っています。またクラウド開発へのシフトは上流工程よりも中流から下流工程に強いインパクトを持つため、誰か一人がクラウド上での設計を知っていてもチーム全員にその知識が行き渡らなければ継ぎはぎ的なソフトウェアとなってしまいクラウドの利点を活かしたシステムにはならないと考えています。
ということでクラウドアプリの開発準備ができているかを判断するのに中流工程向けにいくつか質問を用意してみました。ちなみにここで扱うクラウドはどちらかというとAmazon EC2 などの IaaS/HaaS寄りです。Google App Engine や Salesforce などの PaaS タイプであればもう少し簡単になりますね。
- 1. RDBMS を使わず設計できるか？
- 2. 全てのサーバは落ちることを前提に設計できるか？
- 3 ダイナミックコンフィギュレーションを設計・実装できるか？
- 4. 分散することに重点をおいて設計できるか？
- 5. トラフィックスパイクを柔軟に受け流せるように設計できるか？（メッセージキューを利用して実装できるか？）
以下それぞれの解説をしていきましょう。
- 1. RDBMS を使わず設計できるか？
- クラウドを活用しようとすると CAP 定理*1のうち、C(Consistency: 一貫性）の部分でどうしても妥協することになるので、果たしてそのような設計ができるかというのが課題となります。RDBMS は現時点でスケールアウトさせにくいので KVS などの利用も視野に入れることになるでしょう。
- 2. 全てのサーバは落ちることを前提に設計できるか？
- すくなくとも Single Point Of Failure (単一障害点）を作らない設計にする必要があります。例えば既存のシステムだとロードバランサーが SPOF になっている場合は多いと思います。クラウド上のマシンは、契約するプランにもよりますがそんなに信頼性は高くないので HAサーバとは違うということを肝に銘じた設計が必要になります。調子が悪くなった時点でそのサーバは破棄して新しく作り直せるようにしておくこという発想の転換も必要です（この辺が楽なのもクラウドの特徴のひとつですね）
- 3. ダイナミックコンフィギュレーションを実装できるか？
- いわゆる幹細胞のようにどのような役割でも担えるようなサーバを作っておき、起動時に設定サーバから自分が担うべき役割を取得、分化していける仕組みを指しています。設定情報もトラフィックやデータ量などで自動的に作成されるような仕組みにすればかなりうまくいきそう。単純な例でいうとフロントエンドのコネクションがある閾値を超えている時に幹細胞サーバのインスタンスを作成するとそのインスタンスはフロントエンドとして機能する、などなど。
- 4. 分散することに重点をおいて設計できるか？
- スケールアウトするため、処理やデータを分散していける設計が必要になります。スケールアウトというだけではなく可用性を促進するためにも処理やデータを分散させておく必要がありますね。ただし直列の処理を複数に分断することには注意する必要があります。できれば水平方向に分散させていく設計のほうがサーバーが落ちたときのことを考えると楽なはずです。
- 5. トラフィックスパイクを柔軟に受け流せるように設計できるか？（メッセージキューを利用して実装できるか？）
- 例えばリリース初日、広告の効果が抜群で当初想定していた数の100倍のアクセスがあった場合でもマシンイメージさえ追加できれば運用できるような設計をする必要がありますね。メッセージキューに関しては使い方がいわゆるマルチスレッドプログラミングモデルで言うところの Producer & Consumer モデルなので全く難しくないのですが、こういうメッセージキューを利用することで設計の中に非同期の仕組みを効果的に取り入れて可用性を高める設計ができるかどうかがカギとなります。
さてこれらの質問全てに YES と答えられたでしょうか？
最後にもう一つだけ質問をあげておきます。
- そのアプリはクラウドで開発しなければいけないものなのでしょうか？
個人的にはクラウドでなければならないアプリケーションって実は少ないんじゃないかなと思っています。頻繁にサーバの構成の変更が必要、つまりスケールアウト、スケールインの頻度が高く、スタートアップも迅速でなければならないソーシャルアプリなどには向いているでしょう。いわゆるベンチャー向けですね。
しかし企業内のアプリなどはクラウドにする必要もなければ仮想化する必要もないものが多いのではないかなーと考えています。この企業内のアプリを仮想化さえする必要がないというのは単にコスト面で見合うかどうかという点を鑑みてのことです。仮想化用にサーバやストレージを冗長構成組みながら揃えるのはかなり費用がかかりますし、設計や運用などのプランを立てる人件費もばかになりません。さらには仮想化用のソフトウェアも高額なので費用対効果を慎重に見極めてから、ということになりそうです。
*1:CAP定理とは Consistency（一貫性）, Availability（可用性）, Partition（分割耐性）の３つの性質を同時には満たせないということで、次のURLにわかりやすい説明があります。http://www.hyuki.com/yukiwiki/wiki.cgi?BrewersCapTheore
