今回から「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クラウドのユーザビリティを少しずつ高めていきますので、今後ともご期待ください！

こんにちは＆はじめまして！オンライン開発部インサイドセールス担当の諌山です。 オンライン経由でIDCFクラウドをご利用いただいているお客様へのご提案・ご案内を担当しています♪ 何かお困りごとがありましたら、お気軽にインサイドセールスグループ宛にお問合せください！　　　

さて、先日2/1（月）と2/16（火）に日本経済新聞本誌で「時代は、ワンコインクラウド。」としてIDCFクラウドの全面広告を出稿したのですが、みなさんご覧いただけましたでしょうか？！　　　

こんなに "ワンコイン推し！"なのはいいのだけれど、実際に「ワンコイン＝500円」でどこまで使い倒せるのか？！ ユーザー様にブログで自慢していただきましたので、厳選した記事をいくつかご紹介させていただきます🎶ヽ(*´∀｀)ノ　　　　

「ワンコイン＝500円」クラウド使いこなしブログ　まとめ

「1周年」　-KEi’s Log

　http://31kish.meltaba.com/2015-11-10/

こちらのユーザー様は1台でWebサーバー＆メールサーバーを動かしてるようです。 Minecraft用のサーバーとしてご利用いただいているお客様も多く、ワンコインでも「パワフル」に使いこなしていただけているようです！　　　

IDCFクラウドのCentOS7でSwapを使う　-いなばメモ

　http://blog.1783.org/2015/05/idcfcloud-swap/

先ほどの記事でもCPUの性能についてご意見いただいていますが、ワンコインクラウドのCPU（1コア）よりも性能が欲しい方はSwap領域を作成し駆使しているようです。CentOS7での作成方法を紹介いただいています。

※IDCFクラウドの標準機能ではSwap領域の提供はありません。　　　

「IDCFクラウドで自分だけのHerokuを構築する」　-もくもくブログ

　http://blog.muuny-blue.info/c3daba8ba04565423e12eb8cb6237b46.html

この方はDokkuをIDCFクラウドで構築し、Herokuからいくつかのアプリを乗せ替えて利用されているようです。

　IDCFクラウド借りました

初めてご利用いただく方からよくご質問を受けるのが、仮想ルーターの設定で、FirewallとPort forwardingの概念。 このエントリーでは構成図をもとに、わかりやすく解説されていて、ありがたいです★またこちらでもSwap領域の作り方を伝授。（DokkuはDockerベースなのでSwap領域があったほうがよさそうとのこと。）

　IDCFクラウドの一番安いのでDokkuを使う

DNSの設定も含めた構築手順の詳細を公開しています。さらにPythonのサンプルアプリで一緒にインストールしてみましょう！　　　

法人での使いこなし術🎶

個人ユーザー様の使いこなし術をご紹介しましたが、法人様でももちろん！使いこなしていただいています。

まだAWSのみに頼って生きてるの？複数のクラウド利用で、大幅コストダウンした話　-Qiita: @appwatcher

qiita.com

この方は個人でご利用いただいていたあとに所属する法人様でもIDCFクラウドを採用いただいたようです。 他社のクラウドサービスを使ってサービスを立ち上げた後、ユーザー様が想定よりも増えてその分費用も増大に！（汗）嬉しい悲鳴ということでしょうか。。 そこで弊社サービスの特徴（ネットワーク費用の定額プラン）を活かした構成を組み直して1/10にコストを抑えたそうです。
移設は3人/日程度というスピードで達成し、サーバー側はAnsibleのレシピを少し修正したくらいとか…！DBはデータアクセスをAPI化されたようですが、Goで実装していたため型の安全性が生きたようです。
スピード移行のためには、やはり新規サービス立ちあげ時の設計がポイントのよう。「自分のサービス形態の特質に合わせて、ライブラリやサービスの境界を分離できるようにしておく」など、事前に検討しておくことをいくつかアドバイスされていますので、これから新規サービスで利用検討いただいている方はぜひご参考にしてみてください！

マルチクラウドユーザーとしてのご意見や、一番苦労された部分も詳しく伺ってみたいです！
　　　

まとめ

いかがでしたか？？ やはり個人ユーザーの方はゲームなどでのProxyサーバー、ご自身の開発環境にご利用いただいている場合が多いようですね。 まだまだ、IDCFクラウドを独自の方法で使いこなしているよ！という方もいらっしゃるかと思いますので、ぜひ教えてください！ また次の機会にこちらでまとめさせていただきます！　　　

　◆ 「ブログ書いたよ！」お問い合わせ先 ◆

　　株式会社IDCフロンティア 　　オンライン開発部　インサイドセールスグループ 　　inquiry@idcf.jp

ぜひぜひ、お待ちしておりますよーーー！！！ では、またお会いしましょう〜！ﾟ･:.｡..｡.:･゜(´∀｀)｡. .｡.:･゜ﾟ･*　　　

▼ ワンコインキャンペーン実施中！　<< 期間：2016年2月1日〜2016年3月16日まで >>

www.idcf.jp

関連記事

• IDCFクラウドについてのブログまとめ

※2016年10月1日より、サービス名称が「Yahoo!ビッグデータインサイト」から「トレジャーデータサービス by IDCF」に変更となっております。

はじめに

Yahoo!ビッグデータインサイト（以下YBI）を用いて、大量のデータを容易に分析することができますが、重要なデータをインターネット上でやりとりしたくない、そもそもインターネット接続なんてさせていない、みたいなケースがしばしばあるかと思っています。

データを扱う上でセキュリティは無視できないもの、切っても切り離せない永遠の課題です。 IDCFクラウド(オンプレでも可)ではプライベートコネクトを用いて、プライベートなネットワーク上でYBIに対してデータのimport/exportを行なうことが可能です。 （プライベートコネクトというのは、プライベートでセキュアなネットワーク、いわゆるVPNと考えてください）

プライベートコネクト側の設定

プライベートコネクト側の設定はいたって簡単です。3分くらいで終わります。 まず、プライベートコネクトのコンソール画面でYahoo!ビッグデータインサイトの接続を選択し、

任意のネットワークアドレス、プライベートIPを設定します。 つまりユーザー側で好きなプライベートIPの指定が可能です。 この例の設定では、YBIのAPIに対して192.168.20.1で、YBIのコンソールに対して192.168.20.2でアクセスできるようになります。

YBIではAPIエンドポイントに対してデータのimportを行います。以上でimport用の設定は完了です。

次にexport用の設定です。 exportはユーザーマシン（FTP、MySQL、APIサーバーなど）に解析データをexportする機能です。

“Result Export先Host"部分にexport先のマシンのプライベートIPアドレスを入力し、＋を押すとexport用のFQDNが自動でアサインされます。 この例では192.168.1.1のFTPサーバーと192.168.10.1のMySQLサーバーをexport先に登録する形になります。

以上でプライベートコネクト側の設定は完了です。

実際の利用方法

YBIのアカウント作成、マシン側のtd（CLIツール）、td-agentインストールまでは完了しているとします。 YBIの基本的な使い方はこちらを参考にしてください。

td コマンドを使用する際に、URL部分に先ほどのAPI用のプライベートIPを指定します。 （通常はybi.api.idcfcloud.netの部分） 例えば、下記はプライベートコネクト経由でnginx用のDBにtest というTableを作成しています。

td -e http://192.16.20.1 table:create nginx test

YBI側のコンソールを確認してみると、確かにnginxのDBにtestのTableが作成されています。 （このコンソール画面にも192.168.20.2のプライベートIPでアクセスできます。）

td-agent側の設定は、/etc/td-agent/td-agent.conf で設定します。

