awsを活用した仮想デスクトップのdr構築事例～ …...awsを活用した...

AWSを活用した仮想デスクトップのDR構築事例～月額ランニング費用1万円の実現～

2015年6月

キリン情報戦略部桝田浩久

c Kirin Company, Limited 【機密性区分】（開示範囲）

目次

１．キリングループの概要（5分）

２．情報部門の体制（5分）

３．仮想デスクトップの概要（5分）

４．仮想デスクトップのDR対応（20分）

５．時間があればデモ（5分）

1

キリングループのご紹介

2


キリングループの概要（2014年12月期）

持株会社

設立

資本金

本社所在地

従業員数

事業内容

キリンホールディングス株式会社

1907年（キリンビール株式会社）

1,020億円

東京都中野区

39,922人

酒類、飲料、医薬、バイオケミカル他

経営理念

3


キリングループの事業構成（2014年12月期）

4


キリングループの組織

国内綜合飲料事業の地域統括会社として、2013年にキリン株式会社を設立。

キリンビール、キリンビバレッジ、メルシャンを統括した価値提案をめざす。

5


Ｒ＆Ｄ本部

キリン㈱

経営企画部

ＣＳＶ推進部

ブランド戦略部

コーポレートコミュニケーション部

デジタルマーケティング部

研究開発推進部

基盤技術研究所

酒類技術研究所

飲料技術研究所

健康技術研究所

パッケージング研究所

知的財産部

品質保証部

情報戦略部

法務部

人事・総務部

経営監査部

調達部

キリン株式会社（国内綜合飲料事業）の組織

ＣＳＶ本部

キリンビジネスシステム（ＫＢＳ）

6


ビール業務界はどうなっているのか？

お客様・市場の変化消費の二極化進む本物志向や手作り感重視の「こだわり消費」へ健康志向の一層の高まり、規制緩和社会問題への関心の高まり急速なデジタル化将来の酒税改定

お客様や社会の価値観の変化や市場環境の変化の中から、キリンならではのアプローチで

新しい価値を創造する

7


価値創造のキーワードは？

8


Quality with Surprise とは？「ていねいなものづくり」×「新しい技術」によって生み出した新たな製品価値（モノ）をお客様の経験価値（コト）に結びつけることで、キリン独自のブランドを構築してきます

よいモノから生まれる豊かなコト（ブランド体験）

人と人の絆とっておきの時間

潤いのあるひととき9

おいしさにこだわった丁寧なものづくりを行う

ていねいなものづくり健康機能を軸にR&Dの強みを生かして先進的な提案をする

新しい技術

×キリンの「品質」

9


ビールというジャンルにどのような価値を提案していきたいか？味もコンセプトも個性的なブランド群を展開し、均質で、生活に根付いた「いつものビール」から、特別なシーンでも積極的に選ばれる多様なカテゴリーに変えていきます

【嗜好性】

【多様性】

【これまで】「のどの渇きをいやす」「仕事帰りの一杯」「とりあえずビール」

【これから】「個性を楽しむ」「こだわり」「大切な人、大切な時間」

10


具体的な打ち手は？クラフトビールの展開「つくり手の顔が見える」キリンのクラフトビールを通じて話題を喚起し、多様な個性を楽しめる奥深いビール文化を醸成する

ブルワリー併設店舗「 SPRING VALLEY BREWERY 」を今春から東京・横浜で本格始動自社ＥＣサイト「ＤＲＩＮＸ」とつないだブランドコミュニティづくり国内外のクラフトメーカーとも協働しながら、新たなビジネスモデルを創造『コンビニクラフト』の先鞭をつけた「グランドキリン」をリニューアル気軽に手に取っていただけるクラフトとして若年層に支持を得ていきます

スプリングバレーブルワリーグランドキリンビールの枠を超えた提案

ハードシードル

11


キリンブルワリーオーナーズクラブ（７月より募集開始）

検索キリンオンライン

体験してみてください

12

スプリングバレーブルワリー（代官山・横浜）

情報部門の組織

13


キリン情報部門における３つの大きな機能

事業・ＩＴﾘﾚｰｼｮﾝｼｯﾌﾟ機能業務がわかるIT人材、ITがわかる業務人材

