セッション ID: T1-402 既存業務システムの Windows Azure への移行 マイクロソフト株式会社 コンサルティングサービス統括本部 プリンシパルコンサルタント 赤間 信幸 セッションの目的とゴール Session Objectives and Takeaways セッションの目的 Windows Azure に適したシステムを理解する 既存システムの移行における課題を理解する セッションのゴール システムの分類方法を理解し、クラウド化の適 否をおおまかに判断できるようにする クラウド化に際して、設計の考え方が質的に大 きく変化するポイントを理解する 3 セッションアジェンダ Session Agenda クラウド コンピューティングの波 システムタイプの分類 クラウドの適用領域 クラウドにおける設計の考え方の変化 まとめ (ご注意) 本セッションでは、解説時間の関係上、 ・ .NET アプリケーションのみを対象とします ・ 細かい実装コードについては触れません 4 クラウド コンピューティングの波 IT システムへのプレッシャー クラウド コンピューティングの到来により、 既存 IT システムは見直しを迫られている 自社保有 (オンプレミス) vs クラウド化 コスト削減圧力の強い今日において、クラ ウドの存在を無視することはできない パブリック クラウド 移行 企業 A 自社 保有 5 Microsoft, Google, Amazon, Salesforce, etc. システムタイプの分類 クラウド化に適したシステムの選別 業務システムのクラウド化を考える場合に は、システム特性に応じた使い分けが必要 すべてクラウド、というのは非現実的 システム特性を鑑みて、クラウド化を検討 クラウド化を考える際には、システムを 3 つのタイプに分けて考えるとわかりやすい ① ミッション クリティカル システム 6 ② クラウド ならではの 新システム ③ 従来から 存在する 業務システム システムタイプの分類 ① ミッションクリティカルな業務システム オンプレ MC 系業務システムはクラウドには不向き 主な理由: 性能保証 (特にレイテンシ保証) が難しい 可用性要件が非常に厳しい 自社でのデータ保有・管理の要件があることが多い こうしたシステムは、オンプレミス (プライ ベート クラウド) での構築が適している パブリック クラウド オンプレミス (プライベート クラウド) 7 占有型 共用度 共用型 自由 サービス レベル 画一的 システムタイプの分類 クラウド ② クラウドならではの新しいタイプのシステム クラウドの特性を生かした、全く新しいタ イプの業務システムも登場してきている MapReduce などの大規模分散計算処理 大規模ログ解析、統計分析、学術計算領域など、 伸縮自在性を生かせる領域で強みを発揮 Windows Azure プラットフォーム Worker ロール Web ロール 一時的に 大量のサーバー Worker ロール を利用 SQL Azure など ジョブ投入 並列な タスクに 分解 8 Queue Queue 各ノードの 処理結果を 収集・整理 システムタイプの分類 ③ 従来から存在する典型的な業務システム 簡単な .NET アプリの場合には、ほぼその ままの形を保って Azure 上に乗せられる 例) 2 階層型 Web-DB システムの場合 オンプレミス Windows Server (IIS Web サーバー) SQL Server TCP/IP (TDS) Azure ほぼ そのまま 移行! SQL Azure Windows Azure コンピュートサービス データベース サービス TCP/IP (TDS) 9 システムタイプの分類 ③ 従来から存在する典型的な業務システム Windows Azure プラットフォーム クライアント Web ロール サーバー ASP.NET (AJAX 含む) UI SQL Azure BC DAC BC DAC HTTP/HTTPS UI 制御 C#/VB 動的な 画面処理 UI 制御 JavaScript HTTP/HTTPS SI XMLHTTP Request Silverlight 動的な 画面処理 Web ロール サーバー HTTP/HTTPS SI BC DAC UI 制御 C#/VB WPF, WIndows フォーム Web ロール サーバー HTTP/HTTPS または TCP/IP 動的な 画面処理 UI 制御 C#/VB 10 SI BC ※ TCP/IP 通信を受け付ける 場合には Worker ロール サーバーを利用 DAC システムタイプの分類 ③ 従来から存在する典型的な業務システム しかし、本当にそんなに簡単に移植できる のか? となると、必ずしもそうではない サンプルアプリケーションはともかく、実シス テムとなるとそんなに簡単ではないはず 可用性や性能保証の要件がさほど厳しくな いシステムであったとしても、実システム は、そのままでは移行できないことが多い 現在の Azure には制限事項がそれなりにある このため、ある程度のコード書き換えなどが必 要になることがほとんどである 11 システムタイプの分類 ③ 従来から存在する典型的な業務システム 現在の Azure に見られる典型的な制約事項 としては、以下のようなものがある 必要な修正が大きいと、移行は非現実的になる 海外データセンターのみ 可用性が一律設定 99.9% Dedicate 型 Azure がない お客様監査の受け入れ不可 データベース最大容量 50 GB 日本語リソース ファイルなし リモート デスクトップ接続不 可 Web アプリの構成 特権が必要な処理 サーバー間リモート通信 12 メール送信処理 帳票印刷処理 各種のバッチ処理 国際化対応 Azure 上で使えない機能 ASP 32 bit アプリ 他社製データベース パッケージソフト ローカル リソース アクセス Java, PHP 対応 etc... クラウドの適用領域 昨今の状況 以上より、現在のクラウドの適用可否の境 界は、この③の領域に存在する 多くの業務アプリは... 『クラウドのコストメリットを享受したい』 しかし『クラウド化の一歩を踏み出しにくい』 という状況にある 大規模 ① ミッション クリティカル システム オンプレミス向き 13 (現在の) クラウド適用領域 小規模 ③ 従来から 存在する 業務システム ② クラウド ならではの 新システム クラウド向き クラウドの適用領域 今後の見通し しかし、「何が・どこまでクラウド化でき るか?」は、技術進化と共に変化する クラウド技術はまだまだ発展途上 今後の技術進化により、適用領域は広がる (未来の) クラウド適用領域 技術進化 大規模 ① ミッション クリティカル システム オンプレミス向き 14 小規模 ③ 従来から 存在する 業務システム ② クラウド ならではの 新システム クラウド向き クラウドの適用領域 Windows Azure の今後の見通し Azure に関して言えば、以下の 2 つが登場 してくると、状況がかなり変わってくる ① VM Role IaaS 型に近いクラウド サービスの提供 ② Windows Azure Platform Appliance ワールドワイドで一律のサービス「のみ」→ アプラ イアンスの登場により、様々な Azure が出現 この 2 つが実利用可能になると、Azure の 適用領域が一気に広がる可能性が高い 広範なアプリ・システムが適用領域に入る可能 性が高くなってくる 15 クラウドの適用領域 Windows Azure の今後の見通し 例) Windows Azure Platform Appliance 従来 →「マイクロソフトの Azure」のみ 今後 →「プロバイダーの Azure」「自社内の Azure」なども利用することができるように 物理的な Azure の制御、地理的に近い場所で の Azure 利用、データの保有などが可能に 16 エンド企業 サービス プロバイダー Appliance Appliance Microsoft Azure ※ 現時点では限定されたパートナー様とのみパイロット実施 クラウドの適用領域 今、何をすべきか? こうした見通しの中で、今のうちにやるべ きことは、「とりあえず使ってみる」こと クラウドは進展が早い → 数年後は全く違う状 況になっている可能性が高い 特に Azure に関しては、適用領域が大幅に広 がっている可能性もある もう少し待ってから.... と言っていると、いつ の間にか波に乗り遅れる可能性が高い いきなり実システムに適用するのではなく、 評価・検証 PJ を開始するのがよい 机上検証を繰り返すより、使ってみた方が早い 17 クラウド化で何が変わる? 評価・検証を行っていく際の視点 クラウドへの移行では、ものの見方や考え 方を変えなければならないところがある 実装作業にかかわる細かい課題 → 頑張るだけ 設計やアーキテクチャ → 考え方の理解が必要 設計やアーキテクチャの 考え方にかかわる課題 重要! ・ ・ ・ ・ 18 ストレージの選択 オンプレ/クラウド連携 運用監視 次ページ以降で ポイント解説 etc … 実装などの細かい作業に かかわる課題 ・ ・ ・ ・ 国際化対応 各種の特権処理見直し デバッグ容易性 etc … クラウド化で何が変わる? 評価・検証を行っていく際の視点 従来のシステム設計と比べて、大きく考え 方を変えなければならないポイントは 3 つ 1. データストレージ選択の考え方 2. オンプレミス/クラウド連携の考え方 3. 運用監視の考え方 これらは、技術的制約が緩和されてきても 残る大きな問題である クラウドならではの考え方に慣れることが重要 これらについて解説する 19 クラウドならではの考え方 1. データストレージ選択の考え方 クラウド コンピューティングへの移行で、 最も厄介なのがデータベースの移行である RDBMS の基本思想は「一事実一ヶ所」 オンプレミスの DB はスケール アップが基本 これらの思想は、クラウドと真っ向から反する オンプレミス型 アーキテクチャ スケール アップ 巨大なサーバーで 一括処理するモデル 20 クラウド型 アーキテクチャ スケール アウト 小さなサーバーで 分散処理するモデル クラウドならではの考え方 1. データストレージ選択の考え方 考え方のポイント: クラウド環境では、機 能か容量のどちらかが犠牲になる クラウド環境 → 安価なハードで分散処理 この結果、機能か容量のどちらかが犠牲になる Azure に 2 種類のストレージがあるのはこの ◎ 機能 ため SQL Server (オンプレミス) 機能を優先 容量を犠牲 ◎ × ◎ 21 機能 容量 価格 SQL Azure データベース サービス ◎ × 容量 価格 容量を優先 機能を犠牲 Windows Azure × ストレージ ◎ サービス ◎ 機能 容量 価格 クラウドならではの考え方 1. データストレージ選択の考え方 参考: 具体的な比較表 SQL Server (オンプレミス) SQL Azure データベース サービス Windows Azure ストレージ サービス 22 コスト 機能性 容量 × ○ ○ 相対的に高価 高機能 ACID 制御 ～16 TB/DB ○ ○ × 比較的安価 ($9.99/GB) 高機能 ACID 制御 ○ × 総じて 言えば… 高いけど なんでも できる 容量を犠牲に して機能と ～50 GB/DB 価格を優先 ○ さらに安価 相対的に低機能 ～100 TB ($0.15/GB) BASE 制御 機能を犠牲に して容量と 価格を優先 クラウドならではの考え方 1. データストレージ選択の考え方 このため Azure 環境では、2 つのストレー ジをうまく使い分ける必要がある JOIN などを要する業務データ → SQL Azure 蓄積に主眼を置くような巨大なデータ → Windows Azure ストレージサービス Windows Azure コンピュート サービス TCP/IP (TDS) HTTP REST 23 業務 SQL Azure データ データベース サービス 巨大な Windows Azureデータ ストレージ サービス クラウドならではの考え方 1. データストレージ選択の考え方 注意! データベースの水平分散について 中～大規模の業務システムでは、SQL Azure の容量制限にひっかかることがある このような場合には、DB の水平分割が必要 大がかりな設計変更が必要なので注意すること SQL Azure ユーザー ID ごとに 分割してデータを 各 DB に保持 (水平分散保持) ユーザー ID ユーザー ID ユーザー ID 00,001 ～ 10,000 10,001 ～ 20,000 20,001 ～ 30,000 ユーザー ID に よって接続先の DB を変更 24 通常は以下のような キーで DB 水平分割 ユーザー ID ユーザー ID ユーザー ID 店舗 ID、地域 ID、 30,001 ～ 40,000 40,001 ～ 50,000 50,001 ～ 60,000 ユーザー ID、顧客 ID、 注文日時、etc … (処理が重ならない ユーザー ID ユーザー ID ユーザー ID ようなキーで分割) 60,001 ～ 70,000 70,001 ～ 80,000 80,001 ～ 90,000 クラウドならではの考え方 2. オンプレミス/クラウド連携の考え方 また、多くの業務シス テムでは、オンプレミ スとクラウドの連携が 必要になる すべての業務システム や DB をクラウド化で きないことの方が多い ケースバイケースでの 検討が必要だが、考え 方の枠組みを知ってお くことが重要 25 インターネット ユーザー 認証 連携 データ連携 (バックアップや データ同期など) システム間連携 (オンライン/オフライン) オンプレミス Active Directory 統合監視 オペレーター イントラネット ユーザー クラウドならではの考え方 2. オンプレミス/クラウド連携の考え方 考え方のポイント: 連携させるべきものは 主に以下の 4 つである 26 データ連携 オンプレミスと Azure 間で マスター データなどを同期 させる ・TDS 接続 ・SSIS によるデータ コピー ・Data Sync によるデータ同期 処理連携 オンラインまたはオフライ ンで処理を連携させる オンプレの DB にアクセス ・AppFabric サービス バスを 活用したシステム間連携 認証連携 すでに使われているユーザー ・ADFS、WIF を利用したフェ ID、パスワードを使って、 デレーション認証 Azure のシステムを使う ・Windows Live ID の利用 運用連携 イントラネットのシステム と Azure 上のシステムとを 一気通貫で運用監視する ・ (現時点ではほとんど機能 なし) ・ (一部は作り込みが必要) クラウドならではの考え方 2. オンプレミス/クラウド連携の考え方 連携に関するキー テクノロジとして、以下 の 2 つを知っておくことが望ましい ① AppFabric サービス バス (処理連携) クラウド → オンプレミスへの呼び出しを可能とす る技術 ② フェデレーション認証 (認証連携) オンプレミスの AD アカウントで、クラウド上のシ ステムにログインできるようにする技術 これらについて解説する 27 クラウドならではの考え方 2. オンプレミス/クラウド連携の考え方 ① AppFabric サービス バスとは... オンプレミスから AppFabric サービス バスに 向かって接続 クラウドからの要求を受信できるようになる オンプレミス側の FW の受信ポート解放不要 オンプレミス ユーザー アプリ データベース サーバーなど 呼び出し 物理的な接続方向 論理的な接続方向 28 AppFabric サービス バス クラウドならではの考え方 2. オンプレミス/クラウド連携の考え方 ② フェデレーション認証とは... AD 環境下のイントラネットでは、Windows 統合認証によるログインを行うことが多い ADFS を使うと、Azure 上のシステムに AD ア カウントでログインできるようになる イントラネットシステムの段階的移行に便利 オンプレミス Web サーバー SSO パスワード 入力なし! 29 Active Directory ADFS サーバー ADFS クッキー WIF (Windows Identity Foundation) のモジュールを 組み込んだアプリケーション ADFS クッキーで アクセスする パスワード 入力なし! SSO クラウドならではの考え方 2. オンプレミス/クラウド連携の考え方 こうしたシステム間連携については、以下 のようなポイントが課題になりやすい これらは、机上検証だけでは不確実になりやす い → プロトタイプによる実機評価を推奨 実現方式 30 ・どんな技術を活用して実現するか? ・現状では、WIF/ADFS, AppFabric の 2 つが基本 ・不足部分については作り込みが必要なことも ネットワーク 速度 ・特にオンライン連携処理やデータバックアップなどは ネットワーク速度が問題になりやすい ・机上検証が特に困難な領域なので、実機評価が必要 課金 ・大量データを頻繁にやり取りすると、課金が膨らむ ・データをキャッシュさせたり、差分データだけを転送 させたりするといった、アプリ的な工夫も必要 クラウドならではの考え方 3. 運用監視の考え方 Azure 環境にアプリを移行すると、オンプ レミスのような運用監視はできなくなる クラウド環境のアプリの監視＝リモート監視 必然的に、オンプレミスとは運用監視の勝手が 異なることになる オンプレミス 運用監視 31 パブリック クラウド クラウドならではの考え方 3. 運用監視の考え方 特に従来と大きく異なるのは、Azure が PaaS 型のサービスであるという点である PaaS の基本思想 ＝ ミドルとインフラはブ ラックボックス = 気にせずに済むようになる オンプレミスの場合は中 身がよく見えていたので 不安はなかったが... 障害時は実際どうなる? パッチ適用は? 32 PaaS アプリ部分を 開発・運用・監視 アプリ ミドル ブラック ボックス インフラ 運用監視 これは、従来とかなり勝 手が違う クラウドならではの考え方 3. 運用監視の考え方 考え方のポイント: SLA 境界線より下を分 解する必要があるケースは何か? を考える まずはアプリの運用監視をメインに考える アプリの性能監視/障害監視/運用を中心に考える アプリ ミドル ブラック ボックス インフラ 33 運用監視 その上で、ミドルやインフラを解体しなければ ならないケースとして何があるか? を考える ここをメインに運用監視 PaaS SLA ミドルやインフラを解体 しなければならないケー スにはどんなものが? クラウドならではの考え方 3. 運用監視の考え方 クラウドならではのものもある が、ほとんどはオンプレミス同様 アプリの運用監視とは... 定常的なタスクとして以下のようなものがある 34 アプリの 性能監視 アプリケーションが異常な スロー ダウンを起こしてい ないかを監視 ・パフォーマンス ログを利用 した性能監視 ・開発時はトレースも活用 アプリの 障害検知 アプリケーションやシステ ムが障害を起こした場合に 速やかに検知 ・イベント ログへのログ出力 ・サービス インスタンスのヘ ルスチェック アプリの ver up アプリの機能修正や追加の 際に、スムーズにアプリを バージョンアップ ・アプリケーションのビルド とデプロイ プロセスの確立 ・VIP Swap による差し替え アプリの 運用 アプリケーションの設定管 理やオペミス対策用の DB バックアップなどの実施 ・DB のバックアップ ・プラットフォーム更新時の アプリのデグレチェック クラウドならではの考え方 3. 運用監視の考え方 インフラ/ミドルの解体が必要となるのは... 障害や性能劣化の原因追究の際に、インフラ/ ミドルの分解が必要になるケースがある 例) 金融系システム → 障害の原因報告が必要 例) アプリの性能劣化 → 原因の追究が必要 インフラ/ミドルが原因であると推測された場合には、 その内部を分解しなければならないことがある インフラ/ミドル内部の問題の原因追究は、 ユーザーサイドで自由に行えるものではない このため、PaaS ベンダー (マイクロソフト) に 問い合わせる際に必要なデータを収集しておく 35 クラウドならではの考え方 3. 運用監視の考え方 インフラ/ミドルについて、収集したり、 ウォッチしたりするとよいデータとしては... ロール インスタンスの状態 Service Management API でチェック ロール インスタンスの再起動の発生 現在の Azure では、インスタンス障害 を通知するメカニズムがないため Dr. Watson ID アプリケーション障害時の例外ログ SQL Azure アクティビティ ID etc... 36 運用サイト 障害は適宜 マイクロ ソフトに 問い合わせ クラウドならではの考え方 3. 運用監視の考え方 重要なポイント (繰り返し) 最初からミドルやインフラを分解して考えない に無視することは難しい が、可能な限り、任せら れるところは任せるよう にするのが PaaS のコツ 37 アプリ ミドル ブラック ボックス インフラ 運用監視 PaaS のメリット＝ミドルやインフラの保有や運用 から解放されること ミドルやインフラを必要以上に気にすることは、 PaaS ならではのメリットを失うことにつながる ミドルやインフラを完全 PaaS まとめ Summary 技術進化により、Azure の適用可能領域は 確実に広がりつつある オンプレ/クラウドの棲み分けは今後も必要だ が、Azure 適用範囲は確実に広がりつつある 今すぐ Azure を使わない場合でも、少しずつ 検証作業を進めておくことを推奨 Azure への移行に際しては、クラウド PaaS ならではの考え方に慣れることが重要 1. ストレージの選択 2. オンプレミス/クラウドの連携 3. 運用監視 38 関連セッション T1-302: クラウド時代のデータベース、ベスト プラクティス～企業 情報システムをクラウドへ移せ～ T1-307: Windows Azure を利用したスケーラブルなアプリケー ション構築 T1-308: クラウド開発の高速道路～ Visual Studio 2010 による Windows Azure アプリケーション開発 T1-401: クラウド時代の SOA のあり方と Windows Azure への展 開 T1-502: クラウド コンピューティングの最先端技術動向と選択の戦 略 39 リファレンス クラウドならマイクロソフト http://www.microsoft.com/japan/business/cloud/default.mspx マイクロソフトのクラウド OS http://www.microsoft.com/japan/windowsazure とあるコンサルタントのつぶやき http://blogs. msdn.com/b/nakama/ Azure の鼓動: ITmedia オルタナティブ・ブログ http://blogs. itmedia.co.jp/isago/ Windows Azure Platform 勉強会キット http://www.microsoft.com/japan/powerpro/study/ 40 Announcing... コンサルティングサービス Azure 実装ガイド提供！ マイクロソフトコンサルティングサービス による Azure 実装ガイドを提供予定！ コンサルティングサービスの Azure 実装編 Workshop の資料をダウンロードで提供 具体的な提供方法については後日告知予定 41 ご清聴ありがとうございました。 T1-402 アンケートにご協力ください。
© Copyright 2024 ExpyDoc
