クラウドの加速：最終ステップ

（この記事は、Ampere Computingの「Accelerating Cloud Computing」シリーズの5番目の部分です。すべての記事をSitePointで読むことができます。） クラウドネイティブアプリケーション開発の最後のステップは、どこから始めるかを決定することです。このシリーズの最終号として、クラウドネイティブアプリケーションを開発する方法、組織内のプロセスを開始する場所、およびプロセスで遭遇するさまざまな状況を検討します。

このシリーズの他の部分に示されているように、クラウドネイティブプラットフォームはX86ベースのコンピューティングの強力な代替品になりつつあります。パートIVで実証したように、パフォーマンス、予測可能性、エネルギー効率の観点から、フルコアアンペアVCPUとセミコアX86 VCPUの間には大きな違いがあります。

クラウドネイティブアプリケーションの開発方法

クラウドネイティブコンピューティング環境向けの分散アプリケーションを設計、実装、および展開する自然な方法は、アプリケーションをより小さなコンポーネントまたはマイクロサービスに分割することです。それぞれが特定のタスクを担当します。これらのマイクロサービスでは、通常、機能を共同で提供する複数の技術要素があります。たとえば、注文管理システムには、プライベートデータストア（メモリ内の注文と顧客情報のキャッシュに使用される場合があります）と、APIマネージャーがフロントエンドサービスを有効にするためのAPIマネージャーに加えて、顧客のショッピングカートを処理するセッションマネージャーが含まれる場合があります。それと対話できるように。さらに、商品の可用性を決定するための在庫サービスに接続されている場合があります。おそらく配送と配送日を決定するための配送モジュール、および支払いを徴収する支払いサービス。

クラウドコンピューティングの分散された性質により、アプリケーションは要件とともにスケーリングでき、単一のソフトウェアでは達成できない方法でアプリケーションコンポーネントを独立して維持できます。 eコマースのWebサイトに大量のトラフィックがある場合は、在庫サービスまたは支払いエンジンとは無関係にフロントエンドを拡張するか、注文管理を処理するための労働者プログラムを追加できます。クラウドネイティブアプリケーションの設計目標は、障害の1つがグローバルなシステム障害を引き起こす可能性のある単一の大規模アプリケーションではなく、1つのコンポーネントで障害を分離することにより、他のコンポーネントが影響を受けることを避けることです。

さらに、クラウドネイティブのアプローチにより、ソフトウェアは、現在の負荷を処理し、オフピーク時間中にリソースをシャットダウンするために必要なサーバーを作成するだけで、利用可能なハードウェア機能を最大限に活用できます。 Ampereのような最新のクラウドネイティブCPUは、膨大な数の高速CPUコアと高速相互接続を提供し、ソフトウェアアーキテクトがアプリケーションを効果的に拡大できるようにします。

このシリーズの2番目と3番目の部分では、アームベースのクラウドネイティブプラットフォームへのアプリケーションの移行が比較的簡単であることを示しています。この記事では、この移行を成功させるために通常取られる必要がある手順について説明します。

組織内のどこから始めればよい

AmpereのCloud-Native ARM64プロセッサに移行する最初のステップは、適切なアプリケーションを選択することです。他のCPUアーキテクチャに密接に結びついているアプリケーションの中には、特定の命令セットにソースコード依存関係があるため、または命令セットに関連するパフォーマンスまたは機能的制限のために、移行がより困難になる場合があります。ただし、アンペアプロセッサは、多くの場合、多くのクラウドアプリケーション向けに適切に設計されています。

