基幹システムのクラウド化を実現するための実践的ノウハ

ウ　AWS Summit Tokyo 2014Day2 2014/7/18 ( 金 )12:20-13:00Tech Deep Dive by Customers TC-06

　情報システム部長　篠田敏幸　　

協和発酵キリンの概要• 設立 ： 1949 年（昭和 24 年） 7 月１日

2008 年 10 月 1 日　キリンファーマ株式会社との合併により、 「協和発酵工業株式会社」より商号変更

• 資本金 ： 26,745 百万円 • 従業員数 ： 7,152 名（連結、 2013 年 12

月末現在）

• 事業内容 ： 医療用医薬品の製造・販売。 バイオケミ

カル事業をグループ事業として展開。 親会社はキリンホールディングス。

• 売上高 : 2013 年度 340,611 百万円（連結）　　　

2

キリンホールディングス

協和発酵キリン

協和発酵バイオ

• 事業ビジョン： がん、腎、免疫疾患を中心とした領域で、抗体医薬を核にした最先端のバイオテクノロジーを駆使して、画期的な新薬を継続的に創出し、世界の人々の健康と豊かさに貢献する日本初のグローバルスペシャリティファーマとなる。

＜事業持株会社＞

クラウド化に至る背景

2

クラウド化に至る背景　クラウド化の道のりと今　　　 SAP 移行事例　 AWS だから考慮すべき点　当社の運用実態　課題とまとめ

（画一的）集中

分散 （多様な）集中

の歴史ﾈｯﾄﾜｰｸｺﾝﾋﾟｭｰﾃｨﾝｸﾞ

4

１９７０年 １９８０ １９９０ ２０００ ２０１０

メインフレーム＆端末（ｴﾐｭ）ﾚｰﾀ

ＶＡＸ（分散ｺﾝﾋﾟｭｰ）ﾀ 　 ＷＩＮＤＯＷＳ、

Ｃ／Ｓ

ＷＥＢ、イントラ

ＳａａＳ、クラウド

★ インターネット接続

■ ＪＡＶＡ本格採用

● ＴＣＰ／ＩＰの採用

▲ ＤＥＣｎｅｔ

Year

ネットワーク速度

256K

9.6Kbps

10M

100M

Ⅰ 期

Ⅱ 期

Ⅲ 期

Ⅳ 期無線接続★

Exchange G-mail

の必然性ｸﾗｳﾄﾞｺﾝﾋﾟｭｰﾃｨﾝｸﾞ• ユーザ企業は業務を実行する事が目的

インフラの維持管理（Ｖｕｐ、ウイルス対策）は目的ではない

• 増大するコンピュータ経費を抑制したいＩＴ資産をオフバランスにできないか？

• 業務アプリのサービスインを早くしたいシステム開発に要する期間を短縮できないか？

• 当社のシステム全体アーキテクチャに合致自社のデータモデルを中心とした考え方にマッチ周辺の取り換え可能なプロセスの１つがＳａａＳ

5

当社のシステムアーキテクチャ• 当社独自のモデルに基づいたエンタープライズＨｕｂが中

心。• ﾊﾟｯｹｰｼﾞ等の周辺処理コンポーネントは、取り替え可能！

生産管理（ ）ﾊﾟｯｹｰｼﾞ

原価計算（ﾊﾟｯｹｰｼﾞ）

営業支援（スクラッチ）

会計（ﾊﾟｯｹｰｼﾞ）

　　　　 Ｈｕｂｴﾝﾀｰﾌﾟﾗｲｽﾞ給与計算＜ BPO ＞

販売物流（ﾊﾟｯｹｰｼﾞ）

Local Model Local ModelEnterprise Model

ﾓﾃﾞﾙ変換

モデル変換

トランザクションＤＷＨ

TR-Hub

共通マスター

ﾏｽﾀ Hub

Ｃｌｏ

ｕｄ

6

当社の AWS 基本概念図

