クラウドの光と闇
特定の企業やサービスをDisる意図はない。しばらくクラウドビジネスに関わってみて感じたことをただ個人的に書き留めたいだけ。怒られたら消すし、あといつも通りまとまりはない。
クラウドの利点を説明するとき、よくオンプレと比較されると思う。オンプレっていうのは仮想に対して物理という概念を表現するための言葉で、データセンターやサーバラックなどをイメージするとおおよそ合ってる。
オンプレだとサーバを買おうと思ったら専門の業者に見積りをもらって置き場所を考えてコスト計算して減価償却云々、いろいろ考えるべきところがあるけれども、クラウドならWebをぽちぽちやってるだけでサーバが完成する。見積りもWebから見られる。課金はちょっとややこしいがデータセンターを借りることを考えると単純なほう。産業廃棄物を自社から出さなくていいのもいいですね。
こんな感じで、オンプレより圧倒的に便利だからクラウド使おうぜ、となることが多い。クラウドの利点はすごいと思うし、使えば使うほどハマる。スケールアウトだけかと思いきや、スケールアップも楽で、たとえばtopコマンドみたいなものをShellで回し続けて一定数を超えたら勝手にスケールアップするような操作とか、ソフトウェアルータなんかも通信量を適当に計測してやばくなったら2台目を作るとかがすごく簡単。価格とスケーラビリティは本当にすごい。
でも、こういう利点は、あくまでも「利点」である。オンプレがそれらの利点を持たないことは明白だが、クラウドには欠点も当然ある。それで、ここがもっとも当たり前且つ見過ごされがちなんだけど、欠点はインターネットでもなかなか見つからない。
なぜならクラウド環境を提供するビジネス屋さんはあくまでもビジネスだからです。欠点を主張するメリットがない。言うとすれば、欠点も裏返せば利点に繋がりますよ、みたいな言い方になる。さらに、わりと本気でクラウドのバグなんかを根回しせずにいきなり公開すると消されることもあると聞く。（聞いたことあるだけで都市伝説かもしれません）
まあでも、いろいろ当たり前だ。それゆえに、見過ごされがちなのかなと最近思う。
クラウドの闇にちょっとだけ触れておく。何度も繰り返すが、特定のなにかを批判する意図は本当にない。ただもし、コスト的な問題がないにも関わらず闇雲にクラウド移行を考えているような現場に出くわしたとき、必要になるかもしれないと思うから書いておく。
一番大事だと思うのは、オンプレのようにはクラウドを使えない、ということだ。オンプレの欠点を補うからといって、オンプレでできたことを、そのままクラウドに移すことは、たいていの場合無理がある。クラウドは仮想環境というだけあって、NICという概念がなかったり、OSが起動するのに必要な情報が自分自身のなかで完結していなかったり、ネットワーク低レイヤの概念（MACアドレスとか）がいまいち信用ならなかったりする。
老舗のサービスほどどんどん新機能が出てくるが、喜んでいると急に旧機能がなくなったりする。本体の仕様や価格が突然変更されることもある、それはAPIやSDKがある場合も同じだ。そういうことに対して、お金を払っているユーザだからといって文句は言えない。
お客様は神様ですか？
あとは、事例が少ない機能の実験台になったりすると、有料サポートでも歯が立たないみたいなことがある。日本でサービスが提供されている場合でも、サポートの行き先は海外の開発拠点とか。まあこの辺は海外の有料サービスを使うときと似たようなものだ。それで思い出したけど海外製のサーバを海外から輸入して使ったときはマジで大変だった安息日とかあるし。そういうのに比べれば、クラウドのサポートはかなり理想的だろう。解決しないこともあるけど。解決しなくても文句は言えません。お客様は神様ではない。
オンプレの煩わしさから解放されるかわりに、クラウドならではのやりにくさを引き受けることになる。その覚悟は少なくとも要る。
（ただそれでも、クラウドの価格は圧倒的に安い。どんな面倒があっても（＝つまり人件費に影響が出るとしても）、管理会計上はたぶん圧倒的にコスト削減になって見えると思う）
（まあ、だからといって使い放題だと思ったりするとコスト削減のつもりがお賽銭箱に財布ごと投げるみたいな事態になるので注意は必要ですが）
そんなわけで、クラウドだとオンプレ以上に、インフラの構築・運用テクニックが重要になってくると思う。ハック的なものとか、新機能のレポートはわりとすぐインターネットに流れてくるけど、そういうのに飛びつくときに、本当にそれがまあまあ永続的に利用できるのかとか、プロダクションレベルで使えるのかとか、一度は考えたほうがいい。当たり前だけど。（考えない人をたまに見かけますが、これも私の目が都市伝説かもしれない）
さらに言うと、オンプレでできたことは簡単でしょ3日で移行してよ、って言ってくるお客様は神様なので、やっぱりそれなりに裏側（物理側）も推測できてないと大変なことになります。なるけど、クラウドの概念はクラウドの概念を使って理解したほうがいいので、ものすごく局所的な例えだけど例えばAWSのENIをNICと同じだと思わないほうがいい、ENIはENIであってENI以上でも以下でもありません、とかがあり、物理側を推測しつつクラウド側の概念で考えて神様に説明するというスキルが求められる。
障害発生時はもっと大変です。切り分けが慣れるまで死ぬほど難しい。「とりあえずLANケーブル抜く」みたいな概念がどこに当てはまるのか分からないというか、LANケーブルは実際ないし。慣れても対応の仕方が正しいかすぐ検証できないとかもある。完全に同じ構成で検証環境を作るのが物理よりちょっと難しいと思う。多くのクラウド環境では、コンソールで見られるのはメタ情報で、OSに入ろうと思ったら別の処理が必要なあたりが。KVMスイッチ使いたいなーとかよく思う。じゃあ作ればいい、というのはその通りですねすみません。
あ、そうそう、大規模Webサービスのように、同じサーバをスケールアウトしていくやり方で冗長性や性能を担保している場合はすごくクラウド向いてると思うんですけど、たった1台のサーバを生かさず殺さず鉄壁な守りの中で長く使いたい障害とか絶対ヤメテみたいな、日本的な高品質を求められると向いてるとは言いがたいのが現状ではないかと思ったりします。将来的に変わってくかもしれないし、自分が知らないだけかもしれないけど。
エンタープライズではなく箱入り娘だと思えばなんかかわいいんですよね物理は。
