一般的なガイドラインとベスト プラクティス

  • [アーティクル]

名前付け規則

Azure でサービスの名前を選択することは、次の理由で重要です。

  • 後で名前を変更することは困難です。
  • 名前は特定のリソースの種類の要件を満たしている必要があります。

一貫した名前付け規則によって、サービスが見つけやすくなります。 これらは、ソリューションにおけるサービスの役割を示すこともできます。

Azure サービスの名前付け規則と制限事項、および名前付け規則の推奨事項のベースライン セットをまとめている名前付け規則に関する記事をご覧ください。

リソース グループ

Azure では、すべてのリソースがリソース管理グループに割り当てられます。 リソース グループでは、リソースの論理グループが提供されます。これにより、リソース グループをコレクションとして簡単に操作できるようになるため、有効期間、所有者、その他の条件によって管理できます。

詳細と情報については、リソース グループの管理に関するページをご覧ください。

Azure Storage リージョン

さまざまなストレージ リソースの入力と出力が異なるリージョンにある場合は、リージョン間でのデータの移動に対して課金されます。 詳しくは、「帯域幅の料金詳細」をご覧ください。 アウトバウンド データ転送を回避するには、同じリージョンにある Azure サービスをペアリングします。

ヒント

大多数のユーザーに最も近いリージョンを使用するようにしてください。

セキュリティ

Azure でクラウド ソリューションを設計、デプロイ、管理する場合は、こちらのセキュリティのベスト プラクティスのコレクションをご覧ください。 これらのベスト プラクティスは、Microsoft が Azure について得た経験と、あなたのような開発者の経験からもたらされたものです。

ホワイト ペーパーの各セクションは、次のように個別の記事として公開されています。

セキュリティに関するその他のベスト プラクティスについては、「Azure セキュリティのベスト プラクティスとパターン」をご覧ください。

Azure DDoS Protection: ベスト プラクティスとリファレンス アーキテクチャに関するドキュメントもご確認ください。

プライバシー

プライバシーに関する責任のフットプリントを削減するために、ユーザーのデータを保存するサービスのいくつかによって提供される機能を活用します。

  • Azure Cosmos DB TTL (Time To Live) を使用し、保存されたドキュメントがパージされるまでの期間を設定して、Azure Cosmos DB に自動的に保存された古いデータを失効させることができます。
  • Azure Blob Storage ライフサイクル管理ポリシーを使用して、ライフサイクルの終わりに BLOB を削除できます。

Azure Resource Manager

Azure Resource Manager を活用して、Azure サブスクリプションのリソースを作成、更新、削除します。 問題が発生している場合は、「Azure Resource Manager を使用した Azure へのデプロイで発生する一般的なエラーのトラブルシューティング」と「リソース プロバイダーの登録エラーの解決」をご覧ください。

Azure Event Hub パーティション

パーティションの数を作成後に変更することはできません。 運用環境を対象とすることを計画しており、多数のユーザーからイベントを受け取る可能性があるため、負荷テストとデータ消費量によって裏付けられる事前計算を実行して、必要なパーティションの正確な数を調べる必要があります。

Azure Event Hubs での世界規模のテレメトリ プラットフォームの設計とサイジングに関する詳細なビデオ ガイドについては、こちらのビデオをご覧ください。

1 スループット ユニット (以後、TU) は、1 MB/秒または 1000 メッセージ/秒のうち最初に発生した方と等しくなります。 TU に対して課金されるので、コストを調整するために負荷要件に従って TU を変更できます。

各パーティションは、1 MB/秒または 1000 メッセージ/秒のうち最初に発生した方によって限界に達します。 パーティションの数を決定するには、次の原則を考慮してください。

  • パーティションは高可用性を提供します。 Event Hub にメッセージを送信し、送信を成功させたい場合は、複数のパーティションを作成し、EventHubClient.Send を使用して送信する必要があります。
  • パーティションの数によって、Event Hub パイプの幅と、メッセージを受信して処理できる速度が決まります。 Azure Event Hub に 16 個のパーティションがある場合、容量は 16 TU で限界に達します。 たとえるなら、パーティションは高速道路の車線に相当します。
  • TU は、名前空間レベルで構成されます。 また、1 つの Event Hubs 名前空間に複数の Azure Event Hub を含めることもできます。 各 Azure Event Hub では異なる数のパーティションを使用できます。

