開発者とともにクラウドでのアプリケーションのスケーラビリティをマスターする

クラウド コンピューティングが無限に拡張できるからといって、アプリケーション内のすべてのコンポーネントが拡張できるわけではありません。オペレーターが設計とテストに関与していない場合、チームはコストを無駄にし、アプリケーションのパフォーマンスが低下するリスクがあります。

アプリケーションが本番環境に移行する頃には、スケーラビリティの問題を修正するには遅すぎます。代わりに、開発と運用のパートナーシップと統合テストに重点を置いてください。

[[229342]]

クラウド コンピューティングのスケーラビリティにより、ユーザーは負荷の増加に応じてリソースの消費量を拡大できますが、普遍的なリソースの増加だけでは不十分です。アプリケーションのすべてのコンポーネントが同じ乗算演算を必要とするわけではなく、それらのスケーリングによって負荷のかかったコンポーネントに悪影響が出ることはありません。スマート スケーリングでは、過負荷のアプリケーション コンポーネントをサポートするリソースのみが追加されます。運用チームは、設計プロセスの早い段階でアプリケーションのスケーラビリティについて開発者とコミュニケーションを取り、コンポーネントをいつどのように開始するかを決定する必要があります。これらのチームは統合テストを通じて連携し、需要に応じて拡張してもアプリケーションのパフォーマンスと信頼性が維持されるようにする必要があります。

アプリケーションのスケーラビリティは難しい問題です

この例は、拡張リソースで発生する可能性がある問題を示しています。異なる支店の 2 人の作業者が、何かを販売するためにほぼ同時にトランザクションを開始します。トランザクション サービスは、在庫を確認し、製品を販売し、注文を入力します。クラウドでは、同じアプリケーションの 2 つのインスタンスが 2 人のワーカーをサポートします。各インスタンスは在庫をチェックして製品と注文を見つけますが、2 番目のケースでは、その在庫レベルは最初の注文が処理中であるという事実を反映していません。

弾性スケーリングにより、予測できない数のアプリケーション コンポーネントのインスタンスが作成され、これらのインスタンスは必ずしも互いを認識しているわけではありません。独立したコンポーネントのスケーリングは、この競合に対する大きな課題をもたらしますが、従来の方法では通常、デュアルまたは N+1 冗長コンポーネントのみが扱われます。クラウド バーストは、コンテナ ホスティング、仮想化、プライベート クラウド ツールによって実現され、クラウドの拡張は、パブリック クラウドの自動スケーリング機能とハイブリッド クラウド マネージャーによって実現されます。バーストとスケーリングを可能にするツールは数百ありますが、これらのツールでは通常、コンポーネントがクラウド バースト プロセスを認識することは想定されていません。

IT 運用チームは、どのワークロードが頻繁にまたは過剰に使用されているか、また需要に対応するためにホスティング リソースを拡張する必要がある場所を追跡しますが、アプリケーション コンポーネントが効果的に拡張できない場合、運用ではアプリケーションのスケーラブルなアーキテクチャを確保できません。 DevOps の信条の 1 つは、アプリケーションの展開と管理に関する開発者の要件を運用上の用語に変換することです。では、クラウド コンピューティング環境における運用要件、つまりスケーラビリティとは何でしょうか?アプリケーションのスケーラビリティとインフラストラクチャの柔軟性に関して、運用部門は開発者にどのような具体的な詳細を提供する必要がありますか?

アプリケーション拡張における開発者の役割

アプリケーション開発者は、ソフトウェアが使用されるコンテキストを理解する必要があります。すべてのトランザクションが競合のリスクにさらされるわけではなく、関連するデータベース要素を更新しようとするサービスのみが競合のリスクにさらされます。一部のアプリケーションでは、特定のトランザクションに関連付けられたすべてのメッセージが同じ処理コンポーネントに送信されることを保証するためにファイアウォールが必要です。機能コンポーネントやマイクロサービスのように動作するために状態制御を必要とするものもあります。コンポーネントシーン認識をスケーリングすると、パフォーマンスと機能の問題も解決できます。

これらは開発者だけが対処できる問題です。 IT 運用では、利用可能なクラウド リソースを拡張してソフトウェア コンポーネントをサポートできますが、アプリケーションのパフォーマンスが向上するという保証はありません。開発者は、アプリケーションのスケーラビリティを設計する方法と、スケーラビリティを必要とするコンポーネントについて知っておく必要があります。予想外または役に立たない拡張機能のサポートを追加すると、開発コストと時間が増加し、アプリケーションのパフォーマンスが低下する可能性があります。これは、コンポーネントが複数のアプリケーション間で共有される場合に特に問題になります。 1 つの開発チームが、同じコンポーネントを使用する他のコンポーネントを必ずしも認識しているわけではありません。

展開範囲と統合テスト

ソフトウェアが実稼働しているときにアプリケーションのスケーラビリティの問題に対処しようとする試みは効果がなく、多くの場合まったく非現実的です。代わりに、開発の早い段階でスケーラビリティの想定に関する運用上のフィードバックを取得し、実稼働に移行する前に検証します。アプリケーション開発サイクルにおいて、最も便利なフェーズは統合テストです。

開発者はさまざまな方法でスケーラブルなアーキテクチャを作成します。たとえば、マイクロサービスとコンテナベースのアーキテクチャでは、当然ながら独立したスケーリングが促進されます。開発者がスケーリングの方法を理解すると、データセンター内、データセンターとクラウド間、クラウド プロバイダー間、またはクラウド プロバイダーのプラットフォーム内で適切なコンポーネントの展開パラメータを決定する方法について IT オペレーターと話し合うことができます。

アプリケーションを拡張する必要があるインフラストラクチャの範囲によって、ネットワーク接続の伝送遅延、新しいインスタンスの起動遅延、およびその他の実際のパフォーマンス要因に対するコンポーネントの影響を受けやすさが決まります。スケーラビリティの開発目標が運用で達成できない場合は、開発計画または展開計画を調整する必要があります。ネットワーク接続、展開のコンプライアンスとガバナンス、さらにはクラウド コンピューティング プロバイダーの選択もすべて変更される可能性があります。

統合テストは、開発者と運用の専門家がコンポーネント化されたアプリケーションに関連する情報の流れを確認し、スケーラビリティがアプリケーションのパフォーマンスと安定性にどのように影響するかを調べる最初の機会です。テスターは個々のアプリケーション コンポーネントを組み合わせて、実際のワークフローでどのように機能するかを評価します。統合テストでは、分離されたアプリケーション コンポーネントのスケーリングの問題だけでなく、より高レベルの問題も明らかになる可能性があります。統合テストは、実際の運用環境の展開を可能な限り忠実に模倣する必要があります。

機能開発者やアプリケーション所有者は、デプロイされたコンポーネントは負荷分散され、ワー​​クフローに接続される必要があることを忘れがちです。運用は、ホスティング リソース、ネットワーク接続、およびその他の考慮事項を最適化する方法でアプリケーションを展開することを目的としていますが、データベースの更新に関しては運用の制御下にありません。アプリケーションが構築されると、管理ツールは変わりません。 *** 展開シナリオが十分でない場合、不適切なアーキテクチャをカバーするためにそれを再作成することはできません。それでは少し遅すぎます。

統合テストを将来の運用システムの実証の場として使用し、そのテスト環境から開発/運用パートナーシップを育成して、アプリケーションが独自に成長する際に発生する課題に対処します。