クラウドプログラムは、次の10年間で企業が直面するであろう最も重要なテクノロジーシフトの1つです。ここで紹介する10のベストプラクティスを取り入れて成功を実現しましょう。

クラウドへの移行はメリットをもたらしますが、組織においては慎重に移行を進めることがきわめて重要です。あなたの会社が1つのワークロード、複数のワークロード、またはポートフォリオ全体のどれに目を向けていたとしても、オンプレミスからクラウドベースのITへと移行する場合、テクノロジーを理解するだけでは不十分です。1つ間違いを犯すと膨大なコストと時間が必要になることもあるため、クラウドの導入を成功させるには、焦点を絞り込んで詳細なブループリントを描かなければなりませんが、規範的なアプローチに従ってクラウドプログラムを実施すれば移行が容易になり、価値を実現するまでの時間が短縮されるうえ、リスクも軽減されます。

この記事では、数百の企業でクラウドプログラムの計画の策定、設計、および構築をサポートしてきた経験に基づく重要なポイントを紹介していきます。クラウドへの移行がまだかなり先のことであったとしても、組織に適用できる何かが見つかるはずです。

 

No. 1 - 予防接種からクラウドプログラムを開始する

組織内の全員がクラウドプログラムを支持してくれるわけではないのは当然です。実際のところ、私たちが協力している企業のほぼすべてにプログラムの推進を阻む人や反対意見を述べる人がおり、シンポジウムでも講演を行ったある同僚は、こうした人のことを「ウイルス」と呼んでいました。この印象的な表現は実に的を射ており、ウイルスはクラウドプロジェクトを駄目にしてしまうため、ウイルスを見つけ出して無力化しなければ、成功の可能性は低くなります。

では、何が解決策になるのでしょうか。ほとんどの病気と同様、重要となるのは早期介入で、私たちは、早い段階で主要関係者を (同じ部屋に) 集めればウイルスに対する組織の免疫ができ、プログラムの推進を阻む人が排除されることに気付きました。Cloud Technology Partners (CTP) では、クラウド導入プログラム (CAP) の最初のステップとして、エグゼクティブを対象とした集中的なトレーニングを行う、3日間の体系的なワークショップを実施していますが、このワークショップの中で、参加者の気持ちは否定、怒り、諦め、受け入れと目まぐるしく変化します。あなたの会社のスタッフは、自分の仕事の将来が心配になり、恐怖、不安、疑念 (FUD) でいっぱいになりますが、こうした問題に正面から取り組み、FUDを解消するのがクラウドリーダーの役目です。

CAPワークショップの構成はシンプルで、丸3日間にわたってすべての意思決定者、影響者、および関係者を同じ部屋に集めます。そのための準備に相当な時間がかかることは承知していますが、クラウドへの移行はかなり大きな投資となるため、事前に小規模な投資を行って、将来のより大規模なコストのかかるミスを回避することは、企業にとって大きな意味があります。CTPが実施する大部分のCAPワークショップには、どの日も25～30人が参加し、トピックによって参加者の出入りがあります。このワークショップに必ず参加してもらう必要がある役割は、以下のとおりです。

• エグゼクティブスポンサー - 以下に示すグループ、または (可能な限り) CTO、CIO、CEOなどの経営幹部レベルに参加してもらいます。
• アプリケーションオーナー - 事業部門、開発チーム
• セキュリティ - CISO、SecOps担当者
• GRC - ガバナンス、リスク、およびコンプライアンスのエキスパート
• 財務 - 調達、リスク、およびガバナンスのエキスパート
• リードアーキテクト - クラウドおよび既存のインフラストラクチャを担当するリーダー
• データベース - リードDBA、データアーキテクト
• 中央のIT運用 - リーダー、主要部門の責任者、ネットワーキングスペシャリスト

 

もちろん、CAPワークショップのすべて、または一部に全員を参加させるのは容易ではありませんが、クラウドプログラムを成功させるには、これらすべての関係者の関与が必要です。大規模なITイニシアチブ、特にクラウドの導入と同じくらい重要なイニシアチブにおいては、調整が最も重要な最初のステップとなります。

