読者です 読者をやめる 読者になる 読者になる

Trial and Error

ITで色々やってることを書いてくチラシの裏です

機械学習のwebラーニング課題で教師あり学習をいろいろ試してみた

はじめに

UdacityというwebラーニングコミュニティでIntro to Machine Learningっていうコースを学習している(このボリュームで全て無料!)
www.udacity.com
1-4章では教師あり学習について扱っていて、4章付属のpythonプログラムがいろいろな教師あり学習アルゴリズムを比較検討するのに役立ちそう、と思いついたので、4章まで受講し終わったこのタイミングでまずはざっとやってみた。

環境

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.10.5

$ python -V
Python 2.7.11

$ pip freeze
cycler==0.10.0
matplotlib==1.5.3
nltk==3.2.1
numpy==1.11.2
pyparsing==2.1.10
python-dateutil==2.6.0
pytz==2016.7
scikit-learn==0.18.1
scipy==0.18.1
six==1.10.0
Theano==0.8.2

ライブラリは色々入ってますが、matplotlib,numpy,scipy,scikit-learnあたりを主に使ってるはず。

コードの中身

コードのベースにしたのはこちらからダウンロードできる以下のスクリプト

ud120-projects/choose_your_own/your_algorithm.py

あらかじめプロット関係のコードは書かれているので、your code here!の後に「各アルゴリズムのモジュールをインポート」「classifier導入」「fit」と3行程度追加するだけで図示できる。便利。

一例として、naive bayesの場合はこんな感じになる(一部抜粋)

### your code here! name your classifier object clf if you want the
### visualization code (prettyPicture) to show you the decision boundary

from sklearn.naive_bayes import GaussianNB
clf = GaussianNB()
clf.fit(features_train, labels_train)

try:
    prettyPicture(clf, features_test, labels_test)
except NameError:
    pass

plt.show()

試してみたアルゴリズムと出力結果

今回decision boundaryを図示してみたのは以下のアルゴリズム

  1. Naive Bayes
  2. Support Vector Machine(SVM)
  3. Decision Tree
  4. AdaBoost
  5. Random Forest
  6. k-Nearest Neighbor(kNN)

対象データ

自動運転車の速度制御がモチーフで、横軸に凸凹度(bumpiness 大きいほどでこぼこ)、縦軸に坂の緩急(grade 大きいほど急)を取ってある。
全データはfast(青)かslow(赤)かで既に色分けされている。
f:id:niaoz:20161204180916p:plain
青と赤の領域をどのように分けるのか?が今回のお題。

1.Naive Bayes

使用したライブラリ、モジュール、classifier

from sklearn.naive_bayes import GaussianNB
clf = GaussianNB()

参考:sklearn.naive_bayes.GaussianNB — scikit-learn 0.18.1 documentation
f:id:niaoz:20161204181508p:plain

2.Support Vector Machine(SVM)

使用したライブラリ、モジュール、classifier

from sklearn.svm import SVC
clf = SVC()

参考:sklearn.svm.SVC — scikit-learn 0.18.1 documentation
f:id:niaoz:20161205165945p:plain

3.Decision Tree

使用したライブラリ、モジュール、classifier

from sklearn import tree
clf = tree.DecisionTreeClassifier()

参考:1.10. Decision Trees — scikit-learn 0.18.1 documentation
f:id:niaoz:20161205170818p:plain

4.AdaBoost

使用したライブラリ、モジュール、classifier

from sklearn.ensemble import AdaBoostClassifier
clf = AdaBoostClassifier()

参考:1.11. Ensemble methods — scikit-learn 0.18.1 documentation
f:id:niaoz:20161205170108p:plain

5.Random Forest

使用したライブラリ、モジュール、classifier

from sklearn.ensemble import RandomForestClassifier
clf = RandomForestClassifier()

参考:1.11. Ensemble methods — scikit-learn 0.18.1 documentation
f:id:niaoz:20161205170133p:plain

6.k-Nearest Neighbor(kNN)

使用したライブラリ、モジュール、classifier

from sklearn.neighbors import KNeighborsClassifier
clf = KNeighborsClassifier()

参考:sklearn.neighbors.KNeighborsClassifier — scikit-learn 0.18.1 documentation
f:id:niaoz:20161205170207p:plain

まとめと今後

かなり適当にやりましたが、結構各アルゴリズムの分類特色は出てる気がした。
4章まで進むのは少し大変だけど、ここまで到達してしまえば結構お手軽にアルゴリズムを試せてしまうpythonとsklearnすげえ(あと勿論このコースも)

残った課題としては、

  • 今回はざっとお試しだったので、clfのパラメータを一切いじらないでやってみたが、いじったらどうなる?
  • 関連して、これらパラメータの変更でaccuracyの改善を図る

とかありますが、まだまだコースの先が長い&興味ある章がたくさんあるので、とりあえず先に進みます。

OCP in interop 2014

interop開催から約1ヶ月たち、前回はshownetの中心4分野についてまとめを投げましたが、もう一つ印象に残っているのがこのOCP(Open Compute Project)。それがこのINTEROP Tokyo 2014で日本初展示されたそうです。

 

