Azure Database for MySQL

• 10 分

このユニットでは、回復性があり、高パフォーマンスでメンテナンスが容易な Web ベースのアプリ用データ ストアを構築するために、Azure Database for MySQL がどのように役立つかについて確認します。 あなたは、ビジネスの重要度と高い需要が予想されることを考慮して、コンピューティングとストレージのリソースをスケーリングする機能に関心があります。 また、管理サービスとして Azure Database for MySQL を使用して確実に、管理とメンテナンスのオーバーヘッドを最小限に抑え、ソフトウェア開発に集中できるようにしたいとも考えています。

Azure Database for MySQL のコア特性

Azure Database for MySQL - フレキシブル サーバーは、既存の MySQL アプリケーションとの完全な互換性を提供するように設計されており、広く使用されている MySQL Community Server バージョン 5.7 および 8.0 をサポートしています。 このホスティング オプションは、以下を必要とするシナリオで特に有効です。

• コンピューティングとストレージの構成のきめ細かな制御。
• 一貫したハイ パフォーマンス。
• 信頼性、高可用性、ビジネス継続性。
• 効率的なコスト管理戦略。

さらに、フレキシブル サーバーは、パブリック エンドポイント用の組み込みファイアウォールでセキュリティを強化し、Azure Virtual Network (仮想ネットワーク) 統合と Azure Private Link を介したプライベート接続をサポートして、未承認アクセスからデータを保護します。

Compute

Azure Database for MySQL フレキシブル サーバーは、次の 3 つのコンピューティング層で使用できます。各層は特定のユース ケースに合わせて設計されています。

• バースト可能: 断続的なパフォーマンス要求がある開発または一時的なプロジェクトに最適です。
• General Purpose: バランスの取れたコンピューティングとメモリを必要とする幅広い運用ワークロードに適しています。
• Business Critical: 高いコンピューティング パフォーマンスと回復力を必要とするアプリケーションに最適です。

各層の名前は、マネージド MySQL サーバー デプロイをホストする Azure VM Stock Keeping Unit (SKU) のシリーズ名に由来しています。 各層では、複数の異なる VM サイズから選択できます。各 VM サイズは、異なる数の仮想コア (1 から 96) とメモリ量 (4 ギガバイト (GB) から約 700 GB) を提供します。

バースト可能コンピューティング層では B シリーズの VM が使用され、General Purpose は Dadsv5 シリーズ (AMD) および Ddsv4 シリーズ (Intel) VM に依存し、Business Critical は Standard Eadsv5 シリーズ (AMD) および Edsv5 シリーズ (Intel) VM で実行されます。

Azure portal では、サーバー作成プロセス中に、[基本] ページの [サーバーの詳細] の下、または [フレキシブル サーバーのコンピューティングとストレージ] ページの [コンピューティング] の下で、層オプションを選択できます。

Storage

サーバーのプロビジョニング中、またはその後の任意の時点で、割り当てられるストレージの量を、バースト可能層と General Purpose 層の場合は最大 16,384 ギビバイト (GiB) または 16 テビバイト (TiB)、Business Critical 層の場合は 32 TiB まで増加することができます。 下限 (20 GiB) は、選択したコンピューティング層とサイズに関係なく同じです。 さらに、ストレージのサイズ設定は、選択したコンピューティング層やサイズと無関係であり、ストレージの自動拡張を有効にすることもできます。

また、1 秒あたりの入出力処理 (IOPS) の上限は、ストレージ サイズに関係なく、希望どおりにスケールアップとスケールダウンすることができます。 使用可能な IOPS の上限は、コンピューティング層とサイズによって異なり、Business Critical SKU の使用可能な最大サイズでは、80,000 IOPS に達します。 このスケーラブルな IOPS 機能を使用すると、動的に変化するリソース要件にいつでも対応できるだけでなく、自動スケーリング IOPS を有効にしてワークロードの需要に基づいて自動的に調整することもできます。

ネットワーク接続

Azure Database for MySQL - フレキシブル サーバーでは、パブリック アクセス、プライベート アクセス、プライベート リンクの 3 つの接続方法がサポートされています。

パブリック アクセス

外部エンドポイント経由で提供されるパブリック アクセスでは、ファイアウォール規則を使用してアクセスを明示的に許可する必要があります。

• 外部トラフィックの場合、トラフィックを許可する個々の IP アドレスまたは IP アドレス範囲を指定する必要があります。
• Azure から送信されるトラフィックの場合、任意の Azure サービスからのパブリック アクセスを許可する必要があります。

プライベート アクセス

指定された Azure 仮想ネットワーク経由のプライベート アクセスには、仮想ネットワーク統合サポートを使用します。 プライベート アクセスを使用すると、同じ VNet 内から、またはピアリングを使って別の VNet から、さらには ExpressRoute または VPN 接続を使用してオンプレミスから MySQL フレキシブル サーバーに安全に接続できます。 このオプションを有効にすると、インターネットからの接続はサーバーによって自動的にブロックされます。

プライベート アクセスを有効にする前に、カスタム ドメイン ネーム サービス (DNS) の名前解決を実装する必要があります。 詳細については、「Azure Database for MySQL - フレキシブル サーバーの仮想ネットワーク統合を使用したプライベート ネットワーク アクセス」を参照してください。

プライベート リンク