クラウドにとって最も手強い障害となる 組織の人員をナビゲート

 

No. 2 - 「クラウドファースト」で取り組みを進める

クラウドファーストで取り組みを進めるには、「なぜパブリッククラウドの移行するのか」という質問を投げかけることが最も重要となります。その答えはシンプルですが、こうした効果的な質問は多くのお客様にとってわかりにくいものであるため、CTPでは、CAPワークショップの大部分をクラウド導入のメリットに関する議論や討論に費やしています。クラウドに移行する理由がわからなければ、クラウドファースト戦略はもろくも崩壊し、チームメンバーは、自身の行動が他のメンバーにどのような影響を与えているのかを考えないまま、相反する別の方向へと進んで行ってしまいます。

クラウドにワークロードを置くのは容易ですが、そうした取り組みは見過ごされがちです。

クラウドファーストとは、オンプレミスで維持しなければならないよほどの理由がない限り、すべてのアプリケーションとデータをクラウドに移行することを意味しますが、クラウドファースト戦略を策定しなければ、アプリケーションおよびデータチームに二塁への盗塁を指示しながら、それらのチームを一塁にとどめ続けることになります。そしてこのような状態になると、クラウドを最大限に活用するのに必要な変革に重点が置かれず、ひいき目に見てもそれほどの成果は得られません。

クラウドファーストは一見、攻撃的な姿勢のように思われますが、クラウドファースト戦略を策定しなければ、大きな違いを生み出すのに必要な組織変革を確実に進めるための適切なリソースを投入できないため、CAPワークショップに参加する必要があるすべての人員について、よく考えなければなりません。クラウドの導入は、組織のほぼすべての側面に影響を与えるため、テクノロジーに関する意思決定とは違った、より戦略的な方向性を示すリーダーシップイニシアチブと言えます。

またクラウドファーストにおいては、クラウドプログラムの資金が適切に提供されるよう、専任のチームを割り当てて意思決定を行う必要があります。これはつまり、チームメンバーがクラウド関連のアクティビティに専念し、概念実証やパイロット運用による簡単な検証だけでなく、クラウドへの企業環境の確実な移行に全力を注ぐことを意味します。なお、クラウドチームのメンバーが別に本業を持っている場合、以下のような特徴が見られます。

• クラウドに専念していない。
• 必要な作業が正しく理解されていない。
• エグゼクティブからの支援を得られていない。

(好例であるCapital Oneをはじめとする多くの組織のように) 組織がクラウドとクラウドファースト戦略のメリットを正しく理解すれば、スポンサーは、非常に説得力があり、どのようなCEOからも無視されないような提案を行うことができます。

 

No. 3 - Cloud Business Officeを置く

クラウドの導入は企業に多大な影響を与え、数十年にわたって真剣に取り組んでこなかったプロセスを進化させます。クラウドを導入すると、開発者は初めてソフトウェアを使用して必要なインフラストラクチャを構築したり、変更したりできるようになりますが、こうしたメリットは、素晴らしい結果と恐ろしい結果の両方をもたらします。

ソフトウェアの開発は、ビジネスにもたらされる影響の重大な特質を考慮して、厳格な制御プロセスと長期間にわたる承認サイクルが設けられた、静的な変更管理プロセスの中で行われてきたため、Cloud Business Office (CBO) が必要です。

企業の内外のクラウドプログラムに関する意思決定とコミュニケーションで中心的な役割を果たすCBOは、「クラウドのCenter of Excellence」の枠を超えた、最初の実装から継続的な運用に至るまでの、クラウドプログラムのあらゆる側面の管理と指導を行う恒久的な運用/管理組織です。

CBOのメンバーは、常勤と非常勤の2つのカテゴリに分類され、常勤のCBOメンバーは、リーダーとして、常に組織におけるクラウドの確実な導入、実装、管理に責任を負います。常勤のCBOメンバーは、以下のとおりです。

• クラウドプログラムリーダー
• 技術運用リーダー
• チーフアーキテクト
• セキュリティ運用リーダー

一方、リーダーとしてクラウドプログラムの成功に大きく関わり、プロセスを監視する必要がある非常勤のCBOメンバーは、以下のとおりです。

