こんにちは、河合です。以前はIDCFクラウドDNS/GSLBのGSLB機能について紹介いたしました。振り返りになりますが、GSLBはDNSの名前解決を用いたロードバランシング機能です。ヘルスチェックや重み付けができるラウンドロビン方式による分散を実現します。 今月このGSLBの機能拡張がリリースされてCNAMEレコードにも対応可能となったので、それによりできるようになったことと活用事例をお伝えいたします！

関連記事
3ステップで導入！GSLBを使ってDR対策にトライ

CNAMEレコード対応でできること

これまではAレコードのみ分散対象として登録可能でした。そのため、たとえば図1のようなActive/Standby構成を実現したい場合は各環境のWebサーバー1台ずつに対してGSLBを設定していました。

▲図1 GSLBによるAレコード分散

example.comゾーン

gslb.example.com　IN　A　1.1.1.1　重み1
　　　　　　　　　　IN　A　1.1.1.2　重み1
　　　　　　　　　　IN　A　1.1.1.3　重み1
　　　　　　　　　　IN　A　2.2.2.1　重み0
　　　　　　　　　　IN　A　2.2.2.2　重み0
　　　　　　　　　　IN　A　2.2.2.3　重み0

今回の機能アップデートではCNAMEレコードに対しGSLB設定をすることができるようになりました。これによって、たとえばこれまで多くのリクエストをいただいていたILBやコンテンツキャッシュとの連携が可能となります(図2)。

▲図2 分散対象としてILBを登録

example.comゾーン

gslb.example.com　IN　CNAME　ilb1.idcfcloud.net　重み1
　　　　　　　　　　IN　CNAME　ilb2.idcfcloud.net　重み0

ドメインを直接指定できるようになったことでFQDN単位のサービスなどを分散先として登録可能になりました。実現したい構成に沿った、より柔軟な分散方法が選択できるようになりましたね！
実際のGSLB設定画面は図3のようになっています。Aレコードの設定時と同じ要領で、CNAMEレコードに対してもGSLBの「有効」を選択します。

▲図3 CNAMEレコード記述画面 GSLB有効化設定

そうするとFQDNの入力欄が表示されるので、プルダウン形式で任意のFQDNを選択します。ここで表示される選択肢は同一アカウント内で作成されているILBのFQDN・コンテンツキャッシュの独自ドメインとなります。もし別アカウントで作成しているILBやコンテンツキャッシュに分散したい場合はチケットからお問い合わせください。

また、オブジェクトストレージを直接指定することはできませんが、コンテンツキャッシュのオリジンサーバーとしてオブジェクトストレージを登録いただければ、連携させることが可能です。

重み付けに対する動作

GSLBでは重み付けラウンドロビンで分散を実現しているので、各レコードに対し0から10の重みを指定します。Aレコード/CNAMEレコードともに、通常時は重み0以外のレコードに対し設定された重み付けに従って応答します。重み付けがすべて0の場合、各レコードの応答仕様は次の通りとなります。
　■Aレコード：クエリに対し、すべてのレコードが応答
　■CNAMEレコード：クエリに対し、いずれかの１レコードが応答

ヘルスチェック動作

CNAMEレコードの場合、名前解決によって選択された1つのIPアドレスに対してヘルスチェックを行います。 その他の設定項目、挙動についてはこれまでのAレコードと同様となります。細かな仕様については次のFAQに掲載していますのでぜひご参照ください。
　FAQ - GSLBのヘルスチェック仕様

活用事例

上記ではIDCFクラウド上のサービス連携についてお話してきましたが、マルチクラウドでご利用のケースにもご活用いただけます。たとえばIDCFクラウドとAWSの併用でELBを利用している環境(図4)では、GSLBの分散先としてそれぞれのFQDNを登録します。
※セキュリティ上GSLBの分散先として登録できる範囲を同一アカウント内のILB・コンテンツキャッシュに絞っていますので、次のようなケースでご利用になる場合もチケットにてお問い合わせください。

▲図4 マルチクラウド環境例

example.comゾーン

gslb.example.com　IN　CNAME　ilb.idcfcloud.net　重み1
　　　　　　　　　　IN　CNAME　elb.aws.com　重み0

こうすることでマルチクラウド環境間でのActive/Activeの分散や、物理拠点を分けた分散による耐障害性の向上など自由度の高い構成が実現できます。みなさんの用途、要件に応じたご利用方法をぜひ検討してみてください。 なおDNSのルール上(RFC1912)、ホスト名なしのドメイン(ZoneApex)に対するCNAMEレコードは登録できませんのでご留意ください。

こんにちは、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」を設定してください。
• ヘッダーを変更したら必ずキャッシュ削除を行って、キャッシュの有無確認をしてください。

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

こんにちは、金杉です。7月31日に次のタイトルで、IDCフロンティア主催のセミナーを開催しました。

必見、ヤフーも語る！ 「ディープラーニングで進化するAIと次世代インフラ＆プラットフォーム」

先月、そんな記事見たような？と思われる方もいらっしゃるかと思いますが、今回のセミナーでも前回のセミナーと同じように豪華なセッションを揃えることができました！ヤフーの音声認識技術「YJVOICE」におけるディープラーニングの実用化に加え、なんとあの「DMM.comラボ」や、“AIの民主化”を目指す「クロスコンパス・インテリジェンス」にも登壇いただきました。ヤフーからは、話題のGREEN500ランクインスパコン「kukai」の運用事例についても紹介していただけました。

では、当日のセッション概要をみなさまにお伝えしたいと思います。

セッションのポイント

1. DMM.comにおけるレコメンドへの Deep Learning の活用

登壇者　株式会社DMM.comラボ　中野 裕貴 氏、領家 飛鳥 氏

DMMはゲーム、DVD、FX事業で知られる先進的なTech企業であり、もちろんDeep Learningも始めています。今回紹介していただいたDeep Learningの活用事例は、ゲームのレコメンドです。ゲームのパッケージ画像を分析し、とあるゲームをクリックすると、他の類似したパッケージ画像をユーザーにレコメンドしてくれるというスマートな仕組みです。モデルは元々Illustration2Vecを使っていたものの、それではアニメ画像の特徴検出が難しかったため、自作を選択したとのこと。

• 学習データはGoogle Open DatasetやWeb Search APIを使用
• 加工は"目grep"、顔にフォーカスしノイズを最小限へ
• Caffeを利用、DIGITSや過去実績が多いのが理由
• 過学習防止のためにdrop out方式や学習レイヤーを調整

ライブラリを有効に使うのがコツみたいですね。次の目標は学習データの加工部分を自動化することらしいですが、楽しみです！DMMの開発者ブログでも当日登壇のブログが上がっていましたので、こちらの記事もぜひご覧ください！

【資料公開】「ディープラーニングで進化するAIと次世代インフラ＆プラットフォーム」で登壇しました - DMM.comラボエンジニアブログ

2. AIのあるある話。「こんな◯◯はいやだ！？」

登壇者　株式会社クロスコンパス・インテリジェンス　佐藤 聡 氏

クロスコンパス・インテリジェンスは「誰もがAIを使えるように」と人工知能の民主化を提唱しており、特に製造業に強いAIソリューションを提供しています。第三次AIブームともよばれる繁栄期を迎えた昨今、たくさんのクライアントから相談を受けるクロスコンパス・インテリジェンスならではのAIあるあるを語っていただきました。

あるあるポイント

• 人工知能で何ができるかをそもそも理解していない
• 学習データが少なかったり、正確でないとモデル作成は難しい
• AIは一部の特化した領域で人間を越えているが、脳の代替はできていない
• 歴史的に人工知能は氷河期を迎えたことがあるが、前向きに頑張るべき
• 人手不足が深刻している今こそ、AIで対応する必要がある

まだまだAIへの認識がぼんやりとしていたり、後ろ向きな声もあるので、AIがもたらす本当のメリットをもっと普及させる必要がありますね。IDCフロンティアもAIサービスの基盤となるGPUの提供者として頑張らなきゃ！

3. ヤフー音声認識YJVOICEにおけるディープラーニングの実用化

登壇者　ヤフー株式会社　三宅 純平 氏

YJVOICEをみなさんは知っていますでしょうか？YJVOICE単体はともかく、現時点ではヤフーの15弱のアプリの中にYJVOICEの機能が組み込まれています。その名の通り、YJVOICEは音声を認識することができ、そして音声認識のコアな部分はDeep Learningが活用されているのです。例えば、「天気教えて」とYJVOICEに問いかけると、デバイスは単純な音声データのみをサーバーに送り、サーバー側で音声データをちゃんとした日本語に変換し、認識結果をデバイスにフィードバックします。

• 30%〜40%改善！音声区間検出と音響モデルにおいてDeep Learningを使用
• 音声系列のパターン認識の手法はLeft-to-Right Hidden Markov Model (HMM)
• 学習データはヤフーが持っていたデータ、TITAN Xで約2週間
• フレームワークはTensorFlow、アルゴリズムはMinibatch SGD
• 本番ではIntelのCPUサーバーを使用、Intel MKLライブラリが活躍

今後は学習時にマルチGPU、マルチスレッドを活用し、モデル学習の大規模化を目指すとのことでした。YJVOICEのさらなる進化に期待です！

4. kukai: 省エネ世界2位のディープラーニング・スパコン

登壇者　ヤフー株式会社　角田 直行 氏

世界のスパコンランキングはTOP500、GREEN500など色々ありますが、簡単に言うと世界のスーパーコンピューターのランキングです。TOP500はLINPACKというベンチマークの値をベースにスーパーコンピューターをランキングする指標で、計測単位はTFlops（演算性能）を使用しており、スパコンの高速さを示すものです。一方で、GREEN500の単位はMFlops/Wで、スーパーコンピューターのエネルギー消費効率の良さを示すものです。

ヤフーのスパコン「kukai」は、GREEN500で見事2位を獲得しております！そして、GREEN500へのランクイン条件として、TOP500に入る必要があるため、kukaiはTOP500にもランクインしており、"省エネかつできる子"なのです。そして、気になるkukaiの設置場所ですが、実はIDCフロンティアの白河データセンターにあります！

• 20ブリック構成、計80ノード (1ブリックあたり4CPU、8GPU)
• GPUはNVIDIA Tesla P100 PCIe 16GBを採用
• 冷却はフロリナートによる液浸方式
• LINPACKチューニングは職人的スキルが必要
• ベンチマークでハードウェア故障が発生したり苦労もあった

ヤフーでは様々な場面でDeep Learningを活用しています。前のセッションで紹介されたYJVOICEなどの既存Deep Learningの実装も、今後はkukaiに移行していく予定なので、より学習が効率的になっていきますね。kukaiは斬新な液浸方式を採用してますが、もっと面白い方法も出てくるのかも！？

5. 次世代のIT技術を支える、高度なファシリティ ~ディープラーニングを支えるデータセンター~

登壇者　株式会社IDCフロンティア　皆川 真一朗

ものすごいペースでDeep Learningの挑戦者が増える一方、インフラに対してのニーズも同じように増えています。IDCフロンティアでは1ラック20kVA以上の超高負荷冷却の相談も受けたりします。従来の解決策以外に、新しい方法も模索して、Deep Learningの熱を支えきれるデータセンター設計を目指しています！

• 超高負荷ラックの熱を処理するためにデッドスペースができてしまう
• 対策その1 白河の冷たい外気を利用した従来の外気冷却システム
• 対策その2 チムニー効果を利用した屋外への熱放出
• 対策その3 InRow空調で熱と風量を制御
• 対策その4 熱搬送能力が空気の1000倍ある液浸冷却方式

また、Deep Learningを支えるだけでなく、データセンターの運用自体にも機械学習を活用していけるのが理想的です。例えば、ルールベースではなく、機械学習を用いて空調システムを制御する技術など、IDCフロンティアは今後もインフラ事業者として超高負荷ラックを最適化する研究開発を推進していきます！

