クラウド時代に求められる運用スタイル

昨日（９/２５）EnterpriseZine Dayに行って来た。
その内容をメモメモ。
次は、野村総研（ＮＲＩ）

クラウド時代に求められる運用スタイル
講師：ＮＲＩの人

をメモメモ・・・するけど、ごめん、senjuって、しらないので、よくわかんなかった・・・

---

NRIの運用サービスの売り上げ比率　４８．６％
　　コンサル　　１０．９％
　　開発・製品　３７．１％
　　商品販売　　　３．４％

開発と運用の牽制

本日のテーマ
　　システム基盤の柔軟性
　　運用基盤の柔軟性
　　運用と開発の壁
　　運用の半自動化

システム基盤の柔軟性
今まで：クラウドとオンプレミスの混在
　→クラウドにエンハンス

監視：
　統合＝共通運用基盤
　運用・障害マネジメント
　　リモートでオペレーション

運用標準化
　・開発のスキルセット
　・クラウドコントロールセンター

リモート統合管理の
メリット
　　マルチ環境への対応
　　障害時マネジメント強化
　　統制強化
　　運用体制の柔軟性
　　開発へのサービス向上

課題
　　標準化の推進
　　関係者の理解
　　ローカル運用との距離
　　多様なスキル取得

運用基盤の柔軟性
　業務アプリ・インフラ：所有から利用
　運用基盤は？

運用基盤
　　運用設計「運用基盤構築支援」
　　運用機能「所有から利用」
　　運用改善

mPLAT サービス提供イメージ

mPLAT運用イメージ：エージェントレス管理

mPLATイメージ：
　　監視　キャパシティ
　　自動化（アラート通知）

　クイックスタート
　All in one
　セルフサービス

導入効果

運用と開発の壁
　　メインフレーム時代：閉じた世界
　　オープン化　　　　：あいまいルール
　　仮想化・クラウド　：標準化
　　開発と運用の融合　：DevOps

ウォーターフォール
　　→リーンスタートアップ／アジャイル

開発部門
・アプリケーションを深く理解
・信頼性
・リリースは集大成

運用部門
・作業の１つ
・安全性

→セルフメンテナンス：申請管理、作業、稼動統計分析

運用の半自動化
運用自動化
　メリット
　　　オペミスなくなる
　　　統制強化、証跡管理

　課題
　　　柔軟な対応難しい
　　　維持管理大変

半自動化→ナビゲーション
　判断：人が介在する
ポイントは、自動化率の見極め

障害対応ナビゲーションツールSenju/EN ESP

まとめ
・システム基盤の柔軟性
　　リモート統合運用
・運用基盤の柔軟性
　　mPLAT
・運用と開発の壁
　　セルフメンテナンス
・運用の半自動化
　　Senju/EN ESP

オープンクラウド時代のシステム運用

昨日（９/２５）EnterpriseZine Dayに行って来た。

次は、基調講演その２

オープンクラウド時代のシステム運用
講師：ＣＵＰＡ 荒井さん

の内容をメモメモ。

---

・クラウド利用促進機構（ＣＵＰＡ）
　公共性、中立性、専門性
　クラウドイベントカレンダー
　クラウドコミュニティ２０１４

・クラウドの市場動向／利用状況
　１７年度までの年平均成長率は３２％
　クラウドファースト
　　　クラウドとオンプレ３４％
　　　オンプレ３０
　　　のこり：クラウドファースト
　　　　　→仮想プライベートクラウド２割

・パブリッククラウドの利用割合
　　ＡＷＳが圧倒的に多い

・プライベートクラウド
　　vCenter
　　Openstack→のびている

・ＡＷＳが圧倒的に一位だが、他のプロバイダーも拡大しつつある

・仮想サーバー：物理よりも多い→あたりまえ
　同様にクラウドファーストに

クラウド発展の歴史
　そんなに新しくない
　　・ＡＷＳ：２００６年
　　　→２０１１ぐらいから、加速度的に早くなる
　　・eucalyputs：２００９年位にはやった
　　・オープンベースでOpenStack
　Cloudstackも２０１０年に

ＡＷＳ：パブリッククラウドのパイオニアサービス
Ａｍａｚｏｎ３つのビジネス
　　　Ｅ－コマース
　　　マーケットプレイス、物流サービス
　　　ＡＷＳ
急成長を続けるアマゾンのクラウドサービス
　　IaaSにとどまらないＡＷＳの豊富なサービス
ＡＷＳの適用範囲
　　幅広い用途に利用可能
　　ＡＷＳのデータセンター（リージョン）
　　ＥＣ２：時間割チョイスできる
　　サービスの組み合わせで
Ａｍａｚｏｎ　ＶＰＣ：今は標準