AWS

本番ｾｸﾞﾒﾝﾄ 開発ｾｸﾞﾒﾝﾄ

Virtual Private Gateway

イントラ事業場

データセンター

R

VPN-R

R

Gateway Gateway

本番ｻｰﾊﾞ

開発ｻｰﾊﾞ

本番 VPC（クラウドデータセンター）

ﾃｽﾄｾｸﾞﾒﾝﾄﾃｽﾄｾｸﾞﾒﾝﾄ

本社R

VPN-R

テストLAN

Virtual Private Gateway

AD＆

DNS

ｸﾗｲｱﾝﾄｸﾗｲｱﾝﾄ

ﾃｽﾄｾｸﾞﾒﾝﾄGateway

ﾃｽﾄｻｰﾊﾞ Internet

Gateway

Internetテスト VPC

クラウド化の　道のり　と　今

8

　クラウド化に至る背景クラウド化の道のりと今　　　 SAP 移行事例　 AWS だから考慮すべき点　当社の運用実態　課題とまとめ

クラウド化の道のり

＊システム更新時に順次移行する

プライベートクラウドも可能

仮想化が進むが、独自で装備するのは大変そう !?

仮想サーバは大規模すぎる

パブリッククラウドが台頭

クラウドデータセンター追加

なぜ AWS を選んだか• サーバとOSを従量課金でも提供

⇒MicrosoftのサーバOSの提供や SQLサーバの提供も従量課金あり• システムイメージを含むサーバを、丸ごとバックアップ可能

（ AMIとして）⇒別の へのＡＭＩコピーも可能ﾘｰｼﾞｮﾝ　　（バックアップの遠隔地保管としても利用可）• サーバシステムの起動停止を管理画面だけでなく、スクリプ

トで定期起動停止できる• 開発 /テスト /保守 /障害調査など、簡単にサーバ構築し、試すことができる。 作業スピードアップ

SAP （ ERP ）の AWS での本番稼働を認定金融機関での利用も可能（ＦＩＳＣへの対応も可能） 企業利用でも安心

導入までの流れ• ２０１１年春頃　　　 AWSと出会い（画面によるサーバ管理可能）　　　　　　　　　　　→無料枠で利用。東京 でﾘｰｼﾞｮﾝ Linuxサーバが起動できた。• ２０１１年秋頃　　　 VPCサービスが出てきて、企業利用可能と判断。　　　　　　　　　　　→インターネット認証用サーバをテスト構築。　　　　　　　　　　　　　構築手順と動作を確認したうえで、本番用実機を手配。• ２０１１年年末　　　 VPNサービスが出そろった。　　　　　　　　　　　→数万円で VPN用ルータを購入。 VPN準備開始。• ２０１２年年初　　　評価用のプライベートクラウド環境作成　　　　　　　　　　　→評価用 LANと AWSの VPCと VPNにて接続。• ２０１２年春頃　　　実機によるインターネット認証サーバ構築完了　　　　　　　　　　　→タイの洪水の影響でサーバ到着が２ヵ月程度遅延。　　　　　　　　　　　　　 AWS上でプライベートクラウドデータセンター構築を開始。　　　　　　　　　　　→本番用 VPN回線とルータを準備。５月中旬開通。• ２０１２年夏頃　　　物理データセンター移転のための緊急バックアップとし

て準備• ２０１２年秋頃　　　ＳＡＰ社ＥＲＰの本番適用を認定した　　　　　　　　　　　　本番運用機を AWSへ導入しながら、運用手順整備• ２０１３年年初～　 クラウドデータセンター本番運用開始ﾌﾟﾗｲﾍﾞｰﾄ

稼働後ﾌﾟﾗｲﾍﾞｰﾄｸﾗｳﾄﾞﾃﾞｰﾀｾﾝﾀｰ

