ガートナー: 従来のアプリケーションを最新化してクラウドネイティブの成功を実現

クラウド以前の既存のエンタープライズ アプリケーションでクラウド コンピューティングを最大限に活用できるようにするには、サポートされていないオペレーティング システムのバージョン、エンタープライズ データ ストアやファイル ストレージと緊密に統合されたモノリシック アーキテクチャ、関係者の期待 (コスト削減の期待を含む) を満たすことの難しさなど、多くの技術的な障壁があります。

クラウドネイティブ アーキテクチャを採用したグリーンフィールド アプリケーションは、これらの課題による影響がはるかに少なくなりますが、これらの新しいアプリケーションは、組織の既存のアプリケーションのごく一部を占めるにすぎません。

ドロップイン アプローチを使用して Infrastructure as a Service (IaaS) に再ホストされたレガシー アプリケーションでは、すべてのクラウド機能を十分に活用できないことがよくあります。この再ホスティング アプローチを採用する組織では、移行チームがアプリケーションを実行するためだけに近道をしたり回避策を考え出したりすることがよく起こります。

これらのショートカットや回避策は、再ホスティングの目的が厳しいスケジュールでアプリケーションを移行し、クラウドで既に実行されている他のアプリケーションを大幅に変更してサポートすることであるため発生します。レガシー アプリケーションはクラウド ネイティブ対応について十分に評価されていなかったため、悲惨な結果につながりました。

考慮すべき点の 1 つは、レガシー アプリケーションは強力なデータ整合性を実現するために、従来のリレーショナル データベース管理システム (RDBMS) とアトミック、一貫性、独立性、永続性 (ACID) トランザクションに依存することが多いことです。

これらの従来のデータベースは、基盤となる堅牢で信頼性の高いインフラストラクチャに依存しています。不安定なインフラストラクチャや障害が発生しやすいインフラストラクチャの環境向けに構築されていません。これらのデータベースはスケールアウトではなくスケールアップを目的としているため、豊富なクラウド リソースを活用できず、アプリケーションを柔軟にスケールする能力が制限されます。

ただし、現代のアプリケーション設計では、ポリグロット永続性を活用して、特定のユースケースに合わせてデータベースの動作を最適化します。この概念により、開発者は、従来の構造化クエリ言語 (SQL) モデルにデータを強制的に適合させるのではなく、データとプログラミング アプローチに最適なデータ ストアを選択できます。すべてのデータ ストレージに RDBMS を使用すると、設計の柔軟性が欠如し、データベースの拡張時に多大なコストが発生する可能性があります。

クラウド コンピューティングを導入するには、慎重な計画と、既存のアプリケーションをクラウド ネイティブ アーキテクチャに移行する際の障壁についての深い理解が必要です。ガートナーのクライアントは、クラウド導入が不十分な理由として、計画の不備や移行戦略の不備を頻繁に挙げています。計画と構造がなければ、移行の決定はアプリケーションを実行するために行われることがよくあります。これでは、述べられた目的と矛盾することになります。

目標を設定する

クラウド移行にはさまざまなアプリケーションが含まれることが多く、その一部は大規模な改修や更新を必要とし、クラウドが提供する機能の恩恵を受けることができます。これらの計画は組織によって異なります。これらの取り組みの背後にある決定、プロセス、および人材は、各組織に固有のものです。しかし、ガートナーはいくつかの繰り返し発生する技術目標を特定し、説明しました。

組織のクラウド近代化の取り組みが特定のビジネス目標に沿って進められ、組織全体の関係者がその目標に沿って進むことが重要です。たとえば、すべてのアプリケーションの最新化に再構築が必要なわけではありません。データベースのパーティション分割が特定のアプリケーションのクラウド移行目標の 1 つでない場合は、スケーラビリティを向上させるためにデータベースを調整する必要はおそらくありません。

努力スコアカードを作成する

Gartner は、特定のホット スポットのアーキテクチャ評価をカバーするアプリケーション モダナイゼーションのフレームワークを提案しました。

