既存システム移行時の hints &...

1

© 2013 IBM Corporation

既存システム移行時の Hints & Tips

IBM PureApplication サマー・スクール第２部プランニング編：PureApplication System によるクラウド基盤の設計と構築

日本アイ･ビー･エム WebSphere事業部上野亜紀子 ([email protected])

2

© 2013 IBM Corporation2

Disclaimerこの資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エムシステムズ・エ

ンジニアリング株式会社の正式なレビューを受けておりません。

当資料は、資料内で説明されている製品の仕様を保証するものではありません。

資料の内容には正確を期するよう注意しておりますが、この資料の内容は2013年07月現在の情報であり、製品の新しいリリース、修正などによって動作／仕様が変わる可能性があるのでご注意下さい。

PureApplicationSummer School

3


Agenda§1. 既存システムからPureApplication Systemへの移行検討の前に

§2. 既存システムからPureApplication Systemへの移行に関する Hints & Tips

§3. まとめ

当セッションでは、既存システムからIBM PureApplication System への移行を検討する際のHints & TipsやFAQ をご紹介します。

当セッションでは、既存システムからIBM PureApplication System への移行を検討する際のHints & TipsやFAQ をご紹介します。

当セッションはIBM PureApplication System Summer School プランニング編の

最後のセッションになります。

プランニング編の各セッションではIBM PureApplication System (以後PureApp) のプラニングのフェーズにおいて必要な知識や要検討事項、PureAppを活用する上での設計指針をご紹介してきました。

本日のセッションの多くは、PureAppをPureAppらしく活用し、これからのクラウド基盤として利用する際のヒントになる情報やクラウドを意識した設計指針を主にご紹介しています。

ただし、PureAppは新しいクラウド基盤としてのみでなく、これまでのシステムの次期プラットフォームとして検討されるケースも多くあります。PureApp ではこれまでのITシステム構築とは思想も設計も大きく異なる部分があり、既存システムからの移行時特有の考慮点などもあります。

当セッションではPureAppを既存システムからの移行先プラットフォームとして考えたときにフォーカスし、既存システムをPureAppに移行する際に特に事前に考慮すべき点やガイドをHints & Tipsという形でご紹介します。

4


§1.既存ITシステムからPureApplication Systemへの移

行検討の前に

具体的なHints & Tipsに入る前に、既存ITシステムからPureAppへ移行を検討する際に、理解しておくべき製品登場の背景や特徴をご紹介します。

5


当セッションの目的

IBM PureApplication Systemのコンセプトと特徴を確認した上で、IBMPureApplication System とトラディショナルな IT システム構築の違いを理

解する

既存システムからの移行先としてIBM PureApplication System を検討す

る際に確認すべき項目や考慮事項をまとめる

既存システムからPureAppへの移行に関する FAQや考慮点に加えて、PureAppらしくシステムを構築するための考え方のシフト、指針をまとめる

※当セッションでは以降のページからIBM PureApplication SystemをPureAppと記載します。

前述のとおり、当セッションではPureAppを既存システムから移行する際にフォーカ

スしたセッション内容となっています。このセッションでカバーする内容はいかのとおりです。

•PureApp検討前に理解しておくべき製品のコンセプトや特徴を復習します

•既存システムからの移行先としてPureAppを検討する際に、確認すべき項目や考

慮点をご紹介します

•既存の踏襲だけでなく、PureAppをPureAppらしくクラウド基盤として活用してより

そのメリットを享受できるような発想の転換の重要性などをご紹介します。

6


IBM PureApplication System 登場の背景

企業内ITインフラの現状新しいITトレンドとインフラ要件

資源コスト重視

課題：運用コストの増加

✓資源効率化

✓個別最適化による

安定志向

65%

新規プロジェクト既存インフラ

の運用保守35%

Source: 2012 IBM Data Center Study: www.ibm.com/data-center/study

ネットワーク

ストレージHW

サーバーHW

仮想化基盤

省力化

各種個別設定各種個別設定運用作りこみ運用作りこみ

ITの役割の変化が求められている

ビジネスを加速する新しいITインフラ

✓ 市場の変化や消費や行動の着実なフォロー

✓ 常に新たなユーザー・エクスペリエンスを取り込む

✓ 分析や最適化、予測などを行う

✓ 「業務効率化」から、「新しい価値創造」へのシフト

エンタープライズDevOps

はじめにIBM PureApplication Systemが登場した背景を復習します。ここでは大きく２つの側面に分けて確認します。

１つ目は企業内ITインフラの現状とその課題です。多くの企業が過去数年の間に、サーバーの乱立や資源の無駄を課題として仮想化やサーバー統合に取り組んできました。また昨今では社内統合基盤やクラウド化まで進められている企業も多くなってきています。ただし多くのお客様において実現できているのは、仮想化技術の導入またはIaaSレベルのクラウド化です。その結果、資源の効率化、資源コストの削減という観点では一定の成果が得られたものの、仮想化基盤の上で稼動するアプリケーションの実行環境はこれまでどおり案件やプロジェクト別に個別設計、構築、運用を実施し、その作りこみに今もまだ多くの工数がかかっています。また、案件ごとの個別最適化による安定志向により、案件やプロジェクト別に個別運用を実施するため、ITコスト全体で見ると既存インフラの運用保守が占める割合が65%にものぼり、新規プロジェクトやイノベーションに投資できない状態が新たな課題として見えています。

一方で、世の中では新しいITトレンドの台頭とともにITの役割の変化が求められています。よりビジネスに直結した価値を生み出すインフラとして、クラウド、ソーシャル、ビッグデータ、モバイルが情報システムの新たなプラットフォームとして定義され、その重要性が増しています。また、システム開発の新たなトレンドとしてリーン・スタートアップ、Enterprise DevOpsといった考え方にも注目が集まっています。これらは、システム構築の考え方や構築方法をこれまでと大きく変えるものです。このようにITインフラのあり方自体が大きく変わろうとしています。

この両方を満たすために期待される１つのテクノロジーがPaaSです。ただしPaaSはカバーする領域が広いため、企業内でPaaSを実現することは容易ではありません。

7


これからの企業システム

Systems of Interaction（相互に作用しあうシステム）

継続的な顧客体験パートナーを含めたバリュー・チェーン

クラウドベースサービス

Systems of Engagement（人とかかわりあうシステム）

Systems of Record（基幹システム）

Internet of Things（“モノ”のインターネット）

CRM HR

DB ERP

• 運用・保守ノウハウを蓄積、業務効率化と安定稼動を重視

• ビジネス・ニーズへの即応のために柔軟性とアジリティーが求められる• ビジネスの効率化を重視

次にこれからの企業システム像をおさらいしましょう。