f:id:niaoz:20140719124021j:plain

 
OCPとはいうなればハードウェアのオープンソースプロジェクト(なんか以前流行ったMakersっぽい)
FacebookのDCでは既に導入済みで、このOCPラックがズラッと並んでるそうです。*1
 
 
--
当然各ユニットごとにサイズ、マウント、電源の規格が決まっています。
 
・サイズ
基本1U。横1/2,1/3サイズのモジュールもあり。奥行きまでも全て統一
(これ大事。ラッキング経験者ならわかると思いますが、奥行きはホント各ベンダーでまちまち。あと奥行きを統一させているのは後述の給電方式との絡みもあります。)
 
・マウント
すでに統一規格のレールがラックに標準搭載されており、各モジュールはそのレールに取り付けるだけでおk。
(これもよさげ。ベンダーによってはレールほんとに扱いにくいし。特にI○Mさん猛省してくださ(ry)
 
・電源
ラック背面に電源ワイヤが2*2=4本張ってあって、この線をモジュールの後ろでガチッと挟むことで給電する。*2
モジュールの挟む部分は勿論統一規格。また、抜け防止のための機能も搭載(たしか「かえし」みたいなものがついてた気がする
 

f:id:niaoz:20140719124104j:plain

この写真だと超わかりにくいですが、奥の方にワイヤが4本張ってあります…
--
 
 
で、OCPの流れはサーバ・DBのみにとどまらず、ネットワーク機器にも来ているそうです。
既にOCP対応のスイッチが出ています(見た目はHP Procurveをシンプルにした感じ)。
また今回驚いたのが、ネットワークデバイス向けLinuxディストリビューション*3というものがあるのだそうで、当然Linuxカーネルなのでlsとかcdとか普通に使えるそうです。
 

f:id:niaoz:20140719124327j:plain

(これも何か見にくい…いい写真なくてすんません…)
 
うーむ、ともかく、サーバいじってるのかスイッチいじってるのか瞬間的にわからなくなりそう^^;
 
shownetのサーバ系、ネットワーク系の話を聞いていても感じましたが、今後はSDNの普及と相まってサーバ技術、ネットワーク技術の境界がどんどん曖昧になっていくのかなぁ、と。 

*1:そういえばFacebookが中心となってこのOCP規格を推薦しているというのをなんか(日経COMかな?)で読んだ記憶が...

*2:ただ、電源ワイヤに電気が来てる状態でラック背面で作業する際は触れないよう要注意!ですねこれ

*3:Cumulus Linux。キャラクターは亀

shownetまとめ4(ファシリティ編)

1.ファシリティ系のトレンド
細径ケーブル(高密度配線)
冷却効率、エアフローの考慮→専用の製品も有り
データセンターのエコな運用への注目(機器の省電力化、電力の測定)


2.クラウド
自社内設備数は減少傾向(しかしどうしても社内におく必要のある設備は社内に、という話も)

ラックのマネジメントについては(少なくとも国内では)決定的なソリューションなし
→あれこれ悩まずにコンテナを一括で買ってしまうという手も


3.将来像
各機器の大きさ、奥行きが各社まちまち。
配線(フロントorリア)、操作系もまちまち。
→各機器の設置、配線等まで含めた構成管理ツールは構成が大規模になる海外では事例があるものの、日本国内ではまだ決定的なソリューションはない。現在手探りで進めているような状況。

全ての規格が統一され、悩まずにぽんぽんラックに入れられるのが理想。
 →OCP(Open Compute Project)へ。特に大規模事業者で求められるのでは。
OCP導入により、電力管理やファシリティマネジメントも規格が統一され作業がやりやすくなることを期待。

→shownetのように全部一気にマウントする場合でも、規格の違いを気にせずストレスフリーで順調にマウント出来る機器が出てくれば、実際の現場の人間も幸せになるのでは。

shownetまとめ3(セキュリティ編)

1.セキュリティ、サイバー攻撃分野のトレンド
従来:無差別のバラマキ型→サイバー攻撃のビジネス化へ進化
→高い情報を持つ企業に対し、高いコストをかけ複雑な手法で攻撃
 →対抗するための技術や市場が広がっている=従来の技術では対応は難しい。
DDoS攻撃ランサムウェアも増加
→攻撃のビジネス化と密接な関係。


2.防御手法
新しい攻撃には新しい技術を組み合わせた多層防御が重要。
(次世代ファイアウォール,UTM,IPS/IDS,サンドボックス等を多層的に運用)
→SIEM(複数装置からのログを統合して分析)の重要性


3.セキュリティ対策の実施ポイント
→セキュリティを内部統制の一つとして業務に組み込めるかどうか


4.今後のセキュリティ
人手を介さないセキュリティ対策の強化
狙った情報を扱える人間をまず攻撃するソーシャルエンジニアリングを回避するため。
破られたあとのダメージ・コントロールのサービスやアプライアンスの増加が見込まれる。

セキュリティ対策導入のポイント
→セキュリティを内部統制の一つとしてうまく業務に組み込んでいくこと。


5.将来像
SIEM(Security Information and Event Management)の進化
→更に進んで間接的な情報を収集し、ビッグデータ相関分析を駆使して、サイバー攻撃を事前に予知できる世界が理想

shownetまとめ2(DC/Cloud/サーバー編)

1.ここ2年位のDC事情
すぐ使えるリソースとして仮想化、クラウド採用の流れ強まる
→ファシリティと関連

DCのボトルネックの変化:
物理的な数(ポート数、帯域)→論理的なリソース(VLAN,MACアドレス
*VxLANへの移行


2.インタークラウド
多種多様なクラウドをつなぐ「インタークラウド」が今後重要に?
→震災後ディザスタリカバリBCPに注目が集まったのがきっかけ。
クラウドサービスごとの強みや特色を上手く組み合わせたい要望強。
 →今回のshownetではVXLANで商用クラウド同士を接続する。
 VXLANは現時点ではまだドラフト段階
  →shownet構築では手探りで進めた。


3.shownetでの取り組み
異なるクラウド基盤を持つ、商用クラウド同士を実際につなぐ。(←VXLANプロトコルを使用)

参加企業:
ビットアイル(OpenStackベース)
IDCフロンティア(CloudStackベース)
さくらインターネット(独自クラウド

→DCとして価値あるサービスを構築できるかに挑戦

技術的課題:
カプセル化に依るオーバーヘッドがボトルネックにならないように、どこでフラグメントを回避させるか


4.OpenStack vs CloudStack
初期のサービス:CloudStack→現在増えてきているのが:OpenStack
→OpenstackはAPIが共通化されている利点あり。

AWS vs OpenStack:
現状ではAWSが優勢。
openstackは多くのベンダーが開発に取り組むことで、特定のベンダーに偏った仕様にならないように注意している。


5.その他
ストレージ:NANDフラッシュの採用


6.将来像
レガシーシステムクラウドマイグレーションレガシーシステムの移行)
 →オンプレミスとクラウドを接続する技術の必要性。

仮想システム化による障害の切り分けの困難さ
まとめてAPIでラップし、一括管理できるような仕組みが生まれれば。
 →ネットワーク同様、DCもSDx化する際の標準化が必要なのではないか。

shownetまとめ1(ネットワーク編)

ひと月ほど前に開催されたINTEROP TOKYO 2014で構築された恒例のShowNetについて、
自分がネット上のコンテンツ及び会場で配布されたshownet magazine、ツアーで見聞きしたことをまとめたものをここに掲載。

Shownet2014注力4テーマ:

1.ネットワーク
SDNを用いた新しい参照モデルへ
2.DC/Cloud/サーバ
インタークラウド(商用クラウド事業者間接続)とVXLAN Gateway装置の相互接続実験
3.セキュリティ
多層防御とSIEMによる監視
4.ファシリティ
設備集約による高密度配線化、それに伴うエアフローへの影響

に沿って、まとめ(というよりもメモ?)を4分割して載せていきます。

    • -


ネットワーク編

1.増え続けるネットワークトラフィックへの対応
特に通信キャリアにおいて顕著
オペレーションコストの低減や消費電力、ビットあたりの電気代の低減(→ファシリティとも関連)
ネットワークも分散型から集中型へ


2.NFV(Network Function Virtualization)
まだユースケースをいくつか出している段階。通信キャリアレベルでの検討が始まった段階。

ソフトウェアルータの可能性
→DCや通信キャリアレベルになると小型のFWを何千台導入するより、コストメリットを出しやすくなるかも


3.SDN(Software Defined Network)
少し前からopenflowによる導入事例が増加。
NWオーケストレーションの導入までできればSDNの真価が発揮される。

サーバ、ネットワーク、ストレージを一括管理
→実現すれば運用が簡単になったり、コスト削減といったメリットも

SDNによるNW自動化のノウハウはだいぶ溜まってきたが、トラブル時対応といった面でまだ技術が「枯れる」必要がある。
まだトラブル時にデバッグ出来る人が少ない。


4.SDN向けアプリケーション
機器の設定情報を管理するデータベース
→SDNのパーツとなる要素(OpenDaylight, OpenContrail)は揃い始めている。
→今後はそれを束ねるためのノースバウンドAPIへ進むのではないか。
 →共通APIでの直接制御で、開発運用コスト削減が期待される。

SDNをきっかけにネットワーク屋とサーバ屋の区別が無くなる可能性


5.今後のshownetネットワーク
TTDB(Trouble Ticket DB: 運用情報DBシステム)からネットワークを管理構成し、オーケストレーションを自動化

今年のNFV実例:
上位コントローラから自動的にデプロイしてNFVを実現する
→機器を単純につなぎあわせていけばいいだけの世界!


6.将来像
スイッチからコントロールプレーンを分離し、コントローラーで一括管理という考え方が広まっていくのではないか。

ブログ開設!

この度、ブログを開設しました。
一応IT系技術者のはしくれとして、色々試行錯誤してることを徒然と書いていこうかと思ってます。
どうかよろしくお願いしますm(_ _)m