クラウドの加速：クラウドネイティブへの移行

この記事は、Ampere Computingの「Accelerating Cloud Computing」シリーズの3番目の部分です。ここでは、最初と2番目の部分を読むことができます。

このシリーズの第2部で実証したように、クラウドネイティブコンピューティングプラットフォームへのアプリケーションを再配置することは、多くの場合、比較的単純なプロセスです。たとえば、Momentoは、「PelikanがT2A（GoogleのAmpereベースのクラウドネイティブプラットフォーム）ですぐに実行されるよりもはるかに少ない作業を説明し、既存のチューニングプロセスで最適化しました

もちろん、アプリケーションは複雑で、多くのコンポーネントと依存関係があります。複雑になればなるほど、より多くの問題があります。この観点から、Pelikanキャッシュを再配置したMomentoのAmpereクラウドネイティブプロセッサへの経験は、多くの洞察を提供します。同社は、可能な限りすべてを自動化したい複雑なアーキテクチャを構築しました。再配置プロセスは、彼らにこれを達成する機会を提供します。

クラウドネイティブ処理に適した

アプリケーション

最初に考慮すべきことは、アプリケーションがクラウドネイティブコンピューティングプラットフォームでの再配置からどのように利益を得るかを判断することです。ほとんどのクラウドアプリケーションは、クラウドネイティブ処理に最適です。どのアプリケーションがクラウドネイティブのアプローチから最も利益を得ることができるかを理解するために、Ampere Cloud-Nativeプロセッサアーキテクチャを注意深く調べました。

処理効率と消費電力の低下を実現するために、さまざまなアプローチを採用してコアを設計しました。パフォーマンス、パワー、機能性の統合を回避しますプロセッサ機能は、非クラウドユースケースに追加されました。たとえば、スケーラブルベクトルスケーリングは、アプリケーションが大量の3Dグラフィックスまたは特定のタイプの高性能コンピューティング処理を処理する必要があるが、電力消費とコア密度の観点からトレードオフをもたらす場合に役立ちます。クラウド内のAndroidゲームなどのSVEを必要とするアプリケーションの場合、クラウドサービスプロバイダーには、AmpereプロセッサとGPUをペアにして3Dパフォーマンスを加速するオプションがあります。

クラウドネイティブのワークロードの場合、アンペアコアでの電力消費量の減少とコア密度の増加により、アプリケーションは電力を消費し、熱を放散しながらより高いパフォーマンスで実行されることを意味します。要するに、ほとんどのアプリケーションでは、クラウドネイティブコンピューティングプラットフォームは、運用コストを削減しながら、優れた性能、エネルギー効率の向上、およびより高い計算密度を提供する可能性があります。

Ampereは、多くの独立したコンポーネントを備えたマイクロサービスベースのアプリケーションに特化しています。このようなアプリケーションは、より多くのコアの可用性から大きな恩恵を受けることができ、Ampereは1つのチップで128コアの高いコア密度を提供し、2つのスロットを備えた1Uシャーシで最大256コアを提供します。

実際には、水平方向にスケーリングすると（つまり、多くのインスタンスで負荷分散）、アンペアの利点を実際に確認できます。アンペアは負荷で直線的にスケーリングするため、追加する各コアは直接的な利点をもたらします。これをx86アーキテクチャと比較します。x86アーキテクチャでは、各新しいカーネルの利点が急速に減少します（図1を参照）。

図1：アンペアは負荷とともに直線的にスケーリングするため、各コアが追加された直接的な利点をもたらします。これをx86アーキテクチャと比較して、各新しいカーネルの利点が急速に削減されます。

独自の依存関係

アプリケーションの再配置が直面している課題の1つは、独自の依存関係を特定することです。バイナリファイルまたは専用のX86ベースのソフトウェアパッケージを使用するソフトウェアサプライチェーンのどこでも注意する必要があります。これらの依存関係の多くは、ファイル名に「x86」を含むコードを検索することで見つけることができます。通常、交換プロセスは簡単に完了できます。X86パッケージを適切なARM ISAベースのバージョンに置き換えるか、ソースコードにアクセスできる場合はAmpere Cloudネイティブプラットフォームで利用可能なパッケージを再コンパイルします。

一部の依存関係はパフォーマンスの問題を引き起こしますが、機能の問題は発生しません。 X86プラットフォームに最適化されたコードを使用する機械学習フレームワークを考えてみましょう。フレームワークは引き続きクラウドネイティブプラットフォームで実行できますが、X86ベースのプラットフォームで実行されるほど効率的ではありません。ソリューションは簡単です。AMPEREAIに含まれるようなARM ISA向けに最適化されたフレームワークの同等のバージョンを識別します。最後に、いくつかのエコシステム依存関係があります。 Oracle Databaseなど、アプリケーションに依存している商用ソフトウェアは、ARM ISAベースのバージョンとして利用できない場合があります。この場合、これはそのようなバージョンが利用可能になるまで、再配置に適したアプリケーションではない場合があります。クラウドネイティブに優しい代替品に置き換えるなど、そのような依存関係の回避策は可能かもしれませんが、これにはアプリケーションに大きな変更が必要になる場合があります。

