Trial and Error

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

Openstack stein releaseをPackstack(RDO)でvirtualbox上に構築する手順まとめ(1)

はじめに

前回記事のつづき。
今回はvirtualboxで仮想centos導入→その上にopensrackインスト、ログインまでを取り上げる。

モノが来るのにまだ数日かかるので、その間に構築手順を把握/整理する目的で先人の足跡をまとめておく。

手順をまとめる上で特に参考にさせて頂いた資料は以下。


何はともあれ公式。
www.rdoproject.org

仮想環境上に構築した事例としては以下、
qiita.com

all-in-one構成ではなく、多ノード構成事例(controllerノードとcomputeノードを分離)
qiita.com


各種スペック

物理マシン

前回選定したもの。

GPU NVIDIA(R) GeForce RTX(TM) 2070 8GB【DVI-D x1 / HDMI2.0 x1 / DisplayPort1.4 x2 / USB Type-C x1】
CPU インテル(R) Core(TM) i7-8700 プロセッサー (3.20GHz/6コア/12スレッド/12MB)
メモリ 64GB(16GB×4) PC4-21300(DDR4-2666) DDR4 SDRAM
SSD/HDD 320GB Colorful製 SL500 シリーズ / 3TB S-ATA
OS Windows(R) 10 Home 64bit版

仮想マシン

virtualbox上に以下設定で構築

vCPU 4cpu
メモリ 16GB
仮想ディスク 100GB, VDI, 可変
OS CentOS7.5 minimal 64bit
Provider(Public) network*1 10.0.2.0/24 GW:10.0.2.1 NS:8.8.8.8 interface:enp0s3
Management network*2 192.168.56.0/24 GW:192.168.56.1 interface:enp0s8

手順

仮想centos環境の設定

windowsvirtualboxインスト→virtualbox上にcentosインスト」までの手順はノウハウも豊富にあるので割愛。

但しmanagement network設定の際に、プロミスキャスモードを「すべて許可」にする点に注意(openstackインスタンスが外部と通信するために必要)

以下ネットワーク、セキュリティ周りを中心に設定を進める。

立ち上がった仮想centosにログインして、NICの確認。
provider(enp0s3)とmanagement(enp0s8)2つのインターフェースが認識されていることを確認

# ip a


/etc/sysconfig/network-scripts/ifcfg-enp0sxをそれぞれ以下のように編集。

【provider NW(ifcfg-enp0s3)】
外部NWなのでDHCP有効にする。

TYPE=Ethernet
BOOTPROTO=dhcp
NAME=enp0s3
DEVICE=enp0s3
ONBOOT=yes