情報戦略・ガバナンス機能戦略企画、予算統制、資源配分、セキュリティー

システム開発・保守・運用機能

情報部門が強化すべき領域とは？

強化

14


NTTデータＫＢＳ

情報戦略部

戦略パートナーのリソース支援

ｸﾞﾙｰﾌﾟ情報戦略・ｶﾞﾊﾞﾅﾝｽ機能

事業・ＩＴﾘﾚｰｼｮﾝｼｯﾌﾟ機能

ｼｽﾃﾑ開発・保守・運用機能

内部要員

ＩＴコア機能に内部リソース

をシフト

内部要員

15

どのように強化するか？

戦略パートナーのリソース支援


ＫＢＳ（270人 NTTD支援）

事業・ＩＴリレーションシップ機能（システムアナリスト）

情報戦略部（20人）

事業・ＩＴリレーションシップ機能（ＢＲＭ）

グループ情報戦略・ガバナンス機能

システム開発・保守・運用機能

営業

生産

物流

・・KB KBC Me ・・

ｼｽﾃﾑｱﾅﾘｽﾄ

BRM

【情報戦略部とKBSの役割】

事業ITリレーションシップ機能とは、具体的に何をするか？

事業会社

各部門ITキーマン

経営層経営企画部門

16

仮想デスクトップシステムの概要

17

© Kirin Company; Limited

仮想デスクトップシステムの仕組みは？

シンクラ端末(Windows Embedded)

仮想アプリサーバ

ユーザ数ユーザ数 15,000ユーザ＠国内220拠点

PJ期間PJ期間構築10カ月、展開8カ月

採用製品採用製品Citrix XenDesktop、XenAPP、Windows Embedded

仮想PC型(Win7)仮想デスクトップサーバ

仮想PCﾌﾟｰﾙ型(Win7)仮想デスクトップサーバ

被災時用仮想デスクトップ環境

国内220拠点国内220拠点メインデータセンタ@東京メインデータセンタ@東京 DRセンタ@AWSシンガポールDRセンタ@AWSシンガポール

通常時被災時

18


仮想デスクトップシステムのBCP概要

19


キリングループにおけるＢＣＰの基本的考え方

被災地域以外のお客様に主要ブランド商品をいつも通りお届けすること

被災地域において不足する飲料を政府・流通と連携しながら迅速にお届けすること

20


被害想定をどのくらい見込めばよいか？

項目被災想定

死者、負傷者死者：１６０００人～２００００人負傷者１１万人～１２万人自力脱出困難者５８０００人

避難者他断水・停電の影響を受け、被災２週間後にピークとなり、７２０万人医療が受けられない患者数１万３千人、老人等要援護者２０万人以上食料３４００万食不足、水１７００万リットル不足、毛布３７万枚不足

帰宅困難者１７００万人（東京都では４０～５０％が当日中の帰宅困難）

家屋全壊・焼失件数４６万軒～６１万軒（冬場風速８ｍ／ｓ）

電力被災直後は、最大約１２２０万件（全体の約5割）が停電する。供給側設備が被災し広域的に停電が発生する。主因となる供給側設備の復旧には１ヶ月程度を要する。被災後１週間でピーク電力の５２％の復旧を見込む。

上水道最大で１４４０万人（全体の３割）が断水する。

交通施設

道路：都区部の一般道路は、被災や液状化による沈下、倒壊建物の瓦礫により閉鎖し、通行できない区間が大量に発生し、渋滞と相まって復旧には１ヶ月以上を要する。

鉄道：地下鉄については、運転再開には１週間程度を要する。ＪＲ在来線：沿線の家屋の倒壊や、沿線における市街地延焼火災等が発生し、架線や運行設備のほか、高架橋等の

大きな損傷が生じ、運転再開まで１ヶ月程度を要する。新幹線：高架橋の橋脚等の被災により、都区部近郊で運行が困難となり、損傷を受けない区間からの折り返し

運行となる。

通信

固定電話：最大で４７０万回線（全体の５割）での通話支障が想定され、その復旧までに2週間かかる。携帯電話：基地局の非常用電源による電力供給が停止する１日後に停波基地局率が最大（４６％停止）となる。

