こんにちは、エバンジェリストの藤城（@tafujish）です。

以前にAerospikeのMeetupで登壇させてもらったときに、ブログ書く書く言って長らく書けていなかったのですが、金杉がお試し記事を書いてくれました。

blog.idcf.jp

Aerospikeって何という方はそちらを読んでいただき、ここではAerospikeをIDCFクラウド上で使うのがなぜ適しているのかやベストプラクティスを紹介したいと思います。

$ ethtool -i eth0
driver: vmxnet3
～以下、略～

$ sudo dd if=/dev/zero of=/dev/sdb bs=1M
dd: writing `/dev/sdb': デバイスに空き領域がありません819201+0 records in819200+0 records out858993459200 bytes (859 GB) copied, 2078.7 s, 413 MB/s

storage-engine device { 
    file /aero/test.dat 
    filesize 64G 
}

storage-engine device { 
    device /dev/sdb 
    device /dev/sdc 
    write-block-size 1024K 
}

・./benchmarks -h<IP Address>-k4000000-o S:2048-w RU,50-z64

2016年11月25日、IDCFクラウドに新しいリージョンが追加され、あわせて「GPU BOOSTタイプ Tesla M40」がリリースされました。 www.idcf.jp

ディープラーニング等、通常のCPUでは計算性能が足りなくなるシーンでの利用を想定したGPU搭載仮想マシンです。本記事では、GPUを使い始めるための手順について紹介いたします。

1. GPUコンピューティング

GPUコンピューティングとは

主に3DCGなどの画像処理を行うデバイスであるGPUを、計算分野で利用することをGPUコンピューティングといいます。 昨今の「ディープラーニング（深層学習）」「ビッグデータ」「IoT」「AI（人工知能）」「機械学習」など注目ワードには、GPUコンピューティングが密に関係しています。

なぜGPUを利用するのか

CPUとGPUは、それぞれ下記の特徴をもちます。

• CPU：数コア～数10コアを持ち、逐次処理が得意
• GPU：数百コア～数千コアを持ち、並列処理が得意

このそれぞれの特徴を活かして、逐次処理をCPU、並列処理をGPUに割り当てることで、CPU単体よりも圧倒的な速度で演算することができます。

2. IDCFクラウド GPU BOOSTタイプの特長

大容量GPUメモリ搭載のGPUを採用

「GPU BOOSTタイプ Tesla M40」は名前の通りNVIDIA Tesla M40 (24GBメモリ版)を搭載しています。ディープラーニングなどのGPUを用いた計算では、GPUメモリ容量がボトルネックになりやすいため、Tesla M40の中でもGPUメモリが多い24GB版を採用しています。

専有タイプで他仮想マシンからの性能影響無し

GPU BOOSTタイプは1物理サーバーに1台だけ仮想マシンが稼働する占有タイプとして提供しているため、共有環境で発生しうる、他の仮想マシンからの負荷による影響を受けず、物理サーバーの全性能を使う事が出来ます。

IDCFクラウドの通常の仮想マシンと同じ操作で利用可能

GPU BOOSTタイプは通常の仮想マシンと全く同じ操作で作成・削除などが実施できます。また課金についても上限金額ありの従量課金となっております。ただし、ハードウェア占有タイプである事と、GPUを仮想マシンに直接認識させているため、以下の制限があります。

• 仮想マシンが起動した状態でのボリュームのスナップショットの取得ができません
• 物理サーバーが故障などで停止した場合の別サーバーへのフェイルオーバー機能はありません

3. GPUを利用するためのCUDAライブラリの導入方法

Tesla M40などのNVIDIA社製GPUを用いて計算を行うためには、GPUのドライバと計算を行うためのCUDAライブラリを導入する必要があります。本記事では、IDCFテンプレート「CentOS 7.2 64bit」仮想マシンを前提に、CUDAライブラリのインストール手順を解説いたします。

GPU BOOSTタイプの仮想マシンの作成

GPU BOOSTタイプは現時点では「東日本リージョン2(jp-east-2)」でのみ提供しています。そこで、仮想マシンを作成するためにIDCFクラウドのポータルから東日本リージョン2のコンピューティングを選択します。

次に、仮想マシン一覧画面から「仮想マシン作成」をクリックします。

仮想マシン作成画面で、ゾーンを「weber」もしくは「lux」を選択し、次の「マシンタイプ」で「GPU」タブをクリックします。するとマシンタイプ一覧に「gpu.7XLM40」が表示されるので、選択します。

以後は通常の仮想マシンと同じように設定します。ここではテンプレートとして「CentOS 7.2 64bit」を利用して、設定を確認の上で作成を実行します。

CUDAインストール用のレポジトリRPM取得とインストール

NVIDIA社のCUDA Toolkit配布サイトから、次の図のようにOS等を選択します。そして図内の「rpm (network)」をクリックし、RPMをダウンロードします。

ダウンロードしたRPMをGPU BOOSTタイプの仮想マシンにアップロードし、以下のコマンドでインストールを行います。

$ sudo rpm -i cuda-repo-rhel7-8.0.44-1.x86_64.rpm
警告: cuda-repo-rhel7-8.0.44-1.x86_64.rpm: ヘッダー V3 RSA/SHA512 Signature、鍵 ID 7fa2af80: NOKEY
(以下省略)

CUDAライブラリのインストール

CUDAおよびNVIDIAドライバを配布するレポジトリ情報が登録されたので、次はCUDAのインストールを行います。

$ sudo yum clean all
読み込んだプラグイン:fastestmirror, remove-with-leaves, show-leaves
リポジトリーを清掃しています: base cuda epel extras updates
Cleaning up everything
Cleaning up list of fastest mirrors

$ sudo yum install cuda
(以下省略、大量のパッケージが導入されます）

万一、パッケージのダウンロードやインストールが一部失敗するようなことが発生した場合は、yum clean allから再インストールをもう一度実行します。インストールが無事に完了したら、仮想マシンのOS再起動を実行します。

GPUが認識された事の確認

NVIDIAドライバが導入され、正常に認識されると、nvidia-smiコマンドでGPUのステータスが確認できます。

# nvidia-smi
Tue Nov 22 15:00:36 2016       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 367.48                 Driver Version: 367.48                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla M40 24GB      Off  | 0000:03:00.0     Off |                    0 |
| N/A   39C    P0    60W / 250W |      0MiB / 22939MiB |    100%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

なお、正常にGPUが認識されていない場合は、以下のようなエラーが表示されます。

# nvidia-smi 
modprobe: FATAL: Module nvidia not found.
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

再起動後も上記のエラーが表示された場合、もう一度OS再起動をすると認識される場合があります。

以上でGPUを利用するためのCUDAライブラリの導入が完了しました。ディープラーニングで利用するためには、下記のような各種フレームワークを導入する必要があります。

• Tensorflow（https://www.tensorflow.org/）
• Chainer（http://chainer.org/）
• Caffe（http://caffe.berkeleyvision.org/）

フレームワークの導入に関しては、今後の記事で紹介していきたいと思います。

まとめ

• ディープラーニングするにはGPUコンピューティングによる強力な計算リソースが必要
• IDCFクラウドなら、GPU「NVIDIA Tesla M40」搭載の仮想マシンを利用可能
• CUDAのインストール・フレームワークの導入だけですぐ使える

IDCFクラウド「GPU BOOSTタイプ Tesla M40」のパワーを、ぜひ体験してみてください！

こんにちは！ソリューションアーキテクト部の金杉です。

12/15(木)のアップデートで、IDCFクラウドのILBのノードに対してMackerelを使った監視ができるようになりました。今まで、ILBに対しての監視サービスは提供されていなかったので、これでパフォーマンス調査やトラブルシューティングがだいぶ楽になりますね。

ちなみにILBもMackerelも過去の記事で紹介してきましたが、ILBとはIDCFクラウド上で動作するオートスケール可能なロードバランサーで、Mackerelは株式会社はてなが提供するエージェント型のリソース監視ツールです。詳しくは、以下の記事を参考にしてください。

Mackerel関連記事
Mackerelブログリレー『第1回　新人がIDCFクラウドでMackerelを使ってみた』Mackerelブログリレー『第2回　新人がMackerelにホスト登録してみた』

ILB関連記事
ILBを使ってWebサーバーをバランシング！構成事例もご紹介

はじめに

今回のアップデートのポイントを3つにまとめてみました。 ポイントの紹介後に、早速導入をしてみます。

1. Mackerelの導入が簡単かつ無料

ILBに対してのMackerel導入はとても簡単で、エージェントのインストールやコンフィグの書き換えなどの手間は一切不要です。設定の際にチェックを一つ入れて、APIキーを貼り付けるだけのめちゃ楽作業です。そして、無料です😉

また、Mackerelインターフェイスでのメトリックグラフもすでに定義済みなので、手動で設定する必要もありません。現在は、以下3つの項目が見れるようになっています。項目ごとの説明はステップ③を参考にしてください。
1) Health Check Errors
2) Sessions
3) Traffics

2. UXを重視した見せ方

Mackerelを使って監視をする時、通常はサーバー1台ごとにリソースグラフが表示されますが、ILBでMackerelを使うとすべてのノードの状態をまとめて表示してくれます。

前提として、ILBは負荷に応じてオートスケールする（ノード数が増える）という特徴があります。しかし、ILBを監視する立場になると、ノード単体のリソース状況よりも全体のリソース状況が気になりますよね。よって、今回のアップデートではILBの全ノードを一体化したUX重視な見せ方を採用しています。

3. 稼働中のILBにも適用OK

「ええ！すごいじゃん！でもILBずっと昔に立てちゃったよ...」という方も、心配不要です！Mackerelの実装は、稼働中のILBに対しても可能です👌 新規ILBとほぼ同様の方法で導入できるので、同じ手順を参考にしてください。

ILBにMackerelを導入してみる

それでは、早速ILBにMackerelをインストールしてみましょう。インストールには必ずMackerelのAPIキーが必要になってくるので、まずはMackerelの画面でAPIキーを確認し、その次にILBに対してインストールの手順を紹介します。

IDCFクラウドコンソールの上にカーソルを移動するとサービス一覧がでるので、そこからMackerelとILBの管理画面が開けます。

①事前準備〜Mackerel API Keyを確認〜

まずはMackerelの管理画面に移動します。IDCFクラウドからはシングルサインオンができるので、便利です。新規登録ができていない方は、ぜひこれを機会に登録してみてください。無料で使える特典プランもあります。

左のメニューから対象のオーガニゼーションを選択します。続いて「APIキー」のタブをクリックします。ここでAPIキーのコピーができます。一番右のアイコンをクリックするとそのままコピーしてくれますのでぜひ活用ください。

これでMackerelのAPIキーの確保ができましたので、ILBの設定に移ります。

②ILBにMackerelを導入

新規ILBに対してMackerelを導入する場合、まずILBの作成を行います。画面右上にある「ILB作成」をクリックします。 既存のILBの場合は、直接対象となるILBのILB名をクリックし、直接オプション入力のステップに移ります。

●パラメーター入力
ロードバランサーのネットワーク、FQDN、Configurationなどのパラメーターを入力します。設定で迷ったら、こちらの記事を参考にしてみてください。

●オプション入力
一通り設定が終わったら、オプションの入力をします。Mackerelのインストールもここで選択します。
「リソース監視」の欄にチェックを入れたら、APIキーの入力欄が表示されるので、先ほど確認したMackerelのAPI Keyをペーストします。Firewallの設定も適宜入れます。終わったら、「確認画面へ」をクリックし、問題なければ作成をします。

③MackerelでILBの様子を確認

ILBの画面にもどって、作成したILBのステータスがRunningになったらMackerelの画面で確認してみましょう。

Mackerelのダッシュボードで「Hosts」を確認すると、ILBのFQDNが表示されていて、ステータスがWorkingになっているはずです。

上図のホスト名をクリックすると、各種メトリックグラフが見えます。例のILBでは、Webサーバー2台を分散させています。(10.15.0.98と10.15.0.245) 　　▲Health Check Errorsのメトリック
ILBから分散先サーバーに対してのヘルスチェックの結果を見ることができます。値が1の時はヘルスチェック結果がエラーで、値が0の時はヘルスチェックが正常に通っているということになります。

　　▲Sessionsのメトリック
分散先サーバーごとのセッション数を見ることができます。さらにcurrentとrateで分かれており、currentは現在のセッション数で、rateは秒間の新規セッション数を表しています。
また、totalの値も見ることができます。currentのtotal値は分散先サーバーの合計のセッション数で、rateのtotal値は分散先サーバーの合計の新規セッション数です。

　　▲Trafficsのメトリック
分散先サーバーごとの秒間トラフィックを見ることができます。さらにtxBytesとrxBytesと分かれており、txBytesは秒間送信バイト数で、rxBytesは秒間受信バイト数を表しています。 （※単位はMbpsではなく、Mbytes/secなのでご注意くださいね）
トラフィックも同じく、totalの値を見ることができます。txBytesのtotal値は、各サーバーの秒間送信トラフィックの合計値なので、ILBの秒間トラフィックとも解読できます。今ままではIDCFクラウドのビリングより合計転送量のみ確認できましたが、今後は秒間トラフィックも確認できるのでとても便利です！

これで、ILBに対してのMackerelの導入は完了となります。監視ルールでもこれらのメトリックに対して設定を行えます。

さいごに

ILBのリソース状況が知りたい！という時は、ぜひこの記事に沿ってMackerelをインストールしてみてください。メリットは先ほどもありました通り、以下3点です。
1) 簡単かつ無料👍
2) 見やすい👍
3) 新規/既存のILBどちらも適用可能👍

Mackerelについては以前もたくさん紹介してきましたが、毎日進歩しています。IDCFクラウドとも非常に相性がいいので、ぜひ仮想ルーターやホスト監視などでも活用してみてください。

はじめましてみなさん、コンテンツマーケティング部の河田です。
おもにIDCフロンティアのコーポレートサイトの運営を担当しています。

当社のことをみなさんに知っていただく看板サイトとして、日々、新サービスの紹介やイベント、キャンペーン情報などを発信し続けています。
本日は、IDCFクラウド上で稼働しているコーポレートサイトを運用し続けるための仕組みを次のポイントに分けてわかりやすくご紹介していきたいと思います。

はじめに

今回お伝えしたい内容がこちらです。

• 24時間365日運営できるサイト作り
• サイトを守るために必要な３つの対策
  • GSLBによる広域負荷分散
  • DDoS対策サービスの導入
  • WAFの活用
• 実際に障害が起こってしまったら
• 最後に

前提となるWeb上の脅威のお話から、具体的な対策方法、障害発生時への備えまで一連の流れでご紹介したいと思います。では早速、本題に入りましょう。

24時間365日運営できるサイト作り

Webの世界にはリアル社会のように年末年始の休業期間などはありません。 基本的に24時間365日、サイトを運用し続けることが前提となります。
そしてWeb上でサービスを提供しているかぎり尽きないのがサイバー攻撃の脅威です。
中でもコーポレートサイトのような会社のブランディングに直結するサービスには DDoS攻撃などが猛威を振るってきます。 TCP・SYNフラッド、UDPフラッド、DNSアンプ、Low and Slow攻撃など、その種類は上げればきりがないくらい存在します。
また、それぞれの攻撃が狙うターゲットレイヤーも異なり、その規模もどんどん大きくなってきています。

こうした悪意のある攻撃からサイトを守るためには、単純にサーバーを強化するだけでは対策不足です。ネットワークインフラからサーバーまで一貫した対策が必要になります。

サイトを守るために必要な３つの対策

IDCFのコーポレートサイトは、これからご説明する3つのサービスを用いてセキュリティ対策を実現しています。
では、実際にどのような取り組みをしているのか簡単にご紹介していきます。

1)GSLBによる広域負荷分散

サイバー攻撃に関わらず、人為的なミスや大規模災害などが起きて、サーバーに何らかの障害が発生した場合、ただちにGSLBは登録されているディザスタリカバリ（DR）サイトへ自動でアクセスを切り替え、ダウンタイムを 最小限に抑えてくれます。
通常のロードバランサーと違い、東西の拠点でロードバランシングを行うため、より一層可用性が担保されます。アクセス数の多い都心部からのレイテンシを考慮し、プライマリサイトを東日本に構築していることもポイントです。
そして、拠点間でのコンテンツ同期やバックアップを行い、さらにプライベートコネクト接続で セキュアな通信網を利用すればベストです。

▲GSLBによるDRサイトへの自動切り替わりイメージ

2)DDoS対策サービスの導入

このDDoS対策サービスというのは、トラフィックがサーバーに届くより前の段階のネットワーク領域でDDoS攻撃を緩和、防御してくれます。

もう少し詳しく説明すると、以下のフローを自動で行います。
1. ネットワーク上の振る舞いから悪意のあるトラフィックを検知する
2. そのトラフィックを遮断するためのシグネチャを自動生成（動的シグネチャ※）
3. フィルタリングを実行

既知の攻撃手法に対しての防御は不正侵入検知/防御サービス（IDS/IPS）で対応可能ですが（静的シグネチャ）、未知の攻撃や巧妙に細工された攻撃にはこのDDoS対策サービスが特に効果を発揮します。

※静的シグネチャとは、既知の攻撃パターンをデータベース化して管理した上で、該当する攻撃をフィルタリングする方式です。

3)WAFの活用

WAFとはWeb Application Firewallの略称で、一般的によく知られているFirewallがポート、IP制限などのネットワークレイヤーの不正アクセスを防ぐのに対して、WAFは「SQLインジェクション」や「XSS」などのWebアプリケーションを狙った攻撃を防御してくれます。

例えば、お問い合わせなどのフォームからサーバーへ送られる入力データのチェックを行い、不正なデータが渡されないようにします。つまりサーバーとクライアントの間に立って通信を遮断し、Webアプリケーションを防御してくれます。

しかしながら、WAFを導入すればすべてのWebアプリケーションの脆弱性対策ができるかというと、答えはNOです。 あくまで暗号化された通信（SSL）上でのセキュアなプログラミングや適切なサーバー設定の漏れを補完することが目的です。

▲各レイヤーによりサイバー攻撃を防御する対象が異なる

こうしたネットワークサービスを導入することで、一定のサイバー攻撃からサイトを守ることができます。 しかもその負荷を専用機器でまかなうことができるため、Webサーバーに無駄な負荷をかけずに済みます。
SSLの暗号化・復号処理をサーバーではなく、ロードバランサーで行っていることもポイントの一つです（SSLアクセラレーション）。 普段何気なくアクセスしているコーポレートサイトも、コンテンツへ到達するまでには 上図のような様々なサービスを通過して閲覧できているワケですね。

実際に障害が起こってしまったら

ここからは人や組織の対策です。
あまり考えたくないことですが、実際に問題や障害が発生してしまった時の行動を緊急時対応マニュアルとしてフローチャート形式でまとめることや、エスカレーション先を決めた表を作成する必要があります。
この時、自分ひとりですべての作業を差配している人は少ないと思います。複数の部署をまたいだ連携が必要になってくるハズです。そのため、物事の決定権が誰にあるのかを事前に決めておくことは非常に重要です。できれば担当部署だけでなく、担当者名まで決めておくことができれば安心です。
またその代理や、最悪、誰とも連絡がつかなかった場合などその条件は多岐に渡りますが、まずは自分の上司など身近なところから決めて行き、表を完成させていきましょう。

まとめ

今回は少し駆け足でコーポレートサイトの全体像をお伝えしました。
以上のことを踏まえてIDCFのコーポレートサイトはざっくりと下図のような構成になっています。

普段は個々のサービスとして独立して説明する機会が多いと思いますが、このように一連の流れで説明することで、それぞれのサービスが担当する守備範囲がわかりやすくなったのではないでしょうか。

要点をまとめてみます。

• GSLBによるDRサイト構築
• DDoS対策サービスを含むネットワークサービス（FW、IDS/IPS、WAF、LB）の導入
• SSLによる通信の暗号化
• セキュアなプログラミングや適切なサーバー設定
• コンテンツの同期とバックアップ
• 障害時の対応マニュアルの作成

これらがすべて揃って初めて24時間365日運営できるサイト作りが実現することになります。

最後に、今回取り上げたこれらのサービスを実際使ってみたいという方へのお知らせです。
中でもIDCFクラウド上で導入可能なGSLB（DNS）やプライベートコネクト、ILBならすぐにでも対策を始めることができます。 また、お申込みベースでDDoS対策サービスを含むIDCFネットワークサービスも利用可能です。

これを機にみなさんが運営されているサイトのリスクマネジメント対策を見直してみてはいかがでしょうか？

仮想環境や古いサーバーだと上記画像のように、CPU使用率が特定のコアに偏ることがあると思います。特に2番のCPUのsi（ソフトウェア割り込み）の値のみ大きいです。このような場合、マルチキューネットワークに対応することで複数のCPUコアを利用することができるためネットワーク性能をスケールすることができます。

この話はしばしば質問いただきますが、IDCFクラウドの仮想マシンのNICはRSS(Receive Side Scaling)に標準で対応しているので、マルチキューネットワークのためにこれといった操作や設定は不要です。

「以上です。」
で終わってしまいそうな話ですが、以下ではもう少し踏み込んでみるので、CPUの各コアの利用が偏っている場合は次を参照ください。だいたい多い話として、irqbalanceが入っていなかったり、ダイナミックスケール後の話だったり、ISOから作った仮想マシンだったりします。

# ethtool -i ens160
driver: vmxnet3
version: 1.4.7.0-k-NAPI
～略～

# ls /sys/class/net/ens160/queues/
rx-0  rx-1  rx-2  rx-3  tx-0  tx-1  tx-2  tx-3

# cat /proc/interrupts | grep ens160
  56:         39          0          0      44516   PCI-MSI-edge      ens160-rxtx-0
  57:          7      44132          0          0   PCI-MSI-edge      ens160-rxtx-1
  58:         16          0      44175          0   PCI-MSI-edge      ens160-rxtx-2
  59:         28          0          0      44739   PCI-MSI-edge      ens160-rxtx-3
～略～

# cat /proc/interrupts|grep ens160
  56:         39          0          0     268151   PCI-MSI-edge      ens160-rxtx-0
～略～

# cat /proc/irq/56/smp_affinity
00000000,00000000,00000000,00000008

# echo 1 > /proc/irq/56/smp_affinity
# cat /proc/irq/56/smp_affinity
00000000,00000000,00000000,00000001

# modprobe -r vmxnet3; modprobe vmxnet3

# ethtool -i ens35
driver: e1000
version: 7.3.21-k8-NAPI
～略～

# ls /sys/class/net/ens35/queues/
rx-0  tx-0

# echo f > /sys/class/net/ens35/queues/rx-0/rps_cpus

# echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
# echo 32768 > /sys/class/net/ens35/queues/rx-0/rps_flow_cnt

こんにちは！ソリューションアーキテクト部の金杉です。よくお客様からご質問をいただくので、本日はIDCFクラウドでセカンダリIPを取得する方法について紹介しようと思います。

はじめに

1つのネットワークインターフェイスに複数IPを割り当てたいというケースは多々ありますよね。例えばバーチャルホストを使って同じサーバーで複数ドメインを運営する時や、Virtual IP (VIP)を用いて冗長構成を実現したい時など、様々なシーンでセカンダリIPが必要になってきます。このような技術を一般的に"IPエイリアス"と呼び、元から割り当てられているIPと追加で取得したIPをそれぞれ"プライマリIP"、"セカンダリIP"と呼んだりします。

IDCFクラウドではセカンダリIPの取得が可能です。このブログではIDCFクラウドのサーバーでセカンダリIPの取得およびセカンダリIPアドレスをグローバルIPアドレスと紐づける方法を紹介します。

セカンダリIP取得の２つのパターンと手順

セカンダリIPの取得には以下2通りのパターンがあります。パターンによって、手順が異なりますのでご注意ください。区別がつかない場合は、図1を参考にしてみてください。

パターン1 (手順1)　セカンダリIP経由でインターネットと通信する場合
パターン2 (手順2)　セカンダリIP経由でインターネットと通信しない場合

　　　▲図1 セカンダリIP取得の際の2つのパターン

パターンによって手順が異なる理由は、IDCFクラウドのネットワーク仕様です。IDCFクラウドでは、コンピューティング環境とインターネットの間に仮想ルーターが存在します。対象のセカンダリIPがインターネットと通信をする場合、仮想ルーターを経由するので、セカンダリIPとグローバルIPを紐づける必要があります。一方、セカンダリIPがインターネットと通信をする必要がない場合、これらの操作が不要になります。なので、パターンによってセカンダリIPを取得する手順を両方紹介します。

仮想マシンのデプロイに関してはこちらを参考にしてください。

方法① インターネットと通信する場合

今回は、Light.S1(1コア, 1GBメモリ)の仮想マシンを使ってセカンダリIPを取得していきます。ホスト名はsecondary-ip-test、OSはCentOS 6.8を使用します。プライマリIPは10.32.0.122がDHCPで設定されています。

使用できるIPアドレスの確認

セカンダリIPとして使用できるIPアドレスは限られているので確認をします。IDCFクラウドコンソールより、左メニューバー「ネットワーク」、ターゲットのネットワーク名、「IPアドレス一覧」をクリックします。

DHCP範囲内(CIDRの前半)のIPアドレスが選択できます。つまり、このテーブルに表示されている割当済みのIPアドレスと、「割当範囲外」のIPアドレスを除いたすべてのIPアドレスがVIPとして割当可能です。セカンダリIPはDHCPもしくはスタティックで取得することが可能です。今回は10.32.0.100を指定して使います。

TIPS: DHCP範囲内のIPを選択する理由は？
今回、対象のセカンダリIPアドレスとグローバルIPアドレスを紐づける必要があります。紐づけるにはAPI経由でポートフォワードもしくはスタティックNATの2つの方法があるのですが、いずれも仮想ルーターに対しての操作になります。仮想ルーターに対してIPアドレス関連の操作を行う場合、その対象となるIPアドレスは仮想ルーターが認識できる必要があります。DHCP範囲外のIPアドレスは仮想ルーターでは認識できないので、ここではDHCP範囲内のIPアドレスを選択する必要があります。（でないと、グローバルIPアドレスと紐づけることができません。）

セカンダリIPアドレスの取得

手順①ではセカンダリIPアドレスの取得はCloudStack API経由で行います。IPアドレスの値は、先ほど確認した10.32.0.100をスタティックで付与します。APIに関しては、API Referencesをご参照ください。

IPアドレスを付与するに必要なコマンドはaddIpToNicです。必要なパラメーターおよび取得方法は以下になります。

IPアドレスの取得が完了した後、グローバルIPとセカンダリIPをenableStaticNatコマンドでスタティックNATします。必要なパラメーターおよび取得方法は以下になります。
※通常のスタティックNATの設定はIDCFクラウドコンソールからもできますが、今回はセカンダリIPを紐づけるため、操作はAPI経由で行う必要があります。

それでは、これらのコマンドを使って実際に操作をしてみましょう。

コマンドラインツールのインストール
APIを利用するにあたって、コマンドラインツールのインストールが必要になります。インストールするサーバーは、Pythonが動けばどのサーバーでもかまいません。APIのGetting Started ガイドに沿って「簡単な使い方：Step4」までを実行してください。

APIでセカンダリIPアドレスを取得

# 仮想マシンのid一覧を表示
[root@API-Server ~]# cloudstack-api listVirtualMachines -t displayname,id
+---------------------+--------------------------------------+
|    displayname      |                  id                  |
+---------------------+--------------------------------------+
|  secondary-ip-test  | dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6 |
+---------------------+--------------------------------------+
 
# secondary-ip-testのNIC idを表示
[root@API-Server ~]# cloudstack-api listNics --virtualmachineid dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6 -t ipaddress,id
+-------------+--------------------------------------+
|  ipaddress  |                  id                  |
+-------------+--------------------------------------+
| 10.32.0.122 | 0f25accf-06f8-4722-beda-508cc832c4ef |
+-------------+--------------------------------------+
 
# secondary-ip-testのNICにセカンダリIPアドレスを指定して割り当てる
[root@API-Server ~]# cloudstack-api addIpToNic --nicid 0f25accf-06f8-4722-beda-508cc832c4ef --ipaddress 10.32.0.100

# もう一度secondary-ip-testのNICの情報を表示
[root@API-Server ~]# cloudstack-api listNics --virtualmachineid dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6
 (略)
 "secondaryip": [
  {
    "id": "fadd1502-3aaa-4576-a05a-0d4eb1762265",
    "ipaddress": "10.32.0.100"
  }
]
(略)

IDCFクラウドコンソールでグローバルIPを取得する
まずは、スタティックNATで使用するグローバルIPをIDCFクラウドコンソールより取得します。標準で1個付与されているグローバルIPはスタティックNAT用に使用できませんのでご注意ください。

IDCFクラウドコンソールにログインしたら、対象のリージョン→コンピューティングを選択し、左の「IPアドレス」タブをクリックします。画面の右上にある「IPアドレス取得」をクリックします。

続いて、ポップアップが出てきたらIPアドレスの表示名と対象のネットワークを選択します。入力が終わったら右下の「取得する」をクリックします。

先ほどのIPアドレスの画面に戻ったら、新たにグローバルIPが追加されているのが確認できます。現在「NAT」の欄は"なし"となっていますが、後ほど対象の仮想マシン名(secondary-ip-test)が表示されます。

APIでセカンダリIPをグローバルIPとスタティックNATをする
それでは、先ほど取得したグローバルIPを10.32.0.100とスタティックNATします。

# 現在あるグローバルIPとそのidを表示
# 先ほど取得した210.140.43.145を使う
[root@API-Server ~]# cloudstack-api listPublicIpAddresses -t ipaddress,id
+----------------+--------------------------------------+
|   ipaddress    |                  id                  |
+----------------+--------------------------------------+
| 203.137.176.8  | eaa68c54-29a9-4ad1-bd93-32740e8bc15d |
| 210.140.42.154 | 7b469138-8504-4133-9c73-2d28ebde7aba |
| 210.140.43.145 | 17efd86a-9e2e-452a-ade9-d8b11610a091 |
+----------------+--------------------------------------+

# スタティックNATを有効化
[root@API-Server ~]# cloudstack-api enableStaticNat --ipaddressid 17efd86a-9e2e-452a-ade9-d8b11610a091 --virtualmachineid dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6 --vmguestip 10.32.0.100
{
  "enablestaticnatresponse": {
    "success": "true"
  }
}

スタティックNATのを確認
スタティックNATの設定が完了したら、ポータルから確認してみましょう。「NAT」の欄にsecondary-ip-testと表示されていますね。これで設定は完了です。

手順② インターネットと通信しない場合

手順②ではセカンダリIPアドレスの取得は直接OS内で指定して行います。手順①より簡単です。このブログではCentOS6系とCentOS7系両方のやり方を紹介します。

使用できるIPアドレスの確認
セカンダリIPとして使用できるIPアドレスは限られているので確認をします。IDCFクラウドコンソールより、左メニューバー「ネットワーク」、ターゲットのネットワーク名、「IPアドレス一覧」をクリックします。

ここで表示されている「割当範囲外」のIPアドレスがすべてセカンダリIPとして指定できます。（「利用不可」と書かれている最後の10個のIPアドレスだけはIDCFクラウド側で使用するため割当はできません）なので、この例では10.32.4.1を使います。

セカンダリIPアドレスの取得

CentOS 6系とCentOS 7系を例に手順を紹介します。

CentOS 6系の場合
今回は、Light.S1(1コア, 1GBメモリ)の仮想マシンを使ってセカンダリIPを取得していきます。ホスト名はsecondary-ip-test-cent6、OSはCentOS 6.8を使用します。プライマリIPは10.32.0.122がDHCPで設定されています。

#ifcfg-eth0:1の設定ファイルを作成
[root@secondary-ip-test-cent6 ~]# cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:1

#IPアドレスをDHCP取得ではなく、スタティックに書き込む
[root@secondary-ip-test-cent6 ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0
ONBOOT=yes
IPADDR=10.32.4.1
NETMASK=255.255.248.0

#ネットワークの再起動
[root@secondary-ip-test-cent6 ~]# service network restart

#eth0の情報確認
[root@secondary-ip-test-cent6 ~]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:03:01:be:00:05 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.122/21 brd 10.32.7.255 scope global eth0
    inet 10.32.4.1/21 brd 10.32.7.255 scope global secondary eth0
    inet6 fe80::3:1ff:febe:5/64 scope link 
       valid_lft forever preferred_lft forever

10.32.4.1がちゃんと設定されていました。

CentOS 7系の場合
今回は、Light.S1(1コア, 1GBメモリ)の仮想マシンを使ってセカンダリIPを取得していきます。ホスト名はsecondary-ip-test-cent7、OSはCentOS 6.8を使用します。プライマリIPは10.32.0.209がDHCPで設定されています。

#まずは現在の状態を見てみます
[root@secondary-ip-test-cent7 ~]# ip addr show
(略) 
2: eno16777984: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:03:01:be:00:06 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.209/21 brd 10.32.7.255 scope global eno16777984
       valid_lft forever preferred_lft forever
    inet6 fe80::3:1ff:febe:6/64 scope link 
       valid_lft forever preferred_lft forever

#nmcliコマンドでセカンダリIPを追加
[root@secondary-ip-test-cent7 ~]# nmcli connection modify eno16777984 +ipv4.addresses  "10.32.4.1/21"

#ネットワークを再起動する
[root@secondary-ip-test-cent7 ~]# systemctl restart network

#再度NICの状態を確認
[root@secondary-ip-test-cent7 ~]# ip addr show
(略)
2: eno16777984: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:03:01:be:00:06 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.209/21 brd 10.32.7.255 scope global eno16777984
       valid_lft forever preferred_lft forever
    inet 10.32.4.1/21 brd 10.32.7.255 scope global secondary eno16777984
       valid_lft forever preferred_lft forever
    inet6 fe80::3:1ff:febe:6/64 scope link 
       valid_lft forever preferred_lft forever

こちらでも10.32.4.1がちゃんと設定されていますね。

まとめと注意点

セカンダリIPを使いたい時は、まずはどのような利用をするかに沿って方法を選択しましょう。ちなみに以前セカンダリIPを使ってLVSを冗長化する記事も書いたのでご参考ください。

手順①のAPI経由で取得したセカンダリIPの扱いには、2つ注意点がありますのでご参考ください。

1. セカンダリIPはIDCFクラウドコンソールからの管理ができないので、ご自身での管理となります。
2. セカンダリIPをグローバルIPとスタティックNATした場合、APIでスタティックNATを解除してから仮想マシンを削除するようにしてください。スタティックNATの設定解除せず、そのまま仮想マシンを削除してしまうとシステム側からスタティックNATが削除できなくなってしまいます。

方法2については特に注意点はないのですが、紹介したCentOS6と7の方法は両方ともネットワークの再起動が伴うため、動的にIPを追加したい場合はip addr addコマンドなどで追加することも可能です。

ぜひ、試してみてください。

こんにちは。株式会社アールワークスの井上と申します。

VulsユーザーズグループであるVulsのSlackに参加している関係で、記事を書く機会をいただきました。 IDCFクラウド アンバサダープログラムのMORIO Dojoにも参加しています(白帯のままです...)。

前回は、Vulsのミートアップである Vuls祭りVol.1の記事を書きました。引き続き、Vulsの記事を寄稿させていただきます。

さて先日、IDCFエバンジェリストグループの方から、Vulsのコミュニティテンプレートが公開されました。 今回は、このコミュニティテンプレートについて内容を確認し、追加の情報を提供させていただきます。

• 始まりのVuls/VulsRepo (Vulsを使ってみよう)
• Vulsコミュニティテンプレート利用時に役立つTips
• Vulsコミュニティテンプレートの構成について
• Vulsミートアップ「Vuls祭り #2」のご紹介 &有用なリンク集
• 最後に

まずは、Vulsアップデートはせず、テンプレートのまま使ってみましょう。

[vuls@vuls vuls]$ vuls report -to-localfile -format-json
[Mar  6 20:38:50]  INFO [localhost] Validating Config...
[Mar  6 20:38:50]  INFO [localhost] cve-dictionary: /opt/vuls/cve.sqlite3
[vuls@vuls vuls]$ vuls report -format-full-text
[Mar  6 20:39:00]  INFO [localhost] Validating Config...
[Mar  6 20:39:00]  INFO [localhost] cve-dictionary: /opt/vuls/cve.sqlite3

vuls-server (centos6.8)
=======================
Total: 0 (High:0 Medium:0 Low:0 ?:0)    12 updatable packages

No CVE-IDs are found in updatable packages.
12 updatable packages

[vuls@vuls vuls]$

[servers]

[servers.vuls-server]
host         = "127.0.0.1"
port        = "local"

[servers]

[servers.vuls-server]
host        = "127.0.0.1"
port        = "local"
smtpAddr    = "your-smtp-server-IP/FQDN"
smtpPort    = "25"
from        = "from-mail@domain"
to          = ["to-addr@domain"]
cc          = ["cc-addr@domain"]
subjectPrefix = "[vuls]"

#!/bin/bash
PATH=/bin:/usr/bin:/usr/sbin
CONFIG=/opt/vuls/config.toml
RESULTS=/opt/vuls/results
CVEDB=/opt/vuls/cve.sqlite3
LOGDIR=/var/log/vuls
go-cve-dictionary fetchnvd -last2y -dbpath=$CVEDB -log-dir=$LOGDIR
go-cve-dictionary fetchjvn -last2y -dbpath=$CVEDB -log-dir=$LOGDIR
vuls scan -config=$CONFIG -results-dir=$RESULTS -log-dir=$LOGDIR
vuls report -config=$CONFIG -results-dir=$RESULTS -cvedb-path=$CVEDB -log-dir=$LOGDIR -to-localfile -format-json
vuls report -config=$CONFIG -results-dir=$RESULTS -cvedb-path=$CVEDB -log-dir=$LOGDIR -to-email -format-short-text

/
├─....
├── opt
│   └── vuls
│       ├── config.toml
│       ├── cve.sqlite3
│       ├── cve.sqlite3-shm
│       ├── cve.sqlite3-wal
│       └── results
│           ├── 2017-02-24T11:54:18+09:00
│           └── current -> /opt/vuls/results/2017-02-24T11:54:18+09:00
├── home
│   └── vuls
│       ├── README
│       └── go
│           ├── bin
│           ├── go1.7.5.linux-amd64.tar.gz
│           ├── pkg
│           └── src
.....

みなさまはじめまして、UX開発部の橋口です。

今回の記事は、IDCFクラウドの東日本リージョン2に採用された、新ネットワークアーキテクチャである「VXLAN over CLOS」についてです。
「VXLAN over CLOS」の設計思想や、今までのアーキテクチャと比べ何が違うのかなどを書いていきます！

VXLAN over CLOSとは

IDCフロンティアの新ネットワークアーキテクチャである「VXLAN over CLOS」は、ネットワークをオーバーレイとアンダーレイという2つの階層に分けた設計になっています。
オーバーレイは、トラフィックをカプセル化する仮想的なネットワーク層です。アンダーレイは、いわゆる物理的なネットワーク層であり、オーバーレイでカプセル化されたトラフィックを転送します。

このようにオーバーレイとアンダーレイの2階層に分離することにより、シンプルな設計になっています。

アンダーレイ：CLOS (IP Fabric)

CLOSの考えとしては、小さなインターネットを作ると考えていただければわかりやすいと思います。 実際に今もインターネットを支えているBGPを用いて、多数の機器を相互に接続し、最適な経路を導き出しています。 これにより、一般的なL2ネットワークに比べ拡張性を高めたり、帯域の有効活用を実現しています。

オーバーレイ：VXLAN

VXLANでは、マルチテナントのネットワーク、個別のプライベートなネットワークの構築を行っています。 全サービスで一意なID(VNI)を付与することが可能になり、VLAN4000の壁に捉われない柔軟性に優れたネットワークの設計が行えます。

CLOSの拡張性、VXLANの柔軟性を組み合わせた次世代のネットワークアーキテクチャが「VXLAN over CLOS」というわけです。

VXLAN over CLOSのメリット

「VXLAN over CLOS」には大きく下記の2つのメリットがあります。

1. 新ネットワークアーキテクチャ間のL2接続が容易に可能
2. 拡張性の高い設計思考

それぞれ説明していきます。

1.新ネットワークアーキテクチャ間のL2接続が容易に可能

現在、下記サービスがVXLAN over CLOSで構成されています。

• IDCFクラウド　東日本リージョン2
• プライベートクラウド
• データセンター（ハウジング）

これらのサービス間は、シームレスなL2ネットワークで接続することが可能です。
これにより、例えば下図のように異なる環境で収集・蓄積したデータを簡単に連携させることができます。

IDCFクラウドのゾーン間接続の申し込み方法については、こちらをご参照ください。

2.拡張性の高い設計思想

以前の構成では、各ネットワーク機器がActive-Standby構成となっており、Standby側にはトラフィックが流れていませんでした。しかし「VXLAN over CLOS」ではActice-Active構成となったため、全てのLinkや機器にトラフィックを流すことができ、通信効率と拡張性の向上を実現しました。これにより、各サービス間のネットワークは、従来比の16倍の帯域になりました！

また、耐障害性も向上しています。Actice-Active構成のため、ネットワーク機器の故障時に切り替えが起こらず、縮退のみで留めることができるため、サービス断が発生しなくなりました。
今時はユーザーからすると、内部ネットワークはあまり意識することのない部分ですが、このようにチャレンジと改善を積み重ねることにより、日々サービス品質の向上に努めています！

まとめ

IDCフロンティアが新たに採用したネットワークアーキテクチャ「VXLAN over CLOS」の以下2つのメリットについて紹介しました。

1. 新ネットワークアーキテクチャ間のL2接続が容易に可能
2. 拡張性の高い設計思考

より技術的な内容については、IDCフロンティアの見崎より「JANOG39 Meeting」にて発表しています。 詳しく知りたい方は、下記URLより資料をご覧ください！ https://www.janog.gr.jp/meeting/janog39/application/files/8514/8478/6659/JANOG_IDCF.pdf

今後もシンプルかつパワフルなクラウドを目指し、機能やユーザビリティの向上に努めてまいります！

こんにちは。株式会社アールワークスの井上です。

前回に引き続き、コミュニティテンプレートVulsについて説明していこうと思います。

過去の記事はこちら↓
最近話題のセキュリティスキャナ Vulsと、Vulsのmeetup Vuls祭り Vol.1のご紹介
コミュニティテンプレート Vuls の利用とTips

今回は、先日更新されたコミュニティテンプレートVulsについて、下記内容を共有したいと思います。

• コミュニティテンプレート更新内容の確認
• Vulsミートアップ「Vuls祭り #2」

コミュニティテンプレート更新内容の確認

2017/04/01、IDCFクラウドの中の人にテンプレートのアップデートをしていただきました。ありがとうございます！ 主な更新点は以下の通りです。

• テンプレートのアップデート
  • Vuls および Vulsrepo を、2017/04/01時点の最新のものとしました
• Vulsのアップデートサポートスクリプトを用意
  • 本家の機能ではないのですが、アップデートをスクリプト一つで実行できるようにしました
• sudoersの厳格化
  • sudoersでのvulsユーザ権限を、より厳しい形にしました
• デフォルトconfig.tomlの変更
  • VulsのREADMEの記載が、自身をローカルスキャンする設定になったため、デフォルトのconfig.tomlを変更しました
• 上記に合わせたREADMEの更新
  • vuls scanおよびvuls report付近の記載を一部変更しました

これらについて細かく見てみます。

アップデート

Vulsのバージョンは2017/04/01時点の最新版にしていますが、日々バージョンアップされているため、必要に応じて更新が必要です。

• 前回のコミュニティテンプレートリリース後、Vulsに大幅なバージョンアップがあったため、テンプレートも更新しています
• 後述のアップデートスクリプトを用意しました。ある程度動作確認が取れているバージョンで更新しています

アップデートサポートスクリプトを用意

Vulsミートアップ「Vuls祭り#2」で、1コマンドでアップデートしたい、という話もあったため、取り急ぎ用意しました（公式の手順をシェルスクリプト化しているだけです）。

Vulsのアップデート

/home/vuls/scripts/update_vuls.sh として、vulsのアップデートスクリプトを用意しました。 vulsユーザで実行してください。

[root@HOSTNAME ~]# su - vuls
[vuls@HOSTNAME ~]$ /home/vuls/scripts/update_vuls.sh
Update vuls
remote: Counting objects: 70, done.
remote: Total 70 (delta 42), reused 42 (delta 42), pack-reused 28
Unpacking objects: 100% (70/70), done.
From https://github.com/future-architect/vuls
 * [new branch]      add-testcase -> origin/add-testcase
 * [new branch]      hostkey    -> origin/hostkey
   d4bec0d..f878e22  master     -> origin/master
 * [new branch]      nvd-url    -> origin/nvd-url
 * [new branch]      stty-localexec -> origin/stty-localexec
 * [new branch]      update-deps -> origin/update-deps
...Update start.
...Update finished.
Update go-cve-dictionary
remote: Counting objects: 28, done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 28 (delta 8), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (28/28), done.
From https://github.com/kotakanbe/go-cve-dictionary
 * [new branch]      dep        -> origin/dep
   683256b..103ddbd  makefile   -> origin/makefile
   bbfdd41..4d5c2be  master     -> origin/master
   82087b2..bb95122  redhat-cvedates -> origin/redhat-cvedates
 * [new branch]      refactoring -> origin/refactoring
...Update start.
...Update finished.
[vuls@HOSTNAME ~]$

• 状況によりますが、数分かかる場合があります。スクリプト実行後、そのままでお待ちください
• 利用中のVulsバイナリを保存したい場合は、/home/vuls/go/bin/vuls をリネームして保存してください

sudoersの厳格化

セキュリティを考える場合、必要なもの(人やファイル)に必要な権限の実をつけるという"need to knowの原則"に従う必要があります。 Vuls実行ユーザ"vuls"にも同様な制限を実施しました。

[root@HOSTNAME ~]# cat /etc/sudoers.d/vuls
vuls ALL=(ALL) NOPASSWD:/usr/bin/yum --changelog --assumeno update *
vuls ALL=(ALL) NOPASSWD:/usr/bin/yum --version
vuls ALL=(ALL) NOPASSWD:/usr/bin/yum --color=never check-update
Defaults:vuls env_keep="http_proxy https_proxy HTTP_PROXY HTTPS_PROXY"
[root@HOSTNAME ~]#

Vulsに限りませんが、アプリケーション専用ユーザ等を用意する場合でセキュリティを考慮するときは、以下の点を検討してください。

• ファイルのOwnerになる必要があるのか
  • 読み込みと実行だけでよければ、グループとしてアクセス権を付与することをお勧めします
• 無制限の権限を付与しない
  • sudo -s をさせない、必要なコマンドのみ権限を付与する
  • vulsユーザへは、yumのオプション付きで権限を与えています

デフォルトconfig.tomlの変更

最初にコミュニティテンプレートVulsがリリースされた後、Vulsでローカルスキャンが実装されました。それに伴い、自分自身へのスキャンは「ローカルスキャンモード」を利用するようにREADMEの記載が変わりました。

ローカルスキャンは、SSH接続不要なモードです。

• 今までの、SSH接続をして sudo yum ..でスキャンをする方式を、「リモートスキャンモード」と言います
• SSH接続をせず、直接 sudo yum ..のようにスキャンをする方式を、「ローカルスキャン」と言います
  • Vuls自体はバイナリとして配布が可能であり、SSH接続も不要であるため、監視等で利用しやすくなります
  • 後述のVuls祭り#2で、Mackerelとの連携についても話題になりました（「SaaS/OSSを進化させる オーフ゜ン・エコシステムについて　Mackerel×Vulsの例」）
  • 概要は、上記同様に「Vuls ローカルスキャンモードの活用方法」を参照してください

コンフィグの記載方法の違いは、以下の通りです。

• リモートスキャン(今までの方法)
  • host, port, user, keyPath を指定
    • SSH接続をする為に必要な情報
• ローカルスキャン
  • host および port を指定
    • hostは、localhost 若しくは 127.0.0.1
    • portは、local
    • 上記の2つの指定がされていた場合、ローカルスキャンとなる

Vulsサーバ自分自身はローカルスキャン、自分以外のサーバはリモートスキャン、とするのが良いと思われます。

上記に合わせたREADMEの更新

Vulsのレポートオプション等について、簡単に記載しました。

おおよそ以下のようなフローで利用することになります。

• スキャン
  • vuls scanコマンドで、スキャンをします
  • 必要に応じて、コンフィグファイルの指定-configや、デバッグ-debugなどのオプションを指定してください
• レポート
  • まずはレポートの前処理として、以下を実行します
    • vuls report -to-localfile -format-json -lang ja
      • vulsのスキャン結果は resultsディレクトリにjsonファイルとして保存されます。この段階ではCVEの詳細等は含まれていません
      • まずは上記コマンドを実行することで、go-cve-dictionaryを使ってjsonの情報を更新します
  • 次に、必要な通知処理を実施します
    • どこに出力するかを、-to-xxxオプションで指定します
      • -to-email, -to-slack, -to-localfileなどです
      • -to-localfileの出力先は、reportディレクトリ以下になります
    • 出力形式を、-format-xxxオプションで指定します
      • -format-json, -format-xml, format-short-textなどです

以上で、コミュニティテンプレートの更新内容と、簡単なVulsのスキャンについて説明しました。 次は、Vuls祭り#2 についてレポートします。

Vulsミートアップ「Vuls祭り #2」

2017/03/27に Vuls祭り#2が行われました。

• コミュニティテンプレートVulsを作成頂いた、IDCFクラウドの中の人にもお話しいただきました

Vulsを利用した脆弱性対応や、サーバレスでVulsを使う、mackerelとの連携、などの話がありました。 セッションの資料について、一部アップロードされているので、興味のある方はご覧ください。

次回は夏ぐらいに実施されると思うので、セキュリティや運用に興味のある方はご参加ください。

最後に

今回は、テンプレート更新部分について記載しました。次回からは、コミュニティテンプレートを利用した監視の構築について書いていければと思います。

Vulsを使って、セキュリティ対応や運用の負荷を下げられれるといいですね。

尚、弊社 株式会社アールワークスでは、マネージド運用サービスを行っています。Vulsを使った運用も可能ですので、運用にお困りの場合はご相談ください。

Mastodonとは

Mastodon（マストドン）はTwitterライクなSNSです。誰でも独自のMastodonインスタンスを作ることができて、すでに多数のインスタンスが立ち上がっています。登録されたインスタンスは、Mastodon instancesで参照することができます。

好きなインスタンスに参加するもよし、自分ひとり用のインスタンスを立ち上げるもよしです！本日はMastodonをIDCFクラウド上で構築する手順を紹介します。

• Mastodonとは
• 利用環境
• 作業ディレクトリ作成
• dockerインストール
  • docker保存先を変更
  • docker-composer準備
  • dockerの起動
• Mastodonのインストール
  • GitHubからcloneする
  • データの永続化設定
  • 環境ファイルをコピーし設定する
  • シークレットキーの発行
  • データベースのマイグレーションとフロントエンドコンパイル
  • Mastodonコンテナを起動
• Nginxのインストール
• Certbotを利用してSSL証明書を発行する
• Nginx設定ファイルを準備する
• Nginxを起動する
• Mastodonへアクセスする
• ユーザ認証をコマンドラインで実行する
• 最後に

利用環境

• IDCFクラウド light.S2 （1 CPU, 2GB メモリ）
• Let’s EncryptでSSL証明書を発行
• CentOS 7.3 64-bit テンプレート

仮想マシンの作成に関してはめちゃ楽ガイドを参照してください。

SSH用のポートにポートフォワードとファイアウォールの設定をしてSSHで接続します。

作業ディレクトリ作成

今回の作業用ディレクトリとして、/home/mastodonを作成します。

# mkdir -p /home/mastodon

dockerインストール

Mastodonはdockerコンテナを利用して構成されているため、dockerをインストール・設定していきます。

# yum -y install docker

docker保存先を変更

CentOS 7のテンプレートを利用する場合、ルートディスクが15GBで構成されます。ルートディスクのサイズは変更できないため、ボリュームを追加・アタッチし、dockerの保存先を変更しておきます。(mastodonのDBが肥大化する恐れもありますので）

仮想マシンへのデータボリュームの追加・パーティション作成・マウントについては、IDCFクラウドFAQを参照するかティアラちゃんに質問してみてください。

ディスクの追加完了後、下記ファイルを編集し保存先を変更します。 今回は/data/dockerというディレクトリを作成し、そちらを保存先にしました。

# vi /etc/sysconfig/docker

下記行がありますので、

OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false'

末尾に下記を追記します。

OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false -g /data/docker'

docker-composer準備

MastodonはPostgreSQLやRedisも利用しますので、docker-compose.xmlファイルを利用してコマンド一発で起動できるように準備します。

# curl -L https://github.com/docker/compose/releases/download/1.12.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose

インストールが正常にされたかを確認します。

# docker-compose --version
docker-compose version 1.12.0, build b31ff33

バージョンが表示されればOKです。

dockerの起動

dockerを起動します。

# systemctl start docker

Mastodonのインストール

GitHubからcloneする

MastodonをGitHubからcloneします。

# git clone https://github.com/tootsuite/mastodon

データの永続化設定

標準状態のままですと、データの永続化設定となっていないためコンテナを停止してしまうとデータが削除されます。 ユーザの登録情報等を永続的に維持するためにdocker-compose.xmlファイルを編集します。

# cd /home/mastodon/
# vi docker-compose.yml

下記のコメントアウトされているコンフィグを有効化します。（冒頭の#を外す）

#    volumes:
#      - ./postgres:/var/lib/postgresql/data

#    volumes:
#      - ./redis:/data

環境ファイルをコピーし設定する

# cp .env.production.sample .env.production

シークレットキーの発行

下記コマンドを実行してシークレットキーを発行します。（少し時間がかかります。）

# docker-compose build
# docker-compose run --rm web rake secret

キーは3つ必要なため、上記の'docker-compose run –rm web rake secret'コマンドを合計3回実行する必要があります。最後に表示された長い文字列をコピーして次のステップで貼り付けます。

環境ファイルを編集してシークレットキー・ドメイン名・HTTPSを有効化するかの設定をします。example.comとあるところはご自身のMastodonで利用するFQDNを設定してください。

# vi .env.production
PAPERCLIP_SECRET=（発行されたキー①を貼り付け）
SECRET_KEY_BASE=（発行されたキー②を貼り付け）
OTP_SECRET=（発行されたキー③を貼り付け）
LOCAL_DOMAIN=example.com
LOCAL_HTTPS=true

データベースのマイグレーションとフロントエンドコンパイル

下記コマンドを実行します。

# docker-compose run --rm web rails db:migrate
# docker-compose run --rm web rails assets:precompile

Mastodonコンテナを起動

# docker-compose up -d

docker psコマンドを実行すると起動しているコンテナ一覧を表示することができます。

# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                              NAMES
ae2dc853c315        gargron/mastodon    "bundle exec sidekiq "   4 seconds ago       Up 3 seconds        3000/tcp, 4000/tcp                 mastodon_sidekiq_1
922437f3ff8b        gargron/mastodon    "bundle exec rails s "   4 seconds ago       Up 3 seconds        0.0.0.0:3000->3000/tcp, 4000/tcp   mastodon_web_1
f72ac86fa74e        gargron/mastodon    "npm run start"          4 seconds ago       Up 3 seconds        3000/tcp, 0.0.0.0:4000->4000/tcp   mastodon_streaming_1
147bec4a1086        redis:alpine        "docker-entrypoint.sh"   5 minutes ago       Up 5 minutes        6379/tcp                           mastodon_redis_1
75e3c4008fb8        postgres:alpine     "docker-entrypoint.sh"   5 minutes ago       Up 5 minutes        5432/tcp                           mastodon_db_1

Nginxのインストール

epelリポジトリを追加して、NginxとCertbotをインストールします。

# yum -y install epel-release
# yum -y install nginx certbot python-certbot-apache

Certbotを利用してSSL証明書を発行する

Certbotを利用し、Let’s Encryptから証明書を発行してもらうためには、443番ポートへのアクセスが許可されている必要があるので、管理コンソールからファイアウォールとポートフォワードの設定を追加します。443番のファイアウォールは、ソースIPをANYで開けてください。 具体的な設定方法については、めちゃ楽ガイドを参照してください。

下記コマンドを実行して証明書を取得します。

# certbot certonly --standalone -d <mastodonで利用するFQDN>

Nginx設定ファイルを準備する

MastodonのGitHubページ内にあるconfファイルの内容をコピーします。 下記ディレクトリに、mstdn.confとして保存します。

# cd /etc/nginx/conf.d
# vi mstdn.conf
コピーした内容を貼り付け

server_name、SSL証明書へのフルパスとrootを変更します。 また、今回はRSA鍵を使用するため、ssl_dhparamの行はコメントアウトもしくは削除します。

server_name example.com;

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# ssl_dhparam         /etc/ssl/certs/dhparam.pem;

root /home/mastodon/public/;

Nginxを起動する

# systemctl start nginx.service

Mastodonへアクセスする

設定したFQDNに対してブラウザでhttpsアクセスします。ユーザ登録画面が表示されれば完了です。

ユーザ認証をコマンドラインで実行する

登録をしてもメールサーバの設定をしていないため、登録後の認証用メールを受信することができません。 そのため、コマンドラインからユーザの認証を実施します。

# docker-compose exec web bundle exec rails mastodon:confirm_email USER_EMAIL=＜認証するメールアドレス＞

認証が完了するとログインできるようになりますので、ログインしてトゥートしてみましょう！

最後に

実は、IDCFクラウドでMastodonを運営するには結構メリットが多いのです。

もしアクセスが伸びてきて仮想マシンのスペックが足りなくなった場合、IDCFクラウドには無停止でスケールアップする機能（ダイナミックスケール）もあるのでご活用ください。

また、IDCFクラウドのメリットとして、アウトバウンドの転送量は3,240GBまで無償範囲内でご利用いただけます。超えてしまった分は10円/GBの従量課金となります。転送量の急増が心配な方は、予算アラート機能を使ってみてください。

今回から「IDCFクラウド豆知識講座」と題して、IDCFクラウドに関する「実は知らなかった」「ここがよくわからない」といったポイントを取り上げ、シリーズ化してご紹介していきたいと思います。既にあるFAQなどのドキュメントにプラスした内容によって、初心者の方はもちろん、長くご利用いただいているユーザーの方にも新たな使い方の発見につなげていただけることを目指します！不定期での登場になりますが、ぜひご期待ください！
ではさっそく、本日の本題へ参りましょう。

みなさん、IDCFクラウドで仮想マシンを作成するときに「イメージ」の項目でテンプレートを選択しますよね。
今回はユーザー自身でテンプレートを作成する方法を次の流れでお話したいと思います。

　1. テンプレートとは
　2. インポート
　3. エクスポート
　4. まとめ

▲図1 テンプレートのインポート/エクスポート概念図

１. テンプレートとは

テンプレートとはOSやミドルウェア、アプリを含め各種設定情報をまとめたイメージのことで、このテンプレートを使うと仮想マシンを手軽にセットアップすることができます。
IDCFクラウドのテンプレートにはいくつかの種類があります。
　・標準テンプレート(無償/有償)
　・マイテンプレート
　・標準ISOテンプレート
　・コミュニティテンプレート

「マイテンプレート」はユーザーがカスタマイズしたOSイメージのことです。本記事の対象となるのはこのマイテンプレートになります。
その他のテンプレートについてはサービスページをチェックしてみてください。

マイテンプレートの作成方法には、大きく分けて次の2通りがあります。
1. IDCFクラウド環境内の仮想マシンから作成
2. 外部のOSイメージ(OVAファイル)をテンプレート作成画面からインポート

今回は2つめのテンプレート作成画面を用いる際の設定を紹介します。

２. インポート

上記で紹介した2つめの作成方法はインポート機能とも呼ばれており、異なるリージョン間でのテンプレート移動時にも活用できます。また、外部環境にあるOVAファイルを持ち込むことができるので、例えば自前のVMware環境下の仮想マシンをIDCFクラウド環境に移設(コピー)することも可能です。ではさっそく作成画面のパラメータを見ていきたいと思います。

▲図2 テンプレート作成画面(上部)

作成時のパラメータは全部で14個あります。次の表で各項目をご説明していきます。

▼表 テンプレート作成画面の各種パラメータ

以上のパラメータを設定し「テンプレートを作成する」をクリックします(図3)。

▲図3 テンプレート作成

「テンプレートを作成しますか？」のポップアップで「はい」を選択し、テンプレートの一覧画面でステータスが「Creating」から「Download Complete」になれば作成完了です(図4)！

▲図4 作成したテンプレートのステータス確認

なお、外部からOVAファイルを持ち込む際にはいくつか注意点がありますのでこちら(FAQ)をご参照ください。

３. エクスポート

ここまでテンプレートの作成(インポート機能)について見てきました。続いてエクスポート機能についても簡単に紹介します。
異なるゾーンでテンプレートを使用したい場合は「テンプレートコピー」という機能で実現できます。しかし、テンプレートコピーは同一リージョン内のみ有効です。リージョンが異なる場合はエクスポート機能を使ってテンプレートをエクスポートし、それをインポートすることによって実現できます。別アカウントで作成したテンプレートを使用したい場合も同様です。
また、テンプレートのエクスポート機能は上記以外にも次のようなシーンでの活用方法があります。
　・エクスポートしたテンプレートをOVAファイルでローカル環境にダウンロード、バックアップとして保持
　・IDCFクラウド以外の外部VMware環境に仮想マシンの複製をデプロイ

実際にエクスポートする方法はとても簡単です。
クラウドコンソールでテンプレート一覧に移り、エクスポートしたいテンプレートを選択します。

▲図5 テンプレート選択画面

開いた画面右上のタブに「エクスポート」があるのでこちらを選択します(図5)。そうすると「URLを発行する」というボタンがありますので、クリックしてURLを発行します。これでエクスポートは完了です！

▲図6 発行されたURL

ここで発行されたURL(図6)をコピーし、先ほどのテンプレート作成のパラメータ「URL」にペーストすることでインポートが可能となります。その際、表でも補足しましたが「https」の「s」を取ることを忘れないよう注意してください。httpsのままですと入力がエラーとなり作成の実行ができません。
その他にもエクスポート/インポート時の注意点があるのでご注意ください。

　1. 次の場合、エクスポートができません
　　・有償テンプレート　※必要な場合はチケットよりご相談ください
　　・ISOで作成した仮想マシンから作成したテンプレート
　　・エクスポート機能を無効にして作成したテンプレート
　　・ハードウェア専有タイプの仮想マシンから作成したテンプレート

　2. インポート時、次の点にご注意ください
　　・テンプレート作成元の仮想マシンにISO等のアタッチがされていない状態であること

４. まとめ

ここまでテンプレート作成と、それに関連してエクスポート/インポートについてご紹介してきました。今回は詳しく触れませんでしたが、冒頭で記述した通りテンプレート作成方法にはインポート以外にも対象仮想マシンのディスクや取得したスナップショットから作成する手法があります。
仮想マシンの複製やリージョン、別アカウント同士でのテンプレート利用など、シーンに合わせた方法で実施ください。

Docker Swarm概要

Docker Engineを単独に使う場合はどちらかというと開発の段階で使う場面が多いと思います。その場合、自らそれぞれのコンテナを管理しないといけないので、管理が大変だと感じることが多いのではないでしょうか？

そこで今回紹介するDocker EngineのSwarm Modeを利用すると、クラスタリングツールがコンテナの管理を行ってくれるのでコンテナ管理がとても楽になります。 具体的に次のようなことがSwarm Modeを利用で可能になります。

• サービスのスケーラビリティの向上や単一障害点の排除。 　例えばふたつのコンテナで構成されているサービスにアクセス数が多くなった場合に、簡単にコンテナを増やすことが可能。
• あるコンテナが稼働しているサーバーが落ちた場合に、自動で別のサーバーにコンテナを再作成。
• Docker Engineがインストールされる複数のサーバーでDocker Swarmクラスタを作成。 　複数のアプリケーションそれぞれ違うポート番号使えば、共同にDocker Swarmクラスタに動かすことができます。
• Docker Swarmクラスタを使うことによってリソースの節約や、サービスのスケーリング、アプリケーションのローリングアップデートを比較的簡単に実現。

今回は、Goで作成するサンプルアプリケーションをIDCFクラウド上に作成したDocker Swarmクラスタにて動かしてみます。

• Docker Swarm概要
• IDCFクラウド上に作成する仮想マシンのスペック
• Dockerのインストール
• Docker Swarmクラスタを構築
• GoアプリをDocker Swarmにデプロイ
• アプリのイメージをビルド

IDCFクラウド上に作成する仮想マシンのスペック

IDCFクラウド上で3台のCentOS 7.3 仮想マシンを作成します。詳細は下の表に記載しています。 ※IPは動的に割り当てられたIPをそのまま使っています。

Dockerのインストール

Docker Swarmクラスタを構築するにあたって、3台の仮想マシンすべてにDocker Engineをインストールします。現時点で一番新しいDocker 17.03をインストールします。

sudo yum update -y
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo # Docker Community EditionのRepositoryをインストール
sudo yum makecache fast # Repositoryのメタデータが使えるように
sudo yum info docker-ce
sudo yum install docker-ce -y

sudo groupadd docker
sudo gpasswd -a ${USER} docker # 現在のユーザーがdocker コマンドを使えるように

sudo systemctl enable docker
sudo systemctl start docker # Docker Engineを起動する

Docker Swarmクラスタを構築

まずswarm-node-01でDocker Swarmクラスタを初期化をします。初期化を行うとswarm-node-01がManagerになります。

[deploy@swarm-node-01 ~]$ docker swarm init --advertise-addr 10.32.0.68
Swarm initialized: current node (ynyqekkutkbj3td54e7tw9rpt) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-0ng5lwnm042158d003x0a2g78lz9263rs0upid8t3qevse53ua-cv57yx0i5spgh3j5u65o3nbhi \
    10.32.0.68:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.


$ docker node ls
ID                           HOSTNAME       STATUS  AVAILABILITY  MANAGER STATUS
ynyqekkutkbj3td54e7tw9rpt *  swarm-node-01  Ready   Active        Leader

残りの2台の仮想マシンをクラスタにjoinさせるため、上記コマンドが提示してくれたdocker swarm joinコマンドを入力します。これで2台の仮想マシンがWorkerとしてクラスタにJoinしました。

[deploy@swarm-node-02 ~]$ docker swarm join \
>     --token SWMTKN-1-0ng5lwnm042158d003x0a2g78lz9263rs0upid8t3qevse53ua-cv57yx0i5spgh3j5u65o3nbhi \
>     10.32.0.68:2377
This node joined a swarm as a worker.

[deploy@swarm-node-03 ~]$ docker swarm join \
>     --token SWMTKN-1-0ng5lwnm042158d003x0a2g78lz9263rs0upid8t3qevse53ua-cv57yx0i5spgh3j5u65o3nbhi \
>     10.32.0.68:2377
This node joined a swarm as a worker.

クラスタ中のノードの状況はdocker nodeコマンドで調べることができます。

$ docker node ls
ID                           HOSTNAME       STATUS  AVAILABILITY  MANAGER STATUS
1lqadobvtsp0yrc3s9bp9lgh8    swarm-node-03  Ready   Active
vrk6bserls04hj9rrrn8zpv9t    swarm-node-02  Ready   Active
ynyqekkutkbj3td54e7tw9rpt *  swarm-node-01  Ready   Active        Leader

さらにノードごとの詳細はdocker node inspectコマンドで調べることができます。

$ docker node inspect swarm-node-02

例としてNginxサービスをDocker Swarmクラスタに作成してみます。コンテナ自体は80番ポートにEXPOSEされています。サービスを作る際に仮想マシンの8080番ポートとコンテナの80番ポートをひも付けて公開します。 これで、外部から仮想マシンの8080番ポートにアクセスするとNginxサービスにフォワードされるようになります。

Docker Swarmモードにはrouting mesh機能があり、すべてのノードがリクエストを受け付けすることができます。ポート番号に基づいて、適切にリクエストをサービスにフォワードしてくれます。

[deploy@swarm-node-01 ~]$ docker service create --name test-nginx --replicas 2 -p 8080:80  nginx:1.10 # コンテナのレプリケーションを2にする
t929h1hugo7hk8es4oqqgqzo1

[deploy@swarm-node-01 ~]$ curl 10.32.0.68:8080 # クラスタのどのノードにアクセスしてもレスポンスが返ってくる
[deploy@swarm-node-01 ~]$ curl 10.32.0.34:8080
[deploy@swarm-node-01 ~]$ curl 10.32.0.20:8080

test-nginxサービスの詳細を見てみると、2つのコンテナがswarm-node-01とswarm-node-02の2台の仮想マシン上で動いています。test-nginxサービス自身にVirtual IP(10.255.0.6)が割り当てられています。

[deploy@swarm-node-01 ~]$ docker service ps test-nginx # サービスは2つのレプリケーションで構成されている
ID            NAME          IMAGE       NODE           DESIRED STATE  CURRENT STATE           ERROR  PORTS
x6cz28kimuzx  test-nginx.1  nginx:1.10  swarm-node-02  Running        Running 24 seconds ago
n47lcgfvmm6w  test-nginx.2  nginx:1.10  swarm-node-01  Running        Running 24 seconds ago

[deploy@swarm-node-01 ~]$ docker service inspect --format="{{json .Endpoint.VirtualIPs}}" test-nginx # Virtual IPを取得
[{"NetworkID":"mifrgvabwccmkxok88ouf1z3q","Addr":"10.255.0.6/16"}]

swarm-node-01とswarm-node-02で動いているコンテナはdocker inspectコマンドでIP アドレスが割り当てられていることが確認できます。 docker psコマンドでコンテナ名の取得をし、docker inspectコマンドでIPの確認をします。

[deploy@swarm-node-01 ~]$ docker ps # swarm-node-01に動いているコンテナの名前を取得
CONTAINER ID        IMAGE                                                                           COMMAND                  CREATED             STATUS              PORTS               NAMES
7e7b916c51ec        nginx@sha256:6202beb06ea61f44179e02ca965e8e13b961d12640101fca213efbfd145d7575   "nginx -g 'daemon ..."   10 minutes ago      Up 10 minutes       80/tcp, 443/tcp     test-nginx.2.n47lcgfvmm6w0gnl28khfc95k
bash:swarm-node-02
[deploy@swarm-node-02 ~]$ docker ps  # swarm-node-02に動いているコンテナの名前を取得
CONTAINER ID        IMAGE                                                                           COMMAND                  CREATED             STATUS              PORTS               NAMES
6ba7fc790572        nginx@sha256:6202beb06ea61f44179e02ca965e8e13b961d12640101fca213efbfd145d7575   "nginx -g 'daemon ..."   10 minutes ago      Up 10 minutes       80/tcp, 443/tcp     test-nginx.1.x6cz28kimuzxisopfcogaewhr

[deploy@swarm-node-01 ~]$ docker inspect test-nginx.2.n47lcgfvmm6w0gnl28khfc95k --format="{{json .NetworkSettings.Networks.ingress.IPAddress}}" # コンテナ test-nginx.2のIPを取得
"10.255.0.8"

[deploy@swarm-node-02 ~]$ docker inspect test-nginx.1.x6cz28kimuzxisopfcogaewhr --format="{{json .NetworkSettings.Networks.ingress.IPAddress}}" # コンテナ test-nginx.1のIPを取得
"10.255.0.7"

test-nginxサービスの2つのコンテナは別々の仮想マシンにありますが、Overlay Networkを通して、同じネットワークにあるように通信できています。各コンテナからサービスのVirtual IPにもアクセスできます。

[deploy@swarm-node-01 ~]$ docker exec -it test-nginx.2.n47lcgfvmm6w0gnl28khfc95k /bin/bash
root@7e7b916c51ec:/# ping 10.255.0.7 # もうひとつの別のコンテナをPingすることができる
...
64 bytes from 10.255.0.7: icmp_seq=0 ttl=64 time=0.298 ms
...

root@7e7b916c51ec:/# apt-get update
root@7e7b916c51ec:/# apt-get install curl
root@7e7b916c51ec:/# curl 10.255.0.6 # サービスのVirtual IPにもアクセスできます。
...
<p><em>Thank you for using nginx.</em></p>
...

Nginxのイメージ1.10から1.11へアップデートしたい場合はサービスをアップデートします。イメージタグの変更以外にも、いろいろなオプションを使うことができます。たとえば、-limit-memoryオプションを使うとコンテナの使用できるメモリが制限されます。コンテナが実際使用しているメモリの量はctopコマンドで簡単に確認できます。また、--update-delayオプションを使うことによって、コンテナは10秒間隔で仮想マシンごとにアップデートしていきます。

[deploy@swarm-node-01 ~]$ docker service update test-nginx --image nginx:1.11 --limit-memory 2G --update-delay 10s

Docker Swarmクラスタのノードは2種類に分けられています。ひとつはManager、もうひとつはWorkerです。Managerノードはクラスタのステータスやスケジュールリングなどを管理しています。今回3台の仮想マシンでクラスタを組んでいるため、すべてのノードをManagerにすることをおすすめします。すべてのノードをManagerにすることで、1台のManagerが落ちても、クラスタのスケジューリング管理に問題が出なくなります。。

それではswarm-node-02とswarm-node-03をManagerにしていきます。その後、1台の1仮想マシンのDocker Engineを停止して(systemctl stop docker)、そこに動いているコンテナは別の仮想マシンに作成されるかを見てみましょう。

[deploy@swarm-node-01 ~]$ docker node update --role manager swarm-node-02
[deploy@swarm-node-01 ~]$ docker node update --role manager swarm-node-03

GoアプリをDocker Swarmにデプロイ

今回はGoで作成したサンプルのHTTPSアプリケーションを、Docker Swarmにデプロイしてみます。 ローカルの開発環境でアプリケーションを作成したので、手順を紹介します。 まずは、HTTPS通信のアプリケーションを作るのでサーバーの秘密鍵server.keyと証明書server.crtを作成します。

$ openssl genrsa -out server.key 2048
$ openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650

つぎに /tmp/play.goファイルを作成します。

package main

import (
        "log""net/http""os"
)

func greet(w http.ResponseWriter, req *http.Request) {
        log.Println("Hey there!") // app.logに書き込む
        w.Write([]byte("Hey there!"))
}

func main() {
        file, err := os.OpenFile("app.log", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
        if err != nil {
                log.Fatal("failed to open file :", err.Error())
        }

        log.SetOutput(file)

        http.HandleFunc("/greet", greet)　// greet関数が実行される
        err = http.ListenAndServeTLS(":7443", "server.crt", "server.key", nil)
        if err != nil {
                log.Fatal("ListenAndServe: ", err)
        }
}

go build -o play && ./playコマンドを実行して、 ブラウザからhttps://localhost:8443/greetにアクセスするとHi there!というレスポンスが返ってきます。

Docker Swarmにデプロイする際にはLinuxでアプリを動かすことになるため、GoのCross compilation機能を利用してビルドします。

$ GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -a -ldflags '-s' -installsuffix cgo -o play play.go

アプリのイメージをビルド

この簡単なアプリケーションをDocker Swarmにデプロイしてみますが、バイナリファイルを実行するだけで数百MBのCentOSイメージを使う必要がありません。 できる限り不要なファイル削減したいので、アプリのイメージサイズを小さくして(10Mぐらい)、scratchイメージをベースに作成します。

scratchイメージ自体のサイズは0バイトで、Shellもありません。ですのでコンテナ立ち上げても、docker exec -it <container-id> /bin/bashで入れません。

HTTPS通信なので、Trust Storeルート証明書ca-certificates.crtが必要となるので Mozillaのデータをダウンロードします。

$ curl -o ca-certificates.crt https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt

ログ収集するときに時間が出力されるので、タイムゾーンの情報も必要です。zoneinfo.tar.gzは仮想マシンにログインして取得します。

$ tar cfz zoneinfo.tar.gz /usr/share/zoneinfo

/tmp/Dockerfileを作成します。内容は次の通りで、必要な情報は証明書、タイムゾーン情報、鍵、コンパイルされたバイナリファイルです。

FROM scratch

ADD ca-certificates.crt /etc/ssl/certs/
ADD zoneinfo.tar.gz /

ADD server.crt /
ADD server.key /

ADD play /

WORKDIR /
CMD ["/play"]

イメージをビルドした後にDocker HubにPushします。

$ docker build -t wzj8698/go-swarm:1.0 .

$ docker login # PushするまえにDocker Hubにログインする必要がある
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: wzj8698
Password:
Login Succeeded

$ docker push wzj8698/go-swarm:1.0
The push refers to a repository [docker.io/wzj8698/go-swarm]
7de27f392ae7: Pushed
f6dde78f2228: Pushed
3d99cecfd591: Pushed
1.0: digest: sha256:53ab1aa6295da87ee303041fc161e66649c9839789c712a3c26b1fa881ea2071 size: 948

それでは、ローカル環境から、仮想マシン環境へログインしてください。 これからデプロイに入ります。3台の仮想マシンからwzj8698/go-swarm:1.0をPullしておきます。docker service createコマンドでデプロイし、--mountオプションも一緒に使うため、3台の仮想マシンにあらかじめログファイルapp.logを作成しておく必要があります。--mountオプションを使うことで、仮想マシン側のファイルをコンテナ内のファイルと結びつけることができます。これで、仮想マシン側でもログを確認できるようになります。

[deploy@swarm-node-01 ~]$ docker pull wzj8698/go-swarm:1.0
[deploy@swarm-node-02 ~]$ docker pull wzj8698/go-swarm:1.0
[deploy@swarm-node-03 ~]$ docker pull wzj8698/go-swarm:1.0

[deploy@swarm-node-01 ~]$ cd && touch app.log
[deploy@swarm-node-02 ~]$ cd && touch app.log
[deploy@swarm-node-03 ~]$ cd && touch app.log

[deploy@swarm-node-01 ~]$ docker service create  --name go-swarm --replicas 2  -p 7443:7443 --mount type=bind,source=/home/deploy/app.log,destination=/app.log  wzj8698/go-swarm:1.0

これで外から7443番ポートにアクセスできるようになっています。Docker Swarm 上でアプリが稼働している状態になりました。 今回は Go のアプリケーションをDocker Swarm 上にて動かしていますが、ぜひ自分で作成したアプリケーションで試してみてください。 いろいろなコンテナをたくさん管理する場合は、Docker Swarmを使うとコンテナ管理が捗りますよ。

こんにちは、金杉です。2017年4月27日にYahoo! JAPANの社員食堂にて、モノビット様とIDCフロンティア(IDCF)でVR体験会を兼ねたセミナーを開催しました。

「〜ゲーム＆VR向けリアルタイム通信エンジンの新しい選択肢〜 性能、使い勝手、お値段すべて公開！＆VR多人数コミュニケーション体験会＠ヤフー社員食堂」

今回のイベントの主旨として、モノビット様より新製品「Monobit Unity Networking 2.0 」および「Monobit Revolution Server」の性能、使い勝手、金額について紹介していただきました。また、上記以外にIDCFのセッションや、マルチプレイVRの体験会も人が絶えず盛り上がりましたので、当日の様子をブログで紹介したいと思います！

モノビットについて

株式会社モノビットはゲームとネットワークのテクノロジーを強みとし、エンターテイメントコンテンツを提供するテクノロジーベンチャー企業です。モノビットといえばミドルウェア事業者としてたくさんの方に認識されていますが、ゲーム開発事業も手がけています。過去のゲーム開発事業の実績紹介時には、IDCFクラウドのオールフラッシュディスク搭載サーバーの性能の良さについても言及していただきました。ありがとうございます！^ ^

▲モノビット　代表取締役　本城様

上記以外に、モノビットはVRソリューション事業も手がけており、最近はVRゲームやVRコミュニケーションなどのコンテンツ開発にも注力しています。本城様のVRソリューション事業への強い思い入れを感じることもできました。去年、小規模人数対応のVR Voice Chatをリリースしており、将来的には数万人規模を支えられるVR空間共有技術をリリースしていきたいと語っていました。VR-MMORPGやVRコンサート、実現される日が楽しみですね。

性能大幅向上！Monobit Revolution Server (MRS)

MRSは処理速度とレスポンスを追求したリアルタイムゲーム通信を実装するための通信エンジンです。今まで「リアルタイム通信エンジン」や「モノビットエンジン」と呼ばれてきた製品を置き換える製品として位置付けられています。

旧製品と比べて、何が変わったのかを次の3点で簡単にまとめてみます。

1. 圧倒的な性能アップ
   リアルタイム通信において一番の肝となるレイテンシーは、従来製品のミリ秒単位からマイクロ秒単位となり、またCPUスレッドあたりのスループットは秒間数万レコードから54万レコードまで向上しました(同時接続300の場合)。モノビットが本格的に数万人規模を支えるVR空間共有技術に向けて邁進しているのが実感できます。

2. 幅広い選択肢
   TCP以外にUDP、RUDPなど複数プロトコルに対応できるようになり、プロトコルを状況によって使い分けするような最適な構成が取れます。また、Unityはもちろん、Unreal EngineやCocos2d-xにも年内対応予定で、メジャーなゲームプラットフォームを一通り網羅できるよう進化を続けています。

3. 開発者をさらに楽にさせる
   サーバーサイドの開発言語はC++に加えC#も使えるようになりました。より処理速度面において優れるC++が使えるのはモノビットの差別化ポイントでもあり、大規模接続が予想されるMMORPGの開発が実現できます。また、サーバーOSはLinux以外にWindows、Macなども使用可能となりました。同じソースコードを異なるOSで動作させることができ、例えば開発は使い慣れているWindows、プロダクションはコストが安いLinuxなどと、開発の柔軟性がぐっと高まりました。

▲MRSの従来品との性能比較

本格的な大規模マルチプレイを実現！Monobit Unity Networking 2.0 (MUN2.0)

MUN2.0は上記MRSを用いて実装された、Unity用のプログラミングレスにマルチプレイを実現するミドルウェアです。従来、マルチプレイゲームを実装するにはネットワークの知識が必要なため、設計が難しかったり、開発コスト(リソース、時間)が増えたりと課題がたくさんありました。MUNを使えば、このようなネットワーク部分の作り込みが不要で、マッチングやゲームオブジェクト同期が簡単にできるようになります。MUN1.0(旧バージョン)と比べて、TCP以外にUDP、RUDPとマルチプロトコル対応になったのと、サーバーにC#/C++でコーディングができるようになりました。

MUN2.0を用いて、クライアントアプリ側にあるマルチプレイゲームのロジックをサーバー側に移植するデモを、モノビットミドルウェア事業部部長の安田様より行っていただきました。簡単なマルチプレイゲームでは、MUNを使ってクライアントアプリ側でロジックを持たせると実装は簡単になるものの、規模が大きくなってくるとチート対策について考える必要があります。また、ロジックを持っているホストマシンがネックになりゲームに支障が出る場合もありえるため、重要な判定はサーバーサイドで行い、クライアント側では判定結果や座標情報など簡単な情報のみ送信するのが望ましいです。

▲モノビット　ミドルウェア事業部部長　安田様

デモでは、2人のUnityちゃんが同じフィールド上で点取りを競うゲームを基に、元々1つのクライアントアプリで所有していたロジックをサーバー側に移植しました。コードはクライアントサイド、サーバーサイド共にVisual Studioを使ってC#で記述されており、軽微な改変のみで移植が完了し、ゲームが正常に動作できました。また、MUN2.0サーバーのソースコードもモノビット様HPにて公開されているため、自前でC++やC#で改造して、本格的なMMOも開発できます！

企画段階でわかる！MRSとMUNを使った際のインフラコスト

ゲーム開発における難題を企画段階から解決するための、MRSとMUNを使った際のリアルタイムゲームサーバーのインフラコスト予想ツールを、モノビット取締役CTOの中嶋様より紹介いただきました。ツールは今後MUNのドキュメントサイトに公開される予定です。

▲モノビット　取締役CTO　中嶋様

どうしてインフラコストを試算するのか
単純に運用に入ったあとのインフラコストが知りたい、というニーズももちろんありますが、それだけではありません。通常の流れですと企画が決まり、開発が始まり、最終的に運用に入るのですが、この3つの連携がうまく取れないことがあります。本来であれば、準備段階から運用と開発を見据えて、企画と設計を行うのが理想的です。企画が先走ってしまい開発が延びてしまったり、開発がうまくいかず運用を引きずってしまうようなトラブルを未然に防ぐためにも、きちんとした事前設計を行うのが効率的です。

リアルタイムゲームにおけるサーバーコンポーネント
一般的なリアルタイムゲームシステムには次の3つのコンポーネントがあり、今回のコスト試算対象は3つめのリアルタイムサーバーにフォーカスします。
　1. Webサーバー (一般的にいうフロントサーバー)
　2. DBサーバー
★3. リアルタイムサーバー

リアルタイムサーバーもさらに4種類の用途に分類ができ、それぞれmaster、resolver、proxyとroomサーバーです。Masterとresolverは1台のサーバーに常に1プロセスが動き続け、新規クライアントが参加するときだけ負荷がかかります。一方で、proxyとroomサーバーはゲームパケットの量に応じて台数がスケールしていき、かつゲーム中は負荷が続きます。これらのサーバーのボトルネックはサーバーCPUとなるため、設計もCPU負荷に応じて行う必要があります。

ツールを使って試算！
今回中嶋様に紹介いただいたツールはExcelのマクロを駆使したプログラムで、仮定パラメーターを入力すればサーバーとネットワーク転送のコストが表示されます。出力される結果は、IDCFクラウドのHighcpu.L8 (4 vCPUs, 8 GB RAM)の仮想マシンで測定したパフォーマンスを根拠としています。 入力するパラメーターの分類は大きく「アクセスパターンの仮定」、「プログラム仕様の仮定」と「仮定から予想される通信量」です。例えばアクセスパターンにはレコード送信頻度というパラメーターがあり、カードゲームなどでは比較的小さめな値となり、シューティングゲームでは大きめの値となったり、ゲームの特徴に応じて変数を設定していきます。

ツールのユースケースとして紹介されたのが、同時接続2万人のゲームが、最初の試算で転送量が400万になってしまった例です。この場合、開発者がただ一人で悩むのではなく、企画を交えてもっと良いゲーム設計ができないかを検討することが大事です。例では、一部屋の人数を4から3に減らしたり、32bitだった座標情報を16bitに下げてパケットサイズを小さくしたり工夫してみると、ネットワーク転送量が100万円ほど下がりました。このように開発の前段階でコミュニケーションをとりながら設計をするのが、みんなが幸せになる近道というメッセージを受け取りました。

企画、開発と運用のノウハウを持ち揃えたモノビットならではの視点ですね！

VR体験会

さて、当日の目玉であったVR体験会も大盛況でした！ゲームは5対5で玉入れの点数を競うゲームで、プレイヤー同士は10台のHTC Viveを通して同じ仮想空間に繋げられました。プレイヤーは皆VR内での玉取りに夢中になり、それを遠くから観察するのも面白かったです(笑)！個人的には、VRの魅力はまさにHMDを被っている人を現実世界から引き離すところにあると感じており、その仮想空間がいかに今後現実世界との区切りをぼかしていくのが楽しみです。

▲玉入れVRゲームに夢中

IDCFより

IDCFもお話をする機会をいただきました。IDCFのゲーム業界での事例や、イノベーションに対する取り組み、そしてVRに対しての私の思いをお話させていただきました。インフラ事業者としての品質や安定へのこだわり、またイノベーションへの積極的な姿勢は、IDCFの強みだと思います。そんな強みを生かして、今後より良いサービスを提供していきたいと考えていますし、特にゲーム業界ではその強みが生かしやすいです。品質についてはモノビット様からも評価いただきました、ありがとうございます！

▲IDCフロンティア　金杉

まとめ

今回のイベントには述べ75名のお客様にお越しいただき、本当に感謝してます！当日のモノビット様セッションの録画と資料はこちらに公開しているので興味ある方はぜひご覧ください。

アイデアは、1人でオフィスや家にこもっていても出てくるかもしれませんが、より良くなるのは難しい。やはり、コミュニケーションを取って、インプットとアウトプットを繰り返してこそイノベーションが形になると思っています。モノビット様と共催した今回のイベントが、ご来場いただいたみなさまに少しでも良い刺激になったのであれば、幸いです。

今後もこのようなイベントを開催する予定ですので、"IDCFとこんなことやってみたい！"などありましたら、お気軽にお問い合わせください。それでは、またお会いしましょう！

こんにちは！企画グループの神谷です。

今回は、IDCフロンティアが提供しているコンテンツ配信（CDN）サービスである、コンテンツキャッシュの新機能について紹介します。 5月10日のアップデートで追加された機能は2つです！

1. キャッシュ取り込み
2. エラー応答のキャッシュ停止

何が便利になったのか、それぞれの機能について見ていきたいと思います。また、これらの機能に関しては、コンテンツキャッシュ　スタートアップガイドに詳しく設定方法が記載されていますので、合わせてご参考ください。

1. キャッシュ取り込み

キャッシュ取り込みとは、オリジンサーバーのコンテンツをキャッシュサーバーにワンクリックで登録する機能です。
通常、コンテンツキャッシュの動作の流れは下図の通りです。 ▲図1:キャッシュ取り込みの概要

図1の通り、コンテンツをオリジンサーバーにアップロードするだけでは(ステップ①)、キャッシュサーバーにコンテンツは反映されません。ユーザーからのアクセスがあって(ステップ②)、初めてキャッシュサーバーがオリジンを参照し、コンテンツが登録されます(ステップ③)。

大規模なアクセスが一気にくるのをあらかじめ知っていたら、事前にキャッシュサーバーにコンテンツを登録させておいて、アクセス集中時のレスポンスを早くしたいですよね。その作業を、今まではcurlコマンドなどを用いて手動で行っていただく必要がありました。また、それぞれのキャッシュサーバーに登録させるために、図1のステップ③、④で示した手順を何度も行う必要がありました。そんな手間のかかる作業が、今回のキャッシュ取り込みの新機能でクラウドコンソールから自動で実行可能になりました！

これにより、

• コンテンツ登録後の、オリジンサーバーへの負荷軽減
• キャッシュサーバーへのコンテンツ登録作業時間削減

などの効果が期待できます！

キャッシュ取り込みは、図2のように、クラウドコンソールから設定したいキャッシュサーバーをクリックし、取り込みたいコンテンツ名を入力、「取り込む」ボタンを押すことで実行可能です！また、コンテンツが取り込まれているかどうかを、「確認する」ボタンからチェック可能です。 ▲図2:キャッシュ取り込み機能設定方法

2.エラー応答のキャッシュ停止

コンテンツキャッシュを用いたシステムを運用していると、オリジンサーバーの障害や負荷集中などで、キャッシュサーバーからのリクエストに対しエラー応答を返す場合があります。 ▲図3:オリジンサーバーの障害発生時

今までのコンテンツキャッシュでは、エラー応答と正常応答を区別する仕組みがなく、エラー応答もキャッシュしてしまっていました(図3の③と④)。よって、オリジンサーバーが復旧後もエラーページを表示してしまう…ということが発生していました(図4)。 回避策として、オリジンサーバー側でCache-Controlヘッダのmax-age値を調整し、エラー応答のキャッシュ保持期間を短縮することはできます。しかし、Cache-Controlヘッダの設定ができないサービス（例：オブジェクトストレージ）をオリジンサーバーとして設定している場合、回避することはできませんでした。

▲図4:オリジンサーバー復旧後

今回の「エラー応答のキャッシュ停止」機能では、オリジンサーバーからのエラー応答のキャッシュを制御できるようになりました！この機能を有効化すると、応答が正常な場合はキャッシュし、エラーの場合はキャッシュしないようにできます。これにより、サービスの種別を問わず、オリジンサーバー障害時のダウンタイムを最小限にとどめることが可能になりました。

図5のように、キャッシュサーバー作成時、エラー応答のキャッシュ停止の項目で「有効にする」を選択することで設定が完了します。
▲図5:エラー応答のキャッシュ停止機能設定方法

まとめ

今回は5月10日のコンテンツキャッシュのアップデートで追加された、次の2つの機能について紹介しました。どちらもコンテンツキャッシュサービスをさらに使いやすくさせたと思います。

1.キャッシュ取り込み
2.エラー応答のキャッシュ停止機能

こういった小さなアップデートで、IDCFクラウドのユーザビリティを少しずつ高めていきますので、今後ともご期待ください！

こんにちは、金杉です。

HTTP/2やH2Oをご存知の方は多くいらっしゃるかと思います。今回のブログでは、IDCFクラウド上でH2OのWebサーバーを構築して、Google Chromeデベロッパーツールとh2loadを使ってHTTP/2のレスポンスを測ってみようと思います。使う証明書は無料のLet’s Encryptです。先に結論を申し上げますと、H2OのWebサーバーは思った以上に簡単に立てることができ、予想通りHTTP/1.1より早かったです！

• HTTP/2とは？
• HTTP/2のすごいところ
• H2O WebサーバーをIDCFクラウド上で構築
  • 利用環境
  • Let’s Encrypt証明書の取得
  • H2Oのインストール
  • h2o.confファイル設定
  • H2O起動
• レスポンス計測してみる
  • Google Chromeデベロッパーツールで見る
  • h2loadでベンチマーク
• まとめ

HTTP/2とは？

HTTP/2は、Webプロトコルの一種で、従来のHTTPの上位版もしくはバージョン2として認識されています。2015年2月17日に正式に仕様が公開され、IETF HTTP Working Groupによって管理されています。

HTTP/2という規格が誕生した経緯はWeb世界の急速な発展にあります。昔のWebサイトはレイアウトが単純で、コンテンツもほぼ静的で数も少なかったです。しかし、今はページに1回アクセスするにあたり、リクエストが数十、数百と発生するのが一般的です。例えばIDCフロンティアのコーポレートサイトも1ページに100以上の項目があります。リッチコンテンツが増えれば表示までの待ち時間が増えるのが当然ですが、ユーザーは待ってくれません。なので、Webの高速化は前から認識されていた課題でした。

高速化に向けて、今までサーバーサイド、クライアントサイドでもたくさんの人が頑張ってきましたが、そもそもプロトコルレベルから見直さないか？という思いから、SPDYやHTTP/2が誕生しました。SPDY（スピーディ）は、HTTP/2の前身とも言われており、2009年にGoogle社によって開発されました。SPDY/1、SPDY/2、SPDY/3と数回アップデートされ、それを基にHTTP/2は設計されています。

HTTP/2のすごいところ

HTTP/2が従来のHTTP/1.1と比べて高速な理由はたくさんあります。HPACKを使ったヘッダー圧縮や、バイナリ化、そしてサーバープッシュ通信機能が実装されています。これら以外に一番大きく変わった点は、ストリームの多重化です。HTTP/1.1では、1つのTCPコネクションにおいて、リクエスト〜レスポンスのセットを同時に1つしか送受信できませんでした。なので重たいリクエストがあると、それに引きずられ全体の読み込み時間が長くなってしまいます。1車線の対面通行道路が渋滞を起こしやすいのと同じです。一方HTTP/2では、1つのTCPコネクションにおいて複数のリクエスト〜レスポンスのセットを同時に送受信できます。1つのリクエスト〜レスポンスのやりとりをストリームと呼び、このストリームを多重化することにより効率化を測っています。車線が増えて、パラレルに運行できるようになった感じです。

HTTP/1.1と比べてどれくらい早くなったのかについては、後ほど計測してみます。

H2O WebサーバーをIDCFクラウド上で構築

H2Oは2014年の年末にリリースされた新世代のWebサーバーです。Apache、NginxなどのメジャーなWebサーバーミドルウェアは一通りHTTP/2に対応しています。その中でも、H2OはHTTP/2対応を目的に一から設計されているため、最適化されています。

利用環境

今回、IDCFクラウドで構築するH2Oサーバーの詳細は次の通りです。仮想マシン作成の手順はこちらを参考にしてください。

• IDCFクラウド Standard.S4 （1 CPU, 4GB メモリ）
• CentOS 7.3 64-bit テンプレート
• Let’s EncryptでSSL証明書を発行
• 「IPアドレス」でSSH（22番）、HTTP（80番）、HTTPS（443番）のポートフォワードとファイアウォールの設定
• DNSでドメイン名を登録しておく (以下myDomain)

Let’s Encrypt証明書の取得

# yum -y install epel-release
# yum -y install certbot

# certbot certonly --standalone --agree-tos -m <emailAddress> -d <myDomain>

実行の結果、「〜〜Congratulations!〜〜 」と表示されれば取得は完了です。鍵は次のパスに設置されています。

# ls /etc/letsencrypt/live/myDomain/
README  cert.pem  chain.pem  fullchain.pem  privkey.pem

H2Oのインストール

ソースからダウンロードします。オフィシャルドキュメントに丁寧に書かれているので、合わせて参考にしてください。今回はバージョン2.2.0を使用します。

# yum groupinstall "Development Tools"
# yum install cmake libyaml-devel openssl-devel
# wget https://github.com/h2o/h2o/archive/v2.2.0.tar.gz
# tar xvzf v2.2.0.tar.gz
# cd h2o-2.2.0/
# cmake .
# make h2o
# make install

h2o.confファイル設定

オフィシャルドキュメントを参考に、h2o.confファイルを/usr/local/etc/h2o/配下に作成します。 関連するlogファイルも合わせて作成しておきます。

# mkdir -p /var/www/h2o
# mkdir /var/log/h2o/
# touch /var/log/h2o/access_log
# touch /var/log/h2o/error_log
# vi /usr/local/etc/h2o/h2o.conf
hosts:
  "myDomain":
    listen:
      port: 80
    listen:
      port: 443
      ssl:
        certificate-file: /etc/letsencrypt/live/myDomain/cert.pem
        key-file:         /etc/letsencrypt/live/myDomain/privkey.pem
    paths:
      "/":
        file.dir: /var/www/h2o

access-log: /var/log/h2o/access_log
error-log: /var/log/h2o/error_log
http2-reprioritize-blocking-assets: ON   # performance tuning option

H2O起動

それでは上記で作成したconfファイルを指定してH2Oサーバーを起動します。トップページも適当なものを用意しておきます。

# /usr/local/bin/h2o -c /usr/local/etc/h2o/h2o.conf &

ブラウザからhttpsでアクセスして、画面が表示されれば成功です！

レスポンス計測してみる

Google Chromeデベロッパーツールで見る

冒頭でも説明した通り、HTTP/2の特徴はストリームの多重化です。なので、我が家の愛犬たらちゃん©の画像をたくさんページに並べて、HTTP/1.1とHTTP/2両方でアクセスします。Google ChromeのデベロッパーツールのNetworkパネルを開いて、リソースの読み込み時間を観測します。

まず、全体の読み込みにかかった時間はHTTP/1.1が3.96秒に対し、HTTP/2が3.14秒と約20%改善されています。暗号化されているのに、20%も改善されているのはすごいです！また、2つのグラフを比べて一目瞭然ですが、画像の読み込みをHTTP/1.1が逐次行っているのに対し、HTTP/2では並列に取得しています。先ほども紹介した、ストリームの多重化ですね。

▲HTTP/1.1でアクセスした場合

▲HTTP/2でアクセスした場合

h2loadでベンチマーク

Webサーバーのベンチマークツールで有名なのはab (apache bench)ですが、abはHTTP/2に対応していないため、今回はh2loadを使ってパフォーマンスを計測します。ベンチマークの対象は先ほどと同じページです。h2loadは非常に便利で、nghttp2というパッケージに同梱されており、これをソースからbuildします。h2loadコマンドに–h1オプションをつけることによって、HTTPSのURIでも強制的にHTTP/1.1で計測するように指定できます。では、早速両方試してみます。

まずはHTTP/1.1です。リクエスト数は10,000、コネクション数は100を指定します。

# h2load -n 10000 -c 10 --h1 https://myDomain
starting benchmark...
spawning thread #0: 10 total client(s). 10000 total requests
TLS Protocol: TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Server Temp Key: ECDH P-256 256 bits
Application protocol: http/1.1
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 387.58ms, 25800.86 req/s, 37.01MB/s
requests: 10000 total, 10000 started, 10000 done, 10000 succeeded, 0 failed, 0 errored, 0 timeout
status codes: 10000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 14.34MB (15040000) total, 1.76MB (1850000) headers (space savings 0.00%), 12.09MB (12680000) data
                     min         max         mean         sd        +/- sd
time for request:      166us      3.96ms       334us       104us    89.38%
time for connect:    17.05ms     20.88ms     18.89ms      1.26ms    60.00%
time to 1st byte:    21.00ms     21.21ms     21.11ms        71us    60.00%
req/s           :    2583.92     3093.93     2832.31      139.99    70.00%

続いてHTTP/2です。HTTP/1.1と同じように、リクエスト数は10,000、コネクション数は100を指定します。

# h2load -n 10000 -c 10 https://myDomain
starting benchmark...
spawning thread #0: 10 total client(s). 10000 total requests
TLS Protocol: TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Server Temp Key: ECDH P-256 256 bits
Application protocol: h2
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 359.23ms, 27837.47 req/s, 34.52MB/s
requests: 10000 total, 10000 started, 10000 done, 10000 succeeded, 0 failed, 0 errored, 0 timeout
status codes: 10000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 12.40MB (13001100) total, 137.50KB (140800) headers (space savings 91.95%), 12.09MB (12680000) data
                     min         max         mean         sd        +/- sd
time for request:      161us      3.00ms       314us       101us    89.77%
time for connect:    17.15ms     21.03ms     19.00ms      1.26ms    60.00%
time to 1st byte:    21.10ms     21.35ms     21.21ms        71us    60.00%
req/s           :    2788.66     3349.59     2984.09      176.11    60.00%

一見ちょっとわかりづらいので表組みにしてみます。笑

結論、HTTP/2は優秀でした。

• 秒間リクエスト数がHTTP/2のほうが多く、ベンチマークにかかった時間も10%弱少なかった
• ヘッダー圧縮が効いているので、トラフィックサイズもHTTP/2のほうが少ない
• そもそもHTTP/2は暗号化されているので、HTTP/1.1より成績が良い時点で文句なし

まとめ

IDCFクラウド上でさくっとH2OのWebサーバーを立ててHTTP/2化する方法を紹介しました。HTTP/1.1と比べ、性能的にも帯域使用量においても改善されているため、みなさんもぜひHTTP/2を試してみてください！なお、今回使用したLet’s Encryptの無料SSL証明書は3ヶ月で有効期限が切れてしまうので、cronなどで自動更新を仕掛けておくのが良いでしょう。

IDCFクラウドでロードバランシングをする際の選択肢として、仮想ルーターの標準ロードバランサー機能とILBが挙げられますが、ILBは現在HTTP/2未対応のため、HTTP/2を使いたい場合は仮想ルーターでHTTPSのままロードバランシングするのをおすすめします。また、IDCFクラウドのコンテンツキャッシュも今年夏ごろHTTP/2に対応する予定なので、その時は別エントリーで改めて紹介します。

こんにちはー、梶川です。今は「データビジネス本部」と言う、BigDataやらIoTやらを扱う部におります。久し振りにブログ書きますー。
今回は、Apache NiFiについての紹介です。

Apache NiFiとは？

Apache NiFiってご存知でしょうか。Apache NiFiはシステム間のデータフローをWebベースUIから定義することができるシステムで、パッと見データの流れをとても分かりやすくしてくれます。また、スケーラブルな構成も可能となっており、ビッグデータやIoTなどのデータを処理するのに適しています。

ピンとこないですよね。もっと簡単に例を言うと、「HTTPでデータを受けて、データをJSONに変換し、ファイルへ保存」のように(もちろんこれだけではない。)、システム間のデータの流れをWebベースUIで定義し、実行することができます。

こんな感じです。

このように、データの流れが一目で分かる形になります。

今回は、Apache NiFiのインストール方法の紹介をしたいと思いますが、IDCFクラウドの連携サービスであるHortonworksのHortonworks DataFlow (HDF™)を利用したセットアップを紹介します。また、Hortonworksでは、Future of DataでHortonworks DataFlow (HDF™)のハンズオンなどを定期的に実施されていますので、参加してみても良いかと思います。時間が合わない、遠くていけない、といった方もおられると思いますので、こちらのハンズオンで提供されている資料をみながら進められる程度までは、今回のブログで紹介します。

なお、別になりますが、Hortonworksでは「Hortonworks Data Platform (HDP®)」といったHadoopディストリビューションも提供(こちらの方が有名で、ご存知の方も多そうです。)しており、こちらに興味がある方は、HDPをAmbariでインストールなどを参照してみてください。

ドキュメントについて

今回のインストールはHortonworksが提供しているドキュメントに基づいています。
Apache Ambari Installation
本ブログでは、IDCFクラウドのテンプレートを利用するうえでは不要と思われる手順を省略していますので、以降の手順で困った場合は、この公式ドキュメントも参照してみてください。

利用環境について

今回インストールに使用したHDFのバージョンは2.4.1になります。どんどん新しいバージョンがリリースされていますので、インストールされる時には2.4.1が最新では無いかもしれませんが、基本的なインストール手順が変わるわけではないため、違うバージョンをインストールする場合でも参考にはなると思います。

環境 : IDCFクラウド
      OS : CentOS 7.3 64-bit (IDCFクラウド標準テンプレート)
スペック : standard.S8
     HDF : Version 2.4.1

OSの準備

HDFは各OSに対応していますが、今回はCentOS7へインストールしてみようと思います。まずは、IDCFクラウド上で仮想マシンを作成してください。こちらのブログ執筆時点で最新の「CentOS 7.3 64-bit」を選択しましたが、CentOS7系の最新を選択してください。以下の記事では、テンプレートとして提供しているCentOS 7.3を想定しています。メモリは8GB程度は欲しいので、スペックは「standard.S8」以上を選択してください。

OSの設定

CentOSインストール後に、次の設定を行ってください。

CentOS7を最新にアップデート & openjdkのインストール

# yum -y update
# yum -y install java-1.8.0-openjdk-devel
# init 6

sshの設定

HDFでは、管理ツールであるAmbariからターゲットホストに対してsshでログインし、各ソフトウェアをインストールしますので、Ambari(今HDFをインストールしようとしているホスト)からsshでパスワードレスで入れる必要があります。今回は1ホストにすべてのソフトウェアをインストールするため、自分自身のホストにsshでパスワードレスログインができればokです。もし、複数ホストを利用してセットアップする場合は、Ambari(今HDFをインストールしようとしているホスト)からsshでパスワードレスで入れる用に設定してください。(つまり、複数ホストへの分散インストールなども簡単にできるということになります。)

# ssh-keygen -f /root/.ssh/id_rsa -N ''
# cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys 

Ambariのインストール

HDFでは管理ツールにAmbariを利用しますので、まずはAmbariをインストールします。 AmbariのRepositoryを設定し、yumでインストールしていきます。

# wget -nv http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.4.2.0/ambari.repo -O /etc/yum.repos.d/ambari.repo
# yum -y install ambari-server

※ PostgreSQLが一緒にインストールされます。AmbariではバックエンドにPostgreSQLを使うのがデフォルトですが、MySQLなど他のRDBを選択することもできます。詳細はドキュメントを参照してください。

Ambariのセットアップ

次に、インストールしたAmbariをセットアップします。 いくつか質問されますが、基本的にはデフォルトの選択で大丈夫です。ただし、Javaの選択については、「[3] Custom JDK」を選択して、「Path to JAVA_HOME」へ「/usr/lib/jvm/java」を設定してください。

# ambari-server setup

Using python  /usr/bin/python
Setup ambari-server
Checking SELinux...
SELinux status is 'disabled'
Customize user account for ambari-server daemon [y/n] (n)? 
Adjusting ambari-server permissions and ownership...
Checking firewall status...
Checking JDK...
[1] Oracle JDK 1.8 + Java Cryptography Extension (JCE) Policy Files 8
[2] Oracle JDK 1.7 + Java Cryptography Extension (JCE) Policy Files 7
[3] Custom JDK
==============================================================================
Enter choice (1): 3
WARNING: JDK must be installed on all hosts and JAVA_HOME must be valid on all hosts.
WARNING: JCE Policy files are required for configuring Kerberos security. If you plan to use Kerberos,please make sure JCE Unlimited Strength Jurisdiction Policy Files are valid on all hosts.
Path to JAVA_HOME: /usr/lib/jvm/java
Validating JDK on Ambari Server...done.
Completing setup...
Configuring database...
Enter advanced database configuration [y/n] (n)? 
Configuring database...
Default properties detected. Using built-in database.
Configuring ambari database...
Checking PostgreSQL...
Running initdb: This may take up to a minute.
Initializing database ... OK

About to start PostgreSQL
Configuring local database...
Connecting to local database...done.
Configuring PostgreSQL...
Restarting PostgreSQL
Extracting system views...
ambari-admin-2.4.2.0.136.jar
............
Adjusting ambari-server permissions and ownership...
Ambari Server 'setup' completed successfully.

HDF Management Pack

Ambariはデフォルトでは「Hortonworks Data Platform (HDP®)」を管理するように設定されています。HDFの管理を行うために、HDF Management Packのインストールが必要です。 インストールで--purgeを指定しているため、インストールの途中で既存のスタック定義を削除して置き換えるが良いか？と聞かれますが、「yes」を選択してください。

# ambari-server install-mpack --mpack=http://public-repo-1.hortonworks.com/HDF/centos7/2.x/updates/2.1.4.0/tars/hdf_ambari_mp/hdf-ambari-mpack-2.1.4.0-5.tar.gz --purge --verbose

Using python  /usr/bin/python
Installing management pack
INFO: Installing management pack http://public-repo-1.hortonworks.com/HDF/centos7/2.x/updates/2.1.4.0/tars/hdf_ambari_mp/hdf-ambari-mpack-2.1.4.0-5.tar.gz
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Download management pack to temp location /var/lib/ambari-server/data/tmp/hdf-ambari-mpack-2.1.4.0-5.tar.gz
INFO: Downloading http://public-repo-1.hortonworks.com/HDF/centos7/2.x/updates/2.1.4.0/tars/hdf_ambari_mp/hdf-ambari-mpack-2.1.4.0-5.tar.gz to /var/lib/ambari-server/data/tmp/hdf-ambari-mpack-2.1.4.0-5.tar.gz
INFO: Downloading to: /var/lib/ambari-server/data/tmp/hdf-ambari-mpack-2.1.4.0-5.tar.gz Bytes: 38750066

INFO: Finished downloading http://public-repo-1.hortonworks.com/HDF/centos7/2.x/updates/2.1.4.0/tars/hdf_ambari_mp/hdf-ambari-mpack-2.1.4.0-5.tar.gz to /var/lib/ambari-server/data/tmp/hdf-ambari-mpack-2.1.4.0-5.tar.gz
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Expand management pack at temp location /var/lib/ambari-server/data/tmp/hdf-ambari-mpack-2.1.4.0-5/
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: AMBARI_SERVER_LIB is not set, using default /usr/lib/ambari-server
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: about to run command: /usr/lib/jvm/java/bin/java -cp '/etc/ambari-server/conf:/usr/lib/ambari-server/*:/usr/share/java/postgresql-jdbc.jar' org.apache.ambari.server.checks.MpackInstallChecker --mpack-stacks HDF
CAUTION: You have specified the --purge option with --purge-list=['stack-definitions', 'mpacks']. This will replace all existing stack definitions, management packs currently installed.
Are you absolutely sure you want to perform the purge [yes/no]? (no) yes
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Purging existing stack definitions and management packs
INFO: Purging stack location: /var/lib/ambari-server/resources/stacks
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Stage management pack hdf-ambari-mpack-2.1.4.0-5 to staging location /var/lib/ambari-server/resources/mpacks/hdf-ambari-mpack-2.1.4.0-5
INFO: Processing artifact hdf-service-definitions of type service-definitions in /var/lib/ambari-server/resources/mpacks/hdf-ambari-mpack-2.1.4.0-5/common-services
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Symlink: /var/lib/ambari-server/resources/common-services/NIFI/1.0.0
INFO: Symlink: /var/lib/ambari-server/resources/common-services/NIFI/1.1.0
INFO: Processing artifact hdf-stack-definitions of type stack-definitions in /var/lib/ambari-server/resources/mpacks/hdf-ambari-mpack-2.1.4.0-5/stacks
INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/configuration
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/hooks
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/kerberos.json
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/metainfo.xml
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/properties
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/repos
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/role_command_order.json
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/AMBARI_INFRA
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/AMBARI_METRICS
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/KAFKA
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/KERBEROS
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/LOGSEARCH
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/NIFI
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/RANGER
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/STORM
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/ZOOKEEPER
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/services/stack_advisor.py
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/upgrades
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.0/widgets.json
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.1/metainfo.xml
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.1/repos
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.1/services/KAFKA
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.1/services/NIFI
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.1/services/RANGER
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.1/services/STORM
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.1/services/ZOOKEEPER
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.1/services/stack_advisor.py
INFO: Symlink: /var/lib/ambari-server/resources/stacks/HDF/2.1/upgrades
INFO: Management pack hdf-ambari-mpack-2.1.4.0-5 successfully installed!
INFO: Executing after-install hook script : /var/lib/ambari-server/resources/mpacks/hdf-ambari-mpack-2.1.4.0-5/hooks/after_install.py
INFO: about to run command: ['/usr/bin/ambari-python-wrap', u'/var/lib/ambari-server/resources/mpacks/hdf-ambari-mpack-2.1.4.0-5/hooks/after_install.py']
INFO: Keeping views jar : /var/lib/ambari-server/resources/views/ambari-admin-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/capacity-scheduler-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/files-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/hawq-view-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/hive-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/hive-jdbc-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/hueambarimigration-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/pig-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/slider-2.4.2.0.136.jar
Keeping views jar : /var/lib/ambari-server/resources/views/storm-view-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/tez-view-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/wfmanager-2.4.2.0.136.jar
Deleting views jar : /var/lib/ambari-server/resources/views/zeppelin-view-2.4.2.0.136.jar
Deleting views directory : /var/lib/ambari-server/resources/views/work

INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
Ambari Server 'install-mpack' completed successfully.

Ambariの起動

それでは、Ambariを起動しましょう。

# ambari-server start

Using python  /usr/bin/python
Starting ambari-server
Ambari Server running with administrator privileges.
Organizing resource files at /var/lib/ambari-server/resources...
Ambari database consistency check started...
No errors were found.
Ambari database consistency check finished
Server PID at: /var/run/ambari-server/ambari-server.pid
Server out at: /var/log/ambari-server/ambari-server.out
Server log at: /var/log/ambari-server/ambari-server.log
Waiting for server start....................
Ambari Server 'start' completed successfully.

HDFのインストール

Ambariのインストールが終わったら、AmbariからHDFのインストールを行っていきます。 ブラウザでAmbariへアクセスする必要があるため、IDCFクラウド上でIPアドレスの設定を行ってください。 ポートフォワードの設定を行うか、スタティックNATの設定を行い、ファイアウォールの設定を行います。

仮想マシンへの接続方法 ポートフォワード編
仮想マシンへの接続方法 スタティックNAT編
ファイアウォールの設定方法

Ambariはデフォルトで「ポート8080」で起動しています。

上述は正攻法なのですが、AmbariからNiFi UIへのリンクなどが、ホスト名(hdf-sv1.cs3cidcfcloud.internalなど、DHCPから設定される名前)でリンクされているので、次の方法でアクセスするのがオススメです。

IDCFクラウドの内部DNS名にブラウザで直接アクセス(小ネタ)

この方法であれば、直接ホスト名でアクセス可能になります。 (「 http://hdf-sv1.cs3cidcfcloud.internal:8080/」や「 http://hdf-sv1.cs3cidcfcloud.internal:9090/nifi/」などと、ホスト名でアクセスできます。)

ログイン

それではブラウザで、セットアップしたサーバの8080ポートへアクセスしてください。 デフォルトのID/PWはadmin/adminとなっていますので、ログインしてください。

ここから、「Launch Install Wizard」をクリックし、Wizardにしたがってインストールしていきます。

各ソフトウェアのセットアップ

セットアップするクラスタに名前を付けます。

HDFのバージョンを選択します。デフォルトで選択されている「HDF-2.1.4.0」で問題ありません。

インストールオプションでは、インストール先ホストの選択を行います。今回は1ホストにすべてをインストールするため、Target HostsへAmbariをインストールした自分自身のホスト名(サーバーコンソール上で、hostname -fで表示されるホスト名。)を指定します。
また、「Provide your SSH Private Key to automatically register hosts」へOS設定時に作成したssh-keyを指定します。(あまりセキュアなやり方ではありませんが、サーバーコンソール上で、cat /root/.ssh/id_rsaで表示される内容を貼り付けてください。セキュリティを気にされる方は、別の方法でお願いします。)

インストール先ホストに問題がないかがチェックされます。 「Click here to see the warning.」をクリックすると、warningが確認できるのですが、IDCFクラウドのCentOS7テンプレートからインストールしている場合、「Service Issues(1)」で「ntpd Not running」となっていると思います。

これは、CentOS7では時刻同期にntpdではなく、chronyが利用されるようになったため、ntpdがインストールされていないためです。ntpdを入れることもできますが、要は時刻同期がされていれば問題ないため、このまま進めて問題ありません。

Warningが残っていると進めてよいか聞かれますが、問題点がntpdだけであればそのまま進めましょう。

次に、インストールするサービスの選択になります。デフォルトでNiFiは選択されていますので、今回はすべてデフォルトで行います。

ここでは、どのホストにどのサービスを入れるかの指定になりますが、今回は1台のサーバーにすべてをインストールするため、このまま次へ進めます。(複数ホストで構成する場合、ここでどのホストに何を入れるかを指定できます。また、冗長構成が可能なサービスは、冗長構成でのインストールも可能です。)

次に複数のSlaveを持てるサービスや、各サービスのクライアントツールをどのホストにインストールするかの指定を行います。ここも、今回は1ホストしかないため、デフォルトのまま次へ進みます。

次に各サービスのコンフィグレーション設定を行います。赤くなっている部分は必ず指定しなければならないパラメーターが指定されていないことを示しているため、指定しましょう。

「Ambari Metrics」の「General」の「Grafana Admin Password」が赤くなっていますので、パスワードを指定します。

「NiFi」の「Advanced nifi-ambari-config」の「Encrypt Configuration Master Key Password」「Sensitive property values encryption password」が赤くなっていますので、パスワードを指定します。なお、パスワードは12文字以上の文字列を指定しないと、NiFiが起動すらしない事態に陥るのでご注意ください(もちろん私はハマりました)。

次に進むと、指定したコンフィグがチェックされ、問題があれば報告されます。Warningとして、いくつかのパラメータ推奨と、ErrorとしてNiFiの「nifi.toolkit.token」が指摘されますが、今回は影響無いのでそのまま進めます。もちろん説明を読んでもらって、パラメーターを修正していただいても良いと思います。もちろん、セットアップ後にも修正できます。

最後にレビューが表示されます。問題なければ次へ進みましょう。

インストールが進んで、100％になりSuccessとなれば、完了です！

インストール後のAmbariはこのような画面になります。

最後にもう一つ、先に紹介したHDFのハンズオンではStormを使うため、StormのViewを設定しておきましょう。

右上の「admin」をクリックし、左のメニューから「Views」を選択します。「Create Instance」をクリックします。

各パラメーターをスクリーンショットのように設定してください。

画面右上のadminのすぐ隣りのメニューから「Storm_View」を選択すると、StormのUIを表示できるようになります。

HDFハンズオンの資料の補足

あとは、Future of DataのHDFハンズオンで利用されている、HDFのハンズオンの資料をみながらApache NiFiを試してみればよいのですが、こちらのハンズオンの中では、Stormのアプリケーンは既にセットアップ済みといった形で進んでいきます。

ここでは補足として、このStormアプリのコンパイル方法と実行方法を記載しておきます。 あまり細かくは記載しませんが、mavenを使ってコンパイルするため、mavenのインストール、git cloneして、コンパイルして、storm上で実行、の流れになります。

# yum -y install maven

# git clone https://github.com/ijokarumawak/hdf-tutorials-ja.git

# cd hdf-tutorials-ja/storm
# mvn package

hdf-tutorials-ja/storm/targetディレクトリの下に、hdf.tutorial.storm-1.0-SNAPSHOT.jarと言うファイル名でjarファイルができあがります。これを、stormコマンドで実行します。

# storm jar target/hdf.tutorial.storm-1.0-SNAPSHOT.jar com.hortonworks.hdf.tutorial.storm.ReportingTopology "HOST_NAME:6667" "input" "report" 10 3

上記のHOST_NAMEはhostname -fで表示されるホスト名を指定してください。 実行時に「/usr/bin/storm: 行 2: /usr/hdf/2.1.4.0-5/etc/default/hadoop: そのようなファイルやディレクトリはありません」とエラーが表示されますが、問題ありません。

Storm UIからみると「ReportingTopology」と言う名前のTopologyが登録されているのがわかります。

その他のHDFハンスオンドキュメントの注意事項として、

• Kafka Brokersに「0.hdf.aws.mine」とホスト名を指定する箇所がありますが、IDCFクラウドでは、当然これでは動かないのでhostname -fで表示されるホスト名を指定してください。
• PutFile Processorで出力Directoryを指定する箇所がありますが、存在しないので予め作成しておく必要があります。また、NiFiの起動ユーザー(nifi)での書き込み権限が必要です。

# mkdir -p /opt/hdf-handson/report
# chmod 777 /opt/hdf-handson/report

• KafkaのtopicはNiFiが作ってくれるようなので、予め作っておく必要はありません。

これで、一通りHDFハンズオンを実行できると思います。 皆さん試してみてください！

最後の最後に….

ここまできてから言うのもなんですが、HDFはSandboxの形でVMwareのOVAイメージが公開されています。 こちらをIDCFクラウドへインポートすることでも、HDFを利用することができます。 私の方ではインポートして動くところまでは確認しています。ただ、やはりIDCFクラウドへ最適化されているわけではないため、上述のようにIDCFクラウドの標準テンプレートをベースにインストールすることをオススメします。

こんにちは、松本です。6月13日（火）にYahoo! JAPANの本社にて、社会にイノベーションを起こすであろう、AI（人工知能）・Deep Learningの最新技術動向と事例を紹介したセミナーを開催しました。

今話題の半導体メーカーのエヌビディアや株式会社ABEJA、HPCシステムズ株式会社など国内最先端の企業の方々に登壇いただきました。IDCフロンティア（以下IDCF）も最後に少しお時間をいただき、GPUクラウドの運用のウラ話をさせていただきました。GPUのクラウドサービスを提供する事業者としても、国内最先端のお話ばかりで大盛況であった当日の様子をこのブログにてお伝えいたします。

エヌビディア GPU技術最新情報

最初は、エヌビディアの佐々木邦暢様のご講演です。
ここ数年で、いつしかGPUメーカーといえばエヌビディアの時代になってきました。先月のGPU Technology Conference 2017（以下 GTC 2017）であったGPU Tesla V100の発表もそうですが、技術革新のスピードが早く、そんな勢いを大切にしている印象でした。

▲エヌビディア　佐々木 邦暢様

①10年間の振り返り
AI業界はここ10年で目まぐるしい進化を遂げています。2006年は、CUDAが発表された年です。当時は、やっと物体認識を少しできるようになりましたが、特定の物体を正確に認知するのはまだ困難でした。それが10年経った今では、AIが人間を超えたというニュースもちらほら聞くようになりましたし、様々な分野での応用例が公開されています。ディープニューラルネットワーク（DNN）、ビッグデータとGPU、この3つの要素の進歩によって、Deep Learningは加速を続けています。

②事例紹介
GTC 2017でエヌビディアとSAPが提携すると発表がありました。これにより、ブランドインパクトのROIの測定が容易にできるようになります。例えば、テレビで放送される試合のスポンサーは、今まで自社の広告がどれだけの収益に繋がったのか可視化するのは困難でした。Deep Learningを活用すれば、リアルタイムで画面に表示されるロゴの露出時間を測定でき、即時かつ正確にスポンサーへフィードバックすることができます。このような応用が増えていけば、ビジネスがさらにスマートになりますし、新たなビジネスモデルも生まれてくるでしょう。

③最新のGPU事情
エヌビディアのGPUは主にHPC & Cloud用のTeslaシリーズ、プロフェッショナルグラフィックス用のQuadroとゲーミング用のGeForceがありますが、今回注目していきたいのはHPC & Cloud用のTeslaシリーズです。先日の GTC 2017 で最新アーキテクチャ Voltaとその最初の製品であるTesla V100が発表されました。Tesla V100(Volta)は前世代のP100(Pascal)と比べ、トレーニング速度が12倍、推論速度が6倍と大きな飛躍を遂げました。さらに、このV100を8基搭載したDGX-1というスーパーコンピューターやNVIDIA GPUクラウドなど、たくさんの新製品の話もありましたので、さらに知りたい方はぜひ次の資料をご覧ください。

ハードウェアがソフトウェアやビジネスを引っ張っていくのは斬新であり、夢が無限に膨らんでいきます。今後もエヌビディアのイノベーションに注目していきたいと思います。

IoT、ビッグデータ、人工知能がリードする第四次産業革命

次に、株式会社ABEJA代表取締役社長の岡田陽介様にABEJAのAIプラットフォームについてご講演いただきました。 ABEJAはAI業界で有名なベンチャー企業で、エヌビディアがアジアで唯一出資している会社です。とにかくイノベーションにこだわっており、その想いと技術力が、今皆始めようとしているIoT×ビッグデータをより簡単に実現してくれるのだと岡田社長の講演で感じました。

▲株式会社ABEJA　岡田 陽介様

①ABEJA Platformとは？
ABEJA PlatformはビッグデータやIoTの集積・学習・推論・レポーティングをシンプルかつワンストップで実現させるAIプラットフォームです。クラウドで学習させた結果を簡単にエッジにデプロイする仕組みを持っており、また、プラットフォームには全てAPIベースでアクセスできます。AIに関しての深い知識がなくても、最低限のエンジニア知識があれば、誰でもインテリジェントにデータを扱うことができるプラットフォームです。

②事例の紹介
実際にABEJA Platformを利用している事例で、実店舗での顧客滞在データの解析があげられました。顧客属性から行動や滞在場所・時間などの可視化するものでした。また、製造業では部品の故障予知・検知で活用されていたり、サービス業ではBOTによるサポートで活用されていたりと、改めてAI活用分野でのABEJAの優位性を知ることができました。

③Operationにおける強み
ABEJAの強みはOperationにあります。IoTデバイスのよくある問題は、部品故障です。デバイスの故障は、データが取れなくなるくらいと思われがちですが、貴重なビジネスチャンスを逃している可能性もあります。ABEJAは、IoTデバイスにホットスタンバイを用意しておき、問題発生時にロストなく切り替わりができるよう自動化しておくようなソリューションも提供しています。また、ABEJAのエコシステムでは全レイヤーを網羅できる強いパートナーが揃っているため、導入から運用の一貫性が保てます。さらに知りたい方は次の資料もご覧ください。

【資料】株式会社ABEJAが考える第四次産業革命とABEJA Platformの構成

Deep Learningを知っている人はたくさんいますが、成功した事例はまだほんの一部にしかすぎません。そこにはコスト、ナレッジの問題もありますが、機械学習には唯一の解がないという特徴があります。ABEJAのプラットフォームは、正解への近道であるのは間違いありません。今後もABEJAの第四次産業革命に期待です。

HPCとAIをつなぐGPUクラウド

続いて、HPCシステムズ株式会社の渡邊啓正様よりGPU活用における今後の課題点のご講演です。 HPCシステムズはこれまでのHPC（ハイパフォーマンス・コンピューティング）のナレッジを活かし、AI×HPCの2軸でより賢くビジネスを加速させる取り組みを行っています。また、GPU活用においては、量・効率的な冷却・HPCによる高利便性が大事ということで、GPUとクラウドの親和性が強調されていました。

▲HPCシステムズ株式会社　渡邊 啓正様

Deep Learning用の計算リソースは、今後もきっとデータ量が膨大になっていくにつれて需要が増えていきます。もちろん、GPUの数は多ければ多いほど嬉しいお話ですが、キャパシティ制御に課題もあります。

課題① 分散学習環境の構築
大量のGPUを有効活用するには分散学習環境の構築が必要になってきます。大量のマシンとユーザーの一元管理や、ネットワーク周りの設計、そして並列計算の設定もそれぞれ実施する必要があります。これらを問題なくこなすにはインフラ面の知識が相当必要になってきますが、これらはHPCシステムズにとっては得意な技術であります。

課題② 資源利用の最適化
アクセスするユーザーが増えれば、GPUリソースを最適な形で割り当てる必要があります。ポイントとしてまずあるのは、GPU使用を排他制御できることです。続いて、ユースケースとしてDockerコンテナ経由でGPUを扱うことが増えているので、Dockerコンテナの自動配備、またコンテナからCUDAでGPUを問題なく使えることも重要です。最後に、ジョブスケジューリング機能も必要で、現状うまく制御できるツールが存在しないため新しいジョブスケジューラーが必要という結論になりました。

今後も加速していくAI業界はきっとたくさんのビジネスチャンスをもたらしてくれますが、運用における課題も増えていくでしょう。そんな課題を解決するには自力で頑張るという方法もありますが、HPCシステムズのノウハウに頼ってみるのも賢明な選択肢ではないのでしょうか。

激アツ！GPUのパワーとインフラの戦い

IDCFから菊石のセッションは、「GPUのインフラ運用は結構大変なのです」の一言から始まりました。AI（人工知能）・Deep Learningが進化していく中、その土台となるGPUインフラの課題と当社の解決方法を本音ベースで紹介しつつ、その試行錯誤の過程を共有させていただきました。

▲株式会社 IDCフロンティア　菊石 謙介様

IDCFはデータセンターとクラウドの事業を提供しております。GPUサーバーも、当然IDCFのデータセンターのラック内に収容しており、今回はラックの収容設計について紹介しました。

標準仕様のラックはCPUを搭載した一般的なサーバー向けのため、GPUサーバーをフル搭載すると空調性能が追いつかない課題がありました。また、GPUサーバーを冷却させるファンが強力なため、データセンターのエアフローに影響してしまうという課題もサービス開始前に発覚しました。これらの課題に対して、ラック内の収容設計を見直したり、エアフローを変えるなど試行錯誤を行い、現在の安定したGPUサービス提供に至ります。

IDCF は今後インフラ事業者として、GPUの進歩に追随するだけではなく、それらが問題なく稼働できるデータセンターの設計や考案も行っています。AIを試してみたい！GPUを体験してみたい！という方がいらっしゃれば、ぜひIDCF にご相談下さい。

まとめ

今回のセミナーでは、注目度の高い企業の方々にご登壇いただき感謝しております。また、雨の中にも関わらず、会場はほぼ満席でした。皆様ご来場、本当にありがとうございました。

今後もさらにAI（人工知能）・DeepLearningは進化し、GPUが処理できるTFLOPS数も桁が変わっていくことでしょう。よく「AIの波がそこまで来ている」と言われていますが、それは人を巻き込んではくれません。波に乗るか乗らないかは、自分たち次第です。 きっと何かが変わっていきます。 IDCFでは今後もみなさまと、よりよいパートナーシップを組めるようなきっかけを提供していきたいと思います。 是非またIDCFのセミナーに参加いただければ幸いです。

写真：Yahoo! JAPAN公式カメラ隊（倉長　拓海・Vikram Malhotra）

こんにちは、河合です。サービスを運用する上で止めないこと(可用性)はとても重要ですよね。考慮すべきテーマとしてBCP(事業継続計画)・DR(Disaster Recovery：災害復旧)対策があります。このとき活躍するのがGSLB(Global Server Load Balancing：広域負荷分散)サービスです！GSLBを使えば、災害などの有事によるメインサイトダウン時のバックアップサイトもしくはSorryサーバーへの自動切り替えや、大規模なアクセスがきた時の分散の仕組みを実現することができます。 今回はIDCFクラウドDNS/GSLBのGSLBサービスにフォーカスして、次の流れで設定方法や用途を紹介します。

• GSLB概要
• 設定方法
  • Step1. GSLBサービス申込み＆ログイン
  • Step2. 振り先サーバーの登録
  • Step3. ヘルスチェック詳細設定
• 切り替わりの確認
• まとめ

GSLB概要

GSLBとは、DNSの名前解決を用いたロードバランシング機能です。DNSラウンドロビンとの最大の違いは、ヘルスチェックや重み付けができるところです。

GSLBを使ったグローバルレベルでの分散は、大規模アクセス時の負荷分散や災害発生時のサイト切り替えを実現し事業継続性を高めます。例えばBCP対策としてのGSLB導入には、次のようなメリットが挙げられます。
　・複数拠点間での分散
　　物理的に離れた環境間でサイト分散することで可用性を向上し、自然災害やテロなどの緊急時にもサービスが継続できます。

　・重み付けによる自由な構成
　　各レコードに対して重み付けができるため、Active/ActiveやActive/Standbyなど自由度が高い構成を実現できます。 例えばActive/Standbyは、メインサイトと障害時のみ使うバックアップサイトとわけたり、Active/Active構成であれば両サイト同時にサービス提供するような完全冗長ができます。リソースやコストなどを踏まえてユーザーが最適に選択することができます。

　・自動切り替わりによるダウンタイムの軽減・回避
　　ヘルスチェックに失敗した時には、自動で切り替わりが発生するので、サービスのダウンタイムを軽減できます。また、上記で紹介したActive/Active構成を採用している場合、完全冗長されているため、万が一障害や災害が発生してもサービスへの影響を最小限に留めることができます。

このGSLB、以前テックブログで紹介させていただきましたがIDCFコーポレートサイトでも取り入れています。東日本のメインサイトダウン時には西日本のバックアップサイトへ切り替わるよう、ダウンタイムを最小限に抑えた構成にしています。

関連記事
コーポレートサイトのセキュリティ対策は万全ですか？

GSLBはDNSサービスと一緒にお使いいただくサービスとなります。最小構成ならワンコインから始められるので、無理なく導入を始めることができます。また、IDCFクラウドDNSのネームサーバーは国内3拠点に分散配置、すべてプライマリの冗長構成となっているため安心してお使いいただけます。詳しい仕様はサービスページからぜひチェックしてみてください！

設定方法

これから紹介する3ステップで簡単に分散環境やDR環境が作成できるので、さっそく設定していきましょう。例で構築するのはApache Webサーバーの簡単なDR環境です。東日本と西日本の2拠点でActive/Standby構成とします。GSLBではレコードごとに重み付けの設定ができ、Standbyにするには重み0となります。重み付けについてはこの後Step2で説明します。

▲図1. 作成する環境イメージ

Step1. GSLBサービス申込み＆ログイン

IDCFクラウドコンソールからオンラインでお申込みいただけます。グローバルメニューから「DNS/GSLB」を有効化してください(図2)。

▲図2. グローバルメニュー

Step2. 振り先サーバーの登録

対象ゾーンを選択し、「レコード登録」を選択します。

▲図3. 選択したゾーンの設定画面
※GSLB単体での利用は出来ないので、あらかじめDNSサービスでゾーン作成の必要があります。ゾーンの作成方法については次のドキュメントをご参考ください。

参考ドキュメント
IDCFクラウド DNS　スタートアップガイド

レコード作成画面でAレコードを選択するとGSLBの欄が見えるようになります。ここで「有効」を選択するとGSLBで設定するパラメータ(図4)が表示されるので、利用に応じて記入しましょう。今回、レコード名はwwwとしています。

▲図4. GSLB設定項目

各設定項目は次の通りです。

▲表1. GSLBパラメータ

※1 例えばA,B,C 3つの振り先に対して1:2:3の重み付けにすると、それぞれ1/6、2/6、3/6の割合になります。ですのでDNSの問い合わせが6回来た場合、Aを1回、Bを2回、Cを3回返答します。
※2 ゾーン認証が完了していないとヘルスチェックの有効化ができないのでご注意ください。

ヘルスチェック失敗時の動作
ヘルスチェックで異常と判断した場合、振り分け対象から切り離されます。その後1分に1度自動で復旧の確認が行われ、チェックが2回連続で成功すると復旧と判断します。
ヘルスチェックの設定が「あり自動有効化」であれば、復旧時に自動的に振り分け対象として切り戻され、「あり手動有効化」の場合は手動で切り戻しを実施していただく必要があります。

詳細設定が終了したら、右端の「＋」をクリックすると振り分け対象のサーバーとして登録されます。ここまでの操作を登録するサーバーごとに行ってください。
今回の環境ではWeb-1(東日本リージョン)を重み1の手動切り替え、Web-2(西日本リージョン)を重み0の自動切り替えで登録します。

Step3. ヘルスチェック詳細設定

ヘルスチェックを「あり」にしてレコードを登録すると、さらにヘルスチェックの詳細設定項目が出てきます(図5)。ヘルスチェックの種類をHTTP/HTTPS/TCPから選択し、使用するポートを指定します。
※ヘルスチェックなしにすると単純な重み付けありのDNSラウンドロビンとして利用できます

▲図5 ヘルスチェック設定

「チェック」項目ではヘルスチェックの間隔や失敗回数などを指定することが可能です。

▲表2. ヘルスチェック項目

HTTP/HTTPSの場合、ステータスコードが100,200,300番台を正常と判断します。TCPの場合はSYN/ACKの返答によって正常を確認します。
なお、ヘルスチェック対象IPアドレス側でヘルスチェックサーバーからの通信の許可を忘れずにしてください。次のグローバルIPアドレスがIDCFヘルスチェックサーバーのIPアドレスです。
　210.140.111.128/25
　202.239.51.128/25
　210.152.239.128/25

通知先にはメール/Slackの2種類が選択でき、ヘルスチェック失敗/復旧時の際に通知が実施されます。
すべての設定が終わったら「登録する」をクリックしてGSLBレコードの設定完了です！

切り替わりの確認

では、設定したGSLBが想定通りに動いているか確認してみましょう。 まずはブラウザから登録したドメインにアクセスします。

▲図6 Web-1 (Activeサイト)

Active(重み1)に設定したWeb-1サーバーのページが表示されていることを確認したところで、Web-1のhttpdをDownさせます。
その後ブラウザをリロードすると、Web-2サーバーのページが表示されました。うまく切り替わっています。

▲図7 Web-2 (Standbyサイト) への切り替わり確認

GSLBによる自動切り替えが確認できたところで、先ほどDownさせたWeb-1を再度立ち上げて手動切り替えを実践します。
IDCFクラウドコンソールのDNS/GSLBページを開くと手動切り替え待ちの状態になっているので(図8)、マウスオンして「有効化する」をクリックし、元のWeb-1がActive、Web-2がStandbyの状態に戻します。

▲図8 手動切り替え待ち状態

その後再度Webページをリロードし、Web-1が表示されていることを確認します。 これで今回構築したDR環境の動作確認ができました。今回は手動で切り戻しをしましたが、自動で切り戻すことも可能です。

まとめ

ここまで、GSLBの設定～動作確認までを紹介しました。GSLBレコード自体はわずか3ステップで登録できてしまうので、とても簡単に始められますね！

GSLBの特長は、インフラ関係なく複数拠点を対象として設定できることです。また、IDCFの環境のみにとどまらず、外部のサービスとも組み合わせてご利用いただけます。そのため、IDCFクラウド間に限らずハウジング×IDCFクラウド、他社クラウド×IDCFクラウドといった柔軟な構成が実現できます。もしGSLBを使うためIDCFクラウドDNSへ切り替えを検討される場合は、こちらで無停止切り替えの手順を公開していますので、ご参考ください。
近日中にGSLBの機能アップデートを予定しておりますので、その際は改めて紹介したいと思います。
それではお楽しみに！

Serverspecとは

こんにちは。山田です。 まさかとは思いますが、2017年にもなってサーバーのテストを片手にエクセルのテスト項目をもち、目視で確認している人はいないとは思います。 実はまだ、お手てで頑張ってテストをしている。そんな人に今回の記事を贈ります。 いつまでも旧態然としたエクセル主義を撲滅するためにもServerspecでテストを自動化し、周りの上司へ「一台ずつ確認してるんですか〜？」と言ってやってください。 今回はIDCFクラウド上にてServerspecを構築し、実際のテストを行うまでの手順をご紹介します。

Serverspecのすごいところは以下通りです。

• サーバーの設定/状態が正しいか一瞬でチェックできる。
• サーバーにエージェントなどをインストールする必要がない。
• プログラミング未経験でもなんとかなるようにできている。

使用目的

Serverspecは元々、インフラコードのリファクタリングを目的に開発されていますが、 様々な目的に使用することが可能です。

• サーバー・ネットワーク機器の設定/構築作業における確認手順の自動化
• 既存サーバーの状態確認
• Serverspecの真の目的であるインフラコードのリファクタリング

今回のお話では、サーバーの設定/構築作業における確認手順の自動化に絞ってお伝えします。 例えば手順書ベースで確認作業を行なう場合、見落としが発生したり、確認作業の長期化などの問題があります。 そこでServerspecを使うと下記のメリットがあります。

• 見落としがない
• 属人化の解消
• 作業時間の圧倒的短縮
• あるべき姿が定義されるので、設定/状態の厳密な確認が可能

では実際どのようにしてサーバーの状態をチェックするのか具体的にみてみましょう。 例えばWordPressをインストールしたサーバーをテストするためには次のようなコードを書きます。

require 'spec_helper'

describe package('nginx') do
  it { should be_installed }
end

describe service('nginx') do
  it { should be_enabled }
  it { should be_running }
end

describe port(80) do
  it { should be_listening }
end

コードとか書いたことのない人でも、何がしたいのかがわかりますね。
では、実際にServerspecをIDCFクラウド上に構築し、サーバーのテストを行ってみましょう。

IDCFクラウド上に作成する仮想マシンのスペック

今回はIDCFクラウド上でCentOS 7.3がインストールされている仮想マシンを作成します。 詳細は下の表に記載しています。
※IPはDHCPで動的に割り当てられたIPをそのまま利用しています。

それでは早速Serverspecサーバーを作成していきましょう。

Serverspecユーザー作成

今回はServerspecユーザーを作成し、ユーザーのホームディレクトリ以下に インストールをしていきます。
※今回は検証のため、Serverspecユーザーをwheel(管理者)グループへ追加していますが、皆様の環境に合わせて正しく権限付けしてください。

# useradd serverspec
# usermod -G wheel serverspec
# su - serverspec

ruby,rbenvのインストール

まずは、必要パッケージをインストールします。

$ sudo yum -y groupinstall "Development Tools"
$ sudo yum -y install git openssl-devel readline-devel zlib-devel

上記をインストールしたら、つづいてrubyをインストールします。

まずはgitからクローン

$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
$ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

パスの設定

$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
$ echo 'eval "$(rbenv init -)"' >> ~/.bashrc
$ source ~/.bash_profile

Ruby2.3.4をインストール

$ rbenv install 2.3.4
$ rbenv global 2.3.4

Serverspecのインストール

ユーザーディレクトリにてGemfileを作成します。

$ gem install bundler
$ bundle init

直下にGemfileが作成されるので、 内容を以下に変更

$ vi Gemfile

こんな感じにします。

$ cat Gemfile
source "https://rubygems.org"

gem 'serverspec'
gem 'rake'
gem 'highline'

それではbandleコマンドでServerspecをインストールします。

bundle install --path /home/serverspec/

するとServerspec直下にディレクトリが作成されます。

$ ls
Gemfile  Gemfile.lock  ruby

Serverspecの設定を行います。

$ bundle exec serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1　←今回はCentOSを使用しているので「1」を選択

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 1 ←今回はsshで行なうので「1」を選択

Vagrant instance y/n: n　　　　←今回はVagrantはつかわないので、「n」を選択
Input target host name: wordpress-server
 + spec/
 + spec/wordpress-server/
 + spec/wordpress-server/sample_spec.rb
 + spec/spec_helper.rb
 + Rakefile
 + .rspec

現在のディレクトリ状況

$ tree  --charset=o  -L  3
.
|-- Gemfile
|-- Gemfile.lock
|-- Rakefile
|-- ruby
|   `-- 2.3.0
|       |-- bin
|       |-- build_info
|       |-- cache
|       |-- doc
|       |-- extensions
|       |-- gems
|       `-- specifications
`-- spec
    |-- spec_helper.rb
    `-- wordpress-server
        `-- sample_spec.rb

