AWS 東急ハンズの事例 AWSサミット2013
66 likes27,444 views
2013年6月に行われたAWS Summit Tokyo 2013の東急ハンズの講演資料
AWS 東急ハンズの事例 AWSサミット2013
- 1. Copyright © 2013. All rights reserved. AWS Summit Tokyo 2013 『クラウド利用もハンズ流』 ～POSサーバーもAWSで～ 東急ハンズ 執行役員 ITコマース部長/ ハンズラボ 代表取締役社長 長谷川 秀樹
- 2. 講演者のご紹介 長谷川秀樹の 経歴概要 東急ハンズでの 挑戦 ハンズラボで 目指したいこと 1994年 アクセンチュア入社 ► 小売業を中心に業務改善、コスト削減、SI、ERP営業に従事 2008年 東急ハンズ入社 ► 情報システムとEコマースの責任者 ► ハンズラボ株式会社（IT会社）の代表取締役社長 自社従業員による自社開発への切り替え ► ホスト時代は情シスで開発していたのに、なぜ外注依存になったのか？ ► 「シンプルな技術で開発から運用までやる」という単純な結論 ► 今期でほぼ全領域を内製化、IT費用は就任時から半減 2013年4月 設立 ► 東急ハンズで培ったナレッジ、技術を展開し、「お客様に喜ばれるオー ダーメイドの仕組を誰よりも早く、安く提供する」の実現を目指す。 1
- 3. 2 クラウドに対する疑問 2008年にグーグルアップスを導入した時に、ご質問いただいた代 表的な内容です。（今は、流石にこういう疑問はないのかな） サービスの継続性はあるのか？ • グーグル社が、グーグルアップスをやめたらどうするのか？ ＳＬＡはどうなっているのか？ • ＳＬＡはどうなっているのか？また、そのＳＬＡをどうやって保証しているのか？ セキュリティー対策 • 社外にデータをおいて、大丈夫か。 値上げする可能性は？ • 安いと思って利用したら、突然グーグルの都合で値上げをされても困る。値上げしない保 証はあるのか？ １ クラウドに対する不安は、既存のパッケージベンダーにも同様な不安があるのでは ないでしょうか。 ２ クラウドは、（電話やネットワークのような）インフラですよね。データセンターができ た時代でもＤＣは（他人が入ってくるから危ない）とかあったのかなぁ・・・
- 4. AWS導入の背景と目的 BCP （事業継続性） Pliability （柔軟性） Speed! × Speed!! きっかけは”事業継続性”の検討（オンプレでは、コストが・・・） ► 3.11の震災を受けて、”業務を止めないシステム”、を改めて再考 ► 外部DCでの対応を、柔軟性のなさ、対応の遅さ、コストの高さから断念 ► AWSを想い出す・・AWSを使うんだったら、全部、移そう！ “読めない未来”に悩まない ► 出店、海外展開、新規事業等、事業展開は読みきれない（だから、 オンプレでの事前のサーバ保有、サイジングなど、もう、無理だな） いつでも、増やせる、減らせる、捨てられる、AWSの導入を決定 目指すは“スピード最速化” ► アプリは自社開発により”業界最高水準”のスピード開発を実現 ► アプリを支えるインフラ構築も自社化してより高速化を実現する 3
- 6. 5 AWS導入の基本方針 “リスク”という言い訳で”本丸”から逃げない。 断片的な取り組みこそが事業継続性を”リスク”にさらす。 基本方針 聖域を設けない そもそも論 AWSへの移行方針は2つだけ ► 新規システムはAWS。老朽化（償却）したシステムから移行。 求められるべきものは”気合いと根性” ► 聖域は設けず全部やる（という方針だから真剣に検証する） ► むしろ、一番難しいところから検証していかないとダメ ► （ダメだった時に、方針転換する。これを恥ずかしいと捉えてはダメ） やり切らなければ意味はない ► 例えば、リスクが低いものを対応して事業継続性は担保されるのか？ No！むしろ事業継続の観点では全く意味がない ► 例えば、ハイブリッド構成という名のもとに、webサーバのみ、AWSを使 う意味あるのか？ No！全部やろうじゃないか。
- 7. 6 AWS導入のロードマップ POSサーバーから基幹システムまで。 “聖域”なくどんどんやってみようじゃないか！ 実行済み 現在実行中 老朽化したもののリプレース新規導入 EC ’12.12’ File Server ’13.7’ MD@中国 ‘13.5’ 人事 (OBIC7) ‘見積中’ 会計 (SpStream) ‘13.7’ 勤怠管理 ‘13.10’ MD@日本 ‘13.12’ 顧客・ポイント管理 勘定系システム 経費精算 ‘13.10’ AD Server ‘13.7’ WSUS Server ‘13.6’ 業務 基幹 系 バック オフィス 系 POS Server ‘13.5’ （実行待ち） （昨年導入したばかり）
- 8. Tokyo Region Zone2 Zone1 事例）ECの多重化 新規構築したECにAWSを導入し多重化。使いたいときに使いたいだけ使う、1時間単位での課金を使いきるECの導入（DC冗長パターン）でAWSのナレッジを蓄積。 ECインフラ構成の概要 Web Server Web Server API Server API Server DC Users https://hands.net Point Server Hands-DB Zoneを分けて Web＋API Server を二重化 #1 #2 #3 一部AWS未対応の サーバーへはWeb- API経由でアクセス ELB Load Balancer 7
- 10. 9 柔軟性≠拡張性 “いつでも”×（増やせる＋減らせる＋捨てられる）＝柔軟性。 面倒なサイジングなんてもうやらない。 もうサイジングなんてしない ► サイジングは、ウォーターフォール時代の手法 発想の転換：帰宅時に消灯、サーバーも電源オフ ► 柔軟性を最大限に生かすため「夜間バッチ」の廃止にまで踏み込む なぜサイジングするの？ ► 簡単に増やせないし、とはいえ”多めの”費用も出したくないから でも事業展開（トランボリューム）は読み切れない ► サイジングの根拠となるトランザクション量は読み切れない ► 事業計画（出退店、海外展開、M&A等）は状況に応じ変わるから 求めたもの 柔軟性 そもそも論
- 11. 事例）POSサーバー導入（1/2） 一般的な構成 AWS導入前 小売業のよくある形 （出店のたびにサーバー購入が必要） 店舗サーバーをDCへ集約 （でもトラン量次第でメモリ等の増設が必要） DC Point MD集配信 POS Server 店舗A Point MD集配信 POS Server 使いたいときに使いたいだけ使う、1時間単位での課金を使いきる出店毎にかかるコストの最小化が課題 10 #1 #2 POS Server 新店 店舗A 店舗B 新店 DC 購入・設置 購入・設置
- 12. 事例）POSサーバー導入（2/2） 使いたいときに使いたいだけ使う、1時間単位での課金を使いきる“AWS”導入。トランザクション増に怯える日々からの解放。 AWS導入直後 目指す最終形 AWSを導入 （出店に伴う初期投資が不要に） https接続で効率最大化を目指す （上海店舗では実現済み） 11 店舗A 店舗B 新店 Point MD集配信 POS Server POS Server 店舗A 店舗B 新店 MD Server MD Server ELB Point POSサーバー、集配信の機能は MDへ統合、ELB経由で効率化 DC DC
- 14. 13 エコ計画）夜はサーバーを落とす “夜間バッチ”はもうやめよう。 ”リアルタイム化”で無駄な労力・コストを削減、エコにも貢献する。 夜間サーバー停止の効果見積り （クワドラプルエクストララージでの年額概算） 178.1 60.5 53.7 45.2 0 50 100 150 200 オンデマンド 中度リザーブド3年 重度リザーブド3年 中度リザーブド3年 ＋夜間8h停止 AWSだけで75％削減 ＋運用管理費の削減 （万円）
- 15. スペックを最低限にしても 固定費率が高く価格が下がらない 使いたいときに使いたいだけ使う、1時間単位での課金を使いきる小さいサーバほどAWS有利。大きくはじめて”どんどん小さく”。 オンプレとのコスト比較 14 オンプレミスの場合（5カ年概算） AWSの場合（重度リザーブ5ヶ年概算） 15.2 15.2 60.0 60.0 24.0 20.0 97.9 58.9 0 50 100 150 200 ハイスペック ロースペック 178.0 35.0 3.9 クワドラ Exラージ ラージ マイクロ AWS DC費用 HW保守 作業費 HW 197.1 154.1 AWSだと 柔軟なスペック選択が可能 CPU/Mem 以 外 は 固 定 費 万円
- 17. 16 スピードは全てを凌駕する スピードこそが、コストとリスクを抑える最大の手段。 アプリの“自社開発”と、インフラの“自社構築”で最速化を実現。 1つ目のエンジン＝自社開発（ユニークな開発手法） ► 業務を知る人間こそが、アプリ開発を最速化させる 2つ目のエンジン＝自社構築（AWS） ► アプリ開発者こそが、インフラが必要な”タイミングとスペック”を理解する コストはスピードに反比例する ► “単価×工数＝費用”、工数削減がコスト構造を根本的に変える スピード＝リスク？ ► とにかく早く作って、使ってみて、修正を入れる（アジャイル的発想） 最速化の手段 そもそも論
- 18. 17 事例）自社構築のメリット スピードの”高速化”。 自らが実行することで、全ての”無駄”を排除する。 見積・調達 オンプレミス時代（ベンダー依存） 搬入・設置 インストール 設定・テスト サイジング、金額等の調整 搬入までの待ち時間 AWS利用後（自社構築） DCへの搬入、ラック設置 入館等の諸手続き OS、ミドル等のインストール 設定の変更とテスト とにかく時間と労力とお金がかかりすぎる！ 設定変更とテストは必要 だけど自分達でやる！ 全ての無駄の排除 ≒ 最早・最安 見積・調達 搬入・設置 インストール 設定・テスト AWS使えば不要
- 19. 逆転の発想：インフラは自社でグリップ 一般的な情シス部門 東急ハンズの場合 使いたいときに使いたいだけ使う、1時間単位での課金を使いきる実は、AWSを使った自社インフラのほうが、自社アプリ開発より簡 単？（ハンズは、インフラは自社で準備していました） 18 ハードウェア OS・ミドルウェア ネットワーク アプリ、インフラともにベンダー委託 情シスはベンダー管理者として機能 アプリ、インフラ共に自社化 （スピード最速化には最適だが負担も大） アプリ開発は人数が必要 なためハードルは高い AWS使えばインフラは 特殊技能も不要なため 最小人員で回せる アプリ A アプリ B DC委託ベンダー 開発ベンダー 管理負担が高い 調整時間が多い 外部流出費最大 （コスト高） 情シスの課題 アプリ A アプリ B 自社開発 ハードウェア OS・ミドルウェア ネットワーク 自社構築ここから着手もアリ！
- 22. 21 ユーザー企業が求めるもの 我々は”事業会社”。（≠SIer） 我々は自分達が使い続けたい、”安さ”と”簡単さ”、を追及する。 難しい言葉は嫌い ► RAID01とか、ユーザー企業の人間はわからない ► 「冗長化する/しない」的な選択肢を辿ると、RAIDやロードバランサーの 構成が作られていることが理想的 AWSはいつも安い？ ► グーグル、Rackspace等、進化する競合との比較評価 （評価なんてしなくていいように”EDLP”でいてほしい） リクエスト③ より簡単に リクエスト② EDLP 世界のAWSへ ► 小売にとって海外進出は大きなキーワード ► これを支えるためには全世界の主要都市にAWSの拠点が欲しい リクエスト① 世界展開
- 23. Last Message（最後に） ITの”グリップ奪還” =Hands on IT 御清聴ありがとうございました エンジニア中途採用募集中です ⇒www.hands-lab.com