パーティションの数よりも多くの TU を利用することはできません。3 つのパーティションがある場合、3 つを超える TU を使用することはできません。 次の理由から、通常は TU よりも多くのパーティションを使用します。

  • トラフィックが増加した場合は TU の数を増やすことができますが、パーティションの数を変更することはできません。
  • パーティションの数よりも多くのリーダーを同時に使用することはできません。 10 個のリーダーを同時に使用する場合は、10 個のパーティションが必要です。

ヒント

推奨されるパスは、ソリューションの開発中に、1 TU から始めてパーティション数をモデル化することです。 これが完了したら、プライベート ベータで負荷テストを実行するときに、TU を増やして負荷を調整します。 同じ Event Hub 名前空間に複数の Azure Event Hub を含められることを思い出してください。 したがって、Azure Event Hub の名前空間レベルの 20 TU と、それぞれ 4 つのパーティションを持つ 10 個の Event Hub は、Azure Event Hub の名前空間全体で 20 MBPS を提供します。

Azure Cosmos DB

Azure Cosmos DB リソースは、プロビジョニングされたスループットとストレージに基づいて課金されます。 Azure Cosmos DB のスループットは、1 秒あたりの要求ユニット (以後、RU/秒) で表されます。

予測可能なパフォーマンスを提供するには、100 RU/秒の単位でスループットを確保する必要があります。 Azure Cosmos DB の要求ユニット計算機を使用して、スループットのニーズを見積もることができます。

ヒント

経験則/ベスト プラクティスとして、最大 RU 数は、最小/安定した状態のスループットの 20 倍を超えないようにする必要があります。

  • 初期プロビジョニングされたスループットは瞬時に 2 倍に増やすことができます。 任意のスループット値を非同期的に 1M まで (サポート チケットを使用すると、それより多く) 増やすことができます。
  • 初期プロビジョニングされたスループットは瞬時に 10 分の 1 に減らすことができます (合計範囲は 20 倍)。 ただし、場合によっては、この範囲を超えて減らすことができます。

詳しくは、「Azure Cosmos のコンテナーとデータベースのスループットのプロビジョニング」をご覧ください。

Azure Storage アカウントの制限事項

Azure Storage には、Azure サブスクリプション サービスの制限に関するページに記載されている一定の制限があります。

ゲームのニーズが 1 つのストレージ アカウントのスケーラビリティ ターゲットを超える場合は、複数のストレージ アカウントを使用するようにアプリケーションを構築できます。 次に、これらのストレージ アカウント全体にデータ オブジェクトをパーティション分割できます。

Azure Storage Explorer

Azure Storage Explorer は、Azure Storage リソースをとても簡単に管理するために使用できるツールです。 BLOB、ファイル、キュー、テーブル、Azure Cosmos DB エンティティをアップロード、ダウンロード、管理します。 仮想マシンのディスクを管理するためのアクセス権を簡単に取得できます。 Windows、MacOS、Linux がサポートされます。

Azure Stream Analytics ユニット

特定のジョブについて必要なストリーミング ユニット (以後、SU) の数の選択は、入力のパーティション構成およびジョブ内で定義されているクエリに基づいて行います。 必要な数より多くの SU を割り当てることをお勧めします。 Azure Stream Analytics 処理エンジンでは、追加のメモリの割り当てコストと引き換えに遅延とスループットが最適化されます。

一般に、PARTITION BY を使用しないクエリでは 6 SU から開始し、典型的な量のデータを渡して SU の使用率メトリックを確認した後で SU の数を変更する試行錯誤方式を使用してスイート スポットを特定します。 Stream Analytics ジョブで使用できるストリーミング ユニットの最大数は、ジョブに定義されたクエリのステップ数と各ステップのパーティション数によって異なります。 制限事項について詳しくは、こちらをご覧ください。