まとめ

AIや人工知能がバズワード化する今、一刻も早くAIシフトせねば！と焦っていらっしゃる方も多いのではないでしょうか。今回のセッションで紹介があった成功事例のように、工夫をすればきっとDeep Learningは成功するので、将来への投資だと思ってぜひはじめてみませんか？今後もIDCフロンティアでセミナーを開催しますので、ぜひまたの機会にご参加ください！

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

こんにちは！そして、はじめまして！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

こんにちは、インフラ開発部の鳥垣です。

今回のブログではアクセスログの解析作業の効率化を図るため、ログの可視化のお話をさせていただければと思います。 導入の背景は、仕組みとしてサーバーからsyslogサーバーへのログの集積はすでに実装されていました。 しかし、syslogへの送信元のサーバー数の肥大化に伴い多量のログが保存されるようになり、ログ調査に時間がかかるようになってきました。 もっとサックリとログの調査を行う基盤が欲しいということで、今回Fluentd + Elasticsearch + Kibanaを導入しました。 FluentdでsyslogサーバーからElasticsearchにログを送り、Elasticserchでログ検索、Kibanaでグラフ化しました。 Fluentd + Elasticsearch + Kibanaを導入する際の設定や、構成などを紹介します。

• システム構成
• インストール
  • ElasticSearch
  • kibana
  • Fluentd
• ElasticSearchの設定
• kibanaの設定
• Fluentdの設定
  • ログデータの送信
  • ログデータの受信と加工
• 各プロセスの起動
• ElasticSearchの過去Index削除
• 最後に

システム構成

• サーバー情報(10台)

※全台スペック共通の物理サーバーです。

• バージョン情報

※ElasticSearchは10台でクラスタ構築しています。

※Kibanaで使用するサーバーがリソースに余裕があったのでFluentdと兼用しています。

インストール

ElasticSearch

最初にjdkをインストールします。

sudo yum install java-1.8.0-openjdk

以下手順でElasticSearchをインストールします。

sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
 
sudo vim /etc/yum.repos.d/elasticsearch.repo にて以下内容のファイルを作成します。
[elasticsearch-5.x]
name=Elasticsearch repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
 
sudo yum install elasticsearch

kibana

最初にjdkをインストールします。

sudo yum install java-1.8.0-openjdk

以下手順でkibanaをインストールします。

sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
 
sudo vim /etc/yum.repos.d/kibana.repo にて以下内容のファイルを作成します。
[kibana-5.x]
name=Kibana repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
 
sudo yum install kibana

Fluentd

以下手順でFluentdをインストールします。

sudo curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh

• Fluentdのプラグインをインストール

送信側

sudo /usr/sbin/td-agent-gem install fluent-plugin-multiprocess

受信側

sudo /usr/sbin/td-agent-gem install fluent-plugin-multiprocess
sudo /usr/sbin/td-agent-gem install fluent-plugin-multi-format-parser
sudo /usr/sbin/td-agent-gem install fluent-plugin-elasticsearch
sudo /usr/sbin/td-agent-gem install fluent-plugin-file-alternative

ElasticSearchの設定

/etc/elasticsearch/elasticsearch.yml を変更します。

cluster.name: cluster_name ← 任意の名前を指定。
 
network.host: 0.0.0.0 ← リモートホストからの接続を受け付けられるように設定。
 
bootstrap.memory_lock: true ←スワップ無効化の設定。
 
node.name: hostname ← サーバーのホスト名を指定。
 
discovery.zen.ping.unicast.hosts: ["xxx.xxx.xxx.xxx", "xxx.xxx.xxx.xxx","xxx.xxx.xxx.xxx"] ←ElasticSearchをインストールしたサーバーのIPアドレスを指定。
 
discovery.zen.minimum_master_nodes: 6 ← 計算式（ノード数 / 2 + 1）に従った数値を指定。10台の場合は6。

ヒープ設定を変更するため、/etc/elasticsearch/jvm.options を変更します。

今回使用するサーバーのメモリが64GBのため半分の32GBを指定します。

-Xms32g
-Xmx32g

kibanaの設定

/etc/kibana/kibana.yml を変更します。

server.host: "0.0.0.0" ← リモートホストからの接続を受け付けられるように設定。
 
elasticsearch.url: "http://xxx.xxx.xxx.xxx:9200" ←ElasticSearchサーバーのIPを指定。

Fluentdの設定

ログデータの送信

解析対象のアクセスログはsyslogサーバーに集約されているので、syslogサーバーにFluentdをインストールし、アクセスログを読み込んで送信します。

可視化したいログファイルは4つあるので、multiprocess を使ってFluentdをマルチプロセス化して4プロセス起動し、それぞれのプロセスでログファイルを読み込ませて送信させています。

syslogサーバーは低スペックなうえ、様々なバッチ処理が動いているのでサーバー負荷を上げないようにするため、syslogサーバーのFluentdはログファイルを読み込んで送信するだけの処理をしています。

また、送信先が障害になった場合、送信先をスタンバイ機に切り替えるようにも設定してあります。

以下はログ送信のFluentd設定になります。

※multiprocessプラグインを使用しているので、設定は親プロセスと子プロセスに分けてあります。

親プロセス（/etc/td-agent/td-agent.conf）の設定

<source>
  type multiprocess
 
  <process>
    cmdline -c /etc/td-agent/td-agent-child1.conf --log /var/log/td-agent/td-agent-child1.log ←子プロセスの設定ファイルとログの出力ファイルを指定。
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
  <process>
    cmdline -c /etc/td-agent/td-agent-child2.conf --log /var/log/td-agent/td-agent-child2.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
  <process>
    cmdline -c /etc/td-agent/td-agent-child3.conf --log /var/log/td-agent/td-agent-child3.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
  <process>
    cmdline -c /etc/td-agent/td-agent-child4.conf --log /var/log/td-agent/td-agent-child4.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
</source>

子プロセス(/etc/td-agent/td-agent-child1.conf)の設定

<source>
  @type tail
  path /var/log/filename01.log ← 読み込むファイルを設定。
  pos_file /var/log/td-agent/filename01.log.pos
  format none ← 生ログデータを送信するため「none」を設定。
  read_from_head true ← ファイルの先頭から読み込ませるため設定。
  tag filename01.log
</source>
 
<match filename01.log>
  @type forward
  require_ack_response true ←再送設定を有効にするため設定。
  buffer_type file ←ファイルバッファを有効にするため設定。
  buffer_path /var/log/td-agent/buffer/filename01
  buffer_chunk_limit 8m
  buffer_queue_limit 128
  <server>
    host xxx.xxx.xxx.xxx ←アクティブ機のIPアドレスを指定。
    port 24221
  </server>
  <server>
    host xxx.xxx.xxx.xxx ←スタンバイ機のIPアドレスを指定。
    port 24221
    standby
  </server>
</match>

※上記を4プロセス分設定します。

ログデータの受信と加工

syslogサーバーから送信されたログデータを受信し、fluent-plugin-file-alternativeを使って一旦ファイルに書き出します。ElasticSearchに送るデータはこのファイルを読み込んで送信します。

こうすることで、もしElasticSearch側で障害発生した場合でもsyslogサーバー側のFluentdでバッファが溜まることを防ぐことができます。

書き出したファイルは日付でローテーションさせ、過去ログをJenkinsのJOBで定期削除するようにしています。

受信するFluentdプロセスもマルチプロセス化して4プロセス起動しておき、それぞれのプロセスで受信します。

ログデータは3種類のフォーマットが混ざった形で出力されているので、ElasticSearchに送る前に fluent-plugin-multi-format-parserを使ってそれぞれパースします。

ElasticSearchに送信するFluentdもマルチプロセス化して4プロセスで処理させています。

以下は受信側のFluentd設定です。

※multiprocessプラグインを使用しているので、設定は親プロセスと子プロセスに分けてあります。

親プロセス（/etc/td-agent/td-agent.conf）の設定

<source>
  type multiprocess
 
# 受信したログデータをファイルに出力する子プロセス
  <process>
    cmdline -c /etc/td-agent/child_conf.d/file_alternative01.conf --log /var/log/td-agent/file_alternative01.log ←子プロセスの設定ファイルとログの出力ファイルを指定。
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
  <process>
    cmdline -c /etc/td-agent/child_conf.d/file_alternative02.conf --log /var/log/td-agent/file_alternative02.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
  <process>
    cmdline -c /etc/td-agent/child_conf.d/file_alternative03.conf --log /var/log/td-agent/file_alternative03.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
  <process>
    cmdline -c /etc/td-agent/child_conf.d/file_alternative04.conf --log /var/log/td-agent/file_alternative04.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
 
# 読み込んだデータをパースしてElastcSearchに送信する子プロセス
  <process>
    cmdline -c /etc/td-agent/child_conf.d/multi_format_tail01.conf --log /var/log/td-agent/multi_format_tail01.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
  <process>
    cmdline -c /etc/td-agent/child_conf.d/multi_format_tail02.conf --log /var/log/td-agent/multi_format_tail02.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
  <process>
    cmdline -c /etc/td-agent/child_conf.d/multi_format_tail03.conf --log /var/log/td-agent/multi_format_tail03.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
  <process>
    cmdline -c /etc/td-agent/child_conf.d/multi_format_tail04.conf --log /var/log/td-agent/multi_format_tail04.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
  </process>
</source>

以下は、ログデータを受信してファイルに書き出すFluentdの設定（/etc/td-agent/child_conf.d/file_alternative01.conf）になります。

<source>
  @type forward
  port 24221
</source>
 
<match filename01.log>
  type file_alternative
  path /var/log/td-agent/file/filename01.log.%Y%m%d ←受信したデータを出力するファイルのパス（日毎でローテーションされます）。
 
  buffer_type file
  buffer_path /var/log/td-agent/buffer/filename01
  buffer_chunk_limit 8m
  buffer_queue_limit 256
 
  output_data_type attr:message
  output_include_time false
  output_include_tag  false
  add_newline         true
</match>

※上記を4プロセス分設定します。

以下は、ログデータをパースしてElastcSearchに送信する設定(/etc/td-agent/child_conf.d/multi_format_tail01.conf)になります。

<source>
  @type tail
  path /var/log/td-agent/file/filename*
  pos_file /var/log/td-agent/filename01.log.pos
 
  format multi_format
  <pattern>
    format /^xxxxxxxx$/ ←パースするフォーマットを正規表現で指定。
  </pattern>
  <pattern>
    format /^xxxxxxxx$/
  </pattern>
  <pattern>
    format /^xxxxxxxx$/
  </pattern>
  tag filename01_multi_format.log
  read_from_head true
</source>
 
<match filename01_multi_format.log>
  @type elasticsearch
  logstash_format true
  hosts xxx.xxx.xxx.xxx:9200 ←ElasitcSearchサーバーのIPを指定。
  logstash_prefix filename_log
  buffer_type file
  buffer_path /var/log/td-agent/buffer/filename01_multi_format
  flush_interval 1
</match>

※上記を4プロセス分設定します。

各プロセスの起動

設定完了後、各ミドルウェアのプロセスを起動していきます。

ElasticSearchの起動

sudo systemctl start elasticsearch

Kibanaの起動

systemctl start kibana

Fluentdの起動

systemctl start td-agent

ElasticSearchの過去Index削除

過去のIndexの削除処理にはelasticsearch-curatorを使用しており、Jenkinsから定期実行するようしています。

elasticsearch-curatorをJenkinsサーバーにインストールします。インストール方法は以下になります。

sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

sudo vim /etc/yum.repos.d/curator.repo にて以下内容のファイルを作成します。
[curator-4] 
name=CentOS/RHEL 7 repository for Elasticsearch Curator 4.x packages
baseurl=http://packages.elastic.co/curator/4/centos/7
gpgcheck=1
gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

sudo yum install elasticsearch-curator

