0. はじめに
本記事ではサーバレス構成を例にAzureのアーキテクチャ検討のノウハウをご紹介します。
実際のPJで基盤検討メンバとして、Azureのアーキテクチャの検討に携わる機会がありましたので、ポイントだと感じた部分をピックアップして紹介します。（偏りがありますが、ご容赦ください）
こんな方にオススメ
・Azureのアーキテクチャの検討をやったことがない
・他の人がAzureアーキテクチャを検討する際の考え方を知りたい
・Azureに関する技術情報が知りたい
前回の記事では、アプリケーション観点の内容を紹介しました。
今回はNWの切り口でご紹介します。
1. 本ブログのアーキテクチャ検討
アーキテクチャ検討というと、システムアーキテクチャ図を作成することをイメージする方が多いと思います。
本ブログでは、システムアーキテクチャ図を作成する前段として、各コンポーネントをどのように構成するかについて、基盤担当の目線でご紹介します。
2. 前提
前提は以下の通りです。
・サーバレスのアプリケーションを検討する
・セキュリティを高める構成を検討する
3. 検討ポイント
3-1. VNet構成
小規模のシステムの場合は、１つのVNetを利用し、シンプルな構成とするのがよいと思います。複数のVNetを構成した場合と比べ、VNet間の通信のレイテンシや通信コスト、VNet間の通信の検討等、考慮すべきポイントが減ります。
中規模レベルのシステムであれば、複数のVNetを構成し、役割ごとにVNetを分割するとよいかと思います。どのように分割すればよいという点については、システムの方針次第で変わってきます。以下に例を示します。
共通の機能を集約し、業務機能単位で分割する、いわゆるハブ＆スポーク構成のパターンです。具体的には、Application GatewayやFirewallなど、共通で利用するコンポーネントをHubのVNetに配置し、業務機能を実現するコンピューティングサービス(App Service等)やCosmos DBなどはSpoke側のVNetに配置する構成です。
このVNet構成の利点は、分割単位が明確なので管理がしやすい点と機能が追加となった場合に、SpokeVNetを追加すればよく、拡張しやすい点です。
イメージは以下の通りです。
留意点としては、以下の２点です。
・HubVNetの通信負荷が集中する
・HubVNetの障害発生時にHubVNetを経由する通信が不可となるため、間接的にSpokeVNetのコンポーネントが利用できなくなる
対策として、HubVNetのコンポーネントの可用性が高いプラン(ゾーン冗長等）や方式を検討することで、HubVNetのリソースをケアしていくのがよいかと思います。
さらにコストが限られている場合は、HubVNetをリッチな構成として、SpokeVNetの可用性のレベルを落とすなど、優先順位をつけるのもよいかと思います。
参考情報を載せておきます。
■ハブ＆スポーク構成について
■仮想ネットワークの構成方法について
3-2. VNetからのアウトバウンド通信
VNetに配置しているリソースから、インターネットへのアウトバウンド通信を行う場合は、Azure FirewallやNATGatewayを構成します。
単にインターネットアクセスを実現したい場合は、コスト面で優位なNATGatewayを選択する。一方で、URLのフィルタリングなどにAzure Firewallに具備された機能により、セキュリティを高めたい場合は、Azure Firewallを選択するのがよいかと思います。
3-3. プライベート通信の実現
（1）プライベートリンク、VNet統合
VNetからAzureのPaaSサービスとの通信について、規定では、インターネットを経由することになります。ただし、プライベートリンクやVNet統合を利用することで、インターネットを経由せず、プライベートIPでセキュアに通信することが可能です。詳細については、以下のリンクをご参照下さい。
例えば、Azure FunctionsからCosmos DBにアクセスする場合は以下の流れとなります。
<既定での通信>
Azure Functions→インターネット→Cosmos DB
<プライベート通信を構成した場合の通信>
Functions→VNet統合→プライベートエンドポイント→Cosmos DB
当初、私はVNet統合とプライベートエンドポイントの違いが全く理解できませんでした。しかしながら、情報収集している中で、VNet統合は送信の話で、プライベートエンドポイントは受信の話だと意識するようになってから、理解が深まりました。
■プライベート エンドポイント
https://learn.microsoft.com/ja-jp/azure/azure-functions/functions-networking-options?tabs=azure-portal#inbound-networking-features
上記は、FunctionsやCosmos DBの例でしたが、他のAzureサービス(Service BusやEvent Grid、BLOBなど）でも対応しているものがあります。但し、Premiumプランでのみ対応しているケースが多いので、各Azureサービスで対応しているプランは必ずご確認下さい。
サービスプランを選定する際のポイントを過去の記事で紹介していますので、興味がある方は、是非、ご参照ください。
（2）API Managementの内部モード
API ManagementをVNetにデプロイすることが可能です。これにより、外部からのアクセスを防止し、アプリケーションを保護できます。
さらに、Front Doorを利用する場合、API Managementの前段にApplication Gatewayを配置することで、API Managementを外部ネットワークと直接接続しない構成にできます。
Application GatewayとAPI Managementを併用する場合の構成については、以下の資料が参考になります。
3-4. Sorry機能
Sorry機能を実装すると、サービスが提供できない時にユーザに対して、適切な情報を伝えることで不安や混乱を軽減できます。
Front DoorとApplication Gatewayを利用している場合、どちらにカスタムエラーページを実装するか迷う方もいらっしゃると思います。
実は、Front Doorのカスタムエラーページは、WAFでブロックした通信に対して、応答を返すことが主目的であり、ステータスコードに応じてエラーページを返すことができないようです。
一方で、Application Gatewayでは、下記の応答コードに対して、カスタムエラーページを返すことが可能です。
(引用)
https://learn.microsoft.com/ja-jp/azure/application-gateway/custom-error
注意点として、エラーページを格納するBLOBのストレージアカウントはパブリックアクセス可能な構成とする必要があるのでご注意下さい。
3-5. WAF機能
Web Application Firewallにより、ボット攻撃や一般的な Web 脆弱性 からアプリケーションを保護することが可能です。
Front DoorとApplication Gatewayのオプションとして、WAFを利用することが可能です。どちらか一方に導入するケースが一般的かと思います。
個人的には、フロント側で防御した方が影響範囲を局所化につながるので、Front Door側にWAF機能を持たせる構成がよいかと思います。但し、Front Doorを経由せずにApplication Gatewayへ直接アクセスする経路がある場合は、Application GatewayにWAFを実装することになるかと思います。
Front DoorとApplication GatewayのそれぞれのWAF機能については、以下をご参照下さい。
Application GatewayにWAFを導入する場合は、Front Doorの要求ヘッダー(X-Azure-FDID)をApplication GatewayのWAFのカスタムルールに設定することで、特定のFront Doorからの通信のみに制限できます。
Front DoorのIPアドレス又はサービスタグの制限に比べ、より強い制限をかけることが可能です。
3-6. 負荷分散のオプション
既に本ブログでFront DoorやApplication Gatewayなどに触れてますが、負荷分散として利用するサービスを決定するのに役立つ、ディシジョンツリーをご紹介します。
<引用元>負荷分散のオプション
https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/load-balancing-overview
ざっくりいうと、以下のような条件により、負荷分散のサービスを決定するような内容となっています。
・インターネットに接続するか
・https/http通信のアプリケーションか
・パフォーマンスアクセレーションが必要か
負荷分散の構成を決定する上で迷われた際は、参考になるかと思います。
4. まとめ
サーバレス構成を例にNW観点でAzureのアーキテクチャ検討のノウハウをご紹介しました。
中でもプライベートな通信を実現する場合、例えば、Azureポータルからもアクセスできなくなってしまったり、注意すべき点が多く発生します。また、設計や実装の難易度がグッとあがりますので、実際のプロジェクトでは、十分なスケジュールを確保することやベンダーサポートの協力など、マネジメントでも事前に対策を講じることをお勧めします。
要件によって、何を検討するか、検討の結果、どのアーキテクチャを選定するか変わってきます。一例として、本ブログでお役に立てる部分があれば幸いです。
過去のブログで、アプリケーション観点のサーバレス構成におけるアーキテクチャ検討やAzureのサービスプランの選定方法を紹介してます。興味のある方は、目を通して頂けるとありがたいです。
留意事項
・2024年12月時点の情報となります。Azureサービスの仕様等、変更になる可能性がございますので、最新の情報をご確認ください。
・個人の見解であり、会社と一切関係がありません。