11 directories, 5 files

この状態で、Serverspecを使えるようになりました。

複数ホストを指定できるように設定変更

デフォルトのままだと、1つのホストに対してしかServerspecを実行できません。 なので、二つのファイルを書き換え、複数ホストに対応させていきます。

Rakefile

require 'rake'
require 'rspec/core/rake_task'
require 'yaml'
require 'highline/import'

properties = YAML.load_file('properties.yml')

#ENV['SSH_USER'] = ask("Enter ssh user: ") { |q| q.echo = true }
#ENV['SSH_PASSWORD'] = ask("Enter ssh password: ") { |q| q.echo = false }

desc "Run serverspec to all hosts"
task :serverspec => 'serverspec:all'

namespace :serverspec do
  task :all => properties.keys.map {|key| 'serverspec:' + key }
  properties.keys.each do |key|
    desc "Run serverspec to #{key}"
    RSpec::Core::RakeTask.new(key.to_sym) do |t|
      ENV['TARGET_HOST'] = properties[key][:hostname]
      t.pattern = 'spec/{' + properties[key][:roles].join(',') + '}/*_spec.rb'
      t.fail_on_error = false
    end
  end
end

spec_helper.rb

require 'serverspec'
require 'pathname'
require 'net/ssh'
require 'yaml'