mkdir /var/lib/jenkins/.curator/ ← 設定ファイルを配置するためのディレクトリを作成します。

elasticsearch-curatorの設定は以下になります。

• configファイル（/var/lib/jenkins/.curator/curator.yml） の設定

client:
  hosts:
    - xxx.xxx.xxx.xxx  ←ElasticSearchサーバーのIPを指定。
  port: 9200
  url_prefix:
  use_ssl: False
  certificate:
  client_cert:
  client_key:
  ssl_no_validate: False
  http_auth:
  timeout: 30
  master_only: False
 
logging:
  loglevel: INFO
  logfile:
  logformat: default
  blacklist: ['elasticsearch', 'urllib3']

• actionファイル（/var/lib/jenkins/.curator/delete_indices.yml）の設定

actions:
  1:
    action: delete_indices
    description: "Delete filename_log indices"
    options:
      ignore_empty_list: True
      continue_if_exception: False
      disable_action: False
    filters:
    - filtertype: pattern
      kind: prefix
      value: filename_log- ←削除するIndexのprefixを指定。
      exclude:
    - filtertype: age
      source: name
      direction: older
      timestring: '%Y.%m.%d'
      unit: days
      unit_count: 20 ←何日前のIndexを削除するか指定。「20」の場合は20日前のIndexが削除されます。
      exclude:

上記設定のうえ、Jenkinsで以下を定期実行しています。

/usr/bin/curator /var/lib/jenkins/.curator/delete_indices.yml

最後に

今回はFluentd + Elasticsearch + Kibanaの構成や設定についてお話させていただきました。

これからログの可視化にチャレンジする方の参考になれば幸いです！ それでは！

はじめまして、山賀です。今回はIDCFクラウドの陰の立役者「仮想ルーター」についてお話しさせて頂きます。IDCFクラウドを使いこなす（使い倒す！）にあたっては、「仮想ルーター」の理解が欠かせません。その名の通り、仮想ルーターとは仮想マシンで作られたルーターであり、ネットワーク機能に加え、管理機能も兼ね備えています。あまり意識されない方も多いかもしれませんが、仮想マシンのパスワードをリセットしたり、DNSリゾルバサーバーとして動作するのも仮想ルーターです。

では、先だって簡単にこの記事のサマリをお伝えします。

• 仮想ルーターの機能
• 仮想ルーターの仕組み
  • 仮想ルーターそのものについて
  • 各種機能の実装について
  • 仮想ルーターの切り替わり
• 仮想ルーターの性能、制限
• お勧め構成例
  • コネクション数過多パターン
  • 仮想ルーター高負荷パターン
• まとめ

早速、仮想ルーターの機能からいきましょう。

仮想ルーターの機能

仮想ルーターの最も重要な機能は、パブリックIPアドレスをもち、インターネットとの通信の出口になるゲートウェイ機能です。IDCFクラウドで仮想マシンを起動すると直ぐにインターネットに接続できるのですが、仮想ルーターがデータ転送をしているので通信が可能なのです。

仮想ルーターには一般的なルーターとしての役割が幾つかあるので、まとめてご紹介します。

続きまして、IDCFクラウド内の仮想マシンやサービスを管理するための役割機能です。

さらに、IDCFクラウドを便利に利用して頂くための機能がこちらになります。

仮想ルーターの仕組み

ここからは、仮想ルーターそのものや、各種機能について、どのような仕組（動作条件、ソフトウェア等）で動いているのかをご紹介します。内容が盛りだくさんのため、Q&A形式で記載してみたいと思います。

仮想ルーターそのものについて

Q 仮想ルーターのスペックは？
A 2コア、2GBメモリの仮想マシンです。図1のように、ネットワークメニューの仮想ルーター管理タブにて、「マシンタイプ - M2VR」と確認することができます。IDCFクラウドでは2コアの仮想マシンを「M〜」と呼んでいるため、ここでの「M2」は2コア、メモリが2GBということを表しています。

Q 仮想ルーターはいつできるの？
A ゾーンを有効化した時に作成されます。

Q 仮想ルーターはいくつできるの？
A 1ゾーンにつき1組(2台で冗長)つくられます。たとえば、newton, lux, augustaの3ゾーンを有効にしていた場合は、2台×3ゾーン＝合計6台の仮想ルーターがつくられます。

Q 仮想ルーターのOSは？
A Debian GNU/Linuxベースです。

Q 仮想ルーターにはどのようなネットワークインターフェースがあるの？
A 三種類のインターフェースがあり、以下のようになっています。
① ローカル（アカウント内ネットワーク）通信用
② IDCF管理用
③ インターネット通信用

Q 仮想ルーターはどうやって冗長化しているの？
A Keepalivedがインストールされており、VRRPというルーター冗長用のプロトコルを用いてVIPで冗長化されています。

Q 仮想ルーターは停止/削除されるの？
A アカウントが削除、もしくはゾーンが無効化されると同時に、仮想ルーターは削除されます。また、ゾーンに仮想マシンが1台もない状態で、一定期間が経過すると停止または削除される可能性があります。ただし、仮想マシン作成時に仮想ルーターは起動/作成されます。仮想ルーターの起動/作成を待ってからの仮想マシン作成になるため、しばらくぶりに仮想マシンを作成すると、時間が掛かってしまうことになります。

Q 仮想ルーターのソースIPアドレスは変わるの？
A 仮想ルーターが停止され、起動されるだけでしたら、ソースIPアドレスは変わりません。一度削除され、再作成されるとソースIPアドレスは変わります。

Q 仮想ルーターと仮想マシンは別のところにあるの？
A 仮想基盤上からは仮想ルーターも仮想マシンの1つとして認識しているため、IDCFクラウドのホストサーバー上に混在しています。ただし、冗長している対の仮想ルーターは必ず別のホストサーバーで起動するようにしています。

Q 仮想ルーターを搭載するホストサーバーが故障したらどうなるの？
A 詳しくは仮想ルーターの切り替わりを参考にしてください。

Q 仮想ルーターのリソース状況は見れますか？
A リソース状況についてはMackerelで見ることができます。ロードバランシング状況については、Statistics Report画面にて見ることができます。Statistics Reportを利用するためには、ファイアウォールで23451番ポートを解放する必要があります。詳しくはこちらのFAQを参考にしてください。

各種機能の実装について

Q どの様にパブリックIPアドレスが付与されているの？
A インターネット通信用のインターフェースに直接設定されています。

Q ポートフォワードはどのように実現しているの？
A 登録された情報をiptablesに設定することで実現しています。

Q Static NATはどのように実現しているの？
A 登録された情報をiptablesに設定することで実現しています。

Q ファイウォールはどのように実現しているの？
A 登録された情報をiptablesに設定することで実現しています。

3つ連続で同じ答えになってしまいましたが、パケットの取り扱いについては、iptablesを利用しています。

Q DHCP機能はどのように実現しているの？
A 登録された情報を元に、dnsmasqというOSSを用いて管理しています。

Q ロードバランサー機能はどのように実現しているの？
A 登録された情報をHAProxyに設定することで実現しています。 　

Q VPN機能はどのように実現しているの？
A IPsecを用いて実現しています。

仮想ルーターの切り替わり

次の状況の時、仮想ルーターのマスターとバックアップが切り替わります。

• ホストサーバーの障害によりマスター側仮想ルーターがダウンした時
• マスター側仮想ルーターの過負荷やホストサーバーの過負荷によるVRRP応答遅延が発生した時
• メンテナンス等による切替（マスター側仮想ルーターの任意停止）の時

具体的な切り替わりの仕組みとしては、conntrackdというOSSのツールにより、マスター側のセッションがバックアップ側に同期されます。なので、切り替わりが発生しても、マスター側仮想ルーターのコネクションは維持されます。切替発生時は数秒で切り替わるため、体感ではほとんど気が付かないのですが、監視システム等では不応答を検知することがありますのでご注意ください。

なお、一度切替わった仮想ルーターは切り戻しを行っておりません。Mackerelで監視していた場合は、バックアップに切り替わると監視できなくなってしまうので、お手数ですが再度Mackerelエージェントをインストールする必要があります。現在のマスターとバックアップの状況は、図1のようにネットワークメニューの仮想ルーター管理タブにて確認することができます。

▲図1 仮想ルーターの管理画面

仮想ルーターの性能、制限

続きまして仮想ルーターの性能および制限について紹介します。仮想ルーターは、パケットの転送が主な動作となるので、通常、負荷はそれほど上がりません。仮想ルーターが処理できるトラフィックは、仮想マシンのNICの制約上最大2Gbpsとなっています。フロントのWEBサーバーが1台で構成されているようなシステムであれば、突発的なアクセスがあった場合でも、仮想ルーターがダウンするより先に、サーバー側がリソースを使い果たしてしまうので、仮想ルーターがボトルネックになることはあまりないです。

ただし、ロードバランサー機能を利用している場合は条件が異なってきます。多量のバランシング設定や、大量トラフィック流入があった場合に、HAProxyプロセスの過負荷や各種リソース制限によって、思うように性能が出ない場合があります。ロードバランサー機能（HAProxy）における最大同時接続数（Max Connection）は1つのバランシングルールにつき2,000、合計最大10,000となっています。また、HAProxyプロセスは比較的CPU利用量が多いので、仮想ルーターがCPUリソース不足に陥ってしまうことがあります。なので、同時接続数とCPU使用率両方を考慮する必要があります。

ロードバランサー機能はIDCFクラウドの画面よりお手軽に設定できて便利ですが、簡易的なものであるため、管理するシステムの数（バランシングルールの数）が少なく、数台のフロントサーバーに対し分散する場合にお勧めです。一方で、大量のトラフィック流入や多数のアクセスが見込まれる場合は、別の方法でロードバランシングを実現することで、仮想ルーターのロードバランサー機能がボトルネックとなることを回避することができます。例えば、ILBサービスをご利用いただいたり、内部にロードバランシング専用のLVSを構築していただいているお客様がいらっしゃいます。

その他にも、システムの構成変更でも対応可能です。構成については次のセクションでご紹介します。

お勧め構成例

ソーシャルゲーム等の、大量のアクセスを捌く必要のあるサービスや、複数のシステムをまとめて構築されている場合等は、仮想ルーターの性能がボトルネックになってしまうことがあります。そういった仮想ルーターがボトルネックとならないような構成をご紹介して、本稿の結びとしたいと思います。

コネクション数過多パターン

イベントなどのアクセス集中により、ロードバランサー機能で対応可能なコネクション数を上回ってしまった場合、コネクションが張れずにクライアントではタイムアウトが発生してしまいます。このような場合はロードバランサー機能を切り離すことで解消することが可能です。

▲仮想ルーターがネックとなっている構成イメージ

▲お勧めの構成イメージ(ILB利用)

▲お勧めの構成イメージ(LVS構築)

ILBやLVSについては、以下の記事を参考にしてみてください。

ILBを使ってWebサーバーをバランシング！構成事例もご紹介 - IDCF テックブログ
IDCFクラウドでkeepalivedを使ったLVS構築(1) - IDCF テックブログ
IDCFクラウドでkeepalivedを使ったLVS構築(2) - IDCF テックブログ

仮想ルーター高負荷パターン

前述しましたが、複数のサービスを立ち上げられる場合など、ロードバランシング設定が多量だと、仮想ルーターのCPUリソースが足らなくなってしまうことがあります。そういった場合には、アカウントを複数に分けてご利用いただき、プライベートコネクトで接続することで、仮想ルーターを分け、ボトルネックになることを回避することが可能です。

▲仮想ルーターがネックとなっている構成イメージ

▲お勧めの構成イメージ

実際、2サイト程度は問題なく処理できるのですが、イメージとして分かりやすいように載せています。ちなみに、ネットワーク転送量3,240GBの無料枠を2アカウント分使えるのも地味にポイントです！

まとめ

