2013年6月8日土曜日

乗り遅れてるSIerとして感じた #awssummit

AWS全く使っていない、クラウドなにそれ美味しいの的なレベルの、危機感を感じているSIer(インフラ)の目線で書きます。

2013/06/06 (Wed)に、awssummitに参加して来ました。

■awssummitとは?
Amazon Web Service のカンファレンスです。
毎年やっているみたいですが、私は今回が初参加でした。
全2日間あるうちの2日目のみ参加。



■公式ページ
http://www.awssummittokyo.com/?id=awswebsite
こんなかんじで、なんというか、スタートアップ的感情をくすぐられるデザイン。
いいですね。
このサイトが、イベント決済のシステムと連動していて、まずそこのアカウントを作ってから、申し込む必要がありました。
しかし、知ったのが1週間前だったので、人気のセッションはほとんど売り切れ。
残ってるものの中から興味があるものをチョイスして登録。
そして基本的に企業名とか書かなきゃいけないので、会社に在籍してるって大事だよなぁと振り返るように思いました。



■入場
品川のグランドプリンスホテル新高輪というところでした。
入り口がオシャレに撮れました。



あったこれだ、と思って地下二階に行ったんですけど…、




ホテルの従業員さん「Amazonさんのイベントは一階のずーっと奥だよ!」
なんと、ここはAmazon Data Service Japanの社員の皆様のためのスペースでしたwww
なんとか受付をすませて会場入り…。



■キーノート




こういうカンファレンスとかはたいていキーノートっていう開幕だけどまとめみたいなプレゼンがあるみたいです。
カンファレンスとか一回も行ったことなかったけどTwitterで学びました。
ネットって本当に凄いですよね。
メインスピーカーというか司会というかプレゼンターはアマゾン データ サービス ジャパンの社長の長崎さんという方。

1時間遅れで会場入りしたので、三井物産のプレゼンがちょうど終わるところからでした。
キーノートを聴いて感じたのは、やっぱり使ってもない立場でネットから流れてるおこぼれだけで情報を形成してると、明らかに情報が古くなるなぁと。
たとえばAWSはいわゆるパブリッククラウドですが、フツーに専用線とかVPNでセキュアネットワークを構築することが可能になっているとのこと。
そのため、「パブリッククラウドによるセキュリティの問題なんて殆ど無いんじゃないでしょうか」とか、「サーバをAWS上に移しただけでISMS取れたお客様もいます」なんていう発言を聞くことができ、すげぇと思いました、純粋に。

基本的に、「こんな事例がある、これからこうしたら?AWSで。AWSならヤバい感じでできるぜ?」というような意味の内容の説明の繰り返しだったんですが、プレゼンターの長崎さんがすごく上手い煽り方(聴衆の気持ちの乘せ方)で結構なんというか、胸熱というか、ヤバいというか、そういう感情を抱きながら壇上を見つめてた方も多かったのではないでしょうか。
SIerに勤務している私としてはやっぱり、「脅威の黒船が仕事をかっさらっていく!」みたいな語り口でAWSが話題にあがることが多いですから、再び危機感に煽られましたよねw
でもこういう感情はきっと大切なんですよね。
ビジネスは加速させてなんぼ、でしょうから。

それから個人的に強く印象にのこってるのは、「量の変化がしきい値を超えると質の変化になる。」という言葉と、「重力には逆らえないのではないか」 という言葉。
質的変化を起こすために我々エンジニア(もどき)は何回も勉強して、失敗して、トライ・アンド・エラーで進んでいくべきだし、今自分が一生懸命になっていることは後の質的変化につながるんだろうと思うと、なんというかグッと来ました。確か日立の社長さんが言ってたかな?
「重力には逆らえないのではないか」はAmazonの長崎さんがおっしゃってたのですが、これはもうほんとにその通りで、「クラウド化(インフラのAWS化)」は止められないでしょう。
少なくとも日本企業には。
そういう話は話題のここで散々語られているので、これくらいにしたいと思いますが…。
(ちなみにリンク先のブログとここは何の関係もなく、ただリンクを貼らせていただいているだけです…念のため。)

