Muranaga's Golf

46歳でゴルフを始めて10数年。シニアゴルファーが上達をめざして苦労する日々をつづります

To the Cloud: Cloud Powering an Enterprise サマリー

"To the Cloud: Cloud Powering ane Enterprise" は、企業 IT のクラウド化について、Microsoft が自社での事例を踏まえて、エグゼクティブ向けに解説・啓蒙する本である。100ページほどの薄さで各章の最後にサマリーがついているので、短時間でブラウズすることができる。クラウドは何か、どういう価値提供があるかに始まり、クラウドによる効果をどう考え、どのように企業 IT として採用していくべきか、実際にはどう運営していくか、その成功指標をどう考えるかなど、経営者が知るべきレベルの情報がコンパクトにまとめられている。

To the Cloud: Cloud Powering an Enterprise

To the Cloud: Cloud Powering an Enterprise

企業 IT をクラウド化するプロセスが、次の 4つのステップにわたって整理されている。

  1. Explore 探検する
  2. Envision 予測する
    • クラウドによる変化の事例を認識する
    • ビジョンを共有する
    • クラウドによる機会を分析する
    • ビジネスの事例を作る
  3. Enable 可能にする
    • クラウドを採用するアプローチを定義する
    • クラウド・プロバイダを選定する
    • 組織をアップグレードする
    • ツールとプロセスを刷新する
  4. Execute 実行する

これらのステップについて各章で説明されており、以下は章末のサマリーを取り急ぎ訳出したものである。実際には本の内容、特に例や表をよく読むべきだが、その際の手がかりになることを期待して…。見直していないので誤りも含まれているかもしれないが、随時修正していく。

1. Explore 探検する

クラウドを理解する

  • NIST によるクラウド・コンピューティングの5つの特徴:
    1. オンデマンド・セルフサービス:人の介入なしにストレージや処理能力を必要に応じて提供する。
    2. 幅広いネットワークアクセス:携帯電話、PC、その他の機器がウェブ・ブラウザやアプリケーションなどのクライアントソフトを使って、サービスにアクセスする。
    3. 計算機リソースのプール:計算機資源・データストレージがプールされて共有される(マルチ・テナンシー)
    4. 素早い柔軟性(elasticity):サービスが使えるストレージ、ネットワークバンド幅、計算能力がほとんどすぐに増減でき、ソリューションが最適の資源利用にスケールされる。
    5. 計測されるサービス:トランザクションや資源利用が計測され、その利用が監視・制御・報告される。
  • 3つのサービス・デリバリ・モデル:
    1. IaaS(Infrastructure as a Service):仮想マシン(VM)上でアプリケーションを動かす。IT 部門は OS、データベース、アプリケーションを管理する。(例)Amazon Web Services
    2. PaaS(Platform as a Service):IaaS の柔軟性は失うが、IT 部門はOS やミドルウェアの管理から自由になる。(例)Windows Azure
    3. SaaS(Softwareas a Service):予めパッケージ化されたアプリケーションをサブスクリプションで提供する。(例)Salesforce.com、Microsoft Office 365
  • 新たに現れた 2つのカテゴリ:
    1. DaaS(Data as a Service):生データへのアクセスを提供する。
    2. BPaaS(Business Process as a Service):ビジネスプロセスの一部またはすべてを提供する。一つのアプリケーションではなく、複数のベンダからのサービスを組み合わせる。
  • 4つのクラウド・コンピューティング環境のモデル:
    1. プライベート・クラウド:一つの組織のためのサービス
    2. コミュニティ・クラウド:共通の要件を持つ複数の組織のためのサービス
    3. パブリック・クラウド:大量・地球規模のスケールでサービスを提供することによりコストセーブする汎用・公共のサービス
    4. ハイブリッド・クラウド:データやアプリケーションの移行性のために、二つ以上のクラウドを結びつけるクラウド
  • クラウドの構成要素:
    • クラウド・ファブリック:資源を提供、負荷のバランス、サーバの管理
    • 計算パワー:需要に合わせてスケールできる仮想マシンから構成
    • データ・ストレージ:表形式、BLOB(binary large object)、SQLデータベース
    • ネットワーキング

