ニフクラ ブログ

ニフクラ/FJ Cloud-Vやクラウドの技術について、エンジニアが語るブログです。

VPNゲートウェイでVTIを使ったVPN接続方法

プライベートLAN 機能紹介・TIPS VPN VPNゲートウェイ

みなさんこんにちは！ニフティの蓮沼です。 2年ぶりのユーザブログ投稿になります。もう3年目になりました。 普段はニフティクラウドのVPNゲートウェイやルーターの開発、運用などを行っています。

今回は多くのお客様からお問い合わせをいただいている、ニフティクラウドのVPNゲートウェイの「IPsec VTI」機能について機能概要、構成、設定方法についてご紹介したいと思います！

VTIとは？

VTIとはVirtual Tunnnel Interfaceの略で、VPNゲートウェイのVPN接続先を対象としたルーティング設定ができる機能です。この機能は2016年4月13日にルーター・VPNゲートウェイ 機能エンハンスで追加されました。 通常のIPsec接続では、ニフティクラウドのプライベートLANから対向機器LAN側IPアドレス帯、下の図では192.168.0.0/24のみ通信ができます。これはVPNゲートウェイの仕様になります。

VTIでの接続であればVPN接続先をInterfaceとして認識するため、VTIに対してルーティング設定を行うことが可能になります。VTIでは192.168.0.0/24 , 172.16.0.0/24に対しても通信ができます。

VTIが必要な構成例

ニフティクラウドにVPN接続するお客様拠点の異なるネットワークが、複数ある場合には原則VTIを利用する必要があります。 ※お客様拠点のVPN機器に接続されるネットワークが192.168.0.0/24 , 192.168.1.0/24と隣り合っている場合には、対向機器LAN側IPアドレス帯を192.168.0.0/23と設定する事で、2つのネットワークに対して通信が可能になる場合もあります。

VTIの設定方法

では構成例がわかったところで、実際に以下のネットワークを構築してみます。

ニフティクラウド上のサーバーとお客様環境のサーバー間でping疎通できるように構築していきます。 今回ニフティクラウドをeast-21 , お客様環境は擬似環境としてニフティクラウドのwest-12で構築を行っています。

各サーバー、ネットワークの作成

構成図の通り、各サーバーやネットワークをコンパネから作成していきます。

east-21（ニフティクラウド環境）

west-12（擬似お客様環境）

VPNゲートウェイにはバージョンがあります。過去VTIに関する不具合や仕様変更がありましたので、最新のバージョンか確認してください。 今回、執筆時点の最新バージョンであるv2.3を利用します。

カスタマーゲートウェイの作成

次にVPN接続を行うためのカスタマーゲートウェイを作成します。 以下はeast-21（ニフティクラウド環境）で設定する、対向拠点側west-12（擬似お客様環境）の設定です。ここではIPアドレス124.24.43.50を設定しています。

ポイントは以下2点です。

  • 対向機器LAN側IPアドレス帯にはVTIの場合でもIPsecと同様に、対向機器のLANネットワークアドレス帯を指定します。
  • 対向機器LAN側IPアドレスはVPNゲートウェイに設定される対向側IKE IDです。VPNゲートウェイはデフォルトで対向側IKE IDにグローバルIPアドレスである「対向機器IPアドレス」を利用するため、VPNゲートウェイ同士の接続の場合は空欄にします。接続する対向機器のIKE IDがプライベートIPを利用する場合には設定が必要です。

同様にwest-12（擬似お客様環境）でも、対向拠点側east-21（ニフティクラウド環境）のカスタマーゲートウェイを作成します。

VTIでのVPNコネクションの作成

それではVTIでVPNコネクションを作成し、VPN接続を行います。 以下はeast-21（ニフティクラウド環境）のVPNコネクションの作成画面です。

VTIの場合、接続方式で「VTI / IPsec」を選択します。

同様にwest-12（擬似お客様環境）でもVPNコネクションを作成します。 以下の様にコネクションステータスが接続済みとなればIPsec SAが確立された事を意味し、VPN接続が確立された状態となります。

east-21（ニフティクラウド環境）

west-12（擬似お客様環境）

もしVPN接続ができていなかったら

ニフティクラウドのVPNゲートウェイにはログ機能があります。このログからお客様の機器設定ミスなど接続できない原因を切り分ける事が可能です。 お客様はエラー番号から、エラー内容、解決方法を参照しトラブルシュートする事が可能になっています。とても便利な機能ですので「VPN接続できない！」という時にはぜひご活用ください！

