社内システムの - media.amazonwebservices.com · awsの初期利用 切っ掛け...
TRANSCRIPT
自己紹介氏名:月島 学
!
経歴:IT系メーカ、SIerを経て、
2002~ ガリバーインターナショナルに入社 ~2010 システムインフラの企画、構築、運用の統轄 ~2012 クラウド化のプロジェクトにて AWS中心としたシステムインフラ周りのクラウド化を推進 ~現在 社内システムのAWS化の推進とAWSの管理
!好きなAWSのサービス:VPC
2
会社紹介!
株式会社 ガリバーインターナショナル !
従業員数: 2,300名 店舗数: 420店舗 年間顧客数: 600,000名 年間買取台数: 200,000台 年間小売台数: 40,000台
3
社内システムの変遷 衛星システムの利用(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化
方針
出来るシステムから移行する 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から起動する 他リージョン、サブネットでの復旧も容易
・物理サーバの場合 場合によっては1回の修理で直らない場合がある 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
ASEANで800店舗展開2014年 03月 17日
タイに1号店 Open !AWSで稼働中 (Singapore Region)
!※基本の構成イメージ(AMIなど)はTokyo Regionからコピー
!
他、展開中・・・
過去、海外展開をした時は、 現地に合わせたインフラ作りに大苦戦・・・ AWSでは構成検討から構築が数日で完了
24
ASEANで800店舗展開オフショア開発との組み合わせ
AWSは日本で設定、運用 アプリはベトナムで構築、運用 ! 【データの受渡し、共有】 S3
【ドキュメント】 Google Drive 【コミュニケーション】 Hangouts 【課題管理】 Backlog
利用時のポイント
Regionによって利用できるサービス(VPCならAZの数や構成など)が多少違う
国内展開でも並行で実施中
25
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
今後の取組み②積極的なAWSの専門性の高いベンダーとの連携
社内システムの知識 (社内、業務系ベンダ) !AWS化の加速と高効率なAWS化
AWSを基盤とした新たなサービスの創出
Coming soon…
AWSサービス知識だけでなく、 豊富で多様な事例の所持が重要
事業の促進が本来の我々のミッション
AWSの専門的な知識 (パートナー:ベンダー)
! クラスメソッド社 ・AWSのサポートサービス ・ECサイトの移行や運用 ・新規サービス などを依頼
+
31