LinuxユーザーがイジるはじめてのAzure

LinuxユーザーがAzureを使いこなせるように応援するブログです

はじめてのMicrosoft Azure(ロードバランサ#1)

前回までで、CentOS7.2の仮想マシンを作成し1TBのディスク領域を追加しました。

※前回の記事は以下。

 

はじめてのMicrosoft Azure(ディスクアタッチ) - LinuxユーザーがイジるはじめてのAzure

 

仮想マシンを作成しディスクを追加して、とくれば次はロードバランサの作成、と必然的な流れがありますので、とりあえず乗っかりましょう。とはいえゴールがないと目移りしてしまいますのでゴール設定をします。

 

ゴール:2台のWEBサーバーに対してロードバランサから分散させてWEBを表示する

 以下がこれからやっていく順序になります。

 

1、【事前準備】ロードバランサの種類を理解する 

2、WEBアクセスできる仮想マシンを2台用意し上位にロードバランサ

  を設置する

3、稼働中の1台を強制停止させ正常にロードバランスできていることを確認する

 

 ○1、【事前準備】ロードバランサの種類を理解する

 

まず、一言でロードバランサといってもレイヤと呼ばれる階層毎に異なる種類が存在します。これはMicrosoft Azureに限った話ではなく、どのクラウド事業者が提供するロードバランサも同じです。ではどのような種類があるのか、Microsoft Azureを例に説明します。

 

グローバルロードバランサを担う「Traffic Manager」

その名の通り、世界中に点在するリソースに対して広域負荷分散するロードバランサです。AzureではTraffic Managerと呼ばれる機能がこれに該当します。こちらを利用するケースは、異なるリージョンに対して負荷分散を行う場合に利用するためDNSレベルで制御し、用途としては事業継続性(BCP)やDisasterRecovery(DR)対策といったクリティカルなサービスで必要になります。ポイントは「異なるリージョン間での負荷分散」ですが、Traffic Managerから直接仮想マシンのグローバルアドレスに対して分散させるケースはほとんどなく。大抵は下で説明するL4ロードバランサのエンドポイントへ分散させます。

 

L4ロードバランサを担う「Azure Load Barancer」

L4とはレイヤ4を指しており、OSI参照モデルでいうトランスポート層の分散を担うロードバランサになります。トランスポート層といっても難しく感じますので、平たく言えばIPアドレスを使った分散が可能と考えてください。また、Azure Load Barancerはパブリックなアクセスに対する負荷分散以外に内部ネットワーク間の負荷分散機能としても利用できるため、プライベートロードバランサとしての用途として利用することもできます。※その場合はILB(Internal Load Barancer)と略されます。ILBはWEBからDBサーバーへ分散する際に複数台のマルチマスタ構成のDBサーバーや、複数のreadのみ担当するslaveサーバーへ分散する、などの用途で利用できます。

 

L7ロードバランサを担う「Application Gateway

L7はレイヤ7ですので、アプリケーション層の分散を担うロードバランサです。L4ではIPアドレスを担う分散が可能でしたが、L7ではURLやHTTPヘッダによる分散ができるようになります。こちらはいわゆる仮想ロードバランサと呼ばれる位置づけになりますが、仮想マシンへログインして操作するものではありません。仮想マシンと同列のレイヤで負荷分散機能が利用できます。

 

今回はお試しで利用するためAzure Load Balancerを利用しますが、もしSSLオフロード機能が必須であったり、Cookie処理による振る舞いが必要なケースであればApplication Gatewayを利用しましょう。Azure Load BalancerではSSLオフロード機能は現時点で搭載されていません。

 

Tips

SSLオフロードとは。SSLアクセラレータとも呼ばれる機能ですが、この機能を理解する前にSSL通信を理解する必要があります。

まずクライアント(ブラウザ)がhttpsから始まるWEBサイトへアクセスします。そうするとWEBサーバーから証明書が送られてくるためブラウザはブラウザに搭載されているルート証明書から署名を確認します。※ここで見つからないと警告がでます。確認が取れれば、通信データの暗号化に使用可能な暗号の種類をサーバに通知し共通鍵暗号方式が選択されます。ブラウザは暗号用の共通鍵を生成しサーバの公開鍵で暗号化して送ります。ブラウザから送られた暗号化された公開鍵は、サーバー側の秘密鍵で複合されます。そして双方が共通鍵(セッションキー)を使って暗号化通信が開始されます。これがSSL通信/TLS方式になります。

、、、という具合に、サーバー側で毎回複合化する処理が走るため、結構サーバー側の負担(性能負荷)が大きいのが現状です。この役目を上位にいるロードバランサにやってもらおう、というのがSSLオフロード機能になります。また、数台のサーバーであれば証明書の配置や展開は苦にならないですが、数十台、数百台となってきますと、SSL証明書の更新タイミングや脆弱性発生時の入れ替えなどの手間を考えるとロードバランサの証明書を1つ変更するだけで終わる、という運用の手間軽減にもつながります。

 

今回の記事はここまでとします。

 

ロードバランサに関する種類はある程度理解できたと思いますので、次の記事からは

「2、WEBアクセスできる仮想マシンを2台用意し上位にロードバランサを設置する」を始めたいと思います。