今日（７月２４日）、ＩＴインフラSummit2014に行って来た！
で、そこで聞いてきた内容をメモメモ。
まずはじめに
「みずほクラウド」を活用した攻めのインフラ
～プライベートクラウド構築の事例紹介～
みずほ銀行 正木氏
の内容をメモメモ
-----
・前半：みずほクラウドの構想、コンセプト
・後半：今年３月のＡＩＸの環境、活用方法（画面イメージ）
■みずほクラウドに関する数字
・６割削減
集約したとき、構築コストの削減
→個別環境との比較
削減する具体例
物理サーバー数 １３００台削減
インフラ構築工数の削減 ７割削減（設計標準化、自動化）
業務システム環境提供期間 最短３日 個別３～４ヶ月
→（シミュレーションの範囲だが）１００億、２００億規模でおちる
１．みずほクラウドのスケッチ
（１）インフラに関する課題認識
２００８年 クラウド（パブリック）が世の中に発振
２００９年 みずほのインフラ状態→サイロ型だった
物理サーバー多い、リソース低位（半分遊休）
同じＯＳでも、業務システムごとに違う
【３つの技術】
・仮想化技術 安く、早くリソース
・設計標準化
・共用化
（２）みずほの目指すクラウド像
・パブリッククラウドの長所を享受しつつ
・「セキュリティ」「可用性」を自社でコントロールできるプライベートクラウド
（３）スコープ
仮想化技術を用い、「サーバー」「ストレージ」のリソース、ならびに「運用管理機能」
を共通化・集約化
（４）対応ステップ
～ ２００９年 個別構築
～ ２０１１年 第一世代 標準化を開始、物理集約
→当時管理ツールが充実していなかった
２０１２年～第二世代 仮想化技術、自動構築、共用化
→管理ツールが充実
早い、安い実現
２．みずほクラウドの概要
・ＡＩＸ環境の事例
大きなプール→仮想サーバーをつくる
遠隔地保管のしかけ（ほしいといえば、リソース提供）
・みずほクラウドが実現した主な機能
障害児の影響低減策に関する整理
・ハードウエア障害
・業務アプリ障害
・ＣＰＵループ障害→上限コア数を設定
・効果
設計標準化、自動化がきいている
デプロイの機能→７割強削減（コンサバにみて）
物理サーバー
第一世代：物理集約 ３割
第二世代：仮想化集約８割
従来 ：５年間使えられるリソースを調達
クラウド：１年分だけ
従来 ：開発ピークに合わせてリソース
クラウド：必要なリソースを動的に
従来 ：ＨＷが変わるとＯＳ代わる
クラウド：ハードのみ変更
３．「みずほクラウド」で用いたテクノロジー
２０１４年３月稼動
・仮想化 ＰｏｗｅｒＶＭ、ＬＰＡＲ
・仮想サーバーの筐体間移動（ＬＰＭ）→メモリ交換など、突発処理
業務の継続性、構築期間の短縮
・プロビジョニング（デプロイ）ＬＰＡＲ
・ＳＡＮ仮想化ストレージプール（ＳＶＣ）
データの価値に合わせて使い分け
・稼動統計管理ツール
→統計情報ＤＢ
４．ツールを用いた「早い」環境構築、他（画面イメージ）
（１）仮想サーバーの構築（プロビジョニング、デプロイ）
オペレーションはすぐできる
（２）ＳＡＮ仮想化ストレージのボリュームを構築し、該当仮想サーバーと紐付け
（３）リソースプールの状況管理
（４）仮想サーバーの利用状況管理
リソースプールのＣＰＵ使用率
カスタマイズできる
（５）ツールによるリソース管理サイクル
１．ツールによる余裕リソースの把握
２．余裕リソースに基づくリソース計画
３．リソース拡張
４．業務システムへの環境提供
５．まとめ
ポイント
（１）ベンダーから提案のあった最新仮想化技術および活用事例に真摯に向き合う
対応度合いはかる
（２）経営層とインフラの課題、仮想化ソリューション導入時の効果予測等を共有し、対応の方向性を導出
共通的なインフラを企画（サイロから脱却）
（３）プライベートクラウドの本格稼動に向けて、段階的な歩みを選択
設計標準化ができないと、デプロイもできない
インフラの景色が変わる
攻めのインフラ
・経営貢献
・サイロ化→仮想化により疎結合
で、そこで聞いてきた内容をメモメモ。
まずはじめに
「みずほクラウド」を活用した攻めのインフラ
～プライベートクラウド構築の事例紹介～
みずほ銀行 正木氏
の内容をメモメモ
-----
・前半：みずほクラウドの構想、コンセプト
・後半：今年３月のＡＩＸの環境、活用方法（画面イメージ）
■みずほクラウドに関する数字
・６割削減
集約したとき、構築コストの削減
→個別環境との比較
削減する具体例
物理サーバー数 １３００台削減
インフラ構築工数の削減 ７割削減（設計標準化、自動化）
業務システム環境提供期間 最短３日 個別３～４ヶ月
→（シミュレーションの範囲だが）１００億、２００億規模でおちる
１．みずほクラウドのスケッチ
（１）インフラに関する課題認識
２００８年 クラウド（パブリック）が世の中に発振
２００９年 みずほのインフラ状態→サイロ型だった
物理サーバー多い、リソース低位（半分遊休）
同じＯＳでも、業務システムごとに違う
【３つの技術】
・仮想化技術 安く、早くリソース
・設計標準化
・共用化
（２）みずほの目指すクラウド像
・パブリッククラウドの長所を享受しつつ
・「セキュリティ」「可用性」を自社でコントロールできるプライベートクラウド
（３）スコープ
仮想化技術を用い、「サーバー」「ストレージ」のリソース、ならびに「運用管理機能」
を共通化・集約化
（４）対応ステップ
～ ２００９年 個別構築
～ ２０１１年 第一世代 標準化を開始、物理集約
→当時管理ツールが充実していなかった
２０１２年～第二世代 仮想化技術、自動構築、共用化
→管理ツールが充実
早い、安い実現
２．みずほクラウドの概要
・ＡＩＸ環境の事例
大きなプール→仮想サーバーをつくる
遠隔地保管のしかけ（ほしいといえば、リソース提供）
・みずほクラウドが実現した主な機能
障害児の影響低減策に関する整理
・ハードウエア障害
・業務アプリ障害
・ＣＰＵループ障害→上限コア数を設定
・効果
設計標準化、自動化がきいている
デプロイの機能→７割強削減（コンサバにみて）
物理サーバー
第一世代：物理集約 ３割
第二世代：仮想化集約８割
従来 ：５年間使えられるリソースを調達
クラウド：１年分だけ
従来 ：開発ピークに合わせてリソース
クラウド：必要なリソースを動的に
従来 ：ＨＷが変わるとＯＳ代わる
クラウド：ハードのみ変更
３．「みずほクラウド」で用いたテクノロジー
２０１４年３月稼動
・仮想化 ＰｏｗｅｒＶＭ、ＬＰＡＲ
・仮想サーバーの筐体間移動（ＬＰＭ）→メモリ交換など、突発処理
業務の継続性、構築期間の短縮
・プロビジョニング（デプロイ）ＬＰＡＲ
・ＳＡＮ仮想化ストレージプール（ＳＶＣ）
データの価値に合わせて使い分け
・稼動統計管理ツール
→統計情報ＤＢ
４．ツールを用いた「早い」環境構築、他（画面イメージ）
（１）仮想サーバーの構築（プロビジョニング、デプロイ）
オペレーションはすぐできる
（２）ＳＡＮ仮想化ストレージのボリュームを構築し、該当仮想サーバーと紐付け
（３）リソースプールの状況管理
（４）仮想サーバーの利用状況管理
リソースプールのＣＰＵ使用率
カスタマイズできる
（５）ツールによるリソース管理サイクル
１．ツールによる余裕リソースの把握
２．余裕リソースに基づくリソース計画
３．リソース拡張
４．業務システムへの環境提供
５．まとめ
ポイント
（１）ベンダーから提案のあった最新仮想化技術および活用事例に真摯に向き合う
対応度合いはかる
（２）経営層とインフラの課題、仮想化ソリューション導入時の効果予測等を共有し、対応の方向性を導出
共通的なインフラを企画（サイロから脱却）
（３）プライベートクラウドの本格稼動に向けて、段階的な歩みを選択
設計標準化ができないと、デプロイもできない
インフラの景色が変わる
攻めのインフラ
・経営貢献
・サイロ化→仮想化により疎結合
アクセス
トータル
ランキング
