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

はじめまして。クラウドサービスの運用を担当している村上と申します。 普段は主にクラウドをご利用されているお客様のお問い合わせサポート、また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フロンティア中途採用

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

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

前回は、Vulsのミートアップである Vuls祭りVol.1の記事を書きました。引き続き、Vulsの記事を寄稿させていただきます。
さて先日、IDCFエバンジェリストグループの方から、Vulsのコミュニティテンプレートが公開されました。 今回は、このコミュニティテンプレートについて内容を確認し、追加の情報を提供させていただきます。

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

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

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

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

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

[vuls@vuls vuls]$

[servers]

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

[servers]

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

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

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

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

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

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

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

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

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

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

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

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

アップデート

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

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

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

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

Vulsのアップデート

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

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

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

sudoersの厳格化

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

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

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

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

デフォルトconfig.tomlの変更

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

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

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

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

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

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

上記に合わせたREADMEの更新

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

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

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

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

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

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

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

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

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

最後に

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

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

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

こんにちは。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のアップデートをしていないので、大量に検知できるでしょう。

やり方はいつも通りですが、OVAL情報を使う場合はscan時に -deep オプションが必要です。

[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の記事を書いていきます。 それでは、またお会いしましょう。

こんにちは。この IDCF テックブログには２度目の寄稿となる木村です。
今回はオープンソースのブロックチェーン環境である Hyperledger Fabricを紹介し、特に IDCF クラウドを使ってその環境構築を行うための手順を紹介します。

自己紹介

某外資系クラウド会社で、クラウドや人工知能、DevOps といった比較的新しい技術を使ってお客様アプリケーションのプロトタイプ開発を行ったり、その技術紹介を行ったりしています。会社の方針でもあるのですが、最近はブロックチェーンを使った案件にも多く関わっており、多くの会社が業種内でのトップランナーとなるべく興味を持っていることを実感しています。

Hyperledger Fabric v1.0 について

ビットコインに代表されるブロックチェーン技術に注目が集まる中、 「企業利用に適した分散台帳フレームワーク」を目的としたオープンソースブロックチェーン環境開発プロジェクトがスタートしました。それが Hyperledgerプロジェクトです。Hyperledger プロジェクトではフレームワークの開発と同時に、オープンソースのテクニカルコミュニティを作り、ソリューションプロバイダーやユーザーエコシステムへの便益提供を目的としています。

この Hyperledger プロジェクトの中で行われたハッカソンを通じ、いくつかのインキュベーションプロジェクトが生まれています。その中の１つがブロックチェーンプラットフォームやその SDK/API を含めて提供する Hyperleger Fabricでした。IBM は Hyperledger Fabric が生まれた当初からコードを提供し、発展に貢献してきました。そのベータ版は IBM Bluemix（現 IBM Cloud）を通じて世の中に提供されていましたが、2017年7月に正式バージョンである Hyperledger Fabric v1.0 がリリースされました。

Hyperledger Fabric はオープンソース製品として公開されていると同時に、テクニカルコミュニティ向けにも多くの情報が提供されています。今回は「サポートツール」と呼ばれる、Docker を使って開発者向けに比較的簡単な方法で Hyperledger Fabric v1.0 環境を構築するキットを紹介し、IDCF クラウドの仮想マシン内で同環境を構築する手順を紹介します。

なお Hyperledger Fabric の公式ドキュメントはこちらです：
https://hyperledger-fabric.readthedocs.io/en/release/

作成する環境のシステム図

今回は「サポートツール」を使って Hyperledger Fabric 環境を構築します。このサポートツールは Docker および Docker-Compose が導入されていることを前提として稼働し、Hyperledger Fabric の構成や開発、動作検証に最小限必要な環境を作ります。具体的には今回紹介する手順で次のようなネットワーク構成を（1台の Docker サーバー内に）作ります：

• CA: 認証局ノード

• Orderer: ブロック追加の順序を管理するノード

• Peer: ブロックを持つノード（実際には複数ピアで運用することになるが、サポートツールでは１つだけ作る）

• DB: ステートデータベース

図1　システム図

仮想マシン作成

まずは Hyperledger Fabric 環境を導入するためのサーバーを用意します。今回は IDCF クラウドの仮想マシンを利用しました。

IDCF クラウドのコンソールにログインし、仮想マシンを１台作成します。今回はマシンタイプに（自分が普段使っている環境に近いという理由で） standard.S8 を使用しましたが、環境構築の手順を確認するだけであればもっと小さくても（light.S2 クラスでも）できると思います。

Hyperledger Fabric 自体は後述する Docker および Docker-Composer 上で動きますが、今回利用するサポートツールは macOS および Ubuntu 用に用意されています。今回はサーバーを作成する際に OS としては Ubuntu Server 16.04を選択したものとして、次の説明を続けます。

ネットワーク設定とSSHログイン

仮想マシンが起動したらまずはネットワークの構成を行います。

ファイアウォール

開発用途限定などで、ブロックチェーンを外部からアクセスさせない場合はファイアウォールの設定は必ずしも必要ではありませんが、外部からアクセスさせる場合は IP アドレスのファイアウォールの設定が必要です。具体的には（今回のサポートツールで作る構成の場合は）GRPC と呼ばれるプロトコルが使う次のポートを公開する必要があります：

図2　ファイアウォールの設定

必要に応じて、次の環境設定をする時のために SSH を使う場合は SSH のポート（デフォルトは22）も開けておきます。IDCF クラウドの場合は Web コンソールから仮想マシンのコンソールに直接アクセスすることもできるので、その機能を使って構成する場合は必須ではありません。

ポートフォワード

ファイアウォールで開けたポートを仮想マシンにフォワードするための設定を追加します：

図3　ポートフォワードの設定

なお SSH のポートを開けた場合は、SSH のポートについてもフォワード設定を追加します。

SSH でログイン

SSH か、または IDCF クラウドの場合であれば Web コンソールから仮想マシンのコンソールに直接アクセスする機能があるので、いずれかを使ってターミナル画面にアクセスし、次の準備作業および設定作業を行います。

図4　SSH でログイン

なお、後者の（Web コンソールから仮想マシンのコンソールに直接アクセス）方法については以前にテックブログを書かせていただいた際に紹介しているので、その方法はこの記事内を参照ください：

Secure Gateway を使って、マルチクラウドの環境間でのセキュアなデータ通信を実現する

Hyperledger Fablic導入準備

メモリがキツい可能性あり。スワップを増やす場合はこちら：

今回は Docker を使って、１台の（仮想）マシン内にブロックチェーン環境を構築します。したがって Docker 環境となるホストのメモリは多めに用意しておくべきです。

IDCF クラウドで仮想マシンのスワップメモリを増やす（というか有効にする）方法についてはこちらを参照してください。場合によってはこの方法で仮想的にメモリを増やしておいてください：

http://dotnsf.blog.jp/archives/1019097767.html

とりあえず環境をアップデート

ターミナル画面を開いたら、まずは次のコマンドでライブラリなどの環境をアップデートしておきます：

$ sudo apt-get update -y
$ sudo apt-get upgrade -y

前提条件

Hyperledger Fabric を導入するために必要となる前提条件がこちらです：

• Docker
• Docker-Compose
• Node.js V6.x

Ubuntu 16.04 の場合は次に紹介する手順でこれらを順に導入していきます。導入済みのものがあれば飛ばしていただいて構いません。なお Node.js は V8.x ではなく V6.x をご用意ください。また環境が異なる場合は導入手順も異なると思いますが、これら３つの前提となるミドルウェアが正しく導入されていれば次に進んでいただいて構いません。

Docker CE 17.x のインストール

参考にした記事はこちらです。
公式サイト：
https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/

次の手順では無料版の Docker CE(Community Edition) を導入します：

• リポジトリ設定／更新

$ sudo apt-get -y install apt-transport-https ca-certificates curl software-properties-common  
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -  
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"  
$ sudo apt-get update 

• Docker CE インストール

$ sudo apt-get -y install docker-ce

• Docker CE がインストールされたことを確認

$ sudo docker -v
Docker version 17.09.0-ce, build afdb6d4

↑Docker v17.09.0-ce がインストールできたことが確認できました。

• 権限の変更

Docker のインストールは完了しました。ただし一般ユーザーの場合、このままでは常に sudo を付けないと docker コマンドが使えません。sudo なしで docker コマンドを実行できるようにする場合は次の手順まで実行してください：

$ sudo usermod -aG docker $(whoami)

（この後、一度 Ubuntu からログアウトして再ログインする）

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
 Images: 0
 Server Version: 17.09.0-ce
 Storage Driver: overlay2
 Backing Filesystem: extfs
 :

↑Docker の情報が出力されます。sudo なしで docker コマンドが動くことが確認できました。

Docker-Compose

参考記事はこちら
公式サイト：
https://docs.docker.com/compose/install/

次の手順で docker-compose コマンドを直接ダウンロードします：

$ curl -L "https://github.com/docker/compose/releases/download/1.12.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
$ chmod +x /usr/local/bin/docker-compose

（この後、一度 Ubuntu からログアウトして再ログインする）

$ docker-compose -v
docker-compose version 1.12.0, build b31ff33

↑Docker-Compose v1.12.0 がインストールできたことが確認できました。

Node.js V6.x

最新版ではなく V6.x を導入するために n package を使ってバージョンを指定してインストールします。

こちらの記事を参考にしました。
公式サイト：
https://nodejs.org/ja/download/package-manager/#debian-and-ubuntu-based-linux-distributions-debian-ubuntu-linux

• まず普通に apt-get コマンドで nodejs と npm をインストールします。

$ sudo apt-get install -y nodejs npm

これで nodejs （とnpm）はインストールできているのですが、この方法だと node コマンドではなく nodejs コマンドを実行する必要があります。またバージョンが古く、今回の環境構築に必要な V6.x ではないバージョンが導入されているはずです。

$ node -v
bash: node: command not found

↑node コマンドが使えない

$ nodejs -v
v4.2.6

↑nodejs コマンドであれば使える。ただしバージョンは古い。

• n package をインストール

上記手順で導入した（古い）npm を使って、Node.js のパッケージバージョン管理ツールである n package をインストールします：

$ sudo npm cache clean
$ sudo npm install n -g

• node v6.x をインストール

n package を使って node v6.x をインストールします。まずは Node.js のバージョン一覧を確認します：

$ sudo n list
    :
  6.11.4
  6.11.5   <- 6.x はこれが最新（2017.11.12時点）
  7.0.0
    :

6.x 系では（この画面では）6.11.5 が最新のようでした。このバージョンをインストールする場合は次のように指定して実行します：

$ sudo n 6.11.5

ログインし直して（一度ログアウトして再ログイン）、改めて node コマンドと、そのバージョンを確認します：

$ node -v
v6.11.5

念のため、npm のバージョンも確認します：

$ npm -v
3.10.10

• 最初に入れた nodejs と npm を削除

このままでもいいのですが、最初に apt-get コマンドで導入した nodejs と npm が入ったままだと混乱の原因にもなるので、削除しておきます：

$ sudo apt-get purge -y nodejs npm

これで Hyperledger Fabric を導入する上での前提条件は全て揃いました！

図5　前提となるソフトの導入完了

Hyperledger Fabric

では改めてここから Hypderledger Fabric を導入する手順を紹介します。

（参考） http://dotnsf.blog.jp/archives/1066949876.html

Hyperledger Fabric コマンドラインインターフェース

まず npm を使って Hyperledger Fabric のコマンドラインインターフェースである composer-cli をインストールします：

$ sudo npm install -g composer-cli

↑このコマンドは終了まで結構時間がかかります。コマンドが完了したら composer-cli がインストールできていることを確認します：

$ composer -v
v0.14.2

↑composer-cli の v0.14.2 が導入できています。（バージョンは2017.11.12時点）

サポートツール

docker サービスが止まっている場合はここで起動しておいてください：

$ sudo service docker restart

ではメインディッシュである Hyperledger Fabric サポートツールを導入します。次の例ではホームディレクトリ直下に ~/fabric というフォルダを作って、その中にサポートツールを導入しています。フォルダを変更したい場合は適宜読み替えてください：

$ cd
$ mkdir fabric  （ホームディレクトリ配下の ~/fabric/ にサポートツールを導入する場合）
$ cd fabric
$ curl -O https://raw.githubusercontent.com/hyperledger/composer-tools/master/packages/fabric-dev-servers/fabric-dev-servers.zip
$ unzip fabric-dev-servers.zip

ダウンロード＆展開したサポートツールのファイルを確認します：

$ ls
createComposerProfile.sh  _loader.sh      teardownAllDocker.sh
downloadFabric.sh         package.json    teardownFabric.sh
fabric-dev-servers.zip    startFabric.sh
fabric-scripts            stopFabric.sh

↑バージョンによっては多少変わるかもしれませんが、次で使うシェルスクリプトが展開されることを確認します。

Hyperledger Fabric v1.0 のインストール

サポートツール内のシェルスクリプトを使って Hyperledger Fabric v1.0 をインストールします：

$ ./downloadFabric.sh

このコマンドの中で必要な docker イメージのダウンロード等が行われ、Hyperledger Fabric v1.0 がセットアップされます。

コマンドが終了したら、いったんこの時点で docker のプロセスを確認します。Hyperledger Fabric 関連のプロセスが１つも動いていないことを確認してください。

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

↑Hyperledger Fabric のプロセスが何も動いていない状態

Hyperledger Fabric の起動

では Hyperledger Fabric を起動します：

$ ./startFabric.sh

このコマンドが完了した後、改めて docker のプロセスを確認します。今度は Hyperledger Fabric 関連のプロセスが動いていることが確認できます。

$ docker ps
CONTAINER ID        IMAGE                                     COMMAND                  CREATED             STATUS              PORTS                                            NAMES
59ce8e49b410        hyperledger/fabric-peer:x86_64-1.0.3      "peer node start -..."   25 seconds ago      Up 25 seconds       0.0.0.0:7051->7051/tcp, 0.0.0.0:7053->7053/tcp   peer0.org1.example.com
352f9fe8c96f        hyperledger/fabric-ca:x86_64-1.0.3        "sh -c 'fabric-ca-..."   28 seconds ago      Up 26 seconds       0.0.0.0:7054->7054/tcp                           ca.org1.example.com
d9ad480318bd        hyperledger/fabric-orderer:x86_64-1.0.3   "orderer"                28 seconds ago      Up 25 seconds       0.0.0.0:7050->7050/tcp                           orderer.example.com
5cbf663372fe        hyperledger/fabric-couchdb:x86_64-1.0.3   "tini -- /docker-e..."   28 seconds ago      Up 26 seconds       4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp       couchdb

↑Hyperledger Fabric のプロセスが起動しています！

デフォルトプロファイルの作成

$ ./createComposerProfile.sh
（~/.composer-connection-profiles/hlfv1/connection.json および ~/.composer-credentials/ 以下が作成される）

Hyperledger Fabric の停止

起動した Hyperledger Fabric を停止する場合は stopFabric.sh を実行します：

$ ./stopFabric.sh

コマンド完了後、改めて docker のプロセスを確認して、動いていた Hyperledger Fabric 関連のプロセスが消えていることを確認します。

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

↑Hyperledger Fabric のプロセスが停止しました。

最後に、ダウンロードしたサポートツールのアーカイブファイルはもう不要なので削除しておきます：

$ rm fabric-dev-servers.zip

Hyperledger Fabric

以上でブロックチェーン環境のインフラとも言える Hyperledger Fabric の（最小限の）インフラ環境を構築することができました。もちろん実際の運用時にはピアノード数を増やしたり、（Docker 上で構成されたものだけではなく）他のネットワークとも接続してビジネスネットワークを構成することになると思いますが、一方でこれだけでアプリケーション開発および動作確認程度はできる環境にはなっています。

Hyperledger Fabric を使ってアプリケーションを開発する場合にはいくつかの方法がありますが、その中でも Hyperledger Composer フレームワークを使うと（ChainCode や Go 言語といった知識がなくても）アプリケーションの定義や開発ができて便利＆オススメです。そちらについても機会があればこのテックブログで紹介させていただきたいのですが、導入手順については別サイトで以前に紹介したことがあるので、そちらを参照ください：

http://dotnsf.blog.jp/archives/1066959724.html

こんにちは、藤城（@tafujish）です。今回もidcfcloud-cliの話をします。
予定どおり開発が進みまして、このたびDNS/GSLBとコンテンツキャッシュに対応しました。ここでは、追加された機能について紹介します。

idcfcloud-cliはその名のとおり、IDCFクラウドをコマンドラインから操作するためのインターフェースで、今回のように対応サービスを順次拡張していき各サービスを統合しようとしています。idcfcloudコマンドから簡単にAPIを実行できますので、ちょっとしたスクリプト化など自動化を簡単にはじめられます。

インストールや初期設定については以下のエントリーを参照ください。

Ubuntu 16.04 環境
blog.idcf.jp

CentOS 7.x 環境
blog.idcf.jp

既にインストール済みの方は、

$ sudo gem update idcfcloud
$ sudo idcfcloud init

でアップデート可能です。

では、新機能について見ていきましょう。

• 列選択のオプションが入りました（--fields、--json-path）
  • --fields
  • --json-path
• コンテンツキャッシュを試してみる
• DNS/GSLBを試してみる
• コンピューティング（Beta）を試してみる
• まとめ

$ idcfcloud ilb list_loadbalancers
{
  "status": 200,
  "message": "",
  "data": [
    {
      "id": "476b0e9f-ee26-4630-ab64-51edaa10aad4",
～略～

$ idcfcloud ilb list_loadbalancers --fields=name,id
[
  {
    "name": "clitest",
    "id": "476b0e9f-ee26-4630-ab64-51edaa10aad4"
  },
  {
    "name": "clitest2",
    "id": "9b6fbe71-ead1-4b74-afb6-db8447065d76"
  },
  {
    "name": "clitest3",
    "id": "d3bca49d-c70a-42b1-9cdb-376843db4ea5"
  }
]

$ idcfcloud ilb list_loadbalancers -o csv --fields=name,id
name,id
clitest,476b0e9f-ee26-4630-ab64-51edaa10aad4
clitest2,9b6fbe71-ead1-4b74-afb6-db8447065d76
clitest3,d3bca49d-c70a-42b1-9cdb-376843db4ea5

$ idcfcloud ilb list_loadbalancers --json-path='$..configs'
[
  [
    {
      "id": "65ac4726-4ec1-45aa-8168-71bdad2997c5",
      "port": 80,
      "loadbalancer_id": "476b0e9f-ee26-4630-ab64-51edaa10aad4",
～略～

$ idcfcloud ilb list_loadbalancers --json-path='$..configs' --fields=id
[
  [
    {
      "id": "65ac4726-4ec1-45aa-8168-71bdad2997c5"
    }
  ],
  [
    {
      "id": "4d5ecb9d-a54a-4ce8-8092-39304018bae4"
    }
  ],
  [
    {
      "id": "20d0e565-e876-4bc3-8960-1a9569ae7236"
    }
  ]
]

$ idcfcloud cdn get_fqdn_list '{"api_key":"eHECQ5pdKKIoyxEJOFrzgwN-JqSyR3JMc1Ivf_AmN4uoj3LxzJmmImxgs9CEeorts-JXDRdO4NvmxkviPc-sDG"}'
{
  "status": 200,
  "message": "",
  "data": {
    "status": "success",
    "customer_domain": [
      {
        "id": "4436",
        "customer_id": "65",
        "cache_fqdn": "p1irv22ozsvv61.cdn.jp.idcfcloud.com",
        "cache_dir": "/",
        "origin_fqdn": "cdnorg.ds.jp-east.idcfcloud.com",
～略～

$ idcfcloud cdn delete_cache '{"api_key":"eHECQ5pdKKIoyxEJOFrzgwN-JqSyR3JMc1Ivf_AmN4uoj3LxzJmmImxgs9CEeorts-JXDRdO4NvmxkviPc-sDG","delete_path":"http://cdnorg.ds.jp-east.idcfcloud.com/img003.png"}'
{
  "status": 200,
  "message": "",
  "data": {
    "status": "success",
    "messages": "We accept the cache deleted successfully."
  }
}

$ idcfcloud dns list_zones -o table --fields=uuid,name
+------------------------------------+---------------+
|uuid                                |name           |
|92b7067a-75c0-4cd6-aaa4-7d8a4c1349ac|example.com    |
|faafa764-75d6-468a-b572-c0688ee141d0|example.net    |
|698ff2f7-0f03-48b3-bf8d-85f0789479fe|example.org    |
|d2656f15-80de-4191-81c0-b168f883c7ec|example.jp     |
|058ec764-7e47-41a6-9939-758ad9ecb265|sub.example.com|
+------------------------------------+---------------+

$ idcfcloud dns list_records "92b7067a-75c0-4cd6-aaa4-7d8a4c1349ac" -o table --fields=uuid,name,type,content
+------------------------------------+----------------+----+-----------+
|uuid                                |name            |type|content    |
～略～
|3641e5d9-f3eb-413b-927e-f28fb3eced7e|www.example.com |A   |203.0.113.1|
|4c200167-5679-49ea-b7aa-d77e72c91165|example.com     |A   |203.0.113.1|
|27fba561-4f42-41a5-8c98-0d87f3ec759c|www.example.com |AAAA|2001:db8::1|
+------------------------------------+----------------+----+-----------+

$ idcfcloud dns update_record "92b7067a-75c0-4cd6-aaa4-7d8a4c1349ac" "3641e5d9-f3eb-413b-927e-f28fb3eced7e" '{"content":"203.0.113.99"}'
{
  "status": 200,
  "message": "",
  "data": {
    "uuid": "3641e5d9-f3eb-413b-927e-f28fb3eced7e",
    "name": "www.example.com",
    "type": "A",
    "content": "203.0.113.99",
    "ttl": 3600,
    "description": "",
    "created_at": "2017-12-01T11:56:42+09:00",
    "updated_at": "2017-12-04T20:40:11+09:00"
  }
}

$ idcfcloud compute listVirtualMachines

$ idcfcloud compute listZones

$ idcfcloud compute listServiceOfferings

$ idcfcloud compute listTemplates '{"templatefilter":"featured"}'

$ idcfcloud compute listSSHKeyPairs

$ idcfcloud compute deployVirtualMachine '{"zoneid":"f4583787-7bff-461a-b026-73942911ca8b","serviceofferingid":"bd226b3b-6ae7-454d-b53d-c886f7eebe42","templateid":"49160f13-abbf-4f57-a711-110069d4da7b","keypair":"keyname1","name":"vmtest1"}'

こんにちは藤城（@tafujish）です。IDCFクラウドでは、HighIOタイプやベアメタルサーバーにより高速なIOPSを利用できるプランを用意しており、データベースなどの高IOPSを求める用途で好評いただいています。
その一方で、「●●のタイプは何IOPS出ますか？」という質問もしばしばいただきますが、一言で回答できそうで実は難しいんです。IOPSの上限値のことなのか、ベンチマークの値なのか。それが、リードなのかライトなのか混合なのか、シーケンシャルなのかランダムなのか、ブロックサイズは？並列度は？プリコンディショニングした？キャッシュ効いてる状態？などなど、「1万IOPSです」といったように一言で回答できないのです。

「10万IOPS出ます」なんて言った日には、Queue Depthが大きいときの値だから実アプリからはそんなに出ないし、これが元になってトラブルが起きるのではと余計なことまで考え込むと回答できなくなってしまいます。そこで今回は、様々な利用目的の人が見ても、「このIOPSの値が欲しかったんだ」と言える方法を紹介し、IDCFクラウドの高速なIOPSを提供する全タイプに対してベンチマークによるIOPSを計測してみます。具体的には、ezFIOというツールを使えば、様々なI/O性能をベンチマークしレポーティングまでを一気にやってくれるのです。

• ezFIOとは
• ezFIOの使い方
  • fioをインストール
  • ezFIOをインストール
  • ezFIOの実行例
    • --utilization
    • --output
    • --yes
• ezFIOの結果の見方
• IDCFクラウド上でベンチマーク
• まとめ

# yum install epel-release -y
# yum install fio sdparm -y

# apt update
# apt install fio sdparm -y

# wget https://github.com/earlephilhower/ezfio/archive/v1.1.tar.gz
# tar zxf v1.1.tar.gz
# cd ezfio-1.1

# ./ezfio.py --drive /dev/sdb

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

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

VXLAN over CLOSとは

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

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

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

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

オーバーレイ：VXLAN

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

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

VXLAN over CLOSのメリット

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

こんにちは、河合です。今回はIDCFクラウド DNSについて、12月14日にリリースされた2つの機能をご紹介します！

• お待たせしました♪ NSレコード対応
• レコード一括登録機能が登場
• さいごに

お待たせしました♪ NSレコード対応

これまでレコード操作の対象にネームサーバー(NS)が含まれておらず、追加・削除・編集ができませんでしたが、今回の機能改修でNSレコードも編集できるようになりました。これによって権限委任が可能になりますので、例えばサブドメインをIDCFクラウド環境以外のDNSサーバーで運用したいという方などにもご活用いただけます。
ご利用方法はこれまでの「レコード追加」と同様です(図1)。レコードタイプ選択の一番右に「NS」が追加されていますのでぜひご利用ください！

▲ 図1　NSレコード追加の画面

設定時は次の制限がありますのでご注意ください。詳細は仕様書にも記載がありますのでご参照ください。

※ TTL範囲は600〜86400
※ 一部登録不可のドメイン(RFC2606で予約されているトップレベルドメインなど)があります

では、続けて新機能についてお話します！

レコード一括登録機能が登場

今までは「レコード登録」から1行ずつレコードを登録していただいていましたよね。今回リリースした新機能「バルクインポート」では、このレコード登録を一括でできてしまいます！DNS移管など、大量の設定が必要な際にお役立ていただけます。

▲ 図2 バルクインポート イメージ

登録方法は次の2パターンあります。

1. BIND形式のゾーンファイルをインポート
2. テキストをコピー&ペースト or 直接入力

▲ 図3　ゾーン選択後の画面でバルクインポートをクリック

パターン1は所有しているゾーンファイルをそのままインポートする方法です。バルクインポートを選択後「ファイルを選択」からレコード登録を行う対象ゾーンのファイルをインポートします。そうするとファイルの記述内容がテキストボックスに反映されます(図4)。この時もし不適切なレコード形式があればエラー文が表示されるので、テキストボックス上でそのまま修正することが可能です。

▲ 図4 ゾーンファイル[idcf-dns.zone]を選択した状態

形式が整ったら右下の「適用」をクリックするとインポート内容が表示されるので(図5)、問題なければ再度「適用」をクリックいただき、最後の確認をするとインポートが完了します(図6)。

▲ 図5 インポート前のレコード確認画面

▲ 図6 インポートしたレコードが追加されているのを確認

パターン2はファイルを読み込ませず、コピー&ペーストでテキストボックスに入力して登録する方法です。また、その場でテキストボックス上に記述していくことも可能です。複数のレコードを一括で手間をかけずに設定できるので、例えば一時的にDNSの挙動を確かめたい時などにも有効的です。テキストボックスにレコード情報が書かれている状態になれば、その先はパターン1で説明した手順と同様になります。

さいごに

今回はIDCFクラウド DNSのアップデート情報についてご紹介しました。
また、このアップデートがあった12月14日、もう1つの変化があったことにお気づきの方はいらっしゃいますでしょうか？実は、同日にIDCFクラウド DNSのロゴをリニューアルしています！

本記事の[図2 バルクインポート イメージ]でもさらっと載せていたのですが、これまでのロゴよりもわかりやすく、IDCFがイメージするDNSサービスがより伝わるようにと生まれ変わりました！ちょっとした変化ではありますが、ユーザーのみなさんにはチェックしてほしいポイントなのでこの場を借りてお伝えしました！(もし古いロゴを見かけたら教えてくださいね)
今後もさらなるパワーアップを目指していますので、ぜひご期待ください。

こんにちは。UX開発部　ディベロップメントグループの品川と申します。
IDCFクラウドのサービス立ち上げ期から、主にフロントエンド（たまにバックエンド）を担当してます。

htmlでtable表記をする際になにかと便利なのがdatatablesですよね。IDCFクラウドのサービスサイト内でも頻繁に実装されているjqueryの追加ライブラリですが、最近、サイト内のリファクタリングを進めることになりまして、今いろいろな箇所を見直しています。 見直しの際、せっかくだからBootstrap4をベースに使ってみようと思い 元サイトを見てみたら bootstrap4 用のcssとjsが用意されているじゃありませんか！！こんな便利なのに、より使いやすくなるなんて！これはもう記事にするしかなし！！！

ということで、今回はdatatablesをbootstrap4ベースで利用してみようというお話です。実質 15分程度でステキな高機能テーブルができました。が、少しだけハマったところがあったので注意点も含めてまとめたいと思います。

前提

• 全ての外部ファイル(CSS,JS)は CDNを利用する。
• スタイルやデザインは一切いじらない。
• datatablesのロケールは日本語にする。(datatablesのプラグイン設定を使う。)
• jqueryは 3.2.1を使用する。(ちゃんとdatatablesの手前で宣言しておいてね。)

DataTablesってなに？

一応datatables知らないよって人のために簡単にdatatablesの機能を簡単にまとめてみます。
一言でいうとtableにポピュラーな機能を付加してくれるステキなjqueryの拡張機能です。

• tableタグそのものに手を加える必要がない。
• jqueryのID指定 #("table").datatable();をするだけで次の機能が付加される。
• 自動的に付加される機能
  • ページネーション
  • 表示件数の変更
  • カラムソート
  • 部分検索

ということで実際に実装してみましょう。

bootstrap4、jQuery3の宣言

2017/11時点ではまだbeta版ですが気にせず使っていきましょう。
bootstrap本家サイトに書いてあるとおりに宣言します。

<linkrel="stylesheet"href="//maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/css/bootstrap.min.css"integrity="sha384-PsH8R72JQ3SOdhVi3uxftmaW6Vc51MKb0q5P2rRUpPvrszuE4W1povHYgTpBfshb"crossorigin="anonymous">

jsの宣言は </body>の手前に。

<scriptsrc="https://code.jquery.com/jquery-3.2.1.slim.min.js"integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN"crossorigin="anonymous"></script><scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.3/umd/popper.min.js"integrity="sha384-vFJXuSJphROIrBnz7yo7oB41mKfc8JzQZiCq4NCceLEaO4IHwicKwpJf9c9IpFgh"crossorigin="anonymous"></script><scriptsrc="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/js/bootstrap.min.js"integrity="sha384-alpBpkh1PFOepccYVYDB4do5UnbKysX5WZXm3XxPqe5iKTfUKjNkCk9SaVuEZflJ"crossorigin="anonymous"></script>

datatablesの宣言

準備が整ったので、datatablesの宣言をします。
datatablesのサイトにアクセスし、CDNのページに遷移します。
bootstrap4のトグルボタンを押下して選択したら、その下にあるRelease部分のソースをコピペします。
※宣言はbootstrap4,jQuery3の後にそれぞれ追加してください。

<linkrel="stylesheet"href="https://cdn.datatables.net/1.10.16/css/dataTables.bootstrap4.min.css"/>

<scriptsrc="//cdn.datatables.net/1.10.16/js/jquery.dataTables.min.js"></script><scriptsrc="//cdn.datatables.net/1.10.16/js/dataTables.bootstrap4.min.js"></script>

datatablesの日本語化

全ての宣言を終えたらちょっとだけカスタマイズします。

<script>$(function(){// datatableの設定を変更$("#table1").DataTable({"language":{"url":"//cdn.datatables.net/plug-ins/1.10.16/i18n/Japanese.json"}});});</script>

table属性を記述する。

上記全てが完了したらtableタグを書きます。

<tableid="table1"class="table table-bordered"><thead><tr><th>No</th><th>氏名</th><th>メールアドレス</th></tr></thead><tbody><tr><td>1</td><td>ほげほげ太郎</td><td>hogehoge@example.com</td></tr><tr><td>2</td><td>ほげふが次郎</td><td>hogefuga@example.com</td></tr></tbody></table>

ハマった点

これでもう完成！と思いブラウザで表示させてみたら・・・あれ？テーブル表示以外何にも出ない・・・
デバッガツールのコンソールを見てみたら次のエラーが。

TypeError: $.ajax is not a function

ajaxなんて使ってないのに・・・と思ったのですが、datatablesはajaxでデータのやり取りをする機能がデフォルトでついているので、jQueryの初期化で怒られてました。
何かいけないのか調べていたところ、jqueryの宣言を見ると・・・

jquery-3.2.1.slim.min.js

ん？ slim？
minは良いとしてslimってなんぞ？？

ググってみたところ、このslimっていうのは余分なjQueryの機能をそぎ落としてパフォーマンスを向上させている版でajax部分の記述がどうやらなくなっているらしいです。

参考にさせて頂いたサイト
TypeError: $.ajax is not a function エラーが出た時の対策(jQuery 3.x)

ということで、改めてjQueryCDNのサイトからslimじゃないバージョンの宣言をコピペします。

<scriptsrc="https://code.jquery.com/jquery-3.2.1.slim.min.js"integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN"crossorigin="anonymous"></script>

↓

<scriptsrc="//code.jquery.com/jquery-3.2.1.min.js"integrity="sha256-hwg4gsxgFZhOsEEamdOYGBf13FyQuiTwlAQgxVSNgt4="crossorigin="anonymous"></script>

おぉ、できた！！

完成

完成形のソースは次のとおりです。そのままコピペして頂ければローカル環境でも見られると思います。

<!DOCTYPE html><htmllang="en"><head><metacharset="UTF-8"><title>datatebles site</title><metaname="viewport"content="width=device-width, initial-scale=1, shrink-to-fit=no"><!-- Latest compiled and minified CSS --><linkrel="stylesheet"href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/css/bootstrap.min.css"integrity="sha384-PsH8R72JQ3SOdhVi3uxftmaW6Vc51MKb0q5P2rRUpPvrszuE4W1povHYgTpBfshb"crossorigin="anonymous"><!--  datatables css --><linkrel="stylesheet"href="https://cdn.datatables.net/1.10.16/css/dataTables.bootstrap4.min.css"/></head><body><divclass="container"><divclass="col-xs-12"><tableid="table1"class="table table-bordered"><thead><tr><th>No</th><th>氏名</th><th>メールアドレス</th></tr></thead><tbody><tr><td>1</td><td>ほげほげ太郎</td><td>hogehoge@example.com</td></tr><tr><td>2</td><td>ほげふが次郎</td><td>hogefuga@example.com</td></tr></tbody></table></div></div><!-- jQuery first, then Popper.js, then Bootstrap JS --><scriptsrc="https://code.jquery.com/jquery-3.2.1.min.js"integrity="sha256-hwg4gsxgFZhOsEEamdOYGBf13FyQuiTwlAQgxVSNgt4="crossorigin="anonymous"></script><scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.3/umd/popper.min.js"integrity="sha384-vFJXuSJphROIrBnz7yo7oB41mKfc8JzQZiCq4NCceLEaO4IHwicKwpJf9c9IpFgh"crossorigin="anonymous"></script><scriptsrc="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/js/bootstrap.min.js"integrity="sha384-alpBpkh1PFOepccYVYDB4do5UnbKysX5WZXm3XxPqe5iKTfUKjNkCk9SaVuEZflJ"crossorigin="anonymous"></script><!--  datatables js --><scriptsrc="https://cdn.datatables.net/1.10.16/js/jquery.dataTables.min.js"></script><scriptsrc="https://cdn.datatables.net/1.10.16/js/dataTables.bootstrap4.min.js"></script><script>$(function(){// datatableの設定を変更$("#table1").DataTable({"language":{"url":"//cdn.datatables.net/plug-ins/1.10.16/i18n/Japanese.json"}});});</script></body></html>

以上です。
html1枚ペラで15分程度でこのクオリティ！
もちろんこの後はajaxでバックエンドと通信したり、実際のレコード部分はレスポンスデータを流し込んだりしますが、ガワを爆速で用意できるのは素晴らしいですね。

datatablesは高機能なので色々とカスタマイズしてみると良いと思います。

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

今回は、CloudStackのクライアントの１つである、CloudMonkeyを紹介します。

CloudMonkeyはCloudStackを操作するためのCLIツールです。 IDCFクラウドはCloudStackをベースに構成されているため、とても親和性の高いツールになっています。

IDCF Cloud CLIもリリースされましたが、それぞれのCLIツールの良い点を活かして使い分けて便利にご利用いただければと思います。

• 便利なポイント
• インストール方法
  • Mac
  • RHEL/CentOS
  • Ubuntu/Debian
• 初期設定
• 使い方(対話モード)
  • デフォルトの出力
  • jsonでの出力
  • テーブル出力
• 嬉しい機能
  • tab補完
    • 引数の候補
    • 値の候補
  • エラー出力

便利なポイント

• CLIだけではなく、対話モードがある
• 設定値をプロファイルとして持つことができ、簡単に切り替えが可能
• 非同期ジョブの結果を待って出力が可能
• tab補完ができる
• Ctrl+Rでbashと同じように履歴からコマンドを実行できる
• 表形式、JSON形式をサポート
• 結果を色付けして表示できる
• Unicodeのサポート

インストール方法

インストールはとても簡単(ただし、Windowsにインストールするのは手順が多いので今回は紹介しません）。 Python2系が入っていない場合は別途インストールする必要があります。

Mac

$ sudo easy_install cloudmonkey

RHEL/CentOS

$ sudo yum install python-setuptools
$ sudo easy_install cloudmonkey

Ubuntu/Debian

$ sudo apt-get install python-pip
$ sudo pip install cloudmonkey

初期設定

set profileでプロファイルの切り替えができます(存在しない場合は新規作成)。
設定は ~/.cloudmonkey/configに保存されます。

$ cloudmonkey
(local) 🐵 > set profile idcf-east-1
(idcf-east-1) 🐵 > set url  https://compute.jp-east.idcfcloud.com/client/api
(idcf-east-1) 🐵 > set apikey ---apikey---
(idcf-east-1) 🐵 > set secretkey ---secretkey---

使い方(対話モード)

ゾーン一覧のAPIを使って、いろいろな出力を試してみました。

デフォルトの出力

(idcf-east-1) 🐵 > list zones
count = 6
zone:
name = tesla
id = a117e75f-d02e-4074-806d-889c61261394
allocationstate = Enabled
dhcpprovider = VirtualRouter
localstorageenabled = True
networktype = Advanced
resourcedetails:
pool.storage.capacity.disablethreshold = 0.85
securitygroupsenabled = False
tags:
zonetoken = bbbd8944-a3c5-3538-8a2a-71d93a788ab5
================================================================================
※※※中略※※※
================================================================================
name = newton
id = 01738d49-2722-4788-891e-848536663c6e
allocationstate = Enabled
dhcpprovider = VirtualRouter
localstorageenabled = True
networktype = Advanced
resourcedetails:
pool.storage.capacity.disablethreshold = 0.85
securitygroupsenabled = False
tags:
zonetoken = 29683cbb-b762-3bae-b5fb-1d50333dd0ef

jsonでの出力

jqなどと組み合わせて使うと簡単に処理がかけます。

(idcf-east-1) 🐵 > set display json
(idcf-east-1) 🐵 > list zones
{
  "count": 6,
  "zone": [
    {
      "allocationstate": "Enabled",
      "dhcpprovider": "VirtualRouter",
      "id": "a117e75f-d02e-4074-806d-889c61261394",
      "localstorageenabled": true,
      "name": "tesla",
      "networktype": "Advanced",
      "resourcedetails": {
        "pool.storage.capacity.disablethreshold": "0.85"
      },
      "securitygroupsenabled": false,
      "tags": [],
      "zonetoken": "bbbd8944-a3c5-3538-8a2a-71d93a788ab5"
    },
※※※中略※※※
    {
      "allocationstate": "Enabled",
      "dhcpprovider": "VirtualRouter",
      "id": "01738d49-2722-4788-891e-848536663c6e",
      "localstorageenabled": true,
      "name": "newton",
      "networktype": "Advanced",
      "resourcedetails": {
        "pool.storage.capacity.disablethreshold": "0.85"
      },
      "securitygroupsenabled": false,
      "tags": [],
      "zonetoken": "29683cbb-b762-3bae-b5fb-1d50333dd0ef"
    }
  ]
}

例えば、追加IPアドレスを全ゾーンから削除したい時はこのような形で書くことができます。

(idcf-east-1) 🐵 > list publicipaddresses filter=id issourcenat=false | jq -r '.publicipaddress[].id' | xargs -L1 -IUUID cloudmonkey disassociate ipaddress id=UUID

テーブル出力

filterで表示するフィールドを選択したり、パイプでつなぐとgrepなどもできます。

(idcf-east-1) 🐵 > set display table
(idcf-east-1) 🐵 > list zones filter=id,name
count = 6
zone:
+--------+--------------------------------------+
|  name  |                  id                  |
+--------+--------------------------------------+
| tesla  | a117e75f-d02e-4074-806d-889c61261394 |
| henry  | 9703cdbb-aee7-41ba-ba80-4807eaa68b80 |
| pascal | f0954b9b-2626-4549-82ad-ca421073b3bc |
| joule  | baf86a6e-4e3b-428e-8fd0-7fda43e468d4 |
| radian | a53ff3d3-042b-4cbd-ad16-494bb8d33e06 |
| newton | 01738d49-2722-4788-891e-848536663c6e |
+--------+--------------------------------------+
(idcf-east-1) 🐵 > list zones filter=id,name | grep tesla
| tesla  | a117e75f-d02e-4074-806d-889c61261394 |

嬉しい機能

tab補完

引数の候補

VM作成コマンドです。一部非対応のオプションもありますが、かなり便利です。

(idcf-east-1) 🐵 > deploy virtualmachine
account=            deploymentplanner=  displayvm=          hostid=             iptonetworklist=    networkids=         securitygroupnames= templateid=
affinitygroupids=   details=            domainid=           hypervisor=         keyboard=           projectid=          serviceofferingid=  userdata=
affinitygroupnames= diskofferingid=     filter=             ip6address=         keypair=            rootdisksize=       size=               zoneid=
customid=           displayname=        group=              ipaddress=          name=               securitygroupids=   startvm=

値の候補

テンプレートなどの補完は都度問い合わせるので、少し遅いです。

(idcf-east-1) 🐵 > deploy virtualmachine zoneid=
9703cdbb-aee7-41ba-ba80-4807eaa68b80 henry
baf86a6e-4e3b-428e-8fd0-7fda43e468d4 joule
01738d49-2722-4788-891e-848536663c6e newton
f0954b9b-2626-4549-82ad-ca421073b3bc pascal
a53ff3d3-042b-4cbd-ad16-494bb8d33e06 radian
a117e75f-d02e-4074-806d-889c61261394 tesla

01738d49-2722-4788-891e-848536663c6e  a117e75f-d02e-4074-806d-889c61261394  baf86a6e-4e3b-428e-8fd0-7fda43e468d4
9703cdbb-aee7-41ba-ba80-4807eaa68b80  a53ff3d3-042b-4cbd-ad16-494bb8d33e06  f0954b9b-2626-4549-82ad-ca421073b3bc

エラー出力

引数不足時のエラーがわかりやすいです。

(idcf-east-1) 🐵 > deploy virtualmachine
Missing arguments: zoneid serviceofferingid templateid

IDCFクラウドでは、今後も便利なライブラリや、IDCFクラウドCLIなどの統合CLIツールを開発してまいりますので、お楽しみに。 APIからのみ操作できる機能もありますので、みなさまも便利で楽なツールをつかって、良いAPIライフをお送りください。

＜IDCFクラウド便利ツールの関連記事＞

■idcfcloud-cliをリリース！ - IDCF テックブログ

■idcfcloud-cliがアップデート！新機能を紹介 - IDCF テックブログ

■IDCFクラウド APIを利用した仮想マシンの作成からSSH接続まで - IDCF テックブログ

こんにちは、永岡です。

今回は僕からidcfcloud-cliの話をします！
β版として実装されていたコンピューティングを1月30日についに正式リリースいたしました！本記事では追加された機能やcloudstack-apiとの違いについて紹介していきたいと思います。

idcfcloud-cliとはその名のとおり、IDCFクラウドをコマンドラインから操作するためのインターフェースです。今回のアップデートによりIDCFクラウドの主要なサービスにほぼ対応いたしました。これにより1つのコマンドでIDCFクラウドの複数サービスを操作・実行できるようになり、システム連携や管理の自動化などがより簡単に行える環境になりました！

インストールや初期設定、対応サービスの説明はこれまでのエントリーでご覧いただけます！

Ubuntu 16.04 環境
blog.idcf.jp
CentOS 7.x 環境
blog.idcf.jp
idcfcloud-cliアップデート第1弾！
blog.idcf.jp

既にインストール済みの方は、次のコマンドでアップデート可能です。

$ sudo gem update idcfcloud
$ sudo idcfcloud init

それでは、今回追加された機能について見ていきましょう！

• コンピューティングを試してみる
• cloudstack-apiからの変更点
  • コマンドよりコンフィグ設定が可能に
  • オプションの設定方法
    • 表示形式
    • メソッドパラメータへの入力方法
    • 非同期メソッドをCLI上は同期に
• 最後に

$ idcfcloud compute listZones -o table -f name,id
+--------+------------------------------------+
|name    |id                                  |
|augusta |bcb92d62-3d5a-47cf-aba2-01a012d3db07|
|monstera|66466a55-0bbc-45ad-a621-a06ffcdc81f8|
+--------+------------------------------------+

$ idcfcloud compute listServiceOfferings -o table -f displaytext,id
+------------------------------------------------+------------------------------------+
|displaytext                                                  |id        |
|1 CPU x 0.8 GHz / 1 GB RAM                      |b851997e-1c80-429c-9739-390e0a564989|
|1 CPU x 1.6 GHz / 2 GB RAM                      |2504abf9-5db6-45a4-bf58-aea02731010a|
|1 CPU x 2.4 GHz / 4 GB RAM                      |e9a38771-7569-4d7b-a3f9-5445edb5e423|
                                          ~中略~
|24 CPU x 2.5 GHz / 128 GB RAM - Dedicated HighIO|ed444cb7-a06e-49f2-bd39-8b2f125789ad|
|40 CPU x 2.6 GHz / 128 GB RAM - Dedicated HighIO|ef3d51af-f8fe-473a-ad1f-3681c4a62e61|
+------------------------------------------------+------------------------------------+

$  idcfcloud compute listTemplates '{"templatefilter":"featured"}' -o table -f name,id,zonename
+--------------------------------------------------------------------+------------------------------------+--------+
|name                                                                |id                                  |zonename|
|Windows Server 2016 Std + SQL2016 Std SP1                           |e667ba68-f88c-4c67-a115-0382a561a933|monstera|
|CentOS 7.4 64-bit                                                   |29fa0597-b476-45d7-85e2-71be350f155d|monstera|
以下略

$  idcfcloud compute listSSHKeyPairs -o table -f name
+---------+
|name     |
|cli-test |
+---------+

$ idcfcloud compute deployVirtualMachine '{"zoneid":bcb92d62-3d5a-47cf-aba2-01a012d3db07"","serviceofferingid":"b851997e-1c80-429c-9739-390e0a564989","templateid":"29fa0597-b476-45d7-85e2-71be350f155d","keypair":"cli-test","name":"morio"}'
{
  "status": 200,
  "message": "",
  "data": {
    "id": "72c3e278-e0f1-3352-9096-ace543039994",
    "name": "morio",
    "displayname": "morio",
以下略

$ idcfcloud compute listVirtualMachines -o table -f name,id,zonename
+-------+---------------------------------------------+
|name   |id                                  |zonename|
|morio  |97759930-ed0f-4dd0-a526-f913695c1a33|augusta |
+-------+---------------------------------------------+

初期設定：$ sudo idcfcloud init

変更：$ sudo idcfcloud configure

変更前：$ cloudstack-api <メソッド> -t name,id

変更後：$ idcfcloud compute <メソッド> -o table -f name,id

変更前：$ cloudstack-api listTemplates --templatefilter featured 

変更後：$ idcfcloud compute listTemplates '{"templatefilter":"featured"}' 

Mastodonとは

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

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

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

利用環境

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

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

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

作業ディレクトリ作成

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

# mkdir -p /home/mastodon

dockerインストール

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

# yum -y install docker

docker保存先を変更

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

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

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

# vi /etc/sysconfig/docker

下記行がありますので、

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

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

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

docker-composer準備

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

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

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

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

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

dockerの起動

dockerを起動します。

# systemctl start docker

Mastodonのインストール

GitHubからcloneする

MastodonをGitHubからcloneします。

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

データの永続化設定

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

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

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

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

#    volumes:
#      - ./redis:/data

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

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

シークレットキーの発行

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

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

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

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

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

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

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

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

Mastodonコンテナを起動

# docker-compose up -d

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

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

Nginxのインストール

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

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

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

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

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

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

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

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

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

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

server_name example.com;

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

root /home/mastodon/public/;

Nginxを起動する

# systemctl start nginx.service

Mastodonへアクセスする

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

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

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

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

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

最後に

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

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

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

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

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

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

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

１. テンプレートとは

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

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

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

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

２. インポート

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

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

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

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

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

▲図3 テンプレート作成

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

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

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

３. エクスポート

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

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

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

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

▲図6 発行されたURL

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

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

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

４. まとめ

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

Docker Swarm概要

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

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

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

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

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

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

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

Dockerのインストール

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

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

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

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

Docker Swarmクラスタを構築

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

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

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

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

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


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

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

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

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

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

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

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

$ docker node inspect swarm-node-02

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

package main

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

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

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

        log.SetOutput(file)

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

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

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

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

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

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

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

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

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

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

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

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

FROM scratch

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

ADD server.crt /
ADD server.key /

ADD play /

WORKDIR /
CMD ["/play"]

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

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

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

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

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

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

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

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

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

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

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

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

モノビットについて

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VR体験会

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

▲玉入れVRゲームに夢中

IDCFより

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

▲IDCフロンティア　金杉

まとめ

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

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

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