以上、仮想ルーターについて、駆け足でのご紹介となりましたが、いかがでしたでしょうか？仮想ルーターの内部がかなりイメージできたのではないかと思います。なお、補足となりますが、パスワードリセットとトラフィック集計機能は、IDCFクラウド独自の仕組み（shスクリプト等）で動いています。また、稀に質問される名前解決については、IDCFクラウドの標準リゾルバサーバーが指定されております。

仮想ルーターについて、普段は意識することの無いようにできているのですが、IDCFクラウドを使い倒す！となると考慮する部分が出てきます。仮想ルーターでできることやできないことは明確に分かれているため、物足りない時はぜひ先ほど紹介したILBも検討してみてください。

この記事が面白い！と感じたら、豆知識講座第1回のテンプレート編もぜひ読んでみてください。では、皆様、よきIDCFクラウドライフをお楽しみください！

みなさん、はじめまして。クラウド料金シミュレーションのリニューアルを担当しました小林です。
今回はこのリニューアルしたクラウド料金シミュレーションの便利な活用法をご紹介するとともに、リニューアルにあたってのこだわりも語ります！
ブログの最後に、期間限定のお得なキャンペーン情報がありますのでお楽しみに！

クラウドにおける料金シミュレーションの重要性

クラウドサーバーは、ついつい使いすぎて月末の請求を見てビックリってことありますよね。機能も複雑で、何にどれくらいのコストがかかるかわからないことも多いので、不安に思うこともあります。
そこで活躍するのが料金シミュレーションです。いくつかの条件をもとに試算することで、事前に料金を把握することが可能です。そうすれば、月末の請求を見ても驚くことや、不安になることもなくなるかと思います。料金を把握できるようになれば、請求書の内訳を見てどこにコストがかかったのかを分析し、コスト削減につなげられるようになるのではないでしょうか。

従来のシミュレーションの問題点

従来のシミュレーションでは次の課題がありました。

• IDCFクラウドの一部のサービスしか見積ることができなかったこと
• コンピューティングを必ず含まなければ見積りができなかったこと

こうした課題を踏まえ、従来のシミュレーションでは試算ができなかったプライベートコネクト等のサービスも試算が可能となりました。また、マルチクラウド構成のお客さまや、既存のお客さまが何を求めるのかを考えたときに、オブジェクトストレージや、ネットワークサービスのみのご利用もあるのではないかと思い、コンピューティングを選択しなくても、ほかのサービスのみで見積りできるように改善しました。

UIのこだわり

IDCフロンティアのサイトはレスポンシブデザイン*1を採用しています。
したがって、新しい料金シミュレーションもレスポンシブデザインに対応する必要がありました。（興味のある方は一度ウインドウサイズを動かしていただきレイアウトの変化を試してみてください。）
すべてのデバイスで同じようにご利用いただけるように、レイアウトにはとてもこだわりました。

また、「スペックから選ぶ」画面ではサービス選択メニューを開閉式にすることで、必要な機能のみを表示、余分な設定項目を削除し、見積りしやすくしています。これにより、「従来のシミュレーションの問題点」でも書いたコンピューティング以外のオブジェクトストレージやネットワークサービスのみをご利用のお客さまも使いやすいレイアウトになっているかと思います。
機能の設定項目は、追加も削除もラクラクなので、みなさんどんどんカスタマイズしてみてください。

新料金シミュレーションの特長と活用法

では、いよいよリニューアル後の料金シミュレーションについて見ていきましょう！今回リニューアルした料金シミュレーションの特長は次の3点です。

• 初心者でも簡単に見積りできるように、さまざまなご利用シーンのプランをご用意！
• コンピューティング以外のさまざまなサービスを見積り可能！
• 見積り完了後に発行されるメールに、見積り復元URLを追加！

また、今回の料金シミュレーションでは、ご利用シーンにあわせて「プランから選ぶ」と「スペックから選ぶ」の2種類から試算することが可能となりました。

サーバーのことをよく知らないお客さまでも概算を見積ることができるように、当社エバンジェリスト監修のもと、ECサイト、業務システムなどの実例から代表的な構成をご用意しました。さらにアクセス数の規模からも概算を見積ることができるようになっておりますので、作成したいシステム例をもとに試算したい方は、ぜひ「プランから選ぶ」をご活用ください。

また、従来どおりスペックを細かく見積ることができる機能もパワーアップしています。各サービス単体やサービスを組み合わせての自在な見積りが可能となり、サーバー台数の多い構成のお客さまでも、それぞれのサーバーに名前をつけられることが可能になりましたので、わかりやすい見積り書の作成が可能です。

技術的な質問なども、クラウド料金シミュレーションからお問い合わせいただくことによって、当社技術スタッフから無料のコンサルティングも受けることができますので、お気軽にお問い合わせください。

見積り書を発行した後や、お問い合わせ後に発行されるメールには、見積り復元URLが記載されています。以前見積った内容を流用したい場合や、専門家にアドバイスを求めるときなどご利用いただければと考えております。

期間限定！料金シミュレーション リニューアルキャンペーン開催中

今なら、料金シミュレーションでお見積りまたはお問い合わせいただいた方全員に、1,000円分無料クーポンをプレゼントするキャンペーンを開催中です。詳しくはこちら！↓ www.idcf.jp
※キャンペーン期間　2017年9月6日（水）～10月5日（木）

IDCFクラウドを始めようと考えている方、クラウド料金の見直し・他社比較まで、まずは料金シミュレーションを試してみてください。
テックブログのサイドバーにもバナーが掲載されているのでチェックしてくださいね。

こんにちは、UX開発部の橋口です。

つい先日、『パスワードの専門家が「大文字も数字も記号も意味がなかった』と過去の持論が間違いだったことを認める」(外部サイト)という記事がにぎわせましたが、簡単なパスワードを使っていたり、過去のログインIDやパスワードを使いまわしたりしていませんか？そんなあなたに、パスワードを強固にするだけではなく、もっとセキュリテイを高められる方法をご案内します。

IDCFクラウドには3つのセキュリティオプションがあります。

• ２段階認証
• ログインIP制限
• APIリクエスト元IPアドレス制限

2段階認証

既存のパスワード認証に追加して、代表的な2要素認証方式であるTOTP方式の認証を追加できます。

2段階認証は、スマートフォンにGoogle AuthenticatorやAuthyなどをインストールして、QRコードを読み込むだけで利用可能です。設定が終われば、IDCFクラウドにログインする際に、IDとパスワード入力後にアプリで生成される認証コードを求められるようになります。時刻を元に6桁の認証コードが生成されるため、IDとパスワードを使いまわしている別のサイトで認証情報が流失してしまった場合にも悪意のあるログインを防ぐことが可能です。

2段階認証はIDCFクラウドのユーザーごとに設定ができます。また、アカウントやユーザーごとに2段階認証を必須にすることも可能です。

設定はこちらから→ https://console.idcfcloud.com/user/twofactorauth

スマートフォンの紛失時や水没などで端末が初期化された場合に備えて、臨時のバックアップコードでログインすることもできます。バックアップコードはクラウドコンソールの2段階認証のページから利用状況を確認することが可能で、使用時にはメールが送信されます。

万が一バックアップコードが手元になく、2段階認証ができない場合、お問い合わせベースで対応も可能ですが時間がかかってしまうため、バックアップコードはアクセスしやすいところで保管しておくのがおすすめです。

ログインIP制限

ログインIP制限とは、その名の通り、IDCFクラウドコンソールへのアクセス制御をログイン端末のIPアドレスベースで行えます。

設定はこちらから→ https://console.idcfcloud.com/user/iplimit

設定を間違えるとログインできなくなるので、設定時には別ブラウザでログインできることを確認しましょう。また、ログインに失敗した時にはアクセスログに理由が表示れるので、マルチユーザーを利用している際に、ログインできませんなどの問い合わせにも対応できます。

API IPアドレス制限

IDCFクラウドコンソール以外に、APIアクセス時の送信元IPアドレスを制限することができます。

設定はこちらから→ https://console.idcfcloud.com/user/apikey

現時点ではコンピューティングのみの対応になっており、ILB、DNS、Your(Billing)は非対応ですのでご注意ください。

最後に

アカウントが乗っ取られた場合には、新規にハイスペックな仮想マシンが作成され第三者への攻撃の踏み台とされるだけでなく、ファイアウォールの設定を書き換えられ、稼働中の仮想マシンに設定されている管理者ユーザのパスワードがリセットされ、サーバーのデータが流失し、取得された情報を悪用される恐れがあります。なので、IDCFクラウドアカウントのセキュリティ対策はとても重要です。もし、アカウントが乗っ取られたのではないかと思ったら、サポートか担当営業までご相談ください。

IDCFクラウドでは、セキュリティホワイトペーパー(PDF)や初心者向けのコラムも公開しています、ぜひこの機会にセキュリティ設定を見直してアカウントを乗っ取られないようにしましょう！

はじめまして。クラウドサービスの運用を担当している村上と申します。 普段は主にクラウドをご利用されているお客様のお問い合わせサポート、またFAQやご利用ガイド等のサポートコンテンツの拡充を行っています。 最近ではそのサポートコンテンツ拡充の一環として、「サポートオペレーター」のティアラちゃんの育成活動も行っています。

今回はタイトルにもあるとおり、「サポートオペレーター」ティアラちゃんの育成活動において実際にどのようなことを行っているのか、またその活動において苦労している点についてお話ししたいと思います。 前回のMORIO Dojoのアンバサダー会に参加されていた方にとっては聞いていただいた話とかぶってしまいますが、おさらいも兼ねて最後までお読みいただければ幸いです。

• ティアラちゃんのプロフィール紹介
• ティアラちゃんにはどこから会えるの？
• ティアラちゃんの成長メカニズム
• ティアラちゃんの育成活動について
• まとめ

ティアラちゃんのプロフィール紹介

みなさま、IDCフロンティアのマスコットキャラクターである、井出倉クララ（いでくら くらら）と井出倉ティアラ（いでくら てぃあら）の姉妹については既にご存じですよね？ 当社コーポレートサイトで姉妹の紹介をしているサイトがあるので、可愛い二人をぜひぜひチェックしてみてくださいね。

www.idcf.jp

今回お話したいと思っているのは、しっかり者の頼れる井出倉家の長女、ティアラちゃんについてです。

はじめに、ティアラちゃんのプロフィールを簡単にご紹介します。

名前：井出倉ティアラ（いでくら てぃあら）

年齢：22歳の社会人

身長：166cm　体重：52kg

口癖：「思い出した！」

ティアラちゃんは当社データセンターのマスコットとしても活動していますが、その傍らIDCフロンティアのサービス全般のご質問への対応をする、「サポートオペレーター」としても活動しています。

サポートオペレーターのティアラちゃんは、IDCフロンティアとしては初のチャットボットによるカスタマーサポートサービスを実現したものになります。 今年の4月に運用を開始し、この10月で半年目に突入します。

またティアラちゃんにはサポートレベルが定義されていて、2017年9月末現在でレベル9まで成長しました。 レベル1だった運用開始当初から比べると、少しずつではありますがティアラちゃんは日々成長しています！

サポートオペレーターのティアラちゃんはこのような見た目になっており、質問入力欄に質問を入力すると、ティアラちゃんが対話形式で質問に対する回答を提案してくれます。 チャットボットのメリットとして、質問すると瞬時に回答を出してくれるので早く疑問を解消したいときにはこの速さは嬉しいですよね。

ティアラちゃんにはどこから会えるの？

ところでみなさま、サポートオペレーターのティアラちゃんにはどのようにして会うことができるのかご存じですか？

IDCFクラウドを利用している方であれば、IDCFクラウドコンソールにログイン後、画面右上の[サポート]→[お問い合わせ]から問い合わせチケットを発行する画面にいくと、 画面右上に[ティアラちゃんに聞く]というボタンがあるので、そこからいつでもティアラちゃんに会いに行くことができます。