企業内にはまだまだ従来型のいわゆる基幹システム（図中のSystem of Record 、以後SoR）が多く存在し、従来どおりの運用・保守とゆるぎない安定稼動が求めら

れます。ただし、今後は前述のクラウド、ソーシャル、ビッグデータ、モバイルの新しいプラットフォームが不可欠となり、図中のSystem of Engagement (SoE)とInternet of Things (IoT) というドメインの重要度も増してきます。

SoR(System of Record)とは、いわゆる従来型システムが対象としてきた領域です。

企業内などの限られた環境において、トランザクション処理を実行し、例えば売り上げデータや顧客情報をDBに格納し、CRMやERPなどで利用します。IoT(Internet of Things)とは、情報のインプットとして、マシンデータやセンサーデータ、ブログやTwitterなどのWeb上のデータも対象になっていることを示しています。SoE(System of Engagement)とは、Twitterや、Facebookのように、データがコラボレーションする世界を示しています。

またSoEやIoTといった新しいドメインが増えることで、構築・管理対象のプラットフォームが増えるなど新たな課題があり、さらにSoEやIoTではこれまでよりも、迅速なシステム構築が求められます。こうした新たな課題や要件に対応しつつ、SoRの従来の要件を満たすことがIT部門に求められる時代になってきています。

そして、PureAppはPaaSの特徴である即応性、利便性を実現しつつエンタープライズ利用で求められるQoSを満たすことができるまさにSystems of Interactionのクラウドベース・サービスとして最適な垂直統合型PaaS環境を提供します。

8


当セッションでカバーする領域

Systems of Record

CRM HR

DB ERP

Systems of Engagement

Internet of Things


PureAppでのシステム構築

トラディショナルなITシステム構築とは異なる点が多い

従来の考え方や手法とのギャップの把握

Systems of Record の次世代のプラットフォームとしてPureAppを考える

エンタープライズ・クラウドの基盤としてPureAppを考える

製品コンセプトや機能にあわせる or 既存の運用にあわせる？作りこみ？

それぞれのメリット・デメリットは？

既存の踏襲 vs 新しいことへの取り組み

ここまででご紹介したPureApp登場の背景の内容を踏まえて、当セッションでは以

下の２つのケースにフォーカスします。

•SoRの移行先または次世代のSoRのプラットフォームとしてPureAppを検討する

•企業内クラウドの基盤としてPureAppを検討する

PureApp上でのシステム構築と既存のトラディショナルなシステム構築では考え方や手法が大きく異なる部分があり、既存システムの移行先としてPureAppを検討す

る場合は、プラニングの時点でアセスが必要となります。

アセス時のポイントは以下になります。

•従来の考え方やシステム構築の手法とのギャップを把握します

•ギャップがある項目に対してギャップを埋めるには何が必要かを確認します

•製品コンセプトや機能にあわせるのか？既存にあわせるのか？新たに作りこむのか？などをそれぞれのメリット、デメリットから検討します

アセスの際には、単に技術的な観点や移行の工数・コストの観点だけでなく、将来の基盤のあるべき姿に向けてのステップも合わせて検討することが重要です。

9


PureApplication Systemのプラニングをはじめる前に

IBM PureApplication System の設計指針と特徴を理解する企業のワークロードに最適化されたオール・イン・ワンの PaaS型クラウド環境

高品質なシステムを少ない時間とコストで構築・運用できるよう事前に設計

PureAppのコンセプトにそった使い方をすることでメリットを享受できる

製品機能を使いこなすことで、エンタープライズ・クラウドや企業システムむけのノウハウを最大限活用できる

専門家の高度な知見を実装

設計段階から徹底的に統合

煩雑な作業からの解放

PureAppのプラニングを始める前に、今一度PureApp自身について復習しましょう。

PureApp登場の背景でご紹介したとおり、PureAppは企業内PaaSを簡単、迅速に提供するAll in oneの製品です。“All in one”と“簡単、迅速”というキーワードを実現するためにPureAppでは事前にPaaS環境として利用するための最適解を詰め込んで設計、機能の導入がされています。これは逆に言うと、あらかじめあるていどきまった設計にそって製品が提供されることを意味します。

PureAppを検討する際には、この「あらかじめあるていどきまった設計」とその背後

にあるコンセプトを理解することも重要です。

ここでは主な特徴とコンセプトをリストしていますが、他のセッション資料にもPureAppのコンセプト、特徴は多く紹介されていますのであわせて参照してくださ

い。

また、もう１つ重要なことは、あらかじめビルトインされている設計要素、機能をできるだけ素直に使いこなし、PureAppの設計思想に沿った使い方をすることで、そのメリットを最大限に享受できるということです。繰り返しになりますが、PureAppは企業内PaaS向けに事前に設計され、多くのノウハウやベストプラクティスが組み込まれています。また、垂直統合型製品としてHWからSWの層までまたがって最適化さ

れています。なるべく製品の設計思想にそってビルトイン機能を活用することで、製品を導入するだけで、これらのベストプラクティスを最大限活用できることになります。

10


IBM PureApplication Systemのポジショニング

ネットワークネットワークネットワークネットワーク

ストレージHW ストレージHW ストレージHW ストレージHW

サーバーHW サーバーHW サーバーHW サーバーHW

仮想化基盤仮想化基盤仮想化基盤仮想化基盤

O/S O/S O/S O/S

ミドルウェアミドルウェアミドルウェアミドルウェア

稼働環境稼働環境稼働環境稼働環境

データ管理データ管理データ管理データ管理

アプリケーションアプリケーションアプリケーションアプリケーション

従来のIT環境(個別構築)

IaaS(Infrastructureas a Service)

PaaS(Platform

as a Service)

SaaS(Software

as a Service)

個別設計; 高コスト; 長期間の構築

標準化; 低コスト; 迅速な構築

従来手法で個別設計

製品組込済みで省力化

PureApplication System

最後にPureAppのポジショニングをおさらいします。

PureAppはPaaSを実現する製品です。青い四角で囲われている部分がそれぞれのクラウド・タイプで標準化、省力化される部分になります。

PaaSを実現するには青い部分において仮想化、標準化、自動化をPaaS側で実装する必要があります。これをNWからアプリケーションの各レイヤーにおいて製品

を選定、調達して、設計、導入を行いまた各層にまたがって連携させ、さらに自動化の仕組みを作りこんで・・・とユーザーが１から組み立てていくのは現実的ではありません。また、PaaSはOSやMWおよび実行環境までを含むため、そのバリエーションが増えれば増えるほど、標準化、自動化が難しくなります。PureAppはこの青の部分を製品に組み込み済みですぐに使えるPaaS環境として提供しています。

11


PureApp への既存システムからの移行の検討

大前提

製品のコンセプト、機能の理解

既存システムに求められる要件

現状での実現方法の整理

検討内容