• 法務およびリスクリーダー
• HRリーダー
• 調達
• IT財務
• アプリケーションオーナーと事業部門 (事業部門に関しては、オンボーディングプロセスで短期間常勤メンバーの役割を果たす場合がある)

 

クラウドは、ITの使用および運用方法を完全に変えました。アジャイルな性質を持つクラウドテクノロジーは、企業に大きなメリットをもたらすとともに、組織内のほぼすべての部門に影響を与えるうえ、クラウドでは、管理と運用に必要な人員がオンプレミスの環境よりはるかに少なくて済むため、より緊密に連携するチームを編成してサイロを解消する必要があります。また、運用、開発、インフラストラクチャ、リスク、および財務を集約することになるため、以下を含む一元的なプロセスを確立しなければなりません。

• プロジェクト管理
• 技術に関する意思決定
• アプリケーションオーナーのオンボーディング
• 技術トレーニング
• リスクとセキュリティに関する意思決定
• 組織的な変更管理とトレーニング
• 財務管理
• オペレーショナルサービスおよびガバナンス
• ベンダー管理

 

No. 4 - クラウドの経済性を理解する

クラウド導入の経済性を理解することは、考えるまでもないベストプラクティスのように思われますが、CTPの経験では、おそらくそのメリットを「すでに理解している」という理由から、50%超の企業がクラウドへの移行に関するビジネスケースの決定に必要な時間を取っていません。そうは言うものの、一部の組織はビジネスケースを作成してクラウドの経済性に対する理解を深めることにより、多くの有益な情報を得ています。

クラウドのビジネスケースの作成

クラウドの経済性は、非常に価値のある2つの異なるメリットをもたらします。1つ目は、定額法で総所有コスト (TCO) を分析してハードコストを節約できるという点です。TCOに関しては、オンプレミスのサービスとクラウドサービスを同種交換することを前提としているため、現在のコストを見極める際は、サーバー同士の比較だけではなく、パッケージ全体を見ることをお勧めします。ここで検討すべきコストは、以下のとおりです。

• ハードウェアとネットワーキングのコスト
• ダウンタイムのコスト (計画的および計画外)
• アップグレードのコスト
• ディザスタリカバリと事業継続のコスト
• サービス内容合意書の違約金
• 展開のコスト
• 運用サポートのコスト (日々の運用)
• パフォーマンスのコスト
• ベンダーソフトウェアの選択に関するコスト
• 要件分析のコスト
• 開発者、管理者、およびエンドユーザーのトレーニングのコスト
• 他のシステムとの統合に関するコスト
• 品質、ユーザー側の受け入れ、およびその他のテストのコスト
• アプリケーションの機能強化と「バグフィックス」のコスト
• 物理的なセキュリティのコスト
• 法務、MSA、および契約のコスト
• 交換および引取のコスト
• その他のリスクに関するコスト (セキュリティ侵害など)

クラウドの経済性の2つ目のメリットとしては、アジリティおよびその他の目に見えないコストが挙げられます。ただし、非常に柔軟性の高いアジャイルなインフラストラクチャを使用した場合に得られるメリットや、プロビジョニングに必要な時間が数か月から数時間に短縮された場合のコスト面の効果など、クラウドが企業にもたらす目に見えないメリットを数値化するのは、容易ではありません。ここでは、以下のような質問について考えてみてください。

• 生産性 (人日) に関する効果をどのように測定しますか。
• アプリケーションの開発期間の短縮によって得られる利益の総額はどの程度になりますか。
• ソフトウェアのライフサイクルの短縮によって得られる効果をどのように測定しますか。
• 「フェイルファスト」モデルをどのように評価しますか。
• ヒューマンエラーや機能停止が起きると、組織にどの程度の損害が生じますか。

これらの質問に対する確かな答えを得るのは容易ではありませんが、多くの企業が目に見えるメリットを得ています。たとえば、ある金融サービス企業では、Amazon Web Services (AWS) への移行後にソフトウェア開発の生産性が10%向上しましたが、7億ドルの予算を設定しているこの企業にとって、生産性向上のメリットは非常に大きく、それがクラウドファーストの取り組みに関するビジネスケースの作成に役立っています。