【management NW(ifcfg-enp0s8】
内部NWは固定IPで。
こちらと同様に192.168.56.100をopenstack各サービスのエンドポイントにする。

TYPE=Ethernet
BOOTPROTO=static
NAME=enp0s8
DEVICE=enp0s8
ONBOOT=yes
IPADDR=192.168.56.100
NETMASK=255.255.255.0


firewalldの自動起動停止/起動停止。
外部ネットワークとアクセス可にする。

# systemctl disable firewalld
# systemctl stop firewalld

NetworkManagerの自動起動停止/起動停止。
固定IPをネットワークカードに割り振るのでこれも無効にする。

# systemctl disable NetworkManager
# systemctl stop NetworkManager

設定の反映

# systemctl enable network
# systemctl start network

SELinux無効化

# setenforce 0
# vi /etc/selinux/config
   SELINUX=disabled


ここで仮想マシンから外部へping飛ばしたり、ターミナルソフトでssh接続できるか一旦確認。

openstackインスト

centosの場合は以下、

# yum install -y centos-release-openstack-stein

openstack-steinリポジトリを有効化。

# yum-config-manager --enable openstack-stein

パッケージ全体を更新。

# yum update -y

packstackインスト。

# yum install -y openstack-packstack


今回はheat*3の検証を行いたいのでanswer fileを生成して、インストされるかどうか確認。

# packstack --gen-answer-file=answer.txt

また、management intにprovider intのアドレスがアサインされてしまう(10.0.2.15)ので、全て192.168.56.100に置換する。

他の設定についても確認して適宜変更。


openstackインスト。
30-60分程度かかるとのこと。

# packstack --answer-file=answer.txt

無事終わったらhorizon*4経由でログイン出来るはず。

http://192.168.56.100/dashboard/

ログイン情報は/root/keystonerc_adminにあり。

この次

実際にマシンが届いたら構築して追記する予定。
実際の構築でドはまりしませんように…

更新履歴

2019/5/20: 手順公開

*1:外部アクセス用ネットワーク。Virtual BoxのNATネットワークを使用

*2:管理サーバー用ネットワーク。openstackの内部ネットワークとして使用する。Virtual Boxのホストオンリーネットワークを使用。

*3:openstackでのオーケストレーションを提供するコンポーネントAWS CloudFormationに相当

*4:ダッシュボード機能(webインターフェース)を提供するコンポーネント

機械学習&openstack検証用マシンを調達してみた

はじめに

実は前回記事のsantanderコンペは自前のmacbook(メモリ8GB)で戦っていた。
この型落ちmacでkaggle戦うのは流石にキツイよな…と思ったので、この際思い切ってGPU搭載マシンを調達することにした。

あと、元openstackerとしてopenstackで以前やりたかったけどできなかった事もこの際やりたいので、openstack検証マシンとしての側面も持たせたい。

要件

  • 機械学習用(GPU搭載/当面の使用目的はkaggle。可能なら画像コンペでも戦えるスペックが欲しい)
  • 仮想プラットフォーム検証用(当面の使用目的はopenstack検証)
  • 予算は税込みで20-30万程度

調査

参考資料(機械学習方面)

参考にさせていただいた先人の取り組みを以下に列挙。
ただほとんどが2018年以前のものなので、最重要パーツであるGPUについて情報が古くなってしまったものが多い。

自作式

少し前の記事だが、各パーツについての詳しい考察付き。
roomba.hatenablog.com
echomist.com

半自作式

一部パーツだけ自前調達して、他はBTOベアボーンキットでまとめて調達した事例は以下、

グラボのみ自前調達で、他はBTOから調達した事例。
www.petitmonte.com

ベアボーンキットにSSDとメモリを追加して組んだ例。
blog.hotolab.net

参考資料(openstack方面)

openstackのデプロイツールはdevstackとかjujuとか色々あるものの、今回はall-in-oneでの使用を想定&お手軽に欲しいので、Packstack(RDO)を採用予定。

2019/5時点で最新のStein releaseの要件は以下、*1
https://www.rdoproject.org/install/packstack/

Software
Red Hat Enterprise Linux (RHEL) 7 is the minimum recommended version, or the equivalent version of one of the RHEL-based Linux distributions such as CentOS, Scientific Linux, and so on. x86_64 is currently the only supported architecture.

RHEL7以上かそれと同等のRHELベースlinuxとのことなので、OSはオーソドックスにcentos7以上のものを使えば良さそう。

Hardware
Machine with at least 16GB RAM, processors with hardware virtualization extensions, and at least one network adapter.

きょうびのRDOはメモリ16GB以上も必要なのね…

選定

自作,半自作, or BTO

各パーツとそれらの関係考えながらあれこれ悩みつつ、一つ一つパーツ調達して組み立てるの楽しそうだなーと先人の記録を読んで思ったものの、諸事情により選定&構築に費やせるリソースは残念ながらあまり多くない。

したがってBTO方式メインで行くことに。
まず各社BTOで見積もり取ってみて、予算オーバー!となったら一部パーツの自前調達を検討する。

GPU

以下記事がとても参考になった(界隈では有名記事らしい)
最新GPUがリリースされると更新されるのもありがたい。
timdettmers.com

2019/5現在新しめの日本語情報は以下。
beiznotes.org

関連して、ゲーミング用途での解説ではあるものの、スペックや設置についてまで詳しく解説されており勉強になった記事はこちら。
chimolog.co

同じサイトからRTX2070の解説記事。こちらも勉強になった。
chimolog.co

上記ら情報を比較検討した結果、

  • 仮想通貨マイニングの影響でGTX1080系は品薄であまり安くなっておらず、現時点ではコスパが良くない
  • GPUメモリが少ないと、大きいニューラルネットとかブン回した時に不利と耳にしたので少なくとも8GBくらいは欲しい
  • 深層学習でtensor core使ってみたい

という理由からRTX2070を選定。

CPU

intelの最新はcore i9だが、お財布と相談してcore i7系で行くことに。
型番末尾にkがつくタイプは、オーバークロックの必要性を感じない&CPUクーラーを別途購入しないといけないので除外。

メモリ

仮想マシン立ててopenstack検証することになったら、RDOの要件考慮して余裕を持ってメモリ32Gくらいは仮想マシンに割り振りたい所。
なのでメモリはケチらず基本上限(64GB)まで積むことにする。

kaggleで画像コンペ戦う場合でも64GBあれば困らないはず。

SSD,HDD

データを速く読み書きするためのSSDと、他のデータを置いておくHDDそれぞれ1台ずつ欲しい。
SSD 250GB & HDD 2TBくらいあればまずは充分かな?と雑な感じで見積もる(足りなければ足せばいいし)

電源

電源ユニットの最大W数の半分くらいで電力変換効率がベストになる、とのこと。
今回は800-850W程度あれば充分のはず。

OS

要件にあるようにRDOを導入するならRHEL系のディストリが必要。

しかしtensorflowやchainer等の深層学習ライブラリは基本的にubuntu 1stで作られているとのこと。*2
なのでこれらライブラリやGPUを走らせるにはubuntuが望ましい。

本当は、

「マシン本体にcentosインスト→RDOインスト→openstackで作ったインスタンスubuntu入れる→そこにライブラリとGPU載せてkaggleでバトル!」

が、できたら嬉しい(&かっこいい)ものの、初っ端から元々の設定全部潰してopenstack突っ込むのもちょっと…なので、最初のうちは仮想centos上にRDO入れて様子見、という選択肢を残しておきたい。

なので当分の間マシン本体のOSはデフォルトのwindows(OS無しが選べる場合はそれにして自分でubuntuインスト)にして、仮想centos上でのopenstack検証が一通り終わったら物理マシンOSにcentos/ubuntu入れて機械学習(DL)方面の検証を進めることにする。*3

買ったもの

以上選定品をまとめると、

GPU RTX2070
CPU core i7 無印
メモリ 上限まで積む(64GB)
SSD/HDD 250GB/2TB程度
電源 800-850W
OS 当面デフォルトのまま(OS無しが選べるならそれ)

BTO5,6社で上記条件で見積ってみると、大体税込25万前後だった。


が、フロンティアでタイミングよくお買い得セール品を見つけてしまった。
f:id:niaoz:20190514143351p:plain

あれ?これでいいんじゃね?

という訳で購入!

費用も税込20万以内で収まりましたとさ。

この次

設置→初期設定→仮想環境構築→openstack構築みたいな流れになると思う。

届くのはまだ先なので、それまでに設置場所(物理)を確保したり、openstack周り中心に知識整備を進める予定。

反省点

*1:Stein releaseに訂正。https://www.openstack.org/software/stein

*2:https://deepinsider.jp/tutor/prepareenv/gpuubuntu

*3:当分の間はopenstack検証を進めるつもりなので、ubuntuが必要になる機械学習環境を整えるのは先になりそう、という事情もある。

kaggle初参戦コンペで銅メダルを獲得できたのでその感想戦(1)-test中のfakeデータ抽出

TL;DR

  • kaggle初参戦コンペで銅メダル獲れた
  • 自分がコンペ開催中に気付けなかった&実装できなかった重要ポイント(test中のfakeデータ抽出)について、コンペ終了後に感想戦してみた

はじめに

もう3週間以上経っちゃいましたが、kaggleの初参戦コンペ*1で銅メダルを獲得することができました!

参加コンペは以下、
Santander Customer Transaction Prediction | Kaggle

f:id:niaoz:20190504130942p:plain
あと0.00003で銀メダルだった…

で、本コンペで鍵となった要素について振り返ってみる。
まずはtest中のfakeデータ抽出について。

結論から言うと、このtips(fakeデータ抽出と抽出後のデータ再形成)だけで60/8300位(上位1%以内)くらいは行けたっぽい。

参考kernel

広まるきっかけになったkernelは以下、
List of Fake Samples and Public/Private LB split | Kaggle
testデータ中に含まれてる半分が元データから生成された偽データで、その選別が重要だった。

このkernelはデータの抽出を扱っているだけなので、これでどれだけスコアが上昇するのか見るのに以下kernelを参照。
simple magic VAR 0.922 | Kaggle

上記2つのkernelが主な引用元だが、コンペ中盤頃にベースとして使ってた以下kernalからの引用も少しあるのでご紹介。
このkernelの重要テーマであるdata augmentationは本記事では割愛。
LGB 2 leaves + augment | Kaggle

検証用jupyter notebook

検証に使用したjupyter notebookは以下、

santander_late2

解説

それぞれポイントとなる部分について適宜解説

真テストデータの抽出(セル4)

真テストデータのインデックスを抽出する。
偽データは他データのコピーなので、unique_countを定義した上で他にコピーがなければ真データ、ダブってれば偽データへ分類している。

# GET INDICIES OF REAL TEST DATA
#######################
# TAKE FROM YAG320'S KERNEL
# https://www.kaggle.com/yag320/list-of-fake-samples-and-public-private-lb-split

df_test = pd.read_csv('input/test_santander.csv')
df_test.drop(['ID_code'], axis=1, inplace=True)
df_test = df_test.values

unique_samples = []
unique_count = np.zeros_like(df_test)
for feature in range(df_test.shape[1]):
    _, index_, count_ = np.unique(df_test[:, feature], return_counts=True, return_index=True)
    unique_count[index_[count_ == 1], feature] += 1

# Samples which have unique values are real the others are fake
real_samples_indexes = np.argwhere(np.sum(unique_count, axis=1) > 0)[:, 0]
synthetic_samples_indexes = np.argwhere(np.sum(unique_count, axis=1) == 0)[:, 0]

print('Found',len(real_samples_indexes),'real test')
print('Found',len(synthetic_samples_indexes),'fake test')
#######################

特徴量生成とデータの再形成(セル10-17)

特徴量をtrainデータの各列から持ってきてfeaturesを定義

features = [col for col in df_train.columns if col not in ['ID_code', 'target']]

trainデータと真テストデータを結合し、featuresを加えた新しいデータ群(=df)を生成

#concatenate train data and real test data with new features
df = pd.concat([df_train,real_test], axis = 0)

for feat in tqdm_notebook(features):
    df[feat+'_var'] = df.groupby([feat])[feat].transform('var')

for feat in tqdm_notebook(features):
    df[feat+'plus_'] = df[feat] + df[feat+'_var']

drop_features = [c for c in df.columns if '_var' in c]
df.drop(drop_features, axis=1, inplace=True)

dfを元のデータ比(train/test = 200000/100000)になるように再分割

#divide into new train and test sets
df_train = df.iloc[:df_train.shape[0]]
df_test2 = df.iloc[df_train.shape[0]:]

featuresの再定義

#新trainデータのtargetを使用してfeaturesを再定義
features = [col for col in df_train.columns if col not in ['ID_code', 'target']]
target = df_train['target']

以上の特徴量生成+データ処理で、各データについて新たに200個特徴量が追加されたことがわかる(セル15-17)

学習(セル19-22)

新たに生成したtrainデータとtestデータを5foldのlightGBMに入れる。
パラメータ等各種設定値はほぼsimple-magic-var-0-922 kernelのまま。

結果

augmentaion等、他のトリックなしでも今回のデータ処理だけで上位1%に入れる!

f:id:niaoz:20190504145554p:plain
だいたいPrivateLBで60位前後の成績

おわりに

機械学習方面でまだまだ学ぶことは山のようにあるので、引き続き精進したい。
本コンペではデータのaugmentationも鍵だったので、この検証ももうちょっと深く突っ込んでやりたい…*2


…けどそろそろインフラ方面タスクをやるかな。

*1:以前PLAsTiCCコンペに様子見で参加したことがあるので、正確には初「本格」参戦コンペ

*2:というか、このaugmentaiton改良が今回銅獲得の原動力になった

機械学習の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)の進化
→更に進んで間接的な情報を収集し、ビッグデータ相関分析を駆使して、サイバー攻撃を事前に予知できる世界が理想