各要件に対するPureAppでの実現可否の確認

現行システム/現行手順とのギャップの確認

現行の仕組みとの共存可否の確認

現行の踏襲 or 組み合わせ or 新規実現方法でのメリット/デメリットの確認

次の章でHints &TipsやFAQを紹介します。各トピックにおいてすべての案件にあ

てはまる正解はありません。考慮点や上記の検討項目を踏まえて最適解を検討してください。

次の章でHints &TipsやFAQを紹介します。各トピックにおいてすべての案件にあ

てはまる正解はありません。考慮点や上記の検討項目を踏まえて最適解を検討してください。

この章の内容をまとめます。

既存システムを移行する際には、どうしても既存システムや従来のITシステムの設計や手法をそのまま踏襲する方向で考える傾向が強まりますが、PureAppの場合には必ずしもそれが最適解とは限りません。また既存の手法がそのままPureApp上では実現できない可能性もあります。

まずは大前提として製品コンセプト、機能をきちんと理解することかとからはじめましょう。次に既存システム構築時に振り返って、当時求められた要件とその実現方法を整理しておきましょう。移行先としてPureAppを検討するにあたっては、とくに重要な要件に対してPureAppで推奨される実現方法を確認します。次に現行システムでの手順との違いやギャップを把握します。その上で、現行の仕組み・手順の踏襲がよいのか、PureAppの製品機能を活用するのか、あるいは既存の方法とPureAppの機能を組み合わせるのかを検討します。その際に、各案のメリット・デメリットを確認して、最適案を決定します。

ただし、ここはあくまでプラニングのフェーズの話なので、実現方法を詳細に検討したり１つの案に最終確定するのではなく、PureAppを活用するためのポイントを確認したり、PureAppへの移行の妨げとなるような大きな制約や考慮点がないかを確認するという観点でアセスすることに注力しましょう。

また、既存システムからの移行の際には、既存の手順、既存の運用がPureAppでもそのまま利用できるか？という観点で確認をしがちですが、現行の手順や運用は手段であって、それぞれには目的（要件）があるはずです。各要件がPureAppで満たせるか？という観点での確認をすることで、今よりも運用が楽になったり、不要となる運用もでてきます。今やっていることができるか？ではなく、お客様要件が満たせるか？という観点で考えることを意識することが重要です。

12


§2.既存システムからPureApplication Systemへの移行に関する Hints & Tips

13


Hints & Tips 一覧

HW、SWの決定・購入手続き編キャパシティ・プラニングHW、SWの調達

体制・組織

基盤設計編ネーミング・ルールホスト名の扱い既存環境からの移行方法仮想化環境の管理Windowsシステムの移行

システム・デザイン指針

次のページからHints & Tipsを紹介します。このセッションでは各トピックについて概要や指針を

ご紹介します。関連する詳細説明が別セッションでカバーされている内容については

のように参照先のセッション名を記載しています。

次のページからHints & Tipsを紹介します。このセッションでは各トピックについて概要や指針を

ご紹介します。関連する詳細説明が別セッションでカバーされている内容については

のように参照先のセッション名を記載しています。

運用設計編PureApp環境での監視既存監視システムとの連携バックアップPureApp環境での保守

クラウド基盤設計

このページは次ページからご紹介するHints & Tipsの一覧になります。

各トピックごとに１、２ページでご紹介しています。トピックによっては、考え方や発想の転換が必要という内容だったり、具体的な機能に関する話だったりとレベル感が異なりますが後生量ください。

なお、当セッション資料は各トピックについて概要や考慮点、検討時の指針を主にご紹介しています。関連機能の詳細については、当セミナーの各詳細セッションでカバーしています。関連する詳細説明が別セッションでカバーされている内容については資料の右上に参照先のセッション名を記載していますので、あわせてご参照ください。

また、当セッションはプランニング編でのHints & Tipsになります。より実践的なHints & Tipsは別セッションである、第3部応用実践編PureApplication Systemにおけるパターン開発と運用･管理の「Lessons Learned」セッションにてカバーして

いますので、そちらもぜひ参考にしてください。

14


HW、SWの決定、購入手続き

はじめに、HW,SWの決定、購入手続きなどプランニングの早いフェーズでのHints & Tipsをご紹介します。

15


キャパシティ・プラニング

案件単位の見積もり、案件ごとのリソース割り当て

従来のITシステムの考え方

案件ごとにリソースを見積もり

物理サーバーをシステムに割当てていく

将来の需要も踏まえてリソースを確保

PureApp では“クラウド環境”単位での考え方へシフトが必要

クラウド・グループ単位での見積もり

クラウド・グループからリソースをシステムに割り当てる

システム拡張時はプールから必要分を割り当て

クラウド環境ではリソースの共有、割り当ての仕組みが変わるピークに応じてシステム間でリソースを融通しあう

不要になったリソースはプールに戻して別案件で再利用する

クラウド環境単位での見積もり、ニーズに応じたリソースの割り当てクラウド環境単位での見積もり、ニーズに応じたリソースの割り当て

A案件

B案件

C案件

A

案件

B

案件

C

案件


PureAppの場合、既存システムからの移行であってもキャパシティ・プラニングの考

え方が従来と異なります。

従来の「案件単位で厳密に必要なキャパシティを各種要件から見積もりを実施し案件単位で物理サーバーを割当てていく」という方法から、PureAppでは「クラウド環境単位」での考え方にシフトが必要となります。

PureAppではリソースは案件ごとに管理して割当てるのではなく、複数の案件やプロジェクトまたはエンタープライズ・レベルで共有するクラウド環境で管理していくことになります。

これまでのように案件ごとに必要なリソースも概算レベルでの見積もりは必要になりますが、あくまで管理する単位はリソース・プール単位で、必要なときに必要なだけ割当てていくという考え方に変わります。

またこれまでのように、いったん割当てたリソースは基本的にはそのシステムのライフサイクルに渡って使い続けるのではなく、業務間で負荷に応じて融通しあったり、不要になったリソースはプールに戻して別案件で再利用するなど新しい運用が実現できる可能性もありますので、クラウド環境単位で複数の業務間でリソースを共有するということを念頭においた準備や管理が必要となります。

16


HW、SWの調達

HWモデルの選定

Mini(32/64) / Tall(96/192/384/608) ラックの選択

PaaSに必要な基本HW、SWを同梱

追加SWライセンスの洗い出しと調達

IBM MWはサブ・キャパシティー・ライセンスの適用が可能

他社製品に関してはそれぞれの製品のライセンス・ルールを確認

デプロイの仕組み、仮想化環境でのライセンス管理制御の理解が重要

ネットワーク

ストレージHW

サーバーHW

仮想化基盤

O/S

ミドルウェア

稼働環境

データ管理

アプリケーション