• ２０１３年春頃　　　 に本格移行開始ﾌﾟﾗｲﾍﾞｰﾄｸﾗｳﾄﾞﾃﾞｰﾀｾﾝﾀｰ　　　　　　　　　　　　→開発関連サーバ中心に、順次移行した• ２０１３年８月　　　 DirectConnect稼働（既存 VPNは、 に）ﾊﾞｯｸｱｯﾌﾟ　　　　　　　　　　　　→大規模なデータ移行も可能となった• ２０１３年９月～　　文書管理システム（ SPS２０１３）、DMS(Globaｌ )構築

　　　　　　　　　　　　→データ移行、コンテンツ作成は、順次行った• ２０１３年１２月　　　 SAP本番機稼働 ( ・ にてﾘｻﾞｰﾌﾞﾄﾞ ｲﾝｽﾀﾝｽ )　　　　　　　　　　　• ２０１４年１月　　　 営業支援システム移行①　　　　　　　　　　　　 →大規模なシステムのため、２回に分けた。• ２０１４年３月　　　 営業支援システム移行②

その後、システム更新毎に、 AWSをファーストチョイスとして移行を続けている。

Augu

stSe

ptem

ber

Oct

ober

Nov

embe

rD

ecem

ber

Janu

ary

Febr

uary

Mar

chAp

rilM

ayJu

ne July

Augu

stSe

ptem

ber

Oct

ober

Nov

embe

rD

ecem

ber

Janu

ary

Febr

uary

Mar

chAp

rilM

ayJu

ne July

Augu

stSe

ptem

ber

Oct

ober

Nov

embe

rD

ecem

ber

Janu

ary

Febr

uary

Mar

chAp

rilM

ayJu

ne July

Augu

stSe

ptem

ber

Oct

ober

Nov

embe

rD

ecem

ber

2011 2012 2013 2014

$0.00

$5,000.00

$10,000.00

$15,000.00

$20,000.00

$25,000.00

$30,000.00

$35,000.00

$40,000.00

合計（支払額）

AWS 費用（月額利用料）

