Mais conteúdo relacionado
Semelhante a Aws summits2014 ガリバーインターナショナル社内システムのaws化 (20)
Aws summits2014 ガリバーインターナショナル社内システムのaws化
- 2. 自己紹介
氏名：月島 学
!
経歴：IT系メーカ、SIerを経て、
2002～ ガリバーインターナショナルに入社
～2010 システムインフラの企画、構築、運用の統轄
～2012 クラウド化のプロジェクトにて
AWS中心としたシステムインフラ周りのクラウド化を推進
～現在 社内システムのAWS化の推進とAWSの管理
!
好きなAWSのサービス：VPC
2
- 3. 会社紹介
!
株式会社
ガリバーインターナショナル
!
従業員数： 2,300名
店舗数： 420店舗
年間顧客数： 600,000名
年間買取台数： 200,000台
年間小売台数： 40,000台
3
- 6. 社内システムの変遷
1998
衛星システムの利用（Dolphinetシステム）
社内システムのデータセンター移行
複数アーキテクチャの利用
システムの分散（複数のデータセンター利用）
アーキテクチャの統合
データセンター統合
Google Apps導入
Yammer導入
全営業スタッフへのiPadの導入
全直営店舗へのiMac、MBAの導入
現在
挑戦 ✖ 諦めない ＝ ガリバーの企業文化6
- 7. AWSの初期利用
切っ掛け
2010～2011年
iPadのテスト導入と共に、
そのインフラとして
AWSの利用を開始
項目AWS F社M社
コスト◎ △ △
利用開始までの
◎ △ -
手間、期間レスポンス◯ ◎ -
課金◎ △ -
サービス数◎ △ -
サービスの
◎ △ -
展開スピード
※所見です
当時のクラウドサービスの比較概要
圧倒的な優位性
7
- 9. AWSを利用して得たもの
【経営層からの要求】
!
・経営スピードの加速化
・経営資源の有効化
・事業の多面展開
・事業の継続性の向上
【AWSを利用して得たもの】
・高可用性
・高パフォーマンス
・導入、改修の加速
・少人数での運用
・低コストでの導入、運用
・セキュリティの底上げ
・資産管理の低減
・無駄なインフラの維持、転用の削減
≒ITチームの課題
AWS化により大きく貢献できる事を実感！！
9
- 11. 社内システムのAWS化
目標
2014年度末までにデータセンターで稼働
している全てのサーバをAWSに移行する
方針
出来るシステムから移行する
AWS上での稼働(移行)が優先
アプリケーション改修は少なく
新規構築、改修時にAWSの効果を高める
難易度、工期、コストを見て柔軟に
サービスを利用していく
まず、例外なしで考える
数百あるアプケーションを直すのは困難・・・
まずは移行が優先
11
- 12. 移行方針
なぜ、出来るシステムから行うか？
・予算がブレる
（移行にかかる費用が見積もれない、参考にならない）
・事業、業務優先
（システムが多く、時期、状態により優先順位が変わる）
・効果が確保されている
なぜ、効果が確保されているか？
・リプレースは老朽化対応を兼ねる
（バージョンアップ費用は老朽化対応費）
・EC2ベースでリプレースをしても、ほぼ回収できる
（まずは置換えで考える）
・確実に高い効果が見込める
ベンダが見積もれない事が殆ど
見積の見積がある場合も・・・
EC2は仮想サーバなので、OS以上は
物理サーバと同じ条件と考えられる
リプレース作業費
H/W 購入費
H/W 保守費
データセンター利用費
≧
予算を考える上で
IaaS ＜ PaaS ＜ SaaS
EC2 利用するサービスレイヤーが
高くなれば、効果も大きくなる
12
- 13. 移行方針
移行費用の考え方
移行をEC2メインで行うと作業の殆どがOS、M/Wのバージョンアップと動作確認
!
単純移行だけで見れば、AWS化に対する課題は少ない
少ないとはいえ、課題は確実にあるので、
予算の余裕は必要
セキュリティは大丈夫か？
AWSなら大丈夫
AWSを利用してもセキュリティを十二分に保全出来る
（DCやOSなどのインフラだけでなく、フルレイヤーで保全する必要がある。）
底上げ効果が期待できる
AWSで保全されているセキュリティは強力
HeartBleedにも翌日対応完了
13
MicrosoftのライセンスのSAは要注意
- 14. 得られる効果
構築スピードの向上
・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
- 15. なぜ、AWS？
AWSへの見方
Public or Private Cloud
ではなく
Private on Public Cloud
≒データセンター
データセンターに近しい構成が作れる
• VPC
• Direct Connect
• Tokyo Region
• EC2 （P2Vも出来る）
項目AWS F社B社M社
コスト(利用) ◎ ◯ ◯ ◯
コスト(中間) ◎ ◎ △ -
利用開始までの
手間、期間◎ ◎ △ ◎
レスポンス◎ ◎ ◎ ◯
課金△ ◎ ◎ ◎
機密性◎ ◎ ◎ △
サービス数◎ ◯ △ ◯
API ◎ ◯ △ -
展開規模◎ △ △ ◎
サポート◎ - - -
※所見です
クラウドサービスの比較
変わらず高い優位性
これが選定の決め手
・自動性
・利便性
・可用性
部分的に◯
15
- 16. 社内システムの特徴
• システム数は多い（大小合わせて数百）
• 関連ITベンダが多数
• 継ぎ接ぎシステムが多い
• 古いOSも多数存在
• パッケージ、スクラッチ混在
• 中小規模のシステムで構成
• Microsoft Accessも多い
x86サーバ内 Windows率
その他
15.1%
Windosws
84.9%
Windows 内訳
2008 以降
15.82%
2003 以前
84.18%
バージョンアップを ※2013年期初時点
せざるを得ない16
- 17. 留意点
共有ストレージがない ＝ WSFCが組めない
Disk IOのレスポンス
ELBのセッション管理
Firewall（Security-Group）
パッケージソフトウェアのライセンス
} 業務システムでは重要ポイント
■ アプリやQueryの組替えで改善できる事が殆ど
■ アプリ、DB Query＝業務ロジック＝容易に組替えられない
■ 短期的にはインフラ(EC2)の構成で検討せざるを得ない
もちろん並行して、アプリも改修をしていく
【利用時のポイント】 ～AWSの主なストレージサービス～
【S3】EC2上のWSFCから共有ストレージとして見えない
【EBS】単一EC2 Instanceからしかアクセスできない
【Storage Gateway】EC2上のWSFCから共有ストレージとして見えない
特にDB
17
- 19. 移行時の問題
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
- 20. 課題
運用、構築の自動化
自動化がし易い事がAWSの大きなメリット
!
システム、運用の平準化を行っていく
システムの疎結合化
複数のアーキテクチャ、サービスの連携、利用をしていく為
!
少しずつでも作り変えていく
H/Wレスポンスが必要なものは要検討・・・
基本はAWS化でまずは考える
AWS化できないシステム
データ連携などで物理的な設備、通信が必要なシステム
超レガシーなシステム
自動化にも繋がる
OSSも積極的活用
ー 自動化のメリット ー
・ミス（リスク）の低減
・構築、運用の対応速度の向上
・運用体制のスリム化
20
- 24. ASEANで800店舗展開
2014年 03月 17日
タイに１号店 Open
!
AWSで稼働中
(Singapore Region)
!
※基本の構成イメージ(AMIなど)はTokyo Regionからコピー
!
他、展開中・・・
過去、海外展開をした時は、
現地に合わせたインフラ作りに大苦戦・・・
AWSでは構成検討から構築が数日で完了
24
- 27. VPN in VPC
利用用途： システム保守ベンダのリモート保守接続
コスト削減
システム／資産の管理、運用などからの解放
!
以前の構成
インターネットVPN
保守専用網
!
利用時のポイント
ルータでのACL
BGPの知識が少し必要
構成概要
冗長化前提
27
- 29. 今後の取組み①
AWSのサービスの活用
RedShiftやElastic Beanstalk、Data Pipelineなどの
PaaS、SaaSレイヤのサービスの活用
!
少しずつ試験的に実装
使うポイントの見極めが重要
“今”の社内システムの
AWS化は今後の布石
他クラウドとの連携
Google, Yammer, xxxxxxなど様々なクラウドサービスとの連携
Service Oriented な Cloud 利用
比較もしながら
メール、スケジュール、掲示板、SNS、ドキュメント、
社内向けサイト、テレビ会議、その他・・・Coming soon…
29
- 31. 今後の取組み②
積極的なAWSの専門性の高いベンダーとの連携
社内システムの知識
（社内、業務系ベンダ）
!
AWS化の加速と高効率なAWS化
AWSの専門的な知識
（パートナー：ベンダー）
AWSを基盤とした新たなサービスの創出
Coming soon…
AWSサービス知識だけでなく、
豊富で多様な事例の所持が重要
事業の促進が本来の我々のミッション
!
クラスメソッド社
・AWSのサポートサービス
・ECサイトの移行や運用
・新規サービス などを依頼
＋
31
