アプリ開発のベスト プラクティスを考慮する

  • 5 分

このユニットでは、より優れたパフォーマンス、回復性、セキュリティを確保するのに役立つ、Azure Database for MySQL (フレキシブル サーバー) を使用してアプリを開発するときに適用するいくつかのベスト プラクティスについて確認します。 これらのベスト プラクティスを次に示します。

  • リソースを併置します。
  • 接続プールの実装。
  • 適切なアプリ コンテナー サイズの選択。
  • ネットワークの分離と SSL 接続の実装。
  • 一時的な障害を管理するための再試行ロジックの実装。
  • データベースに適したコンピューティングとストレージ サイズの選択。

これらのベスト プラクティスは、次の図に示すように、Azure Database for MySQL - フレキシブル サーバーを使用したアプリ開発プロセスのさまざまな時点で有用になります。

アプリ開発で従うべき 6 つの主要なベスト プラクティスを示す図。

Note

このベスト プラクティスの一覧は完全なものではありません。 ネットワーク、セキュリティ、監視、パフォーマンスの最適化、事業継続とディザスター リカバリーなどに関連するベスト プラクティスの実装に関する詳細なガイドについては、Azure Database for MySQL ドキュメントを必ず参照してください。

リソースを併置する

アプリを Azure にデプロイするときは、すべてのリソースの依存関係が同じリージョンでホストされていることを確認します。 リソース インスタンスをリージョンまたは可用性ゾーンに分散すると、ネットワーク待機時間が発生し、アプリの全体的なパフォーマンスに影響を与える可能性があります。

接続プールを実装する

アプリ内でデータベース接続を管理すると、アプリ全体のパフォーマンスに大きな影響を与える可能性があります。 アプリのパフォーマンスと回復性を向上させるために、MySQL フレキシブル サーバーに接続するための接続プールの実装を検討してください。 接続プーラー (ProxySQL など) では、アイドル状態の接続の数を減らしたり、既存の接続を再利用したりできます。

ヒント

パフォーマンスを最適化するには、主要なコード パスで、接続が確立される回数と、接続の確立にかかる時間を削減します。

適切なアプリ コンテナー サイズを選択する

アプリ コンテナーに適切なサイズを選択することが重要であるため、予想される負荷を処理するのに十分なコンピューティング リソースとメモリ リソースがアプリにあることを確認します。 JMeter などのツールを使用してロード テストを支援できます。これは、結果に基づいてリソースのサイズを正しく設定するのに役立ちます。

ネットワーク分離と SSL 接続を実装する

VNet 統合 (プライベート アクセス接続方法) を備えた Azure Database for MySQL - フレキシブル サーバーは、ネットワークのセキュリティと分離を提供します。 VNet 統合を使用すると、サーバー アクセスを仮想ネットワーク (VNet) インフラストラクチャのみにロック ダウンできます。 プライベート エンドポイントでは、プライベート ネットワーク経由でフレキシブル サーバーに安全に接続できるため、このセキュリティが強化され、パブリック インターネットへの露出を回避できます。 単一の VNet 内で、あるいは同じまたは異なるリージョン内の異なる VNet 間 (仮想ネットワーク ピアリングでシームレスに接続) でアプリとデータベースのリソースをセキュリティで保護できます。

また、アプリが Secure Sockets Layer (SSL) を使用して MySQL フレキシブル サーバーに接続するようにして、転送中のデータをセキュリティで保護することもお勧めします。

再試行ロジックを実装して一時的な障害を管理する

クラウド環境では、ネットワーク接続の中断やサービスのタイムアウトなどの一時的な障害が発生する可能性が高いため、これらの問題に対処するロジックをアプリに実装する必要があります。通常は要求を遅らせて再試行します。

最初に再試行する前に、5 秒間待つことをお勧めします。 その後、再試行するたびに、待機時間を段階的に増やしていきます (最長 60 秒)。 一定回数再試行した後、アプリはその処理を失敗と見なしてユーザーに通知し、ユーザーが永続的なエラーをさらに調査できるようにします。

データベースに適したコンピューティングとストレージのサイズを選択する

ワークロードを分析し、アプリのパフォーマンスとコストの間で許容できるバランスを達成するために、MySQL フレキシブル サーバー インスタンスのサイズを正しく設定することが重要です。

Compute

MySQL フレキシブル サーバーは、次の 3 つのコンピューティング レベルのいずれかで作成できます。バースト可能、General Purpose、Business Critical。 コンピューティング レベルを選択する開始点として、次の表の詳細を検討してください。

