元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2017/02/17

デブサミ2017「インテリジェンスで挑むサイバー攻撃の最前線」講演メモ #devsumi


IIJの方による大量トラフィックにおける情報セキュリティ+機械学習的な話を聞いてきたので、そのメモです。


  • 穴吹 健一 氏
    • (株)インターネットイニシアティブ
      • IIJの"J"は何なのか、穴吹氏もよく知らないとのこと...
    • ビッグデータや機械学習を少々

サイバーセキュリティをめぐる攻防

サイバーセキュリティとは
  • データ改善やサービス継続の妨害のような犯罪を阻止
  • 最近はMSS(マネージドセキュリティサービス)提供の会社が増えてきた

サイバー攻撃は他人事ではない
  • 標的型メールによるマルウェア感染による個人情報流出
  • 派遣社員によるデータ持ち出しによる個人情報流出
  • CSRF/トロイの木馬による遠隔操作による不正操作
  • などなど

攻撃主体と目的
  • 国家
    • 諜報活動や他国の政治への介入
  • ハクティビスト
    • 政治的主張
  • 犯罪組織
    • 利益目的の情報窃取や脅迫

よくある攻撃手法
  • DDoS攻撃
    • 古典的だがどの通信が攻撃か判別が難しいので効果的
  • Web改ざん
    • マルウェア配布や罠サイトへの誘導等
  • マルウェア感染
    • PC内部の情報を盗んだり暗号化したり
  • 標的型攻撃
    • 特定の人や組織を狙った攻撃

IIJが観測したDDoS攻撃
  • 1日あたり平均4〜5件くらい
    • 大体が30分以内で終わるが、大規模なものも増えてきている

ドライブバイダウンロードによるマルウェア感染の脅威

ここ最近だとRigが急増している


ランサムウェアの動向

月ごとに変わってきている、種類を変えて継続している


高度化するサイバー攻撃
  • 大規模化するBotネットワーク
    • 攻撃に利用されるIoT機器 (MiraiBot)
    • 防犯カメラなどが利用されている
  • 増え続ける新種マルウェアとその亜種
  • より巧妙化する標的型攻撃
    • 内部に侵入しても慎重に活動している (見つかりにくい)

サイバーセキュリティの今後
  • リアルタイムでのモニタリング
    • あらゆるログを横串で分析して兆候を見つける
  • インシデント発生時の迅速な対応
    • 処理時間が短いほど被害を最小に抑えられる
  • リスク管理
    • 何を守り、どこまで許容するか
    • 企業にとって、サイバーセキュリティは経営課題
  • ユーザへの教育
    • セキュリティポリシーを明確にし、ガイドラインを用意する
    • 最終的に、セキュリティは人に依存する

AIに関する基礎知識

AIとは
  • Artifical Intelligence
  • 人工知能

人工知能に対する2種類の考え方
  • ヒトの知能を再現する
    • 強いAI
    • 汎用人工知能と呼ばれているもの
    • 知性とは何か?とか、もはや宗教や哲学の世界
    • 面白そうだけど、ビジネスではまだ役に立たないかも
  • 特定の問題を解決する
    • 弱いAI
    • 反応や行動は人間ぽいが自我も意識もなくルールに従った動作

人工知能 => 機会学習

ビジネス的観点から言えば、特定の課題を解決するために特化した弱いAIのこと


機械学習とは
  • データをもとにパターンやルールを導くためのフレームワーク
  • 主に予測や判別、分類に使われる
    • スパム判定、レコメンド、画像認識、異常検知
  • 機械学習 => 関数みたいなもの
    • 入力を与えると答えを返す
  • 様々なモデル・アルゴリズムがある

タイタニック号の乗客の生存予測をやってみる
  • 入力データ
    • 性別、年齢、客室投球 (だけで試しにやってみた)
  • データの特性を見る
    • 男女別では女性の方が生存率が高い
    • 年代別ではあまりさが見られない
    • 客室投球別では1等級の生存率が高い
  • ロジスティック回帰で生存予測モデルを作成
    • 結果としては、まずまずの精度