set :backend, :ssh
set :path, '/sbin:/usr/sbin:$PATH'
set :request_pty, true

RSpec.configure do |c|
  c.before :all do
    set :host, ENV['TARGET_HOST']
    options = Net::SSH::Config.for(c.host)
    ## for login key + passphrase configurations
    options[:keys] = ENV['KEY'];
    options[:user] = ENV['SSH_USER']
    #options[:password] = ENV['SSH_PASSWORD']
    set :ssh_options, options
  end
end

上記を書き換えたら実行環境は完成です。

では、実際のテスト内容を記載していきます。
まずはspecディレクトリに移動に移動します。
本環境では対象サーバー名を「wordpress-server」としたので、 その名前のディレクトリが作成され、中にsample_spec.rbファイルが格納されています。
この.rbファイルに確認したいテスト内容を記載します。 今回はsample_spec.rbを編集して、実行してみましょう。

$ cd /home/serverspec/spec/wordpress-server
$ vi sample_spec.rb

require 'spec_helper'

describe package('nginx') do
  it { should be_installed }
end

describe service('nginx') do
  it { should be_enabled }
  it { should be_running }
end

describe port(80) do
  it { should be_listening }
end

describe service('mariadb') do
  it { should be_enabled }
  it { should be_running }
end
describe port(3306) do
  it { should be_listening }