適切な SU 数の選択について詳しくは、「スループット向上のために Azure Stream Analytics ジョブをスケーリングする」のページをご覧ください。

注意

特定のジョブに必要な SU 数の選択は、入力のパーティション構成と、ジョブに定義されたクエリによって異なります。 ジョブに対する SU のクォータまでを選択できます。 既定では、各 Azure サブスクリプションには、特定のリージョンにあるすべての分析ジョブに対して最大 200 SU のクォータがあります。 このクォータを超えてサブスクリプションの SU を増やすには、Microsoft サポートにお問い合わせいただく必要があります。 ジョブあたりの SU の有効値は、1、3、6、およびそれ以上の 6 の倍数です。

また、Azure Stream Analytics では、可変サイズのバッチを使用してイベントが処理され、出力に書き込まれます。 通常、Azure Stream Analytics エンジンでは、一度に 1 つのメッセージを書き込むことはなく、効率を高めるためにバッチが使用されます。 入力方向と出力方向の両方でイベント レートが高い場合は、大きなバッチが使用されます。 エグレス レートが低い場合は、遅延時間を低く抑えるために小さいバッチが使用されます。 出力バッチに対する Azure Stream Analytics の考慮事項の一部を説明している「出力バッチ サイズ」ページをご覧ください。

Azure Database for MySQL

Azure Database for MySQL を使用してクラウドネイティブのゲーム アプリケーションを開発する場合は、再試行ロジックと接続プールが重要なコンポーネントです。 Azure Database for MySQL データベース ゲームは、切断された接続と失敗したトランザクションを検出して再試行するように構築されていることが重要です。 アプリケーションが再試行されると、アプリケーションの接続は新しく作成されたインスタンスに透過的にリダイレクトされ、失敗したインスタンスが引き継がれます。 Azure の内部では、新しいインスタンスに接続をリダイレクトするためにゲートウェイが使用されます。 中断時には、通常、フェールオーバー プロセス全体に数十秒かかります。 リダイレクトはゲートウェイによって内部的に処理されるため、クライアント アプリケーションの外部接続文字列は同じままです。 ほとんどのゲーム アプリケーションには低遅延の要件があるため、Azure Database for MySQL で実行されているゲーム アプリケーションには接続プールを強くお勧めします。 接続プールが存在しない場合、セッションの終了時に接続を開いたり閉じたりすると、追加の遅延オーバーヘッドが発生する可能性があります。 データベースへのアクセス時に接続を適切に使用する方法については、「接続の管理」をご覧ください。

スケールアップまたはスケールダウンに関して、Azure Database for MySQL がスケールアップまたはスケールダウンされると、指定したサイズの新しいサーバー インスタンスが作成されます。 既存のデータ ストレージは元のインスタンスからデタッチされ、新しいインスタンスにアタッチされます。 スケーリング操作中に、データベース接続の中断が発生します。 クライアント アプリケーションは切断され、オープン コミットされていないトランザクションは取り消されます。 クライアント アプリケーションが接続を再試行するか、新しい接続を作成すると、ゲートウェイは新しくサイズ設定されたインスタンスに接続を転送します。 詳しくは、「リソースのスケール」をご覧ください。

次のリンクでは、容量、ストレージ エンジンのサポート、権限のサポート、データ操作ステートメントのサポート、およびデータベース サービスの機能に関する制限事項について説明します。

空きストレージの量が、5 GB またはプロビジョニングされたストレージの 5% を下回るとサーバーは読み取り専用としてマークされることに注意してください。サーバー ストレージがしきい値に近づいたときに通知するようにアラートを設定し、読み取り専用状態にならないようにすることをお勧めします。 詳しくは、アラートの設定方法に関するドキュメントをご覧ください。

Azure Container Instances

一般に、Windows コンテナーはスピンアップと読み込みに時間がかかる重いデプロイ イメージであることが多いため、Azure Container Instances では Windows ではなく Linux を使用することをお勧めします。 また、Linux には、仮想ネットワークなど、Windows では現在サポートされていない Azure Container Instances の追加の機能セットもあります。