企業への価値提供を理解する

  • 大量購入による供給側のコスト節約
  • マルチテナンシーによる規模の経済効果
  • 需要側の利益:資源ニーズ・市場に出すまでの時間・設備投資の削減、可用性・スケーラビリティ・開発効率の向上

クラウドのある風景を描く

  • まず複数のクラウドを試して、proofs-of-concept を開発・実験して、どれが適しているか決めることができる。
  • 将来の移行計画を考えておくことは重要。

2. Envision 予測する

現状からクラウド化された将来までの道を明確にする必要がある。

クラウドによる変化の事例を認識する

  • リアルタイムで扱うデータが中心になったり、従業員がより外で働くようになったり、持続可能性が重要であったり、自分で IT をセッティングしたりするのであれば、クラウド・コンピューティングの利益を享受できるだろう。
  • 複雑性、旧式化するシステム、財務的な制約、運営上のプレッシャーなどを深く理解することは、クラウドがどのように役に立ち、またどんな能力何が必要なのかを特定する助けになるだろう。

ビジョンを共有する

  • クラウドに向けての構想を共有するには、エグゼクティブの後押し、関係者の支援、組織的な取組みが必要である。資金、投資の優先順位、リスクなどの課題に取り組む必要がある。
  • クラウド化を既存の IT イニシアティブの推進に使える:共有サービスへの投資、グローバル基盤の統合、アプリケーションのポートフォリオの簡潔化、ユーザ経験の改善、隠れた IT の明確化

クラウドによる機会を分析する

  • 企業アプリケーションの棚卸をして、ビジネスへの影響、アーキテクチャ、データ属性、利用パターンを理解せよ。
  • 需要パターンを分析するなどして、どのアプリケーションがクラウドに向いているか決める必要がある。ビジネスと技術の観点から、どれからクラウド化していくか優先度をつけよ。

ビジネスの事例を作る

  • ビジネスの事例では、アプリケーション開発・人員・ハードウェア・ネットワークのバンド幅などの点で、投資・コスト削減・売り上げの影響などを定量化すべきである。

3. Enable 可能にする

クラウドのベネフィットが理解された後は、どのように前に進めるかが次のステップになる。

クラウドを採用するアプローチを定義する

  • クラウド採用は、徐々に、もっとアグレッシブに、あるいはその中間のバランスのとれたアプローチのどれをとってもよい。それは求められるスピード、労働力が集中しているか分散しているか、社内で移行を実行するかベンダーを使うか、マネジメントからトップダウンでやるかボトムアップでやるか、などによる。
  • パイロットシステムのクラウドへの移行により、技術知識の不足、予測された便益が達成されるかのテスト、コスト節約のデータなどがわかる。
  • 適度な複雑さを持つ小規模・中規模の需要のあるアプリケーションから、クラウド化を始めよ。クラウドでアプリケーションを動かすコストを理解するまでやる。

クラウド・プロバイダを選定する

  • 以下をベースにクラウド・プロバイダを選定せよ:提供されるサービス、何年ビジネスをしているか、ビジネスプロセスの成熟度、契約と SLA の徹底具合、疑問に対してどのくらい明確に完全に答えてくれるか。
  • ニーズに応えられる技術(現状・将来)を持つ「真のクラウド・プロバイダ」を選定せよ。そのプロバイダの価格モデルに基づいて、クラウド化するアプリケーションがどのくらいのコストで動くのか注意深く分析せよ。セキュリティについて技術的・法的にプロバイダがどううまく処理するのか理解せよ。自社と同じくらいの大きさの会社の要件に対して、サービスが機能しているか確認せよ。