Power7+ / Intel x86 計算ノードStorwize V7000（SSD+HDD)BNT 64 PT イーサネット・スイッチ

仮想システム

Hypervisor

管理機能

デプロイ機能OSS3rd party製品

統合管理ノード

Windows


VMware

PureAppではPaaSに必要なHWおよび基本SWは製品に同梱されていますので、

各製品を個別調達するのではなく、必要なリソース・プールのサイズと将来の需要を見越したラックモデルを選定することになります。

PureAppに含まれないSWを利用する際には、従来どおりの必要ライセンスの洗い出しと調達になります。IBM ミドルウェア製品については、サブキャパシティー・ライ

センスの適用が可能です。他社製品については、それぞれの製品のライセンス・ルールを確認してください。PureAppはVMware/Power VMでの仮想化を前提とし

た製品ですので、各ソフトウェア製品の仮想化環境でのライセンスの考え方を理解した上で、適切なライセンスを取得してください。

17


体制・組織

案件単位のプロジェクト体制、案件単位の個別対応

従来のITシステム構築

プロジェクト単位での資源の調達

組織単位での予算管理

エンタープライズ・レベルでの考え方にシフトエンタープライズ単位での資源の調達

プロジェクト、組織をまたがった予算管理、資産管理

組織全体の最適化を意識リソース、ライセンスの共有

課金の仕組みへの取り組み

パターンを活用したガバナンスの徹底

新しいロールとチーム編成

エンタープライズ単位、クラウド環境単位での対応へのシフトエンタープライズ単位、クラウド環境単位での対応へのシフト

パターン作成者

パターン・デプロイヤー

カタログ管理者

システム管理者

Aシステム Bシステム Cシステム

クラウド管理者

PureAppを活用するにあたりもう1つ従来と大きく異なってくるのは体制や組織のあ

り方です。

PureAppに限らず企業内クラウドを運用するにあたっては、今後はエンタープライズ単位、クラウド環境単位での体制や対応へのシフトがクラウドを成功させる1つの鍵になってきます。

従来のITシステム構築（プロジェクト単位での資源、予算の管理）と異なり、クラウド環境ではエンタープライズ単位で資源や予算を管理する必要が出てきます。簡単には実現できる話ではないですが、今後クラウド環境を運用する上では下記のような体制や仕組みを揃えていくことも必要となってくることを意識しておきましょう。

•組織単位でのリソース、ライセンスの共有

•組織単位でライセンスや資産を管理するのではなく、使った分だけユーザー部門に課金する

•パターンを活用して社内ITの標準化、ガバナンスを徹底する

•クラウドの管理者、パターンの管理者など新しいロールとチームが必要となってくる

18


基盤設計

次に基盤設計に関するHints & Tipsをご紹介します。ここでは具体的な内容から考え方的なTipsなど複数のトピックをご紹介します。

19


ネーミング・ルール

仮想マシン名

PureAppが自動作成

環境プロファイルを使ってフォーマットの指定は可能

管理者が主に使用する名前のため業務アプリケーションに直接的な影響はない

WebSphere Application Server環境でのルー

ル

セル/ノード/クラスター/動的クラスター

ユーザー設定のフォーマット＋自動採番

プロファイル名

固定

アプリケーション・サーバー/ODR/Webサーバー

名

PureAppのネーミング・ルールを理解し、既存のネーミング・ポリシーとの

ギャップとその影響度を確認する

PureAppのネーミング・ルールを理解し、既存のネーミング・ポリシーとの

ギャップとその影響度を確認する

前述のとおりPureAppではPaaSを簡単に実現できるように事前設計されています。ユーザーがカスタマイズできる部分も多くありますが、PaaSを実現する上で基本的な作業はすでに仕組みが自動化されており、ネーミング・ルールが一部決まっているものもあります。

従来のITシステム構築のようにユーザーが１からすべての名前を決めて割当てていく方式とは異なりますので、PureAppのネーミング・ルールを理解し、既存のネーミング・ポリシーとのギャップとその影響度を確認する必要があります。

PureAppによって自動的に決定される名前の１つに仮想マシン名があります。仮想

マシン名は基盤管理者が主に使用するもので、業務アプリケーションに直接的な影響があるものではありませんが、PureAppが自動作成することを認識しておいて

ください。（一部フォーマットの指定は可能）

WebSphere Application Server (WAS)環境でもこのページに記述しているように

各コンポーネントの名前が一定のルールにしたがって自動生成されます。すべのコンポーネントにおいてPureAppが自動生成する部分があるため、基本的には現状

と同じ名前を使うことはできないと理解してください。具体的な例は次のページで紹介しています。

20


(参考) WebSphere環境のネーミング・ルール

セル/ノード/クラスター/動的クラスター

ユーザー設定のフォーマット＋自動採番


固定

アプリケーション・サーバー/ODR/Webサーバー

名

自動生成

ユーザー設定フォーマット

ノード名

動的クラスター名

セル名

アプリケーション・サーバー名 Webサーバー/ODR名


このページは各コンポーネントごとにユーザーが指定できる範囲（おもにパターンなどで指定するフォーマット）と、デプロイ時にPureAppが生成する実際の名前の例を示しています。

21


ホスト名の扱い

PureAppでのIPアドレスの割り当てIPグループ登録時にIPアドレスの逆引きができることが必須

仮想マシンのデプロイ時に動的にIPアドレスを割り当て

考慮点デプロイ時までIPアドレス / ホスト名が確定しない

デプロイ時に任意のIPアドレスを割当てることも可能（仮想システム・パターンを利用時）

それぞれの方法のメリット・デメリットを確認すること

明示的にホスト名を割り当てていた従来のITシステム構築と異なり、ホスト名はIPアドレ

スが割当てられるデプロイ時に確定する

明示的にホスト名を割り当てていた従来のITシステム構築と異なり、ホスト名はIPアドレ

スが割当てられるデプロイ時に確定する

IPグループ

192.168.1.11

192.168.1.12

192.168.1.13

DNS

192.168.1.11 － host11.abc.com

192.168.1.12 － host12.abc.com

192.168.1.13 － host13.abc.com

・・・①

・・・②

② ②

①

①

ホスト名にも注意が必要です。明示的にホスト名を割り当てていた従来のITシステム構築と異なり、ホスト名はIPアドレスが割当てられるデプロイ時に確定します。

PureAppでは各クラウド・グループに対して仮想マシンをデプロイ時に割当てるIPアドレスのプールを持たせておきます。このIPのプール（IPグループ）作成時に、登録されるIPアドレスはDNSにて名前解決、逆引きの解決ができる必要があります。

PureAppでは仮想マシンのデプロイ時にこのIPグループから空いているIPアドレスがアサインされ、そのIPアドレスに基づいてホスト名が決定するため、デプロイ時までIPアドレス/ホスト名が確定しません。既存システムからの移行で、外部システムが

