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

社内システムの変遷　衛星システムの利用（Dolphinetシステム）

　社内システムのデータセンター移行

　複数アーキテクチャの利用

　システムの分散（複数のデータセンター利用）

　アーキテクチャの統合

　データセンター統合

　Google Apps導入

　Yammer導入

　全営業スタッフへのiPadの導入

　全直営店舗へのiMac、MBAの導入

1998

現在挑戦 ✖ 諦めない ＝ ガリバーの企業文化

6

AWSの初期利用切っ掛け

2010～2011年 iPadのテスト導入と共に、そのインフラとして AWSの利用を開始

項目 AWS F社 M社コスト ◎ △ △

利用開始までの 手間、期間 ◎ △ -レスポンス ◯ ◎ -課金 ◎ △ -

サービス数 ◎ △ -サービスの 展開スピード

◎ △ -※所見です

当時のクラウドサービスの比較概要

圧倒的な優位性7

AWSの稼働実績

iPadを活用したテーマパーク型 大型展示場モデル

WOW!TOWN

全営業スタッフへの iPad導入

インフラは全てAWSで稼働Elasticなインフラを享受

構成を組替えしながらの構築8

AWSを利用して得たもの【経営層からの要求】

!・経営スピードの加速化

・経営資源の有効化

・事業の多面展開

・事業の継続性の向上

AWS化により大きく貢献できる事を実感！！

【AWSを利用して得たもの】 ・高可用性 ・高パフォーマンス ・導入、改修の加速 ・少人数での運用 ・低コストでの導入、運用 ・セキュリティの底上げ ・資産管理の低減 ・無駄なインフラの維持、転用の削減

≒ITチームの課題

9

社内システムのAWS化へ

10

社内システムのAWS化

方針

出来るシステムから移行する AWS上での稼働(移行)が優先 アプリケーション改修は少なく 新規構築、改修時にAWSの効果を高める

目標

2014年度末までにデータセンターで稼働している全てのサーバをAWSに移行する

難易度、工期、コストを見て柔軟にサービスを利用していく

まず、例外なしで考える

数百あるアプケーションを直すのは困難・・・まずは移行が優先

11

移行方針なぜ、出来るシステムから行うか？ ・予算がブレる 　（移行にかかる費用が見積もれない、参考にならない） ・事業、業務優先 　（システムが多く、時期、状態により優先順位が変わる） ・効果が確保されている

なぜ、効果が確保されているか？ ・リプレースは老朽化対応を兼ねる 　（バージョンアップ費用は老朽化対応費） ・EC2ベースでリプレースをしても、ほぼ回収できる 　（まずは置換えで考える） ・確実に高い効果が見込める

リプレース作業費

H/W 購入費

H/W 保守費

データセンター利用費

≧

ベンダが見積もれない事が殆ど 見積の見積がある場合も・・・

EC2は仮想サーバなので、OS以上は物理サーバと同じ条件と考えられる

IaaS　＜　PaaS　＜　SaaSEC2 利用するサービスレイヤーが

高くなれば、効果も大きくなる

予算を考える上で

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

物理

0 4 8 12 16

設計起動(調達)OSの設定アプリの実装

購入したら変更できない使い続ける必要がある

他の作業が遅れる

EC2

物理

0 2 4 6 8

障害切分け準備障害対応動作確認

一般的なH/W障害系の場合はこれで復旧します

(日)

(時)

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） パッケージソフトウェアのライセンス

} 業務システムでは重要ポイント

【利用時のポイント】　～AWSの主なストレージサービス～

【S3】EC2上のWSFCから共有ストレージとして見えない 【EBS】単一EC2 Instanceからしかアクセスできない 【Storage Gateway】EC2上のWSFCから共有ストレージとして見えない

■ アプリやQueryの組替えで改善できる事が殆ど

■ アプリ、DB Query＝業務ロジック＝容易に組替えられない

■ 短期的にはインフラ(EC2)の構成で検討せざるを得ない

もちろん並行して、アプリも改修をしていく

特にDB

17

移行時の問題社内外のAWSに関する知識、理解の不足

AWSへの理解不足から、作業／対応が見積もれなかったり、対策案がでない !考え方の共有、勉強会、やってみる、試してもらう

ELBのセッションとロードバランス

BIG-IP(L7)からの脱却（Cookieへ） 無通信時のタイムアウトの把握

ライセンス

クラウド用のライセンスが用意されていない !交渉あるのみ・・・

OSSの知識も

ケースを作って、横展開する

18

移行時の問題SQL Server (on EC2)の冗長化時のレスポンス

業務システムでは冗長化が求められる !冗長化のオーバーヘッドが大きい 構成、リストア方法は要検討

SQL Serverの冗長化

EC2には共有ストレージがない !簡単にWSFCが組めない クラスタ専用S/Wを使った方が早い

手段 WSFC with DataKeeper

Cluster専用M/W DB Mirror SQL Server

AlwaysOn (Enterprise

コスト ◯ ◯ ◎ △

対応DB Ver. 2012～ Software による 2005～ 2012～

DBパフォーマンス

◯ ◯ △ -

切換えレスポンス

◯ Software による ◎ ◯

構築／運用 ◎ △ ◯ -

※所見です

Single(非同期) Cluster SW (同AZ)(同期) Cluster SW (同AZ)(同期) Cluster SW (別AZ)

0% 100% 200% 300%

レスポンス

(%)

DB冗長化方法の比較

DBレスポンスの比較例

RDSのSQL Serverの今後の対応に期待

アプリやQueryの改修ができれば、一番好ましい

19

課題運用、構築の自動化

自動化がし易い事がAWSの大きなメリット !システム、運用の平準化を行っていく

AWS化できないシステム

データ連携などで物理的な設備、通信が必要なシステム 超レガシーなシステム

システムの疎結合化

複数のアーキテクチャ、サービスの連携、利用をしていく為 !少しずつでも作り変えていく

H/Wレスポンスが必要なものは要検討・・・基本は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レイヤのサービスの活用 !少しずつ試験的に実装

他クラウドとの連携

Google, Yammer, xxxxxxなど様々なクラウドサービスとの連携 Service Oriented な Cloud 利用 メール、スケジュール、掲示板、SNS、ドキュメント、 社内向けサイト、テレビ会議、その他・・・Coming soon…

使うポイントの見極めが重要

“今”の社内システムの AWS化は今後の布石

比較もしながら

29

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

30

今後の取組み②積極的なAWSの専門性の高いベンダーとの連携

社内システムの知識 （社内、業務系ベンダ） !AWS化の加速と高効率なAWS化

AWSを基盤とした新たなサービスの創出

Coming soon…

AWSサービス知識だけでなく、 豊富で多様な事例の所持が重要

事業の促進が本来の我々のミッション

AWSの専門的な知識 （パートナー：ベンダー）

!　クラスメソッド社 ・AWSのサポートサービス ・ECサイトの移行や運用 ・新規サービス　　などを依頼

＋

31

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