1 / 31

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

基幹システムのクラウド化を 実現するための実践的ノウハウ. AWS Summit Tokyo 2014 Day2 2014/7/18 ( 金 )12:20-13:00 Tech Deep Dive by Customers TC-06. 　情報 システム部長 篠田敏幸. 協和発酵キリンの概要. 設立 ： 1949 年（昭和 24 年） 7 月１日 2008 年 10 月 1 日　キリンファーマ株式会社との合併により、 「協和発酵工業株式会社」より商号変更 資本金 ： 26,745 百万円

oakley
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 基幹システムのクラウド化を 実現するための実践的ノウハウ AWS Summit Tokyo 2014 Day2 2014/7/18 (金)12:20-13:00 Tech Deep Dive by Customers TC-06 　情報システム部長篠田敏幸

  2. 協和発酵キリンの概要 • 設立 ： 1949年（昭和24年）7月１日 • 2008年10月1日　キリンファーマ株式会社との合併により、 「協和発酵工業株式会社」より商号変更 • 資本金 ：26,745百万円 • 従業員数 ： 7,152名（連結、2013年12月末現在） • 事業内容 ： 医療用医薬品の製造・販売。 バイオケミ • カル事業をグループ事業として展開。 • 親会社はキリンホールディングス。 • 売上高 : 2013年度340,611百万円（連結）　　　 ＜事業持株会社＞ • 事業ビジョン： がん、腎、免疫疾患を中心とした領域で、抗体医薬を核にした最先端のバイオテクノロジーを駆使して、画期的な新薬を継続的に創出し、世界の人々の健康と豊かさに貢献する日本初のグローバルスペシャリティファーマとなる。

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

  4. ﾈｯﾄﾜｰｸｺﾝﾋﾟｭｰﾃｨﾝｸﾞの歴史 （画一的）集中 分散 （多様な）集中 メインフレーム＆端末（ｴﾐｭﾚｰﾀ） Ⅰ期 ▲ＤＥＣｎｅｔ 100M ＶＡＸ（分散ｺﾝﾋﾟｭｰﾀ） Ⅱ期 ＷＩＮＤＯＷＳ、Ｃ／Ｓ ●ＴＣＰ／ＩＰの採用 ★インターネット接続 ＷＥＢ、イントラ Ⅲ期 ■ＪＡＶＡ本格採用 ＳａａＳ、クラウド ネットワーク速度 10M Ⅳ期 無線接続★ 256K 9.6Kbps Exchange G-mail Year １９７０年 １９８０ １９９０ ２０００ ２０１０

  5. ｸﾗｳﾄﾞｺﾝﾋﾟｭｰﾃｨﾝｸﾞの必然性 • ユーザ企業は業務を実行する事が目的 • インフラの維持管理（Ｖｕｐ、ウイルス対策）は目的ではない • 増大するコンピュータ経費を抑制したい • ＩＴ資産をオフバランスにできないか？ • 業務アプリのサービスインを早くしたい • システム開発に要する期間を短縮できないか？ • 当社のシステム全体アーキテクチャに合致 • 自社のデータモデルを中心とした考え方にマッチ • 周辺の取り換え可能なプロセスの１つがＳａａＳ 4

  6. 当社のシステムアーキテクチャ • 当社独自のモデルに基づいたエンタープライズＨｕｂが中心。 • ﾊﾟｯｹｰｼﾞ等の周辺処理コンポーネントは、取り替え可能！ Enterprise Model Local Model Local Model ﾓﾃﾞﾙ変換 モデル変換 　　　　ｴﾝﾀｰﾌﾟﾗｲｽﾞＨｕｂ 販売物流 （ﾊﾟｯｹｰｼﾞ） 給与計算 ＜BPO＞ ﾏｽﾀHub Ｃｌｏｕｄ 共通マスター 営業支援 （スクラッチ） 生産管理 （ﾊﾟｯｹｰｼﾞ） TR-Hub トランザクション ＤＷＨ 原価計算 （ﾊﾟｯｹｰｼﾞ） 会計 （ﾊﾟｯｹｰｼﾞ） 5

  7. 当社のAWS基本概念図 Internet テストVPC 本番VPC （クラウドデータセンター） ﾃｽﾄｾｸﾞﾒﾝﾄ ﾃｽﾄｾｸﾞﾒﾝﾄ ﾃｽﾄｾｸﾞﾒﾝﾄ ﾃｽﾄｻｰﾊﾞ Internet Gateway 本番ｾｸﾞﾒﾝﾄ 開発ｾｸﾞﾒﾝﾄ 本番ｻｰﾊﾞ 開発ｻｰﾊﾞ Gateway Gateway Gateway VirtualPrivateGateway VirtualPrivateGateway AWS イントラ データセンター AD＆DNS VPN-R 本社 ｸﾗｲｱﾝﾄ VPN-R 事業場 ｸﾗｲｱﾝﾄ R テストLAN R R

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

  9. クラウド化の道のり 仮想化が進むが、独自で装備するのは大変そう!? 仮想サーバは大規模すぎる パブリッククラウドが台頭 プライベートクラウドも可能 クラウドデータセンター追加 ＊システム更新時に順次移行する

  10. なぜAWSを選んだか • サーバとOSを従量課金でも提供 • ⇒MicrosoftのサーバOSの提供やSQLサーバの提供も従量課金あり • システムイメージを含むサーバを、丸ごとバックアップ可能（AMIとして） • ⇒別のﾘｰｼﾞｮﾝへのＡＭＩコピーも可能 • 　　（バックアップの遠隔地保管としても利用可） • サーバシステムの起動停止を管理画面だけでなく、スクリプトで定期起動停止できる • 開発/テスト/保守/障害調査など、簡単にサーバ構築し、試すことができる。 作業スピードアップ SAP（ERP）のAWSでの本番稼働を認定 金融機関での利用も可能（ＦＩＳＣへの対応も可能） 企業利用でも安心

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

  12. ﾌﾟﾗｲﾍﾞｰﾄｸﾗｳﾄﾞﾃﾞｰﾀｾﾝﾀｰ稼働後ﾌﾟﾗｲﾍﾞｰﾄｸﾗｳﾄﾞﾃﾞｰﾀｾﾝﾀｰ稼働後 • ２０１３年春頃　　　ﾌﾟﾗｲﾍﾞｰﾄｸﾗｳﾄﾞﾃﾞｰﾀｾﾝﾀｰに本格移行開始 • 　　　　　　　　　　　　→開発関連サーバ中心に、順次移行した • ２０１３年８月　　　 DirectConnect稼働（既存VPNは、ﾊﾞｯｸｱｯﾌﾟに） • 　　　　　　　　　　　　→大規模なデータ移行も可能となった • ２０１３年９月～　　文書管理システム（SPS２０１３）、DMS(Globaｌ)構築 • 　　　　　　　　　　　　→データ移行、コンテンツ作成は、順次行った • ２０１３年１２月　　　SAP本番機稼働(ﾘｻﾞｰﾌﾞﾄﾞ・ｲﾝｽﾀﾝｽにて) • ２０１４年１月　　　 営業支援システム移行① • 　　　　　　　　　　　　 →大規模なシステムのため、２回に分けた。 • ２０１４年３月　　　 営業支援システム移行② • その後、システム更新毎に、AWSをファーストチョイスとして移行を続けている。

  13. 現在の利用状況と費用推移 • 　　　７/１０現在、１８システム３９サーバ本番稼働 • 　　　全９３サーバ設定済み リザーブド化 コスト抑制の手法　：　リザーブドインスタンスの利用を推進

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

  15. SAP更新の背景と方針 • ＜背景＞ • ・ハードウエア・ソフトウェア共に保守切れが迫っている。 • 　　　ハードウェア ：　５年以上経過し延命措置。 • 　　　ソフトウェア　 ：　現Ｖｅｒ（R/34.7）は、ＳＡＰ社が2013年に保証停止。 • ＜方針＞ • ・現行機能に変更を加えずＥＣＣ　Ｖｅｒ６．０へアップグレードを行う。（テクニカルアップグレード） • ・現サーバー構成を見直し集約を行う（クラウドも検討） • ・ハードウェア・ソフトウェア更新に伴うＣＳＶ実施 • ・運用管理のＳＬＡ見直し

  16. 概要構成図(SAP Serverson AWS) 本番VPC （クラウドデータセンター） S3 EC2・EBS バックアップ 本番環境 開発・検証環境 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 VirtualPrivateGateway Windows 2008 ＳＡＰ社 社内ネットワーク ＤＣ SAP ルーター AD＆DNS VPN-R 　拠点 ｸﾗｲｱﾝﾄ R R

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

  18. ■ システム概念図(2013年12月～) 本社管理 USA管理 本番VPC#3 （米国東部Region） JAPANDomesticドメイン Globalドメイン USADomesticドメイン 本番VPC#4 （米州東部Region） 本番VPC#1 （東京Region） 本番VPC#2 （東京Region） DMS Global USA-System DC DC SAP 業務AP 業務AP TEST DC VPG VPG VPG IG DirectConnect AWS テストVPC#5 （米州東部Region） R 本社 VPN-R VPN-R KHKDomestic ネットワーク USA子会社 Backup ProviderRouter R NYDC VPN-R VPN-R データセンター AD&DNS AD＆DNS VPN-R DC＆DNS R R AD&DNS R

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

  20. オンプレと大きく変わるところ ＜クラウドにおけるバックアップ装置の変更＞ 　１）クラウド内でのバックアップ・冗長性を信頼する 　　→クラウドで提供されているバックアップ手法に変更する 　２）万が一のバックアップ(クラウドの異常状態を想定） 　　→物理データセンターや別のｸﾗｳﾄﾞｻｰﾋﾞｽに、 　　　　データをバックアップする ＜ネットワーク設計が重要＞ 　１）クラウドとの端末通信環境を整える 　２）他システムとの通信環境を整える ＜リザーブドインスタンス化を検討＞ 　１）SAP等基幹システムは、検証時期にサイジングする 　２）サーバ集約時など、稼働状況を見てサイジングする

  21. データ通信インフラストラクチャ Internet 新営業支援 文書管理 勤務 消耗品購買 Web会議 ・・・ ・・・ Eﾗｰﾆﾝｸﾞ CloudData Center SAP 人事給与 認証 メール ﾌｧｲﾙｻｰﾊﾞ 会計 ・・・ 認証 DataCenter SCM 申請文書 国内 ネットワーク網 　グローバル 　ネットワーク網 営業所 海外拠点 その他拠点 本社・支店・研究所・工場 海外拠点 プライベートネットワーク

  22. AWS特有の管理 ・サーバの物理管理はなくなるが、仮想的な設定情報の 管理・権限管理が必要となる。 １）複数の要素認証(AWSMFA)の設定による特権管理の徹底 ２）マネージメントコンソール利用権限をIAMにて権限設定する →個人ごとにユーザ権限設定し、ルートアカウントは使わない。 ３）ネットワーク、セキュリティ、F/Wの知識も必要 ４）起動、停止、バックアップなど、ｽｸﾘﾌﾟﾄ化が必要 良いパートナーさんを選べる時代になった 　　⇒AWS未経験Sierの見積りに注意！

  23. これからのAWS活用 • 基幹システムを順次載せていく。 • コンピュータシステムバリデーションの対応も行い、 • 安全性と品質を保ちつつ、システム立ち上げのスピードアップと • 障害時の早期復旧（原因追究や代替手段の早期確保も）も目指す。 • より品質の高いシステム提供を行う。 • 開発・保守は、スピードとテスト重視 • リスクが高そうなことは、テスト環境を作成して早く検証する • データセットアップ時は、大きな性能のサーバーをチョイス • ビッグデータ関連ツール(Redshift,EMR)の検討

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

  25. 運用移管の実施 • AWS上に作成したプライベートクラウドデータセンターも、 • 物理データセンターと同様に、運用管理グループの管理配下とし、運用移管を行った。

  26. AWSツール群の整備 • 自動化や運用担当者への業務移管を行うためには、 • AWSのマネージメントコンソールだけでなく、右のようなｽｸﾘﾌﾟﾄの用意が必要である。

  27. AWSの運用申請書 • 右に、運用関連のAWS申請書を示す。 • 運用担当者とアプリケーション開発保守担当者を職務分離するために、申請書による作業申請制をとっている。 • 本番サーバ構築は、事前に部内決裁必要。 • 評価用サーバは、ある金額内であれば、担当マネージャー権限でOK。

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

  29. AWSで、ぶち当たっている課題 ・DirectConnectの増速がタイムリーにできない 　→物理増速がベンダー次第、約２週間かかる ・オンプレからのデータ移行がネットワーク越しでしかできない 　→AWSImportが、東京ﾘｰｼﾞｮﾝでリリースされない ・リージョン間のVPCﾋﾟｱﾘﾝｸﾞ接続機能が待望される ・VPCのIPアドレス拡張が単純にできない 　　（全サーバ停止⇒IPｱﾄﾞﾚｽ拡張⇒全サーバ起動） ・インターネット接続のセキュリティ確保が良くわからない 　→InternetGatewayを利用する上でのセキュリティアプライアンス構築などの標準的な対応方法

  30. まとめ • AWSを進化させるとともに、既存システムの安定稼働が図られるよう働きかける • 利用に関する疑問など、サポート部隊を最大限活用する • 業務に必要な課題は、声を大にして優秀なエバンジェリストに伝える • AWSは今までと大変さは変わらず • システム運用管理ルールは変わらない • AWSでも運用に必要なことはほとんど同じ 他社事例・障害対応事例の勉強 ⇒　E-JAWSへの参加

More Related