データ分析に対するIIJの取り組み

  • DAMカラオケ機器向けの新機能開発
    • ユーザの選曲行動をもとに思わず歌いたくなるようなレコメンドを実装
      • 一緒にカラオケを行く人によって、共通項があったり選曲しているのではという仮説
      • テキストマイニング(tf-idf法)でクラスタリングをカラオケの選曲に適用
        • 各選曲番号のtf-idfを算出
        • Canopy-Kmeans Clusteringでクラス多数と中心座標を算出
      • 従来のカテゴリわけでは見つからなかった楽曲間の関連性が見つかった

サイバーセキュリティへのAI適用に対する取り組み

  • 各種膨大なログなど、ISPならではの情報と、20年を超えるシステム運用実績から得られるビッグデータを情報分析基盤で保持
  • 膨大な情報分析より、セキュリティインテリジェンス(レピュテーション作成、トレンド予測など)を生成

情報分析基盤の構成
  • LogFlow => Kafka => K2(内製) => Hive/HBase

レピュテーション情報の生成
  • セキュリティにおけるレピュテーションは、IPアドレスに関する評価、あるIPが悪意ある攻撃者かどうか
  • 既存のレピュテーション情報は、43億あるIPv4のIPのうち、数万程度の網羅率
  • IIJでは、一般のセキュリティベンダでは入手不可能な大量のデータを持っている
  • 機械学習によって、既存のレピュテーション情報を教師データとして使用する
  • 様々なログから特徴量を抽出する
  • IPごとの特徴ベクトルを入力として機械学習を実施

IIJ C-SOCサービス

インシデントを検知〜通知〜対応〜対策まで管理

今後の取り組み

全ての人が安全にインターネットを利用できる世界を実現する

デブサミ2017「DeNAの機械学習基盤と分析基盤」講演メモ #devsumi


sonots先生の話を聞きに行ってきたので、そのメモを残しておきます。


  • 瀬尾 直利 氏
    • DeNA Co., Ltd.
    • AIシステム部 リードエンジニア

DeNAの機械学習基盤

  • ディープラーニングの基盤 => GPU基盤 という認識
  • GPUすごくて、CPU使って30日のところ、GPUを使うと4日くらいのオーダー

GPUの特徴
  • 並列処理が得意
    • CPUだと24coreとかのオーダー
    • GPUでは3000〜4000core
  • 分岐処理は苦手
  • 行列演算に向いている

GPU製品
  • NVIDIA Tesla
    • HPC向けにGPUシリーズ
  • NVIDIA GeForce GRID
    • クラウドゲーミング向け
  • AMD FirePro

NVIDIA Tesla
  • API
    • CUDA
    • OpenCL
    • DirectCompute

CUDAのアーキテクチャ
  • CPU(ホスト)からGPU(デバイス)にデータを転送
  • GPUで処理
  • GPUからCPUに転送

AI案件の環境
  • トライアンドエラーな開発用途
    • 占有GPUマシン
  • パラメータチューニング用途
    • パラメータを少し変えて大量に並列実行
    • チューニングの時だけ使う
    • クラウドのGPUインスタンスが相性が良い
  • サービス提供環境はCPUでもよい

オンプレGPU環境
  • Xeon E5 *2
  • NVIDIA Tesla *2

AWS
  • g2インスタンス
    • NVIDIA GeForce GRID
  • p2インスタンス
    • NVIDIA Tesla
    • 今は東京リージョンは使えないので、USリージョンを使っている

GCP
  • Alpha版
  • 申請したらk80が使える(p2インスタンスと同じ)

APIサーバ
  • 2つのフェーズ
    • 学習フェーズ
    • 予測フェーズ
  • 学習フェーズは開発環境で (GPU)
  • 予測フェーズが本番環境で (CPU)

実例
  • Chainer - Python
  • Django
  • ローカル Jubatus
  • Blue Green Deployment

機械学習支援ツール
  • GPUサーバのオンデマンドオートスケール
    • 並列で学習を走らせたいので、必要な分だけ自動で起動する
    • 終わったら自動で落ちる
  • ec2-scale-run
    • 既に立ち上がって使われていないインスタンスがいれば使用
    • AWSは1時間課金なので、すぐには殺さない
    • docker対応
    • ECSは使っていない
  • NFSマウント
    • 中間データや学習結果データは共有ストレージにいれている
    • Amazon EFSをマウント
    • 容量自動拡張、値段は高め(S3の14倍)
    • 東京リージョンでは使えない
  • スポットインスタンスも活用している
    • 70%OFFのコストで処理できることも