OpenStack
自社で作りたい
データセンター側で機材

ソフトウェアの特徴
　　オープンソース、Apache2ライセンス
　　IaaS
　　標準化

プロジェクトの特徴
　多数のスポンサー
　操作イメージ
国内事例
　YAHOO
GREE
GMO
OpenStackDays Tokyo 2014→2015は２月に

Docker
・コンテナ技術
　Google Computer Engine App
Amazonもサポート
　AzureもKubernetes
　VMWareもKubernetes
240人に５００名以上の傘下登録

・コンテナ統合管理フレームワーク
　コンテナ：ユーザーごとにコマンド・権限の制限、操作範囲を再定義
　ハイパーバイザーとの違い
　コンテナ管理：構成管理、イメージ管理、実行管理
　Infrastructure as a code
Dockerが動く環境なら、どこでもＯＫ！
　ライブマイグレーション可能
　ＧＵＩ：エコシステムで

次世代ＩＴインフラ
・これまでのクラウドのシステム設計・運用
　　設定人手
・今後
　　アプリ再配布にdocker、
　　かなり動的管理（自動復旧）
ＡＷＳ＋Openstack+Dockerで作るＤＲシステム
→２、３年後

まとめ
・パブリック市場
　　ＡＷＳ
・オープンなクラウド技術
　　Openstack
・コンテナ技術
　　docker
・仮想プライベートクラウド
　　VPC
・ハイブリッドクラウド

インフラデザインパターン－ＮＴＴデータにおけるインフラ設計のパターン化の取り組み

昨日（９/２５）EnterpriseZine Dayに行って来た。
その内容をメモメモ。

誤操作で順番狂っちゃったけど、まずは基調講演の１本目

インフラデザインパターン～安定稼動のためのシステム運用
ＮＴＴデータにおけるインフラ設計のパターン化の取り組み

からメモメモ

---

アジェンダ
　はじめに
　なぜインフラ障害は起こるのか
　安定稼動に向けた対策
　　・可用性の向上
　　・グランドデザインによる標準化
　　　　非機能要求グレード
　　　　インフラデザインパターン
　　　　運用体制の検討－サービス仕様パターン
　　　　リスク低減・失敗防止－アンチパターン
　まとめ
　最後に


はじめに
・ＩＴアーキテクト人材の不足
・問題プロジェクト→上流工程で起こる
　　→要件定義：少数精鋭
　まとめよう！
　インフラのノウハウを体系的に

・デザインパターン
　　インフラデザインパターン
　　　セッション共有負荷分散パターン
　　→ひとつのツール

なぜインフラ障害は起こるのか
・システム障害→販売機会のロス、ブランドイメージダウン・・・
・セキュリティ上の問題
・なぜインフラ障害が起こるのか
　　システム：複雑になっている
　　メインフレームからＩＡサーバーまで
　　→システム単位に開発
　　→様々なシステム組み合わせ
　　この複雑な構成がもんだい
　　→原因の切り分け、対処がむずかしくなる
・仮想化統合がはやり
　　→コスト削減：経営サイド
　　　Ｐ２Ｖ：移行コストの観点で有効
　　　　→ただし、安定稼動しやすいという観点からは遠い
　　　　　なぜなら、ひとつのインフラに異なるシステムが混在
　　　　　　→仮想化によって複雑になる

安定稼動に向けた対策
　故障：オペミスが多い
　　→構成定義の変更により、システムが動かなくなる
　　　ＨＡ：安心・・・ということはない
　　　　→必要な要素というだけ。ハードウエア故障しか対応できない

　対策：可用性の向上
　　　未然防止（故障の防止）
　　　事後対策（迅速な復旧）
　間接的には
　　文書化と継続的なカイゼン
　　確認の守備徹底


　故障の防止
　　ＡＰ
　　　品質作りこみ
　　　ファイルセーフ

　　主にインフラ
　　　ＳＰＯＦ（単一障害点）の排除
　　　単純化
　　運用
　　　運用・設定の自動化→開発の際に
　　　ＩＴＩＬの適用

　復旧
　　ＡＰ
　　　ログメッセージの適切化
　　　リラン可能なバッチ処理の設計
　　インフラ
　　　影響と原因の分かるシステム監視
　　　バックアップ・リカバリー方式の最適化
　　運用
　　　運用体制・運用手順の整備
　　　事業継続管理（ＢＣＰ，ＢＣＭの策定）
　　　　→ディザスタリカバリサイトを作れという意味ではない
　　　　　意思決定／報道関係の対処