• マイクロサービスアプリケーション、ステートレスサービス：アプリケーションが必要に応じて独立して拡張できるコンポーネントに分割されている場合、Ampereプロセッサはそれに最適です。アプリケーションを分解し、クラウドが提供する利点を活用する重要な部分は、ステートフルとステートレスのサービスを分離することです。ステートレスアプリケーションコンポーネントは水平方向にスケーリングでき、必要に応じてより高い容量を提供し、データベースなどのステートフルサービスを使用して非輸送データを保存します。 Stateless Servicesのスケーリングは、多くのサービスのレプリカ間でバランスを取り、コンピューティングインフラストラクチャにコアを追加して需要の増加に対処できるため簡単です。 AmpereのシングルスレッドCPU設計のおかげで、これらのコアをアプリケーションの遅延に影響を与えることなく、より高い負荷で実行して、全体的な価格/パフォーマンスを削減できます。
• オーディオまたはビデオトランスコーディング：データをあるコーデックから別のコーデックに変換する（たとえば、ビデオ再生アプリケーションまたはIP電話システムの一部として）。より多くの労働者プログラムを追加することにより。したがって、このタイプの負荷はアンペアプラットフォームで非常にうまく機能し、他のプラットフォームよりも30％以上高い価格/パフォーマンスの優位性を提供できます。
• AI推論：トレーニングAIモデルは、トレーニング用の非常に高速なGPUの可用性から利益を得ることができますが、モデルをデータに適用することは、生産環境に展開された場合、それほど浮動点は集中していません。実際、AIモデルの推論のパフォーマンスと品質SLAを満たすために、低精度の16ビットフローティングポイント操作を使用して、汎用プロセッサでうまく実行できます。さらに、AIの推論は、トランザクションボリュームの変化に応答するために、より多くの労働者と核を追加することで利益を得ることができます。全体として、これは、アンペアのようなモダンなクラウドネイティブプラットフォームが優れた価格/パフォーマンスを提供することを意味します。
• メモリ内データベース：アンペアカーネルはカーネルごとに大きなL2キャッシュを持つように設計されているため、通常、オブジェクトやクエリキャッシュなどのメモリ集中的なワークロード、およびメモリ内データベースで非常にうまく機能します。 Redis、Memcached、MongoDB、MySQLなどのデータベースワークロードは、コアごとの大きなキャッシュを活用してパフォーマンスを向上させることができます。 - 継続的な統合ビルドファーム：ビルドソフトウェアは非常に計算集約型で並行可能になります。継続的な統合プラクティスの一部としてビルドと統合テストを実行し、継続的な配信プラクティスを使用して、生産に参加しようとしている新しいバージョンを検証することで、Ampere CPUでのランニングから恩恵を受けることができます。 ARM64アーキテクチャへの移行の一環として、そのアーキテクチャのソフトウェアの構築とテストは前提条件であり、ネイティブARM64ハードウェアでこの作業を実行すると、ビルドのパフォーマンスが向上し、開発チームのスループットが増加します。

アプリケーションの依存関係を分析します

移行に適していると思われるアプリケーションを選択したら、次のステップは、依存関係スタックを更新するために必要な作業を決定することです。依存関係スタックには、ホストまたはゲストオペレーティングシステム、プログラミング言語、ランタイム、およびサービスが持つ可能性のあるアプリケーションの依存関係が含まれます。Ampere CPUで使用されているARM64命令セットは、近年目立つようになっており、多くのプロジェクトは近年ARM64のパフォーマンスを改善するために一生懸命働いています。したがって、このセクションの一般的なトピックは「新しいバージョンがより良い」です。

• オペレーティングシステム：ARM64アーキテクチャが過去数年間で大きな進歩を遂げているため、パフォーマンスの改善を活用するために更新されたオペレーティングシステムを実行することをお勧めします。 Linux分布の場合、最近の主流分布は、ネイティブARM64バイナリインストールメディアまたはDockerベースの画像を提供します。アプリケーションが現在、Red Hat Enterprise Linux 6または7、またはUbuntu 16.04または18.04などの古いオペレーティングシステムを使用している場合は、ベースオペレーティングシステムの更新を検討することをお勧めします。
• 言語ランタイム/コンパイラ：すべての最新のプログラミング言語はARM64で利用できますが、一般的な言語の最新バージョンには追加のパフォーマンスの最適化が含まれる場合があります。 Java、Go、および.NETの最新バージョンがARM64のパフォーマンスを大幅に改善したことは注目に値します。
• アプリケーションの依存関係：オペレーティングシステムとプログラミング言語に加えて、他の依存関係を考慮する必要があります。これは、アプリケーションが使用するサードパーティライブラリとモジュールをチェックし、これらのライブラリがARM64に利用可能であり、配布用にパッケージ化されていることを確認し、データベース、必要に応じてアンチウイルスソフトウェアなどの外部依存関係を考慮していることを意味します。依存関係分析には、ARM64依存関係の可用性や、これらの依存関係がプラットフォーム固有の最適化を備えている場合のパフォーマンスへの影響など、複数の要因を含める必要があります。場合によっては、一部の機能が失われたときに移行することができますが、他の機能では、移行がARM64アーキテクチャの最適化に適応するためにエンジニアリング作業が必要になる場合があります。

ARM64

でソフトウェアをビルドおよびテストします

クラウドサービスプロバイダー（CSP）でのARM64コンピューティングリソースの可用性は最近拡大しており、まだ成長しています。 Ampere Computing Webサイトでページを購入する場所と場所からわかるように、ARM64ハードウェアの可用性は、データセンターであろうとクラウドプラットフォームでも問題ではありません。

アンペアインスタンス（ベアメタルまたは仮想マシン）にアクセスできると、移行のビルドとテストフェーズを開始できます。上で言ったように、ほとんどの最新の言語は現在、ARM64を一流のプラットフォームとして完全にサポートしています。多くのプロジェクトでは、ビルドプロセスはバイナリを再コンパイルするか、JavaコードをARM64ネイティブJVMに展開するのと同じくらい簡単です。