ホスト名を使ってアクセスをしている場合などは考慮が必要となりますので、影響度を確認してください。

また、（仮想システム・パターンの場合）決めうちのホスト名のアサインが必要であれば、デプロイ時にIPグループからIPアドレスを自動的にアサインするのではなく、管理者が明示的にIPアドレスを指定することも可能です。

22


Private Clouds

Public Clouds

Public Clouds

Public Clouds

Private Clouds

Public Clouds

Private Clouds

パターン

既存環境からの移行方法

PureAppではパターンを軸にシステムを構築

PureApp向けに設計されたパターンを使って品質の高いシステムを迅速に構築できることが最大の

メリット

ハイパーバイザー・エディションや既成パターンの標準構成をなるべく採用することでエキスパートのベスト・プラクティスを活用できる

今動いているものをそのまま移行するのではなく、再利用性の高いPaaSにあったパターンを

設計して、パターンを繰り返し活用することが重要

P2V、V2Vによる既存環境の移行はできないP2V、V2Vによる既存環境の移行はできない

新しいプラットフォームにあわせたシステム構築方法への改革

クラウド環境に共通で使えるパターン作成でハイブリッド・クラウド化への準備

ハイパーバイザー技術に詳しいお客様や既存システムが仮想化環境上に実装されているお客様の場合、P2VやV2Vを使って移行をしたいという要件もあるかと思いますが、PureAppでは今動いているものをそのまま移行することはできませんの

でご注意ください。

PureAppでは再利用性の高いパターンを使ってシステムを構築することを製品の

基本方針としています。パターンを軸にしたシステム構築を行うことで、ハイパーバイザー・エディションや既成パターンに含まれるベストプラクティスを活用していただくことができます。また、クラウド環境に共通で使えるパターンを作成することで海外やグループ企業への横展開や将来のハイブリッド・クラウド化への準備につながることを意識して、最初にパターンの作成が必要であるということを理解してください。

23


仮想化環境の管理

PureAppはHW、仮想化レイヤーの機能を管理者に意識させない設計になっている。“PureApp基盤”としてのオペレーションが求められる。

PureAppはHW、仮想化レイヤーの機能を管理者に意識させない設計になっている。“PureApp基盤”としてのオペレーションが求められる。

リソース・プール

ハイパーバイザー

サーバー

ストレージ

ネットワーク

リソース・プール管理

仮想化管理・・・

・・・

NWSwitch

サーバー SAN Switch

ストレージ

vCenter ISD HMC/VMC

管理サーバー群

・・・

VMware

VMware

可用性や拡張性を考慮してハイパーバイザーを設計、設定

ハイパーバイザー・タイプを意識し、固有の機能を活用

PureApp がリソース・プールを事前設計、導入

設定済みで提供

ハイパーバイザーを意識させない設計

ハイパーバイザーやHWの構成ツール固有の

機能は利用できない

PureApp基盤として管理

従来のシステム

PureApp