ルートテーブルの設定

VTIでのVPN接続はできましたので、次にVPNゲートウェイに対してルートテーブルの設定を行います。まずVTIのVPNコネクションを作成すると、自動的にVPNゲートウェイに以下の様なルートテーブルの設定がされます。

このためVTIのVPN接続が確立された直後ではニフティクラウドの「10.0.0.0/24」とお客様環境の「192.168.0.0/24」のネットワーク帯のみ疎通が出来る状態になっています。 「10.0.0.0/24」と「172.16.0.0/24」のネットワーク間で疎通できるように以下のルートテーブルを作成します。

east-21（ニフティクラウド環境） , west-12（擬似お客様環境）のVPNゲートウェイに設定するルートテーブル

作成後VPNゲートウェイの操作から、「ルートテーブル設定変更」でルートテーブルを変更します。

ここでポイントなのが、VPNゲートウェイに設定するルートテーブルは「172.16.0.0/24」のみという事です。VTIのVPNコネクションが設定されているVPNゲートウェイは、設定されるルーテーブルに自動的にVTIのルールを追加します。このため今回設定するルートテーブルは「172.16.0.0/24」のみのルールとなります。

また疎通確認のために、west-12（擬似お客様環境）のルーターのデフォルトゲートウェイの設定も行っておきます。

west-12（擬似お客様環境）のルーターに設定するルートテーブル

疎通確認

以上でVTIのVPN接続、ルーティング設定が完了しました。 さっそく172.16.0.0.100（擬似お客様環境）のサーバーから10.0.0.100（ニフティクラウド）のサーバーにping疎通してみます。 pingコマンドの前に、各サーバーのルーティング設定を行います。