なお、被災直後は輻輳により大部分の通話が困難となる。復旧には１ヶ月程度を要する。なお、被災１週間後は基地局の停電による影響で想定不能。

インターネット：１割程度の地域で利用できなくなる可能性があるが、概ねサービスは継続される。停電が長期化された場合には、サービスの提供が難しくなる。

燃料タンクローリー輸送の遅滞、ドライバーの不足等により、石油製品の供給が困難となる。

～首都圏直下型地震の被災想定（2013年12月政府中央防災会議答申内容）～

21


キリン社における被害想定の定義をどうするか？

＜現行のBCPの前提＞

2006年東京都発表による

社会インフラ被害想定に基づいたもの

＜社会インフラ被害想定の方向性＞

※行政による、具体的な社会インフラ

想定被害は、今後公式発表される予定

最大震度震度6強震度7

電力最大3日の大規模停電

4～6日の大規模停電と長期間の輪番停電

※2週間以上の大規模停電が起こりえるとした報告もある

ネットワーク通信途絶の可能性はあるものの回線の二重化等の対策により長期化する可能性は低い

停電の長期化により、通信障害による影響が増大

交通機関線路・道路等の被害により、

都区部を中心に運行への影響あり

線路・道路等の被害により、都区部を中心に運行への影響あり

津波による浸水や大規模な火災により一部の地域では復旧までに長期間を要す

見直し

22


各データセンターの自家発電可能時間はどれくらいなのか？

A センタ B センタ C センタM社

東京第1iDC

Ｍ社東京第2iDC

NC社 I社 N社

メインセンター①

メインセンター②

ファイルサーバー/基本サービス

モバイル環境（東京） TV会議 IP電話

VAN／FDS（FAX送信

ｻｰﾋﾞｽ)Web発注

1 所在東京都神奈川県東京都東京都大田区（西大井）

東京都大田区（平和島）

東京都文京区（湯島）

神奈川県横浜市保土ヶ谷区

神奈川県横浜市神奈川区

2 無給油継続利用可能時間

72時間 24時間※燃料供給契約締結済3.11実績有

20時間 15時間 24時間 24時間 24時間 48時間

3 DRサイト有無・所在大阪府 ※一部

サービス大阪府大阪府－大阪府

外部システム①（基本/共通サービス外部提供元）

外部システム②業務システム外部接続先

項番観点

ﾒｲﾝｾﾝﾀｰ

23


メール

キリングループのBCP）システム概要は？

物流系基幹統合システム L10

メール

東京SC 大阪SC（新規）

物流系基幹統合システム L10

リアルタイムデータ同期

リアルタイムデータ同期

AWSクラウド（Singapore）

×

仮想デスクトップ

仮想デスクトップ

災害ポータル

データ非同期

東京SCダウン時切り替え

24


なぜ仮想デスクトップのＤＲ対策にパブリッククラウドを採用したのか？

当初はＤＲ（ディザスタリカバリ）用のデータセンターである大阪ＳＣにオンプレミスで構築する前提で検討が進んでいた

ＢＣＰ対策コストをもっと抜本的に削減したい特に通常運用におけるコストをミニマム化したい

通常運用時はＤＲ用のサーバは全て停止状態でよいため、パブリッククラウド活用がベストな解決策になるのでは？

25

Gartner Magic Quadrant for Cloud Infrastructure as a Service

Gartner “Magic Quadrant for Cloud Infrastructure as a Service,” Lydia Leong, Douglas Toombs, Bob Gill, Gregor Petri, Tiny Haynes, May 28, 2014. This Magic Quadrant graphic was published by Gartner, Inc. as part of a larger research note and should be evaluated in the context of the entire report. The Gartner report is available at http://aws.amazon.com/resources/analyst-reports/. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. 26


ＡＷＳのオンデマンドインスタンスとは

オンデマンドインスタンス

リザーブドインスタンス

オンデマンドインスタンスの「事前の支払いが発生しない」、「利用時間に応じて課金」という料金体系が、通常時はコストを最小化したいという当社のニーズにうまくフィットした

・事前の支払いが発生しない・利用時間に応じて課金される・利用するサーバは起動時に確保する

