2014.07.17
社内システムの
AWS化
ガリバーインターナショナル
月島 学

自己紹介
氏名：月島 学
!
経歴：IT系メーカ、SIerを経て、
2002～ ガリバーインターナショナルに入社
～2010 システムインフラの企画、構築、運用の統轄
～2012 クラウド化のプロジェクトにて
AWS中心としたシステムインフラ周りのクラウド化を推進
～現在 社内システムのAWS化の推進とAWSの管理
!
好きなAWSのサービス：VPC
2

会社紹介
!
株式会社
ガリバーインターナショナル
!
従業員数： 2,300名
店舗数： 420店舗
年間顧客数： 600,000名
年間買取台数： 200,000台
年間小売台数： 40,000台
3

ビジネスモデル
おクルマの買取、販売
その他、自動車流通に関わる事業も
4

AWS利用の経緯
5

社内システムの変遷
1998
衛星システムの利用（Dolphinetシステム）
社内システムのデータセンター移行
複数アーキテクチャの利用
システムの分散（複数のデータセンター利用）
アーキテクチャの統合
データセンター統合
Google Apps導入
Yammer導入
全営業スタッフへのiPadの導入
全直営店舗へのiMac、MBAの導入
現在
挑戦 ✖ 諦めない ＝ ガリバーの企業文化6

AWSの初期利用
切っ掛け
2010～2011年
iPadのテスト導入と共に、
そのインフラとして
AWSの利用を開始
項目AWS F社M社
コスト◎ △ △
利用開始までの
◎ △ -
手間、期間レスポンス◯ ◎ -
課金◎ △ -
サービス数◎ △ -
サービスの
◎ △ -
展開スピード
※所見です
当時のクラウドサービスの比較概要
圧倒的な優位性
7

AWSの稼働実績
iPadを活用したテーマパーク型
大型展示場モデル
WOW!TOWN
全営業スタッフへの
iPad導入
インフラは全てAWSで稼働
Elasticなインフラを享受
構成を組替えしながらの構築
8

AWSを利用して得たもの
【経営層からの要求】
!
・経営スピードの加速化
・経営資源の有効化
・事業の多面展開
・事業の継続性の向上
【AWSを利用して得たもの】
・高可用性
・高パフォーマンス
・導入、改修の加速
・少人数での運用
・低コストでの導入、運用
・セキュリティの底上げ
・資産管理の低減
・無駄なインフラの維持、転用の削減
≒ITチームの課題
AWS化により大きく貢献できる事を実感！！
9

社内システムのAWS化へ
10

社内システムのAWS化
目標
2014年度末までにデータセンターで稼働
している全てのサーバをAWSに移行する
方針
出来るシステムから移行する
AWS上での稼働(移行)が優先
アプリケーション改修は少なく
新規構築、改修時にAWSの効果を高める
難易度、工期、コストを見て柔軟に
サービスを利用していく
まず、例外なしで考える
数百あるアプケーションを直すのは困難・・・
まずは移行が優先
11

移行方針
なぜ、出来るシステムから行うか？
・予算がブレる
（移行にかかる費用が見積もれない、参考にならない）
・事業、業務優先
（システムが多く、時期、状態により優先順位が変わる）
・効果が確保されている
なぜ、効果が確保されているか？
・リプレースは老朽化対応を兼ねる
（バージョンアップ費用は老朽化対応費）
・EC2ベースでリプレースをしても、ほぼ回収できる
（まずは置換えで考える）
・確実に高い効果が見込める
ベンダが見積もれない事が殆ど
見積の見積がある場合も・・・
EC2は仮想サーバなので、OS以上は
物理サーバと同じ条件と考えられる
リプレース作業費
H/W 購入費
H/W 保守費
データセンター利用費
≧
予算を考える上で
IaaS ＜ PaaS ＜ SaaS
EC2 利用するサービスレイヤーが
高くなれば、効果も大きくなる
12

移行方針
移行費用の考え方
移行をEC2メインで行うと作業の殆どがOS、M/Wのバージョンアップと動作確認
!
単純移行だけで見れば、AWS化に対する課題は少ない
少ないとはいえ、課題は確実にあるので、
予算の余裕は必要
セキュリティは大丈夫か？
AWSなら大丈夫
AWSを利用してもセキュリティを十二分に保全出来る
（DCやOSなどのインフラだけでなく、フルレイヤーで保全する必要がある。）
底上げ効果が期待できる
AWSで保全されているセキュリティは強力
HeartBleedにも翌日対応完了
13
MicrosoftのライセンスのSAは要注意

