クラウドワークロードを移行するための4つの重要な戦略

実際には、これは言うほど簡単ではありません。 IT エンジニアは、気まぐれでアプリケーション全体を 1 つのクラウド プラットフォームから別のクラウド プラットフォームに移行するわけではありません。クラウド移行という言葉の本当の意味は、それではありません。対照的に、ワークロードの移植性は、短期的なオプションと長期的な柔軟性の両方が可能であるという事実を反映しています。特定のアプリケーションを特定のクラウド プラットフォームまたはオンプレミス環境で実行することを決定しても、そのアプリケーションを常にその環境で実行する必要があるわけではありません。

コンテナ化、オーケストレーション、および最新のソフトウェア開発と運用のその他の側面は、運用環境の基礎となります。もちろん、ワークロードの移植性は、企業が少なくとも 2 つのクラウド プラットフォームまたはオンプレミス/ベア メタル環境から選択できることも意味します。

クラウド ワークロードの移行では、いくつかの重要な問題が発生する可能性があります。 Red Hat のテクニカル エバンジェリストである Gordon Haff 氏は、ワークロードの移植性はハイブリッド クラウドとエッジ アーキテクチャにおける重要な用語であると述べています。

クラウドワークロードを移行する4つの方法

次の記事では、クラウド ワークロードを移行するための 4 つの異なるアプローチについて詳しく説明し、複数の環境にわたるワークロードの実行と移行、および全体的なハイブリッド クラウドまたはマルチクラウド戦略の開発について詳しく説明します。

（１）クラウドワークロードの移行に関する標準の策定

多くのハイブリッドおよびマルチクラウド環境は、アドホックまたは無計画な方法で始まります。それは当然のことですが、ハフ氏が指摘するように、最終的にはより目的意識のある戦略に置き換えられるべきです。

まず、特定の環境内でワークロードを実行および移行するための明確な標準が必要です。

「ワークロードをどこで実行するかを決める理由はたくさんあります」と、Faction の CTO である Matt Wallace 氏は述べています。 「最も難しいのは、チームやパートナーのワークロードが異なるクラウドにあるか、異なるサービスにアクセスする必要があるため、正しい答えがないことです。」

したがって、ビジネスにとって重要な特定の理由に焦点を当て、それに基づいて選択を行うようにしてください。ウォレス氏はいくつかの例を挙げた。

• 他のアプリケーションやデータへの近接性 (「データ グラビティ」とも呼ばれます) は、パフォーマンスやレイテンシが主な懸念事項となる場合の推進要因となることがよくあります。
• 他のチームやパートナーと共同作業します。特定のクラウド プラットフォームを使用している場合は、同様に共同作業を行います。
• 特定のクラウド プラットフォームで利用可能なツールセットは、すべてが同じように作成されているわけではありません。
• 地理/場所の問題。
• 料金。
• スケール – たとえば、予測可能で安定したワークロードと、リソース需要が増大したり急増したりする可能性のあるワークロードとの違い。

一部の標準では、企業の目標やニーズに関してさらに具体的に指定すると有益です。パフォーマンスは非常に広範囲にわたります。たとえば、パフォーマンスのバランスはレイテンシです。これらの用語が企業とそのアプリケーションにとって実際に何を意味するかを定義することで、ワークロードを適切な環境に一致させるための、より洗練された意思決定マトリックスが提供されます。

同様に、クラウド プラットフォームの選択も、特にコア インフラストラクチャを超えて考えると、万能というわけではありません。

「どんなクラウド環境でも、インフラストラクチャ サービスは必須です」と、Liberty Mutual Insurance のシニア アーキテクトである Eric Drobisewski 氏は述べています。 「これらのコア サービスを超えて、ビジネスに差別化された価値を提供できるパブリック クラウド プロバイダーの主要要素を特定し、それらを活用してより大きな価値をより早く提供することを目指します。」

（２）全員が、そしてすべての物事がうまく連携して機能するようにする

ハイブリッドおよびマルチクラウド環境は、通常、時間の経過とともに分散化と多様化が進みます。ワークロードを効果的に管理および移行するための鍵は、すべてを壊すことなく変更を加えることができることです。新しいツールやサービスを追加して、既存のテクノロジー スタックと互換性を持たせることができる必要があります。