DeNA流データエンジニアリングの極意

データレイクとDWHに分けるべし
  • レイヤを分けておく
  • 全ては一度データレイク(HDFS)に入れて、そこから統合DWH(BigQuery)へ

  • データレイクに集める
    • 収集だけでも困難
    • フォーマットやカラムなど、同時に考えるのは難しい

ストリーミング収集にはバッファを設けるべし
  • ストリーミング収集
    • 利点:リアルタイム性がある
    • 欠点:運用が難しい
      • メモリリークを引き起こしやすい、再転送が困難、負荷上昇時に遅延発生
  • バッチ収集
    • 利点:プロセスが常駐しないので、メモリリークが問題にならない、データ取り直しも再実行でOK
    • 欠点:リアルタイム性がない、マシンリソースを最大利用するため、他に影響が出る可能性がある
      • 処理が終わったら全くリソースを使わない時間がある
  • 使い分け
    • ストリーミング
      • ログ収集
    • バッチ
      • DBのマスタデータの取り込みなど

  • ログ収集基盤
    • fluentdがログAPIにデータを転送
    • HDFSに格納

  • Importdb
    • sqoopをベースにした内製ツール
    • MapReduceでHDFSに格納

  • Cassandraをログのバッファレイヤーに使っている
    • 細かく書き込むとI/O負荷高い
    • 送信側(fluentd)にもバッファレイヤーがあるデータをまとめて送ることで効率化

Retryableにすべし
  • 手動で再実行する場合の考え事を少なく
  • 自動リトライできるように

  • べき等にすべし
    • リトライで同じデータを二重にいれてしまう問題など
    • 追記ではなく上書きを原則とする
    • それでも追記したい場合は、ユニークなjob_idを振って、リトライしても二重実行されないように

  • atomicにすべし
    • 途中までスカデータが格納されていない状態で、後続のジョブが走ってしまう問題
    • リトライすると格納先のデータが一時的に消されてしまい、データが存在しない瞬間が発生する問題
    • atomicな操作をストレージごとに調査
      • HDFSだとtmp領域に書き込んで、終わったらrenameする、など

  • uuidで重複除外すべし
    • ログにuuidカラム設けて、基盤側で重複除去

Validationすべし
  • 何もエラーが起こらずデータがnull値に変わっているような問題
  • Validationして早めに気づくべし

SQLで分析すべし
  • 生成系BIツールの問題点
    • 内部で複雑なクエリが生成されて異常に重い
    • やりたいことがサポートされていなかったり
    • 分析者が自分でSQLを記述すべし
      • 自由度高い

再取り込みを容易にすべし
  • 再取り込みは頻繁に発生しうる
    • データ遅延
    • データ不正
    • BigQueryが不安定、などで取り込み失敗

  • 極意
    • Retryableにすべし
    • 時間パラメータの指定を可能にすべし
      • デフォルト値としてのNOW()以外にも、再実行時に時間パラメータを指定できるようにしておく
    • データ発生事項でデータをわけるべし
      • データ発生時刻でディレクトリを分割する
    • データのつながりを管理すべし
      • ワークフローツールやJenkinsパイプラインで依存関係を整理する
      • Triglav活用
        • データ駆動ワークフロー形成ツール
        • データ駆動でつながりのないツールにつながりを持たせてワークフロー形成を支援するツール(OSS)
        • https://github.com/triglav-dataflow

追記

sonots先生が、資料を公開されていますので、そのリンクを。

2017/02/16

デブサミ2017「グランブルーファンタジーを支えるインフラの技術」講演メモ #devsumi


CAを離れて1年半。最近はどんな感じか知りたかったので聞いてきました。面白かったです。


グランブルーファンタジーを支えるインフラの技術

  • (株)Cygames
  • 佐藤太志 氏

グランブルーファンタジーについて

特徴
  • スマホのRPG
  • ブラウザゲーム
  • 協力プレイ、マルチプレイ

