AWS 使い捨てサーバ Immutable Infrastructure

Immutable Infrastructure

稼働環境（Server）に変更をかけず、新バージョンの環境（Server）に切り替えるという運用スタイル。

これによるメリットは

１. 運用がシンプル

　使い捨ての考えで、サーバに変更をかけないので、新しいサーバに切り替えるというシンプルな運用方法が適用できる。

２. 環境がクリーン

　稼働中環境に変更を加えないので想定外の問題を抱えにくく、クリーンな環境を維持できる。

３.ロールバックが簡単

　新規環境に切替途中で問題が発生したら元に戻せば良い。

４.テスタビリティ

　テストした環境をそのまま公開できる。

Immutable Infrastructureの考え方により、BlueGreenDeploymentやAutoScaling(ここでは割愛)を実現すると。

BlueGreenDeployment

BlueGreenDeploymentの考え方は、新しいバージョンの環境を新規に立ち上げ、Routerで稼働中環境から切り替えるというものである。

稼働中環境(青色)から新環境(緑)に切り替えるのでBlueGreenDeploymentという。

(参考：BlueGreenDeployment)

Implementing Blue-Green Deployments with AWS

ここではAWSを使ってBlueGreenDeploymentを検証している。

１. Floating IPパターン
ELBを使用していないシンプルな構成の場合の話し。インスタンスのElastic IP Addressを付け替えるだけなので、DNSのTTLに影響されずサーバーを切り替えられる。但し、EIPの切り替えには通常数秒程度の時間がかかってしまうという注意点があります。

２. ロードバランサ配下のインスタンスの追加・削除
Auto Scaling Groupで、ELB APIを使ってGreenInstanceの追加とBlueInstanceの削除を行う方法。
注意点としては、ELBがヘルスチェックを行うため、Green Instanceにルーティングされるには遅延がある。
Amazon.comではこの方法を採用しているようである。
(参考:Amazonは1時間に最大1000回もデプロイする。クラウドネイティブなデプロイとはどういうものか？ AWS re:Invent基調講演（Day2 AM）)

３. AutoScalingのLaunch Configurationを使う方法
これは面倒だし、挙動が見えにくいので割愛。

４. Route53のDNSリダイレクトを使用する方法
ここでは３つの方法が紹介されています。
①CNAMEを変更する方法
②alias resource record setsを変更する方法
③Route53のCDP:Weighted Transitionパターンを使う方法
　これはBlue環境からGreen環境へ重み付けラウンドロビンで移行していく方法。
　メリットとして以下をあげている。
　（１）ほぼゼロのダウンタイム
　（２）Green環境でテストができる
　（３）カナリアリリースができる

５. AWS Elastic Beanstalkを使う方法

Green環境を構築し、Beanstalkの手順でアップデートするだけ。

Beanstalkは検証した事無いのでわかりませんが、ゼロダウンタイムリリースができるとのこと。

AWSのProgrammable Infrastructureのおかげでクラウドの世界がますます面白くなってきたと感じます。やってみたい方法としては、Route53のWeighted TransitionとBeanstalkかな。この辺の検証ができたらまた報告します。

(photo:UF Computers Monitors Keyboards Trash by Christopher Sessums)

「２位じゃダメなんでしょうか？」ではなく「AWSじゃダメなんでしょうか？」

日本のスーパーコンピューター京なんですが、開発費が1000億円かかったそうです。

スパコン性能ランキングは中国「天河2号」がトップ、「京」は4位

2013年11月版スーパーコンピューター処理能力ランキング「TOP500」によると、開発費20億円の中国「天河２号」が１位で、50億円の米国スパコンが２位だという。

しかも、京は維持費に年間数十億円かかっちゃうということなんで、１年間の維持費で「天河２号」をつくれちゃう。

こんなに金かけて恥ずかしくないんでしょうかね。

スピーディーなサービス化のために「作るより使え」という精神で

お金のかからない方法を考えたほうがよいのではないですかね。

【案１】維持費を天河２号の購入費にあてちゃう
京が出来ると、天気予報などのシミュレーションができますと言ってましたが、それは、天河２号でもできちゃんですね。やっぱり単に見栄のために1000億円かけたとしか思えません。

【案２】AWSを使う

分散アーキテクチャーをグリッドで使用すれば済むのでは？

AWSもTOP500リストに入ってます。Top500 List - November 2013
2011年11月 240.09TFLOPSで42位
2013年11月 484,2TFLOPSで64位
利用Core数やコストからすると、かなり善戦してるんじゃないでしょうか。

やっぱり京にかけた予算はあきらかに膨大すぎます。

「２位じゃだめなんでしょうか？」でなく
「AWSじゃだめなんでしょうか？」と言うべきだったのでは。

偽物クラウド サーバーメーカーが提供するのは単なるホスティング

サーバーメーカーが提供しているクラウドサービスは、ホスティングと一体何が違うのだろうか。
（サーバーメーカーというのは、IBM、HP、富士通など従来からコンピューターを提供してきたメーカー）

クラウドの定義も曖昧になっているが、バズワード化してるのはクラウドサービスを提供しているサーバーメーカーに問題があると思うんです。

優れたクラウドサービスを提供してきたのはサーバーメーカーではない。
優れらクラウドサービスは、PaaSレイヤーならGoogle App Engine、WIndows Azure、IaaSレイヤーならAmazon Web Serviceが優れたクラウドに該当するだろう。

クラウドサービスの利用者にとって重要な点は、「迅速な伸縮性」スケールアウト・インが無制限であるという点であろう。（アメリカ国立標準技術研究所による、クラウドコンピューティングの定義（出典：Publickey））

ここで言う「迅速な伸縮性」は、充分なコンピューターリソースが用意されていなければ成り立たない。しかし、サーバーメーカーのクラウドサービスで利用されるコンピューターリソースは、従来から提供してきた高価なコンピュータであることが多い。（それを売りにしているメーカーもある。）ハードが高価であり、さらに利用者が少ない事より充分なリソースが提供されてない。つまり、１ユーザにとって「無制限」ではなく、ホスティングと同じレベルの「有限」なのである。

また、ネットワークリソースに「迅速な伸縮性」が担保されてないことがほとんどだ。ネットワークがSPOFになることが多い。Firewall、Load Balancerなどのネットワークリソースをホスティングサービスと変わらない提供方法をしていることも共通している。
Firewall、Load Balancerの冗長性やスケールアウト性が無いのだ。

「富士通は従来からデータセンター型のサービス、アウトソーシングの受託をやってきている。これらも一種の「クラウド」だと考えている。」
(「クラウドに“寄せる”ことでコストは下がる」富士通・富田副社長)　
このコメントにあるように、提供する側の意識としては「ホスティング＝クラウド」なのだ。サービスを構築しようとする利用者は、実際使ってみて、はじめてクラウドIaaSではなくホスティングだと気が付くということになる。

GAEやAWSに追いつけないサーバーメーカーが、取り残される焦りで、「クラウド」と拡大解釈している状況なのだろう。
サーバーメーカーに、ホスティングとクラウドの違いを明確にしてもらいたいものだ。

(photo: Clouds by Karin Dalziel)