1. IDCFクラウドコンソールにログインし、画面右上の[サポート]→[お問い合わせ]をクリックします
   

2. お問い合わせ一覧画面の右上にある、[ティアラちゃんに聞く]ボタンをクリックします
   

またはIDCFクラウドページから、先ほど冒頭でご紹介した姉妹紹介サイトの中にもティアラちゃんサイトへのリンクが貼ってあるので、そこからも会いに行くことが可能です。

もしよろしければ、ティアラちゃんのページをよくご利用されるブラウザにブックマークしていただけると嬉しいです！

ティアラちゃんの成長メカニズム

みなさま、一度はティアラちゃんとお話してみたことはありますでしょうか？　ある方もない方も、是非たくさんお話してあげて欲しいです！

なぜティアラちゃんにたくさんお話して欲しいかというと、ティアラちゃんはユーザーの方にご利用いただければいただくほど経験値が上がり、成長するからです。 ティアラちゃんは、質問に回答した後、みなさまからの「大丈夫」「ちょっと違う」ボタンを押していただく度に経験値が加算されます。そして経験値バーがMAXになるとサポートレベルが1つずつアップしていきます。

つまりみなさまからたくさんの質問・フィードバック（「大丈夫」「ちょっと違う」ボタンのクリック）をしていただくほど、ティアラちゃんの成長につながるのです。

また、みなさまに質問・フィードバックをしていただくことは、次項でもお話しするティアラちゃんの育成活動においても非常に重要なものになっています。

ティアラちゃんの育成活動について

そして私は、ティアラちゃんがサポートオペレーターとしてみなさまのお困りごとを素早く解決できるようティアラちゃんの育成を担当しています。

具体的にどういう育成をしているかというと、みなさまから寄せられた質問の内容に対してティアラちゃんがどういった回答を返しているのか、 またその回答が適切な回答だったのかどうかをフィードバックログから確認し、ご満足いただけなかった回答については私が手動で改善をしています。

たとえば、そもそもティアラちゃんでも回答を持っていない質問内容だったのであれば新しく回答データを作成してあげたり、ティアラちゃんも回答を持っているはずのに的外れな回答をしているのであれ適切な回答を返すことができるようにチューニングしたりしています。 なので育成活動のためにもみなさまからのたくさんのご質問・回答に対しての清きフィードバックがとても大切なのです！

実際私が育成のために使用しているフィードバックログのイメージは、次のようになっています。 たとえばこのログの中に同じ質問に対して3回NGとなっている箇所があります。

ティアラちゃんは一回の質問に対して、3回まで回答を提案してくれます。 つまり先の例では、ティアラちゃんの回答が質問したユーザーにとって3回とも「ちょっと違う」、つまりユーザー意図にまったく合っていない回答であったということで読み取ることができます。

続いてティアラちゃんが具体的にどういった内容の回答をしていて、ユーザーから「ちょっと違う」と言われてしまったのかを紐解いていきます。 先ほどと同様にフィードバックログを参照します。

ティアラちゃんが持っている回答データには、一つ一つにアンサーIDというものが一意で付与されているのでそこから実際の回答内容の中身を見ていきます。

その結果、まったく的外れな回答をしているようであれば適切な回答を持っていないかティアラちゃん回答データ一覧の中から探します。 もし適切な回答を持っていないようであれば、新規に回答データを作成しティアラちゃんに教えて（データ入力して）あげます。

またユーザーの質問の仕方にもさまざまなものがあると想定されます。たとえば「仮想ルーター」を「VR」と呼ぶ人もいれば、「バーチャルルーター」と呼ぶ人もいます。 このような表記ゆれが想定される単語は予め質問の「キーワード」として登録することもでき、異なる表現でも同義であればティアラちゃんが認識できるようにしています。 キーワード登録は単語に限らず、例えば「仮想ルーター"とは？"」と「仮想ルーター"の意味を教えて"」という末尾の表現に関しても登録可能です。

このキーワード登録を活用して、先のフィードバックログ分析で実は回答を持っているのにうまく導き出せていないとわかったものについては、 その質問に含まれているキーワードを適切な回答データに登録・紐付けし、次回に類似の質問をされたときにはその回答を表示させることができるような工夫もしています。

このような地道な作業…いえ育成活動をおこなっているのですが、現状まだまだティアラちゃんの回答率はあまり高くなく、育て親としてはなかなか苦労しているところです。

まとめ

ティアラちゃんはもうすぐ半年目になりますが、まだまだお世辞にも完璧なサポートオペレーターとは言えず、みなさまの疑問をスムーズに解決できるようになるためにはさらに努力を積み重ねる必要があると考えています。 しかしそのためには、ユーザーのみなさまによりティアラちゃんを活用いただき、フィードバックをたくさんいただくことが非常に重要になってくるのです。

是非ともこの記事を見てくださったみなさま、今日からIDCフロンティアサービスに関して何かわからないことがあったら、まずはティアラちゃんに質問してみてあげてください。 もちろんティアラちゃんで解決できない疑問については、IDCFクラウドであればお問い合わせチケットなどからお問合わせいただくことで、人間のオペレーターによる手厚いサポートを受けることも可能ですので、こちらも遠慮なく活用してください。将来的にはユーザーのすべての疑問をティアラちゃんがすべて回答できるようになることが目標です！

また、この記事をみてティアラちゃんの育成にアドバイスをいただける方も大歓迎しております！ チャットボットを開発されている方、もしくは他社のAIやチャットボットを使っている方など、よろしければテックブログのコメント欄にお気づきの点やアドバイスをいただけるととても嬉しいです。

はじめまして、永岡と申します！
テックブログを通してみなさまにIDCFクラウドの良さをどんどんお伝えしていきたいと思います！

今回は、セキュリティ面やSEOの観点から様々な企業でも対応が進んでいる常時SSL化がなぜ求められてきているのか、またIDCFサービスを使用した対応方法をご紹介したいと思います！

• 常時SSL化ってなに？
• なぜ対応が求められているのか？
• 常時SSL化時の課題点とIDCFでの対策
  • 「ILB」を使って証明書の導入、更新時の手間を効率化
  • 「コンテンツキャッシュ」を使って負荷を軽減
• まとめ

常時SSL化ってなに？

常時SSL化とはすべてのWebページを暗号化(SSL/TLS化）するセキュリティ手法のことでAOSSL(Always On SSL)とも呼ばれています。 通常ログインページなどの特定ページのみを暗号化しますが、すべてのページを暗号化することでCookieなどの情報も暗号化され、盗聴されにくくなります。
また、常時SSL化を行うことで次の3点を守ることができます。

1.機密性
すべてのページで通信が暗号化されます。
通信内容を盗聴されにくくなり、情報の機密性を守ることができます。
2.完全性
通信を暗号化することにより、データの改ざんがされにくくなりデータの完全性を守ることができます。
3.サイトの実在性
常時SSL化する際に、証明書が必要になります。証明書によって通信相手が正しく存在していることを証明できます。サイトの実在性が取れることにより、フィッシング対策にもなります。

このように、常時SSL化を行うことでサイトのセキュリティを強化することができます。
また、サイトの実在性が取れることでユーザーが安心して通信を行え、結果としてサイトの信頼性向上にも繋がります。

なぜ対応が求められているのか？

常時SSL化に対応することでユーザーが安全に通信を行えたり、個人情報の盗難を防ぐことができることはお分かりいただけたと思います。

ではみなさん、「個人情報」と聞いてどのようなキーワードが思い浮かぶでしょうか？
多くの方は「名前」、「電話番号」、「住所」などを思い浮かべると思います。
しかし、これらの情報だけが個人情報ではなく、 ユーザーとWebサイトがやり取りしているCookieや履歴などの情報も立派な個人情報として認識する必要があります。

近年、カフェや空港などでも公共の無線LANが普及してきており、とても便利になってきました。
しかし、中にはパスワードが不要な無線LANなどがあります。
暗号化されていない公共の無線LANから、悪意のある第三者により次のような被害にあう危険性があります。

・盗聴、なりすましによる個人情報流出や、盗聴した情報を使ってページの改ざん
・偽のWebページを用意し個人情報などを入力させ詐取する「フィッシング詐欺」などネット上での犯罪　　

このようなユーザーの個人情報やWebページの運営側の信頼性低下を回避するため、サーバー側での対策として常時SSL化が求められてきています。

また、SEOの観点からも常時SSL化対応を促す動きが起きています。

2014年8月にGoogleから「HTTPS（暗号化通信)をランキングシグナルにします」という発言がありました。
これは「HTTPS(暗号化通信)しているかどうかを検索ランキング順位決めの判断基準としますよ」という意味です。 また、入力フォームがあるページではHTTPS化していないと「このページは保護されていません」という警告文が表示されるようになりました。
常時SSL化を行っていないと検索ランキングの低下や警告文の表示による信頼性の低下などのデメリットが生じるようになり、これを機に多くの企業で対応されるようになってきています。

これらの背景によって、常時SSL化はユーザーを守るだけではなく、Webページの運営側も守るために必要であり、求められてきています。

常時SSL化時の課題点とIDCFでの対策

セキュリティ強化や信頼性の向上などと多くのメリットがある常時SSL化ですが、導入時に証明書のコストや手間がかかったり、通信時に暗号化(SSL/TLS化)するためサーバーへの負荷が増えレスポンスが遅くなる...というデメリットも存在します。

このようなデメリットを感じ「まだ対応しなくても大丈夫だろう...」とあと一歩常時SSL化へ踏み出せない方もいらっしゃるのではないでしょうか。
そんなみなさま！IDCFサービスを使えばこのようなデメリットを改善し、常時SSL化に対応させることが可能です！今回はILBとコンテンツキャッシュの2通りの方法をご紹介します。

「ILB」を使って証明書の導入、更新時の手間を効率化

ILBを使用し、証明書の管理方法を工夫することで導入、更新時の手間を効率化できます。

基本的に証明書の管理方法として

・各サーバーごとで管理する方法
・証明書用管理サーバーを立て管理する方法
・ロードバランサ―に集約させ管理する方法

があると思います。
「証明書用管理サーバーを立て管理する方法」、「ロードバランサ―に集約させ管理する方法」は一箇所で管理するだけで済むため各サーバーで管理するよりも作業効率がいいです。 しかし、大量のトラフィックが流れてきたときに処理が追いつかずボトルネックとなってしまうケースがあります。

そこで、IDCFサービスのILB(Infinite Load Balancer)に証明書を集約させることで、導入や更新時の手間を格段に効率化することができます。
ILBはIDCFクラウドで動作するロードバランサーで、証明書を集約できるほか、トラフィック流量に応じてオートスケールアウト/インを行います。
また、通常のロードバランサ―に比べ処理が約10倍の性能*1なので手間なく証明書集約によるボトルネックを防ぐことができ安定した運用が可能になります。
ILBでは証明書を終端させる機能のみを使用しバランシング機能は使わないという使用方法もできますので、 現在使っているサーバー構成を変えずに常時SSL化したりなど要望に沿った使い方が可能です。

www.idcf.jp

＜「ILB」の関連記事＞

■ILBを使ってWebサーバーをバランシング！構成事例もご紹介 - IDCF テックブログ

■超簡単〜ILBをMackerelで監視してみよう - IDCF テックブログ

*1 計測ツール：Apach Bench 2.3 / リクエスト回数:100,000回 / 同時コネクション数：2,000 / ファイルサイズ:32KB

「コンテンツキャッシュ」を使って負荷を軽減

また、コンテンツキャッシュを使用し暗号化通信によるサーバーへの負荷を軽減することで、レスポンスタイムの低下を防ぐことができます。

常時SSL化はすべてのページを暗号化するため、HTTPで通信するよりサーバーやロードバランサ―に負荷がかかりレスポンスタイムが遅くなってしまうことがあります。 レスポンスタイムが遅くなってしまうとユーザーが快適にWebページを閲覧することができなくなり結果的にページから離脱してしまうかもしれません。