という感じの刺激的なキーノートでした。

キーノートが終わったら昼食で、周りの皆さんは会場で用意されているおいしそうな食べ物に群がっていたので、私はダイエットも兼ねて昼食はあきらめ、いくつか展示を回ってみることにしました。
展示は主に「自社プロダクトがAWSでこんなことできます・こんな連携します」というものと、「AWSのインテグレーション(構築・運用保守)承ります!」っていう自社の業務紹介系が多かったです。
Twitterで流れてた「RedHatの薄い本」ももらえたし、色々お話を聴いてインプットできて良かったです。


写真ほとんど撮ってないですね私wこういうイベントは行き慣れてないので、今後はもっと「写真とってもいいですか?」とかやって、なんか雰囲気が分かるような写真を撮りたいですね。

ということで、お昼が終わったら3つのセッションを聞きに行きました。



■デジタルマーケティングにおけるクラウド適用俯瞰図
http://www.awssummittokyo.com/session.html#DM-05
マーケティングに関する話題は、いま私が従事しているプロジェクトの事業ドメインから遠くて、深い話や専門用語はちょっと良くわからなかっったんですが、AWSのアーキテクチャのはなしをしてくださって、なるほどと思いました。
マーケティングのためにはまず大量にユーザ(Webサイト訪問者)からクッキーや訪問に関する様々な情報を取得し、保存し、解析する必要があるのですが、生データはS3などのストレージ系インスタンスに置いておき、そこからHadoop系のインスタンスとか、KVS系のインスタンスとかに渡してあげて、いじくって解析するっていうようなアーキテクチャになるみたいです。
静的コンテンツはS3とクラウドフロント、動的コンテンツはEC2とRDSと、コンテンツごとでインスタンスの種類を使い分けることで、いい感じにトラフィックをさばいて、遅すぎワロタみたいなことにならないようにしてるとのことです。
そしてやっぱり、クラウド(というかエラスティックな仮想環境)の何がいいかって「簡単にマシンを減らせること」ですね。
これは聴いたセッションの全てで言われていました。
そうなんですよ。プライベートクラウドでは、ホストマシン上のリソースの許す限りではいくらでも増やしたり減らしたりできるけど、ホストマシンが許すリソースを越えることはなかなかできない。プロビジョニングはできますけど、ぶっちゃけすぐに「あんたそれは期待しすぎや!」って感じで性能ダウンしちゃいますし。
それに逆に全然要らなくなった場合に、ホストマシンを半分にザクっと切って省力化できますか?っていうと、出来ないですよね…。
と、改めて「Elastic」のすばらしさを痛感。まだ使ったこと無いけど…w
あとスピーカーがおっしゃってたなかで、「システム設備投資に関する事業計画が実証ベースになるので、より正確になる。」っていうのがありました。
これは思わぬ良い副作用でしょうね。
最初だけちょっと誤差の大きい投資をして業務のAWS上での稼働実績をつくれば、今後はそれをベースに次の投資の程度が判断できますもんね。


■グローバル展開も視野に入れた、協和発酵キリンのクラウド活用事例
http://www.awssummittokyo.com/session.html#EP-07

ユーザ起業からみたシステム開発・運用に関する視点を多く確認できてよかったです。
仮想化技術を使ってプライベートクラウドを構築しても、ハイパーバイザやハードウェアのリプレイスは避けられないですよね。
SIerとしてはそれは仕事の機会と捉えちゃう、つまり良い事ですが、ユーザ企業からすると金と労力のムダでしかない。
「『サーバ飼い』なんて言葉もありましたが、私達はシステムを別に維持したいわけではなくて、『業務をより良く』したいんです。」というプレゼンターの方の発言が印象的でした。
ある程度力のあるIT組織を持つユーザ企業は思っているはずですよね。「辛いばっかりのリプレイスとかいった「オンプレのしがらみ」から脱却できないのだろうか」と。
ただ、AWSは従量課金制なので、利用料の制御がきちんとできていないと思わぬ痛みを伴うことがあるようですね。
社内にAWS上でのシステムを構築する歳は、コスト抑止策や課金について考慮する必要があります。
運用面については、「データセンタの運営」と同じ扱いで運用を行なっている」とのこと。AWSの利用は申請によって許可されます。
「マルチクラウドサービスの運用統治」が必要とおっしゃっていました。
「クラウドはサービスレベルが一方的だったり、選択制だったりする。しかしそういうものをうまく使いこなさないといけない」といったことが苦しんだようです。
そのへんはITILの出番ですね。ただ、社内手続きでクラウドの即効性を相殺するようにはしたくないですね。
サービスストラテジのレベルからITILをベースに、クラウドのスピードを殺さない業務の回し方を考えてみたいものです。


