Transcript

• 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
• 5. BCP（事業継続性）“聖域”なき取り組み中途半端こそが最大のリスク
• 6. 5AWS導入の基本方針“リスク”という言い訳で”本丸”から逃げない。断片的な取り組みこそが事業継続性を”リスク”にさらす。基本方針聖域を設けないそもそも論 AWSへの移行方針は2つだけ► 新規システムはAWS。老朽化（償却）したシステムから移行。 求められるべきものは”気合いと根性”► 聖域は設けず全部やる（という方針だから真剣に検証する）► むしろ、一番難しいところから検証していかないとダメ► （ダメだった時に、方針転換する。これを恥ずかしいと捉えてはダメ） やり切らなければ意味はない► 例えば、リスクが低いものを対応して事業継続性は担保されるのか？ No！むしろ事業継続の観点では全く意味がない► 例えば、ハイブリッド構成という名のもとに、webサーバのみ、AWSを使う意味あるのか？ No！全部やろうじゃないか。
• 7. 6AWS導入のロードマップ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 RegionZone2Zone1事例）ECの多重化新規構築したECにAWSを導入し多重化。使いたいときに使いたいだけ使う、1時間単位での課金を使いきるECの導入（DC冗長パターン）でAWSのナレッジを蓄積。ECインフラ構成の概要WebServerWebServerAPIServerAPIServerDCUsershttps://hands.netPoint ServerHands-DBZoneを分けてWeb＋API Serverを二重化#1 #2 #3一部AWS未対応のサーバーへはWeb-API経由でアクセスELBLoadBalancer7
• 9. Pliability（柔軟性）使い倒す”勇気”サーバーの電源は帰宅時に落とそう!
• 10. 9柔軟性≠拡張性“いつでも”×（増やせる＋減らせる＋捨てられる）＝柔軟性。面倒なサイジングなんてもうやらない。 もうサイジングなんてしない► サイジングは、ウォーターフォール時代の手法 発想の転換：帰宅時に消灯、サーバーも電源オフ► 柔軟性を最大限に生かすため「夜間バッチ」の廃止にまで踏み込む なぜサイジングするの？► 簡単に増やせないし、とはいえ”多めの”費用も出したくないから でも事業展開（トランボリューム）は読み切れない► サイジングの根拠となるトランザクション量は読み切れない► 事業計画（出退店、海外展開、M&A等）は状況に応じ変わるから求めたもの柔軟性そもそも論
• 11. 事例）POSサーバー導入（1/2）一般的な構成 AWS導入前小売業のよくある形（出店のたびにサーバー購入が必要）店舗サーバーをDCへ集約（でもトラン量次第でメモリ等の増設が必要）DCPoint MD集配信POS Server店舗APoint MD集配信POS Server使いたいときに使いたいだけ使う、1時間単位での課金を使いきる出店毎にかかるコストの最小化が課題10#1 #2POS Server新店店舗A 店舗B 新店DC購入・設置 購入・設置
• 12. 事例）POSサーバー導入（2/2）使いたいときに使いたいだけ使う、1時間単位での課金を使いきる“AWS”導入。トランザクション増に怯える日々からの解放。AWS導入直後 目指す最終形AWSを導入（出店に伴う初期投資が不要に）https接続で効率最大化を目指す（上海店舗では実現済み）11店舗A 店舗B 新店Point MD集配信POSServerPOSServer店舗A 店舗B 新店MDServerMDServerELBPointPOSサーバー、集配信の機能はMDへ統合、ELB経由で効率化DC DC
• 13. 特に開店1～2時間は平日の200倍越え!（ハイスペックで使う）使いたいときに使いたいだけ使う、1時間単位での課金を使いきるバーゲンのトランザクションにあわせて、スペック変更（受注件数）事例）ECの特売対応ハンズメッセ期間の受注数推移05001,0001,5002,0002,5003,0003,5004,0004,5002日目以降は10倍程度（ミドルスペックにする）12
• 14. 13エコ計画）夜はサーバーを落とす“夜間バッチ”はもうやめよう。”リアルタイム化”で無駄な労力・コストを削減、エコにも貢献する。夜間サーバー停止の効果見積り（クワドラプルエクストララージでの年額概算）178.160.5 53.7 45.2050100150200オンデマンド 中度リザーブド3年 重度リザーブド3年 中度リザーブド3年＋夜間8h停止AWSだけで75％削減＋運用管理費の削減（万円）
• 15. スペックを最低限にしても固定費率が高く価格が下がらない使いたいときに使いたいだけ使う、1時間単位での課金を使いきる小さいサーバほどAWS有利。大きくはじめて”どんどん小さく”。オンプレとのコスト比較14オンプレミスの場合（5カ年概算） AWSの場合（重度リザーブ5ヶ年概算）15.2 15.260.0 60.024.0 20.097.958.9050100150200ハイスペック ロースペック178.035.0 3.9クワドラExラージラージ マイクロAWSDC費用HW保守作業費HW197.1154.1AWSだと柔軟なスペック選択が可能CPU/Mem以外は固定費万円
• 16. Speed! × Speed!!スピードは全てを”凌駕”する圧倒的な早さこそが最大の武器
• 17. 16スピードは全てを凌駕するスピードこそが、コストとリスクを抑える最大の手段。アプリの“自社開発”と、インフラの“自社構築”で最速化を実現。 1つ目のエンジン＝自社開発（ユニークな開発手法）► 業務を知る人間こそが、アプリ開発を最速化させる 2つ目のエンジン＝自社構築（AWS）► アプリ開発者こそが、インフラが必要な”タイミングとスペック”を理解する コストはスピードに反比例する► “単価×工数＝費用”、工数削減がコスト構造を根本的に変える スピード＝リスク？► とにかく早く作って、使ってみて、修正を入れる（アジャイル的発想）最速化の手段そもそも論
• 18. 17事例）自社構築のメリットスピードの”高速化”。自らが実行することで、全ての”無駄”を排除する。見積・調達オンプレミス時代（ベンダー依存）搬入・設置インストール設定・テスト サイジング、金額等の調整 搬入までの待ち時間AWS利用後（自社構築） DCへの搬入、ラック設置 入館等の諸手続き OS、ミドル等のインストール 設定の変更とテストとにかく時間と労力とお金がかかりすぎる！ 設定変更とテストは必要 だけど自分達でやる！全ての無駄の排除 ≒ 最早・最安見積・調達搬入・設置インストール設定・テストAWS使えば不要
• 19. 逆転の発想：インフラは自社でグリップ一般的な情シス部門 東急ハンズの場合使いたいときに使いたいだけ使う、1時間単位での課金を使いきる実は、AWSを使った自社インフラのほうが、自社アプリ開発より簡単？（ハンズは、インフラは自社で準備していました）18ハードウェアOS・ミドルウェアネットワークアプリ、インフラともにベンダー委託情シスはベンダー管理者として機能アプリ、インフラ共に自社化（スピード最速化には最適だが負担も大）アプリ開発は人数が必要なためハードルは高いAWS使えばインフラは特殊技能も不要なため最小人員で回せるアプリAアプリBDC委託ベンダー開発ベンダー 管理負担が高い 調整時間が多い 外部流出費最大（コスト高）情シスの課題アプリAアプリB自社開発ハードウェアOS・ミドルウェアネットワーク自社構築ここから着手もアリ！
• 20. 19事例）自社開発＆自社構築の恩恵自社開発した基幹システムをインフラ含めて”丸ごと”移植。“史上最速”の海外展開を実現する。展開済み展開予定上海台湾（FC店への展開）シンガポールマレーシア東京AWSがある国への海外展開は、ものすごく簡単！上海は東京AWSを利用（マレーシア店はシンガポールとする予定）現基幹システムをAWS上にコピーして立ち上げ使いながら各国向けカスタマイズし最終化
• 21. Request to AWSより”安く”、より”簡単”に我々は”進化と評価”を忘れない
• 22. 21ユーザー企業が求めるもの我々は”事業会社”。（≠SIer）我々は自分達が使い続けたい、”安さ”と”簡単さ”、を追及する。 難しい言葉は嫌い► RAID01とか、ユーザー企業の人間はわからない► 「冗長化する/しない」的な選択肢を辿ると、RAIDやロードバランサーの構成が作られていることが理想的 AWSはいつも安い？► グーグル、Rackspace等、進化する競合との比較評価（評価なんてしなくていいように”EDLP”でいてほしい）リクエスト③より簡単にリクエスト②EDLP 世界のAWSへ► 小売にとって海外進出は大きなキーワード► これを支えるためには全世界の主要都市にAWSの拠点が欲しいリクエスト①世界展開
• 23. Last Message（最後に）ITの”グリップ奪還” =Hands on IT御清聴ありがとうございましたエンジニア中途採用募集中です⇒www.hands-lab.com