そして最後に、クラウドプログラムを作成するときは、ベストプラクティスとして財務面のKPIを追跡します。クラウドの経済モデルは、ユースケースを追加するのに従って、次第に優れたものとなります。

 

No. 5 - 所有するアプリケーションの内部構造を理解する

AWS、Microsoft Azure、およびGoogleのようなパブリッククラウド環境には、完全な下位互換性がなく、一部のアプリケーションはクラウドに移行できませんが、こうしたアプリケーションの重要性に応じて、パブリッククラウドプロバイダーと私有のMPLS回線を接続する、ハイブリッドクラウドネットワークが導入されることもあります。このモードでは、コスト効率の高いアジャイルなインフラストラクチャのメリットを得ながらも、クラウドベースのアプリケーションから従来のオンプレミスのサービスにアクセスすることが可能です。

ハイブリッドネットワークの課題としては、レイテンシの問題やネットワークを通じて送信されるデータのボリュームなどがあり、簡単に言うと、アプリケーションの依存関係におけるアプリケーションマッピングやデータボリュームを理解していなければ、クラウドプログラムを駄目にしてしまう可能性があります。

ここでの問題としては、多くの組織が所有するアプリケーションの内部構造を理解していることがあまりないという点が挙げられます。このレベルの詳細な情報がCMDBに含まれていることはほとんどなく、また、こうした情報を持っていたチームのメンバーがすでに組織に去っていることも少なくありません。多くの企業は、アプリケーションを中心にデータセンターを構築してきましたが、それらのアプリケーションの間でどのような接続が行われ、どの程度の量のデータがやり取りされているのかを確実に理解しておかなければ、プログラムが成功する見込みはほとんどありません。

自動化、ツール、および大胆な取り組み

アプリケーションの検出は容易ではありません。しかし幸いなことに、そうした作業の手間はツールと自動化によって大幅に軽減されます。

検出の自動化

自動化を使用して仮想マシン (VM) のプロファイルを検出するというのは、今に始まったことではなく、大部分のハイパーバイザーでこのような情報が提供されるうえ、(RAMやコアなどの) 仮想および物理サーバーの詳細を検出するサードパーティツールも多数存在します。しかしその一方で、VM間の接続、サービスコールの頻度、およびVM間を移動するデータのボリュームがわかるツールはほとんどありません。

現在のところ、標準的なVMのプロファイル情報のすべてを検出し、サービスコールに基づいて依存関係マップを作成する、エージェントレスのソフトウェアツールが提供されており、このツールを使用すれば、時間とともにVM間のデータフローの状況がわかるようになります。検出における非常に重要な最初のステップとなる依存関係マップは、その他のプロセスの基礎を築きます。

プロファイルツール

CTPでは、検出ツールの情報をインポートできるカスタムIPを開発しています。この検出ツールの情報は、サーバーの物理的な特性を示し、それらをお客様のCMDBにマッピングします。

ソフトウェア内では、チームが選択したアプリケーションの最善の移行方法を決定できるよう、アプリケーションのエントリーポイント、SLA、PIIのステータス、コンプライアンス、およびその他のリスクに関連する情報といった重要なメタデータが関連付けられます。これにより、チームは以下のようなことが行えるようになります。

1.    サーバーとアプリケーションの依存関係を特定する

2.    リスクを特定する

3.    移行戦略を決定する

4.    移行計画を策定する

5.    トレードオフと機会を見極める

6.    クラウドのリソースを適正規模にする

7.    クラウドのリソースのランレートを予測する

収集と分析が完了すると、移行チームはそのデータを移行ファクトリ用の部品表として使用します。このトピックについては、ベストプラクティスNo. 10で詳細を説明します。

 

No. 6 - 実用最小限のクラウドを構築する

実用最小限のクラウド (MVC) は、10個のベストプラクティスの中で最も重要なものの1つです。実用最小限の製品の概念に基づくMVCは、最初の本番クラウドの開始点であり、クラウドへの移行時に繰り返し使用して改善するプラットフォームとなります。Azure、AWS、およびGoogleでは、いずれにおいても新しいプラットフォームを構築するための主な手段として自動プログラミングを使用できるため、クラウドをソフトウェアの一部として考える必要があるわけですが、このような流れから生まれたのが、「インフラストラクチャはコード」という新しい合言葉です。

