Microsoft Azure のようなクラウドサービスを使ってソリューションを設計する場合、サービスの可用性は自動的に担保されるものだと考えられる人もいるかもしれませんが、複数の Azure サービスを使ってソリューションをくみ上げる場合、組み合わせ方によっては個々のサービスで保証されている可用性 (たとえば 99.9%) を大きく下回ってしまうこともありますので注意が必要です。

注意点には設計の時点からきちんと考えて組み込んでおかないといけない事項、個々のサービスに追加で施せる事項が存在します。それぞれ「可用性チェックリスト」「高可用性チェックリスト」という形で公開されていますので、ご紹介します。

この記事では、項目のみをご紹介します。詳しい説明はそれぞれの記事をご覧ください。

可用性チェックリスト

•  アプリケーションの設計
  • すべての単一障害点を回避します。
  • ワークロードを異なるサービス レベル アグリーメントごとに分解します。
  • サービスの依存関係を最少化し、把握します。
  • 可能な限り、タスクとメッセージがべき等になる (安全に繰り返しできる) ように設計します。
  • 重要なトランザクションの高可用性を実装する、メッセージ ブローカーを使用します。
  • 適切に機能が低下するアプリケーションを設計します。
  • 急速なバースト イベントを適切に処理します。
• 展開と保守
  • 各サービスのロールの複数のインスタンスを展開します。
  • 複数のデータ センターでアプリケーションをホストします。
  • 展開および保守のタスクを自動化してテストします。
  • プラットフォームのステージングおよび運用機能の使用を検討します。
  • 可能な場合はインスタンスを再利用せずに、構成の変更を適用します。
  • 更新中のダウンタイムをゼロにするためのアップグレード ドメインを使用します。
  • Azure の仮想マシンの可用性セットを構成します。
• データ管理
  • ローカルおよび地理的な冗長性によるデータ レプリケーションを利用します。
  • オプティミスティック同時実行制御、および結果整合性を使用します。
  • 定期的なバックアップとポイントインタイム リストアを使用します。
  • Azure Redis Cache のセカンダリ コピーを保守するため、高可用性オプションを有効にします。
• エラーと障害
  • タイムアウトの概念を紹介します。
  • 一時的な障害により失敗した操作を再試行します。
  • リモート サービスが使用できない場合は連鎖的な障害を回避するため、要求の送信を停止します。
  • 複数のコンポーネントを構成またはフォールバックします。
  • 別のサービスまたはワークフローにフォールバックします。
• 監視と障害復旧
  • 可能性の高い障害や障害イベントの豊富なインストルメンテーションを提供します。
  • チェック機能を実装することでシステム正常性を監視します。
  • すべてのフェールオーバーおよびフォールバック システムを定期的にテストします。
  • 監視システムをテストします。
  • 実行時間の長いワークフローの進行状況を追跡します。
  • 障害復旧を計画します。

▼ 可用性のチェックリストを参照する

高可用性のチェックリスト

• ロールに対して単一の仮想マシンを使用しないようにしていますか。
• アプリケーションのインターネットに接続する VM の手前でロード バランサーを使用していますか。
• ステートレスなアプリケーションや Web サーバーで可用性セットを使用していますか。
• ステートレスなアプリケーションや Web サーバーで仮想マシン スケール セット (VMSS) を使用していますか。
• Premium Storage を使用し、各仮想マシンに別々のストレージ アカウントを使用していますか。
• アプリケーションの各階層間でロード バランサーまたはキューを使用していますか。
• SQL データベースでアクティブ geo レプリケーションを使用していますか。
• データベースの手前でキャッシュ (Azure Redis Cache) を使用していますか。
• 大規模なイベントが予想される場合に、Microsoft Azure サポートに連絡しましたか。
• Web に接続されたストレージ BLOB と静的なアセットの手前で Content Delivery Network (Azure CDN) を使用していますか。

▼ 高可用性のチェック リストを参照する