・事前の支払いが発生する・利用時間に関係なく課金される・事前に利用するサーバを確保できる

さらにスポットインスタンスという3つ目の購入オプションがあるが、今回はいざ被災が発生した場合は継続的に使うため、当初から評価の対象から外した

ここには落とし穴が！！（後述）

27


AWS OnDemandとReserved でどれくらい金額が違うか？

オンデマンド：リザーブド

2014年検討時の価格比率

１：２７０

28


オンデマンドインスタンスのデメリットへの対策

オンデマンドインスタンスは、起動時に必要サーバ数を確保できないリスクを伴う。その対策として、メイン・セカンダリの２つのリージョンを利用する方式を採用した。セカンダリリージョンにはＡＭＩを事前格納していないため、追加費用は一切かかっていない。

メインリージョンセカンダリリージョン

ゾーンＡゾーンＢゾーンＡゾーンＢ

ゾーンＡで起動できなければゾーンＢで起動

ゾーンＢでも起動できなければ別リージョンで起動

29


さらにコストを最小化するために

オンデマンドインスタンスを採用した上でさらに、通常時はＥＣ２インスタンスは停止させ、ＡＭＩのみをＥＢＳに保存する方法を採用した。被災発生時にそのＡＭＩからＥＣ２インスタンスを複数起動する方式である。

AMIAMI

通常時

AMIAMI

被災発生時

複製

起動

停止

ＥＢＳ上に保管

この保管にのみ少額の料金が

発生

30


仮想デスクトップをＡＷＳ上で稼働させるために

本番環境

通常時利用する仮想デスクトップは仮想ＰＣ型であったが、ＡＷＳではクライアントＯＳの提供がない。そのため、サーバ共有型を採用。それによる制約は、災害時には利用者によるソフトウェアのインストール不可という点のみ。また処理能力もプライマリの７５％とし、ここでもコストカット。

仮想デスクトップ方式

ＤＲ環境＠ＡＷＳ

仮想ＰＣ型（クライアントＯＳ）

○

サーバ共有型（サーバＯＳ）

デスクトップメール利用

○

ソフトウェアインストール

○ ×

処理能力１００％７５％

割り切ったポイント

31


どのような体制で構築したのか？

32

PL:NTTデータ

AWS基盤

NTTデータKBS

AWSコンサル（アドバイス1人月）

Citrix基盤

NTTデータKBS

IBM SECitrixコンサル

（アドバイス1人月）

メール基盤

NTTデータ

PM：NTTデータ

アドバイザーNTTデータ


構築した期間はどれくらいか？

33

領域工程 7月 8月 9月 10月 11月 12月仮想DT 基本設計

検証環境構築検証

▲費用再精査詳細設計環境構築・テスト

メール基本設計ラック調達 ▲発注　　　　▲納品HW調達　　　▲発注　▲納品詳細設計環境構築・テスト

NW（WAN) 回線・機器調達 ▲発注　　　　　▲納品環境構築・テスト

監視基本設計構築

結合テストテスト計画テスト実施


どのリージョンを選択したか？

34

カリフォルニア

ダブリン

シンガポール

東京

オレゴン

バージニア

サンパウロ

リージョン

エッジローケーション

GovCloud

シドニー

北京

# リージョンレイテンシ(参考)1 東京 10ms程度2 シンガポール 80ms程度3 北カリフォルニア 120ms程度4 オレゴン 220ms程度5 シドニー 120ms程度6 アイルランド 320ms程度7 サンパウロ 340ms程度8 バージニア北部 130ms程度


ネットワークはどれくらいの帯域を確保したか？

35

ノート型端末利用者

社外

モバイル

デスクトップ型端末利用者

キリングループ各拠点(中野本社／研究所

／営業所など)

バックアップサイト（大阪SC）

バックアップサイト（AWSシンガポールリージョン）

基本サービス

共通サービス

業務システム

共通コンポーネント

仮想デスクトップ制御コンポーネント

仮想アプリコンポーネント

(IE6)

接続ベンダー社外ユーザ向け認証

メインサイト（東京SC）

インターネットVPN

拠点間IP-VPN

センター間専用線（200MB）

大阪～AWS間インターネット

VPN

ベストエフォート：通常1Mb

自動拡張最大：1Gb