end

describe service('php-fpm') do
  it { should be_enabled }
  it { should be_running }
end

• Nginxはインストールされているか。
• Nginxは自動起動設定されているか。サービスが上がっているか。
• ポート80はLISTENしているか
• MariaDBは自動起動設定されているか。サービスが上がっているか。
• ポート3306はLISTENしているか
• php-fpmは自動起動設定されているか。サービスが上がっているか。
  を確認しています。 その他の設定や、サービスの起動状態なども確認できるので、公式サイトをチェックしてみてください。
  http://serverspec.org/resource_types.html

最後にServerspecをでテストしたい対象と、テストの内容を properties.ymlに記載します。
デフォルトでは存在しないので、新規で作成します。

vi /home/serverspec/properties.yml
wordpress-server:
  :roles:
    - wordpress-server
  :hostname: wordpress-server

今回は一台のみ記載しましたが、この上記と同様の記載を追記していくことで複数のホストを登録できます。 roles部分に記載したものの実態は spec/wordpress-server/sample_spec.rbです。 wordpress-serverディレクトリ以下の*.rbがこのroleで実行されます。 複数のroleを記載して実行することも可能です。

Serverspecを実行

※実行前にテスト対象へのssh接続ができるようにしてください。
　テスト対象への名前解決ができるようにしてください。

