アプリケーションをスケーラブルにする

拡張の準備の基本を理解し、容量計画で考慮すべき要素を認識できたので、アプリケーションを可能な限りスケーラブルにするという課題に取り組むことができます。

アーキテクチャのレビュー

覚えておくべき重要なポイントは、システムの定期的なアーキテクチャ レビューを実行する必要があるということです。

クラウド リソースのデプロイ方法を改善するために、コードとしてのインフラストラクチャなどのプラクティスを適用できることはわかっています。 アプリケーション コードは定期的に更新して改善します。基になるプラットフォーム リソースでも同じ操作を行う必要があります。

アーキテクチャ レビューを実行すると、改善が必要な領域を特定するのに役立ちます。

Azure アーキテクチャ センターには、クラウドでアプリケーションを設計するのに役立つ豊富なリソースが用意されており、アプリケーション アーキテクチャ ガイドの次のリンクにある多くのスケーラビリティに関する推奨事項があります。

Azure アーキテクチャ センター

シナリオ: Tailwind Traders のアーキテクチャ

最初のステップは、アーキテクチャとアプリケーションの評価を行い、その弱点がどこにあるかを判断するだけでなく、その強みも見極めることです。 何が良いですか?

前のユニットで確認したシナリオをもう一度見てみましょう。 組織のアーキテクチャの図をもう一度次に示します。

アプリケーションをより小さなマイクロサービスに分解し、これらのサービスの一部がAzure Kubernetes Service上のコンテナーとして配置されているか、VM または App Service で実行されている可能性があります。 また、Functions や Logic Apps など 、本質的にスケーラブルな サービスも使用しています。

この変更は適切ですが、アプリケーションのスケーラビリティを向上させるいくつかの機能強化があります。 例として、Products サービスに注目します。 この図では、製品サービスは Kubernetes で実行されていますが、この説明では、Azureの VM で実行されていることを前提としています。 スケーリングの概念は、実装が若干異なる場合があります。アプリケーションは、サーバー、App Service、またはコンテナーで実行されているかどうかにかかわらず、アプリケーションに適用できます。

製品は現在、単一のAzure SQL データベースに接続された単一の VM 上で実行されています。 スケールアウトするには、この VM を有効にする必要があります。これを行うには、Azure仮想マシン スケール セットを使用します。これにより、同一の負荷分散された VM のグループを作成および管理できます。 複数の VM が作成されたので、VM 間でトラフィックを分散するためにロード バランサーを導入する必要があります。

Virtual Machine Scale Sets

単一の VM に仮想マシン スケール セットを適用すると、いくつかの利点が得られます。

• ホスト メトリック、ゲスト内メトリック、アプリケーションの分析情報、またはスケジュールに基づいて自動スケーリングできます。
• Availability Zones (AZ) は、Azure リージョン内の物理的に独立した場所であり、それぞれが 1 つ以上のデータセンターで構成されています。 AZ サポートを使用すると、VM を複数の AZ に分散できるため、アプリケーションの信頼性が向上し、データセンターの障害から保護されます。 スケール セット内の新しいインスタンスは、AZ 間で自動的に均等に分散されます。
• ロード バランサーの追加が簡単になります。 仮想マシン スケール セットでは、基本的なレイヤー 4 トラフィック分散にAzure Load Balancerを使用できます。 また、より高度な L7 トラフィック分散と SSL 終了のためのAzure Application Gatewayもサポートしています。

スケール セットを実装する前に考慮する必要がある重要な要素がいくつかあります。 具体的には：

• 特定のバックエンドにクライアントがスタックしないように、インスタンスの持続性を避けます。
• VM から永続的なデータを削除し、Azure Storageやデータベースなどの別の場所に格納します。
• スケールインを意識した設計。 また、アプリケーションを簡単にスケールダウンできることも重要です。 トラフィックを処理するサーバーのプールに追加されたインスタンスが増えるだけでなく、負荷が低下した場合のインスタンスの突然の終了も適切に処理する必要があります。 スケーリングのスケールダウンの側面は見落とされることが多いです。

分離

スケールセットを使用して、さらに多くの VM を追加しました。 スケールアウトは、"スケーリングする必要がある" という一般的な答えです。ただし、スケールできるメトリックは 1 つだけです。この回答は、製品サービスによって実行されるすべてのタスクに関連しない場合があります。

このシナリオでは、製品サービスにはジョブがあります。製品イメージがアップロードされると、その画像がトランスコードされ、サムネイルやカタログ内の画像などのためにいくつかの異なるサイズで格納されます。 画像処理は CPU を集中的に使用しますが、一般的な使用量はメモリを大量に消費します。