ここでウォレスは、この戦略を「アーキテクチャ」という単一の用語に要約しています。

「建築を設計することで、解釈に行き詰まるのを避けることができる」と彼は付け加えた。 「移植性や一貫性のために抽象化を提供するツールを利用することは有用です。集中化された ID と Security Assertion Markup Language (SAML) 認証を使用して他のものを標準化することも有用です。」

実際、標準化は統合戦略における大きな利点です。特にクラウド コンピューティング分野の変化のペースを考えると、オープン スタンダードはさらに優れています。 Drobisewski 氏は、これは初期の統合コストと長期的な柔軟性の両方にとって有益であると指摘しました。

「可能であれば、さまざまなクラウド プロバイダーが採用しているオープンな仕様と標準を活用することで、統合が簡素化され、相互運用性が向上します」とドロビセフスキー氏は述べています。

SAS のシニア ソフトウェア開発マネージャー、ジャスティン デンプシー氏は、「すべて」が何を意味するのかがわからないと、すべてを調和させることは難しいと述べています。彼のチームは、複数のクラウド プラットフォームにわたるツールとアプリケーションのマトリックス インベントリを作成することが有用であることに気付きました。これは、ギャップの特定からソフトウェア サプライ チェーンのセキュリティの確保まで、あらゆることに役立ちます。また、ワークロードの移植性に関する意思決定にも役立ちます。

「管理するツールのマトリックスを作成し、どのツールがクラウドに依存しないか、クラウドに移植できないか、クラウドに固有のものかを示します」とデンプシー氏は述べた。 「これにより、あるクラウドから別のクラウドへの移行や、複数のクラウド プロバイダーにまたがるアーキテクチャの作成に伴うリスクを評価することができます。」

できるだけ多くのコードを管理することも、ここでの重要な戦略です。

「『すべてをコードとして』という取り組みは、一貫した配信、ガバナンス管理の遵守を促進し、新しい運用環境が既存の運用環境と調和して機能することを保証するテスト標準を実施する方法です」とデンプシー氏は述べた。

（３）コストの管理と最適化

クラウドのコストは、「クラウドの方が安い！」など、絶対的かつ極端なものに単純化されることがよくあります。 （必ずしもそうとは限りません）または「クラウドの請求額がなぜこんなに高いのですか？」 （理由はいろいろ考えられます。）

これは、慎重な設計と計画を必要とするもう 1 つの領域です。 Faction の Wallace 氏は、インフラストラクチャ コストとして分類されるものの多くは、実際にはアプリケーション レベルの問題であると指摘しました。

「API ゲートウェイとサーバーレス機能を使用してクラウド内に 3 層の自動スケーリング アーキテクチャを構築し、わずかなコストで実行できる作業を実行すると、クラウド サービスの使用に莫大なコストを支払うことになります」と Wallace 氏は述べています。

Red Hat の Haff 氏が以前述べたように、クラウド コンピューティングは確かに高価になっています。これは、これらを使用すべきではないという意味ではないとハフ氏は説明する。「しかし、これらが企業に高い価値をもたらす場所と、オンプレミスでワークロードを実行することを検討すべき場所を理解する必要があります。」

ワークロードとデータの実行と移行について情報に基づいた意思決定を行うには、コストを包括的に理解することが重要です。ウォレス氏は別の例として深冷貯蔵庫を挙げているので、使用初期段階ではコストは高くないと思われるかもしれません。

「あるクラウドでは、データをクラウドから取り出すコストが、データを4年間保存するコストを上回った」とウォレス氏は語った。 「これはクラウド プロバイダーの問題ではありませんが、オフライン リポジトリのテープを置き換えることができる「保存して忘れる」ユース ケースに対する需要が非常に高まっています。ただし、サービスをユース ケースに適合させないと、コストが高くなることになります。」

ワークロードの移植性とクラウド コンピューティングのコストに関して、重点を置くべき主な領域は 2 つあります。