そこでIDCFのコンテンツキャッシュというコンテンツ配信サービス使うことでサーバーやロードバランサーのSSL処理の負荷を軽減させることができます。 さらに、HTTPと同等費用でHTTPS化を簡単に行うことができます。

www.idcf.jp

＜「コンテンツキャッシュ」の関連記事＞

■IDCフロンティアのコンテンツキャッシュサービスを使ってコンテンツを高速配信！ - IDCF テックブログ

■コンテンツキャッシュの2つの新機能について - IDCF テックブログ

このように、IDCFのサービスを使用することでそれぞれの構成や要望に合わせたサービスを選び常時SSL化することができます！

まとめ

ユーザーに安心してサイトを利用してもらえるように、運営側がWebページのセキュリティを高める手段として常時SSL化は求められています。 今後もどんどん常時SSL化の動きは加速していくと予想され、HTTPSページが当たり前になる日もそう遠くないのかもしれません。
ただ、流されるままに対応するのではなく本当に対応する必要があるのか、 対応するならどの証明書がベストなのかなどサイトに合った対応方法をしっかりと考えることが重要だと思います。

今回は常時SSL化についてイベントで登壇した際の資料をベースとしています。 本記事の内容に加え、事例などを用いた対応方法も紹介していますので是非みなさまのご参考になればと思います。

はじめまして。データビジネス本部の木村です。普段は福岡オフィスで Python の機械学習系のライブラリを使ったデータ分析・予測モデルの構築を行っています。

IDCF は今年、高齢者介護施設においてIoTセンサーとデータ分析技術を活用し、機械学習による介護/看護職員の行動認識・業務分析を実証実験として実施しました。今回はその実証実験について、技術視点でお伝えしたいと思います。

Contents:

• 実験フィールドは「介護現場」
• 実験の目的は「職員の業務効率化」
• 要素技術
  • 全体構成
  • IoT デバイス
  • スマートフォン
  • サーバーサイド
• IDCF の役割
• 行動ラベル分析
  • 作業時間の分布
  • 作業項目ごとの平均作業時間とトータルの実施回数
  • 1回あたりの作業時間と職員属性の関係
• 機械学習による行動認識
• まとめと課題

実験フィールドは「介護現場」

このプロジェクトは、福岡県を中心に全国で84施設の介護施設を運営する株式会社さわやか倶楽部さん、九州工業大学、 IDCF の合同で行われた実証実験です。 IoT デバイスを使ったセンシングと機械学習により、施設の職員の方々の行動認識を行いました。

実験フィールドは、福岡県北九州市にある定員65名の介護付き有料老人ホームです。それなりに大きな介護施設で、利用者の方々も職員の方々もたくさんいらっしゃいます。実験時は介護士の方が22名、看護師の方が5名でした。

実験の目的は「職員の業務効率化」

職員の方々は、日々の業務を手書きで記録しています。記録業務は、業務時間全体で大きなウェイトを占めています。そこで、実験ではセンシングと機械学習により行動認識を行い、業務を推定することで記録業務を自動化したいというねらいがありました。また、行動認識により「いつ」「どこで」「誰が」「何を」していたかを蓄積することで、職員の業務負担を可視化して忙しい時間と場所にリソースを分配するなど、介護業務の効率化・品質向上を図るねらいもありました。今回は実証実験として、各手法が「本当に業務効率化の役に立つか？」にフォーカスしています。 IDCF としては、センシング技術や機械学習技術の習得をしたい、というねらいもあります。

行動認識をする上で業務をカテゴリ化する必要がありました。実験では介護・看護という職種で分割し、「食事介助」「服薬介助」「トイレ介助」など、それぞれ25種類程度の業務に分割しました。介護・看護の業務は重複があるので、全体で31種類の業務が定義されました。行動認識では、その業務のうちどれを実施してたかを機械学習で予測します。

要素技術

全体構成

全体の構成は次のようになりました。

施設の壁などに設置される「環境センサー」と、職員のあたりに装着される「スタッフセンサー」により温度、湿度、加速度などのデータを取得します。取得データは BLE (Bluetooth Low Energy)通信により職員が携帯しているスマートフォンに送られます。センサーデバイスだけでなく、スマートフォンに搭載されているセンサーのデータも付加されます。データは Wi-Fi ルーター経由でサーバーにアップロードされます。サーバーサイドのアプリケーションは、 IDCFクラウド上の OpenShift という PaaS 基盤の上で動作します。そこで認証、データクレンジングが行われ、センサーデータは トレジャーデータサービス by IDCFに格納されます。バッチ処理により機械学習アプリケーションが実行され、その日の職員の行動が予測として出てきます。また、センサーデータとは別に、職員の手入力による行動ログも記録されます。このデータは機械学習の教師データとして利用します。

IoT デバイス

「環境センサー」と「スタッフセンサー」は同じデバイスを使っています。Texas Instruments 社の SimpleLink SensorTag というデバイスです。

CC2650STK SimpleLink SensorTag | TIJ.co.jp

「温湿度センサー」「周辺光センサー」「赤外線温度センサー」「加速度、ジャイロセンサー」「気圧センサー」が搭載されており、 BLE 通信によりスマートフォンなどのデバイスとの連携が可能です。

スマートフォン

デバイスは FREETEL の Priori3 という端末を使いました。この実験ではスマートフォンの役割は2つあります。ひとつはセンサーデータの集計とアップロードで、もうひとつは業務記録の集積です。

センサーデータの取り扱いは、九州工業大学の井上研究室の方々が開発した InuLog というアプリケーションを使います。このアプリケーションは主に以下の5つの機能を持っています。

1. スマホ搭載センサーのデータ取得
   • 加速度、地磁気、方位、角速度、照度
2. センサーデバイス(SensorTag)のID取得
   • 設置場所情報として利用
3. マルチスレッドによるセンサーデータ取得
   • 同時並行で複数のデバイスの複数のセンサー種に接続・データ取得
4. 自動ログイン
   • 定期的にログイン実行、セッション切れに対応
5. バッファ関連機能
   • バックグラウンド実行を継続
   • 端末再起動後もアプリが起動
   • ネットワークが中断しても確実に1回アップロード

業務記録の入力には、サードパーティの aTimeLogger というアプリケーションを利用しました。あらかじめ登録しておいた行動を手動で登録することができます。開始時と終了時に画面をタップすることで、いつ何をしていたかを記録します。入力した行動データはあとから修正可能になっています。クラウド機能もあり、 app.atimelogger.com と自動で同期するようになっています。同期された行動履歴情報はAPIで取得することができます。

サーバーサイド

サーバーサイドアプリケーションの役割は認証、データの加工、機械学習による行動認識です。

まず Ruby on Rails アプリでデータを受け、クライアントの認証を行い、それを次の Node.js アプリに投げます。そこでは簡単なデータの加工やクレンジングを行います。空データをはじいたり、タイムスタンプのフォーマットの表記ゆれを修正したりします。クレンジングされたデータは トレジャーデータサービス by IDCFに保存されます。

aTimeLogger に保存されたデータは、バッチ処理により定期的に PostgreSQL にコピーされます。このデータと トレジャーデータサービス by IDCFに保存されたセンサーデータをもとに機械学習を行います。機械学習のロジックは R で書かれており、 k-最近傍法という手法をコアに実装され、行動のクラスタリングを行います。

IDCF の役割

開発フェーズではサーバーサイドの技術選定と実装、運用・実験フェーズではデータの可視化、分析レポートの作成などを行いました。

1. データフローの設計、構築
   • 要件･実験フェーズにあわせた技術選定
2. コンテナベースのアプリ群を OpenShift 上にデプロイ
   • 試行錯誤･探索型の開発プロセスに対応
3. BIツールによる 行動データ･センサーデータの可視化
   • Re:dash による可視化環境の構築･運用
4. 分析レポート作成
   • 行動ラベルデータと職員属性を比較した分析レポートの作成

行動ラベル分析

実証実験の主なねらいは行動認識による自動予測です。しかし、せっかく手入力の業務記録を集積したのに、機械学習に使うだけではもったいないですよね。このデータを使って業務分析をやってみました。

作業時間の分布

まずは各作業の完了時間でヒストグラム化してみました。10分以内で終わる作業が一番多いことがわかりますね。これだけでも、介護業務が細切れのタスクがたくさんある、ということがわかります。

作業項目ごとの平均作業時間とトータルの実施回数

縦軸を平均作業時間、横軸を総実施回数としてマッピングしてみました。「トイレ介助」は1回あたりの作業時間は長くないが頻度は最も高い、など各作業の特性がわかりますね。

1回あたりの作業時間と職員属性の関係

経験の長さと作業時間にはなにか関係があるのでは？と思い、縦軸を1回あたりの作業時間(中央値)、横軸を経験(年)として各職員をプロットしました。また、職員の持っている資格によってグループ分けしてあります。プロットされた各点の数字はデータ上の識別番号で、意味はありません。

これを見る限りでは、経験年数や資格で1回あたりの作業時間に差がある、ということはなさそうです。これは、各業務が標準化されて職員の経験によって差がでにくいようになっていると言えるのかもしれません。

中央値や平均値では差はありませんでしたが、もっとよく調べてみると作業時間の「ばらつき」には資格の有無で差がありそう、ということがわかってきました。より高度な資格を持っている職員ほどばらつきが多いようです。つまり、短時間で終わる作業は全職員が行うが、高度な資格を持っている職員は比較的長時間の作業をする必要がある、ということでしょう。このあたりは、さらに踏み込んだ調査が必要になりそうです。

機械学習による行動認識

さて、機械学習による行動認識の精度はいかほどだったでしょうか。

通常、行動認識を行う場合は「その瞬間何をしていたか」あるいは時間を一定のセグメントに区切って「各セグメントで何をしていたか」を認識するシンプルなクラスタリングを行います。しかし、今回は「開始・終了時刻の予測」と「その期間何をしていたか」を同時に予測します。また、介護業務では並行作業もあるため、さらに複雑になります。

精度評価は、「開始時刻の予測精度」と「継続時間の予測精度」別々で行います。時刻や時間の精度を秒単位で行うのは大変むずかしいので、ある程度マージンを持たせて、精度評価を行っています。また、さらに作業項目ごとにわけて評価を行っています。

まずは「開始時刻の予測精度」です。

マージンは3時間としています。つまり、誤差が3時間以内なら認識成功としています。「朝礼」や「休憩」などの精度の高い項目を除き、あまり高い精度で予測できていないことがわかります。

次に「継続時間の予測精度」です。

継続時間予測では、10分の誤差を認識成功として評価しています。開始時刻予測に比べれば高い精度が出ていることがわかります。

まとめと課題

介護現場での IoT と機械学習による行動認識実証実験についてお伝えしました。センサータグとスマートフォンによりデータを収集し、機械学習による行動認識を試みました。一方でラベルデータとして収集した行動ログを分析し、職員の方々の作業傾向の可視化を行いました。

センサータグについては、故障や電池切れによる現地作業が頻繁に発生し、データの安定収集に課題があることがわかりました。スマートフォンでの作業実績の記録については、職員の方々のリテラシーに課題が見られました。普段スマートフォンを使っていない方が多くいらっしゃったようで、入力に苦戦していたようでした。

行動ログの分析については、誰がどんな作業をしているか、感覚に頼って予測していたものを定量的に可視化することができました。それにより、作業負荷が高いフロアや時間帯にパート職員の方を配置する、定時作業を比較的作業の少ない時間帯にずらす、などの対応策が可能となりました。職員のみなさんの業務を定量的に見える化することで、介護業務の効率化と品質向上に貢献することが原理的には可能であることを示すことができたと思っています。