10.0.0.100（ニフティクラウド）のサーバー CentOS 7.1
[root@localhost ~]# route add -net 192.168.0.0/24 gw 10.0.0.1
[root@localhost ~]# route add -net 172.16.0.0/24 gw 10.0.0.1
[root@localhost ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         27.133.232.1    0.0.0.0         UG    100    0        0 ens160
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 ens192
27.133.232.0    0.0.0.0         255.255.248.0   U     100    0        0 ens160
172.16.0.0      10.0.0.1        255.255.255.0   UG    0      0        0 ens192
192.168.0.0     10.0.0.1        255.255.255.0   UG    0      0        0 ens192
172.16.0.0.100（擬似お客様環境）のサーバー Microsoft Windows Server 2012 R2
PS C:\Windows\system32> route add 192.168.0.0 mask 255.255.255.0 172.16.0.254
 OK!
PS C:\Windows\system32> route add 10.0.0.0 mask 255.255.255.0 172.16.0.254
 OK!
PS C:\Windows\system32>

172.16.0.0.100（擬似お客様環境）のサーバーからpingを実行します。

PS C:\Windows\system32> ping 10.0.0.100 -t

10.0.0.100 に ping を送信しています 32 バイトのデータ:
10.0.0.100 からの応答: バイト数 =32 時間 =10ms TTL=61
10.0.0.100 からの応答: バイト数 =32 時間 =10ms TTL=61
10.0.0.100 からの応答: バイト数 =32 時間 =10ms TTL=61

10.0.0.100（ニフティクラウド）のサーバーのtcpdump

[root@localhost ~]# tcpdump  -n -i ens192 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), capture size 65535 bytes
17:38:36.027467 IP 172.16.0.100 > 10.0.0.100: ICMP echo request, id 1, seq 24, length 40
17:38:36.027498 IP 10.0.0.100 > 172.16.0.100: ICMP echo reply, id 1, seq 24, length 40
17:38:37.043041 IP 172.16.0.100 > 10.0.0.100: ICMP echo request, id 1, seq 25, length 40
17:38:37.043066 IP 10.0.0.100 > 172.16.0.100: ICMP echo reply, id 1, seq 25, length 40
17:38:38.058701 IP 172.16.0.100 > 10.0.0.100: ICMP echo request, id 1, seq 26, length 40
17:38:38.058731 IP 10.0.0.100 > 172.16.0.100: ICMP echo reply, id 1, seq 26, length 40
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

無事VPNを介して疎通確認ができました！

まとめ

今回VTIを使ったVPN接続の要件、一連の設定内容をご紹介しました。
VTIのVPN接続によりお客様の既存のネットワークを維持しながら、ニフティクラウドへのセキュアな接続が可能です。
またVPNゲートウェイのログ機能により、VPN接続が出来ない原因をトラブルシュートできるなどユーザーフレンドリーなサービスになっています。
既存のシステムをクラウドに接続する事で柔軟に拡張する事が可能ですので、ぜひご活用ください！

オブジェクトストレージをPHP・Bashから使ってみる

オブジェクトストレージ 機能紹介・TIPS S3

こんにちは。ニフティクラウド ストレージサービスチームの湊と申します。

「ニフティクラウド オブジェクトストレージ」は様々なREST APIを提供しており、利用者はこのAPIを経由してバケット・オブジェクトの操作を行うことができます。

提供APIの詳細な仕様につきましては、APIリファレンスをご確認ください。

オブジェクトストレージがサポートしているAPIインターフェースは「SDK for Java」のみですが、ほかのインターフェース（PHP・Bash）からでも利用できるかどうかを検証してみます。

なお、紹介するサンプルプログラムはシグネチャーの生成およびリクエストをオブジェクトストレージへ送る箇所に重点を置いているため、一部割愛しています。 したがって、実行時はエラーを参照しつつ適宜サンプルプログラムを修正してください。

また、サンプルプログラム内で生成するシグネチャーのバージョンはすべてv2になります。

共通環境

以下のニフクラVM上で動作確認しました。

項目 値
OS CentOS 6.6
サーバータイプ medium4
リージョン east-2

対象APIは「PutObject」（ファイルのアップロード）・「GetObject」（ファイルのダウンロード）です。

PHP

オブジェクトストレージにおいてPHP経由でファイルのアップロード・ダウンロードができることを確認します。 シグネチャーとリクエストヘッダーをキー情報・リクエストメソッドから生成し、それらをcurlのパラメーターに指定することでAPIが実行されます。

動作環境

項目 値
PHPバージョン 5.4.45

PutObject

$bucket = 対象バケット名;
$endpoint = "https://jp-east-2.os.cloud.nifty.com";
$file = アップロードファイル名;
$type = 'text/plain';
$content = file_get_contents ( $file );
$method = 'PUT';
$md5 = base64_encode ( md5 ( $content, true ) );
$date = gmdate ( \DateTime::RFC2822 );
$resource = "/$bucket/$file";
$stringToSign = $method . "\n" . $md5 . "\n" . $type . "\n" . $date . "\n" . '' . $resource;
// シグネチャーを生成。
$signature = base64_encode ( hash_hmac ( 'sha1', $stringToSign, SECRET_KEY, true ) );
$auth = "AWS " . ACCESS_KEY . ":" . $signature;
// リクエストヘッダを作成。
$headers = [ 
        "Date: ".$date,
        "Content-Type: ".$type,
        "Content-MD5: ".$md5,
        "Authorization: ".$auth 
];
$options = [ 
        CURLOPT_URL => $endpoint . $resource,
        CURLOPT_CUSTOMREQUEST => $method,
        CURLOPT_HTTPHEADER => $headers,
        CURLOPT_POSTFIELDS => $content,
                CURLOPT_HEADER=>true
];
$ch = curl_init ();
curl_setopt_array ( $ch, $options );
// curl実行。
$res = curl_exec ( $ch );

実行結果。

HTTP/1.1 200 OK
Date: Fri, 28 Oct 2016 04:32:22 GMT
Server:  
ETag: "ad74d3059a5f047882fc138a1ab7ac86"
Content-Length: 0
Accept-Ranges: bytes
x-amz-request-id: tx00000000000000157130e-005812d4d6-612bb3-default
Connection: close
Content-Type: text/plain; charset=UTF-8

GetObject

$bucket = 対象バケット名;
$endpoint = "https://jp-east-2.os.cloud.nifty.com";
$file = ダウンロードオブジェクト名;
$type = '';
$method = 'GET';
$md5 = '';
$date = gmdate ( \DateTime::RFC2822 );
$resource = "/$bucket/$file";
$stringToSign = $method . "\n" . $md5 . "\n" . $type . "\n" . $date . "\n" . '' . $resource;
// シグネチャーを生成。
$signature = base64_encode ( hash_hmac ( 'sha1', $stringToSign, SECRET_KEY, true ) );
$auth = "AWS " . ACCESS_KEY . ":" . $signature;
// リクエストヘッダを作成。
$headers = [ 
        "Date: ".$date,
        "Authorization: ".$auth 
];
$options = [ 
        CURLOPT_URL => $endpoint . $resource,
        CURLOPT_CUSTOMREQUEST => $method,
        CURLOPT_HTTPHEADER => $headers,
                CURLOPT_HEADER=>true
];
$ch = curl_init ();
curl_setopt_array ( $ch, $options );
// curl実行。
$res = curl_exec ( $ch );

実行結果。

HTTP/1.1 200 OK
Date: Fri, 28 Oct 2016 04:33:55 GMT
Server:  
Content-Length: 85
Accept-Ranges: bytes
Last-Modified: Fri, 28 Oct 2016 04:32:22 GMT
ETag: "ad74d3059a5f047882fc138a1ab7ac86"
x-amz-request-id: tx000000000000001570ce0-005812d533-6180f2-default
Connection: close
Content-Type: text/plain; charset=UTF-8

PutObject・GetObjectともに「HTTP/1.1 200 OK」と200応答が返され、正常に処理されていることがわかります。

Bash

オブジェクトストレージにおいてBash経由でファイルのアップロード・ダウンロードができることを確認します。 基本的なフローは前述のPHPと同じです。

動作環境

項目 値
Bashバージョン 4.1.2

PutObject

file=アップロードファイル名
bucket=対象バケット名
endpoint="jp-east-2.os.cloud.nifty.com"
resource="/${bucket}/${file}"
contentType="text/plain"
date="$(LC_ALL=C date -u +"%a, %d %b %Y %X %z")"
stringToSign="PUT\n\n${contentType}\n${date}\n${resource}"
#シグネチャーを生成。
signature=`${ECHO} -en ${stringToSign} | ${OPENSSL} sha1 -hmac ${secretKey} -binary | base64`
${CURL} -X PUT -T "${file}" \
  -H "Host: ${endpoint}" \
  -H "Date: ${date}" \
  -H "Content-Type: ${contentType}" \
  -H "Authorization: AWS ${accessKey}:${signature}" \
  https://${endpoint}/${bucket}/${file} -v

実行結果。

< HTTP/1.1 200 OK
< Date: Fri, 28 Oct 2016 04:40:06 GMT
< Server:  
< ETag: "4729f35bda896cb0c0c7712c333384af"
< Content-Length: 0
< Accept-Ranges: bytes
< x-amz-request-id: tx0000000000000015711e7-005812d6a6-6180f2-default
< Connection: close
< Content-Type: text/plain; charset=UTF-8

GetObject

file=ダウンロードオブジェクト名
bucket==対象バケット名
endpoint="jp-east-2.os.cloud.nifty.com"
resource="/${bucket}/${file}"
contentType=""
date="$(LC_ALL=C date -u +"%a, %d %b %Y %X %z")"
stringToSign="GET\n\n${contentType}\n${date}\n${resource}"
#シグネチャーを生成。
signature=`${ECHO} -en ${stringToSign} | ${OPENSSL} sha1 -hmac ${secretKey} -binary | base64`
${CURL} -X GET -T "${file}" \
  -H "Host: ${endpoint}" \
  -H "Date: ${date}" \
  -H "Authorization: AWS ${accessKey}:${signature}" \
  https://${endpoint}/${bucket}/${file} -v

実行結果。

< HTTP/1.1 200 OK
< Date: Fri, 28 Oct 2016 04:41:05 GMT
< Server:  
< Content-Length: 82
< Accept-Ranges: bytes
< Last-Modified: Fri, 28 Oct 2016 04:40:06 GMT
< ETag: "4729f35bda896cb0c0c7712c333384af"
< x-amz-request-id: tx000000000000001570acf-005812d6e1-618170-default
< Connection: close
< Content-Type: text/plain; charset=UTF-8

PutObject・GetObjectともに「HTTP/1.1 200 OK」と200応答が返され、正常に処理されていることがわかります。

まとめ

  • 上記すべてのサンプルプログラムにおいて、200応答（正常応答）を得ることができました。
  • 動作を保証するわけではありませんが、PutObject・GetObjectについてはPHP・Bashからでも利用できることを確認しました。

注意事項

  • 本サンプルプログラムの使用は利用者の自己責任となります。
  • 本サンプルプログラムによって生じたいかなる損害についても、当社は責任を負いかねます。

ニフティクラウド NAS 「標準」と「高速」の比較結果

未分類 dbench NAS

こんにちは。ニフティクラウドテクニカルアカウントエンジニアチームです。

2016年11月21日にニフティクラウド NASの新タイプ「標準」がリリースされました。 ※今まで提供されていたNASは「高速」タイプとなります。

今回は「標準」タイプ、「高速」タイプの性能比較を行いたいと思います。 仕様や料金などの詳細につきましては、以下のページをご確認ください。 > ニフティクラウド NAS

nas

続きを読む

RDB新タイプ「MySQL 5.7」の性能を計測

ベンチマーク・検証 MySQL RDB

こんにちは。ニフティクラウドテクニカルアカウントエンジニアチームです。

2016年11月21日にニフティクラウドRDBにて、MySQLの新バージョン「MySQL 5.7」がリリースされました。 今回はすでに提供中の「MySQL 5.6」の最新バージョンと新たにリリースした「MySQL 5.7」にて性能比較を実施し、その結果をご紹介します。

logo-mysql-170x115

続きを読む

オブジェクトストレージを使って爆速自作CDN作ってみた

オブジェクトストレージ 未分類 CDN DNS Fastly LBR Varnish

こんにちは。ニフティクラウド ストレージサービスチームの吉田です。

ニフティクラウドは、東日本／西日本／北米から選択できるマルチリージョン対応となっています。 今回は、複数のリージョンとオブジェクトストレージを活用して簡単に自作できるキャッシュサーバーの構築方法をご紹介させていただきます。また、キャッシュサーバーを複数のリージョンに構築して簡単なCDNを作成することもできますので、その方法もあわせてご紹介いたします。

なお、ニフティクラウドでは「fastly」という低価格で高機能なCDNサービスの提供も行っていますので、本格的にCDNを導入したい方はCDN（Fastly）をぜひご利用ください。

CDN（コンテンツ・デリバリー・ネットワーク）とは？

CDN（コンテンツ・デリバリー・ネットワーク）とは、Web上の動画や画像などのコンテンツを配信するのに最適化されたネットワークのことです。このWeb上の動画や画像などのコンテンツを分散配置したキャッシュサーバーの中から、ユーザーに最も近い経路にあるサーバーがオリジンサーバーに代わってコンテンツを配信するという仕組みです。 CDNを導入することで、コンテンツのキャッシュによってオリジンサーバーの負荷を軽減し、配信を高速化することができます。また、経由するルーターが少ないキャッシュサーバーから応答するため、遅延時間が少なくなり、より早くコンテンツを返すことが可能となります。

自作キャッシュサーバー、CDNについて

自作キャッシュサーバー、CDNの構築について簡単に説明します。 配信するコンテンツは、ニフティクラウドのオブジェクトストレージ上に配置します。そのコンテンツをキャッシュできるようにニフティクラウドでサーバーを作成し、キャッシュサーバーを構築します。 そして、ニフティクラウドの各リージョン（今回はeast-1~3,west-1,us-east-1）へ同様にキャッシュサーバーを構築します。 最後にドメインを取得し、同じホスト名でアクセスしたときに、ユーザーに近いキャッシュサーバーから応答をするようにすることでCDNを構築します。

今回、使用する環境の情報は以下の通りとなります。

[markdown] |構築リージョン|OS|ミドルウェア|ベンチマークツール| |-|-|-|-| |east-1,east-2,east-3,west-1,us-east-1|CentOS7.1 64bit Plain|Varnish 4.1|Apache Bench| [/markdown]

cdn

1.コンテンツの配置

まずはニフティクラウドのオブジェクトストレージ上に、配信したいコンテンツをアップロードします。今回は以下の画像を使用します。

ttl_top_niftycloud01

オブジェクトストレージへのアップロード

オブジェクトストレージへのアップロードは、コントロールパネルから簡単に行うことができます。 まずはコントロールパネルからバケットを作成します。公開レベルはprivateのままで大丈夫です。

createbucket

作成したバケットの中に先ほどの画像をアップロードします。アップロードしたオブジェクトは後ほどキャッシュサーバーからアクセスするため、今回は簡単に公開レベルをpublic-readに設定します。

uploadfile

これでファイルのアップロードが完了しました。 アップロードしたファイルのURLの取得も簡単に行うことができます。

url-obj

2.キャッシュサーバー作成

続いてキャッシュサーバーを作成します。

まずは、ニフティクラウドのコントロールパネルからサーバーを作成します。今回はeast-2にCentOS7.1 64bit Plainでサーバーを作成いたします。 サーバー作成方法については、以下のページをご確認ください。

ニフティクラウドは本当に5分以内でサーバー作成できるのか？【動画あり】

Varnish

今回は、Varnishでキャッシュサーバーを構築します。Varnishはリバースプロキシを提供するためのミドルウェアで、ウェブコンテンツのキャッシュ機能を備えており、簡単に設定することができます。 まずは、Varnishをインストールします。なお、インストールについては、自己責任でお願いいたします。 参考：Installation on Red Hat Linux

yum install epel-release
rpm --nosignature -i https://repo.varnish-cache.org/redhat/varnish-4.1.el7.rpm
yum install varnish

続いて転送先ホストの設定をします。 先ほどの画像のURLのjp-east-2.os.cloud.nifty.comの部分を転送先に指定します。ポート番号は、今回は簡単にするために80番に設定します。 vim /etc/varnish/default.vcl

backend default {
    .host = "jp-east-2.os.cloud.nifty.com";
    .port = "80";
}

Varnishの待ち受けポートを80番に変更します。 vim /etc/varnish/varnish.params

VARNISH_LISTEN_PORT=80

それでは、Varnishを起動してみましょう。

systemctl start varnish

systemctl status varnish

起動ができたら、実際にアクセスして画像が表示されるか確かめて見ましょう。 ブラウザで http://サーバーのIPアドレス/バケット名/オブジェクト名 を入力し、先ほどの画像が表示されれば成功です！

varnish-check ついでに、Varnishの自動起動設定をしておくと、後ほど紹介するサーバーのイメージ化をするときに便利です。

systemctl enable varnish

3.Varnish ベンチマーク

では、キャッシュサーバーでコンテンツをキャッシュすると、実際にどれだけ応答が速くなるのかベンチマークを取ってみたいと思います。 また、北米リージョン（us-east-1）にも、先ほどeast-2に構築したキャッシュサーバーと同じものを構築し、北米リージョンからの応答の速さも見てみたいと思います。

比較対象は、オブジェクトストレージへ直接アクセスした場合、east-2のキャッシュサーバー、us-east-1のキャッシュサーバーで行います。 ベンチマークツールは、Apache Benchを使用し、east-2にアクセス用のサーバーを構築してベンチマークを取りたいと思います。 今回は、総アクセス数を40000、同時接続数を200に設定します。

まずは、オブジェクトストレージの方に直接リクエストした場合のベンチマークを取ります。

ab -n 40000 -c 200 https://バケット名.jp-east-2.os.cloud.nifty.com/オブジェクト名

結果は以下の通りとなります。

obj%e7%9b%b4%e6%8e%a5-n40000c200

続いてeast-2のVarnishを導入したキャッシュサーバーを経由して画像を取得するリクエストのベンチマークを取ります。

ab -n 40000 -c 200 http://east-2サーバーのIPアドレス/バケット名/オブジェクト名

結果は以下の通りとなります。

varnish-n40000c200

最後にus-east-1のVarnishを導入したキャッシュサーバーを経由して画像を取得するリクエストのベンチマークを取ります。

ab -n 40000 -c 200 http://us-east-1サーバーのIPアドレス/バケット名/オブジェクト名

結果は以下の通りとなります。

us-east-1-ab

直接アクセスした場合 Varnish Cache
east-2		 Varnish Cache
us-east-1
1秒間あたりの処理リクエスト数[#/sec] 778.78 1556.15 236.98
1リクエストあたりの処理時間[ms] 1.284 0.643 4.220

reqpersec ms

オブジェクトストレージに直接アクセスした場合とeast-2のキャッシュサーバーの結果を見ると、しっかりとキャッシュサーバーとしての役割を果たしているようです。 やはりVarnishを導入してキャッシュした方がリクエスト処理速度が早いですね。

しかし、北米リージョン（us-east-1）のキャッシュサーバーは流石に遅いようです。 当然ですがコンテンツをキャッシュしてもネットワーク的に遠すぎてはキャッシュサーバー導入による高速化は期待できません… キャッシュサーバーによる高速化を図るなら、アクセス元に近いサーバーからコンテンツを配信したいですね。

4.各リージョンにキャッシュサーバー構築

ここからは自作CDNに入っていきたいと思います。 ニフティクラウドは、東日本、西日本、北米の複数リージョンがあります。その各リージョンにキャッシュサーバーを構築します。 今回は、east-1～3、west-1、us-east-1にそれぞれキャッシュサーバーを構築したいと思います。先ほど、Varnishを導入したキャッシュサーバーはeast-2に構築しましたので、そのサーバーのイメージを作成し、イメージからほかのリージョンにキャッシュサーバーを構築したいと思います。

サーバーイメージ作成

まずは、先ほど作成したサーバーを停止します（完全に停止するまで少々時間がかかります）。 サーバーが完全に停止したら、選択したサーバーの操作から、「イメージとして保存」を選択します。 すると、以下の画面になりますのでイメージ名と保存先リージョンを決定し、イメージを作成してください（イメージの作成には少々時間がかかります）。

serverimagecap

イメージからサーバー作成

イメージの作成が完了したら、そのイメージから別リージョンにサーバーを作成します。 まずはeast-1でイメージからサーバーを作成したいと思います。通常のサーバー作成と同様に、「サーバー作成」を選択してください。 次に、OSイメージ選択画面で、イメージ種別の「自分のイメージ」を選択してください。

serverimagecap3

すると、先ほど作成したイメージが表示されますので選択し、あとは通常通りサーバーを作成してください。 これでeast-1にvarnish導入済みのキャッシュサーバーが構築されました。上記のVarnish導入時に自動起動設定をしておけば、Varnishの手動起動や設定などはせずにキャッシュサーバーとして稼動します。 同様にeast-3、west-1、us-east-1にもイメージからサーバーを作成してください。

5.ドメイン取得

ドメインの取得もニフティクラウドのコントロールパネルから簡単にできます。 取得したいドメインを入力し検索すると、取得可能なドメインが表示されます。利用規約を確認し、Whois情報登録をすれば簡単に取得できます。

getdomainname

6.DNS設定

最後にユーザーに近いリージョンのサーバーからコンテンツを配信するために、DNSを使用します。 ニフティクラウドDNSでは、LBR（レイテンシーベースルーティング）という、1つのホスト名に複数のIPアドレスが紐付けられている場合、アクセス元の最寄りのサーバーに接続させることができる機能があります。 これで上記ベンチマークの北米リージョンのように、キャッシュサーバーによる高速化を図れないという残念な事態を回避できます。

ゾーン登録

取得したドメインをDNSのゾーンに登録します。 「DNSゾーン登録」を選択し、取得したドメインを登録してください。

dnszone

レコード登録

ゾーン登録が完了したら「レコード新規作成」を選択し、DNSのAレコードへ、レコード名および各リージョンに作成したキャッシュサーバーのIPアドレスを登録します。 この時、レコード名は日本国内のリージョン（east-1～3、west-1）は同じ値を、北米リージョン（us-east-1）は別の値を入力してください。

record dnsarecord

LBR（レイテンシーベースルーティング）

続いて、北米からのアクセスは北米のキャッシュサーバーから、国内からのアクセスは国内のキャッシュサーバーから応答をするようにニフティクラウドのLBR（レイテンシーベースルーティング）機能を使用して実現します。 コントロールパネルから「レコード新規作成」を選択し、タイプのプルダウンから「LBR」を選択してください。 ここで入力したレコード名でアクセスすることで、ユーザーに近いサーバーから応答することができます。 値には、指定エリア以外からアクセスがあった場合にアクセスさせるレコード名を選択してください。 「追加」ボタンを押すと、エリアとアクセスさせるレコード名を選択できます。日本と北米でそれぞれ先ほど登録したレコード名を選択してください。 また、日本で選択するレコード名は1つにしてください。

lbr

では、実際にアクセスしてみたいと思います。わかりやすいように、北米リージョン（us-east-1）にアクセス用のサーバーを構築し、北米リージョンのキャッシュサーバーから応答が返ってくるかを見てみたいと思います。

us-east-1-access

接続しているサーバーのIPアドレスが北米リージョンのサーバーのIPアドレスになっていますので、アクセス元に近いサーバーに接続できていることがわかりました。

CDN完成

これで、「ニフティクラウドを活用した簡単自作CDN」が完成しました！ 最後にブラウザでアクセスしてみます。

cdncheck

このように、ニフティクラウドとオブジェクトストレージを活用すれば、簡単に自作CDNを構築することができます。CDNを検討中だけど本格的なCDNの前にCDNを体感したいという方、またCDNに興味のある方、ぜひお試しください。