ただし、ソフトウェア開発プロセスの問題が、移行プロセス中にチームが返済しなければならない「技術的債務」につながる場合があります。これは多くの形をとることができます。たとえば、開発者は、特定のハードウェア機能の可用性や、標準では定義されていない実装固有の動作について仮定することができます。たとえば、CHARデータ型は、実装に応じて署名された文字または非署名文字として定義でき、X86のLinuxでは署名されます（つまり、-128〜127の範囲）。ただし、同じコンパイラを使用してARM64では、署名されていません（範囲0〜255）。したがって、charデータ型シンボルに依存するコードは正しく機能しません。

ただし、全体として、SSEなどのX86固有のハードウェア機能に依存しない標準とコードに準拠するコードは、Ampereプロセッサで簡単に構築できます。 Jenkins、Circleci、Travis、GitHubアクションなどのサポートARM64ビルドノードなど、ほとんどの連続統合ツール（サポートプラットフォームマトリックス全体で自動化された構造とテストを管理するツール）。

生産中のアプリケーションの展開を管理

クラウドネイティブのアプリケーションを生産に展開する際に、インフラストラクチャ管理にどのような変化が起こるかを確認できます。最初に注意すべきことは、アプリ全体を一度に移動する必要がないということです。ARM64への移行から最も恩恵を受ける部分を選択して、それらの部分から始めることができます。ほとんどの管理されたKubernetesサービスは、単一のクラスターの不均一なインフラストラクチャをサポートしています。面倒なことに、CSPによって異なる名前は、単一のKubernetesクラスターでさまざまなタイプの計算ノードを混合するメカニズムに異なる名前を持っていますが、すべての主要なCSPはこの機能をサポートしています。 Kubernetesクラスターにアンペア計算プールがあると、「ブロット」と「耐性」を使用して、コンテナのノードアフィニティを定義できます。

ARM64アーキテクチャ用のプロジェクトコンテナを構築している場合、マルチアーキテクチャコンテナとなるマニフェストを作成するのは非常に簡単です。これは基本的に、複数のコンテナ画像へのポインターを含むマニフェストファイルであり、ホストアーキテクチャに基づいて画像を選択するときにコンテナが実行されます。

展開段階で人々が通常遭遇する主な問題は、再び「技術的債務」に分類できます。展開および自動化スクリプトは、特定のプラットフォーム固有のパス名を想定したり、X86のみのバイナリアーティファクトに依存するようにハードコードすることもできます。さらに、異なるLinux分布によって返されるスキーマ文字列は、分布によって異なる場合があります。 x86、x86-64、x86_64、arm64、aarch64に遭遇する場合があります。これらのプラットフォームの違いを正規化することは、過去に行ったことのないことかもしれませんが、プラットフォーム変換の一部として非常に重要です。

プラットフォーム変換の最後のコンポーネントは、アプリケーションの操作です。クラウドネイティブアプリケーションには、適切に機能するように、生産における多数の足場が含まれています。これらには、イベントを集中化するログ管理、管理者が物事が期待どおりに機能することを確認するための監視、異常、侵入検知ツール、アプリケーションファイアウォール、またはその他のセキュリティツールが発生した場合にアラートを警告することが含まれます。俳優。これらには、適切なプロキシとインフラストラクチャがアプリケーションノードに対してアクティブ化されるように投資するのに時間がかかりますが、すべての主要な監視およびセキュリティプラットフォームがARM64をプラットフォームとしてサポートするようになるため、アプリケーションの内部作業を見ることができないことを保証します。 。実際、サービスとしての最大の観測可能性ソフトウェアプラットフォームの多くは、アプリケーションプラットフォームをAmpereおよびその他のARM64プラットフォームにますます移行して、プラットフォームが提供するコスト削減を活用しています。

ボトムラインを改善します

クラウドネイティブプロセッサへの移行は膨大である可能性があり、移行投資は努力する価値があります。このアプローチを使用すると、組織が時間の経過とともに期待できる運用貯蓄を評価および検証することもできます。

パフォーマンスの向上に対する最大の障害の1つは、慣性であり、組織が最も効率的または費用対効果の高い方法でなくても、組織が行ってきたことを続ける傾向であることに注意してください。そのため、クラウドネイティブテクノロジーの価値を組織に証明するために最初のステップを踏むことをお勧めします。このようにして、利害関係者と共有するための実際の結果が得られ、クラウドネイティブコンピューティングが大幅な投資やリスクなしにアプリケーションのパフォーマンスと応答性を改善する方法を示します。

クラウドネイティブプロセッサが登場しました。問題は、クラウドネイティブに切り替えるかどうかではなく、変換するときです。以前に未来を受け入れる組織は、今日から恩恵を受けるでしょう。

クラウドアプリケーションを設計、構築、展開するためのリソースが含まれるAmpere Developer Centerのクラウドスピードでの開発について詳しく学びます。クラウドネイティブコンピューティングの利点を自分で体験する準備ができたら、Ampere AltraシリーズとAmpereoneテクノロジーに基づいて、CSPにクラウドネイティブのオプションを尋ねてください。

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