一方で、機械学習による行動認識の精度には課題があります。継続時間予測はそれなりの精度が出ていますが、開始時刻の予測に難があります。この精度では予測結果をそのまま業務記録として使うことは難しいでしょう。精度向上のためには、アルゴリズムの見直しだけでなく、センサーデバイス側の改善も必要です。例えば、今回は職員の位置情報の予測には環境センサーのデバイスIDを使っていましたが、ビーコンを使ってより正確な位置の把握をすべきでしょう。また、センサーデバイスを増やすことで精度向上につながると考えられます。高い精度の行動認識システムを構築できれば、職員のみなさんが手入力することなく行動ログの集積と分析を行うことができます。きっと業務の効率化と品質向上につながることでしょう。

今回の実証実験の内容は、プレスリリースでも公開しており、日経新聞さんにも取り上げていただいています。また、「介護施設における介護スタッフの行動センシング実験」というタイトルで研究会発表、論文執筆も行っています。詳細が気になる方は、ぜひそちらもご確認ください。

• プレスリリース: ウチヤマホールディングス、九州工業大学、IDCフロンティア、介護施設従事者のIoTによる行動認識実証実験を実施
• 介護現場センサーで分析　ウチヤマＨＤなど　効率化、書類記録カギ　　：日本経済新聞
• 介護施設における介護スタッフの行動センシング実験 - 情報処理学会 電子図書館

普段は IDCF クラウド関連の記事が多いこのテックブログですが、今回は一味違った内容をお届けできたと思っています。 IDCF といえばクラウドやデータセンターなど、 IT インフラのイメージが強い方もいらっしゃるかもしれませんが、 IoT やビッグデータ、機械学習などのキーワードを中心に新規ビジネスの開拓も常に行っています。もし、この分野で活躍したいエンジニアがいらっしゃいましたら、ぜひ採用ページからご応募ください！ OSS を中心とした最新技術の調査・検証を行いながら、新たなビジネスを創るチャレンジングな職場です。インフラ、ミドルウェア、サーバーサイドアプリケーション、 Web フロントエンド、機械学習・分析、どのレイヤーのエンジニアでも強みを活かして貢献することができます！

データ分析系サービス開発エンジニア・プログラマ募集要項 IDCフロンティア中途採用

こんにちは、金杉です。

GPUを使って機械学習をするとき、リソースや開発で課題を抱えている人は多いのではないでしょうか。個人でGPUを所有していたり、学習時間にあまりこだわらなければ問題ないと思います。しかし、本格的なDeep Learningをやろうとすると、プロジェクト間で同じGPUを共有するケースや、複数の環境で学習をさせるなど、リソースプランニングをしっかりやる必要があります。クラウド型GPUを利用になるのであれば多少楽になるものの、CUDA環境やアプリケーションを都度インストールするのも手間ですよね。

そんなリソースが限られたなかで開発を効率化するために、今回はnvidia-dockerを使ってDeep Learningをコンテナで動かす方法を紹介したいと思います。

• Issue
• nvidia-dockerとは
• 環境構築
  • 今回の環境
  • 1. GPUドライバのインストール
  • 2. Docker環境インストール
  • 3. nvidia-dockerインストール
    • nvidia-docker 1.0.1
    • nvidia-docker 2.0
• サンプル実行
• イメージの保存
  • リポジトリを使う場合
  • リポジトリを使わない場合
• まとめ

※このブログはnvidia-dockerの公式ドキュメントを参考にしています。

Issue

冒頭でも簡単に言及しましたが、Deep Learningを本格的に進めるにはさまざまな課題があります。

• チーム内で開発環境の共有が必要
• ライブラリやツールのバージョン管理が煩雑
• ドライバや開発環境の都度デプロイが手間
• 自社所有のGPUとクラウドGPUなど、複数環境を使い分けしたい
• 複数GPUを同サーバーに搭載しており、無駄が発生する

これらを解決するには、GPUの抽象化(コンテナ化)が向いています。モビリティが格段に向上する他、アプリケーションの共有や構築が簡単になり、結果的にコストダウンにも繋がります。GPUのコンテナ化にはいくつかの選択肢がありますが、Dockerが一番汎用的なので、今回はnvidia-dockerにフォーカスします。

nvidia-dockerとは

nvidia-dockerはNVIDIAのハードウェアを活用できるGPUコンテナを自動で認識し、セットアップできるようなToolkitを搭載した、DockerをラッピングしたCLI（プラグイン）です。NVIDIA社により開発されています。

Dockerについてはご存知、もしくはすでにご利用されているかたが多いと思います。Dockerの一番の特長としてあげられるのは、ハードウェアやプラットフォームへの依存性がないという点です。しかし、GPUは専用ハードウェアのため、利用になるには専用のドライバが必要です。よって、従来のDockerからはGPUリソースが認識できず、GPUのコンテナ化はできませんでした。ホストOSとコンテナの両サイドにドライバをインストールするという手段もありますが、その場合両方のドライバのバージョンが同じである必要があり、Docker本来の利便性を失ってしまいます。

上記を解決するために、nvidia-dockerはホストOSにGPUドライバを持たせ、コンテナ側にCUDA Toolkitを持たせ、コンテナイメージをドライバに依存しない形を実現しました。

▲ nvidia-docker利用イメージ図
出典 https://github.com/NVIDIA/nvidia-docker/tree/2.0

環境構築

nvidia-dockerを動作させるには、次の3つのコンポーネントをインストールする必要があります。

1. GPUドライバ
2. Docker
3. nvidia-docker

今回の環境

nvidia-dockerを使う際、ホスト側のドライバのバージョン、コンテナのToolkitのバージョンとGPUのアーキテクチャの関係性についてはこちらのページをご参考ください。基本的にホスト側のドライバは新しいバージョンにしておくのが推奨です。コンテナ側のCUDA Toolkitは使うフレームワークやアプリケーションに依存すると思うので、その都度最適なバージョンを選択するのが良いです。今回は動かすTensorFlowのサンプルの関係で、ホスト側にはCUDA Toolkit 9.0を搭載させているのに対し、イメージでは8.0を選択しています。

1. GPUドライバのインストール

NVIDIA公式のダウンロードページより、GPUのタイプやOSが選択できます。

以下はホスト側での作業です。

OSアップデートを実施
# apt update && apt upgrade -y && reboot
# apt-get install -y gcc

# wget http://us.download.nvidia.com/tesla/384.81/nvidia-diag-driver-local-repo-ubuntu1604-384.81_1.0-1_amd64.deb
# dpkg -i nvidia-diag-driver-local-repo-ubuntu1604-384.81_1.0-1_amd64.deb

# apt-get update 
# apt-get install -y cuda-drivers
# reboot

2. Docker環境インストール

Docker CEの公式ページの手順です。

以下はホスト側での作業です。

# apt-get install -y apt-transport-https ca-certificates curl software-properties-common
# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
# apt-key fingerprint 0EBFCD88
pub   4096R/0EBFCD88 2017-02-22
      Key fingerprint = 9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
uid                  Docker Release (CE deb) <docker@docker.com>
sub   4096R/F273FCD8 2017-02-22

# add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

# apt-get update
# apt-get install -y docker-ce

テスト
# docker run hello-world

3. nvidia-dockerインストール

現在はバージョン1.0が主流ですが、バージョン2.0もαテストとして公開されています。今回は1.0を使いますが、2.0のインストール方法についても軽く紹介します。

nvidia-docker 1.0.1

nvidia-dockerの公式Wikiです。

以下はホスト側での作業です。

# wget -P /tmp https://github.com/NVIDIA/nvidia-docker/releases/download/v1.0.1/nvidia-docker_1.0.1-1_amd64.deb
# dpkg -i /tmp/nvidia-docker*.deb && rm /tmp/nvidia-docker*.deb

GPUが正しく認識されていればインストール成功です  
# nvidia-docker run --rm nvidia/cuda nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.81                 Driver Version: 384.81                    |
|-------------------------------+----------------------+----------------------+
| 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  | 00000000:14:00.0 Off |                    0 |
| N/A   41C    P0    57W / 250W |     11MiB / 22939MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

nvidia-docker 2.0

公式wikiを参考に、nvidia-docker 2.0のメリットを紹介します。

• Docker CLIのラッピングが不要になった (nvidia-dockerコマンドではなく、標準のdockerコマンドが使えるようになった)
• デーモンを新たにスタートさせる必要がなくなった
• GPUアイソレーションが環境変数NVIDIA_VISIBLE_DEVICESでできるようになった
• 公式のCUDAイメージだけでなく、すべてのDockerイメージからGPUを認識できるようになった
• CentOSとUbuntu向けにパッケージリポジトリが用意された
• libnvidia-containerに基づいた新たな実装方法になった

バージョン2.0をインストールする際は、バージョン1.0で起動しているすべてのコンテナを停止し、削除する必要があります。また、1.0のパッケージも完全に削除する必要があるのでご注意ください。

以下はホスト側での作業です。

リポジトリを入れる
# curl -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
# sudo tee /etc/apt/sources.list.d/nvidia-docker.list <<< \
"deb https://nvidia.github.io/libnvidia-container/ubuntu16.04/amd64 /
deb https://nvidia.github.io/nvidia-container-runtime/ubuntu16.04/amd64 /
deb https://nvidia.github.io/nvidia-docker/ubuntu16.04/amd64 /"

# apt-get update
# apt-get install -y nvidia-docker2

dockerコマンドでコンテナを起動する際にnvidia runtimeを指定します
# docker run --runtime=nvidia --rm nvidia/cuda nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.81                 Driver Version: 384.81                    |
|-------------------------------+----------------------+----------------------+
| 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  | 00000000:14:00.0 Off |                    0 |
| N/A   38C    P0    63W / 250W |      0MiB / 22939MiB |    100%      Default |
+-------------------------------+----------------------+----------------------+

サンプル実行

それでは、必要なソフトウェアが一通り揃ったので、試しにコンテナを起動してTensorFlowのCIFAR-10を動かしてみます。CIFAR-10は機械学習のなかでもよく使われるベンチマークの例題で、学習のアウトプットはRGB 32×32ピクセルの画像を10個のカテゴリ（飛行機、犬、猫など）に分類できるCNNです。

以下はホスト側での作業です。

コンテナ起動、NVIDIAが提供しているcuDNNがプリインストールされているイメージを使用  
# nvidia-docker run --rm -i -t nvidia/cuda:8.0-cudnn6-runtime-ubuntu16.04 /bin/bash

以下はコンテナ内での操作です。

必要なパッケージをインストール
# apt-get update
# apt-get install python-pip python-dev python3-pip python3-dev git -y
# pip3 install --upgrade pip
# pip3 install tensorflow-gpu

CIFAR-10のモデルを落とす
# git clone https://github.com/tensorflow/models
# cd models/tutorials/image/cifar10/

サンプル実行開始
# python3 cifar10_train.py | tee -a results.txt
....
name: Tesla M40 24GB
major: 5 minor: 2 memoryClockRate (GHz) 1.112
pciBusID 0000:14:00.0
Total memory: 22.40GiB
Free memory: 22.29GiB
...
2017-10-23 09:30:33.384193: step 0, loss = 4.68 (256.9 examples/sec; 0.498 sec/batch)
2017-10-23 09:30:33.641038: step 10, loss = 4.64 (4983.5 examples/sec; 0.026 sec/batch)
...
2017-10-23 09:30:56.448989: step 1000, loss = 2.26 (3485.6 examples/sec; 0.037 sec/batch)
2017-10-23 09:30:56.667036: step 1010, loss = 2.48 (5870.3 examples/sec; 0.022 sec/batch)
...
2017-10-23 09:31:19.319086: step 2000, loss = 1.64 (3560.0 examples/sec; 0.036 sec/batch)
2017-10-23 09:31:19.545818: step 2010, loss = 1.62 (5645.4 examples/sec; 0.023 sec/batch)
...
2017-10-23 09:32:28.360640: step 5000, loss = 0.91 (3561.1 examples/sec; 0.036 sec/batch)
2017-10-23 09:32:28.582057: step 5010, loss = 1.09 (5781.0 examples/sec; 0.022 sec/batch)