MVCには、ハブとスポークという2つの重要なコンポーネントがあります。

MVCハブ

MVCハブは、クラウドユーザーが使用する共通サービスのすべてを提供する、本番クラウドの構成要素であり、CTPでは、IT運用チームが一元的にサポートする共通サービスの連携型モデルを推奨しています。MVCハブで使用される標準的なサービスは、以下のとおりです。

• ログ収集と監視 (集中型)
• IDアクセス管理 (IAM)
• 暗号化ツールとキー管理
• IPS、IDS、WAFなどのセキュリティサービス
• InfoSec (セキュリティオペレーションセンター)
• イメージ管理およびレポジトリ
• 自動化とテンプレート (Chef、CloudFormationなど)
• オンプレミスリソース向けのネットワーキングサービス
• 財務管理、チャージバック、および課金

(図1に示す) MVCハブは、クラウドで最初のアプリケーションを追加する前に、最初に作成して設置する必要があります。このようにコアとなる中央のサービスを事前に設置すれば、新しいアプリケーションと既存のアプリケーションを迅速にオンボーディングするための基盤が構築されます。

「中央のサービスになぜそれほどの先行投資をするのか」と聞かれることがありますが、これは重要なポイントで、CTPは、アプリケーションを移行する前にコアとなる管理サービスを実装する方がはるかに容易であるということを経験から学びました。クラウドの基盤を変更するには非常に手間がかかり、そのクラウドを使用してきたユーザーからは、コアサービスに対応してからアプリケーションを追加することを求められます。

図2: 事業部門に固有のアプリケーションが含まれるMVCスポークは、MVCハブが提供するサービスを共同で使用します。

私たちは、大部分の組織がすべての関係者を関与させることができておらず、大規模なクラウドへの移行に着手する段階になって、IT部門以外の関係者がブレーキをかけていることに気づきました。

そのため、MVCのパイロットアプリケーションで主要関係者の懸念を解消することが重要となります。ここでは、50～100のアプリケーションを移行する段階で、(リスク、法務、財務といった) 自社の他のグループが今後のことを想像できるよう、組織を強化することを目標とします。

MVCのパイロットアプリケーションを選択するときは、以下のような特性があるかどうかを確認します。

• 機密データがある - MVC 1.0では、機密データを取り扱う必要があります。その理由は、組織がユーザーの行動に注意を払う必要があるからであり、機密データの話題を避けたとしても、それは問題への対応を先送りにすることにしかなりません。こうした問題に事前に対応し、早い段階で懸念を解消することが重要です。
• サーバーが10台未満 - 実現不可能なことをしようとしてはなりません。パイロットの段階では、大規模なアプリケーションを移行するのではなく、扱いやすく意味のあるものを選択します。
• 「リフトアンドシフト」が可能 - アプリケーションのリファクタリングや書き換えを行わないようにします。こうしたプロセスは長期間にわたり、作業が遅れる原因になることが多いため、クラウドプロバイダーがサポートするOSとデータベースサービスを含むアプリケーションを探すことが重要です。
• 要塞ホストがある - 要塞ホストは、開発者が外部からアプリケーションにアクセスできるようにする、インターネットに接続するポータルです。クラウドプラットフォームをインターネットに公開すると、リスクおよびコンプライアンス事業部門が懸念を持つ傾向にあるため、任意ではあるものの、これは組織にとって重要なステップとなります。コードを開発している場合は、今後これが必要になります (MVC 1.0で必要なかったとしても、MVC 1.1または1.2では必ず必要になります)。
• 協力的なアプリケーションオーナーがいる - 考えるまでもないことのように思われますが、クラウドへの移行を希望しているチームが所有するアプリケーションの重要性を見落としてはなりません。すべてのアプリケーションオーナーが同じというわけではないため、賢明な選択が求められます。

 

No. 7 - セキュリティとガバナンスのギャップアセスメントを行う