コンピューティング レベル 対象のワークロード
バースト可能 CPU を継続的にフルに使用する必要がないワークロードに最適です。 小規模な Web アプリや開発ワークロードに対してコスト効率が高くなります。
汎用 バランスの取れたコンピューティングとメモリ、およびスケーラブルな I/O スループットを必要とするほとんどのビジネス ワークロードに最適です。 例としては、Web およびモバイル アプリ、他のエンタープライズ アプリをホストするサーバーが挙げられます。
Business Critical 高速なトランザクション処理と高いコンカレンシーのためにインメモリ パフォーマンスを必要とする、高パフォーマンスのデータベース ワークロードに最適です。 たとえば、リアルタイム データと高パフォーマンスなトランザクション アプリや分析アプリを処理するためのサーバーが挙げられます。

MySQL フレキシブル サーバーの作成後にサイズを変更することもできますが、スケールアップまたはダウンできるのは、General Purpose と Business Critical レベルの間のみです。

Storage

ストレージに関しては、ストレージ容量の制限に近づいているときにスケールアップできます。 また、ストレージの上限に近づいたときに、確実にサービスによってストレージが自動的にスケーリングされるように、ストレージの自動拡張機能を有効にすることもできます。

コンピューティングとストレージに関する情報に基づいた意思決定をタイムリーに行うには、ホスト CPU 使用率、ホスト メモリ率、ストレージ使用率、IO 使用率、アクティブな接続などの主要な Azure Monitor メトリックを常に監視するか、ソリューションがデプロイの制限に近づいたときに通知するアラートを設定します。

最適なパフォーマンスを得るために IOPS を調整する

Azure Database for MySQL - フレキシブル サーバーで使用できる大幅な機能強化は、自動スケーリング IOPS (1 秒あたりの入出力操作) 機能であり、既存の事前プロビジョニングされた IOPS 機能を補完します。 このセクションでは、事前プロビジョニングされた IOPS および自動スケーリング IOP オプションを使用して、さまざまなワークロード要件に基づいてデータベースのパフォーマンスを最適化する方法について説明します。

事前プロビジョニングされた IOPS

事前プロビジョニングされた IOPS を使用して、特定の数の IOPS をデータベース インスタンスに割り当てることができます。 この機能は、一貫性のある予測可能なパフォーマンスを必要とするワークロードにとって非常に重要です。 定義済みの IOPS 制限を設定することで、データベースが 1 秒あたり一定数の要求を処理できるようになり、安定した信頼性の高いパフォーマンスを維持できます。 また、ワークロードの変化に応じてプロビジョニングされる IOPS の数を柔軟に調整できるため、データベースのパフォーマンスについて、スケーラビリティと正確な制御の両方が可能になります。

IOPS の自動スケーリング

自動スケーリング IOPS は、変動するワークロードを効果的に管理するために不可欠な機能である、動的なパフォーマンス スケーリングを実現します。 この機能を有効にすると、データベース サーバーは事前プロビジョニングを必要とせずに、リアルタイムの需要に基づいて IOPS を自動的に調整します。 この柔軟性は、パフォーマンスのニーズが変動する可能性があるレベル 1 のミッション クリティカルなアプリにとって特に有益です。

自動スケーリング IOPS 機能を使用する主な利点は次のとおりです。

  • 動的スケーリング:自動スケーリング IOPS 機能は、実際のワークロードの需要に基づいて IOPS 制限を自動的に調整します。 この動的な調整により、データベースが人手を介さずに、最適なパフォーマンス レベルで一貫して動作するようになります。

  • ワークロードの急増に対応する:この機能により、データベースは負荷の急激な増加をシームレスに処理できるようになり、ピーク期間中もアプリのパフォーマンスが一定に保たれるようになります。 この機能は、サービスの可用性とユーザーの満足度を維持するために非常に重要です。

  • コスト効率:実際の使用量に関係なく、指定された上限分の料金を支払う事前プロビジョニングされた IOPS とは異なり、自動スケーリング IOPS では、実際に使用した I/O 操作に対してのみ料金が発生します。 これにより、特に I/O のニーズが変動するデータベースの場合、コストが大幅に削減される可能性があります。

  • 管理の簡素化:自動スケーリング IOPS は手動によるスケーリングと容量計画の必要性を減らすことで管理リソースを解放し、チームが日常的なメンテナンスではなく、より戦略的なイニシアティブに集中できるようにします。