この参照アーキテクチャでは、Linux 上の Apache Cassandra をデータ層に使用して、N 層アプリケーション用に構成された仮想マシン (VM) と仮想ネットワークをデプロイする方法を示します。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
このアーキテクチャには次のコンポーネントがあります。
全般
リソース グループ。 リソース グループは、Azure リソースをグループ化して、有効期間、所有者、またはその他の条件別に管理できるようにするために使用されます。
可用性ゾーン。 可用性ゾーンは、Azure リージョン内の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 複数のゾーンに VM を配置することで、アプリケーションは 1 つのゾーン内の障害に対する回復性が高くなります。
ネットワークと負荷分散
仮想ネットワークとサブネット。 すべての Azure VM が、サブネットにセグメント化できる仮想ネットワーク内にデプロイされます。 階層ごとに個別のサブネットを作成します。
Application Gateway。 Application Gateway はレイヤー 7 のロード バランサーです。 このアーキテクチャでは、これによって HTTP 要求が Web フロント エンドにルーティングされます。 Application Gateway には、一般的な脆弱性やその悪用からアプリケーションを保護する Web アプリケーション ファイアウォール (WAF) も用意されています。
ロード バランサー。 Azure Standard Load Balancer を使用して、Web 層からビジネス層にネットワーク トラフィックを分散します。
ネットワーク セキュリティ グループ (NSG)。 NSG を使用して、仮想ネットワーク内のネットワーク トラフィックを制限します。 たとえば、ここに示されている 3 層アーキテクチャでは、データベース層は Web フロントエンドからのトラフィックを受信せず、ビジネス層と管理サブネットからのトラフィックのみ受信します。
DDoS Protection。 Azure プラットフォームには分散型サービス拒否 (DDoS) 攻撃に対する基本的な保護が用意されていますが、DDoS 攻撃を軽減する機能が強化されている Azure DDoS ネットワーク保護を使用することをお勧めします。 「セキュリティ」の考慮事項を参照してください。
Azure DNS。 Azure DNS は DNS ドメインのホスティング サービスです。 これは Microsoft Azure インフラストラクチャを使用した名前解決を提供します。 Azure でドメインをホストすることで、その他の Azure サービスと同じ資格情報、API、ツール、課金情報を使用して DNS レコードを管理できます。
仮想マシン
Apache Cassandra データベース。 レプリケーションとフェールオーバーを有効にすることで、データ層で高い可用性を提供します。
OpsCenter。 DataStax OpsCenter などの監視ソリューションをデプロイして Cassandra クラスターを監視します。
Jumpbox。 要塞ホストとも呼ばれます。 管理者が他の VM に接続するために使用するネットワーク上のセキュアな VM です。 jumpbox の NSG は、セーフ リストにあるパブリック IP アドレスからのリモート トラフィックのみを許可します。 NSG は、リモート デスクトップ (RDP) トラフィックを許可する必要があります。
Recommendations
実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。 これらの推奨事項を開始点として使用してください。
仮想マシン
VM の構成に関する推奨事項については、「Azure で Linux 仮想マシンを実行する」を参照してください。
仮想ネットワーク
仮想ネットワークを作成するときに、各サブネット内のリソースが要求する IP アドレスの数を決定します。 CIDR 表記を使用して、必要な IP アドレスにとって十分な規模のサブネット マスクとネットワーク アドレス範囲を指定します。 標準的なプライベート IP アドレス ブロック (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) の範囲内にあるアドレス空間を使用します。
後で VNet とオンプレミスのネットワークとの間にゲートウェイを設定する必要がある場合は、オンプレミスのネットワークと重複しないアドレス範囲を選択します。 VNet を作成した後は、アドレス範囲を変更できません。
機能とセキュリティの要件を念頭に置いてサブネットを設計します。 同じ層または同じロール内のすべての VM は、同じサブネットに入れる必要があります。これがセキュリティ境界になります。 VNet とサブネットの設計の詳細については、Azure Virtual Network の計画と設計に関するページを参照してください。
Application Gateway
Application Gateway の構成の詳細については、「アプリケーション ゲートウェイ構成の概要」を参照してください。
ロード バランサー
VM は直接インターネットに公開しないでください。 代わりに、各 VM にプライベート IP アドレスを付与します。 クライアントでは、Application Gateway に関連付けられている IP アドレスを使用して接続します。
ロード バランサー規則を定義して、ネットワーク トラフィックを VM に転送します。 たとえば、HTTP トラフィックを有効にするには、フロントエンド構成からのポート 80 をバックエンド アドレス プールのポート 80 にマッピングする規則を作成します。 クライアントがポート 80 に HTTP 要求を送信するときに、ロード バランサーは、発信元 IP アドレスを含むハッシュ アルゴリズムを使用して、バックエンド IP アドレスを選択します。 クライアント要求がすべての VM に分散されます。
ネットワーク セキュリティ グループ
NSG ルールを使用して階層間のトラフィックを制限します。 たとえば、上記の 3 層アーキテクチャでは、Web 層はデータベース層と直接通信しません。 これを強制するには、データベース層が Web 層のサブネットからの着信トラフィックをブロックする必要があります。
- VNet からのすべての受信トラフィックを拒否します。 (ルール内で
VIRTUAL_NETWORKタグを使用します。) - ビジネス層のサブネットからの受信トラフィックを許可します。
- データベース層のサブネットからの受信トラフィックを許可します。 このルールにより、データベースのレプリケーションやフェールオーバーに必要な、データベース VM 間の通信が可能になります。
- ジャンプボックスのサブネットからの SSH トラフィック (ポート 22) を許可します。 このルールによって、管理者がジャンプボックスからデータベース層に接続できるようにします。
最初のルールよりも高い優先順位を設定してルール 2 から 4 を作成し、最初のルールをオーバーライドします。
Cassandra
運用環境では DataStax Enterprise の使用をお勧めしますが、これらの推奨事項はすべての Cassandra エディションに適用されます。 Azure での DataStax の実行の詳細については、「DataStax Enterprise Deployment Guide for Azure (Azure 用の DataStax Enterprise デプロイ ガイド)」を参照してください。
ラック認識モードでノードを構成します。 cassandra-rackdc.properties ファイル内で障害ドメインをラックにマッピングします。
クラスターの前にロード バランサーは必要ありません。 クライアントはクラスターのノードに直接接続します。
このアーキテクチャのデプロイ スクリプトでは、名前解決を使用して、クラスター内通信用のシード ノード (gossip) を初期化します。 名前解決を有効にするために、デプロイでは、Cassandra ノードに対応する A レコードを使用して Azure プライベート DNS ゾーンを作成します。 初期化スクリプトによっては、代わりに静的 IP アドレスを使用できる場合があります。
注意
現在、Azure プライベート DNS はパブリック プレビュー段階にあります。
Jumpbox
アプリケーション ワークロードを実行する VM へのパブリック インターネットからの SSH アクセスを許可しないでください。 代わりに、これらの VM へのすべての SSH アクセスは、ジャンプボックスを経由する必要があります。 管理者はジャンプボックスにログインし、次にジャンプボックスから他の VM にログインします。 ジャンプボックスは、既知の安全な IP アドレスからのみ、インターネットからの SSH トラフィックを許可します。
ジャンプボックスのパフォーマンス要件は最小限に抑えられているので、小さな VM サイズを選択します。 ジャンプボックス用にパブリック IP アドレスを作成します。 ジャンプボックスを、他の VM と同じ VNet 内の、個別の管理サブネット内に配置します。
ジャンプボックスをセキュリティで保護するには、安全な一連のパブリック IP アドレスからのみ SSH 接続を許可する NSG ルールを追加します。 管理サブネットからの SSH トラフィックを許可するように、他のサブネットの NSG を構成します。
考慮事項
スケーラビリティ
スケール セット
Web 層とビジネス層については、個別の VM を可用性セットにデプロイするのではなく、Virtual Machine Scale Sets を使用することを検討してください。 スケール セットにより、同一の VM のセットを簡単にデプロイおよび管理し、パフォーマンス メトリックに基づいて VM を自動スケーリングできるようになります。 VM の負荷が増えると、追加の VM が自動的にロード バランサーに追加されます。
スケール セットにデプロイされる VM を構成するには、2 つの基本的な方法があります。
デプロイ後に、拡張機能を使用して VM を構成します。 この方法では、新しい VM インスタンスは、拡張機能なしの VM よりも起動に時間がかかる場合があります。
カスタム ディスク イメージと共にマネージド ディスクをデプロイします。 このオプションの方が早くデプロイできる場合があります。 ただし、イメージを最新の状態に保つ必要があります。
詳細については、「スケール セットの設計上の考慮事項」を参照してください。
ヒント
自動スケールのソリューションを使用する場合は、十分前もって実稼働レベルのワークロードでテストしてください。
サブスクリプションの制限
各 Azure サブスクリプションには、リージョンごとの VM の最大数などの、既定の制限があります。 サポート リクエストを提出することで、制限値を上げることができます。 詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。
Application Gateway
Application Gateway は、固定容量モードまたは自動スケール モードをサポートしています。 固定容量モードは、ワークロードが一定で予測可能なシナリオに便利です。 トラフィックが変動するワークロードには自動スケール モードを使用することを検討してください。 詳細については、「自動スケーリングとゾーン冗長 Application Gateway v2」を参照してください。
パフォーマンス効率
Azure VM 上の Cassandra で最適なパフォーマンスを得るには、「Azure VM 上で Apache Cassandra を実行する」の推奨事項を参照してください。
可用性
可用性ゾーンは、1 つのリージョン内で最適な回復性を実現します。 さらに高い可用性が必要な場合は、2 つのリージョン間でアプリケーションをレプリケートすることを検討してください。
すべてのリージョンが可用性ゾーンをサポートするわけではありません。また、すべての VM サイズがすべてのゾーンでサポートされるわけではありません。 次の Azure CLI コマンドを実行して、リージョン内の各 VM サイズでサポートされているゾーンを検索してください。
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
可用性ゾーンをサポートしていないリージョンにこのアーキテクチャをデプロイする場合は、可用性セット内に各層の VM を配置します。 同じ可用性内の VM は、冗長性のために複数の物理サーバー、コンピューティング ラック、ストレージ ユニット、およびネットワーク スイッチに展開されます。 スケール セットでは "配置グループ" が自動的に使用されます。これは、暗黙的な可用性セットとして機能します。
可用性ゾーンにデプロイする場合は、Azure Load Balancer の Standard SKU と Application Gateway の v2 SKU を使用します。 これらの SKU は、ゾーン間の冗長性をサポートします。 詳細については、次を参照してください。
- Standard Load Balancer と可用性ゾーン
- 自動スケーリングとゾーン冗長 Application Gateway v2
- Application Gateway は高可用性とスケーラビリティをどのようにサポートしますか?
1 つの Application Gateway のデプロイでは、ゲートウェイの複数のインスタンスを実行できます。 運用環境のワークロードの場合は、少なくとも 2 つのインスタンスを実行します。
Cassandra クラスター
Cassandra クラスターの場合、フェールオーバー シナリオは、アプリケーションで使用される一貫性レベルと、レプリカの数によって異なります。 Cassandra の一貫性レベルと使用方法については、「データの一貫性の構成」と「Cassandra: クォーラムと一緒に表示されるノードの数」を参照してください。Cassandra でのデータの可用性は、アプリケーションおよびレプリケーションメカニズムで使用される一貫性レベルによって決まります。 Cassandra のレプリケーションについては、「Data Replication in NoSQL Databases Explained (NoSQL Database でのデータ レプリケーションの説明)」を参照してください。
正常性プローブ
Application Gateway と Load Balancer はどちらも正常性プローブを使用して、VM インスタンスの可用性を監視します。
- Application Gateway は常に HTTP プローブを使用します。
- Load Balancer は、HTTP または TCP のいずれかをテストできます。 一般に、VM で HTTP サーバーが実行されている場合は、HTTP プローブを使用します。 それ以外の場合は、TCP を使用します。
タイムアウト期間内にプローブがインスタンスに到達できなかった場合、ゲートウェイまたはロード バランサーはその VM へのトラフィックの送信を停止します。 プローブでは引き続きチェックが行われ、VM を再び使用できるようになった場合は、VM がバックエンド プールに戻されます。
HTTP プローブでは、指定されたパスに HTTP GET 要求が送信され、HTTP 200 応答がリッスンされます。 このパスには、ルート パス ("/")、またはアプリケーションの正常性をチェックするためのカスタム ロジックを実装した正常性監視エンドポイントを指定できます。 エンドポイントでは、匿名の HTTP 要求を許可する必要があります。
正常性プローブの詳細については、以下を参照してください。
正常性プローブ エンドポイントの設計の考慮事項については、「正常性エンドポイントの監視パターン」を参照してください。
コスト最適化
コストを見積もるには、Azure 料金計算ツールを使用します。 その他の考慮事項のいくつかを次に示します。
仮想マシン スケール セット
仮想マシン スケール セットは、Linux VM のすべてのサイズで使用できます。 デプロイする Azure VM や、消費したその他の基になるインフラストラクチャ リソース (ストレージやネットワークなど) に対してのみ課金されます。 Virtual Machine Scale Sets 自体に対する増分料金は発生しません。
単一の VM の価格オプションについては、Linux VM の料金に関するページを参照してください。
ロード バランサー
構成された負荷分散およびアウトバウンド規則の数に対してのみ課金されます。 インバウンド NAT 規則は無料です。 規則が構成されていない場合、Standard Load Balancer に対する 1 時間あたりの料金は発生しません。
詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。
セキュリティ
仮想ネットワークは、Azure のトラフィックの分離境界です。 ある VNet 内の VM が別の VNet 内の VM と直接通信することはできません。 トラフィックを制限するネットワーク セキュリティ グループ (NSG) を作成していないかぎり、同じ VNet 内の VM 同士は通信可能です。 詳細については、「Microsoft クラウド サービスとネットワーク セキュリティ」をご覧ください。
インターネット トラフィックを受信する場合、ロード バランサーの規則でバック エンドに到達できるトラフィックを定義しています。 しかし、ロード バランサーの規則では IP の安全な一覧をサポートしていないため、特定のパブリック IP アドレスを安全な一覧に追加したい場合は、NSG をサブネットに追加してください。
DMZ。 ネットワーク仮想アプライアンス (NVA) を追加してインターネットと Azure Virtual Network の間の DMZ を作成することを検討してください。 NVA とは、ネットワーク関連のタスク (ファイアウォール、パケット インスペクション、監査、カスタム ルーティングなど) を実行できる仮想アプライアンスの総称です。 詳細については、Azure とインターネットの間の DMZ の実装に関する記事を参照してください。
暗号化。 機密の保存データを暗号化し、Azure Key Vault を使用してデータベース暗号化キーを管理します。 Key Vault では、ハードウェア セキュリティ モジュール (HSM) に暗号化キーを格納することができます。 データベース接続文字列などのアプリケーション シークレットも Key Vault に格納することをお勧めします。
DDoS 保護。 Azure プラットフォームには、基本的な DDoS 保護が既定で用意されています。 この基本的な保護は、Azure インフラストラクチャ全体を保護することを目的としています。 基本的な DDoS 保護は自動的に有効になっていますが、Azure DDoS ネットワーク保護を使用することをお勧めします。 ネットワーク保護では、アプリケーションのネットワーク トラフィック パターンに基づいて、アダプティブ チューニングが使用され、脅威が検出されます。 これにより、インフラストラクチャ全体の DDoS ポリシーで見落とされてしまう可能性のある DDoS 攻撃に対して、軽減策を適用することができます。 ネットワーク保護では、Azure Monitor 経由で、アラート、テレメトリ、および分析機能も提供されます。 詳細については、「Azure DDoS Protection:ベスト プラクティスと参照アーキテクチャ」をご覧ください。
オペレーショナル エクセレンス
このアーキテクチャではすべての主要なリソースとその依存関係が同じ仮想ネットワーク内にあるため、同じ基本的なワークロードに分離されます。 そのため、ワークロード固有のリソースをチームに容易に関連付けられるので、DevOps チームはこれらのリソースのあらゆる側面を個別に管理できます。 この分離により、DevOps チームと DevOps Services は、継続的インテグレーションと継続的デリバリー (CI/CD) を実行できます。
また、各種デプロイ テンプレートを使用して、それを Azure DevOps Services と統合することで、さまざまな環境を数分でプロビジョニングし、必要なときにのみ、たとえば疑似運用シナリオをレプリケートしたりテスト環境を読み込んだりできるため、コストを節約できます。
このシナリオでは、Apache Cassandra などの特定の追加ソフトウェアが仮想マシンにインストールされる可能性があるため、仮想マシンは仮想マシン拡張機能を使用して構成されています。 特に、カスタム スクリプト拡張機能を使用すると、仮想マシン上で任意のコードをダウンロードして実行でき、Azure VM のオペレーティング システムを無制限にカスタマイズできます。 VM 拡張機能は、VM 作成時にのみインストールおよび実行されます。 つまり、後からオペレーティング システムの構成に問題が生じた場合、正しい状態に戻すには手動による介入が必要になります。 この問題に対処するために、構成管理ツールを使用できます。
Azure Monitor を使用して、インフラストラクチャのパフォーマンスを分析および最適化することを検討してください。仮想マシンにログインせずに、ネットワークの問題を監視および診断できます。 Application Insights は、実際には Azure Monitor のコンポーネントの 1 つであり、ご利用の Azure 環境全体の状態を検証するためのメトリックとログを豊富に提供します。 Azure Monitor は、インフラストラクチャの状態を追跡するのに役立ちます。
アプリケーション コードを支えるコンピューター要素だけでなく、ご自身の特定のデータベースで、データ プラットフォームも監視するようにしてください。アプリケーションのデータ層のパフォーマンスが低いと、深刻な結果を招く可能性があるからです。
アプリケーションが実行されている Azure 環境は、テストの目的で、アプリケーション コードと同じメカニズムを使用してバージョン管理およびデプロイされている必要があるため、DevOps テストパラダイムを使用してテストおよび検証することもできます。
詳細については、Microsoft Azure Well-Architecture Framework に関するページのオペレーショナル エクセレンスのセクションを参照してください。