前頁とも関連しますが、PureAppではHW、仮想化レイヤーの機能を管理者に意識させない設計になっており、“PureApp”としてのオペレーションが求められます。従来のシステムではお客様自身で可用性や拡張性を考慮して基盤を設計し、ハイパーバイザーを意識してその固有機能を使って可用性、拡張性といった要件を実現していました。PureAppでは企業内クラウド向けに可用性まで考慮してリソース・プールを事前設計、構成してご提供しています。W1500(IAサーバーモデル）でもW1700(Powerモデル）でも提供する機能は同じで、ハイパーバイザーを意識せずともPureApp基盤として管理できます。逆に言うと各ハイパーバイザー・タイプに固

有の機能をユーザーが直接利用することはできませんのでご注意ください。

24


（補足） PureApp基盤が提供する機能

可用性の確保

計算ノード障害時に障害ノードで稼動していた仮想マシンの別ノードへの退避

リバランス

計算ノード間の仮想マシンの移動による計算ノードの負荷を調整する機能

無停止保守

無停止でのPureAppの保守機能のサポート

保守モード

計算ノードの保守時に明示的に設定することで、稼働中の仮想マシンを別ノードに自動退避する機能

PureAppでは運用・保守に必要な機能を実装済み

仮想化レイヤーの機能を直接使わずとも非機能要件を満たすことができる

PureAppでは運用・保守に必要な機能を実装済み

仮想化レイヤーの機能を直接使わずとも非機能要件を満たすことができる


前頁にて仮想化レイヤーの機能を直接利用することはできないことをご説明しましたが、PureAppでは企業内クラウドで求められる非機能要件を考慮し、運用・保守に必要な機能を実装済みでご提供します。ハイパーバイザー固有の機能を使って従来のITシステムでよく実施される運用は製品機能としてすでに組み込まれています。その一例がこのページに記載されている機能です。これらの機能はPureAppが自律的に活用したり、PureAppの管理コンソールから容易に実行可能ためこれ

までのように仮想化レイヤーの機能を直接使わずとも非機能要件を満たすことができます。

25


Windows システムの移行

PureAppでWindowsを使用する場合の考慮点Windowsのライセンスが別途必要

ICCTを使ったデプロイ用イメージの作成が必要

イメージ作成時にPureAppの外にVMware環境が必要

イメージの保守もユーザーの責任

共有サービスはLinuxで稼動する

RHEL への移行も検討するOSライセンス込みで提供される

イメージ、パターンが提供されるメリットを考える

Windows 環境でのIBM MWのHypervisor Edition や仮想アプリケーション・

パターンの提供はない

Windows 環境でのIBM MWのHypervisor Edition や仮想アプリケーション・

パターンの提供はない

パターン・カスタマイズ

Windows 継続 or RHELに移行するか？

メリットvs デメリットと時間、工数のバランスを考慮

Windows 継続 or RHELに移行するか？

メリットvs デメリットと時間、工数のバランスを考慮

PureApp v1.1からW1500（IAサーバー・モデル）にてWindowsをゲストOSとしてサポートしており、RHELとWindowsの両方をデプロイすることができますが、Windowsの場合にはいくつか注意点がありますのでここでご紹介します。

PureApp W1500にはWAS、DB2のほかにOSのライセンスとしてRHELが同梱されていますが、Windows環境を構築したい場合には別途Windowsのライセンスが

必要となります。

また、IBMのミドルウェアやIBMが提供している仮想アプリケーション・パターンはすべてRHELまたはAIXをベースとしており、Windows版の提供はありません。Windows上でIBM MWを利用したい場合には、お客様自身でハイパーバイザー・エディションに相当するイメージを作成したり、仮想アプリケーション・パターンを開発していただく必要があります。また、Windowsをベースとしたイメージの作成には外部のVmware環境が必要となります。

さらに、イメージやパターンを開発しても、PureAppが提供する共有サービス（ELBやシステム・モニターなど）はLinuxで稼動します。共有サービスは基本的にはOSを意識させない設計になっており、ユーザーが直接OSにログインする必要はほとんどありませんが、お客様のアプリケーションがWindowsで稼動しても、それらを支える共有サービスはLinuxで稼動しますので、PureApp上に複数の種類のOSが稼

動することになります。

既存システムがWindowsベースの場合PureApp移行後もWindowsで稼動したいというご要望は多いと思います。ただし、PureAppではRHELを使った場合、OSライセンスが組み込まれていること、イメージやパターンが提供されるメリットがあるので、可能であればRHELへの移行の可能性も検討してください。

26


（補足）Windowsシステムの移行

WAS Hypervisor Edition (HV)とユーザー作成イメージとの違いWAS HVではWASの基本設定作業の自動化の仕組みが組み込まれている

WAS HVではコンポーネントごとにパートが提供される

パートを配置するだけでプロファイルが作成され、ノードが構成される

ICCTでパートの作成も可能だが、WAS HVと同等の設定作業をすべてイメージ内に組み込むのは現実的ではない

WASおよびフィックス導入

ASノードプロファイル作成

ODRプロファイル作成

DMプロファイル作成

動的クラスター作成

過負荷保護の設定

ODRクラスター作成

OSのチューニング

OSおよびフィックス導入

IHSおよびフィックス導入

ASノードのaddnode

ODRノードのaddnode

ICC

T

での作成

範囲

スクリプトまたは手動での対応

WA

SH

V

に組み込み済み

ヘルスポリシーの設定

Webサーバー作成

Elasticityモードの設定

パターン・カスタマイズ

WAS HV利用時ユーザー作成時

Windows システムの移行の際の考慮点は前頁のとおりですが、ここで少しWASを

例に補足します。

WAS HVでは図の黄色の部分（導入イメージの組み込み）だけでなく、紫色の部分（つまり、WASを使う場合に最初に必要な基本設定作業の多く）を自動化する仕組みがHVイメージ内に組み込まれています。

Windowsを利用したい場合、黄色の部分はユーザーが作成するイメージに取り込むケースが多く、イメージの作成にはICCTというツールが提供されるので作業の省

力化は可能ですが、紫色の部分を自動化するにはスクリプトの開発が必要となります。

また、WAS HVではWebサーバー、デプロイメント・マネージャー、オンデマンド・ルーター、カスタム・ノードなどコンポーネント別に「パート」として1つのHVイメージ内に実装されており、パートをパターン内に配置することで簡単にトポロジーを構成することができます。これにより、ユーザーがスクリプトを開発しなくともセルを構成したり、ノードをセルに統合したりする仕組みが自動化されます。

Windows環境の場合、ICCTでパートを作成することも可能ですが、WAS HVと同等の設定の自動化機能をイメージに実装することは現実的ではなく、RHEL環境に

比べて、多くの工数が必要となります。

PureApp V1.1でWindowsに対応したことは、Windowsでしか稼動できないワークロードをPureApp上に載せたり、PureAppの適用範囲のスコープを広げる意味で

非常にメリットがありますが、すでに提供されているイメージやパターンを活用するメリットも十分ご検討ください。

27


システム・デザイン指針

従来は限られたリソースの中での構築が基本、複数のシステムがリソースを共有

ハイパーバイザー・エディションやパターンの標準構成・推奨構成をなるべく採用することでベンダーのベスト・プラクティスを活用できる

シンプルにすることで柔軟性を向上し、スケールアウトや問題判別が容易な構成に

JVM 1JVM 1JVM 2JVM 2

RHEL

WAS

IHS

RHEL

WAS

IHS

DM

RHEL

WAS

IHS

RHEL

IHS

x3 RHEL

WAS

x3 RHEL

DM

x1

JVM 1JVM 1JVM 2JVM 2

JVM 1JVM 1JVM 2JVM 2 JVM 1JVM 1 JVM 2JVM 2

前システムからの移行・設定踏襲ではなく、PureAppにあった既存の設計とは異なるトポ

ロジーも検討しよう！

前システムからの移行・設定踏襲ではなく、PureAppにあった既存の設計とは異なるトポ

ロジーも検討しよう！

「詰込み型」の構成から「シンプル」な構成へ積極的に変更する「詰込み型」の構成から「シンプル」な構成へ積極的に変更する

パターンを利用したシステム・デザイン

既存システムからの移行の場合、極力既存システムの設計やトポロジーを踏襲したいというリクエストはごく自然なご要望です。ただし、PureAppの場合は、トポロジーを変えることも積極的に検討してください。

従来のITシステム構築では限られたリソース、固定的なシステム構成の中で、可用性や信頼性重視でシステム設計が行われてきました。そのトポロジーはハイパーバイザー・エディションや既成パターンのデフォルトのトポロジーとは一致しない場合もあります。ハイパーバイザー・エディションやパターンの標準構成・推奨構成をなるべく採用することでベンダーのベスト・プラクティスを活用できること、シンプルにすることで柔軟性を向上し、スケールアウトや問題判別が容易な構成になることを意識することもPureApp上でシステムを構築する際には重要です。前システムからの移行・設定踏襲ではなく、PureAppにあった既存の設計とは異なるトポロジーも積極的に検討し、PureAppのメリットを最大限に活用できるパターンにそったシステ

ムを構築しましょう。

28


運用設計

最後に運用設計編のHints & Tipsをご紹介します。

29


PureApp環境での監視

PureApp提供の機能と、追加の監視機能を必要に応じて組み合わせ、実装を行うこと

で監視の設計、実装の省力化が可能

PureApp提供機能を活用しつつ、足りない機能を補足するアプローチを検討

PureApp 内蔵の監視機能の活用を積極的に検討しよう！PureApp 内蔵の監視機能の活用を積極的に検討しよう！

仮想マシン上のOS, M/Wの障害・性能監視システム・モニター

共有サービス

H/W、PureAppのイベントを検知PureSystem Manager （PSM）

DB2の性能監視データベース・パフォーマンス・モニター

監視機能ツール

ログ監視LogFile Agent

イベント管理Netcool/OMNIbus （SNMP Probe）

監視機能ツール（Tivoli製品の場合）

運用1

監視については、PureApp内臓の監視機能の活用をまずは検討してください。PureAppにはPureSystem Manager (PSM) とモニター・サービスという共有サービスが実装されており、これらは容易に利用することができます。内臓機能を利用することで、監視の設計、実装の省力化が可能となります。既存の監視システムがある場合でも、PureApp内部についてはPureAppの機能を活用して、既存監視システムと連携させることも可能です。可能な限りPureApp内臓の機能を活用しつつ

足りない機能を外部機能や既存システムと連携して補足するアプローチを検討しましょう。

PureApp内臓機能で何ができるかなどの詳細については、第3部応用実践編PureApplication Systemにおけるパターン開発と運用･管理の「運用１」のセッショ

ン資料を参照してください。

30


既存の監視システムとの連携

確認ポイントPSMと既存の監視サーバー/イベント管理サーバーとの連携が可能か？

SNMP trapでの連携が可能か？

受信側でイベントのフィルタリングなどの処理が必要となる

既存監視システムで利用しているMWのライセンス体系も要確認ライセンス対象は連携先数? 、監視対象数・・・ ?

PureApp 内蔵の監視機能は使わず既存の監視方法をそのまま踏襲する選択肢もありただしハイパーバイザーにエージェントを導入するタイプの製品は利用不可

エージェント型の製品の場合、イメージへの事前組み込みまたはスクリプトでの導入も可

外部監視ツール（ex Netcool）

運用監視オペレーター

外部システム管理ドメイン管理ドメイン

PSM

サービス・ドメインサービス・ドメイン

システム・モニター

DBモニター

仮想マシン PureApp監視機能の活用 vs 既存との連携 vs 既存の踏

襲？

確認ポイントの各項目間のバランスから最適解を検討

PureApp監視機能の活用 vs 既存との連携 vs 既存の踏

襲？

確認ポイントの各項目間のバランスから最適解を検討

運用1

ここでは既存の監視システムや外部の監視/イベント管理サーバーと連携をする際

の確認ポイントをまとめています。

PureAppではすべてのイベントがPSMに集約されます。PSMと外部サーバー間はSNMP Trapで連携させることができます。この際、受信側（外部サーバー側）でイベントのフィルタリングなどの処理が必要となります。

ライセンス面でも確認も重要です。既存監視サーバーと連携したい場合には、現在使用している監視製品のライセンス体系がPureAppとの連携でも適用可能か？の

確認も必要となります。

また、PureAppの機能を使わずに既存の監視方法をそのまま踏襲するという選択

肢もあります。ただし、ハイパーバイザーに直接エージェントを導入するタイプの製品など、一部PureApp環境では利用できないものもありますのでご注意ください。

31


バックアップ – PureApp環境でのバックアップ

PureAppではバックアップの単位や対象が従来とは異なるものがあるPureAppではバックアップの単位や対象が従来とは異なるものがある

PureApp でのバックアップ対象PureApp 本体が管理する情報、データPureApp 上にデプロイされ、稼動するインスタンス

PureApp 本体が管理する情報、データはPureApp外にバックアップを取得内部データベースに格納されているPureApp 本体の構成情報

カタログに保存されるコンテンツ

スクリプトはパッケージのダウンロード機能を使用

パターンはExport機能を使用

お客様作成のスクリプト、パターン類

製品のバックアップ機能または個別にExport仮想イメージ

製品のバックアップ機能を使用PureApp 自身の構成情報

バックアップ方法PureApplication Systemでのバックアップ対象

PureApp 本体が管理する情報・データ

運用3

PureAppではバックアップの単位や対象が従来とは異なるものがあります。運用設計をする際にはPureApp環境特有のバックアップ対象や考慮点を事前に把握しおくことが重要です。

PureAppではPureApp上にデプロイされ稼動するインスタンス上のデータのほかにPureApp本体が

管理する構成情報・データが新たなバックアップ対象になります。

PureApp本体が管理するデータは製品機能でバックアップを取得しPureApp外に補完します。また、

カタログ内に登録されているお客様作成のスクリプトやパターン、カスタマイズしたイメージなどもバックアップ対象となりますので、これらのバックアップ運用を検討する必要があります。

詳細は第3部応用実践編PureApplication Systemにおけるパターン開発と運用･管理の「運用3」のセッション資料を参照してください。

32


バックアップ－インスタンスのバックアップ

Hypervisorが提供するAPIを通じて、データを保護する手法

✓vStorage API for Data Protection

ストレージの持つスナップショットやクローン等の機能と連携する手法

✓ Flash Copy✓ LANフリーバックアップ

バックアップサーバーやメディアサーバーを配置して、データを取得する手法

✓ TSM✓ DB2 Replication

PureApp環境で利用できるのは、「バックアップ・エージェント型」のみ。ストレージのFlash Copy機能やLANフリーバックアップ機能を利用できない。

PureApp環境で利用できるのは、「バックアップ・エージェント型」のみ。ストレージのFlash Copy機能やLANフリーバックアップ機能を利用できない。

バックアップ・エージェント型ストレージ機能連携型仮想機能連携型

PureApp環境での推奨運用

データはTSMや製品機能などを使ってバックアップ/リストアを行う

システムはバックアップからリストアするのではなく、仮想マシンのクローン作成またはパターンの再デプロイから復旧

パターン内でできるだけMWの構成の自動化を行う

PureApp環境での推奨運用

データはTSMや製品機能などを使ってバックアップ/リストアを行う

システムはバックアップからリストアするのではなく、仮想マシンのクローン作成またはパターンの再デプロイから復旧

パターン内でできるだけMWの構成の自動化を行う

インスタンスのバックアップについてもいくつか考慮点があります。バックアップには記載のとおりいくつかの方法がありますが、PureApp環境で利用できるのは仮想マシンのゲストOSにエージェントを導入してバックアップを取得する「バックアップ・エージェント型」のみとなります。ストレージのFlash copy機能やハイパーバイザーのAPIを使ったバックアップの取得は利用できませんのでご注意ください。

PureApp環境で推奨されるインスタンスのバックアップ運用は以下のとおりです。

•データはTSMや製品機能などを使ってバックアップ/リストアを行う

•システムはバックアップからリストアするのではなく、仮想マシンのクローン作成またはパターンの再デプロイから復旧する

•パターン内でできるだけMWの構成の自動化を行う

33


バックアップ－確認ポイント

Reusableなパターンを作ればシステムの復旧もパターンの再デプロイで可能

一部のパートではパターンで構築したシステムの部分復旧が可能

パターン内でインスタンスのカウントが有効なパートは稼働中VMの複製

が可能

パターン内でインスタンスのカウントが有効なパートは稼働中VMの複製

が可能

復旧時の要件によっては、パターンの分割も検討

復旧する範囲を狭めることで影響範囲を最小化

復旧する範囲を狭めることで復旧時間を短縮

DM

AP DB2 (P)

DB2 (B)

4ODR

2

パターン (フル・パターン) 分割 DM

AP DB2 (P)

DB2 (B)

4ODR

2

パターン1 (WAS)

パターン2(DB 正系)

パターン3(DB 副系)

PureApp の機能を活用したリカバリー方法を検討しよう！PureApp の機能を活用したリカバリー方法を検討しよう！

パターンを利用したシステム・デザイン

PureApp環境では、ユーザー・データについては前頁の推奨運用のとおりエー

ジェント型のバックアップ製品やミドルウェア自体が提供する機能を用いてバックアップを取得することが推奨されます。システムについては、バックアップ/リストアでの復旧でなくPureAppの特性をいかしたリカバリー方法も検討をしましょう。

PureAppではパターンをベースにシステムを繰り返し活用することで均一なシステムを迅速にデプロイすることができます。Reusableなパターンを作成することでパターンの再デプロイでシステムを復旧させることができます。また一部の仮想マシンに関しては稼動中の仮想マシンのクローンを作成することも可能です。図の例のように、仮想システム・パターンの定義時にインスタンスのカウントが有効なパートに関しては、稼働中の仮想マシンを複製することができ、パターン単位での再デプロイではなく、仮想マシン単位で再構築が可能です。

なお、パターン単位で復旧する再には、復旧に許容される時間などの要件によってはパターンを分割することも検討が必要です。復旧する範囲を狭めることで影響範囲を最小化したり、復旧時間を短縮することができます。復旧時の要件もパターン設計に影響する場合があることを事前に理解しておきましょう。

34


PureApp 環境での保守

問い合わせはPAテクニカル･サポートで一本化

保守サービスには以下が含まれる管理ノードのソフトウェア障害時の修復作業

管理ノードのバックアップからのリストア作業

管理ノードに対するソフトウェア更新作業

ハードウェアに対するファームウエア更新作業

システム・アップサイズ（モデル変更）作業

電源オフ/オン作業

ハードウェア障害時の修復・交換作業

お客様、サービス・エンジニア側で実施する保守作業仮想マシンに対するソフトウェア更新作業

仮想イメージ、スクリプト、パターンの更新作業

お客様(Web / お電話)

お客様(Web / お電話)

国内サポート窓口SW障害、HW障害の

切り分けを実施し振り分ける

S/WS/W

SW障害 HW障害

H/WH/W

PureApp では保守作業の責任範囲が異なる。プロジェクトやIT部門の体制、

分担作業が異なる。

PureApp では保守作業の責任範囲が異なる。プロジェクトやIT部門の体制、

分担作業が異なる。

運用2

最後にPureAppでの保守についてまとめます。PureAppでは保守作業の責任範囲が従来のITシステムと大きく異なります。お客様の負担が増えることはありませんが、従来と異なり保守サービスにHWの保守などが含まれますので、プラニング・

フェーズとしては、プロジェクトの体制、要員計画が従来と異なるということを意識しておくことが必要となります。

35


§3. まとめ

36


（復習）PureApp の製品コンセプトと特徴

自動化ツールリソース・プール運用管理ツール

プロビジョニング

自動化管理

イメージ管理

パターン管理ハイパーバイザー

サーバー

ストレージ

ネットワーク

リソース・プール管理

仮想化管理

PureSystemsManager

IBM PureApplication System

企業のワークロードに最適化されたオール・イン・ワンの PaaS型クラウド環境

高品質なシステムを少ない時間とコストで構築・運用できるよう事前に設計

PureAppのコンセプトにそった使い方をすることでメリットを享受できる

製品機能を使いこなすことで、エンタープライズ・クラウドや企業システムむけのノウハウを最大限活用できる

（再掲）当チャートは復習チャートです。PureAppの製品コンセプトと特徴を事前に

理解してください。

37


（復習）当セッションでカバーした領域

Systems of Record

CRM HR

DB ERP

Systems of Engagement

Internet of Things


PureAppでのシステム構築

トラディッショナルなITシステム構築とは異なる点が多い

従来の考え方や手法とのギャップが大きい

Systems of Record の次世代のプラットフォームとしてPureAppを考える

クラウド・ベースサービスの基盤としてPureAppを考える

製品コンセプトや機能にあわせる vs既存の運用にあわせることのメリット/デメリットは？

新しいことへの取り組みによる意識改革。クラウドの割り切りも重要

クラウドの実現に必須の標準化、自動化が進まない

（再掲）当チャートは復習チャートです。当セッションでは、既存システムの移行にフォーカスして考慮点をまとめました。

3838


最適化

• 集約、仮想化によるHWリ

ソースの有効活用とコスト削減重視

• 安定化志向のインフラ・サービス

イノベーション

• 柔軟性とアジリティーが求められるSystems of engagement へのフォーカス

• ビジネスの効率化を重視した新たなインフラ・サービスの価値の創出

既存システムの最適化と新しいエンゲージメント・モデルによるイノベーションとのバランス

既存システムの最適化と新しいエンゲージメント・モデルによるイノベーションとのバランス

今、そしてこれからのIT部門に求められるもの

既存のインフラおよびアプリケーション・リソースの再利用と

シンプル化

新しいタイプのアプリケーション、ビッグデータ、アナリティクス、ソーシャル、モバイルなどの新しいリソースの加速化

1章でご紹介したように、これからのITシステムはSystem of Recordsの領域のほかに新たな領域への対応も重要となってきます。IT部門に対して既存システムの最適

化と新しい領域への対応のバランスが求められる時代にうつりつつあります。

PureAppは製品思想としてこの両方の領域をカバーできる製品です。既存システム移行の際にはPureAppは制約と捉えられる部分もあるかと思いますが、既存システムをPureAppに移行しつつ新しいドメインのプラットフォームとして、イノベーションを実現するための土台としてPureApplicationをうまく活用することをぜひご検討くださ

い。

38

39


(まとめ) PureApp と一緒に新しいことを提案・実現しよう！

PaaSとPureAppのメリットを理解し、製品思想、機能を最大限活用する

今までよりも少ない時間とコストで高品質のシステムを構築・運用する

継続デリバリーを実現するプラットフォームを提供する

インフラ作業やその運用を省力化し、ビジネス・アプリケーションの開発に専念できる環境を提供する

クラウド連携、ハイブリッド・クラウドの活用によりインフラの柔軟性を高める

IT組織が抱える課題を解き、次世代のIT組織への変革に活用する

既存手法との調和、連携を重視しつつ、新しいテクノロジーを活用して、よりよいインフラサービスの提供ができないか？を考えよう

既存手法との調和、連携を重視しつつ、新しいテクノロジーを活用して、よりよいインフラサービスの提供ができないか？を考えよう

求められるスキルセットがvertical specialistsからhorizontal generalistsへ

縦割りの組織編成から、より統合されたエンタープライズ単位の体制での最適化モデルに

中央集中型のガバナンスの徹底と分散型のオペレーションの実施による運用効率向上

ITプロセスのシンプル化と変化へのよりダイナ

ミックで迅速な対応が可能に

40


ITを、もっと手早くカンタンに。

既存システム移行時の hints &...

Documents