　　インフラの標準化：もっとも効果的
　　　　統合的な運用を可能とし、故障防止や迅速な復旧を実現

→インフラのグランドデザイン例
Ｓｔｅｐ１：現状システム開発
　　現状インフラ情報調査
　　課題・問題点
　　システムグルーピング
Ｓｔｅｐ２：時期インフラ構想
　　次期インフラ構想作成
　　実現方法の検討
Ｓｔｅｐ３：ＩＴロードマップの策定
　　ＩＴロードマップ策定

Ｓｔｅｐ１：現状
２軸：
　　スピード重視か、ロングライフ重視か
　　コスト重視か、品質重視か

→適切なグルーピング、適切なインフラ基盤

Ｓｔｅｐ２：標準インフラ構想
（１）要求の確認
（２）設計パターンの抽出
（３）ＩＴインフラ構成（設計方針の検討）
（４）ＩＴインフラ構成の確認

補足：要件定義が重要
　情報サービス産業協会（ＪＩＳＡ）の資料

Ｓｔｅｐ２－１：要求の確認
　　非機能要求：可用性、セキュリティ
　　→非機能要求グレード

Ｓｔｅｐ２－２：設計パターンの抽出
　　提案書の第三者チェック
　　実システム→抽象化・図案化→パターン
　　　・一目見ただけでおおよその設計方式を理解
　　　現在３２１パターン

パターン
　　インフラデザインパターン
　　クラウドデザインパターン
　　アーキテクチャーパターン
　　サービスしようパターン
　　基盤設計・運用ガイド
　　アンチパターン

Blueprints for hi avilability second edition
　可用性対策レベルと投資額の相関性

Ｓｔｅｐ２－３：ＩＴインフラ構成
　実際にアーキテクチャを書いていく
　　→論理レベルで：経営状況の変化につよい

Ｓｔｅｐ２－４：確認
・経営戦略と技術戦略の整合性
・制約条件など

メリット
・用気炎に対して最適なインフラ方式
・検討漏れ、みおとしぼうし
・コミュニケーションそごの問題
・短期的に身につけられる

そのほか
・サービスしようパターン
　　ＳＬＡをどうやって実装していくか
・アンチパターン
　　簡単にできるもの、公開資料に含めていない
　　　未然防止

まとめ
・安定稼動は一朝一夕ならず
　継続的な総合力が試される

360度ITパフォーマンスの可視化がビジネスを強靭にする

昨日（９/２５）EnterpriseZine Dayに行って来た。
その内容をメモメモ。

誤操作で、

360度ITパフォーマンスの可視化がビジネスを強靭にする

講師：日本ＣＡの人

が講演順番は後のほうなのに、先にアップしてしまった。
まあ、いいか。これをメモメモ

---

・CA=コンピューター・アソシエイツ

出そうで出ない性能、見えてそうで見えない性能
・ハードウェアの性能は上がっているが、
　サービスの性能問題は、いまだに解決しない
・共通
　動かしたら・・・
　昨日までは問題なかった・・
　どこがおかしいか？

しかも性能問題は、責任の所在がわかりにくい
　サイロでものを管理→切り分けが難しい

直面する問題
　クレームではじめて気づく
　特定の人間系に依存
　本末転倒：ログフレームワークの巨大化
　理解得られない
　新たな経験していない事態の遭遇

リスク要因・脆弱性が増加

性能問題の対応
・リリース直前に発覚
・全員集合になってしまう
・ステージングで再現しない
・オーバーヘッド
・本番でまた再発

運用フェーズでの障害は、障害実体の４０％
　最近：リリースタイミングを早くする

死活監視だけでは対応できない本番システムダウン
　→停止してくれれば、話は簡単
　　停止しないまでも、役割が果たせない
　→パフォーマンス・リスク・マネジメント
　　見えないとリスク→可視化

複雑化したシステムのパフォーマンス・リスクを可視化！
発現防止と迅速な対応を可能に

従来のシステム監視製品にアドオン、連携して仕様

ＩＴサービス性能リスク管理上の課題
　　・迅速に根本ノードを特定、可視化、自己防衛
　　・サービス（業務）単位でリアルタイムでＳＬＡ監視
　　・プロアクティブな予兆監視、本番前のリスク除去
　　・将来の投資計画の適正化

従来の監視→これから
　機器個別→ユーザー視点
　死活→予兆検知
　擬似トランザクション→実リクエスト

事例：
　あめりかんえきすぷれす
　ふぇいすぶっく
　itau BBA：データは取ってある。利用できない
国内：
　大手キャリア

ＣＡ　Ｗｏｒｌｄ１４