一部の依存関係は、スクリプト（つまり、Ansibleのプレイブック、シェフのレシピなど）など、アプリケーションコードの外側にあります。スクリプトが特定のパッケージ名またはスキーマを想定している場合、クラウドネイティブのコンピュータープラットフォームに展開するときに変更する必要がある場合があります。これらの変更のほとんどは簡単であり、スクリプトの詳細なレビューはこれらの問題のほとんどを明らかにします。開発チームが長年にわたって行った可能性のある命名の仮定を調整することに注意してください。

現実には、これらの問題は通常対処しやすいということです。それらを徹底的に識別して処理するだけです。ただし、このような依存関係に対処するコストを評価する前に、技術的な負債の概念を考慮する必要があります。

技術的債務

フォーブスの記事「技術的債務：デジタル変革における測定可能な障害」では、技術的な負債は「システム内の比較的速い修理の蓄積、または重いが誤って指示された投資が長期的には財政的である可能性があります。長期的な解約では、迅速な修正はシステムを実行し続けることができますが、蓄積された技術的な負債は無視できません。時間の経過とともに、技術的な負債は、コーヒーマシンの規模の蓄積が最終的にそのパフォーマンスを低下させるのと同じように、ソフトウェアシステムの変化のコストを増加させます。

たとえば、

モーメントがペリカンキャッシュを再現した場合、クラウドネイティブプロセッサをAmpereに再現した場合、15年前からオープンソースコードに依存していたロギングおよび監視コードをインストールしていました。コードは機能するため、更新されることはありません。ただし、ツールが時間の経過とともに変化するにつれて、コードを再コンパイルする必要があります。後方互換性を維持し、古いコードに依存関係を作成するためには、一部の作業が必要です。これらの依存関係はすべて、長年にわたって蓄積されてきました。ある時点で、これらの依存関係を維持することが複雑で高価になると、新しいコードに移行する必要があります。技術的な負債は回収されていると言えます。

アプリケーションをクラウドネイティブコンピューティングプラットフォームに再展開する場合、現在の技術的債務とそれがどのように決定を促進するかを理解することが重要です。長年にわたってレガシーコードを維持および適応させると、技術的な負債が蓄積される可能性があるため、再配置がさらに複雑になります。ただし、これ自体は再配置のコストではありません。別のプラットフォームに再展開しないことに決めたとしても、いつかコードの更新を延期するためのこれらすべての迅速な修正やその他の決定を補う必要があります。あなたはまだそれをしていません。

技術的な負債はどれほど現実的ですか？ McKinseyの調査（Forbesの記事を参照）によると、調査のCIOの30％は、新製品の技術予算の20％以上が実際に技術的債務に関連する問題に対処するために使用されたと推定しました。

赤い展開は、長年にわたってアプリケーションによって蓄積された技術的債務のいくつかに対処する絶好の機会です。会社が対処するために使用するテクノロジー債務の「20％」の一部を取り戻すことを想像してください。これにより、再配置プロセスの時間が長くなる可能性がありますが、技術的な負債の処理には、長期的にコードの管理と維持の複雑さを簡素化する利点があります。たとえば、コードを依存し続けるのではなく、コードを現在の開発環境に移行することにより、多くの依存関係を「リセット」できます。これは、開発サイクルを簡素化することで即座に報われる投資です。

PleskのプロダクトマネージャーであるAnton Akhtyamovは、再展開の経験を説明しました。 「移植後、いくつかの制限に遭遇しました。Pleskは、多くのアドオンモジュール/拡張機能をインストールできる大きなプラットフォームです。一部はDr. WebやKaspersky Antivirusなど、ARMによってサポートされていません。一部の拡張機能も利用できません。拡張機能のほとんどは、アームのベンダーによって再構築されたパッケージを使用して既にサポートされています（主にc）。重要な問題

クラウドネイティブプラットフォームへのアプリケーションの再展開のより実用的な例については、ARMおよびAmpere AltraのTakuaをOpenMandrivaに移植することを参照してください。

このシリーズの第4部では、アプリケーションをクラウドネイティブコンピューティングプラットフォームに再配置するときに期待できる結果に飛び込みます。

以上がクラウドの加速：クラウドネイティブへの移行の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。