■コンテンツの変化はインフラの変化 ソーシャルゲーム vs. バンダイナムコゲームスの適応力
http://www.awssummittokyo.com/session.html#CS-07

バンダイナムコゲームスのソーシャルゲームのインフラについてでした。
オンプレの仮想化基盤資産があるので、原則オンプレだが適材適所で利用しているとのこと。
会社的には、「原則はオンプレ仮想基盤、適宜AWS」という方針だそうな。
アーキテクチャとしては、やはりWebサーバなどのトラフィック処理はEC2インスタンスを増やしたりして対応する。
Queのインスタンスやメモリキャッシュのインスタンスなども使っており、PaaSインスタンスは色々使ってみようというスタンスのようでした。
安定しないとき(忙しい時)はとりあえずスケールアウトする。それで凌いでから、チューニングし、そのあとスケールイン(サーバを減らす)していくというやり方でやってますということでしたが、おそらくどんな企業も高負荷時の対応はそのようになりそうですね。
それから、構成管理の効率化しないと辛いですよという言葉にはうなずきました。一括変更出来る仕組みあればとっさのチューニングにも対応できますが、そうでなければ数十のインスタンスに一つ一つ入っていったり…ってなっちゃいますもんね。
chefやPuppetでインスタンスの構成管理を…その辺もいじったことないなぁ。勉強しないと。
それから、バッドノウハウを簡単に紹介されていて、凄くためになりそうでしたが、残念ながら記録できておらず。
たとえばAmazonRDSっていうデータベースのインスタンスが凄く遅くなった場合には、更新頻度が多いテーブルのIndex処理が終わってないから、Indexを貼り直しましたとか、DBレプリケーションが終わらないなーと思って確認したら、スレーブスペックがマスターより低すぎて、マスターが新規に生み出すレプリケーション対象データを追いかけきれないとか。
あとでスライドは公開される?(どのセッションも見れるのかな??)ようなので、もう一回確認したいと思います。


■画像保存・共有サービス「NIKON IMAGE SPACE」における海外展開へのクラウド活用
http://www.awssummittokyo.com/session.html#CS-08

NIKONはカメラを買ってくれたお客様に、タダで20GBのストレージ+リッチGUIでの写真管理スイートを提供しているらしいです。
初耳でした。しかも製品を買わなくても2GBまでのアカウントなら無料で作れるんだとか。へー。
今回のセッションはその写真管理スイートをリニューアルして海外展開するにあたり、海外顧客からの性能に関するクレーム(遅い)にどう対応するかみたいな話でした。
性能を改善するにあたって、問題が遠隔地からのアクセスなのでスループットが出ないといった場合は、プログラム側で対策することはできますが、サーバ自体を海外に置くほうが効果は高いですよね。
そこでAWS、みたいな流れでした。
 ・複数リージョンがあるから、アメリカ置いて、ヨーロッパに置いて、アジアに置いて、みたいなことができる
 ・少しだけ置いて試せる
 ・契約が簡単だし、すごく早い(一般的なエンタープライズ契約の速度だと数週間簡単に消費しますもんね)