ちゃんとコンテナからGPUを認識できており、学習ができているのがわかります。

イメージの保存

学習させた結果を他の環境に持っていくのにコンテナはとても便利です。ここでは、リポジトリを使うケースと使わないケース両方を紹介します。

リポジトリを使う場合

今回はDocker Hubを使用します。Docker Hubでのアカウント作成やリポジトリの作成はDocker Hubでできます。ちゃんとしたプロジェクト管理が必要な場合や複数人へ共有する必要があるときに向いています。プロジェクトによってはプライベートリポジトリをGitHubやGitLabで構築するという選択肢もあります。プライベートリポジトリについては別途紹介する記事を出したいと思ってます。

以下はホスト側での作業です。

Container IDを取得
# docker ps

[Container ID]の部分は1530abdc1234などの番号で、[Repository]はidcf/pj1など、[:Tag]は:v1など
# docker commit [Container ID] [Repository[:Tag]]

イメージが保存されていればOK
# docker images

Docker Hubへログイン、そしてpush
# docker login
# docker push [Repository[:Tag]]

別ホストログインし、イメージをpull
# docker login
# docker pull [Repository[:Tag]]

リポジトリを使わない場合

リポジトリの用意が手間だったり、SCPなどでお手軽にイメージを移動したい場合は、リポジトリを使わなくても実施が可能です。なお、冒頭のイメージ作成の部分は、リポジトリを使うときの手順と同じです。

以下はホスト側での作業です。

コンテナIDを取得
# docker ps

[Container ID]の部分は1234abcd1234などの番号で、[Repository]はidcf/pj1など、[:Tag]は:v1など
# docker commit [Container ID] [Repository[:Tag]]

イメージが保存されていればOK
# docker images

docker saveコマンドでtarファイルへ保存
# docker save -o [filename.tar] [Repository[:Tag]]

SCPなどでファイルを転送
# scp [filename.tar] user@x.x.x.x:/path

別ホスト上でdocker loadコマンドでイメージをロード
# docker load -i [filename.tar]

イメージが保存されていればOK
# docker images

まとめ

まだGPUをコンテナで利用されている事例は多くありませんが、今後はDeep Learningのさらなる加速により需要が増えてくるでしょう。

今回ブログを執筆した時点では、CUDA9とcuDNN7がリリースされて間も無かったため、TensorFlowのサンプルがCUDA8とcuDNN6にしか対応していなかったことが構築してから発覚しました。。が、ここでコンテナの出番です。exitして、もう一度別バージョンのイメージを指定して立ち上げるのみなので、"fire and forget"ができます。Deep Learningの手間な部分をほとんど解決してくれるのがnvidia-dockerで、今後のアップデートも楽しみです。

今後は複数GPUやApache Mesosを使ってのスケジューリングについても紹介していきたいと思いますので、お楽しみに！

こんにちは。IDCFクラウド ユーザー会の井上です。 VulsのSlackチームや、IDCFクラウドアンバサダープログラムMORIO Dojoにも参加しています。 今回もいつも通り、Vulsに関する情報です。

Vulsですが、2017年09月末に大幅アップデートがありました。変更部分が多々ありますので、実際に利用する観点からお話をさせて頂こうと思います。 また、Vulsアップデートに合わせ、Vulsコミュニティテンプレートも更新して頂きました。スクリプト等一部変更がありますので、こちらも一緒にお話しさせていただきます。

Vulsの大型アップデート

2017年09月末に、検知性能向上等を目的に大型アップデートが行われました。これによりデータの後方互換性が無くなりましたが、有用な機能が追加されました。

その為、アップデートに関しては計画を立てて実施する必要があります。

更新されたVuls及びVulsrepoの機能

今回のアップデートで、下記の機能が追加/更新されました。

• スキャンモードの分割
  • Fastスキャン：root権限が不要で、インターネット接続が無い環境でもスキャン可能。低負荷
  • Deepスキャン：Changelogの差分を取得し、そこに含まれているCVE-IDを検知。後述のOVALも利用。スキャン対象サーバーに負荷がかかる場合あり
• 再移動の必要性を検知
  • カーネルアップデート後の再起動をしていない場合に警告
• 検知精度の向上
  • OVAL(Open vulnerability adn Assessment Language)を利用したスキャンを提供
    • ただし、OVAL情報を提供しているディストリビューションのみ
    • deepスキャンモードで利用可能
• VulsRepoの更新
  • 上記機能を表示できるよう、機能更新
  • バイナリでの提供を開始
    • 今まではWEBサーバーやPHPの設定が一部必要だったが、WEBサーバー機能を含んだバイナリが利用可能に
    • これにより、既存WEBサーバーの設定変更が不要に

root権限が不要になったことで、(スキャンユーザに対する)セキュリティ的懸念が解消されました。例えばPCI/DSS環境や運用監視サービスなどでも導入が可能になるかもしれません。

また、OVALを利用する事ができるため、潜在的に内包している脆弱性を検知することができるようになりました。これは、CVEが発行されているがパッケージでは修正されていない脆弱性、を可視化することができます。

パッケージで解決できないならどうするの、という話もありますが…

アップデートに伴う検討事項

前述のように各種機能が追加されたのですが、それに伴い過去のスキャンデータとの互換性が無くなりました。

そのため、過去のデータを参照しつつ新しいバージョンを使うためには、移行計画を立てなければなりません。どの程度過去のデータを保管しておくかなどの「データ保存要件」をまとめておく必要があります。 下記に「データ保存要件」の例を2つ書いてみました。

1. 永遠に過去のデータを見たい
旧バージョンのVulsRepoが動く環境と、スキャン結果のJSONファイルを、永遠に保存しておく必要があります。データ保存してあればよい環境であれば、resultsディレクトリを圧縮保存で問題ないでしょう。 ただし、普通はそこまで保存しておく必要はないと思います。法令や何らかの規則で保存期間が決まっていない場合は、これを機に保存期間を決めてしまいましょう。 過去バージョンはメンテナンスされない為、これからのスキャンはVuls新バージョンの利用を推奨します。

2. ある程度の期間だけ、過去の情報は保存しておく
「3か月程度は残しておくが、以降は削除してよい」という運用であれば、並行期間分だけ旧バージョンのVulsRepoを稼働させればよいでしょう。

オススメのVulsアップデート方法

可能であれば、最新版のVulsを構築後、既存の古いVulsでのスキャンは停止し閲覧用にしてしまいましょう。

IDCFクラウドにはせっかくVulsコミュニティテンプレートがあるので、これを使って簡単に構築・移行をするとスムーズです。 なお、今回のアップデートでベースのOSがCentOS7になりました。CentOS6のサポートは2020年11月までとまだ先ですが、Vulsに限らずそろそろCentOS7に移行しておいた方がよいかもしれません。

最新版のVulsテンプレートを利用する

サーバーを作る

いつも通り、コミュニティテンプレートからデプロイしましょう。

IDCFクラウドコンソールにログインし、「仮想マシン作成」を押します。 その後ゾーン等を選択しつつ、「イメージ」の項目で「おすすめTemplate」→「COMMUNITY」→「コミュニティテンプレートの一覧へ」を選択します。

テンプレートのページが開くので、「Vuls / VulsRepo」を選択します。

選択後に「仮想マシン作成」を押し、ゾーンの選択とサービス同意のチェックボックスを確認し、「仮想マシン作成画面へ」を押します。

後は通常の仮想マシン作成と同じです。 IDCFクラウドを初めて使う方は、めちゃ楽ガイドに簡単な使い方がまとまっているので参考にしましょう。

各種更新を行う

VulsRepoがバイナリ化したことで、Vuls/VulsRepoのアップデートは、すべてVulsユーザで実行できるようになりました。

rootでログイン後に、su - vulsをし、各種アップデートの後にデータ更新をしましょう。

[root@hostname ~]# su - vuls

--Vuls/VulsRepo/go-cve-dictionary/goval-dictionaryの更新--
[vuls@hostname ~]$ cd scripts
[vuls@hostname scripts]$ update_vuls.sh
...vuls等のアップデートが終わるまで待ちます...
...初回は5分くらいかかるかもしれません...

--CVE-DBとOVAL-DBの情報を更新する--
[vuls@hostname scripts]$  cd /opt/vuls
[vuls@hostname vuls]$ go-cve-dictionary fetchnvd -last2y
...
[vuls@hostname vuls]$ go-cve-dictionary fetchjvn -last2y
...
[vuls@hostname vuls]$ goval-dictionary fetch-redhat 7

スキャンを行う

まずは、Vulsテンプレートでデフォルトで入っている「自分自身のスキャン」を行いましょう。手順通りであればOSのアップデートをしていないので、大量に検知できるでしょう。

[vuls@hostname vuls]$ pwd
[vuls@hostname vuls]$ vuls scan -deep
...
[vuls@hostname vuls]$ vuls report -to-localfile -format-json
...
[vuls@hostname vuls]$ vuls tui
...[Ctrl+C]で終了させます...
[vuls@hostname vuls]$

また、Vulsサーバーの5111ポートへアクセスすることで、WEBブラウザからも確認可能です。 以前のVulsRepoはhttpdなどのWEBサーバーを調整する必要がありましたが、今回からはバイナリでの提供があります。対象バイナリを実行すると、デフォルトとでは5111ポートで待ち受けます。またアクセス制限も実装されているので、以前のようなBASIC認証設定は不要です。

• http://[VulsサーバーのIP]:51111
  • 上手く稼働しない場合は、サービスの稼働状況を確認
    • 状態を見る # systemctl status vulsrepo
    • 再起動する # systemctl restart vulsrepo
  • HTTPS及びユーザ制限をしたい場合は、WEBサーバーを立ててリバースプロキシで5111に流す必要がありそう

既存Vulsサーバーからの移行を行う

既に以前のVulsテンプレートで脆弱性検査をしていた場合、新Vulsテンプレートサーバーに監視を移行する必要があると思います。 監視対象（スキャンされる側）でIP制限等を行っていない場合は、下記の手順で移行できると思います。

• 既存ConfigやSSH鍵の複製
  • 既存Vulsで利用していた設定やSSH鍵を、新Vulsサーバーに複製
    • /opt/vuls/config.toml
    • /home/vuls/.ssh/id_rsa/ (config.tomlの例に従っていた場合)
• 新Vulsサーバーでの稼働テスト
  • 新Vulsサーバーで、移行したconfig.tomlでのスキャンを実施
    • スキャンが上手く行われない場合は、設定やSSH鍵のアクセス権、ネットワーク経路上の問題、などの洗い出し
    • テストついでに、cpeNamesでの検知を入れている場合は、現状のCPE名を確認
• 新Vulsサーバーでの定期スキャン設定
  • 旧Vulsサーバーのスキャンタイミングと被らないように、定期スキャンをcron等に設定
    • 平行稼働させないのであれば、旧サーバーのcron設定等を移植
    • go-cve-dictionary等のデータ類の定期fetchも忘れずに設定

終わりに

Vulsはこれからも、順次進化していきます。場合によっては（それが必要であれば）今回のような後方互換性のない更新も行われます。 アップデート等の情報は、Slackチーム若しくは vuls_jaでアナウンスされます。安定運用をする場合は、当該の情報源を見る必要があります。

ただし、IDCFクラウドユーザーの場合は、コミュニティテンプレートで最新版を利用可能です。 Vulsのバージョンアップがある場合は、コミュニティテンプレートをIDCFのエバンジェリストが更新します。
今回のような大幅なバージョンアップ時は、コミュニティテンプレートでサーバーを作り直して移行する方法をお勧めします。 既存Vulsテンプレートサーバーと平行稼働をさせることも可能なので、アップデートよりは安全かと思います。

今後、アップデートや有用な情報が集まれば、またVulsの記事を書いていきます。 それでは、またお会いしましょう。