• 可視性: クラウド コストを効果的に管理するには、「誰が何を使用しているか」という質問に答えられることが重要です。クラウド コストを最適化するには、「なぜ？」という質問に答えられる必要があります。ウォレス氏は、金融用語を使ってこの質問を明確に尋ねました。「誰がどのサービスにいくら使っているのか？」これがブラックボックスだとコスト目標の達成は難しくなります。
• データ フロー: クラウド ワークロードを移行すると、環境へのデータの流入と流出 (多くの場合、データ イングレスとデータ エグレスと呼ばれます) に関連する追加の (場合によっては予期しない) コストが発生する可能性があります。

どちらの方法でも料金の支払いが必要ですが、データ送信の料金は通常注意が必要です。

SAS のデンプシー氏は、「特に複数のクラウドやクラウド地域にまたがるデータ移行の場合、データ送信料金はすぐに膨らむ可能性がある」と述べた。

ウォレス氏が言及したディープコールドストレージの例は、予期せぬクラウド請求につながるデータ送信料金に関わる多くのシナリオのうちの 1 つです。

「これはネットワークトラフィックの点で最も顕著です。パブリッククラウドのネットワークゲートウェイをオンにして仮想ネットワークに接続すると、ゲートウェイに1日あたり2.40ドルを支払うことになりますが、極端な例では、データ転送料金が1日あたり1万800ドルに達する可能性があります」とウォレス氏は述べた。

クラウド間でワークロードを移行すると、コストが急上昇する可能性が高まります。

「マルチクラウドの場合、クラウド外のネットワークトラフィックに高いコストが発生する可能性が高くなるため、リスクは拡大します」とウォレス氏は述べた。 「これは一般論ですが、これらのデータフローを理解する必要があることに注意することが重要です。」

（4）開発者はシンプルかつ高速にする必要がある

最後に、開発者のことを忘れないでください。最近では開発者の経験がすべてです。

ハイブリッドおよびマルチクラウド環境が多様化および複雑化するにつれて、企業が決定した基準に基づいてワークロードを最適な環境に一致させる制御と柔軟性など、いくつかの利点は、開発チームへの不必要な摩擦を防ぐことにかかっています。

Wallace 氏は、開発者、アプリケーション ポートフォリオ、コード ベース、ミッションなど、さまざまな要因によって決まると指摘しています。

ウォレス氏は、マルチクラウドの利点と開発者の豊富な経験を組み合わせた理想的なシナリオは、開発者がオンプレミスまたはクラウド開発環境のいずれかで開発でき、保守するインフラストラクチャがほとんどなく、開発中の暴走コードによるコストの暴走を回避するために、API ゲートウェイなどのコンポーネントにスロットリング制限などのツールが組み込まれているサーバーレス モデルになる可能性があると述べました。

コードの作成、テスト、およびデプロイ間の摩擦を最小限に抑える優れたツールは、ビジネスと開発者の両方にとって有益であり、真のワークロード移植性の基盤となります。

「この設計パターンは、あらゆるクラウド プラットフォーム、オンプレミス データ センター、エッジ展開間の移植性を最大化するのに非常に優れています」と Wallace 氏は述べています。

Drobisewski 氏は、ハイブリッドおよびマルチクラウド エコシステムの利点により、開発者がそれらを簡素化する可能性があると指摘しました。

「技術サポートを統合し、安全かつコスト最適化された一連の適切に設計されたパターンをキュレートする単一のマーケットプレイスに投資することで、再利用の文化を育みながら開発者の能力強化を加速できます」とドロビセフスキーは述べています。

最後に、クラウド ワークロードの移植性が優先される場合、ハイブリッド クラウドとマルチクラウドは実際にうまく連携し、相互に補完し合って開発の速度を向上させます。デンプシー氏は、特定の方法論やプロジェクト管理スタイルに固執しすぎないようにアドバイスしています。

コストと同様に、開発者の速度もアプリケーション レベルで確認する必要があります。

「あなたのアプリケーションのうち、何らかの抽象化を提供していないものはどれでしょうか。アプリケーション スタックのどの側面が特定のテクノロジーやベンダーと密接に結びついているでしょうか。これらは摩擦の原因となる可能性があります。目標が分離して堅牢なデータ配信パイプラインの作成に重点を置くことであれば、開発者とデータ コンシューマーに長期的な柔軟性と統合の機会がもたらされます」とデンプシー氏は語った。