OpenStack Stein releaseをPackstack(RDO)でvirtualbox上に構築する手順まとめ
はじめに
前回記事のつづき。
今回はvirtualboxで仮想centos導入→その上にopensrackインスト、ログインまでを取り上げる。
モノが来るのにまだ数日かかるので、その間に構築手順を把握/整理する目的で先人の足跡をまとめておく。
※6/3追記
構築完了しました！
手順をまとめる上で特に参考にさせて頂いた資料は以下。
何はともあれ公式。
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 |
|---|---|
| メモリ | 32GB |
| 仮想ディスク | 100GB, VDI, 可変 |
| OS | CentOS7.6 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環境の設定
「windowsにvirtualboxインスト→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
ネットワーク設定の反映
# systemctl enable network
# systemctl start network
NetworkManagerの自動起動停止/起動停止。
固定IPをネットワークカードに割り振るのでこれも無効にする。
※6/3追記
NetworkManagerを止める前に、ip a叩いてホストオンリーアダプタにIPアドレスが振られているか確認する。
振られていない場合はnmtui等でstaticにアドレスを割り振る→NWプロセス上げ直し→再確認した上でNMを停止。
networkmanager上げなおし→staticでアドレス振る→ip aで今度こそ付与されてること確認→NM 再disでうまくいきましたとさ。
— niao (@niao28790890) 2019年6月1日
# systemctl disable NetworkManager
# systemctl stop NetworkManager
SELinux無効化
# setenforce 0 # vi /etc/selinux/config SELINUX=disabled
openstackインスト
centosの場合は以下、
# yum install -y centos-release-openstack-stein
yum-config-managerを使用するのでyum-utilsインスト
yum install -y yum-utils
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に置換する。
※6/3追記
IPアドレス以外で、今回answerファイルを書き換えた箇所は以下
# Specify 'y' to install OpenStack Data Processing (sahara). In case # of sahara installation packstack also installs heat.['y', 'n'] CONFIG_SAHARA_INSTALL=y # Specify 'y' to install OpenStack Orchestration (heat). ['y', 'n'] CONFIG_HEAT_INSTALL=y # Specify 'y' to install OpenStack Container Infrastructure # Management Service (magnum). ['y', 'n'] CONFIG_MAGNUM_INSTALL=y # Specify 'y' to install OpenStack Database (trove) ['y', 'n'] CONFIG_TROVE_INSTALL=y
今回はもちろん入れるheatに加え、コンテナ周り&DB周りも触る可能性があるのでsahara,magnum,troveをオンにする
— niao (@niao28790890) 2019年6月1日
openstackインスト。
30-60分程度かかるとのこと。
# packstack --answer-file=answer.txt
※6/3追記
当環境では30分位でインスト完了。
無事終わったらhorizon*4経由でログイン出来るはず。
http://192.168.56.100/dashboard/
ログイン情報は/root/keystonerc_adminにあり。
※6/3追記
無事ここまで辿り着いたらNMを再度有効にする。
（これを忘れると、次回起動時にIPアドレスがホストオンリーアダプタにアサインされない！）
# systemctl enable NetworkManager
# systemctl start NetworkManager
この次
実際にマシンが届いたら構築して追記する予定。
実際の構築でドはまりしませんように…
※6/3追記
次はOpenStack内の認証、セキュリティ、NW諸々の整備とheatの簡単な検証かなー
と、言いたいとこですが…
物理マシンのwin10でcritical process diedというかなりやばい事象が頻発してるので、その対処しないとorz
更新履歴
2019/5/20: 手順公開
2019/6/3: 構築完了により手順追記
機械学習&openstack検証用マシンを調達してみた
はじめに
実は前回記事のsantanderコンペは自前のmacbook（メモリ8GB）で戦っていた。
この型落ちmacでkaggle戦うのは流石にキツイよな…と思ったので、この際思い切ってGPU搭載マシンを調達することにした。
あと、元openstackerとしてopenstackで以前やりたかったけどできなかった事もこの際やりたいので、openstack検証マシンとしての側面も持たせたい。
要件
調査
参考資料（機械学習方面）
参考にさせていただいた先人の取り組みを以下に列挙。
ただほとんどが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万前後だった。
が、フロンティアでタイミングよくお買い得セール品を見つけてしまった。
あれ？これでいいんじゃね？
という訳で購入！
RTX2070で行くか…と決めて物色してたら、フロンティアでRTX2070のセール品がなんと本日から売られてた&他パーツのスペックも全て検討基準クリアしてたので運命を感じ、腹を括ってポチった＼(^o^)／https://t.co/ca1fMu2XY6 pic.twitter.com/Us9UM5qA9I
— niao (@niao28790890) 2019年5月13日
費用も税込20万以内で収まりましたとさ。
この次
設置→初期設定→仮想環境構築→openstack構築みたいな流れになると思う。
届くのはまだ先なので、それまでに設置場所（物理）を確保したり、openstack周り中心に知識整備を進める予定。
反省点
勢いで64GB全マシしたけど、振り返れば4つあるスロット考慮して16*2=32GBで注文→残り16GB*2は他から安く調達、で更にお得になったかも…今後への反省点
— niao (@niao28790890) 2019年5月13日
*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
で、本コンペで鍵となった要素について振り返ってみる。
まずは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%に入れる！
機械学習の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を図示してみたのは以下のアルゴリズム
- Naive Bayes
- Support Vector Machine(SVM)
- Decision Tree
- AdaBoost
- Random Forest
- k-Nearest Neighbor(kNN)
対象データ
自動運転車の速度制御がモチーフで、横軸に凸凹度(bumpiness 大きいほどでこぼこ)、縦軸に坂の緩急(grade 大きいほど急)を取ってある。
全データはfast（青）かslow（赤）かで既に色分けされている。
青と赤の領域をどのように分けるのか？が今回のお題。
1.Naive Bayes
使用したライブラリ、モジュール、classifier
from sklearn.naive_bayes import GaussianNB clf = GaussianNB()
参考:sklearn.naive_bayes.GaussianNB — scikit-learn 0.18.1 documentation
3.Decision Tree
使用したライブラリ、モジュール、classifier
from sklearn import tree clf = tree.DecisionTreeClassifier()
4.AdaBoost
使用したライブラリ、モジュール、classifier
from sklearn.ensemble import AdaBoostClassifier clf = AdaBoostClassifier()
参考:1.11. Ensemble methods — scikit-learn 0.18.1 documentation
5.Random Forest
使用したライブラリ、モジュール、classifier
from sklearn.ensemble import RandomForestClassifier clf = RandomForestClassifier()
参考:1.11. Ensemble methods — scikit-learn 0.18.1 documentation
6.k-Nearest Neighbor(kNN)
使用したライブラリ、モジュール、classifier
from sklearn.neighbors import KNeighborsClassifier clf = KNeighborsClassifier()
参考:sklearn.neighbors.KNeighborsClassifier — scikit-learn 0.18.1 documentation
OCP in interop 2014
interop開催から約1ヶ月たち、前回はshownetの中心4分野についてまとめを投げましたが、もう一つ印象に残っているのがこのOCP(Open Compute Project)。それがこのINTEROP Tokyo 2014で日本初展示されたそうです。
OCPとはいうなればハードウェアのオープンソースプロジェクト（なんか以前流行ったMakersっぽい）
--
当然各ユニットごとにサイズ、マウント、電源の規格が決まっています。
・サイズ
基本１U。横1/2,1/3サイズのモジュールもあり。奥行きまでも全て統一
（これ大事。ラッキング経験者ならわかると思いますが、奥行きはホント各ベンダーでまちまち。あと奥行きを統一させているのは後述の給電方式との絡みもあります。）
・マウント
すでに統一規格のレールがラックに標準搭載されており、各モジュールはそのレールに取り付けるだけでおｋ。
（これもよさげ。ベンダーによってはレールほんとに扱いにくいし。特にI○Mさん猛省してくださ(ry）
・電源
ラック背面に電源ワイヤが2*2=4本張ってあって、この線をモジュールの後ろでガチッと挟むことで給電する。*2
モジュールの挟む部分は勿論統一規格。また、抜け防止のための機能も搭載（たしか「かえし」みたいなものがついてた気がする
この写真だと超わかりにくいですが、奥の方にワイヤが4本張ってあります…
--
で、OCPの流れはサーバ・DBのみにとどまらず、ネットワーク機器にも来ているそうです。
既にOCP対応のスイッチが出ています（見た目はHP Procurveをシンプルにした感じ）。
（これも何か見にくい…いい写真なくてすんません…）
うーむ、ともかく、サーバいじってるのかスイッチいじってるのか瞬間的にわからなくなりそう^^;
shownetのサーバ系、ネットワーク系の話を聞いていても感じましたが、今後はSDNの普及と相まってサーバ技術、ネットワーク技術の境界がどんどん曖昧になっていくのかなぁ、と。
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)の進化
→更に進んで間接的な情報を収集し、ビッグデータ相関分析を駆使して、サイバー攻撃を事前に予知できる世界が理想