CTPのクラウド導入プログラムは非常に規範的です。私たちは、数百件のクラウドの導入に携わった後、お客様が使用するクラウドセキュリティテクノロジーがほぼ同じであることに気付きました。プログラムのギャップのアセスメントに使用できるベースラインを形成するリファレンスアーキテクチャーには、反復可能なパターンがあり、CTPがこうした反復可能なパターンをMVCモデルに組み込んだことから、このパターンは、CTPが構築するすべてのMVCの標準となっています。

しかし、多くの場合に、MVCの反復可能なパターンに対応するセキュリティとガバナンスの制御に関する目標のアセスメントが行われていません。制御の目標はお客様によって大きく異なり、PCIやSOXの規制に従うことを求めている場合もあれば、NISTやFISMAなどのその他多くの業界標準に従うことを求めている場合もあるため、こうした標準や規制がクラウドプログラムにどのように対応しているのかを把握するのは容易ではありません。

Cloud Security Alliance (CSA) は、セキュアなクラウドコンピューティング環境の実現に役立つベストプラクティスを定めて広く普及させる活動に力を注ぐ世界有数の組織です。CSAは、企業のクラウドコンピューティングの制御に関する目標のベースラインとして一般に認められ、現在クラウドセキュリティ手法の中心的な要素となっている、Cloud Controls Matrix (CCM) を生み出しました。

CTPでは、このCSAのCCMをAWS、Azure、およびGoogleの反復可能なアーキテクチャーに対応付けました。セキュリティとガバナンスのギャップアセスメントでは、CSAのマトリックスのような既知の標準に基づいて制御の目標を確認し、一般に認められているベストプラクティスに照らして制御とテクノロジーのギャップをドキュメント化します。

その結果として生まれたのが、CSAのマトリックスに対応付けられた規範的なセキュリティおよびガバナンスプラットフォームを含むMVCです。これを使用すれば大幅に時間が節約され、セキュリティリファレンスアーキテクチャーを基礎から構築するのではなく、ベースラインを受け入れてわずかな変更を加えるだけで、組織に固有のニーズに対応できます。

新たな制御機能とツール

大部分の組織は最初、クラウドプログラムをデータセンターであるかのように考えますが、すぐに既存の制御の目標と新たなクラウドモデルを対応付ける方法がわかっていないことに気付きます。しかしここで既存のツールセットをクラウドに適用しても意味はありません。データセンター向けのツールは、パブリッククラウドプラットフォームを念頭に置いた設計にはなっておらず、私たちの経験では、新しいツールとプロセスを導入してこうした問題を解決する必要があります。

また、新しいツールを活用することにはもう1つ大きなメリットがあり、データセンターツールと比較して、はるかにコストが少なくて済みます。

 

No. 8 - Continuous Complianceのための計画を立てる

企業は、多くの制御機能を使用してIT環境を管理しています。大部分のリソースはハードウェアベースのため、こうした機能は変更管理サービスや運用サービスの形を取っていますが、ソフトウェアをベースとする新しいクラウドモデルは、その性質から野放しの状態になっています。ここで、パーミッションベースの購買プロセス (新しいハードウェアの署名済みの発注書を取得するプロセス) から、承認を得ることなく新しいサービスを購入できるオープンなクレジットカードアカウントに移行することを想像してみてください。

新しい従量制のモデルでは、新たなレベルのガバナンスが必要とされるため、標準的な変更管理と制御のアプローチを使用してもうまくはいきません。従来の変更管理ではプロセスが長期化し、避けようとしていた状況に逆戻りすることになります。

ここで必要となるのが、Continuous Complianceです。この文脈においては、Continuous Complianceとは、常に環境を監視してクラウドにおけるサービスの使用状況と使用量を制御するソフトウェアを指し、制御は、特定のガバナンスおよびコンプライアンス要件をチェックする、「ソフトウェアシグネチャー」を使用して行われます。