システム規模
  • 登録ユーザ数1400万人
  • 月間300億PV
  • 100万query/sec
  • 8万req/sec
  • トラフィック12Gbps (CDN除く)

システム構成
  • LBはBIG-IP
  • CDNはAkamai
  • HTTP/WebSocketがフロントインターフェース

  • Web: Apache + mod_php + mysqli
  • Node: Node.js + twemproxy
  • DB: MySQL + MHA

オンプレミス、仮想化環境は使っていない
  • ネットワーク通信量が非常に多い
  • 低レイテンシを求められている
  • ハイパフォーマンスを実現するため
    • NVMe SSDやFusion-ioを採用
    • ネットワークIRQのマルチコアスケーリングに対応したNICを採用

ログデータの取り組み

ソーシャルゲームとログ
  • CS対応、補填対応などのユーザ対応
    • CS最優先、数ヶ月前のログを調査する必要あり
  • KPI指標の取得
  • システム不具合の調査
    • エラーログやSQLログ
  • バックアップ
    • 不具合発生時の再現(スナップショットからの復元)

ログのデータ量は5TB/day
  • テキストログ(4.8TB/day)
  • DBインサートログ(180GB/day)

ログ肥大化による問題
  • 当初は、ログ集約サーバに転送し、ログストレージに深夜にrsyncしてた
  • ログ肥大化により、ログ集約サーバを分散したが、ログの転送が遅延し、CS対応に支障をきたし始めた
  • DBでもログが肥大化し、ディスク容量が枯渇したり、インサート処理が遅延

ログシステムの改善
  • Amazon S3にログを集約
  • 独自ログ転送エージェントを開発
    • テキストログ転送
      • 一行で送信できるサイズ制限を取っ払うため
      • S3オブジェクトのプレフィックスをつける
    • 非同期MySQLログ転送
      • TSVをS3に転送、SQSにメッセージキューを作成、EC2のアグリゲータでまとめて、Auroraへ

ログを活用
  • ログ転送エージェント => S3 => BQ, Mackerel, Kibana, Aurora, DWH分析等

Kibana
  • アクセスログ、APログ、エラーログから統計情報をビジュアル化
    • レスポンスタイムとか遅いURLとかエラー数とか
    • 特定地域ごとのエラーを可視化
      • 特定区域の通信障害などを特定させるため

Mackerel
  • Apacheレスポンスタイムを集計
    • 2秒以上の分布を可視化
    • twitterのキーワード検索も可視化
      • 「グラブル 重い」などのtweet

ログデータの取り組みまとめ
  • Amazon S3に集約
  • 非同期・マイクロサービス化
    • 非同期処理でゲームシステムとは分離
  • 独自エージェントの開発
    • コア技術は自前で開発するポリシー

リアルタイム通信の高速化

双方向リアルタイム通信が必要なところ
  • チャットでのメッセージ交換
  • マルチバトルでのパラメータ反映

双方向リアルタイム通信
  • WebSocketの導入
  • Node.jsで実装

リアルタイム通信のサーバ構成
  • サーバでは複数Roomが紐づく
    • クライアントはRoom単位でグループ化
  • アーキテクチャ
    • バランシング管理サーバモデル
    • Pub/Subメッセージモデル

バランシング管理サーバモデル
  • 管理サーバがクライアントやRoomの紐付けを管理
  • 管理サーバの冗長化を考慮すべきで複雑になる

Pub/Subメッセージモデル
  • メッセージキューを介してサーバ間でやりとり
  • メッセージキュがボトルネックになりやすい
  • ブロードキャストによる通信量の増加
  • Redis Pub/Subがボトルネックになった、またスケールアウトに課題
    • セット構成でスケールさせるように、8セットまで増大

Room対応のL7ロードバランサーを開発
  • アプリケーションはRoomIDをURLクエリストリングに付与
  • RoomIDのハッシュ値を使って分散

Nginx L7 ロードバランサー + Lua
  • NginxはWebSocketのLB
  • RoomIDからNode.jsプロセスへのルーティング
  • Luaで分散ロジックの実装
  • Consistent Hashingを活用
  • Nodeのヘルスチェックも行う (自動切り離し)