得られる効果
構築スピードの向上
・EC2の場合
テンプレート（AMI）から起動
リソースの上限が事実上ない
・物理サーバの場合
物理的な作業が多く、人も時間も必要
システム障害時の機会損失の削減
・EC2の場合
Stop/Startで異なるH/Wから起動する
他リージョン、サブネットでの復旧も容易
・物理サーバの場合
場合によっては１回の修理で直らない場合がある
H/W保守の加入が必要
EC2
物理
設計
起動(調達)
OSの設定
アプリの実装
0 4 8 12 16
購入したら変更できない使い続ける必要がある
他の作業が遅れる
一般的なH/W障害系の場合はこれで復旧します
EC2
物理
障害切分け
準備
障害対応
動作確認
(日)
0 2 4 6 8
(時)
Cloud Formationを使えば更に早く
14

なぜ、AWS？
AWSへの見方
Public or Private Cloud
ではなく
Private on Public Cloud
≒データセンター
データセンターに近しい構成が作れる
• VPC
• Direct Connect
• Tokyo Region
• EC2 （P2Vも出来る）
項目AWS F社B社M社
コスト(利用) ◎ ◯ ◯ ◯
コスト(中間) ◎ ◎ △ -
利用開始までの
手間、期間◎ ◎ △ ◎
レスポンス◎ ◎ ◎ ◯
課金△ ◎ ◎ ◎
機密性◎ ◎ ◎ △
サービス数◎ ◯ △ ◯
API ◎ ◯ △ -
展開規模◎ △ △ ◎
サポート◎ - - -
※所見です
クラウドサービスの比較
変わらず高い優位性
これが選定の決め手
・自動性
・利便性
・可用性
部分的に◯
15

社内システムの特徴
• システム数は多い（大小合わせて数百）
• 関連ITベンダが多数
• 継ぎ接ぎシステムが多い
• 古いOSも多数存在
• パッケージ、スクラッチ混在
• 中小規模のシステムで構成
• Microsoft Accessも多い
x86サーバ内 Windows率
その他
15.1%
Windosws
84.9%
Windows 内訳
2008 以降
15.82%
2003 以前
84.18%
バージョンアップを ※2013年期初時点
せざるを得ない16

留意点
共有ストレージがない ＝ WSFCが組めない
Disk IOのレスポンス
ELBのセッション管理
Firewall（Security-Group）
パッケージソフトウェアのライセンス
} 業務システムでは重要ポイント
■ アプリやQueryの組替えで改善できる事が殆ど
■ アプリ、DB Query＝業務ロジック＝容易に組替えられない
■ 短期的にはインフラ(EC2)の構成で検討せざるを得ない
もちろん並行して、アプリも改修をしていく
【利用時のポイント】 ～AWSの主なストレージサービス～
【S3】EC2上のWSFCから共有ストレージとして見えない
【EBS】単一EC2 Instanceからしかアクセスできない
【Storage Gateway】EC2上のWSFCから共有ストレージとして見えない
特にDB
17

移行時の問題
社内外のAWSに関する知識、理解の不足
AWSへの理解不足から、作業／対応が見積もれなかったり、対策案がでない
!
考え方の共有、勉強会、やってみる、試してもらう
ライセンス
クラウド用のライセンスが用意されていない
!
交渉あるのみ・・・
ELBのセッションとロードバランス
BIG-IP(L7)からの脱却（Cookieへ）
無通信時のタイムアウトの把握
OSSの知識も
ケースを作って、横展開する
18