画像処理は、バックグラウンド ジョブに分割できる非同期タスクです。 これを行うには、キューを使用して画像処理サービスを分離します。 切り離すと、両方のサービスを個別にスケーリングでき (1 つはメモリ上で (製品サービス)、もう 1 つは CPU 上またはキュー長に対して (画像処理サービス))、別のスケール セットでそれらのメッセージを使って、画像を処理できます。

キューでのスケーリング

Azureには、次の 2 種類のキュー オファリングがあります。

• Azure Service Bus キュー: より広範な Azure Service Bus 製品に含まれる、より高度なキュー オファリングであり、パブリッシュ/サブスクライブおよびより高度な統合パターンを提供します。
• Azure Storage Queues Azure Storage上に構築された単純な REST ベースのキュー インターフェイス。 信頼性の高い永続的なメッセージングを提供します。

このシナリオの要件は単純であるため、Azure Storage キューを使用できます。 このバックグラウンド タスクを切り離したため、製品レベルをスケーリングする必要はありません。

メモリ内キャッシュ

アプリケーションのパフォーマンスを向上させるもう 1 つの方法は、メモリ内キャッシュを実装することです。

これで、パフォーマンスがスケーラビリティと正確に等しくないことがわかりますが、アプリケーションのパフォーマンスを向上させることで、他のリソースの負荷を軽減できます。 この改善は、すぐにスケーリングする必要がない可能性があることを意味します。

Azure Managed Redis (以前のAzure Cache for Redis) は、マネージド Redis オファリングです。 Redis は、多くのパターンやユース ケースに使用できます。 このシナリオの製品サービスでは、キャッシュ アサイド パターンを実装する可能性があります。 このパターンでは、必要に応じてデータベースからキャッシュに項目を読み込み、アプリケーションのパフォーマンスを向上させ、データベースの負荷を軽減します。

Redis は、メッセージング キュー、Web コンテンツのキャッシュ、またはユーザー セッション キャッシュにも使用できます。 この種類のキャッシュは、ショッピング カート サービスなど、システム内の他のサービスに適している場合があります。このサービスでは、Cookie を使用する代わりに、セッションごとのショッピング カート データを Redis に格納できます。

データベースをスケーリングする

コンピューティング リソースのスケーラビリティを高めたので、データベースを見てみましょう。 このシナリオでは、Azure SQL Databaseを使用しています。これは、Azureのマネージド SQL Server オファリングです。

リレーショナル データベースは、非リレーショナル データベースよりもスケールアウトが困難です。 データベースをスケーリングするために最初に行うことは、データベースのサイズをスケールアップすることです。 このサイズ変更は、Azure SQLで簡単な API 呼び出しを使用するか、ポータルのスライダーを使用して、接続損失の短時間で簡単に行うことができます。

このサイズ設定が要件を満たしていない場合は、トラフィックの特性によっては、読み取りをデータベースにスケールアウトし、読み取りトラフィックを読み取りレプリカにルーティングできる場合があります。

この変更はコードで実装する必要があります。 ルーティングの意図を指定するには、データベース 接続文字列で ApplicationIntent 属性を設定します。 ReadOnlyを使用してレプリカに接続するか、ReadWriteを使用してプライマリに接続します。

推奨される方法は、認証にマネージド ID を使用し、必要な構成をAzure Key Vaultに格納することです。

#Read Replica Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;Encrypt=True;

#Primary Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;Authentication=Active Directory Default;Encrypt=True;

この変更はコードで実装する必要があるため、状況に適したソリューションではない可能性があります。 すべての製品サービスで読み取りと書き込みの機能が必要な場合はどうなりますか?

その場合は、シャーディングを使用してAzure SQL Databaseのスケールアウトを見ることができます。

データベース シャーディング

読み取りレプリカをスケールアップまたは実装した後も、データベース リソースがシステムのニーズを満たしていない場合、次のオプションは シャーディングです。

シャーディングは、同じ構造の大量のデータを多数の独立したデータベースに分散させる手法です。 シャーディングは、さまざまな理由で必要になる場合があります。 例えば次が挙げられます。

• データの総量が大きすぎて、個々のデータベースの制約内に収まらない。
• ワークロード全体のトランザクション スループットが、個々のデータベースの機能を超えています。
• コンプライアンス上の理由から、個別のテナントを異なる物理データベースに配置する必要があります (この要件はスケーリングに関する要件は少なく、シャーディングが使用される別の状況です)。

アプリケーションによって関連するデータが関連するシャードに追加されるため、個々のデータベースの制約を超えてシステムがスケーラブルになります。

Azure SQLには、Azure Elastic Database ツールが用意されています。 これらのツールは、アプリケーション ロジックからAzureでシャード化された SQL データベースの作成、保守、クエリを行うのに役立ちます。