アプリケーションを最新化するために必要な労力の量は、各ホットスポットが移行のビジネス目標をどの程度妨げるかを評価することによって決定する必要があります。アプリケーションの適応が容易になればなるほど、クラウドネイティブのアーキテクチャ パターンと原則を採用するために必要な作業、労力、リソースが少なくなります。

このステップでは、評価の残りの部分で各ホットスポットを分析するときに入力する労力スコアカードを作成する必要があります。

近代化を妨げる要因

アプリケーションの最新化の労力を増加させる主な制約は、結合と複雑さの 2 つです。

結合は、アプリケーション内外の相互依存関係の数と考えることができます。たとえば、コードの観点からは、コード ブロックが相互にどのように相互作用するか、また、メソッド、クラス、関数がどのように構成されているかなど、呼び出しグラフを調べる必要があります。異なるコード ブロックに依存するスクリプトまたはコード ブロックは結合されていると見なされます。

アーキテクチャとコードの複雑さにより、結合の問題がさらに複雑になる可能性があります。複雑さは、基盤となるソフトウェアとハ​​ードウェアの詳細に大きく依存する、密に結合されたアプリケーション コンポーネントから発生する可能性があります。この複雑さにより、クラウド ネイティブ プラットフォームの展開、ランタイム、ホスティングの選択肢が制限されます。類似しており同時に変更される低レベルの依存関係とコンポーネントの抽象化とカプセル化を実現することが重要です。この意味での複雑さとは、実装が難しい依存関係があることを意味します。アプリケーション レベルの依存関係 (たとえば、アプリケーション コンポーネント間の依存関係) も影響を与える可能性があります。

アプリケーションを評価すると、アプリケーション内の結合の深さと複雑さが明らかになります。これにより、アプリケーション内の各ホットスポットを最新化するために必要な全体的な労力を判断できます。これらの近代化の程度に応じて、コードのさまざまな部分にさまざまな戦略を選択できます。

近代化の程度はビジネス目標に直接関係します。アプリケーションの変更能力がこれらの目標を達成するのに十分である場合は、コードをリファクタリングし、アプリケーションをクラウド ネイティブ プラットフォームに最新化するだけで十分な場合があります。完全な最新化の取り組みが大きすぎる場合は、アプリケーション全体を再構築するしか選択肢がない可能性があります。ただし、アプリケーション アーキテクチャの観点からは最新ではないが、データ永続性の観点からは最新の場合は、個々のコンポーネントを再設計して再構築することもできます。

その他の課題

クラウド環境では、障害が発生する可能性のある信頼性の低いコンポーネントを多数使用して信頼性の高いアプリケーションを構築しようとしており、障害の種類は一般に、単一のマシンで発生するアプリケーション コンポーネントの障害とは異なります。クラウド コンピューティングには、垂直方向のスケーリングよりも水平方向のスケーリングに適した一時的なリソースを持つ環境で動作するアーキテクチャが必要です。

クラウド ネイティブ アーキテクチャは、クラウドが提供する利点と、プロバイダーにアウトソーシングされて制御が制限される異種のドメインとのバランスをとります。組織は、スケーラビリティの向上、ビジネスの拡大、新しいチャネルの導入、需要の減少時のリソースの削減を目的としてクラウドに移行します。これにより、通常の日常業務とは異なる予測不可能な負荷が発生する可能性があります。

クラウド プロバイダーでネイティブ ホスティング サービスを使用すると、アプリケーション コンポーネントがネットワーク全体に分散されるため、アプリケーションに遅延が発生する可能性があります。クラウド ネイティブ アーキテクトは、一部のクラウド サービス障害、システム障害、セキュリティ脆弱性が完全に制御できないことも考慮する必要があります。

リーダーシップは、クラウド ネイティブの原則をアプリケーションにいつ、どこで使用すべきかを理解するために、全面的に考え方を変える必要があります。リーダーシップは、個人が組織の文脈の中でこれらの教訓を継続的に学び、改善できるようにする必要があります。クラウド ネイティブのモダナイゼーションをアプリケーション メンテナンス ライフサイクルの定期的な一部にします。クラウド イノベーションは既存の組織プロセスや文化を超え、既存の手順を混乱させるため、組織変更プロセスへの多大な投資が必要です。