オンプレとＡＷＳ間での機能配置のポイントは？

36

バックアップサイト（大阪SC）

DHCP

基本サービス

DNS

バックアップサイト（AWSシンガポールリージョン）

共通サービス

プリンタサーバ

共通コンポーネント

負荷分散

Web Interface

仮想デスクトップ制御コンポーネント

仮想アプリコンポーネント

(IE6)

XML Broker/DataCollector

XenAppXenApp

SQLサーバ

ファイルサーバ

無線LANAP

RADIUSサーバ

業務システム

L10

AD

メール

災害ポータル

ライセンスサーバ

負荷分散XML

Broker/DataCollector

XenAppXenApp


レイテンシーは本当に大丈夫か？

一般的に仮想デスクトップシステムで許容可能なレイテンシーは120～150msと言われている。

レイテンシーの問題は当初からの懸念だったため、実機検証を実施した。結果、シンガポールリージョンも、レイテンシーの大きいオレゴンリージョンもデスクトップの操作には支障が無いことがわかった。

シンガポール

採用リージョン

オレゴン

約 80ms→検証結果も問題無し

約200ms→検証結果も問題無し

レイテンシー

メインリージョン

セカンダリリージョン

37


セキュリティ対策はどのように考えているか？

AWSを利用するにあたりセキュリティ面での懸念もあったが、「VPCを利用する」「データは置かない」という施策により問題無いと判断した。

対策

・VPCを利用する・インターネット接続はオンプレのプロキシ

サーバ経由で

・各ユーザのパソコンのデータ(Dドライブ)は同期しない

・必要なデータは全てオンプレに配置

クラウド上に業務データを格納することが不安

インターネット上のサービス利用のため不正アクセスが心配

懸念点

38


どのような組み方にしたか

NetScaler

ロードバランサー仮想基盤監視

VMware

XenDesktopHinemos

メールメール

AWSの機能を全面的に利用した。オンプレとAWSの構成の違いは下記の通り。

オンプレ

ELB

ロードバランサー仮想基盤監視

EC2

XenAppCloudWatch

SNSSNS

AWS

39


BCP要件であるRTOの実現

オンデマンドインスタンスは、通常時のコスト最小化を実現できる反面、約100台のサーバを起動しなければならないため、起動時間の面で懸念があった。しかし、起動を全て自動化することにより、63分での起動を実現できた。

リージョン

メインリージョン(シンガポール)

セカンダリリージョン(オレゴン)

起動時間の目標

85分

ベストエフォート

結果

63分

約4時間※

※シンガポールからオレゴンへのAMI転送時間(3時間20分)を含む

40


通常運用

通常時はEC2インスタンスもELBも停止しており、ネットワーク通信も発生しないため、故障も発生せず、監視は不要。

専任の運用者も置いておらず、人的リソース面でもコストを削減できている。

インタネットVPN接続用のルータの監視は必要。

運用監視故障対応問合せ対応定期

メンテナンス

不要不要不要必要

（次ページ）

41


システム維持のために

定期的なメンテナンスは必要。２ヶ月に１回程度のペースで下記のメンテナンス作業を実施している。

定期メンテナンス

WindowsUpdate

ウイルス対策ソフトの定義ファイルアップデート

プリンタードライバーの追加・更新

: (などなど)

42


結局、いくら？

43

オンプレ構築初期費用： 4.0億円ランニング： 0.7億円

AWS構築初期費用： 1.0億円ランニング： 1万円（回線費除く）

※災害時は、2300万円/月＋回線費900万円・月


AWSを利用する際のポイント

44

常時同期が必要なマスタ類は、オンプレに配置し、AWS側に配置しない

繁閑の差が大きいシステムには向いている（例：ＤＲ対応や開発環境）

オンデマンドとリザーブドの選択は慎重に。セカンダリーも想定する。

停止時は極力リソースをリリースし、利用時にスクリプトで一挙に確保

海外リージョンでも、レイテンシーの問題は意外に少ない


デモ

45

デモ


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

awsを活用した 仮想デスクトップのdr構築事例 ～ …...awsを活用した...

Documents

awsを活用した仮想デスクトップのdr構築事例～ …...awsを活用した...