こんにちは！ GIMLEチームの太田です。
突然ですが、皆さん「レビュー」ってどんなイメージを持っていらっしゃるでしょうか。
私は最近、成果物のレビューをしてもらう機会が多いのですが、何回出しても少し緊張してしまいます。 実は、この記事自体も先輩方にレビューしてもらったのですが、中々に鋭い指摘をいただき、改めて考え直すことも多かったです・・・。
ただ、レビューをしてもらうことで、自分にない"視点”がいただけるなぁとも感じます。 新たなモノの見方をレビューを通じて受け取ることで、新たな考え方や問いが自分の中から生まれてきます。 こうして少しずつですが、成長させてもらっております。
そこで・・・この記事にいただいたレビューと、それに対して考えたことを抜粋して、そのまま記事内に書いてしまおうと思い立ちました。
「レビューの現場から」というサブタイトルも付けさせていただきました。
記事の中で↓のようになっているところを押していただくと、レビューの内容が表示されます。
まだまだ発展途上で、考慮不足な部分がたくさんあると思いますが、何かの参考にしていただけると大変ありがたいです。
それでは、いってみましょう！
はじめに
終わってから結構経ってしまいましたが、ゴールデンウィークは皆様いかがお過ごしでしたか？ 私は「みんなが休んでいる今が最大のチャンス！」と思って予定をたんまり詰め込んでおりました。 中々スリリングな1週間を過ごすことができて、楽しかったです(^_^)
さて、そのゴールデンウィーク前まで遡ってしまうのですが、Google Cloud Dayというオンラインカンファレンスに参加する機会がありました。
その中でGCPにおけるネットワーキングについてのセッションを拝見。
AWSだけでなく、GCPやAzureなどのクラウドサービスも使っていきたい身として、「Azureのネットワーキングってどうなっているんだろう？」という疑問が湧いてきました。
ということで、今回はクラウドサービスを使うにあたっての基本的な部分となるネットワーキングについて、Azureではどのような感じで作っていくことになるのか、
- リージョンと可用性ゾーン
- 可用性セット
- Azure Virbual Network (VNet)
- ルーティングとサブネット
- ファイアウォール
のような観点で概要を見ていけたらいいな、と思います。
リージョンと可用性ゾーン
リージョンは、データセンターを設置している独立した地域のことで、日本だと「西日本」と「東日本」のリージョンが存在します。
各リージョンは、別のリージョンとペアになっており、Azure Site Recovery（ASR）を使用することで、ペアのリージョンでの災害復旧（Disaster Recovery：DR）が可能とのこと。
この Azure Site Recovery なのですが、オンプレミス（データセンタ）をメインにしたDRサイトをAzure上に作成したり、フェイルオーバー（障害が発生した際に、システムを別の場所に復旧させること）のテストも可能だそうです。
さて、リージョン内には「可用性ゾーン」と呼ばれる場所が複数存在しています。
英語にすると「Availability Zone」です。AWSでも馴染みのある言葉になりますね。
１つの可用性ゾーンは、それぞれ異なる電源・ネットワーク・冷却装置をもつ、１つ以上のデータセンターで構成されています。
なので、複数のゾーンに渡って仮想マシンを配置すれば、１つのデータセンタで障害が発生しても、他のゾーンのデータセンターでカバーできる、ということになります。
継続して稼働しなければならないシステムを作る際は、可用性／ 冗長性の確保という視点が必要。 その時に使用する仕組みが、リージョンと可用性ゾーンというわけですね。
リージョンと可用性ゾーンについて、詳しくは公式ドキュメント↓を参照していただければと思います。
リージョンと可用性ゾーン
可用性セット
そしてAzureにはもう一つ「可用性セット」と呼ばれる冗長化の仕組みがあります。 こちらは、１つの可用性ゾーンの中の、１つのデータセンター内で仮想マシンを冗長化する仕組みです。
可用性セットには、
- 障害ドメイン
- 更新ドメイン
という枠組みが存在します。
障害ドメインというのは、電源やネットワークスイッチを共有する１つのラック に相当します。
複数の障害ドメインに渡って仮想マシンを配置すれば、１つのラックで障害が発生しても、他の障害ドメインのラックでカバーできる、という仕組みですね。
更新ドメインというのは、計画メンテナンスで同時に再起動される、基礎となる物理ハードウェアのグループ１つ分 に相当します。
複数の更新ドメインに渡って仮想マシンを配置すれば、１つの更新ドメインで再起動がかかっても、他の更新ドメインの物理ハードウェアでカバーできる、という仕組みです。
可用性セットの詳細についての公式ドキュメントはこちら↓
可用性セットの概要
上記で見てきたリージョン・可用性ゾーン・可用性セットは、いずれも障害時にいかにダウンタイムを防ぐか、という観点で設計していくことになります。
Azure の回復性 というタイトルでそのような観点についてまとめた公式ドキュメントもありますので、是非見てみてくださいね。
Azure Virtual Network (VNet)
Azure Virtual Network (以下、Vnet) は、Azure内に仮想のネットワークを作成できるサービスです。 AWSで言うところの VPC に相当するサービスですね。
リージョン間をまたいだVNetは構成できないため、リージョン毎に作成していく形です。 そして、VNetおよび後述するサブネットはリージョン内のすべての可用性ゾーンにまたがっています。 AWSの場合はアベイラビリティゾーン毎にサブネットを作成するので、こちらは違いがありますね。
また、後述のシステムルートが自動的に作成されることで、作成したVNet内のリソースはデフォルトでインターネットへの送信方向の通信が可能になるとのこと。
VNetについての公式ドキュメントはこちら↓
Azure Virtual Network とは
ルーティングとサブネット
さて、VNet内に作成したサブネットについてですが、サブネット毎にルートテーブルが自動的に作成され、既定のシステムルートが追加されます。
こちらのシステムルートは削除不可能ということで、新しいルートを追加するには、ユーザー定義のルートテーブルを作成してサブネットに割り当てることで実現が可能です。
また、Azureの機能を有効化した場合に、システムルートに追加されるルートがあるとのこと。 具体的には、
- VNetピアリングを有効化した場合、ピアリングした各VNet向けのルートが追加されたり
- サービスエンドポイントを有効にしたサブネットでは、特定のサービスのパブリックIP向けのルートが追加されたり
といったことがあるそうです。
VNetピアリング は、AWSで言うところの VPCピアリング。 サービスエンドポイント は、AWSで言うところの VPCエンドポイント に相当するサービスというイメージですね。
オンプレミスとの接続におけるルーティングはまた別の話となるのですが、長くなるので今回は割愛させていただければと・・・。
VNetにおけるルーティングについては、↓のドキュメントが詳しいです。
仮想ネットワーク トラフィックのルーティング
さらに、サブネットをAzureサービスに委任することで、そのサブネットを特定のAzureサービス専用にすることもできるとのこと↓
仮想ネットワークに専用の Azure サービスをデプロイする
ここまでで リージョン、可用性ゾーン、可用性セット、VNet、サブネット、ルートテーブル について見てきましたが、ややこしくなってきたので、簡単な図を書いてみました。
これだけでも中々たくさん登場人物がいて、覚えるのが大変です(汗
ファイアウォール
さて、今回最後に見ていくのは ファイアウォール です。
Azureでは、ネットワークセキュリティグループ (以下、NSG)というサービスがあり、これを使って通信をフィルタリングすることができます。
NSG はサブネット、もしくは仮想マシンのNIC（Network Interface Card）に紐つけて使用します。
NSGには、以下のような特徴があります。
- NSGが紐ついていないサブネットやNICにNSGが紐ついていない仮想マシンの作成は可能
- １つのサブネットまたは、１つのNICに対して、１つのNSGだけが適用可能
- サブネットと中に配置する仮想マシンのNIC両方にNSGをつける場合、両方のNSGで同じルールを設定しておかないと、どちらかのNSGで弾かれてしまう
- 既定のルールが設定されており、こちらは削除はできないが、より優先度の高いルールで上書きが可能
- 類似のサービスであるAWSのセキュリティグループとは違い、「拒否」のルールを設定したり、ルールごとの優先度を設定することも可能
- 拡張機能として、仮想マシンを用途別にグループ化する仕組みである、アプリケーションセキュリティグループ（以下 ASG）というサービスがある
言葉で説明するとどうしても冗長になってしまいますね(´•_• ٥)
AWSと似ているようで違う部分も多く、設計する時の考慮事項も結構変わってきそうです。
（特にNSGとASGの使い分けのあたりはややこしそう・・・）
NSGやASGの詳細に関するドキュメントはこちら↓
さらに、NSGとは別に、Azure Firewallというサービスもあります。
通知をフィルタリングするサービスという意味ではNSGと同じなのですが、こちらはVNet自体に紐つけます。
NSGよりもフィルタリングできる範囲が広がっている他、NSGにはない機能がいくつか備わっているようです。
ドキュメントはこちら↓
おわりに
今回改めてAzureにおけるネットワークについて調べてみたのですが、
初めて目にする言葉が多くて、最後の方はエネルギー切れのような状態になってしまいました・・・(´･ᴗ･`;)
実際に手を動かして体感してみないと、概要をまとめるのは難しいですね。
ちなみに、AzureとAWSの比較は、Azureの公式ドキュメントにも載っていたりします。 今回の記事を書く上でもかなり参考にさせていただきました。
ネットワークは、クラウドを扱う上での基本となる部分かと思います。 今回取り上げられなかった要素も含めてしっかり理解して、クラウドサービスを使いこなしていきたいですね！