たとえば、AWS社は、サーバー (EC2) と接続ストレージ (EBS) で基本的なサーバー/ストレージ構成を提供していますが、サーバーを削除してから、特にAWS社にストレージの削除を依頼しなければ、ストレージは孤立したままとなります。このようにして孤立化したブロックストレージは、次第に企業にとってのリスクとなり、適切に管理しなければ、不明なストレージボリュームによってコストが増加し、そこに機密データが格納されてしまう可能性があります。そしておわかりの通り、コンプライアンスチームはストレージディスクが野放しになっている状況を良しとしません。

現在のところ、CTPはMVCで200を超えるシグネチャーを実装する必要があると見ており、その範囲は、オブジェクトストレージの制御からIAMのチェック、暗号化の検証、キー変更のスケジュールなどに至るまで多岐にわたります。また、セキュリティ、IPS/IDP、ファイアウォールルールといった、運用の特定の領域をカバーするためのガバナンスフレームワークを提供するベンダーは存在しますが、それらすべてに対応する単一のツールはないため、すべてをカバーするには、複数のツールとカスタムソフトウェアを組み合わせる必要があります。

さらに広い範囲で見ると、継続的なガバナンスとは、ソフトウェアを使用して行われるセキュリティ、リスク、コンプライアンス、および財務面の制御の組み合わせであり、あらゆるソフトウェアの制御と同様、プロファイルを管理すればエラーが減少し、一貫性のある、繰り返し得られる成果の形で最高のメリットがもたらされます。

 

No. 9 - 自動化のフレームワークを実装する

これらのベストプラクティスでは、実装の核となる原則として自動化を挙げるとともに、Infrastructure as Codeが合言葉となっています。あらゆるアプリケーションをサポートするインフラストラクチャの自動化は、クラウド導入の中核をなしますが、その目標は、コードを通じて各アプリケーションを実装および展開することにあり、CTPでは、新しいクラウド環境の開発にDevOpsの精神を取り入れたいと考えています。

自動化の推進においては、MVCの自動化テンプレートが中心的な役割を果たしますが、ここでは、前のセクションで説明した、運用面の管理を行う反復可能な自動化テンプレートを作成することが目標となります。これにより、たとえばMVCに新しいアプリケーションチームをオンボーディングすると、GitHubや管理しているフレームワークから、クラウドプラットフォーム向けのコードの90%以上が引き出されることになります。

MVCの構築にあたっては、新しいアプリケーションチームのオンボーディングに使用する、反復可能な自動化テンプレートを作成しますが、このテンプレートには、共通サービス、ガバナンスルール、タグ付けのシナリオ、メタデータ、VPC、IAMの役割、イメージレポジトリ、およびMVCハブから提供される多数の共通サービスが含まれます。自動化テンプレートは、ヒューマンエラーの多くを排除することによって、大幅な時間の節約とリスクの軽減に貢献します。

このような新しいプロセスでは、自動化テンプレート、コードレポジトリ、およびサーバーイメージライブラリのコンテンツの制御に重点が置かれます。そして変更管理では、中核的な業務としてソフトウェア開発を行ったことがないグループのコードの管理が中心となるため、DevOpsの管理モデルを発展させ、ソフトウェアチームとの関係を強化することが欠かせません。

 

No. 10 - Migration @ Scaleに備える

Migration @ Scaleとは、ファクトリモデルを活用してクラウドにアプリケーションワークロードを移行するテクノロジー、プロセス、および人員を指します。多くのお客様は、データセンタービジネスからの撤退を強く望んでおり、大部分のエグゼクティブは、パブリッククラウドのメリットを理解したうえで、クラウドへの移行によってデータセンターのコストを削減するよう、IT部門の幹部に指示を出しています。

私たちの経験では、業界全体のTCOの平均削減率が前年比で約40%となり、こうした目標は主に、アプリケーション移行のファクトリアプローチで達成されます。

TCOを確実に削減するには、クラウドへのアプリケーションワークロードの大規模な移行が必要です。

これまでの9個のベストプラクティスでは、(数千ではないにしても) 数百のアプリケーションを移行するためのチームの準備を進めてきましたが、このような移行には、堅実なファクトリアプローチが必要です。これについて、CTPでは、クラウドに移行できるアプリケーションを見極めてから、クラウド環境をセットアップしてセキュリティを確保し、アプリケーションを受け入れるための運用の準備を行いました。

