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)

ソリューション 「組み合わせ」でなく「すり合せ」

クルマが“パソコン”になる日

にもあるように、電気自動車により、自動車がコモディティ化してしまう可能性があるという。

エンジンは「すり合せ」技術が難しく参入障壁が高かったが、電気自動車になると「組み合わせ」技術で自動車が作れてしまう。実際、高速な電気自動車を作った会社は小さな会社だった。
自動車メーカでなくても自動車が作れる世界になてしまうと、日本の自動車業界はどうなってしまうのだろうか。

「組み合わせ」よりも「すり合わせ」か
この記事の「組み合わせ」と「すり合せ」の分析が秀逸だ。

IT業界における「ソリューション」とは、正に「すり合せ」技術の提案することである。
ユーザ「業務フロー」に「ソフトウェア」を「組み合わせ」て利用するだけでは、業務改善はなかなか行えない。ソリューションでは、そこで「すり合せ」を提案して、より効果的な「業務フロー」改善を提案することである。

ソリューションを提供してる会社だと謳ってる会社で、本当にソリューションを提供している会社はいったいどれだけあるだろうか。

ソリューションのパターン

ソリューションには大きくわけて３つのパターンがある。
1. 「箱売り型」ソリューション
単にソフトウェアを提供するだけのパターン。まったくもってソリューションではないのだが、多くの場合この「箱売り型」になってる状況である。

2. 「請け負い型」ソリューション
お客様の話しを聞き、それに答えるのがソリューションだと勘違いしているパターン。
お客：「こうしてくれないか」
営業：「はい、わかりました。」
の繰り返し。
これは、無償で「請け負い」開発をしてしまうパターン。
これでは業者が赤字を喰らってしまう。

3. 「提案型」ソリューション
お客様の話しから課題を見つけ、改善提案するパターン。これが本来のソリューションなのだが、これが出来てる会社って本当に少ない。改善提案のアイデアっていうのは、本当に難しい。営業やコンサルタントのセンスに寄るところが多いからである。

構造的にはこうなる。

1.「箱売り型」＝「組み合わせ」
2.「請け負い型」＝「組み合わせ」+α
3.「提案型」＝「すり合せ」

1. 2.　→　コモディティ化
3. 　　→　マーチャンタイズ化（差別化）

1.2.ではコモディティ化してしまうので、価格競争に陥って、業者は疲弊してしまう。ユーザもコストをかけて導入した割には業務改善を行えないという状況だ。
「提案型」こそ、顧客満足度を上げる手段であり、ユーザとIT業者が共存できる構造だろう。

ただ、「すり合せ」技術はアイデア次第なので、優秀な営業やコンサルタントが必須というところが難しいところである。

(参考)電気通信事業のコモディティ化とマーチャンダイズ化
(photo: puzzle by INTVGene)

日本メーカーが落ち目なワケ

言葉は要らない

http://2chcopipe.com/archives/51816464.html

「２位じゃダメなんでしょうか？」ではなく「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)