アプリケーションをスケーラブルにする
- 8 分
拡張の準備の基本を理解し、容量計画で考慮すべき要素を認識できたので、アプリケーションを可能な限りスケーラブルにするという課題に取り組むことができます。
アーキテクチャのレビュー
覚えておくべき重要なポイントは、システムの定期的なアーキテクチャ レビューを実行する必要があるということです。
クラウド リソースのデプロイ方法を改善するために、コードとしてのインフラストラクチャなどのプラクティスを適用できることはわかっています。 アプリケーション コードは定期的に更新して改善します。基になるプラットフォーム リソースでも同じ操作を行う必要があります。
アーキテクチャ レビューを実行すると、改善が必要な領域を特定するのに役立ちます。
Azure アーキテクチャ センターには、クラウドでアプリケーションを設計するのに役立つ豊富なリソースが用意されており、アプリケーション アーキテクチャ ガイドの次のリンクにある多くのスケーラビリティに関する推奨事項があります。
シナリオ: Tailwind Traders のアーキテクチャ
最初のステップは、アーキテクチャとアプリケーションの評価を行い、その弱点がどこにあるかを判断するだけでなく、その強みも見極めることです。 何が良いですか?
前のユニットで確認したシナリオをもう一度見てみましょう。 組織のアーキテクチャの図をもう一度次に示します。
アプリケーションをより小さなマイクロサービスに分解し、これらのサービスの一部が Azure Kubernetes Service 上のコンテナーとして配置されているか、VM または App Service で実行されている可能性があります。 Functions や Logic Apps など 、本質的にスケーラブルな サービスを使用しています。
この変更は適切ですが、アプリケーションのスケーラビリティを向上させるいくつかの機能強化があります。 例として、Products サービスに注目します。 この図では、製品サービスは Kubernetes で実行されていますが、この説明では、Azure の VM で実行されていることを前提としています。 スケーリングの概念は、実装が若干異なる場合があります。アプリケーションは、サーバー、App Service、またはコンテナーで実行されているかどうかにかかわらず、アプリケーションに適用できます。
この製品は現在、単一の Azure SQL データベースに接続された 1 つの VM で実行されています。 スケールアウトするには、この VM を有効にする必要があります。これを行うには、Azure 仮想マシン スケール セットを使用します。これにより、同一の負荷分散された VM のグループを作成および管理できます。 複数の VM が作成されたので、VM 間でトラフィックを分散するためにロード バランサーを導入する必要があります。
Virtual Machine Scale Sets
単一の VM に仮想マシン スケール セットを適用すると、いくつかの利点が得られます。
- ホスト メトリック、ゲスト内メトリック、アプリケーションの分析情報、またはスケジュールに基づいて自動スケーリングできます。
- Azure リージョン内の独立したスタンドアロン データセンターである Availability Zones (AZ) を使用できます。 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 製品の一部であり、pub/sub とより高度な統合パターンを提供します。
- Azure Storage キュー Azure Storage 上に構築された単純な REST ベースのキュー インターフェイス。 信頼性の高い永続的なメッセージングを提供します。
このシナリオの要件は単純であるため、Azure Storage キューを使用できます。 このバックグラウンド タスクを切り離したため、製品レベルをスケーリングする必要はありません。
メモリ内キャッシュ
アプリケーションのパフォーマンスを向上させるもう 1 つの方法は、メモリ内キャッシュを実装することです。
これで、パフォーマンスがスケーラビリティと正確に等しくないことがわかりますが、アプリケーションのパフォーマンスを向上させることで、他のリソースの負荷を軽減できます。 この改善は、すぐにスケーリングする必要がない可能性があることを意味します。
Azure Cache for Redis は、マネージド Redis オファリングです。 Redis は、多くのパターンやユース ケースに使用できます。 このシナリオの製品サービスでは、キャッシュ アサイド パターンを実装する可能性があります。 このパターンでは、必要に応じてデータベースからキャッシュに項目を読み込み、アプリケーションのパフォーマンスを向上させ、データベースの負荷を軽減します。
Redis は、Web コンテンツのキャッシュやユーザー セッション キャッシュのメッセージング キューとしても使用できます。 この種類のキャッシュは、ショッピング カート サービスなど、システム内の他のサービスに適している場合があります。このサービスでは、Cookie を使用する代わりに、セッションごとのショッピング カート データを Redis に格納できます。
データベースをスケーリングする
コンピューティング リソースのスケーラビリティを高めたので、データベースを見てみましょう。 このシナリオでは、Azure のマネージド SQL サーバー オファリングである Azure SQL データベースを使用しています。
リレーショナル データベースは、非リレーショナル データベースよりもスケールアウトが困難です。 データベースをスケーリングするために最初に行うことは、データベースのサイズをスケールアップすることです。 このサイズ変更は、平均ダウンタイムが 4 秒以下で簡単に行うことができます。 Azure SQL で単純な API 呼び出しを使用するか、ポータルのスライダーを使用します。
このサイズ設定が要件を満たしていない場合は、トラフィックの特性によっては、データベースへの読み取りをスケールアウトするのに適している可能性があります。 読み取りトラフィックを読み取りレプリカにルーティングできるようになります。
注
Azure SQL では、Premium レベルまたは Business Critical レベルを使用している場合、読み取りスケールアウトは既定で有効になっています。 Basic レベルまたは Standard レベルでは有効にできません。
この変更はコードで実装する必要があります。 その方法を次に示します。
#Azure SQL Connection String
#Master Connection String
ApplicationIntent=ReadWrite
#Read Replica Connection String
ApplicationIntent=ReadOnly
#Full Example
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;
データベース接続文字列の ApplicationIntent 属性を更新して、接続先のサーバーを指定します。 レプリカに接続する場合は ReadOnly 、マスターに接続する場合は ReadWrite を使用します。
このコマンドはコードで実装する必要があるため、状況に適したソリューションではない可能性があります。 すべての製品サービスで読み取りと書き込みの機能が必要な場合はどうなりますか?
その場合は、シャーディングを使用して SQL DB をスケールアウトする方法を見ることができます。
データベース シャーディング
読み取りレプリカをスケールアップまたは実装した後も、データベース リソースがシステムのニーズを満たしていない場合、次のオプションは シャーディングです。
シャーディングは、同じ構造の大量のデータを多数の独立したデータベースに分散させる手法です。 シャーディングは、さまざまな理由で必要になる場合があります。 例えば次が挙げられます。
- データの総量が大きすぎて、個々のデータベースの制約内に収まらない。
- ワークロード全体のトランザクション スループットが、個々のデータベースの機能を超えています。
- コンプライアンス上の理由から、個別のテナントを異なる物理データベースに配置する必要があります (この要件はスケーリングに関する要件は少なく、シャーディングが使用される別の状況です)。
アプリケーションによって関連するデータが関連するシャードに追加されるため、個々のデータベースの制約を超えてシステムがスケーラブルになります。
Azure SQL には、Azure Elastic Database ツールが用意されています。 これらのツールは、アプリケーション ロジックから Azure でシャード化された SQL データベースの作成、保守、クエリを行うのに役立ちます。