クラウドへ基幹システムを移行する東急ハンズ。決断したきっかけ、システム構成、メリットを語る。AWS Summit Tokyo 2013

2013年6月10日

Amazonクラウドのイベント「AWS Summit Tokyo 2013」が6月5日、6日の2日間、都内で開催され、AWS（Amazon Web Services）を活用したさまざまな事例の紹介や技術者向けの解説などが行われました。

ここではそのセッションの中から、基幹システムをAWSへ移行している東急ハンズの事例を解説したハンズラボ長谷川氏のセッションをダイジェストで紹介します。東急ハンズはGoogle Appsを社内システムとしていちはやく採用するなど、クラウドへの積極的な取り組みで知られています。

クラウド利用もハンズ流。POSシステムもAWSで

ハンズラボ株式会社　代表取締役社長長谷川秀樹氏。

私はSIerも経験していて、2008年に東急ハンズに入社しました。エンジニアも営業もSIもやっていたことがあって、そういうバックグランドで今日はお話したいなと思っています。

東急ハンズでは自社従業員による自社開発を推し進めてきました。自社開発のナレッジもたまってきたので、外販向けの会社「ハンズラボ」を作って始めたところです。

AWS利用のきっかけはBCP

ハンズでAWSをいれるきっかけと目的。きっかけはBCP（事業継続計画）でした。3.11が起こって、私たちのデータセンターはやや海に近かったんですね。

AWSのいいところは、データセンターの冗長化が簡単にできること。

これは800億程度の会社では割に合いません。データセンターをもう1つ借りて、本番環境と同じサーバを入れて、必要なときにはデータセンターを切り替える。そうした事態が発生する確率と、それに対する投資額を考えるとなかなか難しい。しかしAWSはいとも簡単にそれができてしまうのが、AWSにシステムを移そうと思ったきっかけです。

次の2つ（Pliability、Speed!）も似たようなことを書いていますが、どちらもAWSでないとできないことなんです。コストではないんですね。

AWSのコストについてはいろんな人の話を聞きましたが、みなさん違うんです。すごく安いと思っている人と、高いよねと思っている人と。前提の違いによる。

コストが安いから移るというのは、そんなに得策ではないと思います。うちはAWSでしかできない、ということが理由でした。

AWSは本丸になる技術、やるならがっつり

AWSにシステムを移すときには、いちばんリスクが小さいところから試して、よかったら次の段階へ、というのが定石だと思います。しかし私たちは最初から基幹システムを検証しようと、それがだめだったらだめなんだよ、という考えで進めました。

いちばんよくないのが、ちょっとだけ試してみること。既存のデータセンターの運用を一生懸命やっているのに、そこへ新しいものを少しだけ増やというのは、それなんのためにやってるんだっけ？苦労は増えたけどメリットもないので元に戻してもよくない？となってしまう可能性があります。

それよりも、基幹でやってみて移せなかったら移せなかったでその経験は残るよねと。だめだったら1年後にまた検証するとか、スピードと検証コストなどを含めてクラウドへのマイグレーションをいちばん早くできるできるのはこの方法だと思います。AWSは本丸になる技術だと思いますので、やるならがっつりやるのがいいと思います。

そこで私たちは、新しいシステムはAWSで作っていこうと、昨年の10月に決めました。それから古いものもAWSへ移していくことにしました。2012年頃に作った、まだ新しいシステムは移す意味がないので、いずれ全部をAWSに移すのは決めていますが、古いものと新しいものから移行しています。

1ギガの専用線でAWSと接続

これがAWS導入のロードマップです。左のEC、POSサーバ、MDが実行済み、いま実行中なのが日本でのMDです。MDというのはマーチャンダイジングシステムで、小売りでいう基幹システムです。

クラウドへ移行して想定しなかったところもあります。例えばPOSでは時間になると自動で電源がはいる機能があります。これはWake On LANなのですが、AWSではそれを許していません。オンプレミスのシステムとクラウドではそういう違いはたしかにあります。

これが構成図です。オレンジがAWSで、灰色がうちのデータセンターです。AWSとデータセンターは1ギガの専用線でつなげています。ある程度以上の規模やなんだかんだで移行がある場合はこういうのがいいのではないかと思います。

AWSの中にZone1、Zone2とありますが、これがそれぞれデータセンターです。紫色のELBがロードバランサーで、どちらかのデータセンターが落ちてもうまくバランシングしてシステムが動き続ける、という仕組みになっています。こういうシステムをオンプレミスで組むのはめちゃめちゃお金がかかりますので、それがすぐできるのはいいのではないかな、と思います。

サイジングはもうやらない

サイジングについて。新しいシステムを構築するときにはサイジングするじゃないですか。僕は前職も含めて、サイジングが正確にできたことは一回もありませんでした。サイジングを本当に正確に、自信を持ってやっている人はいないと思います。

それでもパッケージソフトでユーザーが多くいて実績があるのならば、サイジングは可能ですが、新しいアプリでは無理ですよね。

だから弊社の場合、基本的にサイジングはもうやらないんです。これくらいのサーバスペックで動くだろうという余裕のあるところで始めて、スペックを減らしていけばいいんです。で、適当なところにきたらリザーブドインスタンスにしてがつっとおさえる、というのがいいと思います（注：AWSのリザーブドインスタンスとは、インスタンスを1年分や3年分まとめて予約することで安く利用できる仕組み）。

POSサーバをAWSへ移行した事例。いままでは店舗が1つ増えると、POSを買ってPOSサーバが増えると。POSが増えるのは仕方ないですが、POSサーバが増えるのはもったいないと思い、POSサーバを仮想化しました。

最初は1サーバで5店舗分はいけると思ったら3店舗分しかはいらず、それ以上増えると時間をかけて新しいサーバを買うしかありませんでした。

そこでAWSにしていこうと。図の黄色いところがPOSサーバです。最終的にはPOSサーバ、集配信の機能はMDサーバへ統合して、POSサーバはいらない。というのをイメージしています。

AWSではハードウェアの調達がないのがうれしい

オンプレミスとAWSのコストの比較。データセンターの費用はだいたい1Uで1カ月1万円としました。オンプレミスのサーバは、ハイスペックでもロースペックでも、かかる費用はあまり変わらないんです。

ところがAWSではすごく小さなマイクロインスタンスではすごく安くなるので、管理サーバのようなのはマイクロインスタンスを使えばいいのではないかなと思います。ただこの比較はオンプレミスのサーバを仮想化していないので、仮想化を使うと右のAWSに似たような感じになると思いますが。

われわれはどんどんシステムを作っていますが、AWSではハードウェアの調達がないのはすごくうれしいんです。

ハンズラボではシステムの外販もやっていますが、サイジングなどの心配がまったくない。労力と時間、オンプレミスではこれがかかりすぎているのではないかと思います。

インフラは自社でやる、というのもあり

ソフトウェアの開発者を育てるのと、インフラエンジニアを育てるのでは、インフラエンジニアを育てる方が難しいと思いますよね？しかしAWSを使うと分かりますが、AWSはいじるのが簡単なので、アプリケーションレイヤーは外部に頼んで、インフラは自社でやる、という世界もあるのではないかなと思います。

例えばシステム構築をNECさんに頼むとNECさんがサーバを持ってきますよね。しかしハンズでは私たちがインフラを用意する、ということでやってきました。そうでないとシステムごとにベンダが違ってバックアップ機器とかがどんどん増えていってしまうんですよね。だから「サーバはこちらで用意するから必要なスペックだけ教えてくれ」と言ってきました。インフラは自分で用意する、というのはありだと思います。