組織をアップグレードする

  • 適切な投資をすれば、多くの企業は2年で組織のすべてをトレーニングすることができる。技術者のトレーニングに時間とリソースの約70%を費やすこと。マネジメント層のトレーニングに20%、ビジネスの関係者のトレーニングに10%。
  • クラウド・ガバナンスは資源投入・予算・プロジェクトの優位性のポリシーを決めるために重要である。ステアリング委員会とワークグループを組み合わせて、ガバナンスプロセスを管理することができる。
  • CIO は人事、IT、その他のビジネスグループのマネジャーと一緒に、クラウドを採用することで、組織が変わることをわからせる必要がある。たとえばクラウドにより人員削減ができたり、役割分担が変化したりする。

ツールとプロセスを刷新する

4. Execute 実行する

これまでの IT はレガシーとなるハード・ソフトが混在する環境で、システム構成に一貫性もなければ、サードパーティとの長期契約に縛られてベンダーを変えることも難しく、個々のアプリケーションを維持するだけで、事業ニーズに合わせて新しい方法を取り入れることはできなかった。これらの問題を解決するために、クラウド・サービスを利用することは、ソリューションのアーキテクチャ、設計、実装、運用を今までとは違うやり方で考える必要がある。

企業アーキテクチャを再考する

  • クラウドでは、IT システム全体にフォーカスして、情報・サービス・プロセス要件がどこで収束して、効率・コスト節約・スピードを生み出すのかを見極める必要がある。
  • 多くの企業は、最初はデータをオン・プレミスに置くなど、クラウドとのハイブリッド・アーキテクチャを採用するだろう。ハイブリッド・アーキテクチャでは、パブリックなインターネットとつなぐ際の遅延やセキュリティに注意する必要がある。

クラウド用にソリューションを設計する

  • セキュリティ:クラウド・アプリケーションは企業ファイアウォールの外にあるため、攻撃の対象になり易い。ポリシー、標準、アーキテクチャ、開発、運用、インシデントへの対応(incident response)を徹底的に再考する必要がある。
  • スケーリング:オン・デマンドでスケーリングするためには、アプリケーション・ロジックは、レガシーシステムと違って、モジュール性を持ち、緩やかに結合している必要がある。
  • アプリケーションの安定性(resiliency):不要な依存関係を削除する、再トライのロジックを追加する、永続的なキャッシュを利用する、クラウド・プロバイダの "availability zones" にまたがって単一アプリケーションのスケール・ユニットを運用する、など。
  • 並列性:要求、処理、データの格納、ビジネスロジックの実行などで並列性をうまく使うことで性能と可用性を高められる。
  • 遅延:キャッシュを使う、コンポーネント間のインタラクションや負荷を減らす、地球規模でコンテンツを分散・複製させるなどにより、遅延を短縮する。

ソリューションを実装して統合する

  • ツール:クラウド・プロバイダによっては、クラウドでの計算・スケーリング・ストレージなどを、ローカル環境でシミュレートするツールを準備しているところもある。しかし技術者はアプリケーションをクラウド上ですべてテスト・検証し、ソリューションが期待通りに動作することを確認すること。
  • ID管理:クラウド・プロバイダによっては、認証(authentication)、認可(authorization)を提供するところもあれば、IDプロバイダが必要な場合もある。
  • 場所を超えた統合:オン・プレミスのサービスとクラウド環境にあるサービスを接続するには、IP 接続層を用いるか、クラウド・プロバイダが提供するメッセージングなどのミドルウェアを活用する。
  • テスト:擬似的に障害を起こす、コストを測定する、スケールアウトさせる、ユーザ・アクセスをシミュレートする、ネット遅延のような外部環境要因からアプリケーションの性能を独立させる、など。

クラウドを運用する

  • 大規模な移行を行う前に、企業とクラウド・プロバイダの役割と責任分担をマップする管理マトリックスを作るべし。
  • サーバやwebホストの状況よりもむしろ、利用者がタスクを実行できているかどうかをベースに監視を行うべきである。
  • 性能を定量化するべく定常的に測定をし、意味のある傾向が現れているか見つけること。