プライベート リンクでは、MySQL フレキシブル サーバーに直接接続するための VNet サブネット内のプライベート IP アドレス エンドポイントが提供されます。 Azure Private Link では基本的に、他の VNet リソースと同様に IP アドレスを介してプライベート VNet 内に Azure サービスが提供されます。 複数のプライベート エンドポイントを作成できます (たとえば、接続しているアプリケーションまたは Azure PaaS リソースごとに 1 つ)。 NSG ファイアウォール規則と組み合わせることで、プライベート リンクでは、データベースにアクセスできるサービスをきめ細かく制御できます。

既定では、サーバーは、受信ネットワーク通信を保護するためにトランスポート層セキュリティ (TLS 1.2) を適用します。

高可用性

Azure Database for MySQL - フレキシブル サーバーは、自動フェールオーバーによる高可用性をサポートして、コミットされたデータが局所的な障害によって失われないようにします。 この機能を有効にすると、プラットフォームによってスタンバイ レプリカが自動的にプロビジョニングされて管理されます。

レプリカの配置に応じて、次の 2 つの高可用アーキテクチャ モデルがあります。

ゾーン冗長高可用性

回復性を強化するために、ゾーン冗長高可用性モデルでは、プライマリ データベースを 1 つの可用性ゾーンに配置し、そのスタンバイ レプリカを別のゾーンに配置します。 この構成は、データ センター レベルの障害から保護するように設計されており、プライマリ データベースとバックアップ データベースが同じ局所的なリスクに確実にさらされないようにして、より高いレベルのデータ保護を提供します。 このモデルは、データセンター全体がオフラインになった場合でもサービスが利用可能な状態を保つことを可能にするため、継続性とデータ整合性が最も重要な目標となるクリティカル アプリケーションに推奨されます。

同一ゾーンの高可用性

同一ゾーン高可用性モデルでは、プライマリ データベースとそのスタンバイ レプリカが同じ可用性ゾーン内に配置されます。 アプリケーションのパフォーマンスにとって待機時間を最小限に抑えることが重要なシナリオでは、同一ゾーンへのデプロイを選択すると効果的です。 プライマリ インスタンスとそのレプリカの両方を物理的に近接している場所に保持すると、フェールオーバー プロセスが応答時間に大きな影響を与えないようにすることができます。 この設定は、待機時間の僅かな違いによる影響を受けて機能やユーザー エクスペリエンスに影響が出る可能性があるアプリケーションに最適です。

ビジネス継続性

Azure Database for MySQL - フレキシブル サーバーを使用すると、データベースの特定の時点のバックアップが自動的に作成されます。 これらのバックアップは、最大 35 日間、または長期保有を使用する場合は最大 10 年間、ローカル冗長ストレージに保持されます。 バックアップを構成する場合、ローカル冗長、ゾーン冗長、または geo 冗長のバックアップを選択できるため、Azure リージョン全体に影響する停止から復旧できます。 さらに、オンデマンド バックアップをいつでも実行して、定期的なバックアップ スケジュール以外のバックアップ スナップショットを作成することもできます。

Azure Database for MySQL では、サーバーのパッチ適用の自動化を目的としたマネージド メンテナンス期間もサポートされており、ビジネス継続性が促進されます。 カスタム パッチ適用スケジュールを指定することで、サーバーの再起動による一時的なダウンタイムの影響を最小限に抑えることができます。

コストの最適化

Azure Database for MySQL - フレキシブル サーバーには、コストを最適化するためのさまざまなオプションが用意されています。

• コンピューティングとストレージの構成のきめ細かな制御。 サーバー構成オプションの大半は独立して構成できるため、目的や、その対象とするユース ケースに応じてデプロイ コストを最適化できます。 たとえば、次のオプションを個別に調整できます。

  • コンピューティング SKU
  • ストレージの量
  • IOPS
  • バックアップ保持期間

  さらに、自動スケーリング IOPS 機能を有効にして、ワークロードの需要に基づいて IOPS を自動的に調整することもできます。 固定 IOPS 制限が指定され、使用量に関係なく料金が支払われる事前プロビジョニング IOPS とは異なり、自動スケーリング IOPS では、使用した I/O 操作の数に対してのみ料金を支払います。

• オンデマンドでサーバーを停止および開始する機能。 サーバーを停止するとすぐに、コンピューティング層の課金は停止されます。 この機能は、確実に予測可能なスケジュールによる開発、テスト、運用のワークロード中のコストを最小限に抑えるのに役立ちます。

• バースト可能コンピューティング層。 低い CPU 使用率を必要とし、CPU 使用率のスパイクがときどき発生するワークロードの競争力のある価格を提供するには、バースト可能コンピューティング層を利用します。

• 予約 VM インスタンスの割引。 1 年間または 3 年間の購入プランにコミットすることで、予約インスタンスの割引が適用され、割引前の元のコストの 60% 以上を節約できます。 予測可能な長期的なコンピューティング容量要件を持つ運用ワークロードについては、このオプションを検討してください。

• Azure 無料アカウント。 Azure 無料アカウントを使用すると、12 か月間無料でフレキシブル サーバーを評価できます。月単位の上限は次のとおりです。

  • Burstable B1MS インスタンスを 750 時間。これは、データベース インスタンスを毎月十分に継続実行できるだけの時間です。
  • 32 GB のストレージと 32 GB のバックアップ ストレージ。