Cloud & IT Cert Prep · レッスン

実際のアーキテクチャに WAF パターンを適用する

モノリシックな Azure アーキテクチャを再設計し、各柱の WAF 要件を満たしながら、コスト、複雑さ、レジリエンスのトレードオフを文書化します。

「実際のアーキテクチャに WAF パターンを適用する」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。

プラクティスとしてのアーキテクチャレビュー

WAF のパターンを実際のアーキテクチャに適用することは、理論上の演習ではありません。5つの柱に照らして各設計判断を評価し、十分な情報に基づいてトレードオフを決める必要があります。一般的な出発点はアーキテクチャ図です。ユーザーのリクエストが各コンポーネントを通過する経路をたどり、各段階で、そのコンポーネントに障害が発生したらどうなるか、どの程度のコストがかかるか、どのように保護されているかを確認します。

モノリシックアーキテクチャを評価する

従来型のモノリシックな Web アプリケーションについて考えてみましょう。これは、Web サーバーとデータベースを同じ VM 上で実行し、パブリック IP の背後に配置した構成です。WAF の柱に照らすと、5つすべてで低い評価になります。つまり、冗長性がない（信頼性）、Web 層と同じホスト上にデータベースがある（セキュリティ）、トラフィックに関係なく VM が常時稼働している（コスト）、CI/CD がない（オペレーショナルエクセレンス）、垂直スケーリングのみ（パフォーマンス効率）という状態です。

冗長化による信頼性の向上

信頼性の柱に対応するため、異なる可用性ゾーンに複数の VM を配置して Web 層を分散し、データベースをgeo-replicationでセカンダリリージョンに複製し、手前にAzure Load Balancerを配置します。これにより単一障害点がなくなり、手動で対応しなくても、ゾーンやリージョンの障害時にアプリケーションの稼働を継続できます。

# Deploy VMs across availability zones:
az vm create \
  --resource-group myRG \
  --name webVM1 \
  --zone 1 \
  --image Ubuntu2204LTS

az vm create \
  --resource-group myRG \
  --name webVM2 \
  --zone 2 \
  --image Ubuntu2204LTS

スタック全体のセキュリティ強化

セキュリティの柱に対応するため、Web 層とデータベースを別々のサブネットに分離し、Web 層からデータベースのポートへの接続だけを許可するNSG rulesを設定します。データベースの接続文字列はAzure Key Vaultに保存し、Web アプリではmanaged identityを使用して実行時に取得します。これにより、アプリケーションコードや構成ファイルに認証情報をハードコーディングせずに済みます。

スケーリングと適正サイズによるコスト削減

コスト最適化のため、常時稼働する VM を、オフピーク時間帯にスケールインできるVirtual Machine Scale Setに置き換えます。データベースについては、適切な DTU レベルのAzure SQL Databaseのようなマネージド PaaS サービスが、SQL Server を搭載した完全な VM よりも低コストになるかを評価します。12 か月先まで予測できる基準キャパシティについては、Reserved Instancesを購入します。

IaC と CI/CD による運用上の卓越性

運用上の卓越性を高めるため、インフラストラクチャ全体をBicepまたは ARM テンプレートとして定義し、バージョン管理システムに保存します。Azure Pipelines または GitHub Actions で CI/CD パイプラインを構築し、インフラストラクチャの変更とアプリケーションコードを自動的にデプロイします。変更を本番環境に反映する前に、自動スモークテストや手動承認などのデプロイゲートを追加します。

# Deploy infrastructure via Bicep:
az deployment group create \
  --resource-group myRG \
  --template-file main.bicep \
  --parameters @parameters.json

キャッシュと CDN によるパフォーマンス向上

パフォーマンス効率のため、データベースの手前にAzure Cache for Redisを導入し、頻繁に読み取られるクエリをキャッシュしてデータベースの負荷を軽減します。静的アセット（画像、CSS、JavaScript）はAzure CDN経由で配信し、世界中のユーザーに近いエッジノードから提供します。変更のたびにアプリケーションの負荷テストを実施し、改善効果を測定できることを確認します。

トレードオフの文書化

アーキテクチャを変更するたびに、トレードオフが生じます。たとえば、マルチゾーンアーキテクチャに移行すると信頼性は向上しますが、コストが増加します（2 つのゾーン = 2 台の VM）。Redis キャッシュを追加するとパフォーマンスは向上しますが、運用の複雑さが増します（監視と保守が必要なサービスが 1 つ増えます）。優れたアーキテクチャドキュメントでは、こうしたトレードオフを明確に記録し、将来のアーキテクトが意思決定の理由を理解できるようにします。

反復的な改善アプローチ

1 回の再設計で完璧を目指すのは避けてください。この方法はコストが高く、リスクがあり、時間もかかります。その代わりに、反復的な改善サイクルを採用します。Well-Architected Review を実施し、最も影響の大きい上位 3 つの問題を特定して修正し、改善を測定して、これを繰り返します。このアプローチにより、アーキテクチャの改善をアジャイルな開発と連携させ、各スプリントでの進捗を関係者に可視化できます。

アーキテクチャリファレンス設計の利用

Microsoft は、一般的なワークロードパターン向けのリファレンスアーキテクチャを Azure Architecture Centerで公開しています。Web アプリケーションアーキテクチャ、AKS 上のマイクロサービス、データ分析パイプラインなど、さまざまな設計が含まれています。各リファレンスアーキテクチャは WAF の柱に照らしてあらかじめ評価されており、そのパターンで選択されたトレードオフに関する注記も含まれています。

アーキテクチャ上の意思決定の伝達

Architecture Decision Records (ADRs)を使用して、重要なアーキテクチャ上の選択、その選択が行われた背景、検討した代替案、WAF の柱への影響を文書化します。コードベースとともに ADR をバージョン管理システムに保存すると、監査可能な履歴が作成され、新しいチームメンバーが現在のアーキテクチャになっている理由を理解しやすくなります。

理解度チェック

このレッスンで扱った Microsoft Azure Fundamentals (AZ-900) の概念について、理解度を確認します。

レッスンのまとめ

このレッスンでは、WAF パターンは各アーキテクチャ上の意思決定を 5 つすべての柱に照らして評価することで適用すること、最も影響の大きい問題から始めて改善を段階的に進められること、そして将来のアーキテクトが判断理由を理解できるようにトレードオフを文書化する必要があることを学びました。次は、Azure SLA と、複数サービスのアーキテクチャにおける複合 SLA の計算方法について学びます。

よくある質問