Nginxリソース状況
  • 同時19,000TCPセッションで、サーバのCPU使用率は3%になった
  • 負荷低いので、集約した結果、ポート枯渇に
  • カーネルパラメータ調整したり、TIME_WAITの残留時間を短くするためにカーネルのリビルドを行うも追いつかず
  • サーバに複数のIPアドレスを付与して、多くのポートを使えるようにした
  • 現状では、12万セッション/1台を捌けるようになっている

タグシステムと運用

大規模環境の運用
  • 複数サーバのリスト作成
    • 複数サーバに並列にコマンド実行
  • 故障機器の排除
    • デプロイ対象から排除
  • 運用情報の管理
    • 解析ツールのインストール情報
    • LBへの組み込み状況

タグシステム開発
  • サーバ情報インベントリシステム
    • サーバリスト抽出の簡略化
    • サーバの構築情報の可視化
  • 任意にタグ情報を付加できる
    • 事前にスキーマ定義は不要にしている
  • ElasticSearchにサーバ情報を登録し、全文検索できるようにしている

Kibanaで可視化
  • 開発エンジニアとWeb UIを通して連携
  • CLIでホスト情報(JSON)を取得できるようにした
    • DCとかEnvとかLBへの紐付けとかタグ情報で確認できる
    • サーバリストの取得

タグ運用のまとめ
  • 大規模運用の効率化
  • サーバ情報のテキスト管理からの脱却し、オペミスを防止
  • 各種ツールとの連携を促進

Cygamesインフラが大切にしていること

  • 当たり前のことを当たり前にやる
    • ボトルネックを作らないシステム設計
    • 枯れた技術を採用し、安定化を目指す
  • アプリケーションロジックを抽象化する
    • 冗長化・分散等のロジックはシステムで吸収・抽象化
    • 他プロジェクトへの展開を容易にする
  • コア技術は自分たちで実装する

2016/12/31

"元RX-7乗りの適当な日々"の2016年人気エントリランキング


2016年も残すところあと少しとなりました。

今年も当ブログへアクセスいただき、ありがとうございました。

例年通り、まとめの意を込めて、当ブログでの2016年のアクセスランキングを残しておきます。


今年の当ブログへのアクセス数(PV数)を確認してみると、昨年(2015年)比で約10%減という結果でした。何より、書いたエントリ数が少なく、昨日思い出しながら3エントリを書いたものの、それまでは8エントリのみしか書いてないという有様・・・。

ということで、例年通りの2016年に書いたエントリのランキングが出す意味があまりない、、、という情けない状況ですので、ブログ全エントリに対する2016年アクセスランキングを残しておきます。そんな状況でもそこそこアクセスが残せているという意味では、ありがたい話ではあります。


ちなみに、過去のランキングは以下のエントリを。


では、ブログ全エントリに対する2016年内のアクセスランキングです。

例年の傾向ではありますが、2016年に書いたエントリに限らず、それ以前の過去エントリの閲覧数が全体的に非常に多くなっています。(2015年のエントリはベスト10内で1つ。)


1. Linuxサーバがディスク容量不足になった!何か消さねば!ってなった時にどう対処するか


2. 様々なLinuxのOSバージョンを確認する


3. 新しい車を買いました「WRX STI tS」


4. Linuxで使っているNICのドライバやバージョンを調べる方法いろいろ


5. Linuxサーバに搭載されているCPUコア数の確認


6. psコマンドでスレッドを表示させたり、スレッドごとのCPU使用率を確認する


7. ある文字列をファイルの特定行に挿入するコマンド


8. ハネムーンで行ったタヒチの海が素晴らしすぎた件


9. 大容量ファイルのSCP転送を高速にする方法


10. 自分で自動車の名義変更(所有権解除)+住所変更をしてみた記録


次点



・・・と、2016年の当ブログはこんな感じでした。

これまで4年連続で1位だった「様々なLinuxのOSバージョンを確認する」は今年は僅差の2位となりました。

15位くらいまでは、昨年のランキングとほとんど同じような傾向で、息の長いTIPS的なエントリはそれなりに需要があり、1年くらいでは変化しづらい感じですね。


では、今年はこれが最後のエントリとなります。どうぞ、来年もよろしくお願い致します。

それでは、よいお年を!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


関連リンク




オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)