スライド 0

基幹システムのクラウド化を
実現するための実践的ノウハウ
AWS Summit Tokyo 2014
Day2 2014/7/18 (金)12:20-13:00
Tech Deep Dive by Customers TC-06
情報システム部長 篠田敏幸
協和発酵キリンの概要
•設立
: 1949年(昭和24年)7月1日
2008年10月1日 キリンファーマ株式会社との合併により、
「協和発酵工業株式会社」より商号変更
•資本金
キリン
ホールディングス
: 26,745百万円
•従業員数 : 7,152名(連結、2013年12月末現在)
<事業持株会社>
協和発酵キリン
•事業内容 : 医療用医薬品の製造・販売。 バイオケミ
カル事業をグループ事業として展開。
親会社はキリンホールディングス。
•売上高
協和発酵バイオ
: 2013年度 340,611百万円(連結)
•事業ビジョン: がん、腎、免疫疾患を中心とした領域で、抗体医薬を核にした最先端
のバイオテクノロジーを駆使して、画期的な新薬を継続的に創出し、世界の人々の健
康と豊かさに貢献する日本初のグローバルスペシャリティファーマとなる。
1
クラウド化に至る背景
クラウド化に至る背景
クラウド化の道のりと今
SAP移行事例
AWSだから考慮すべき点
当社の運用実態
課題とまとめ
2
ネットワークコンピューティングの歴史
(画一的)集中
分散
(多様な)集中
メインフレーム&端末(エミュレータ)
Ⅰ期
100M
▲DECnet
VAX(分散コンピュータ)
Ⅱ期
WINDOWS、C/S
●TCP/IPの採用
★インターネット接続
Ⅲ期
ネットワーク速度
9.6Kbps
WEB、イントラ
10M
256K
■JAVA本格採用
Ⅳ期
無線接続★
SaaS、クラウド
Exchange
1970年
1980
1990
2000
G-mail
2010
Year
3
クラウドコンピューティングの必然性
•ユーザ企業は業務を実行する事が目的
インフラの維持管理(Vup、ウイルス対策)は目的ではない
•増大するコンピュータ経費を抑制したい
IT資産をオフバランスにできないか?
•業務アプリのサービスインを早くしたい
システム開発に要する期間を短縮できないか?
•当社のシステム全体アーキテクチャに合致
自社のデータモデルを中心とした考え方にマッチ
周辺の取り換え可能なプロセスの1つがSaaS
4
当社のシステムアーキテクチャ
• 当社独自のモデルに基づいたエンタープライズHubが中心。
• パッケージ等の周辺処理コンポーネントは、取り替え可能!
Enterprise Model
Local Model
Local Model
給与計算
<BPO>
Cloud
モデル
変換
モデル
変換
エンタープライズHub
マスタHub
販売物流
(パッケージ)
共通マスター
生産管理
(パッケージ)
原価計算
(パッケージ)
TR-Hub
営業支援
(スクラッチ)
トランザクション
DWH
会計
(パッケージ)
5
当社のAWS基本概念図
テストVPC
本番VPC
Internet
(クラウドデータセンター)
テスト
サーバ
本番
サーバ
開発
サーバ
Gateway
本番セグメント
Internet
Gateway
Gateway
テストセグメント
テストセグメント
テストセグメント
Gateway
開発セグメント
Virtual Private
Gateway
Virtual Private
Gateway
AWS
VPN-R
AD&
DNS
クライアント
クライアント
R
データセンター
事業場
VPN-R
R
本社
R
イントラ
テスト
LAN
クラウド化の 道のり と 今
クラウド化に至る背景
クラウド化の道のりと今
SAP移行事例
AWSだから考慮すべき点
当社の運用実態
課題とまとめ
7
クラウド化の道のり
仮想化が進むが、独自で装備するのは大変そう!?
仮想サーバは大規模すぎる
パブリッククラウドが台頭
プライベートクラウドも可能
クラウドデータセンター追加
*システム更新時に順次移行する
なぜAWSを選んだか
•サーバとOSを従量課金でも提供
⇒MicrosoftのサーバOSの提供やSQLサーバの提供も従量課金あり
•システムイメージを含むサーバを、丸ごとバックアップ可能(AMIとして)
⇒別のリージョンへのAMIコピーも可能
(バックアップの遠隔地保管としても利用可)
•サーバシステムの起動停止を管理画面だけでなく、スクリプトで定期起
動停止できる
•開発/テスト/保守/障害調査など、簡単にサーバ構築し、試すことができる。
作業スピードアップ
SAP(ERP)のAWSでの本番稼働を認定
金融機関での利用も可能(FISCへの対応も可能)
企業利用でも安心
導入までの流れ
•2011年春頃
AWSと出会い(画面によるサーバ管理可能)
→無料枠で利用。東京リージョンでLinuxサーバが起動できた。
•2011年秋頃
VPCサービスが出てきて、企業利用可能と判断。
→インターネット認証用サーバをテスト構築。
構築手順と動作を確認したうえで、本番用実機を手配。
•2011年年末
VPNサービスが出そろった。
→数万円でVPN用ルータを購入。VPN準備開始。
•2012年年初
評価用のプライベートクラウド環境作成
→評価用LANとAWSのVPCとVPNにて接続。
•2012年春頃
実機によるインターネット認証サーバ構築完了
→タイの洪水の影響でサーバ到着が2ヵ月程度遅延。
AWS上でプライベートクラウドデータセンター構築を開始。
→本番用VPN回線とルータを準備。5月中旬開通。
•2012年夏頃
物理データセンター移転のための緊急バックアップとして準備
•2012年秋頃
SAP社ERPの本番適用を認定した
本番運用機をAWSへ導入しながら、運用手順整備
•2013年年初~ プライベートクラウドデータセンター本番運用開始
プライベートクラウドデータセンター稼働後
•2013年春頃
•2013年8月
•2013年9月~
•2013年12月
•2014年1月
•2014年3月
プライベートクラウドデータセンターに本格移行開始
→開発関連サーバ中心に、順次移行した
DirectConnect稼働(既存VPNは、バックアップに)
→大規模なデータ移行も可能となった
文書管理システム(SPS2013)、DMS(Global)構築
→データ移行、コンテンツ作成は、順次行った
SAP本番機稼働(リザーブド・インスタンスにて)
営業支援システム移行①
→大規模なシステムのため、2回に分けた。
営業支援システム移行②
その後、システム更新毎に、AWSをファーストチョイスとして移行を続けている。
$40,000.00
$35,000.00
$0.00
August
September
October
November
December
January
February
March
April
May
June
July
August
September
October
November
December
January
February
March
April
May
June
July
August
September
October
November
December
January
February
March
April
May
June
July
August
September
October
November
December
現在の利用状況と費用推移
7/10現在、18システム39サーバ本番稼働
全93サーバ設定済み
$30,000.00
$25,000.00
$20,000.00
$15,000.00
$10,000.00
リザーブド化
$5,000.00
2011
2012
合計
(支払額)
2013
AWS費用
(月額利用料)
2014
RI登録
(一時費用)
コスト抑制の手法 : リザーブドインスタンスの利用を推進
SAP移行事例
クラウド化に至る背景
クラウド化の道のりと今
SAP移行事例
AWSだから考慮すべき点
当社の運用実態
課題とまとめ
13
SAP更新の背景と方針
<背景>
・ハードウエア・ソフトウェア共に保守切れが迫っている。
ハードウェア : 5年以上経過し延命措置。
ソフトウェア : 現Ver(R/3 4.7)は、SAP社が2013年に保証停止。
<方針>
・現行機能に変更を加えずECC Ver6.0へアップグレードを
行う。(テクニカルアップグレード)
・現サーバー構成を見直し集約を行う(クラウドも検討)
・ハードウェア・ソフトウェア更新に伴うCSV実施
・運用管理のSLA見直し
概要構成図(SAP Servers on AWS)
S3
EC2・EBS
本番VPC
(クラウドデータセンター)
本番環境
R3
本番・検
証・開発
サーバ
バックアップ
SVF・JP1
本番・検
証サーバ
開発・検証環境
R3
本番サーバ
SVF・JP1
本番サーバ
SAP
ルーター
R3
検証サーバ
R3
開発サーバ
SVF・JP1
検証サーバ
Windows
2008
Windows
2008
Windows
2008
Windows
2008
Windows
2008
Windows
2008
インスタンスBACKUP
Solution
Manager
AWS
Virtual Private
Gateway
Windows
2008
SAP
ルーター
SAP社
VPN-R
AD&
DNS
クライアント
DC
拠点
R
R
社内ネットワーク
SAP更新スケジュール(2013年下期)
6
7
8
9
10
SAP標準機能
修正・単体検証
新バージョン機能
分析/影響範囲調査
システム移行
方針策定
システムテスト
システム移行
詳細計画策定
I/F分析設計
JP1分析JOB設計
AWS
基盤準備
AWSインフラ構成検討
(バックアップ、可用性など)
12
テスト障害対応
パフォーマンス検証障害対応
Add-on PG
改修定義・改修・単体検証
システムテスト
計画策定
11
CSV対応
I/F
事前検証
I/F
テスト
運用・パフォーマンス検証
JOB
環境設定
JOB
テスト
UAT・トレーニング
AWSインフラ
環境構築/検証
移行
リハ①
移行
リハ②
本番
移行
アップグレード作業計画
Solman
設置
開発機
設置
SAPRouter
Solman
構築
検証機
設置
開発機
upgrade
本番機
設置
検証機
upgrade
本番機
初回
upgrade
開発機システム設置
検証機システム設置
本番機システム設置
★機能仕様書 ★設計仕様書
製造
★開発計画書(済)
システムテスト
★要求仕様書(済)
★VMP
IQ:検証機据付時
適格性検証
DQ:設計時
適格性検証
本番機
本番機
Upgrade
準備・
リハーサル
Upgrade
運用テスト
IQ:本番機据付時
適格性検証
検証工程
OQ:運転時
適格性検証
PQ:性能時
適格性検証
★検証報告書
■ システム概念図(2013年12月~)
本社管理
本番VPC#1
(東京Region)
業務
AP
本番VPC#3
(米国東部Region)
本番VPC#2
(東京Region)
SAP
DC
業務
AP
USA管理
本番VPC#4
(米州東部Region)
DMS
Global
USASystem
DC
TEST
VPG
VPG
VPG
IG
Direct
Connect
AWS
テストVPC#5
(米州東部Region)
R
Backup
VPN-R
DC
KHK Domestic
ネットワーク
VPN-R
R
VPN-R
USA子会社
Provider Router
本社
NYDC
VPN-R
AD&
DNS
VPN-R
AD & DNS
DC&DNS
R
R
R
AD & DNS
データセンター
JAPAN Domesticドメイン
Globalドメイン
USA Domesticドメイン
17
AWSだから考慮すべき点
クラウド化に至る背景
クラウド化の道のりと今
SAP移行事例
AWSだから考慮すべき点
当社の運用実態
課題とまとめ
18
オンプレと大きく変わるところ
<クラウドにおけるバックアップ装置の変更>
1)クラウド内でのバックアップ・冗長性を信頼する
→クラウドで提供されているバックアップ手法に変更する
2)万が一のバックアップ(クラウドの異常状態を想定)
→物理データセンターや別のクラウドサービスに、
データをバックアップする
<ネットワーク設計が重要>
1)クラウドとの端末通信環境を整える
2)他システムとの通信環境を整える
<リザーブドインスタンス化を検討>
1)SAP等基幹システムは、検証時期にサイジングする
2)サーバ集約時など、稼働状況を見てサイジングする
データ通信インフラストラクチャ
Internet
文書管理
SAP
新営業支援
勤務
消耗品購買
CloudData
Center
Web会議
人事給与
会計
・・・
DataCenter
SCM
国内
ネットワーク網
・・・
認証
・・・
ファイルサーバ
Eラーニング
メール
認証
申請文書
グローバル
ネットワーク網
海外拠点
営業所
本社・支店・研究所・工場
その他拠点
海外拠点
プライベートネットワーク
20
AWS特有の管理
・サーバの物理管理はなくなるが、仮想的な設定情報の
管理・権限管理が必要となる。
1)複数の要素認証(AWS MFA)の設定による特権管理の徹底
2)マネージメントコンソール利用権限をIAMにて権限設定する
→個人ごとにユーザ権限設定し、ルートアカウントは使わない。
3)ネットワーク、セキュリティ、F/Wの知識も必要
4)起動、停止、バックアップなど、スクリプト化が必要
良いパートナーさんを選べる時代になった
⇒AWS未経験Sierの見積りに注意!
これからのAWS活用
•基幹システムを順次載せていく。
コンピュータシステムバリデーションの対応も行い、
安全性と品質を保ちつつ、システム立ち上げのスピードアップと
障害時の早期復旧(原因追究や代替手段の早期確保も)も目指す。
•より品質の高いシステム提供を行う。
開発・保守は、スピードとテスト重視
リスクが高そうなことは、テスト環境を作成して早く検証する
データセットアップ時は、大きな性能のサーバーをチョイス
•ビッグデータ関連ツール(Redshift,EMR)の検討
22
当社の運用実態
クラウド化に至る背景
クラウド化の道のりと今
SAP移行事例
AWSだから考慮すべき点
当社の運用実態
課題とまとめ
23
運用移管の実施
•AWS上に作成したプライベートクラウドデータセンターも、
物理データセンターと同様に、運用管理グループの管理配下
とし、運用移管を行った。
AWSツール群の整備
•自動化や運用担当者への業
務移管を行うためには、
AWSのマネージメントコンソー
ルだけでなく、右のようなスクリ
プトの用意が必要である。
AWSの運用申請書
•右に、運用関連のAWS
申請書を示す。
•運用担当者とアプリケー
ション開発保守担当者を
職務分離するために、申
請書による作業申請制を
とっている。
•本番サーバ構築は、事
前に部内決裁必要。
•評価用サーバは、ある金
額内であれば、担当マ
ネージャー権限でOK。
課題とまとめ
クラウド化に至る背景
クラウド化の道のりと今
SAP移行事例
AWSだから考慮すべき点
当社の運用実態
課題とまとめ
27
AWSで、ぶち当たっている課題
・DirectConnectの増速がタイムリーにできない
→物理増速がベンダー次第、約2週間かかる
・オンプレからのデータ移行がネットワーク越しでしかできない
→AWS Importが、東京リージョンでリリースされない
・リージョン間のVPCピアリング接続機能が待望される
・VPCのIPアドレス拡張が単純にできない
(全サーバ停止⇒IPアドレス拡張⇒全サーバ起動)
・インターネット接続のセキュリティ確保が良くわからない
→InternetGatewayを利用する上でのセキュリティアプライア
ンス構築などの標準的な対応方法
28
まとめ
•AWSを進化させるとともに、既存システムの安定稼働が
図られるよう働きかける
利用に関する疑問など、サポート部隊を最大限活用する
業務に必要な課題は、声を大にして優秀なエバンジェリスト
に伝える
•AWSは今までと大変さは変わらず
システム運用管理ルールは変わらない
AWSでも運用に必要なことはほとんど同じ
他社事例・障害対応事例の勉強
⇒ E-JAWSへの参加
29