RI 登録( 一時費用）

現在の利用状況と費用推移

コスト抑制の手法　：　リザーブドインスタンスの利用を推進

リザーブド化

　　　７ /１０現在、１８システム３９サーバ本番稼働　　　全９３サーバ設定済み

SAP 移行事例

14

クラウド化に至る背景　クラウド化の道のりと今　　SAP 移行事例　 AWS だから考慮すべき点　当社の運用実態　課題とまとめ

SAP 更新の背景と方針＜背景＞・ハードウエア・ソフトウェア共に保守切れが迫っている。　　　ハードウェア ：　５年以上経過し延命措置。　　　ソフトウェア　 ：　現Ｖｅｒ（ R/3 　 4.7 ）は、ＳＡＰ社が 2013 年に保証停止。

＜方針＞・現行機能に変更を加えずＥＣＣ　Ｖｅｒ６．０へアップグレードを行う。（テクニカルアップグレード）・現サーバー構成を見直し集約を行う（クラウドも検討）・ハードウェア・ソフトウェア更新に伴うＣＳＶ実施・運用管理のＳＬＡ見直し

　

概要構成図 (SAP Servers on AWS)

　

AWS Virtual Private Gateway

社内ネットワーク　拠点

ＤＣR

VPN-R

R

R3本番ｻｰﾊﾞ

本番 VPC（クラウドデータセンター）

AD ＆DNS

ｸﾗｲｱﾝﾄ

Windows2008

SVF・ JP1本番ｻｰﾊﾞ

Windows2008

R3検証ｻｰﾊﾞ

Windows2008

R3開発ｻｰﾊﾞ

Windows2008

SVF・ JP1検証ｻｰﾊﾞ

Windows2008

バックアップ

R3本番・検証・開発

ｻｰﾊﾞ

SVF・ JP1本番・検証ｻｰﾊﾞ

インスタンスBACKUP

SAPルーター

Windows2008

ＳＡＰ社

EC2・EBS

S3

本番環境 開発・検証環境

SolutionManager

Windows2008

SAPルーター

検証工程

6 7 8 9 10 11 12

★開発計画書（済）★要求仕様書（済）

★機能仕様書 ★設計仕様書製造

開発機 設置ｼｽﾃﾑ

ｼｽﾃﾑ ﾃｽﾄ

★検証報告書DQ：設計時適格性検証

OQ：運転時適格性検証

PQ：性能時適格性検証

新ﾊﾞー ｼ ｮ゙ﾝ機能分析/ 影響範囲調査

Add-on PG改修定義・改修・単体検証

SAP標準機能修正・単体検証

ｱｯﾌ ｸ゚ ﾚ゙ｰ ﾄ 作゙業計画

SAPRouterSolman構築

開発機upgrade

検証機upgrade

検証機設置

本番機初回

upgrade

本番機設置

本番機Upgradeﾘﾊｰｻ ﾙ

本番機準備・

Upgrade

★ＶＭＰ

ｼｽ ﾃﾑ ﾃｽﾄ計画策定 ｼｽﾃﾑ ﾃｽﾄ CSV対応

障害対応ﾊ ﾌ゚ｫｰ ﾏﾝｽ検証障害対応

ｼｽﾃﾑ移行方針策定

ｼｽ ﾃﾑ移行詳細計画策定

I/F事前検証

I/Fﾃｽﾄ

I/F分析設計

J P1分析JOB設計

移行①ﾘﾊ

本番移行

J OB環境設定

J OBﾃｽﾄ

移行②ﾘﾊ

運用・検証

UAT・ﾄﾚｰﾆﾝｸﾞ

運用ﾃｽﾄ

IQ：検証機据付時適格性検証

IQ：本番機据付時適格性検証

検証機 設置ｼｽﾃﾑ 本番機ｼｽﾃﾑ設置

AWS基盤準備

AWS構成検討（ﾊ ｯ゙ｸｱｯﾌ 、゚可用性など）

AWSｲﾝﾌﾗ環境構築/ 検証

Solman設置

開発機設置

SAP 更新スケジュール (2013 年下期 )

USA子会社

NYDC

本社管理 USA 管理

KHK Domesticネットワー

ク

■ システム概念図 (2013 年 12月～ )

18

AWSDirect

Connect

本社

データセンター

R

業務AP

本番 VPC#1（東京Region ）

RR

AD ＆DNS

DMSGlobal

DC ＆DNS

本番 VPC#3（米国東部Region ）

VPG

USA-System

本番 VPC#4（米州東部Region ）

VPG

R

AD & DNS

VPN-R

VPN-R VPN-R

Provider Router

AD & DNS

Global ドメインJAPAN 　 Domestic ドメイ

ン

IG

TEST

テスト VPC#5（米州東部Region ）

DCDC

DC

VPN-R

USA Domestic ドメイン

SAP

R

VPG

VPN-R

Backup

本番 VPC#2（東京Region ）業務

AP

AWS だから考慮すべき点

19

　クラウド化に至る背景　クラウド化の道のりと今　　　 SAP 移行事例AWS だから考慮すべき点　当社の運用実態　課題とまとめ

オンプレと大きく変わるところ＜クラウドにおけるバックアップ装置の変更＞　１）クラウド内でのバックアップ・冗長性を信頼する　　→クラウドで提供されているバックアップ手法に変更する　２）万が一のバックアップ (クラウドの異常状態を想定）　　→物理データセンターや別の に、ｸﾗｳﾄﾞｻｰﾋﾞｽ　　　　データをバックアップする

＜ネットワーク設計が重要＞　１）クラウドとの端末通信環境を整える　２）他システムとの通信環境を整える

＜リザーブドインスタンス化を検討＞　１） SAP等基幹システムは、検証時期にサイジングする　２）サーバ集約時など、稼働状況を見てサイジングする

データ通信インフラストラクチャ

21

営業所

本社・支店・研究所・工場 海外拠点

　グローバル 　ネットワーク

網

プライベートネットワーク

Internet

SCM

認証・・・

申請文書DataCenter

会計

その他拠点

国内ネットワーク網

認証 ﾌｧｲﾙｻｰﾊﾞ メール

人事給与

・・・

・・・ E ﾗｰﾆﾝｸﾞWeb会議消耗品購買

CloudDataCenter

文書管理 新営業支援

SAP

勤務

海外拠点

AWS特有の管理

１）複数の要素認証 (AWS MFA) の設定による特権管理の徹底２）マネージメントコンソール利用権限を IAM にて権限設定する→個人ごとにユーザ権限設定し、ルートアカウントは使わない。３）ネットワーク、セキュリティ、 F/W の知識も必要４）起動、停止、バックアップなど、 化が必要ｽｸﾘﾌﾟﾄ

・サーバの物理管理はなくなるが、仮想的な設定情報の管理・権限管理が必要となる。

良いパートナーさんを選べる時代になった　　⇒ AWS未経験 Sier の見積りに注意！

これからの AWS活用• 基幹システムを順次載せていく。

コンピュータシステムバリデーションの対応も行い、安全性と品質を保ちつつ、システム立ち上げのスピードアップと障害時の早期復旧（原因追究や代替手段の早期確保も）も目指す。

•より品質の高いシステム提供を行う。開発・保守は、スピードとテスト重視リスクが高そうなことは、テスト環境を作成して早く検証するデータセットアップ時は、大きな性能のサーバーをチョイス

• ビッグデータ関連ツール (Redshift,EMR) の検討23

当社の運用実態

24

　クラウド化に至る背景　クラウド化の道のりと今　　　 SAP 移行事例　 AWS だから考慮すべき点当社の運用実態　課題とまとめ

運用移管の実施• AWS 上に作成したプライベートクラウドデータセン

ターも、物理データセンターと同様に、運用管理グループの管理配下とし、運用移管を行った。　

AWSツール群の整備

• 自動化や運用担当者への業務移管を行うためには、

AWS のマネージメントコンソールだけでなく、右のような の用意が必要ｽｸﾘﾌﾟﾄである。

AWS の運用申請書

•右に、運用関連のAWS申請書を示す。

• 運用担当者とアプリケーション開発保守担当者を職務分離するために、申請書による作業申請制をとっている。

• 本番サーバ構築は、事前に部内決裁必要。

•評価用サーバは、ある金額内であれば、担当マネージャー権限でOK 。

　

課題とまとめ

28

　クラウド化に至る背景　クラウド化の道のりと今　　　 SAP 移行事例　 AWS だから考慮すべき点　当社の運用実態課題とまとめ

AWS で、ぶち当たっている課題

29

・ DirectConnect の増速がタイムリーにできない　→物理増速がベンダー次第、約２週間かかる

・オンプレからのデータ移行がネットワーク越しでしかできない　→ AWS Import が、東京 でリリースされないﾘｰｼﾞｮﾝ

・リージョン間の VPC 接続機能が待望されるﾋﾟｱﾘﾝｸﾞ

・ VPC の IP アドレス拡張が単純にできない　　（全サーバ停止⇒ IP 拡張⇒全サーバ起動）ｱﾄﾞﾚｽ

・インターネット接続のセキュリティ確保が良くわからない　→ InternetGateway を利用する上でのセキュリティアプライアンス構築などの標準的な対応方法

まとめ

30

• AWS を進化させるとともに、既存システムの安定稼働が図られるよう働きかける利用に関する疑問など、サポート部隊を最大限活用する業務に必要な課題は、声を大にして優秀なエバンジェリストに伝える

• AWS は今までと大変さは変わらずシステム運用管理ルールは変わらないAWS でも運用に必要なことはほとんど同じ他社事例・障害対応事例の勉強　　　　⇒　 E-JAWSへの参加