$ pwd
/home/serverspec
$ bundle exec rake serverspec --trace KEY=~/.ssh/id_rsa

[serverspec@serverspec ~]$ bundle exec rake serverspec --trace KEY=~/.ssh/id_rsa
** Invoke serverspec (first_time)
** Invoke serverspec:all (first_time)
** Invoke serverspec:wordpress-server-syamada (first_time)
** Execute serverspec:wordpress-server-syamada
/home/serverspec/.rbenv/versions/2.2.3/bin/ruby -I/home/serverspec/ruby/2.2.0/gems/rspec-core-3.6.0/lib:/home/serverspec/ruby/2.2.0/gems/rspec-support-3.6.0/lib /home/serverspec/ruby/2.2.0/gems/rspec-core-3.6.0/exe/rspec --pattern spec/\{wordpress-server-syamada\}/\*_spec.rb

Package "nginx"
/home/serverspec/ruby/2.2.0/gems/specinfra-2.68.0/lib/specinfra/backend/ssh.rb:76:in `create_ssh': Passing nil, or [nil] to Net::SSH.start is deprecated for keys: user
  should be installed

Service "nginx"
  should be enabled
  should be running

Service "mariadb"
  should be enabled
  should be running

Port "3306"
 should be listening

Service "php-fpm"
  should be enabled
  should be running

Port "80"
  should be listening

Finished in 0.41725 seconds (files took 0.24948 seconds to load)
9 examples, 0 failures

** Execute serverspec:all
** Execute serverspec

上記のように完了します。
成功した場合は緑の文字で出力され、失敗の場合は赤字で出力されます。

まとめ

IDCFクラウド上でさくっとServerspecサーバーを立ててサーバーのテストをする方法を紹介しました。 皆様も是非、Serverspecを使って、エクセル管理のテスト項目書の撲滅を目指しましょう。 次はよく使用するテスト項目などの紹介をしてみたいと思います。

はじめまして＆こんにちは。某外資系クラウド会社にて「ブルーなんとか（注　下に答が・・）」というサービスの洗脳活動エバンジェリストをしている木村と申します。前職を含めた IDCF 歴は３年、MORIO Dojoでは青帯を拝命しております。ご縁あって IDCF テックブログにデビューさせていただく機会を頂戴しました。よろしくお願いします。

お客様がクラウドを利用する場合、「特定の一社だけと契約する」というケースは珍しく、検証も含めて多くのケースでいわゆるマルチクラウド環境をご利用いただく機会が多いと実感しています。

今回はそんなマルチクラウド環境における相互ネットワーク間をセキュアに接続する例として、IBM Bluemix と IDCF クラウド環境間で Secure Gateway というサービスを利用した通信方法の実現について、その概要と具体的な手順を紹介します。

マルチクラウド間接続

複数のクラウド環境を併用する、いわゆる「マルチクラウド」環境は、各社の提供するサービスや機能のイイトコ取りをするようなケースでは珍しくないと思っています。その環境下では各社の提供するネットワーク条件やセキュリティ用件が全く同じということは考えにくく、それらを意識した上でマルチクラウド間の接続を実現する必要が出て来ることも考えられます。Secure Gatewayならこれらの課題をクリアするセキュアな接続が実現できます。その方法について本ブログで紹介します。

背景

マルチクラウド環境を利用していると、多くのケースでこのようなことを実現したくなることもあるでしょう：

▲図1 マルチクラウド間のセキュア接続

１つのクラウドはいわゆる「パブリッククラウド環境」として利用し、別のクラウドは「プライベートクラウド環境」として利用するようなケースです（後者は「オンプレミスの社内ネットワーク」を想定していただいても構いません）。この２つの環境ではネットワーク要件やセキュリティ要件は全く異なっているのですが、パブリックネットワーク側からプライベートネットワーク内のデータを利用したい（実際ありますよね）、という要件が出てきたようなケースです。

このようなケースでは「プライベートネットワーク内のデータを、どこまでセキュアな状態で／どれだけ他の環境に影響を与えずに／どれだけ簡単にパブリックネットワークのサーバーから接続させるか？」が鍵となります。今回は IBM Bluemix環境（パブリックネットワークと想定）と IDCF クラウド環境（プライベートネットワークと想定）を使い、この２つのネットワーク間を IBM Secure Gatewayでセキュアに接続する、という方法とその実現手順を紹介します：

▲図2 IBM Secure Gatewayによるセキュア接続イメージ

準備

• IDCF クラウドのアカウント、および IBM Bluemix のアカウント

• IDCF クラウド内の仮想サーバーインスタンス（グローバルIPアドレスは不要）

• IBM Bluemix 内の PHP ランタイム（PHP でなくてもよいが、今回は PHP でサンプルアプリを用意）

２つの環境内にそれぞれサーバーが用意されている、という状態になっている所までが準備されているものとします(図3)：

▲図3 両ネットワークに仮想マシン準備

Secure Gateway

今回は IBM Bluemix の Secure Gatewayサービスを使います。Secure Gateway は２つの異なるネットワーク間のデータおよびアプリケーションをセキュアに接続するトンネリングサービスです。特に IBM Bluemix で SaaS として用意されている Secure Gateway サービスには以下の特徴があります：

• IBM Bluemix 上のアプリケーションとプライベートネットワーク内との通信を簡単に実現

• トンネリング実現のための特別なハードウェアを用意する必要はなく、docker 環境または専用のソフトウェアをプライベートネットワーク内に用意するだけ

• プライベートネットワーク内の接続先（IPアドレス＋ポート番号）が１つであればSecure Gatewayサービスが無料で使える

環境設定手順

プライベートネットワーク（IDCF クラウド）側で docker 環境を用意

まずは IDCF クラウド内に 「プライベートネットワーク内のサーバー」に相当する仮想マシンを用意します。プライベートネットワーク想定なので、グローバル IP アドレスは 不要 です（light.S1 プランなら 500 円／月で作れます）。この例では個人的に使い慣れた CentOS 6 のサーバーを作りました：

▲図4 IDCFクラウドコンソール 仮想マシン詳細画面

IDCF クラウドの場合、Web画面からコンソールにアクセスしてコマンドを実行できる、という便利な機能が用意されています（これを使えば SSH などを使う必要もなく、グローバル IP アドレスがなくてもコマンドラインアクセスが可能になります）。今回の環境設定等はこのコンソールを使うことにします(図5)：

▲図5 仮想マシン コンソールアクセス

こんな感じの画面(図6)が現れるので、ログインします。なお、ここで使用するパスワードは仮想マシン作成時にログインしているユーザーのメールアドレスに送付されるものを使います。：

▲図6 Webコンソール画面

普通に root でログインしちゃいました。良い子はマネしちゃだめよ：

▲図7 Webコンソール ログイン時

ここでネットワーク環境についてあらためて確認しておきます。 Secure Gateway をインストールする際には docker 環境または専用のソフトウェアがインストールされたサーバーがプライベートネットワーク内に必要になります（今回は前者を想定）。 またプライベートネットワーク上の１つのデータベースサーバーに対する外部からのセキュアな接続を実現する方法を紹介するのですが、今回はこのプライベートネットワークを１台のマシンで実現します。つまり docker 環境とデータベースサーバーを同じ仮想マシン上に構築します。

外部ネットワークからの接続先データベースが複数あるようなケース（この場合は有償版 Secure Gateway で対応）だったり、そもそも docker 環境とデータベース環境を分けて構築するようなケースで応用することも可能です。ただしその場合は docker の仮想マシンからデータベースに接続できるようなセキュリティ設定があらかじめなされていることが前提となることをご注意ください。

というわけで、改めて docker 環境を用意します（ちなみに CentOS 6.x の場合、6.6 以上である必要があります。また docker 1.8 以上は公式には CentOS 6.x では非サポート環境となるので、docker 1.7 を使うことになります）。こんな感じのコマンドを実行して docker 環境をインストール＆起動します：

# yum -y --enablerepo=remi,epel,rpmforge install docker-io
# service docker start

▲図8 Webコンソール Docker起動

同様にしてプライベートネットワーク内にデータベースサーバーを構築します。今回は MySQL を使うことにします（ポート番号は3306）。今回は docker と同じ仮想マシン上に作成しますが、（docker の仮想マシンからアクセスできるサーバー上であれば）どこにあっても構いません。以下のコマンド等を実行して、MySQL サーバーが実際に動いている状態にします：

# yum -y install mysql-server
# service mysqld start

テーブルやデータ、ユーザーは適当に作っておきます。ただしこのユーザーは docker 環境からアクセスできる必要があります。MySQL と docker が異なる環境となる場合は外部接続を許可するよう設定しておいてください。

パブリックネットワーク（IBM Bluemix）側で Secure Gateway サービスをインスタンス化

次に IBM Bluemix 側で Secure Gateway サービスをインスタンス化します。まだアカウントをお持ちでない場合は 30 日間無料トライアルにお申込みください。

アカウントをお持ちの場合は IBM Bluemix にログイン後、カタログ一覧画面から Secure Gatewayサービスを検索して選択します：

▲図9 IBM Bluemixカタログ一覧

そしてプランを選択して「作成」します。"Essentials"プランであれば、接続先が１つに限られてしまい、通信量は月500MBまでとなりますが無料で提供されているサービスです（今回のケースはこれでもOKです）：

▲図10 Essentialsプラン

作成後にダッシュボード画面を見ると “Secure Gateway-XX” と書かれたサービスがインスタンス化されていることが分かります。これをクリックして管理画面に移動します(図11)：

▲図11 ダッシュボード画面

このような画面が表示されればパブリックネットワーク（IBM Bluemix）側の Secure Gateway は準備できたことになります。 ただ、この時点ではまだトンネリングの接続先がまだ存在していない、以下のような状態です(図12)：

▲図12 IBM Bluesmix側 Secure Gateway準備

このまま続けてプライベートネットワーク（IDCF クラウド）側にも Secure Gateway クライアントを用意する手順に進むため、画面内の＋マークをクリックします：

▲図13 Secure Gatewayダッシュボード

「ゲートウェイの追加」画面にて接続先を定義します。ここではとりあえず名称（図では「クララのゲートウェイ」）、セキュリティトークンの有無と期限を設定（図では使用せず）し、「ゲートウェイの追加」ボタンをクリックします：

▲図14 ゲートウェイ追加手続画面

「クララのゲートウェイ」という接続先が定義できました。この時点ではまだ実際の接続先が用意されていないので切断されています（図15：右上が赤くなっている）： 最後に接続先を設定するための方法を確認しましょう。画面内の「クライアントの接続」と書かれた部分をクリックします：

▲図15 クライアントの接続

Secure Gateway をプライベートネットワーク側に導入する場合の手順が表示されます。 実際には３種類の方法で導入することができます（図の左から専用クライアントアプリ／docker イメージ／専用ハードウェア）。今回は docker を使うので docker アイコンをクリックし、その手順を確認します。 この Secure Gateway と接続するために docker 環境上で実行するコマンドが表示されるので、この内容をメモしておきます(図16)：

▲図16 Secure Gateway接続方法

プライベートネットワーク（IDCF クラウド）側で Secure Gateway クライアントを導入

ここからはあらためてプライベートネットワーク側での作業になります。先程表示されたコマンドを docker 環境で実行します。

（注）実際にはホストモードで実行しないと接続できないケースがあるようなので、先程の画面に表示されたメッセージに --host=netというオプションを追加して実行します。

初回のみ Secure Gateway のイメージがダウンロードされ、docker コンテナ上で実行され、コマンド待ちの状態で Secure Gateway が起動します：

▲図17 Secure Gateway起動画面

この時点でプライベートネットワーク側にも Secure Gateway のインスタンスが用意できました：

▲図18 プライベートネットワーク側 Secure Gateway準備

なお、この時点で IBM Bluemix 内の Secure Gateway サービス画面を確認すると、右上の先程まで赤くなっていた部分が緑色に変わり、クライアントとの接続ができたことが分かります。ここまで確認できたら Bluemix 側の Secure Gateway 画面は閉じてしまっても構いません（図19：右上の×をクリック）：

▲図19 Secure Gatewayサービス画面

この時点でパブリックネットワークの Secure Gateway と、プライベートネットワークの Secure Gateway とが接続できている状態になりました。ただ実際のデータベースサーバーとはまだ繋がっていません。最後にそのための設定を行います。

まず、docker 上で稼働している Secure Gateway の Worker ID を確認します。Secure Gateway のコマンドで “L”を実行し Worker ID （図20では 1）を確認します：

▲図20 Worker ID確認

Worker ID がわかったら、アクセスを許可するリソースを IP アドレスとポート番号、そして Worker ID のセットで “A”コマンドで指定します。今回は MySQL サーバーへのアクセスを許可するので、以下のようなコマンドを実行します：

> A （MySQL サーバーのIPアドレス）:3306 1

（注） MySQL サーバーが docker 環境と異なるホストの場合は、MySQL サーバーの設定で docker ホストからのリモート接続を許可するような設定が別途必要です。

▲図21 MySQLへのアクセス許可

これでパブリックネットワーク（IBM Bluemix）とプライベートネットワーク（IDCF クラウド）とが Secure Gateway を介して接続され、パブリックネットワーク側からプライベートネットワーク内の MySQL サーバーへの接続が許可された状態になりました。

パブリックネットワーク（IBM Bluemix）側からプライベートネットワーク（IDCF クラウド）のデータベースにアクセスする

ここまでの手順でパブリックネットワーク側からプライベートネットワーク内の MySQL サーバーにアクセスを許可する設定が完了しました（この時点では許可までが完了しただけであって、まだ接続設定はできていない）。では最後にパブリックネットワーク側からプライベートネットワーク内の MySQL サーバーに接続する設定を行います。

再度 IBM Bluemix のダッシュボード画面から Secure Gateway サービスの管理画面を開き、宛先タブの＋印をクリックします：

▲図22 Secure Gatewayサービス画面

今回はパブリックネットワークのクラウドから、プライベートネットワーク（オンプレミス）ネットワーク内の MySQL へのアクセスを行いたいので、リソースはオンプレミス側にあることになります。というわけでリソースの場所に「オンプレミス」を指定します：

▲図23 リソース選択

オンプレミス側の MySQL リソースの IP アドレスとポート番号を指定します。ここで指定する IP アドレスは当然プライベートネットワーク内の IP アドレスになります：

▲図24 宛先ホスト、ポート設定

通信プロトコルを指定します。今回は MySQL のネイティブプロトコルで、特に認証も行わないので “TCP”を選択します：

▲図25 通信プロトコル選択

認証の種類を指定します（今回は “None"）：

▲図26 宛先での認証方法選択

更にリクエスト元の IP アドレスを絞る場合はこの画面で指定します（今回は空白のまま）：

▲図27 リクエスト元IPアドレス指定

最後にこの接続に名前（下図では「プライベート MySQL」）を付けて「宛先の追加」をクリックします：

▲図28 宛先追加

ここまでの手順で、プライベートネットワーク内の MySQL に接続するための設定が完了しました：

▲図2 IBM Secure Gatewayによるセキュア接続イメージ(再掲)

管理画面にも宛先が追加されています。 この宛先の右下にある歯車部分をクリックします(図29)：

▲図29 Secure Gateway管理画面

するとこのようなダイアログが表示されます(図30)。 クラウド・ホスト：ポートと書かれた部分に注目してください。これが パブリッククラウド(IBM Bluemix)側からみた MySQL サーバーの接続先となる情報です：

▲図30 MySQLサーバー接続先情報

接続アプリを作ってパブリックネットワーク上で動かす

あとは上記で作成した環境を使ったアプリケーションをパブリックネットワーク上の（IBM Bluemix 上の）サーバーで実行するだけです。試しにこんな PHP アプリを作って、サーバー上に配置してみました：

▲図31 構築したマルチクラウド間のセキュア接続

<?php

// プライベートMySQLへの接続
$hostname = 'XXXXX.integration.ibmcloud.com';
$port = NNNNN;
$dbname = 'mydb';
$username = 'username';
$password = 'password';


// ここは編集不要
$dsn = 'mysql:dbname='.$dbname.';host='.$hostname.';port='.$port;
?>


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html> 
<head> 
<title>MySQL 接続テスト</title> 

<meta http-equiv="viewport" content="width=device-width, initial-scale=1" />
<meta http-equiv="apple-mobile-web-app-capable" content="yes" />
</head> 
<body> 
  <h1>MySQL 接続テスト</h1>
  <br/>
  <table border="1">
  <tr><th>#</th><th>名前</th><th>年齢</th></tr>

<?php
try{
  $dbh = new PDO( $dsn, $username, $password );
  if( $dbh != null ){
    $sql = "select id, name, age from people order by id limit 10";
    $stmt = $dbh->query( $sql );
    while( $row = $stmt -> fetch( PDO::FETCH_ASSOC ) ){
      $id = $row['id'];
      $name = $row['name'];
      $age = $row['age'];
        
      $tr = "<tr><td>" . $id . "</td>"
          . "<td>" . $name . "</td>"
          . "<td>" . $age . "</td></tr>\n";
      echo $tr;
    }
    
    $dbh = null;
  }
}catch( PDOException $e ){
  print( 'Error: ' . $e->getMessage() );
  die();
}
?>
</table>
</body>
</html>

このアプリケーションにアクセスするとこのようになります(図32)。無事にパブリックネットワーク上のアプリケーションから、プライベートネットワーク内の MySQL データベースサーバーにアクセスして動いていることがわかります：

▲図32 MySQL接続確認

感想

パブリックネットワークとプライベートネットワークとの間をセキュアで簡単に接続できる Secure Gateway を紹介し、実際に接続環境を作るまでを説明しました。 今回の紹介の中では専用のハードウェアやトンネリングのための設定を用意する必要もなく、ファイアウォールを通す必要もなく、そしてプライベートネットワーク側にはグローバル IP アドレスも用意していないことを改めて思い出してください。 そうして作成したプライベートネットワーク内の MySQL サーバーにここで書かれている情報を使ってセキュアにアクセスできるようになっている、ということを意味しています。

今回は IBM Bluemix と IDCF クラウドという２つの異なるネットワークの間をセキュアに接続する、というケースで紹介しましたが、この Secure Gateway を使えば同様のトンネリングネットワークを簡単に作成することができます。 マルチクラウド時代における、クラウドネットワーク間の接続ツールとして紹介させていただきました。

この記事を作成するにあたり、IDCF クラウドを「プライベートクラウド環境」と位置付けて紹介させていただきました。他の多くのクラウドベンダー環境と異なり、専用のWebコンソールが用意されていることで、グローバルIPアドレスを付与したり、SSHなどを利用することなく外部からホストにアクセスして利用することができました。プライベートネットワークを実現したり、あるいはプライベートネットワークをエミュレートする環境として非常にユニークであり、簡単でかつ使いやすいと感じました。

今回紹介したメイン機能である Secure Gateway は IBM Bluemix からは SaaS として提供しており、これを各クラウドから外部利用いただくことも可能ですが、「自分のクラウド環境の中に Secure Gateway インスタンスを作りたい」という要望もあると思います。その場合はソフトウェア製品版である WebSphere CastIronをお使いください。