はじめまして。ニフティクラウド オブジェクトストレージ担当の北條です。
2016年6月29日にリリースしたニフティクラウド オブジェクトストレージは、おかげさまで着々とユーザー数を伸ばし、多くの方々にご利用いただいています。
今回は、Amazon S3互換のREST APIを提供するニフティクラウド オブジェクトストレージをLinux OS上でS3ツールを使って、手軽に利用する方法をご紹介します。
※本記事に掲載されている情報は、2016年11月25日時点でニフティクラウドで提供されているCentOS7.1およびUbuntu 16.04にて動作確認を行っています。
なお、今回取り上げるツールのうち、ニフティクラウド ストレージ SDK for Java以外のツールにつきましては、ニフティから提供されているツールではないため、サポート範囲外となりますのでご了承ください。
続きを読むこんにちは。ニフティクラウドでエンジニアをしている竹内です。
2016年10月25日にリリースされた新機能「ニフティクラウド Data Visualizer（β）」は、IoTデバイスや業務システムなどから生み出されるビッグデータを「見える化」し、アクションの「自動化」につなげるクラウド型BI（Business Intelligence）ツールです。
今回はこのData Visualizer（β）を利用し、IoTデバイスハブ + RDBで蓄積した自分の部屋の温度をグラフとして可視化してみました！
前回のサーバー不要！ タイマー＋スクリプトで定期処理を自動化 | ニフティクラウドブログと同じく、今回も一切サーバーを構築・運用することなく、データを描画するところまでできましたのでご紹介させていただきます！
続きを読むこんにちは。ニフティクラウドで開発を担当している大友と言います。
本日は、2016年10月25日にリリースされましたニフティクラウド Machine Learning（現在トライアルα版として受付中）をご紹介します。
ニフティクラウド Machine Learningは、クラウド上に機械学習のモデルを構築して、UIやAPI経由でモデルの出力する予測値を得ることのできるサービスです。
※本記事は2016年11月28日時点での情報を元に執筆しています。
機械学習とは、データに含まれるパターンなどをコンピュータに学習させることで、データを入力として与えた際に、何らかの有益な出力を返すプログラムを構築する仕組みです。出力を返すプログラムをモデルと呼びます。機械学習にはいくつか種類があります。以下に代表的なものを挙げます。
実際の応用例として、以下のようなものがあります。
今回はニフティクラウド Machine Learningの機能として提供している、教師あり学習について説明していきます。
モデルを構築する際に、少なくとも下記のような課題があると考えられています。
一つめは、いわゆる前処理と呼ばれている処理です。機械学習のモデルを構築するアルゴリズムは数値を入力とするものが主になります。そこで、入力するデータを適切な形にあらかじめ処理しておく必要があります。例えば、入力の中に記号が含まれている場合などには数値化する必要があります。また、アルゴリズムによっては、入力する数値のカラムごとの大きさに影響を受けるものがあるため、数値の大きさを調整する必要があります。
二つめはモデルの選択と各モデルのハイパーパラメーターのチューニングです。機械学習にいくつか種類があることは前述しましたが、その中の教師あり学習のモデルについても、いくつか種類があります。それぞれのモデルごとに特性が異なっており、あるデータでは精度の高かったモデルでも別のデータに対しては精度が低く、別のモデルの方が適している場合などがあります。このため、色々なモデルに対して精度の検証を行い、適切にモデルを選択する必要があります。また、各モデルにはハイパーパラメーターという構築を行う前にあらかじめ設定する必要のあるパラメータが存在するモデルもあり、ハイパーパラメーターの値によっても精度が変わってくるためチューニングが必要となります。
加えて、このようなモデルを構築する際の前処理を行い、データを入力するパイプラインは予測時にも同様に適用する必要があるため、永続化して予測時に呼び出せるようにしておくためのシステムが必要となります。
ニフティクラウド Machine Learningは、前述の様な機械学習のモデル構築における課題を解決することに注力したサービスです。主な機能として、下記を提供しています。
今回はこれらの機能を用いて予測モデルの構築を行ってみたいと思います。
UCI Machine Learning Repositoryで公開されている乳がんの良悪性の予測を行うデータセットBreast Cancer Wisconsin （Diagnostic） Data Set（以下Breast Cancerデータセット）を利用して予測モデルを構築していきます。
ニフティクラウド Machine Learningでデータを利用するためには、まずデータソースを登録する必要があります。データソースにはMySQLかニフティクラウド オブジェクトストレージ（以下オブジェクトストレージ）にアップロードされたCSVが対応しています。今回は前述のデータセットをCSVに変換して、オブジェクトストレージから利用することにします。また、実際に利用する際は必要ありませんが、後ほど予測機能を利用するためにあらかじめテスト用のデータを分けて登録しておきます。登録には下記の様にコントロールパネルからデータソースの登録を選択し、前述のアップロードしたCSVファイルを入力します。
続いてモデルの登録を行います。モデルの登録には先ほど登録した学習用のデータソースと予測対象となるカラムを選択します。今回予測したい属性は良悪性のため良性の場合に1となるカラムであるbenignを選択します。
次に前処理の設定を行います。前処理の内容は欠損値補完、正規化、特徴抽出に対応しています。Breast Cancerデータセットは予測対象以外のカラムは実数値のため欠損値を平均値で補完し、平均0分散1で正規化します。
前処理の設定が終わったので学習を開始します。
学習が完了するとモデル一覧からスコアを確認することができます。評価指標のF値は再現率（陽性のデータのうち、正しく陽性と予測できた割合）と適合率（陽性と予測したうち、正しく予測できた割合）の調和平均になります。単純に予測の正解率を指標とすると正解ラベルに偏りがある場合に多いラベルを常に予測するモデルのスコアが良くなってしまうため、機械学習では上記のような指標を用いることが多いです。
ステータスが学習済みになると予測APIが利用可能になります。実際に利用する場合はここで正解が分からないデータに対して予測を行いますが、今回はデータソースを登録する際に用意したテスト用のデータを利用します。UIから予測を行う場合はモデル構築の際に利用する場合と同様に登録済みのデータソースに対して予測値の出力を行います。
実際の値（左側）と予測した結果（右側）とを比較してみると、正しく分類できていることがわかります。
APIを用いて予測することも可能です。APIはAWSのSignature V4互換のためPythonの場合は下記の様にboto/botocoreを利用してリクエストすることができます。
$ cat predict.py
import os
import sys
import json
import requests
from botocore.auth import SigV4Auth
from botocore.credentials import Credentials
from botocore.awsrequest import AWSRequest
endpoint = 'https://ml.api.cloud.nifty.com/'
req = AWSRequest(
method='POST',
headers={
'x-amz-target': 'MachineLearning_20161025.Predict',
'host': 'ml.api.cloud.nifty.com',
'content-type': 'application/json',
},
data=json.dumps(json.load(open(sys.argv[1]))),
)
cred = Credentials(os.environ['ACCESS_KEY'], os.environ['SECRET_KEY'])
SigV4Auth(cred, 'machinelearning', 'east-2').add_auth(req)
print(requests.post(endpoint, headers=req.headers, data=req.body).text)
$ python predict.py payload.json | xmllint --format -
<?xml version="1.0" encoding="utf-8"?>
<PredictResponse>
<predictedLabels>
<predictedLabel>0</predictedLabel>
</predictedLabels>
<modelId>1</modelId>
</PredictResponse>
ニフティクラウド Machine Learningを用いて、予測モデルの構築と予測を実施しました。
このようにCSVデータからカジュアルに予測モデルの構築が行えるサービスとなっておりますのでぜひご利用ください。
トライアルα版の申し込みはこちらから受付中です 。
こんにちは。ニフティの東條（ひがしじょう）と申します。 今回は、2016年9月にリリースされた「Fastly（CDN）」を利用して、簡単にデータ配信する方法をご紹介いたします。
続きを読むこんにちは。ニフティクラウドテクニカルアカウントエンジニアチームです。
今回はニフティクラウド上で実現するネットワーク構成のちょっとした工夫について記載したいと思います。具体的には、プライベートLANに所属するサーバーで複数の異なるネットワーク帯のIPを付与した構成の検証を行ってみます。以降に記載する実際の検証では次の構成を実現しています。
ニフティクラウドでサーバーを作成するとグローバル側とプライベート側のNIC2つが割り当てられた状態で作成されます。その中でもプライベート側のNICは「プライベートLAN」オプションを使用し、プライベート側のNICをプライベートLANに適用することによりユーザー側で自由にIPアドレスを付与することが可能です。
・各サーバーに複数のNIC（複数のIPアドレス）が欲しい。
・システム移行の案件で既存環境のままネットワークの体系を維持したい。
上記要望がありますが、ニフティクラウドの仕様ではどうしてもNICの数は増やすことはできません。。。
2021年1月現在、追加NICによりサーバーに追加のNICを付与することが可能となりました。追加NICの利用方法はブログ「NICを追加してみた（追加NIC機能）」も参考にしてください。
そのため本ブログはは追加NICの上限(1サーバーあたり6個など)を越えて利用したい場合の参考としてください。
しかし、プライベートLANに所属させたプライベート側のNICであれば自由にIPアドレスを付与することができるため、複数のIPアドレスを付与することが可能です。
FAQ：プライベートLAN利用時、1つのサーバーにプライベートIPアドレスは複数振れますか？
※共通グローバル、共通プライベートのNICには複数のIPアドレスの付与設定、staticのIPアドレスの設定は行わないでください。禁止事項に抵触します。 ニフティクラウド 禁止事項
ここまでは通常の仕様ページでわかるものとなります。以降にちょっとした工夫をご紹介します。
プライベートLAN作成時には以下のようにCIDRを指定します。 例：192.168.0.0/24
各仮想サーバーのプライベート側のIPアドレスも指定したCIDRにあったプライベートのIPアドレスを設定します。
例：192.168.0.5
複数のIPアドレスを設定する場合も同一のCIDRで設定する必要があると思われる方が多いかと思います。
例：192.168.0.5 192.168.0.6
実は各仮想サーバーのIPアドレスはプライベートLANで指定したCIDR通りにIPアドレスを設定することが必須という制限はありません。そのため以下のようなことが可能となります。
・プライベートLANで設定したCIDR
192.168.0.0/24
・仮想サーバーAに設定するプライベートIPアドレス
①192.168.0.5/24
②10.0.0.5/8
・仮想サーバーBに設定するプライベートIPアドレス
①192.168.0.6/24
②10.0.0.6/8
①は業務LAN用、②は管理用、バックアップ用などでネットワーク帯を分けることが可能です。そのため既存システムのIPアドレス体系を維持できる可能性があります。
また、プライベートLAN作成時に指定できるプレフィックス長は16～28ですが手動で仮想的に指定する分にはプレフィックス長を8で付与することも可能です。
ただし、以下を注意点として認識しておく必要があります。
| NIC自体は一つであることは変わらない | バックアップでネットワーク流量を逼迫することを懸念としてネットワーク帯を分けたいなどの要望であればあまり意味を成さないことになります |
| 十分にネットワーク構成を検討する必要がある | ニフティクラウドのルーター、VPNゲートウェイなどはプライベートLANで設定したCIDR内のIPアドレスを指定する必要があります |
| プライベートLANは1本である | あくまで1本のプライベートLAN内に複数のネットワークセグメントを設定している形になります |
また、ルーターとVPNゲートウェイはOS上の操作は不可のため、複数IPを付与することはできません。そのため、プライベートLANで指定したCIDR以外のIPアドレスでほかのネットワーク帯のIPアドレスと通信するためにはルーティング用のサーバー構築を行うなどの検討が必要です。
これまでの記載が実現可能か確認するために、以下図の構成で実際に検証してみました。
1つのプライベートLAN上で複数の仮想IP（各IP異なるセグメント）を作成しています。 以下表にそれぞれのセグメントを記載します。
| セグメント | ネットワーク帯 | 備考 |
|---|---|---|
| セグメントA | 192.168.0.0/24 | 実際にコントロールパネルより作成 |
| セグメントB | 10.0.0.0/8 | - |
| セグメントC | 172.16.0.0/16 | - |
| セグメントD | 192.168.2.0/24 | - |
| セグメントE | 192.168.3.0/24 | 共通セグメント |
| セグメントF | 192.168.1.0/24 | コントロールパネルより作成（セグメントAとルーターで接続） |
複数のIPアドレスを付与する対象のOSとしては、Windows（サーバー①）とCentOS（サーバー②、③）どちらも検証しています。サーバー④はルーティング用のサーバーでCentOSで構築しています。仮想的に複数のネットワーク帯を実装するプライベートLAN（セグメントA（B～E））とは別のプライベートLAN（セグメントF）を作成し、プライベートLAN同士をルーターで接続して別のプライベートLANとの疎通も検証してみます。
各登場機器達のIPアドレスは以下で設定しています。
| 対象 | IPアドレス | 備考 |
|---|---|---|
| サーバー① | 10.0.0.2 | B:10.0.0/8セグメントのIPアドレス |
| 192.168.3.2 | E:192.168.3.0/24のIPアドレス | サーバー② | 172.16.0.2 | C:172.16.0.0/16セグメントのIPアドレス |
| 192.168.3.3 | E:192.168.3.0/24のIPアドレス | サーバー③ | 192.168.2.2 | D:192.168.2.0/24セグメントのIPアドレス |
| 192.168.3.4 | E:192.168.3.0/24のIPアドレス | サーバー④ | 192.168.0.2 | A:192.168.0.0/24セグメントのIPアドレス |
| 10.0.0.1 | B:10.0.0.0/8セグメントのIPアドレス | |
| 172.16.0.1 | C:172.16.0.0/16セグメントのIPアドレス | |
| 192.168.2.1 | D:192.168.2.0/24セグメントのIPアドレス | |
| 192.168.3.1 | E:192.168.3.0/24セグメントのIPアドレス | サーバー⑤ | 192.168.1.2 | F:192.168.1.0/24セグメントのIPアドレス | ルーター | 192.168.0.1 | A:192.168.0.0/24セグメントのIPアドレス |
| 192.168.1.1 | F:192.168.1.0/24セグメントのIPアドレス |
本構成で各機器に設定したルーティング情報は以下で設定しています。
| 対象 | デスティネーション | ターゲット（ゲートウェイ） | 備考 |
|---|---|---|---|
| サーバー① | 0.0.0.0/0 | 10.0.0.1 | デフォルトゲートウェイで設定 |
| サーバー② | 0.0.0.0/0 | 172.16.0.1 | デフォルトゲートウェイで設定 |
| サーバー③ | 0.0.0.0/0 | 192.168.2.1 | デフォルトゲートウェイで設定 |
| サーバー④ | 192.168.1.0/24 | 192.168.0.1 | route add コマンドで設定 |
| サーバー⑤ | 0.0.0.0/0 | 192.168.1.1 | デフォルトゲートウェイで設定 |
| ルーター | 10.0.0.8/8 | 192.168.0.2 | ― |
| 172.16.0.0/16 | - | ||
| 192.168.2.0/24 | - | ||
| 192.168.3.0/24 | - |
ここまでで今回必要な構成自体は完成しました。
最後に各登場機器間でそれぞれpingの疎通が可能かどうかのテストを実施したところ、すべて問題無く疎通が可能なことまで確認できました。
※各機器でニフティクラウドファイアウォールは適切に設定しています。
本検証の通り、各仮想サーバーに複数の異なるネットワーク帯のIPアドレスを付与できることがわかります。既存のIPアドレスの体系を維持したい要件が強い場合には選択肢の1つになると考えられます。 実際に本検証内容を利用し、以下のような構成で実装されているお客様もいらっしゃいます（下図を参照）。
この構成ではセキュリティ面を鑑みて、WEB/AP層、DB層のネットワーク帯を分けた形になっています。具体的な通信フローは以下のようになります。
・ご利用者様はL7LB（L7ロードバランサー（Brocade Virtual Traffic Manager））にグローバル側からアクセス
・L7LBからWEB/APサーバー「192.168.1.0/24」のネットワーク帯のIPアドレスに対して負荷分散を行う
・WEB/APサーバーからDBサーバーへは「192.168.2.0/24」のネットワーク帯を利用して通信を行う
本検証内容に関してはOS以上の動作となり、お客様責任で実施いただく範疇になります。そのため、実装をご検討いただく場合は十分に検討/設計/検証いただくようお願いします。
ブログ中にもいくつか記載していますが、注意事項/制約事項などが多くあるため、それらを鑑みてご利用いただければと思います。
【注意事項/制約事項（ブログ中に記載した注意事項の再記載を含む）】
・共通グローバル、共通プライベートのNICには複数のIPアドレスの付与設定、staticのIPアドレスの設定は行わないでください。禁止事項に抵触します。
・あくまで1本のプライベートLAN内に複数のネットワークセグメントを設定している形になります。
・上記のとおり、プライベートLAN自体はあくまで1本となります。コントロールパネルのネットワーク図上では作成時に指定したCIDRの情報のみ見える形になります。
・コントロールパネル上でサーバーのIPアドレスを確認しても複数設定したIPアドレスのうち１つのみ表示されている状況になります。
-設計書等で明確に管理しておくなどの運用が必要になります。
・構成によっては、ルーティング用のサーバーを別途構築するなどの対応が必要です。
・ニフティクラウドのルーター、VPNゲートウェイなどのネットワークサービスの設定は原則プライベートLANで設定されるCIDRのみに制限されます。またOSの操作はできないため複数IPアドレスを付与することはできません。具体的には以下制限があります。
-ルーターのDHCPの払い出しレンジはプライベートLANで設定されるCIDRのみに制限される
-VPNゲートウェイでL3VPN接続(IPSec)の場合、対向拠点から受け付けられる通信もプライベートLANで設定されるCIDRのみに制限される
-ルーター、VPNゲートウェイともにルートテーブルでnext hopで指定できるのはプライベートLANで設定されるCIDRのみに制限される
【その他】
・VPNゲートウェイやダイレクトポート（専用線・閉域網 接続サービス）などを利用して拠点と接続する構成の場合、ルーティングの設定などネットワーク構成がより複雑となることが想定され、事前に緻密な設計が必要になります。
上記に記載した注意事項/制約事項などを把握していただき、本構成を実現する必要があります。
使いやすさやネットワーク図上での見やすさなどを優先されるのであれば、通常通りにニフティクラウドのサービスに則った形で構成した方が良い可能性があります。
[2021年1月22日追記：現在では追加NICが利用できるようになっています。詳しくは下記の記事をご覧ください。] blog.pfs.nifcloud.com