クラウドプラットフォームには完全な下位互換性がないため、アプリケーションを変更しなくても移行できるのか、移行の前に変更が必要なのかを確認する必要があります。また、アプリケーションの複雑性、開発時期、およびアーキテクチャーによって、クラウドへの移行の手間が大きく異なるため、CTPでは、アプリケーション移行ワークベンチのアプローチを推奨しています。

移行ワークベンチの立ち上げ

移行ワークベンチは、特定の移行タスクを実行するエンジニアのチームです。移行ワークベンチは、以下のように6つのタイプに分類されます。

• 再ホスティング - 一般的に「リフトアンドシフト」と呼ばれるこのワークベンチは、マシン間のアプリケーションの移行とクラウドプラットフォームへのデータの移行を行います。これは最も簡単な移行で、自動化を使用して大部分のタスクを実行できますが、アプリケーションがクラウド向けに開発されていないか、書き換えられていないため、クラウドのすべてのメリットを得られるわけではありません。
• プラットフォーム変更 - プラットフォーム変更ワークベンチは、小規模ではあるものの、きわめて重要なプラットフォーム変更のための機能を実行し、新しいクラウドプラットフォーム上でアプリケーションサーバーおよびソフトウェアを稼働させることができるようにするエンジニアのチームです。このワークベンチは一般的に、コードレベルの変更ではなく、環境の変更に関与します。プラットフォーム変更には、以下が含まれます。

       o    OSまたはデータベースバージョンのアップグレード

       o    DNSやネットワーク機器の大幅な変更

       o    INIおよび構成ファイルの変更

• リファクタリング - コードレベルの変更が必要になったときに行われるアプリケーションのリファクタリングには、クラウドへの移行を阻むブロッカーのコードのスキャンが含まれます。これに関して、CTPは、クラウドへの移行を制限することがある、.NETおよびJavaコードの問題のある領域をスキャンするソフトウェアツールを開発しました。リファクタリングは複雑な機能で、チームにはクラウドサービス分野のスキルだけでなく、セキュリティとインフラストラクチャの知識も求められます。
• 廃止 - アプリケーションの廃止は単純な作業のように思われますが、多くのお客様が多数のメリットを見落としています。データセンターアプリケーションは、クラウドプラットフォーム内で複製されるサービスによって、平均で30%が廃止されるうえ、コンプライアンス要件に対応するだけのために維持されているアプリケーションがデータセンターで稼働しているケースも少なくありません。こうしたアプリケーションは、ソフトウェアでシステムを構築してテストを行ったら停止し、必要なときにだけサービスを使用することによって、早いうちにクラウドで廃止できる場合があります。このようにすれば、大幅にコストが削減されます。
• 置換 - アプリケーションの置換はより複雑で、事業部門やアプリケーションオーナーに大きく依存します。ただし、データセンター全体を閉鎖する場合は、置換ワークベンチによる作業が必要となります。
• 保持 -- ゼロフットプリントを目標としていない限り、所有するアプリケーションの一部を保持しなければならない可能性があります。かつては、「サポート終了」のシナリオとプラットフォームの撤去に向けた計画の策定方法が非常に重視されていましたが、現在では、アプリケーションを保持する方法ではなく、クラウドベースのアプリケーションと保持するアプリケーションをどのように連携させるのかが課題となっており、そうしたアプリケーションが中心に置かれることが少なくありません。また、他のサービスとの数百の接続がある多数のデータベースやレガシーシステムが使用されており、データセンターを統合して、それらのアプリケーションを移行する必要がある場合は、保持ワークベンチが複雑に絡み合った接続を整理します。

 

まとめ

クラウドプログラムは、次の10年間で企業が直面するであろう最も重要なテクノロジーシフトです。クラウドに移行するには、いくつかのベストプラクティスに従うだけでは十分ではなく、クラウドプログラムを開始する前にまず、移行を成功させるのに必要とされる経験豊富なチームを作り、ツールやプロセスを整備しておくことが重要です。

この記事は、The Dopplerに掲載されていたものであり、許可を得てこのページに再掲載しています。