<source>
  type tail
  format /^(?<remote>[^ ]*) (?<host>[^ ]*) (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)" "(?<forwarder>[^\"]*)")?/
  time_format %d/%b/%Y:%H:%M:%S %z
  path /var/log/nginx/access.log
  pos_file /var/log/td-agent/nginx-access.pos
  tag td.nginx.test
 </source>
<match td.*.*>
  @type tdlog
  apikey 123456789012345678901234567890
  auto_create_table
  buffer_type file
  buffer_path /var/log/td-agent/buffer/td
  endpoint http://192.168.20.1   ###ここをAPIエンドポイントIPにする###
  flush_interval 10s
  <secondary>
    @type file
    path /var/log/td-agent/failed_records
  </secondary>
</match>

上記の例だと、nginxのアクセスログが、td-agentを用いて、192.168.20.1がアサインされているYBIのnginx.testにimportされていきます。当然インターネットは経由しません。

実際はこんな感じでアクセスログのデータが溜まっていきます。

YBIではデータを解析した結果を抽出するというResult Exportという機能があります。 プライベートコネクト経由でユーザーマシンにexportする際には、YBIのResult Exportの設定画面で、Hostの部分に 専用のFQDNを入れる必要があります。（※プライベートIPだと期待した動作にはならないので注意してください。）

これで適切なSQL文を書いて、実行（Run）すると、192.168.10.1 のMySQLマシンに結果がexportされます。

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

以前Aerospikeの記事を書いた金杉と同じ部署で働いています。
私からも、皆様に本ブログにてIDCFクラウドの魅力をお伝えしていきます！
今回は、IDCFクラウド連携サービスの一つであるGitHub Enterpriseを、IDCFクラウド上で動かしていきます。

www.idcf.jp

GitHub Enterpriseについて

GitHubは今や開発者にとってなくてはならないサービスとなっていますね。
ソースコードを管理するだけでなく、Issuesによる課題管理やPullRequestを使ったコードレビューなど、ソフトウェア開発の効率を上げるための機能が多く用意されています。

そんな非常に便利なツールであるGitHubですが、WebサービスのGitHub.comと企業向けのオンプレミスなGitHub Enterpriseが用意されています。

企業向けのGitHub Enterpriseは、WebサービスのGitHub.comに比べ以下のような利点があります。

• 社内でソースコードを管理できる
• 土台となるサーバーを自社で管理できる
• GitHub.comのメンテナンスやサーバーダウンなどに左右されない

そのため、以下のケースでは、GitHub Enterpriseが適しています。

• セキュリティポリシーの観点から、社外にソースコードを置けない
• 定期的にリリースするソフトウェアなどがあり、メンテナンス時間をコントロールしたい

通常GitHub Enterpriseのインストールには、VMware、Xen、KVMなどのハイパーバイザーを用意する必要がありますが、
IDCFクラウドでは仮想マシンを立ててインストールするだけで使うことができます！ お手軽ですね。

IDCFクラウドへインストール

それでは実際のインストール手順を紹介していきます。

1.GitHub Enterprise(評価版)のダウンロード

今回は、45日間無料で使えるGitHub Enterpriseの評価版をインストールしていきます。 以下のサイトから評価版のダウンロード申し込みを行ってください。

http://www.macnica.net/github/download.html/

申し込み完了後、GitHub Enterprise評価版の案内に従い、以下の2つのファイルをダウンロードしてください。

• GitHub Enterprise Virtual Appliance(OVA)
• GitHub Enterprise ライセンスファイル

2.テンプレートの作成

先ほどダウンロードしたOVAファイルを使用して、IDCFクラウド上にテンプレートを作成していきます。
それではまず、IDCFクラウドにログインします。左のメニューの「テンプレート」に入り、右上の「テンプレート作成」ボタンを押してください。

その後、以下の項目に沿ってテンプレートを作成していきます。

3.GitHub Enterpriseの仮想マシン作成

次に、作成したテンプレートを使って仮想マシンを作成していきます。 該当のテンプレートを選択し、「仮想マシン作成画面へ」をクリックしてください。

以下が作成する仮想マシンのスペックです。今回はお試しなので、最小構成のhighmem.M16（2CPU メモリ16GB）で構築します。
（GitHub Enterpriseのハードウェア要件など、詳しくはこちら）

作成が完了したら、仮想マシンへ接続するため「IPアドレス」の設定をする必要があります。 以下の2つのポートに、ポートフォワードとファイアウォールの設定をしてください。

4.GitHub Enterpriseのインストール

いよいよGitHub Enterpriseのインストールをしていきます！
ブラウザで以下のURLにアクセスすると、「Install GitHub Enterprise」という画面が表示されます。
https://[サーバーのIPアドレス]:8443/setup/start

「License me」をクリックして、手順１でダウンロードしたライセンスファイルをアップロードします。
そしてパスワードの設定をしたら、「Finish Installation」をクリックします。

「Choose installation type」では、「New Install」を選択します。

その後、「Setting」画面に遷移します。 パスワードの設定など完了したら、「Save settings」をクリックしてください。

すると、GitHub Enterpriseのインストールが始まります！

完了したら、「Visit your instance」をクリックしてください。
利用開始まであと一歩です！
最後に、管理者アカウントを設定し「Create an account」をクリックします。

そして、ついに…！

新しいリポジトリの作成画面が表示されました！
これでGitHub Enterpriseのインストール＆初期設定が完了です！
ちなみにここまで約30分、意外と簡単にインストールできましたね！

まとめ

• GitHub Enterpriseは企業向けのオンプレミスなGitHub
• IDCFクラウドでは仮想マシンを立ててインストールするだけで使える
• 最小構成なら構築時間約30分

どうでしたか？普段GitHub.comをお使いの皆様も、試しに使ってみてはいかがでしょうか。 今回はGitHub Enterpriseのインストールのみで少しボリュームが少なめでしたが、今後はGitHub Enterpriseのバックアップやディスク追加の手法、監視設定などもお伝えしていきたいと思いますので、ご期待ください！

こんにちは。Vuls Slackチームに参加している井上です。
IDCFクラウド アンバサダー プログラムでMORIO Dojo ( https://www.idcf.jp/cloud/dojo/ ) にも参加しています(まだ白帯ですね)。

今回、GitHub trending総合で一時的に1位になったこともある、話題の脆弱性スキャナ「Vuls」について、ご紹介の機会をいただきました。

• Vulsのテスト環境を、MORIO Dojoの縁もあり、IDCFに提供いただきました。ありがとうございます！

• そのご縁もあり、こちらに寄稿させていただくことになりました。

実機での操作やコードは今回はありませんが、しばらくお付き合いいただければ幸いです。

そもそもVulsって何？

脆弱性スキャナに分類されるプログラムです。表記上は、”Vuls”(大文字始まり)が本プロジェクトの名前で、”vuls”(すべて小文字)はプログラムを示しています。細かいことなので、あまり気にしなくても良いと思います。
同様なものとして、OpenVASがあげられます。
https://github.com/future-architect/vuls/
VulsでスキャンしたデータをWEBで見ることが出来る、VulsRepoというものもあります。
https://github.com/usiusi360/vulsrepo/

Vulsの優れた点は以下の通りです。

• エージェントレス
  SSH(鍵認証)を利用して通信します。
• アップデートの必要性だけではなく、影響度が分かる
  アプリケーションなどの兼ね合いでアップデートが難しいサーバーの場合、現在のバージョンではどのような脆弱性が残っているのか、影響度はどのくらいであるのかなどの情報をもとに、アップデートを検討します。この判断の補助が出来ます。

概要

Vulsは、サーバーに導入されているパッケージやプログラムをチェックし、NVD/JVNの脆弱性情報と突き合せることで脅威度を「目に見える形」で示すことが出来る、OSSのソフトウェアです。

• 導入済みのパッケージに対し、aptitude chagelogやyum update –changelog、yum plugin security、pkg auditなどを用いて、現状残存する脆弱性のCVE IDを取得します

• また、CPE(Common Platform Enumeration)を利用することで、パッケージ以外のソフトウェアの脆弱性も確認可能です CPE:https://www.ipa.go.jp/security/vuln/CPE.html

• 取得したCVE IDをもとに、NVD/JVNの情報と突き合せ、各CVE IDの概要や影響度情報を得ます。その結果を JSONファイルとして保存します。 JVNについては、JPCERT/CC 戸田様の資料が詳しいです: http://www.slideshare.net/jpcert_securecoding/ss-66412794

• 保存されたJSONファイルを、WEBブラウザで見ることが出来ます。 スキャンタイミング毎の結果の比較や、ピボットテーブルのように表示しての分析などが可能です。VulsRepoを利用します

図：Vulsの動作概要 (https://github.com/future-architect/vuls/blob/master/README.ja.mdhttps://github.com/future-architect/vuls/blob/master/README.ja.md )

図: VulsRepo: WEBアクセスで、現在の脆弱性残存状況が分かる(画面はヒートマップ表示)

インストール

詳細はGitHubサイトのREADME.ja.mdをご覧ください。

①Vulsを導入します

・Go言語で書かれているため、Goを入れます

・Vulsを使うユーザを作り、sshなどの設定を行います

・VulsをGitHubから落として、インストールします

②Vulsのスキャン結果を見る
・VulsRepoを入れます

・httpdなどのwebサービスを用意します

・VulsRepoをダウンロードし、DocumentRoot配下など、コンテンツディレクトリに配置します

③おわり
Vulsはスキャン用ユーザ配下に配置できるため、もしも不要になった場合やお試しで使った後は、ユーザのhomeディレクトリを削除することで、きれいさっぱり消去することが出来ます。

導入や削除は難しく無いため、気軽に試すことが出来ると思います。

初めてのmeetup、Vuls祭り Vol.1

9/26に、Vulsjpとしては初めてのミートアップ「Vuls祭り Vol.1」が開催されました。

vuls-jp.connpass.com

当初は50名規模想定でしたが早々に参加枠が埋まったため、最終的には100名まで規模を拡大して実施しました。想定よりも多くの方に興味を持っていただいていたようでした。

今回は、Vuls祭り Vol.1 のダイジェストをお伝えさせていただきます。 (各発表で利用されたスライドは、Vuls祭りのページから閲覧可能です。)

どのような雰囲気だったか

個人的には「Vulsを使っている方が来る」と思っていたのですが、大半の方が「まだVulsは利用していないが、興味がある」という感じでした。

各セッションを見ると、他のサービスと連携させるとどうなるのか、どうやったら使いやすくできるのか、そもそもセキュリティ面でどうなのか、という内容でした。これから使い始める人にとって、Vuls単体ではなく、周辺の既存サービスと連携をさせる点で、有用な内容だったように思えます。

セッションサマリ

各セッションについて、すごく簡単にまとめました。興味のある方は、Vuls祭りのサイトから資料をご確認ください。

基調講演:Vuls概要、これまでとこれからの話

• 2016/04/01にVulsを公開したところ、ドイツやスロバキアなどでも話題になった。
• 今後は以下をサポートしていきたい
  ・他のツールとも統合したい
  　OWASP dependency-check(https://www.owasp.org/)
  　WordPress (https://wpscan.org/)
  　Lynis (https://cisofy.com/lynis/)
  ・JPCERT/CCのAlert
  ・ローカルスキャン モード
  ・バイナリパッケージ化
  ・IDCFクラウドでの、テスト環境活用

脆弱性情報はこうしてやってくる

• Vulsが参照しているJVN(Japan Vulnerability Notes)について、情報が登録されるまでの過程のお話し
  ・正確には、JVN iPedia(http://jvndb.jvn.jp)を参照している
• JVN iPediaは…
  ・JVNに掲載される情報のほか、米国NISTが運営するNVD及び国内ベンダーからの情報を収集している
  ・データの蓄積と検索機能を重視。(JVNは迅速に公開することを重視)
  ・脆弱性が公表されてから一週間程度を目安に公開している
• JPCERT/CCでは、脆弱性の届け出を受けた後、ベンダーと調整の後に情報を公開している
  ・脆弱性発見、届け出、調整、公開＝Vulsで活用
• これらの情報をVulsでは活用している

Vulsで危険な脆弱性を最速検知！

• VulsのレポートをWEBブラウザで確認するための VulsRepo の作者
• Vulsで検査すると、パッケージのchengelogで検知できるため、NVDやCVEで情報が公開される前に検知することが可能
• Vulsで素早く系値・対応するための運用方法
  ・毎日スキャンし、新しく検知した内容だけをウォッチする
  ・VulsRepoで、検知結果をピボットテーブルのように集計して分析

  PCI/DSS and Vuls -VulsとPCI/DSS-

• PCI/DSSとは
  ・クレジットカード情報をインターネット経由で取り扱う人がしたがう必要のある、クレジット業界におけるグローバルセキュリティ基準
  ・守らないと、クレジットカード情報の取り扱いが出来なくなるかも
• Vulsは、PCI/DSSに準拠「し続ける」ために利用可能であり、有用
  ・ただし、Vulsを動かすためには注意すべきセキュリティ的な点がある

  PCI/DSS対応を考慮したVuls設定方法

• PCI/DSS環境でVulsを使う際に、セキュリティ上で「しなければいけないこと」「してはいけないこと」がある
  ・vulsスキャンユーザの秘密鍵は、対象サーバから削除する
  ・vulsスキャンユーザに与える特権は、制限する
  ・vulsでスキャンしたデータは、権限のある人にしか見えてはいけない
  　　→need to know basisの原則
• IDCFが、Vulsの開発環境のスポンサーになっていただいたことの報告

  EC2のVulsスキャンをほんの少し便利にするツールを作った

• ec2-vuls-confgというツールを作った
  ・Amazon EC2インスタンスタグを見て、設定ファイルを自動で書き換える
• なぜ作ったのか
  ・オートスケールなどで、インスタンスが常に変わり続けている環境でもスキャンしたい
  ・常にスキャン対象を設定ファイルに書いていく運用は、大変
  ・Amazon Inspectorのように、タグだけを見て自動的にスキャン対象を見つける仕組みが欲しかった

  本番サーバでの実運用 on GCP

• パッケージ化されていないもの(RPMではないもの)をスキャンする
  ・Vulsのconfig.tomlに cpeNames を記載することで対応が可能
• phpやnginxやredisなどを、自動的に脆弱性検知することが出来る
• initScriptによる運用の簡易化が便利

  Vuls x Microsoft Azure

• Azureで簡単にVulsを試せるように、一発構築コピペを作った
  ・Vuls本体と、VulsRepoがインストールできる
  ・スキャンしやすいような単位で構築される

  VulsとAzureでやってみた

• Azure Functionsでやってみた
• Log Analyticsでやってみた

  MackerelとVuls

• mackerel-agentが定期的にVuls scanをして、結果をMackerelに送るようにした

  ZabbixアプライアンスをVulsしてみた話

• 資料ありませんでした

  Vuls x DeepSecurity

• DeepSecurity保護下でも残存する、緊急度の高い脆弱性が発見できないかを試した
  ・VulsとDeepSecurityを組み合わせることで、対象の環境における緊急度の高い脆弱性がわかる
  ・Vulsと他のセキュリティ製品の組み合わせも、同じように連携できると考えられる
  ・DeepSecurity APIは、すごく便利

  How to contribute Vuls

• Vulsは、Pull Request大歓迎！
• 一緒にコーディングして、OSS contributorになろう！
• Vulsのドキュメント作成プロジェクトがそろそろはじまります！

まとめ

今後、IDCFクラウド用のコミュニティテンプレートをリリース予定です。

Vulsでスキャンすることで、実環境上の脆弱性状況の把握が簡単になるはずです。楽が出来るところは楽をして、休みを取ったり、他に注力しなければいけないところに力を割けるようになればいいな、と思っています。

株式会社アールワークス　ネットワークインテグレーション部　井上圭

こんにちは、金杉です。

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に対応する予定なので、その時は別エントリーで改めて紹介します。

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は自動起動設定されているか。サービスが上がっているか。
• ポート3360は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をお使いください。

こんにちは、IDCFの藤城（@tafujish）です。久しぶりにブログを書きますが、今回はIDCFクラウドからだいぶ遠い話をします。

みなさんは、ロボカップ（RoboCup）という大会を聞いたことがあるでしょうか。「2050年までに、人間のサッカーのワールドチャンピオンチームに自律人型ロボットで勝つ」というランドマークプロジェクトを掲げ、毎年世界で開催されている、ロボットと人工知能(AI)の学術大会です。この世界大会が今年は7月27日から名古屋で開催されます。

https://www.robocup2017.org/www.robocup2017.org

人工知能を搭載した自律型ロボットを用いてサッカーで競い合うわけですが、ヒューマノイドリーグで毎年優秀な成績を収めており、今月の世界大会にも出場するのが、千葉工業大学のチーム「CIT Brains」です。ディープラーニングというキーワードから、CIT Brainsの皆さんと繋がり、今回の大会ではIDCFクラウドとしてもCIT Brainsを応援しています。
CIT Brainsでは、ボール認識にディープラーニングを使用しロボットに実装しています。このあたりの話を教えてもらい大変面白かったので、今回ご紹介いたします。

sites.google.com

おおまかなデータフローとしては下図の通りです。

それでは、ポイントごとに見ていきましょう。

こんにちは。Vuls Slackチーム辺りをうろうろしている、井上と申します。 MORIO Dojoは白帯のままです(そろそろ青帯になりたい)。 某SNSでは、脆弱性情報やセキュリティインシデントを追いかけています。

近年、セキュリティ業界でも「シフトレフト」が叫ばれています。 「テストなどの工程を、プロジェクトライフサイクルのより速い段階で実施する」というアプローチです。 セキュリティに関しても同様で、リリース前にテストをすることで、リリース後のセキュリティ対応負荷を軽減することができます。

今回は、WEBアプリケーションの依存ライブラリの脆弱性を検査する OWASP Dependency Checkを利用して、WEBアプリケーションリリースのシフトレフト、を目指します。

OWASP Dependency Checkとは

OWASPとは、2015年の資料によると以下のように説明されています。

OWASPは、「The Open Web Application Security Project」の略称であり Webアプリケーションのセキュリティ向上や、セキュアなWebサービスの展開を目的として 2001年12月01日に設立されたグローバルなオープンなコミュニティです。 現在、世界198ヶ国ローカルチャプター(現地支部)があり、43,000人以上の メーリングリスト参加者が様々なプロジェクトに参加しています。

そのOWASPから、プロジェクトの依存関係から既知の脆弱性がないかをチェックするユーティリティとして Dependency Checkが公開されています。Javaと.NETがサポートされており、部分的に Ruby, Node.js, Python, C/C+(autoconf, cmake)サポートをしています。

ざっくりいうと、「対象のWEBアプリケーションで古いコンポーネント依存の脆弱性がないかを確認する」為のものです。

概要

リリース前のWebアプリケーションをスキャンする、というシチュエーションを想定してみます。

• Javaアプリケーションとして、Apache Struts2を用意します
  • Java以外のRuby、Node.js、Pythonなども限定的ながらチェックができる可能性があるので、 一度試してみることをお勧めします
• VulsサーバーとOWASP Dependency Checkをするサーバーは、別サーバーとします。同一サーバーでも問題ありません

説明の為、以下のような構成とします。

• Vulsサーバーを、Vulsコミュニティテンプレートから作成する
• 開発用WEBサーバーとして、CentOS6のテンプレートから作成する
  • 開発用WEBサーバーで構成したアプリケーションを、OWASP Depencency Checkで検査する
  • 検査後のアプリケーションを、本番WEBサーバー等(今回は構成せず)に展開する

試してみる

WEBアプリケーションを用意する

今回は、Apache Struts2(現時点の最新版の 一つ前 である 2.3.2)を用意します。 アプリケーションの動作の脆弱性検査(ペネトレーションテスト等)はしないので、Struts2単体を検査します。

$ mkdir tmp
$ cd tmp
$ wget http://archive.apache.org/dist/struts/2.3.32/struts-2.3.32-all.zip
$ unzip struts-2.3.32-all.zip
$ ls
struts-2.3.32  struts-2.3.32-all.zip
$

OWASP Dependency Checkの環境を用意する

OWASP Dependency Checkは Javaが必須であるため、導入します。 実行ファイルは展開したディレクトリの bin/dependency-check.sh です。 個人的には、/opt/OWASP/Depencency-Check/ 辺りにインストールするべきと思っています。

$ sudo yum install java
$ wget http://dl.bintray.com/jeremy-long/owasp/dependency-check-2.0.1-release.zip
$ unzip dependency-check-2.0.1-release.zip
$ ls dependency-check/bin/
dependency-check.bat  dependency-check.sh
$ ./dependency-check/bin/dependency-check.sh -v
Dependency-Check Core version 2.0.1
$

OWASP Dependency Checkで検査する

先ほど導入した OWASP Depencency Checkで、Apache Struts2.3.32を検査します。

初回の検査ではNVDのCVEをダウンロードするため、多少時間がかかかります。

$ ./dependency-check/bin/dependency-check.sh --format HTML --project projectName --scan ./tmp/struts-2.3.32 --out ./result.html
[INFO] Checking for updates
[INFO] Skipping NVD check since last check was within 4 hours.
[INFO] Check for updates complete (54 ms)
[INFO] Analysis Started
[INFO] Finished Archive Analyzer (15 seconds)
[INFO] Finished File Name Analyzer (0 seconds)
[INFO] Finished Jar Analyzer (9 seconds)
[INFO] Finished Central Analyzer (124 seconds)
[INFO] Finished Dependency Merging Analyzer (0 seconds)
[INFO] Finished Version Filter Analyzer (0 seconds)
[INFO] Finished Hint Analyzer (0 seconds)
[INFO] Created CPE Index (7 seconds)
[INFO] Finished CPE Analyzer (14 seconds)
[INFO] Finished False Positive Analyzer (0 seconds)
[INFO] Finished Cpe Suppression Analyzer (0 seconds)
[INFO] Finished NVD CVE Analyzer (3 seconds)
[INFO] Finished Vulnerability Suppression Analyzer (0 seconds)
[INFO] Finished Dependency Bundling Analyzer (0 seconds)
[INFO] Analysis Complete (171 seconds)
$

出力形式をHTMLとしているため、HTMLが出力されています。人間は読みやすいですが、Vulsやその他のプログラムと連携するには少し難しい形式です。

検査結果をVulsと連携させる

まずはVuls等と連携しやすいように、XMLフォーマットで出力します。

$ ./dependency-check/bin/dependency-check.sh --format XML --project projectName --scan ./tmp/struts-2.3.32 --out ./result.xml
$

ここで出力されたXMLファイルを、Vulsサーバーからアクセスできるようにします。

今回は、Vulsのコミュニティテンプレートに従い、/opt/vulsの下に配置します。NFS等でのアクセスでも問題ないです。
その後、Vulsのコンフィグを編集し、scan, reportを実行します。

[vuls@vulsserver ~]$ cd /opt/vuls/
[vuls@vulsserver vuls]$ vi config.toml
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
...
[servers.vuls-server]
host  = "localhost"
port  = "local"
dependencyCheckXMLPath = "/opt/vuls/result.xml"  <--ここを追加
...
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
[vuls@vulsserver vuls]$ vuls scan
[vuls@vulsserver vuls]$ vuls report -to-localfile -format-json
[vuls@vulsserver vuls]$

結果を読む

VulsRepoで結果を確認します。

• Packagesに cpe:/ で始まるものとして、登録されています
  • cpe:/a:apache:tomat:6.0.18　など
    

利用している(依存している)Tomcatなどの脆弱性がこれでわかるので、リリース前にアップデート等を行って、リリース時に脆弱性が残らないようにしましょう。

• 脆弱性対応を、運用ではなく、開発側に「シフトレフト」しましょう。その方が、対策コストは少なくて済みます

Vulsの今後

Vulsですが、今後、OVALに対応予定です。現時点では08月末付近を予定しています。これにより、検知精度の向上等が見込まれます。

リリース後、既存コミュニティテンプレートを更新する方法を公開する予定です。

おわりに

脆弱性対応は運用で行うもの、という環境が多いかと思います。しかしながら、Webアプリケーションのリリース後の修正は運用では難しいです。そのため、開発段階でセキュリティを考慮したテストを行うことで、リリース時点で既知の脆弱性を作りこまないことが重要です。

また、今回は既知の脆弱性を検知しましたが、WEBアクセスを伴った脆弱性診断もこの段階で行うのが良いと思われます。OWASPでは OWASP Zed Attack Proxy (OWASP ZAP)も公開しています。利用には脆弱性に対する知識が必要ですが、機械的に自動スキャンする製品よりは自由度が高いです。

OWASP ZAPについては、例えば脆弱性診断研究会で実施している 「脆弱性診断ええんやで(^^)」という勉強会等で、利用方法を学ぶことができます。

OWASPには、Webアプリケーション開発時に有用な情報がありますので、一度確認されることをお勧めします。

こんにちは。田崎です。

みなさん、素敵なコンテンツキャッシュライフを送ってますか？サイトのパフォーマンス向上とサーバーの負荷軽減をしてくれるコンテンツキャッシュは凄く便利でありがたいですよね。5月にも、テックブログでコンテンツキャッシュの2つの新機能：キャッシュ取り込みおよびエラー応答のキャッシュ停止について紹介させていただきました。

しかし、同じオリジンサーバーにはキャッシュさせたなくない、させるべきではないコンテンツもあるかと思います。もしキャッシュさせたくないものをキャッシュしてしまうと、情報漏えい事故になりかねます。IPAでもコンテンツの暴露対策の記事（プロキシキャッシュ対策）が挙げられていましたね。そうならないためにも、キャッシュさせないやり方も知っておくべきだと思い、今回のブログを書いています。

それでは、本日はコンテンツをキャッシュさせない3つの設定方法と確認の方法について紹介します。

確認環境

• オリジンサーバーはIDCFクラウド上に構築
• HTTP/1.1
• Apache/2.4
• Cache-Controlの設定はApache側ではなく、コンテンツ側(PHP)に設定
• IDCFクラウドのコンテンツキャッシュ（CDN）
• ブラウザはGoogle Chrome

キャッシュ確認方法

まず、キャッシュさせない設定の前に、キャッシュされたかの確認方法をCLIとGUIの2パターン使って紹介します。キャッシュさせたいコンテンツに以下ヘッダーを設定しています。

header('Cache-Control: public, max-age=60');

この例では、Cache-Controlヘッダーとmax-ageが設定されています。

• Cache-Control: public
  このコンテンツはキャッシュしてOKという設定です。

• max-age=60
  キャッシュの有効期限は60秒という設定です。すなわち、60秒間コンテンツがキャッシュされた後は強制的にオリジンサーバーを参照しにいきます。

CLI（Linux/Unix コマンドのcurl）で確認を行う例

$ curl -v http://cachetest01.xxxxxxxxxxxxx/hello2.php > /dev/null

> GET /hello2.php HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: cachetest01.xxxxxxxxxxxxx
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 20 Jul 2017 00:29:02 GMT
< Server: ATS
< X-Powered-By: PHP/5.4.16
< Cache-Control: public, max-age=60　★1
< Content-Length: 87
< Content-Type: text/html; charset=UTF-8
< Age: 1
< Connection: keep-alive
< Via: http/1.1 xxxxxxxxxxxxxxxxxxxxxxxxxx (ATS [cHs f ])　★2

★1：設定したCache-Controlヘッダーが表示
★2：キャッシュされているという意味

GUI（Google Chromeブラウザ）で確認を行う例

まずキャッシュ確認の前に、Chromeのメニューより【デベロッパーツール】を開き、【Network】を選択します。

次に、ブラウザから【http://キャッシュサーバーのドメイン名/ファイルのパス】へアクセスして確認します。

▲ブラウザからキャッシュ確認した結果

Response HeadersのVia ヘッダーの末尾が、[cHs f ]となっているので、キャッシュサーバー上にコンテンツがキャッシュされていることを示しています。

補足：Via ヘッダーの見方

Viaヘッダーの見方とその意味について補足します。

キャッシュさせないための設定

では、本題のキャッシュをさせないようにする設定ですが、「private」、「no-cache」と「no-store」等3種類あります。それぞれの意味は次の通りです。

1. private
レスポンスがひとりのユーザーのため(private)のものであり、共有キャッシュに保存してはいけない。 つまり、プライベートなんだからそもそもキャッシュするのは論外！！

2. no-cache
オリジンサーバーでの確認無しにキャッシュを利用してはいけない。つまり、勝手に再利用するな！毎回聞きに来い！キャッシュ、ノー！！

3. no-store
リクエスト、レスポンスを一切保存してはいけない。つまり、キャッシュに記録するんじゃないぞ！ノー、ストック！！

今回はCache-Controlヘッダーの「public, max-age=60」を「private」に変更して、キャッシュ状態を確認してみます。

header('Cache-Control: private');

CLI（Linux/Unix コマンドのcurl）で確認した結果

$ curl -v http://cachetest01.xxxxxxxxxxxxx/hello2.php > /dev/null

> GET /hello2.php HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: cachetest01.xxxxxxxxxxxxx
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 20 Jul 2017 02:12:23 GMT
< Server: ATS
< X-Powered-By: PHP/5.4.16
< Cache-Control: private　★1
< Content-Length: 87
< Content-Type: text/html; charset=UTF-8
< Age: 0
< Connection: keep-alive
< Via: http/1.1 xxxxxxxxxxxxxxxxxxxxxxxxxx (ATS [cMsSf ])　★2

★1：変更したprivateが表示
★2：キャッシュされてない

GUI（Google Chromeブラウザ）で確認した結果

Response HeadersのVia ヘッダーの末尾が、[cMsSf ]となっているので、キャッシュサーバー上にコンテンツがキャッシュされていないことを示しています。

▲ブラウザからキャッシュ確認した結果

Cache-Controlヘッダーに複数指定した場合

今までキャッシュさせる方法とキャッシュさせない方法を紹介しました。では1つのCache-Controlヘッダーに、キャッシュさせる「public, max-age=60」とキャッシュさせない「private」の両方の値を指定した以下のケースではどうなるでしょうか。

header('Cache-Control: private,public,max-age=60');

CLI/GUIで確認した結果

< Cache-Control: private,public,max-age=60　
(略)
< Via: http/1.1 xxxxxxxxxxxxxxxxxxxxxxxxxx (ATS [cMsSf ])　

▲ブラウザからキャッシュ確認した結果

CLI/GUI共に表示上ではCache-Controlに設定した全ての値が見えますが、「private」が優先されてキャッシュは無効化されます。「private」の他にIPA推奨ヘッダーである「no-cache」、「no-store」でも確認したところ、同じ結果でキャッシュは無効化されます。また、IPAでこれらキャッシュさせない値(private、no-cache、no-store、must-revalidate)をすべて指定した場合でも構わないと記載しているとおり、結果は同じでキャッシュはされません。

まとめ

今回は、コンテンツをキャッシュさせない3つの設定方法（private, no-cacheとno-store)とその確認方法について紹介しました。

キャッシュの有効化と無効化の両方のやり方を知ることで、オリジンサーバーの管理品質が向上され、大切なコンテンツを守ることができます。キャッシュさせたが故に情報漏えい事故が起きてしまった後では遅いので、この機会に一度キャッシュの設定を見直してみてはいかがでしょうか。

• キャッシュを無効化させたい場合、Cache-Controlの設定に「private」を設定してください。
• ヘッダーを変更したら必ずキャッシュ削除を行って、キャッシュの有無確認をしてください。

次回は、コンテンツキャッシュの機能アップデートについて紹介します。ありがとうございました！

こんにちは！そして、はじめまして！IDCFクラウドの開発エンジニアの生江です。2017年6月に入社したばかりの新人おじさんエンジニアです。 前職では企業向け Web サービスの開発を担当していました。守備範囲はデータベース設計からフロントエンド開発までと幅広いですが、最近は美しいCSSを書くことに魂を燃やしてます。好きな食べ物は餃子とビールです。

そんな私ですが、IDCフロンティアに入社してすぐにイベントに登壇する機会がありました。今回は7月28日に開催された Developers Summit 2017 Summerの講演についてご紹介します。

Developers Summit 2017 Summer とは

▲登壇の様子

Developers Summit (通称デブサミ) は、翔泳社が開催する IT エンジニア向けのカンファレンスで、さまざまな時期に各所でイベントが開催されています。2017 年 7 月 28 日に「エンジニアコミュニティが推進する新しい企業文化と開発の現場」というテーマで Developers Summit 2017 Summer が開催され、登壇する機会をいただきました。

伝えたかったこと

今回の登壇では、コミュニケーションしやすい環境を構築することでチーム活動が活性化することと、活性化事例として改善活動を紹介しました。

コミュニケーションしやすい環境について

会議で意見を述べるときなど、考えを表現することにリスクを感じない状態を「心理的安全」といいます。心理的安全を高めるには、企業文化や風土を改善することのほかに、互いの個性を知り、尊重することが重要になります。

互いの個性を知る機会として、以前は「飲みニケーション」が役割の一部を担っていましたが、価値観の変化などから、現在は飲み会自体が減少傾向にあります。また時間的負担や金銭的負担の観点でもチームメンバー全員が参加できる活動とはいえず、「互いの個性を知る機会」として有効な手段とはいえません。そのため、業務時間内に行うことができるグループワークに注目が集まっています。

私の部署では、数名のチームを作り、パスタとマシュマロを使っていちばん高いタワーを作る「パスタタワー」というチーム対抗ゲームを行いました。部署内で干支ごとにチーム分けをしたため、普段あまり関わらない方たちとコミュニケーションをとりながら、作戦を練っていました。レクリエーションの題材は業務と関係ありませんが、こういった活動が社員同士の個性を知るきっかけになります。

改善活動について

登壇時にご紹介した改善活動の一つである、技術的負債の返済について記載します。 イベントでは私が入社後に最初に取り組んだ「ソースコード内のインデントが統一してない問題」について紹介しました。 現状、高い品質を確保できています（安心してご利用ください！）が、多くの技術的負債が生産性に悪影響を及ぼしています。 さまざまな種類の負債を抱えていますが、例えば、使わなくなったコードは削除することや、適切なタイミングでリファクタリングを行うなど、 簡単にできる負債の返済を始めることでも、生産性を高められると確信しています。

また、周囲の利益を考え、自分のもっているノウハウ・ナレッジも積極的に共有し、生産性を高める活動も行なっています。

▲Qiita:Teamでの共有例

長期間に渡って開発を継続するためには、技術的負債を溜め込まないことが重要です。 新機能と違って成果の見えにくい活動ですが、よりよいサービスを提供するにあたって、引き続き、さまざまな課題に取り組んでいきたいと決意表明いたしました。

おわりに

登壇資料は、slideshareに掲載しています！

人生初の登壇経験で、いろいろなことを学びました。来場される方を考えつつ伝えたいテーマを絞り込んで熟成させていくことの難しさや、視覚的に判りやすい資料を作るためのノウハウ。意外に苦戦したのが時間枠を意識して話をすすめることです。無事にイベントが終了してほっとしてますが、時間が経つとさまざまな反省点も浮かんできます。このような大きなイベントで登壇する機会はなかなかないですが、今後もテックブログで積極的に情報発信していきたいと思います。引き続きよろしくお願いします！

こんにちは、酒巻です。
今回は今年最も注目されるDNS関連イベント、"ルートゾーンKSKロールオーバー"について書いていきます。

今年に入ってから各所で話題に上がることも多く、日頃あまりDNSに馴染みのない方でも何度か耳にしたことがあるのではないでしょうか。

既に準備を終えた方も多くいらっしゃるとは思いますが、いま一度皆さんと一緒に、対応のポイントについて直前のおさらいをしていきます。

なおこの記事では、それぞれのサーバーの役割を下記のように定義します。

• キャッシュDNSサーバー：DNSクライアントからの様々なドメイン名の名前解決要求を受け取って再帰的な名前解決を行うDNSサーバー

• 権威DNSサーバー：ある特定のゾーンに関するレコードデータを管理し、そのゾーンに関する問合せに対してのみゾーンの権威として応答を返すDNSサーバー

DNSSECのおさらい

「そもそも『KSK』ってナニそれおいしいの？」という方向けに、まずはざっとDNSSECについて説明します。 DNSSECについて十分理解されているかたは読み飛ばして下さい。

DNSSECに対応した権威DNSサーバーでは、管理対象のゾーンについて、

　① 「従来のリソースレコード(AやMXといったレコード)」
　② 「①をゾーンの管理者しか知らない秘密鍵で署名したレコード」
　③ 「②で使用した秘密鍵と対になる公開鍵のレコード」

が公開されます。

一方、DNSSEC検証を有効にしたキャッシュDNSサーバーでは、上記の①～③の情報を権威DNSサーバーから取得し、③で②のレコードを解読した結果と①を突き合わせ、一致すれば取得した①のレコードは正しい、と判定します。

ただ、これだけでは検証としては不完全であることは、すぐに分かりますよね。

何故なら、DNSSECはそもそも①に対する毒入れ対策のために生まれたものですが、①への毒入れが可能である以上、当然②や③についても毒入れの危険性があり、上記の検証プロセスの拠り所である③の正しさがそもそも保証されていないからです。

③の正しさを検証するには、親ゾーンの権威DNSサーバーの助けを借ります。

子ゾーンの管理者は、子ゾーンの権威DNSサーバーで①～③を公開することと併せて、親ゾーンの権威DNSサーバーに、

　④ 「③(と等価な情報)を親ゾーンの秘密鍵で署名したレコード」

を登録してもらいます。
勿論、親ゾーンの権威DNSサーバーでは④と共に

　⑤ 「④の署名に使った秘密鍵と対になる親ゾーンの公開鍵のレコード」

も公開されています。

親ゾーンの権威DNSサーバーから取得した④、及び⑤の情報が信用できるなら、⑤を使って④を解読した結果が③と一致すれば、③の正しさが保証されたことになります。

このように、DNSSEC検証の正当性は、「子ゾーンの公開鍵を、信頼出来る親ゾーンが保証する」という信頼の連鎖によって担保されています。

では、最上位のゾーンであるルートゾーンの公開鍵は誰が保証してくれるのか？というと、それは「キャッシュDNSサーバー自身」ということになります。

キャッシュDNSサーバーにはあらかじめ「信頼できるルートゾーンの公開鍵情報」を持たせておき、ルートゾーンの権威DNSサーバーから取得したルートゾーンの公開鍵と自身が持っている公開鍵情報が一致すれば、入手したルートゾーンの公開鍵は正しい、と判定されます。
この、「キャッシュDNSサーバーに予め持たせる公開鍵情報」は、「トラストアンカー(Trust Ancher)」と呼ばれます。

以上がDNSSECの基本的な仕組みですが、実際のDNSSECの運用では、鍵管理の運用コストに配慮して、各々のゾーンで2種類の鍵ペアが使われています。一つはゾーンのレコードを署名するための"Zone Signing Key"(ZSK)、もう一つはZSKを署名するための"Key Sigining Key"(KSK)です。

さらに、同じ鍵を長く使い続けているとそれだけ鍵の危殆化リスクも高まるため、適切な間隔で新しい鍵ペアに交換して新しい鍵でレコードを署名し直す必要があります。この鍵の更新作業が「鍵のロールオ―バー(Key Rollover)」と呼ばれており、一般にはZSKは1～3ヵ月、KSKは1～2年で更新することが推奨されています。

ルートゾーンKSKロールオーバーの特殊事情

さて、改めて言うまでもなく、"ルートゾーンKSKロールオーバー"というのはルートゾーンのKSKの更新のことなのですが、前述のKSKの一般的な更新間隔を見れば分かる通り、単なるKSKの更新ならば、これまでにも様々なゾーンで何度も行われており、さほど珍しいことではありません。

にもかかわらず、何故今回に限ってこれだけ騒がれているのでしょう。

その理由は、次の3点だと思います。

(1) ルートゾーンのKSKが全ての信頼の連鎖の起点であること
(2) KSK更新に合わせて、キャッシュDNSサーバー側でもトラストアンカーを追加する必要があること
(3) ルートゾーンでは今回が初めてのKSK更新であること

こういった事情により、今回各所で多くの注意喚起が行われているのだと思います。

KSK更新に伴う影響と要注意日

ICANNが発表している情報によれば、今回のKSK更新作業は2017年の7月～2018年の3月にかけて幾つかのステップを経て行われる予定です。
その期間中で特に注意が必要なのが、2017年9月19日と2017年10月11日です。

ルートゾーンの公開鍵情報のレコード(DNSKEYレコード)の応答サイズは、その時々のKSK/ZSKの公開鍵の公開状況によって変化しますが、KSK更新作業期間中には、DNSKEYレコードとその署名レコード(RRSIGレコード)の応答サイズの合計が1,400オクテットを超える期間が何度か発生します。

IPv6の最小Path MTUは1,280オクテット、またIPv4のPath MTUも大体1,200～1,400オクテット程度の場合が多いため、応答サイズが1,400オクテットを超えた場合、IPフラグメントが発生してDNSKEYレコードの問合せに対する応答を受信できなくなる可能性があります。

2017年9月19日は、KSK更新作業期間中ではじめてDNSKEYとそのRRSIGレコードの応答サイズが1,400オクテットを超える日です。

また、2017年10月11日には実際に新しいKSKによる署名に切り換わります。 従って、それまでにキャッシュDNSサーバーに新KSKのトラストアンカーが追加されている必要があります。

必要な準備

まず、キャッシュDNSサーバーがDNSSEC検証を行っている・いないにかかわらず、前述の1,400オクテット超の応答の受信確認を行っておきましょう。

具体的には、次のように実行します。

dig @キャッシュDNSサーバーのIPアドレス +bufsize=4096 +short rs.dns-oarc.net txt

• 実行例

$ dig @127.0.0.1 +bufsize=4096 +short rs.dns-oarc.net txt
rst.x4090.rs.dns-oarc.net.
rst.x4058.x4090.rs.dns-oarc.net.
rst.x4064.x4058.x4090.rs.dns-oarc.net.
"116.91.131.134 DNS reply size limit is at least 4090"
"116.91.131.134 sent EDNS buffer size 4096"
"Tested at 2017-08-07 02:00:33 UTC"

上記実行例のように、"at least"の後ろの数値が"1424"以上であることを確認します。

若しくは、Verisign Labs の DNSSEC Key Size Testのサイトを利用することも出来ます。 サイトにWebブラウザでアクセスして、上から4項目まで"PASS"、5項目だけ"FAIL"と表示されることを確認します。(当然、確認したいキャッシュDNSサーバーを使ってWebブラウザが名前解決を行う必要があります)

• 実行例

さらに、DNSSEC検証を行っている場合は、新KSKのトラストアンカーが追加されていることを確認します。

具体的な確認方法は、ご利用中のDNSソフトウェア製品によって異なるため、ご自分で調べていただく必要があります。 ここでは参考までに、CentOS 7.xのBIND RPMパッケージを利用している環境での例を挙げておきます。

• 参考例の環境

[root@bind9 ~]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
[root@bind9 ~]# named -v
BIND 9.9.4-RedHat-9.9.4-50.el7_3.1 (Extended Support Version)

※ named.confはRPMパッケージ既定のファイルを変更せずに使用
※ chrootは行っていません

参考例の環境では、ルートゾーンのトラストアンカーは、BIND自身によって"RFC5011"の仕様に従って自動更新されます。
トラストアンカーは"/var/named/dynamic/managed-keys.bind"というファイルで管理されていますので、中身を確認します。

[root@bind9 ~]# cat /var/named/dynamic/managed-keys.bind
$ORIGIN .
$TTL 0  ; 0 seconds
@                       IN SOA  . . (
                                2          ; serial
                                0          ; refresh (0 seconds)
                                0          ; retry (0 seconds)
                                0          ; expire (0 seconds)
                                0          ; minimum (0 seconds)
                                )
                        KEYDATA 20170808025709 20170807025709 19700101000000 257 3 8 (
                                AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
                                bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
                                /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
                                JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
                                oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
                                LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
                                Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
                                LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
                                ) ; KSK; alg = RSASHA256; key id = 19036
                        KEYDATA 20170808025709 20170807025709 19700101000000 257 3 8 (
                                AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
                                iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
                                7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
                                LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
                                efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
                                pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
                                A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
                                9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
                                ) ; KSK; alg = RSASHA256; key id = 20326

1つ目のKEYDATA(key id = 19036)が現行のKSKのトラストアンカーで、2つ目のKEYDATA(key id = 20326)に新しいKSKのトラストアンカーが追加されています。

まとめ

ルートゾーンのKSKの更新による影響と準備について簡潔にまとめます。

影響

• ルートサーバーのDNSKEYレコード応答サイズが増加し、IPフラグメントが発生してキャッシュDNSサーバーが応答を受信できなくなる可能性がある
• DNSSEC検証を行っている場合、新KSKによる署名開始後は、現行のトラストアンカーを使ったDNSKEYの検証が出来なくなる

準備すること

• キャッシュDNSサーバーが、少なくとも1,424オクテット以上のDNS応答を受信できるようにする
• DNSSEC検証を行っている場合は、さらにキャッシュDNSサーバーに新KSKのトラストアンカーを信頼済みの状態で追加する

IDCFの対応状況

最後に、IDCFでの対応状況について記載します。

KSKロールオーバーによりIPフラグメントが発生し名前解決ができなくなる問題について、 EDNS0は1220byteで制限していますが、IDCF提供のDNSサービス(IDCFクラウドDNS・リゾルバ)は 想定される1400byteを超えるパケットに対してTCPフォールバックで受信処理されるため影響はありません。

また、IDCFクラウドのテンプレートにて作成された仮想マシンでは、TCPフォールバックで受信処理される 仮想ルーター（KSKロールオーバー対策済）及びIDCFクラウド標準リゾルバが 問い合わせ先のリゾルバとして指定されている観点からもKSKロールオーバーの影響はありません。

IDCFクラウドの仮想マシンでiptables/firewalldを用いた制御を行っている場合、TCP port 53の通信を塞がないようにご注意ください。

“ルートゾーンKSKロールオーバー"による影響範囲はかなり広いので、早めに確認し、準備をしておきましょう。

参考:

• 株式会社日本レジストリサービス:
  「ルートゾーンKSKロールオーバーによる影響とその確認方法について」
  https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.html

• 株式会社日本レジストリサービス：
  「ルートゾーンKSKロールオーバーの概要と影響の確認方法」
  https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.pdf

• ICANN：
  「ルートゾーンKSKのロールオーバー」
  https://www.icann.org/resources/pages/ksk-rollover-2017-05-31-ja

こんにちは、IDCF営業の木村です。 2017年8月3日、Yahoo! JAPANの社員食堂にて、 トーセ様、ORATTA様、ドリコム様、XFLAGスタジオ様の豪華面々に、 有名タイトルの裏側を支えるチーム作りや技術を大公開していただきました！

ビール片手に、キャッシュを活用したDBの効率運用やNagiosによる監視体制といったサーバー運用からチーム体制まで、ここだけの話が盛りだくさんだったので、 今回は当日の様子を本ブログでご紹介したいと思います！

「夏だ！飲もうぜ！Game Day ～ビッグタイトルの裏側～＠ヤフー社員食堂」

まずはアジェンダ(敬称略)

・株式会社トーセ：「サーバ運用の魔法について」

・株式会社ORATTA：「戦国アスカZEROに学ぶ！エンジニアの力を最大化するチーム作り」

・株式会社ドリコム：「ダビマスの裏側を支える技術と体制」

・XFLAG スタジオ：「モンストとサーバ運用体制」

・XFLAG スタジオ：「小規模アプリ開発者が中から見るモンスターストライク」

1つ1つ紹介していきます～

株式会社トーセ：「サーバ運用の魔法について」

東証一部上場の老舗ゲーム開発会社、トーセ様からは、これまでの大中小様々なサーバー運用実績からそのノウハウを語っていただきました。

登壇者：株式会社トーセ　南方氏

結論！サーバー運用に魔法なんてない！？
ゲームのサーバー担当をされているみなさんなら、きっと困っているであろうサーバーの「コスト」「トラブル回避」「負荷軽減」。 これらを「安く！」「トラブルなく！」「負荷もなく！」、そんな魔法は実は存在しませんでした…。
でも、安心してください！魔法はないですが、ちゃーんと種と仕掛けのある手品で解決できるんです！

サーバー運用のポイント

1．コスト対策
お金を掛けようと思えばいくらでも掛けられるサーバーコストですが、 事前に何秒の遅延を許容できるか？バースト時のスケールアウトまたはスケールアップにどの程度の対応時間を予測しておくか？ これらを事前に明確にしておくことで、リッチ過ぎない、最適なインフラ環境を実現できるそうです。

また、今やネイティブゲームなら当たり前になっているCDN(コンテンツキャッシュ)を活用して、 安定かつ安価に大量配信を実現することもポイントですね。

ちなみに！IDCFではYahoo! JAPANを支えるコンテンツ配信技術を使った安定かつ安価なCDN(コンテンツキャッシュ)をご用意しています！

2．トラブル回避
どんなに対策、予測していてもトラブルは必ずと言っていいほど起こるもの…。
バックアップを取るだけでなく、そこからちゃんと切替えられるかの事前試験が重要です。 また、メンテナンス明けやコンテンツ更新明けなど売上増加が見込まれるときは、トラブルの機会損失の方が影響が大きいのでしっかりとサーバー増強と事前のウォームアップが大切になります。

3．負荷軽減
負荷は軽減できないので、分散させましょう！フロントサーバーの分散、DBのキャッシュ、Worldの開放時間の分散など、普段何気なくやっていることが重要になってくるんですね。

株式会社ORATTA：「戦国アスカZEROに学ぶ！エンジニアの力を最大化するチーム作り」

創業から8期目、毎年2倍成長の目標を掲げる急成長企業のORATTA様からは大ヒットタイトル『戦国アスカZERO』におけるエンジニアの力を最大化するチーム作りについてお話しいただきました。

登壇者：株式会社ORATTA　市川氏

結論！エンジニアが活性化する環境作りで、エンジニアの力を最大化！
メンバーも少なくないし、能力も高いのに、なんだか活気のない雰囲気ってありますよね。 機能追加やUX改善、バグ修正など、日々のやらねばならぬ業務はやりつつ、働くエンジニアが活性化していくチームビルディングは、文化作りにありました！

チームビルディングのポイント

1．エンジニアがプロジェクトを愛せる文化
愛があれば自分事で考え行動できるように、 エンジニアにも自身のプロジェクトに愛を持ってもらう仕掛けづくりが大切とのことです。

具体的には、

・作品に触れられるチャンネルを社内に用意
・作品へ本音でぶつかるチャンネル用意

いち開発者よりも前に、いちユーザーとして作品に触れる機会をつくることで、ユーザー目線での改善案や別チーム間でのコミュニケーションが活性化したそうです。

2．エンジニアが他のチームに感謝される文化
他チームやメンバーのために力を発揮できるエンジニア集団にするために、 他のメンバーから感謝される仕組みづくりを整えたそうです。

具体的には、

・各チーム合同での運用改善MTG
　⇒別チームが抱える問題をKeep(継続)、Problem(問題)、Try(挑戦)の軸に分け、みんなでブレストして洗い出し

・風呂部(フロンティア部)
　⇒業務時間を使って、業務改善・技術開拓のために自分のしたいことをする時間を確保

これによって、エンジニア発信でプロジェクト全体の課題解決や改善案が生まれるようになったそうです。

3．気軽にナレッジ情報を発信できる文化
営業もそうですが、どうしても個人プレーになりがちな日々の業務。 お互いのスキルアップと相互助長の目的で、 情報を発信しやすい環境づくりが肝要ですよね。

具体的には、

・情報収集/学習時間を「毎朝」確保
・収集/学習した内容を情報共有サービス(esa.io)で「毎日」情報発信

これによって、一人一人のアンテナが高くなり、 自発的な勉強会が開催されたり、発信の場が拡大していったそうです。

ついつい日々の業務に忙殺されがちですが、 こういったインプットとアウトプットの時間を作ることって本当に大切だと感じます。

登壇資料 -「戦国アスカZEROに学ぶ！エンジニアの力を最大化するチーム作り」

株式会社ドリコム：「ヒットタイトル『ダビマス』を支える技術と体制」

ドリコム様からは「人々の期待を超える」ために、大ヒットタイトル『ダービースタリオンマスターズ』における技術と体制についてお話しいただきました。

登壇者：株式会社ドリコム　白石氏

戦略～IP Strategy～
IRにも記載がありますが、ドリコム様はIP¹戦略を掲げており、『ダビマス』もその一環。 コンテンツがリッチ化＆多様化している昨今ですと、なかなかオリジナル作品でヒット作を生むのは至難の業です。 一方、マーケティングやプランニングの観点では、一定のユーザーがすでについているIPはとても有用ですよね。 ただし、IP作品にはステークホルダーがとにかく多くて、その分制約も多いのが実情です…。

そんな中、ドリコム様にはステークホルダーとの信頼と実績を築くための技術と体制がありました。
『ダビマス』を支える技術
アプリ：Cocos2d-x、C++
ミドルウェア：Ruby on Rails、Ruby、NoSQL
インフラ：IDCFクラウド、AWS

利用されている技術はゲーム開発では一般的なものが多いですね。

実際、ドリコム様でもこれまでで実績のある言語やミドルウェアをあえて選択しており、実績のある技術とメンバーで開発期間の短縮を図ったそうです。

一方で、技術的な未来投資もちゃんと考えられており、今回は"マルチクラウド化"をキーワードにIDCFクラウドを採用いただきました！

昨今、いろいろな企業様でマルチクラウドというキーワードが出ていますが、 1社にロックされるのではなく、マルチな環境を利用できることでエンジニアのスキルと会社としてのリスクヘッジが取れるメリットがありますよね。

マーケティングスケジュールが非常にシビアなIP作品で、ドリコム様は開発期間の短縮と自社の技術未来投資、両方を実現する方法で技術採用と体制をしっかり考えられているのが勉強になりました。

『ダビマス』を支える体制
冒頭に記載した通り、IPには多くのステークホルダーが存在しており、IP固有の問題も多々あるそうです。 ドリコム様もやはりIPタイトルでは多くの苦労をされているんですね。

特に次の3点

　1. クオリティとリリース時期の問題
　2. そのIPが持つ固有の問題
　3. マーケティングスケジュールのコントロール問題

IPの世界観を損なわず、プロモーションや季節感に合わせたリリーススケジュール調整が大変とのこと。

優秀なエンジニアだけでなく、渉外できるメンバーアサインやプロジェクト全体を管理進行できる体制づくりがIPタイトルの成功の秘訣なんですね。 ドリコム様では開発だけでなく運営もされているので、マーケティング含めて体制構築をされているのがよく伝わりました。

IDCFでもインフラレイヤーだけでなく、こうしたゲーム開発～リリースまでの苦労を少しでも軽減できるようなお手伝いをしていきたいものです。

まとめ！『ダビマス』からの学び
・ステークホルダーとの信頼関係大事！

IPは今の時代のゲーム成功においてとても有用で将来性もあります。 ただし、逆に言えばIPがもつ世界観もあるし、ましてTVアニメや連載中漫画などでは絶対に失敗は許されない厳しい世界…。 その大切なコンテンツをゲーム化するにはしっかりと信頼関係を構築することが最も大切な要素の一つなのですね。

・渉外大事！

これはゲーム開発だけでなく、日々の私たちの業務においても関係者が増えれば増えるほど連絡や交渉は難しくなるものですよね。だからこそ、社内だけでなくちゃんと外部との連携を密に行うことが特に重要なんですね。

・計画大事！

単に開発スケジュールを引くだけでなく、タイトルの持つ季節感や独自のスケジュールに合わせ、いつ、だれが、何をするか、しっかりと計画を立てて進める。 できているようで意外と抜け漏れがあったりするもので、PDCAサイクルを日々回していくことが基本的に大切なことであることを再認識できました。

・関係者全員を含めた細かい共有大事！

何度か記事でも書いていますが、とにかくこれにつきますね。 言った言わない、聞いた聞いてない。本当によくおこる問題です。特に関係者が多ければ多いほど…。 今はSlackやChatworkなどさまざまなコミュニケーションツールがあるため、全員がいつでも確認、認識してみんなで進めることも成功には欠かせない要素ですね。

どれも当たり前かもしれませんが、 当たり前のことをちゃんとやることがIPタイトルでの成功の鍵。

開発期間が限られていると開発終盤のベロシティも気にしなくてはならないし、 社内リソースだけでなく、社外関係者全体と認識をしっかり合わせつつ、進めていく大変さが伝わってきました。

ちなみに、ドリコム様ではIPタイトルだけでなく、今後IP×ブラウザ領域にも積極挑戦されるそうです。

メンバーも絶賛募集中で、これからの動きに注目ですね。

登壇資料 -「ヒットタイトル『ダビマス』を支える技術と体制」

XFLAG スタジオ：「モンストとサーバ運用体制」

XFLAG スタジオ様からは、誰もが知っているあのスマホアプリ『モンスターストライク』(以下、モンスト)のサーバー運用体制と、その工夫について語っていただきました。

『モンスト』の説明は不要かと思いますが、2013年にリリースされ、今では3DSや昨年は映画にもなったXFLAG スタジオ様の代名詞的タイトル。最大4人で同時に楽しめるひっぱりハンティングRPGです。そのモンストの裏側の運用体制をお話しいただきました。

ちなみに、XFLAG スタジオ様のロゴのB.B.Qは、字のごとくバーベキューを意味しているそうです。

XFLAG スタジオ様のコンセプトは、

「家族や友達と集まって、熱く盛り上がれる場所を創る」

バーベキューはその代名詞のような存在のため、ロゴにも採用されたそうです。素敵ですね。

登壇者：株式会社ミクシィ XFLAG スタジオ　松本氏

『モンスト』とサーバー運用体制
メンバーはSREチーム8名、サーバーチーム9名の計17名。

SREは負荷対策と運用改善、サーバーチームは新機能開発で編成されており、CSや解析等はプロダクトを跨いで組織が存在しているそうです。

特にこのSREとサーバーチームで、日々の運用だけでなく、メンテナンス時の運用体制をしっかりと定義づけることで、迅速な対応ができるようにされているそうです。

通常運用～PagerDutyの活用～
XFLAG スタジオ様では、万一のシステム障害対応時、障害発生から20分以内に対応開始できるように当番制を敷いているそうです。

二人一組、1週間交代のローテーションをさせることで、 いつ起こるかわからない障害に対して備えられているんですね。 当番手当もちゃんとあるところがなお素敵です！

さらに、体制だけでなく”気づく”仕組みもXFLAG スタジオ様ならでは。

監視は一般的なNagiosを利用されていて、”PagerDuty”というツールを活用されているそうです。

この”PagerDuty”が優秀で、あらかじめ決めたスケジューリングやエスカレーションポリシーに基づき、Nagiosの検知キックによってアクションを起こせるツールです。 万が一の障害時にはSlackにもアラート通知ができ、二人一組の当番体制とメンバー全員がすぐに気づける仕組みづくりをされていました。

日々の運用の中でも新しい便利なSaaSを活用しているところがさすがです。

メンテナンス
通常運用とは別に、メンテナンスも事前に体制と方法が決められているそうです。 特にメンテナンスの決め事は次の4点

1. メンテナンス時間は0:00～5:00
2. メンテナンス内作業はGitHub Issueで管理
3. サーバー人員は事前に座組みを決めておく
4. 作業は自宅で行えるように

メンテナンス時も基本的には二人一組で、作業量に応じて人数を増やされるそうです。 特徴的だなと感じたのは、深夜組、早朝組、通常組の3組編成であること！

深夜組は、上記のメンテナンス時間帯で実際に作業を担当
早朝組は、5:00～のメンテナンス明け、万が一の不具合や負荷観察を担当
さらに、通常組もあらかじめ編成しており、計画メンテナンスでも万全の体制を敷かれていました。

また、ここでもGit Hub IssueやSlackを活用して、各担当者だけでなく関係者全員で作業内容をチェックできるように工夫されているのも、国民的な大規模ゲームを運営するシビアさが感じられます。

結論！『モンスト』の運用の肝は事前準備と密なコミュニケーション！

XFLAG スタジオ様では事前の体制づくりにもみられるように、想定外の事象に誰がどのように対応できるかを具体化させていました！

また、メンバー全員でコミュニケーションを取りながら進めることを大切にされていることがよくわかりました。

登壇資料 -「モンストとサーバ運用体制」

XFLAG スタジオ：「小規模アプリ開発者が中から見るモンスターストライク」

XFLAG スタジオ様からもう1名！ ご存知の通り、ネイティブゲーム市場では『モンスト』規模のタイトルも限られてきます。 小～中規模アプリ開発から見て『モンスト』の開発が、どんな特徴をもっているか語っていただきました。

登壇者：株式会社ミクシィ XFLAG スタジオ　川又氏

『モンスト』のサーバー構成
既にSlide Shareで公開されているのでご存知の方も多いかもしれませんが、 『モンスト』のサーバー構成には次の4つの特徴があるそうです。

1. クラウド×オンプレのハイブリッド構成
2. データセンターレベルでの冗長化
3. TURNサーバーを利用したマルチプレイ
4. DB性能限界の解決としてキャッシュ比重が大きい

みなさん、ユーザー増加によるDB性能限界は苦労されているかと思います。

マシンパワーで解決できる場合、IDCFであればioMemory搭載の高性能サーバーを採用しクラウドハイブリットで利用されるケースが多くあります。 XFLAG スタジオ様でもまさにこの構成を採用いただきました。

一方で、やはりパワーだけでは解決できない問題もありますよね。 XFLAG スタジオ様でもWorld分割したり、スケールアップ対策などもちろん実施されていますが、これまでの小規模アプリ開発から見たとき、特に特徴的だったのが4点目の「キャッシュ比重」だったそうです。

『モンスト』での複数キャッシュ活用パターン
DBの性能限界解決のアプローチとして大きく特徴的なのは次の2点です。

① データセンターレベルでのキャッシュ冗長

XFLAG スタジオ様ではデータセンター自体が冗長化されていることはお伝えしましたが、 キャッシュももちろんデータセンター間で冗長化されています。

1プールあたり約40台超、1プール全体で2TB超の容量をもっており、これを2プール用意されているそうです。さすがの規模ですね…。

また2プール両方に同時書き込みを行っており、メンテナンスなしでプールの切り替えが可能かつ増強も可能な構成にして、『モンスト』の高い可用性を維持しているんですね。

② データの性質に応じたキャッシュ活用

また、規模だけでなくデータの性質をちゃんと理解して、それぞれにあったキャッシュパターンを採用されています。

具体的には、次の5つの観点がありました。

1. Mirroring
   MirroringではReadの多い静的なデータで主に利用されているそうで、Keyデータにsuffixをつけて、Memcachedサーバーの分散も同時に行っています。

2. Local Cache(memory / file)
   Local Cachedのmemoryではリクエスト単位で生存期間の短いデータを、fileではファイルとして書き出されるデータを使い分け、キャッシュサーバーに繰り返し問合せさせないように負荷対策の仕組みをされています。

3. Compress
   トラフィック量を削減させるためにCompressを活用することで、負荷とコストの両軸で対策をされています。

4. Versioning
   VersioningではMirroringとは異なりKeyにPrefixを付与することで、Versioningで一部のデータのみ削除した際、Prefixを変更させてHitさせない構成にされています。

5. Double Write
   先にも記載したように万が一の大規模障害時に備え、2プール同時に書き込みを行っています。

以上のように、データの性質や保持期間、データサイズ、冗長性担保有無などの観点で、 細かくパターンを仕分けしキャッシュをさせることで、 ユーザー増やイベント時のDB性能限界解決に結びつけているんですね。

『モンスト』ともなるとデータセンター冗長やサーバー台数など、ちょっと桁の違う規模でしたが、 規模だけでなく、開発/運用メンバーの工夫のもとに、支えられていることがよくわかりました。　

登壇資料 -「小規模アプリ開発者が中から見るモンスターストライク」

まとめ

以上！長くなりましたが、ビッグタイトルを支える裏側についてでした！　 共通してうかがえたのは、「事前準備」と「コミュニケーション」の重要性　 ビッグタイトルだからこそ、基本が重要になってくるんですね。　

IDCFでもより多くのビッグタイトルを支えられるように日々サービスを磨いていきます！

写真：Yahoo! JAPAN公式カメラ隊（阪倉 秀幸、倉増　崇史）

はじめまして。前回の記事で紹介いただいた千葉工業大学チームCITBrainsの関と申します。
紹介があったようにロボカップは「2050年までにサッカーワールドチャンピオンチームにロボットで勝つ」ことを目的としたランドマークプロジェクトです。CITBrainsは7/24-7/30に名古屋で行われたRoboCup2017ヒューマノイドリーグKIDサイズに参加しました。成績は惜しくも中国チームZJUDancerに1点差で敗れましたが、世界3位という結果を残せました。

△図1 入賞の記念撮影

△図2 シャチホコモチーフ(?)のトロフィー

この記事では、我々が今年度初めて導入した「深層学習を用いたリアルタイムサッカー物体認識」について世界大会での実践結果を書き連ねさせていただきます。

IDCFクラウドを使う理由

今年度、私達は学習用GPUサーバーとしてIDCFクラウドを利用いたしました。というのも、ロボカップでは2015年以来、毎年大会直前まで使用されるボールが明らかになりません。

△図3 大会ごとに変化するボール

ディープラーニングに限った話ではないですが、物体認識には未知の環境や異なる模様の物体を識別できない可能性がつきまといます。
そんな背景から、現地で集めた訓練データを学習することを視野にいれ、リモート接続可能でありマシンパワーに優れているIDCFクラウドを利用しました。IDCFクラウドのGPUの性能について触れている前記事もぜひご覧ください。

ディープラーニングの試み

さて、今年度のシステムの本命であるディープラーニングについてです。前記事でも説明されているとおり、目的は物体認識です。今年度はボールとゴールの検出にディープラーニングを用いました。 世界大会に備えての訓練画像はCITBrainsが活動拠点としている千葉工業大学・新習志野キャンパスにある人工芝フィールド上で集めました。もちろん上で述べたとおり、この訓練画像で世界大会の環境に適応できるかこの時点では分かりません。

△図4 訓練画像

世界大会の環境は…

まずは私達のロボット「Accelite」の視点で会場の環境をご覧ください。

△図5 ロボットから見た会場

事前の訓練画像との違いとして、白い壁や明るさの違いなどフィールド外に懸念点が多くありました。また、幸か不幸か今年度は昨年と同じ模様のボールでした。運営の新しいボールの選定にミスがあり、変更が間に合わなかったみたいです。新しいボールでどれだけ検出できるか試したい気持ちの反面、今まで学習してきたボールと同じでラッキーという気持ちです。

実践結果

会場で発見された誤検出です。やはり、懸念していたフィールド外に反応しました。

△図6 誤検出している画面

中には意外なものも誤検出されていました。ポイ捨てはいけませんね。

△図7 こんなものも誤検出の対象に

とはいえ集めた画像の内から、誤検出を探すほうが苦労するほど問題なく検出できていました。なかなかの性能です。しかし、本番である以上、不安な点は取り除いておきたいところです。
こういうときこそIDCFクラウドの出番です。現地で集めた500枚程度の画像を、以前の訓練画像に加えて学習させました。

学習を更新させた結果

IDCFクラウドのGPUサーバーは、大学のサーバーより2時間以上早く学習が終わるというデータを得ていましたが、この２時間にどれだけ助けられたことか。会場の閉館までにロボットを動かしながら、更新した学習済みモデルで貴重なデータを取ることができました。

現地の訓練画像を混ぜることで、検出対象の物体らしさが大きく向上しました。これによって誤検出との切り分けができるようになります。

△図8 訓練画像の学習によりボール認識率が向上

試合では大会中１，２を争うボール認識率だったと自負しています。けれども、ご存知のとおりサッカーはボールが見えるだけでは勝てません。来年度はこの認識率を活かせるといいかなと思います。

こんなトラブルもありました

ロボカップをやっていると毎年本番に不測の事態はつきものなのですが、そんな不測の事態がGPUマシンに起きたのが、RoboCup2017でした。Adultサイズという私達とは別リーグに参加していたチームメンバーが大学のGPUサーバーにアクセスできなくなったというのです。

その場は私達が使っていたIDCFクラウドを貸与することで解決しました。後にわかった原因は、大学職員が親元のルータの配線を変更したためだそうです。サーバーの管理がずさんな学生ならではの問題かもしれませんが、ネットワークの配線が他者にいじられるような環境にサーバーがあると不安ですね。こういう面での安心感はクラウドサービスのメリットと言えるのではないでしょうか。

展望

ディープラーニングによる物体認識はサッカーを行うために十分な性能を発揮できていたと試合を見て強く思いました。これから学習を経てゆくごとに高精度な検出器ができるのではという可能性を感じています。
GPUサーバーが身近に存在するようになった今、さらなる機械学習の発展に期待しています。

こんにちは、藤城（@tafujish）です。前回から話を戻し今回はIDCFクラウドの話、idcfcloud-cliを詳細に紹介しまショウ。

idcfcloud-cliはその名のとおり、IDCFクラウドをコマンドラインから操作するためのインターフェースです。もう少し具体的に話すと、idcfcloudコマンドを実行してIDCFクラウドの各サービスのAPIを操作することができます。この手のCLIツールとしてはこれまでcloudstack-apiを提供してきました。cloudstack-apiはコンピューティングのAPIにのみ対応しており、ILBなど他のサービスには対応していませんでした。そこでIDCFクラウドの全サービス全APIへの対応をゴールにしたCLIツールを提供しようというのがidcfcloud-cliです。

今回のリリースでは、

• ILB
• Your（Billing）

に対応しています。12月に予定している次のアップデートでは、DNS/GSLBとコンテンツキャッシュに対応予定で、その後も追加を予定しています。それでは、以下の流れで紹介していきます。

• Yourってなぁに
• インストール方法
• idcfcloud-cliを初期設定する
• idcfcloud-cliの使い方
• Yourのビリングを試してみる
• ILBを試してみる
• まとめ

$ ruby -v
ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]

$ sudo apt update && sudo apt install ruby-dev gcc g++ make -y
～略～
$ sudo gem update --system
$ sudo gem install idcfcloud
～略～
1 gem installed

$ idcfcloud help
Commands:
  idcfcloud configure              # create configure
  idcfcloud help [COMMAND]         # Describe available commands...
  idcfcloud ilb [OPTION]           # ILB Service
  idcfcloud init                   # initialize
  idcfcloud update                 # list update
  idcfcloud your [OPTION]          # Your Service

$ sudo idcfcloud init
default:api_key[NONE] :
【API Keyを貼りつけてください】

default:secret_key[NONE] :
【Secret Keyを貼りつけてください】

default:region[NONE] :
【デフォルト指定するリージョンを記述ください（jp-east/jp-east-2/jp-west）】

please write in
~/.bash_profile
source /var/lib/gems/2.3.0/gems/idcfcloud-0.1.2/output/complement.bash
~/.zprofile
source /var/lib/gems/2.3.0/gems/idcfcloud-0.1.2/output/complement.zsh

$ sudo idcfcloud configure

$ idcfcloud configure --no-global

$ sudo idcfcloud update

$ sudo gem update idcfcloud

$ idcfcloud <serviceName> <command> [attributes] [option]

$ idcfcloud ilb help
Commands:
  idcfcloud ilb add_server <lb_id> <config_id> <data> [headers]
～以下略～

$ idcfcloud your list_billing_detail 2017-04 
{
  "status": 200,
  "message": "",
  "data": {
    "meta": {
      "account_id": "71000000000",
      "taxable_amount": 395789,
      "tax": 31614,
      "total": 427403,
      "updated_at": "2017-05-01T02:29:43+09:00",
      "billing_period_start_at": "2017-04-01",
      "billing_period_end_at": "2017-04-30",
      "invoice_no": "B7129932301"
    },
    "data": [
      {
        "Region": "jp-east",
        "ServiceName": "Cloud Computing",
        "ZoneName": "joule",
        "Category": "VirtualMachine",
        "Menu": "standard.S4",
        "ResourceDisplayName": "web01",
        "StartDate": "2017-04-10",
～以下略～

$ idcfcloud your list_billing_detail 2017-04 -o csv > 2017-04.csv
$ cat 2017-04.csv
Region,ServiceName,ZoneName,Category,Menu,ResourceDisplayName,StartDate,EndDate,Usage,Allocated,Running,Stopped,Amount,Tax,Net
jp-east,Cloud Computing,joule,VirtualMachine,standard.S4,web01,2017-04-10,2017-04-30,491.92444419861,491.96638870239,491.92444419861,0.04194450378418,5300,424,5724
～以下略～

$ idcfcloud ilb list_loadbalancers
～略～
          "servers": [
            {
              "id": "70da2f85-9893-4ae0-864e-4f3e2dfb23a1",
              "loadbalancer_id": "476b0e9f-ee26-4630-ab64-51edaa10aad4",
              "config_id": "b43e38a3-3d6e-4096-afdf-9bf09ecb6c9d",
              "ipaddress": "10.32.0.204",
              "port": 80,
              "created_at": "2017-08-30T16:44:18.000+09:00",
              "updated_at": "2017-08-30T16:44:44.000+09:00",
              "state": "Running"
            }
          ],
～略～

$ idcfcloud ilb add_server "476b0e9f-ee26-4630-ab64-51edaa10aad4" "b43e38a3-3d6e-4096-afdf-9bf09ecb6c9d" '{"ipaddress":"10.32.0.123", "port":80}'
{
  "status": 200,
  "message": "",
  "data": [
    {
      "id": "70da2f85-9893-4ae0-864e-4f3e2dfb23a1",
      "ipaddress": "10.32.0.204",
      "port": 80
    },
    {
      "id": "bf28183d-a291-4b27-b4f1-4815d6174014",
      "ipaddress": "10.32.0.123",
      "port": 80
    }
  ]
}

$ idcfcloud ilb delete_server "476b0e9f-ee26-4630-ab64-51edaa10aad4" "b43e38a3-3d6e-4096-afdf-9bf09ecb6c9d" "bf28183d-a291-4b27-b4f1-4815d6174014"
{
  "status": 200,
  "message": "",
  "data": null
}

$ idcfcloud ilb list_servers "476b0e9f-ee26-4630-ab64-51edaa10aad4" "b43e38a3-3d6e-4096-afdf-9bf09ecb6c9d"
{
  "status": 200,
  "message": "",
  "data": [
    {
      "id": "70da2f85-9893-4ae0-864e-4f3e2dfb23a1",
      "ipaddress": "10.32.0.204",
      "port": 80
    }
  ]
}

こんにちは、藤城（@tafujish）です。前回のidcfcloud-cliリリースに続きまして、今回はidcfcloud-cliを動かすためのRuby環境の構築について紹介します。

idcfcloud-cliはRuby 2.2.7以降が必要となります。Ubuntu16.04ではRuby 2.3.1なので問題ないですが、CentOS7ではRuby 2.0.0なのでバージョンが古く未対応です。そこで今回は、CentOS7環境でRuby 2.3.1の環境を構築する手順を扱います。Rubyのソースを持ってきてビルドすれば終わりですが、管理の問題やそもそもビルド自体が大変ですよね。Rubyのバージョン管理は最近ではrbenvを利用するのが一般的です。Rubyでの開発目的であればrbenvで環境構築するのが一般的ですが、idcfcloud-cliを動かすだけならSoftware Collections(以下SCL)でインストールするのが楽でしょう。ここでは、rbenvとSCL両方の手順を紹介して、idcfcloud-cliをcronで回すような使い方ができるところまでやります。

• rbenvにする？それともSCLにする？
• rbenvでrubyインストール
  • rbenvでruby 2.3.1インストール
  • rbenvからidcfcloud-cliを利用
  • シェルスクリプトをcronでまわす
• SCLでrubyインストール
  • SCLでruby 2.3.xインストール
  • SCLからidcfcloud-cliを利用
  • シェルスクリプトをcronでまわす
• まとめ

# yum install git gcc make bzip2 openssl-devel readline-devel -y

# git clone https://github.com/rbenv/rbenv.git ~/.rbenv
# cd ~/.rbenv && src/configure && make -C src
# echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
# echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
# source ~/.bash_profile

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

# curl -fsSL https://github.com/rbenv/rbenv-installer/raw/master/bin/rbenv-doctor | bash
Checking for `rbenv' in PATH: /root/.rbenv/bin/rbenv
Checking for rbenv shims in PATH: OK
Checking `rbenv install' support: which: no rbenv-install in (/root/.rbenv/shims:/root/.rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/root/bin)
/root/.rbenv/plugins/ruby-build/bin/rbenv-install (ruby-build 20170726-9-g86909bf)
Counting installed Ruby versions: none
  There aren't any Ruby versions installed under `/root/.rbenv/versions'.
  You can install Ruby versions like so: rbenv install 2.2.4
Checking RubyGems settings: OK
Auditing installed plugins: OK

# rbenv install --list

# rbenv install 2.3.1
# rbenv global 2.3.1

# yum install gcc gcc-c++ make -y
# gem update --system
# gem install idcfcloud

#!/bin/sh
OUTPUT=/tmp/`date --date='1 day ago' +%Y-%m-%d`.csv
source /root/.bash_profile
idcfcloud your list_billing_detail ` date --date='1 day ago' +%Y-%m` -o csv \
  > $OUTPUT

# yum install centos-release-scl -y

# yum install rh-ruby23 rh-ruby23-ruby-devel -y

# scl enable rh-ruby23 bash

# yum install gcc gcc-c++ make -y
# gem update --system
# gem install idcfcloud

#!/bin/sh
OUTPUT=/tmp/`date --date='1 day ago' +%Y-%m-%d`.csv
source scl_source enable rh-ruby23
idcfcloud your list_billing_detail ` date --date='1 day ago' +%Y-%m` -o csv \
  > $OUTPUT