Webサービスなので当たり前ですが、TCP/IPの知識とWebの知識を使って、速度検証を行い、想定しているいくつかのアーキテクチャ案をAWSで実際に構築して試して、使い方の選定を行ったというところは大事だと思いました。
これまた当たり前ですが、事前検証はしっかり行うべきですね。なかなかできないからみんな苦しんでたりするんでしょうけど。
今回はサービスリプレースなので移行に関する仕事が沢山あり、大変だったようです。自分がもしシステムアーキテクトとして構築に携わるときは、移行はものすごく大掛かりな作業なんだよ?ということを上層部が理解する、もしくは上層部に訴えかけるといったことを気をつけようと思いました。
固有のアーキテクチャの話としては、システムに必要なキャッシュ処理・ログイン処理をAWS上で構築するよう再考することによって海外の顧客に提供できる速度を改善したということでした。このへんはWebアプリシステム開発をやってない私はよくわかりませんでした。XMLの読み込みがどうのとか。
あと、国際回線の品質はばらつきがあり、アメリカでも一般家庭の回線は日本の10年前の速度以下とかだったりザラにあるようです。海外展開のときはその辺も気をつけておきたいですね。


■SIerはAWSという「重大事象」をどう受け止めるべきか
AWSは事業のスピードを明らかに加速させ、エンタープライズではなかなかやらせてもらえない、
トライ&エラーでのエコシステム実現に挑戦できる、とても良いプラットフォームなので、
使わない手はないですよね。ユーザ企業としては。

仕事を奪われる側のSIerは今後どうしていけばいいんでしょうか…。

まず、大きい話を考えるのが好きな私は、こんな図を作ってみました。



SIerの事業領域的にどうするかっていう視点です。
どこも大変そうなので、やっぱりこういうエコシステムを作って日本企業からお金を巻き上げまくっているAmazonはすごいと思います。

次に個人としてはどう受け止めればよいのか、自分の考えをまとめると以下の2点に集約されました。

(1)コア技術は変わらないので泣かなくてもいい
もう何回も耳にしていると思いますが、「クラウド」は全く新しい未知の技術、ではなく、既存の技術のオーサライズ、総集編、技術の集約と応用です。
つまり、「非クラウド」な技術しか今の仕事の周りに無くて、「クラウド」にあやかれない、クラウドを学びたくても学べない、置いてかれる……と、悲観することは無いと思います。
既存の技術、今自分が目の前で仕事としてやっている技術、それらをできるだけ広く吸収することで、「クラウド」を学習する上でのしっかりとした土台ができあがります。
クラウドを学ぶ際の学習スピードがどんどん早くなるということです。
AWSに限って言えば、AWSSummitを聞いていると、「『ものすごく高等なITインフラ知識のパズル』をやっているような感じだなぁ」という印象を受けました。
あらかじめパズルのはめ込み方、ピースの作り方を学んでおけば、いざ1000ピースの本番パズルを渡されても、すぐにこなせるようになるのではないでしょうか。

勉強の方針としては、まずはオンプレでいいので、会社ではできるだけ新しめ、そして大きめの案件に関われるように仕事を頑張ります。
そしてその傍らで、AWSはありがたいことに事例サイトなど積極的に情報共有をしてくださっているので、そのへんに目を通して、「自分がAWSを使ってシステムを作るなら」みたいな妄想をします。
会社では要素技術に注目しながら働けるといいですね。使った技術はタスクが消化できたら終わり~ではなく、できるだけ自分のものにしていきたいですね。


(2)サラリーマン経験として、クラウドを使ったシステムのDevOpsに携われるか
ただ、(1)のように頑張って勉強しても、日本社会は「経験」がめちゃくちゃ重要視されますから、「お前色々知ってるけどクラウドやったことねーじゃn」と今後理不尽?不都合な評価を受けることになるかもしれません。
そうならないために、会社でクラウドシステムの経験ができるとたぶん凄くいいですよね。
社内にすでにそういう部署やプロジェクトがあれば、参画を希望してみたり、ベンチャー的部署に配属されればそのうち「クラウドやろうぜ」となる可能性もあるでしょうね。
私はオンプレですが仮想化基盤のプロジェクトに参加させていただいているので、ここからどうやってパブリッククラウドやハイブリットクラウドへシフトしていけるのかということを考えないといけないのかもしれませんね。



以上、長ったらしいAWS Summitのまとめでした。