移行時の問題
SQL Server (on EC2)の冗長化時のレスポンス
業務システムでは冗長化が求められる
!
冗長化のオーバーヘッドが大きい
構成、リストア方法は要検討
アプリやQueryの改修ができれば、
一番好ましい
SQL Serverの冗長化
EC2には共有ストレージがない
!
簡単にWSFCが組めない
クラスタ専用S/Wを使った方が早い
DBレスポンスの比較例
手段WSFC with
DataKeeper
レスポンス
Cluster
専用M/W DB Mirror SQL Server
AlwaysOn
コスト◯ ◯ ◎ (Ente△rprise
対応DB Ver. 2012～ Software
による2005～ 2012～
DB
パフォーマンス◯ ◯ △ -
切換え
レスポンス◯ Software
による◎ ◯
構築／運用◎ △ ◯ -
※所見です
Single
(非同期) Cluster SW (同AZ)
(同期) Cluster SW (同AZ)
(同期) Cluster SW (別AZ)
0% 100% 200% 300%
(%)
DB冗長化方法の比較
RDSのSQL Server
の今後の対応に期待
19

課題
運用、構築の自動化
自動化がし易い事がAWSの大きなメリット
!
システム、運用の平準化を行っていく
システムの疎結合化
複数のアーキテクチャ、サービスの連携、利用をしていく為
!
少しずつでも作り変えていく
H/Wレスポンスが必要なものは要検討・・・
基本はAWS化でまずは考える
AWS化できないシステム
データ連携などで物理的な設備、通信が必要なシステム
超レガシーなシステム
自動化にも繋がる
OSSも積極的活用
ー 自動化のメリット ー
・ミス（リスク）の低減
・構築、運用の対応速度の向上
・運用体制のスリム化
20

更なる効果
21

多業態店舗の展開
22

国内店舗の倍増
2018年 2月末までに
!
420店舗
800店舗
※店舗系システムのAWS化が優先度高
23

ASEANで800店舗展開
2014年 03月 17日
タイに１号店 Open
!
AWSで稼働中
(Singapore Region)
!
※基本の構成イメージ(AMIなど)はTokyo Regionからコピー
!
他、展開中・・・
過去、海外展開をした時は、
現地に合わせたインフラ作りに大苦戦・・・
AWSでは構成検討から構築が数日で完了
24

ASEANで800店舗展開
オフショア開発との組み合わせ
AWSは日本で設定、運用
アプリはベトナムで構築、運用
! 【データの受渡し、共有】 S3
国内展開でも並行で実施中
【ドキュメント】 Google Drive
【コミュニケーション】 Hangouts
【課題管理】 Backlog
利用時のポイント
Regionによって利用できるサービス
（VPCならAZの数や構成など）が多少違う
25

すぐにでも出来る
AWSの構成事例
26

VPN in VPC
利用用途： システム保守ベンダのリモート保守接続
コスト削減
システム／資産の管理、運用などからの解放
!
以前の構成
インターネットVPN
保守専用網
!
利用時のポイント
ルータでのACL
BGPの知識が少し必要
構成概要
冗長化前提
27

SES
利用用途： システムからのメール送信
メールシステムのセキュリティの維持やパフォーマンス維持
システム／資産の管理、運用などからの解放
!
以前の構成
アプライアンスシステムと
メールサーバの併用
!
利用時のポイント
認証(ドメイン／ユーザ）を
複数リージョンで行っておく
Bounce mailの処理
構成概要
28

今後の取組み①
AWSのサービスの活用
RedShiftやElastic Beanstalk、Data Pipelineなどの
PaaS、SaaSレイヤのサービスの活用
!
少しずつ試験的に実装
使うポイントの見極めが重要
“今”の社内システムの
AWS化は今後の布石
他クラウドとの連携
Google, Yammer, xxxxxxなど様々なクラウドサービスとの連携
Service Oriented な Cloud 利用
比較もしながら
メール、スケジュール、掲示板、SNS、ドキュメント、
社内向けサイト、テレビ会議、その他・・・Coming soon…
29

ECサイトのAWS化
221616.comサイトのAWS化
30

今後の取組み②
積極的なAWSの専門性の高いベンダーとの連携
社内システムの知識
（社内、業務系ベンダ）
!
AWS化の加速と高効率なAWS化
AWSの専門的な知識
（パートナー：ベンダー）
AWSを基盤とした新たなサービスの創出
Coming soon…
AWSサービス知識だけでなく、
豊富で多様な事例の所持が重要
事業の促進が本来の我々のミッション
!
クラスメソッド社
・AWSのサポートサービス
・ECサイトの移行や運用
・新規サービス などを依頼
＋
31

ご清聴、ありがとうございました。