TMD45'β'LOG!!!

Life is Beta-ful.

デブサミ2016冬 1日目 #devsumi

ノベルティで、CodeZine で連載されていた『風雲! ITおじさん』の単行本をもらいました。無料参加でももらえる 1,000 円の本。

風雲!  ITおじさん (CodeZine Books)

風雲! ITおじさん (CodeZine Books)

あと無料自販機と、バナナが食べ放題(kintone 提供のジャングルカフェにて)。

event.shoeisha.jp

2 日間まるまると長いので拝聴したものをざっくりメモ書き。さっくりと言いつつめっちゃ多いのでちょくちょく手直ししていくと思う。

【18-E-1】DevOps時代に明日から活かせるセキュリティ対策術

OWASP Japan 仲田さん

  • セキュリティ対策として考えなければならないこと
    • 立場(運用者かエンドユーザか)や工程により考慮すべきセキュリティ事象が異なる
    • システム知識が広く必要
  • 攻撃者は効率性を重視し「楽な対象」=セキュリティ対策の甘い対象を狙う
    • 攻撃にかかる負担やコストを高める、ちょっとしたセキュリティ意識向上やセキュリティ対策でも十分効果がある
    • ガチガチにすると逆に「攻略対象」となってしまうこともある
  • セキュリティ対策が後回しにされがちな理由
    • 非機能要件(品質の1要素に過ぎない)
    • ユーザの使いやすさに非直結
    • コスト・時間がかかる
  • しかし「セキュリティ対策は当然」とされた判例もある
    • "SQLインジェクション対策を怠ったのは重過失" → 損害賠償請求
    • クレジットカード情報を保存すべきでないという提案を原告が受け入れなかったので相殺
    • 受注側も発注側も認識しておく必要がある
  • 後回しにしないほうがいい理由
    • 「設計・開発工程」でセキュリティ対策するのが最も効果が高い
    • 「設計・開発工程」でセキュリティ対策するのが最もコストが安い
      • という統計?がある
  • どうしたらいいか
    • OWASP が指標やツールを提供してるよ!
      • 日本語で概要リストを作ったり、一部翻訳などもしている → 取り掛かりやすい
    • ドキュメントや診断ツールなど(全部無料、基本英語だけど一部日本語訳されたものもある)
      • OWASP Top 10 → 日本語訳: OWASP_Top_10_2013_JPN.pdf
      • OWASP IoT Top 10
      • OWASP Cheat Sheet Series
      • OWASP ZAP
      • OWASP ASVS
        • c⌒っ゚д゚)っφ それぞれあとで見る

発表前に(というか先日)OWASP ってなんぞや?と思ってサイト見に行ったんですが、正直なんだかわからずにそっとじしてしまったのよね…

なるほどそういう活動をしていて、そんな便利なものがあるのか、ってこの発表でやっとわかった感じ。

【18-B-2】データ分析で始めるサービス改善最初の一歩

IIJ 石原さん

  • これまでの運用
    • 単発の障害検知を目的にした監視システム
      • 社内共通の監視基盤(ping, snmp 等)
      • munin
      • エラーログ収集
    • ユニットテスト結合テスト中心の自動化
      • 定常的なパフォーマンス計測については手薄
    • できていなかったこと:サービス利用の全体傾向をつかむこと
      • 障害の全体像がわからない
      • 需要予測がしづらい
      • 予防的なパフォーマンス改善ができない
        • c⌒っ゚д゚)っφ わかる…
  • 手始めにログ収集・可視化
    • Flume でデータ収集
      • Flume: Fluentd, Logstash の類似ツール
    • Elasticsearch への蓄積、kibana による可視化
  • 問題点
    • ログの容量が多い → 長期間ログの保管できない
  • 対策
    • 収集するログを絞った → Apacheアクセスログのみ(ユーザ利用傾向だけなら十分)
    • Flume に Esper(SQL ライクにイベントデータの操作が可能)を組み込んでデータ集約
      • 一定時間ごとにログを収集し、アクセス総件数など計算結果を収集
  • 「可視化だけ」で不足する点
    • 人の目に頼った判断
    • ログ集約によるデータ落ち
  • さらなる対策
  • アクセスログ解析でわかること
    • 例:API アップデート前後の処理時間の変化
      • 極端に遅いリクエストがなくなったことがわかった(ログ集約時は落とされてしまっていた情報)
  • まだ残る問題点
    • 人の目で結果を判断する。経験に依存する → 全量ログを活かした機械学習
  • 機械学習
    • 異常値に関する指標を探す。可視化してまずは人が探す
    • 適切なアルゴリズムを選ぶための試行錯誤
  • 機械学習たいへん?
    • R はライブラリが豊富で、試行錯誤は簡単
    • 簡単な解析でも思っているよりずっといろんなことがやりやすくなる
    • より客観的・継続的な改善のためにデータ分析を軸にした方法は有用
      • 昔に比べて環境が整っているので「とりあえず」やってみてもいい

お昼休み

ランチセッションで SPA の話聞きたかったけど、混んでる風だったのとお腹すいたのでさっさと外に出た。が、なかなか席の空いてるお店が見つからずうろうろ。ガストで普通のハンバーグ食べてきた。注文も会計もなかなか時間がかかってギリギリアウトで午後のセッションに戻る。

っていうかランチは今半のサンドイッチが出てたらしい!参加すればよかった!!!(後悔

【18-A-3】 myThingsからみたIoTの未来と課題

Yahoo! JAPAN 山本さん、倉林さん(ID連携絡みでお世話になってますm(__)m)

  • 商業系 IoT
  • myThings の立ち位置
    • IoT サービス同士の連携
    • IoT サービスをセンシングして、他の IoT サービスに連携する
    • 「モノがインターネットに繋がる」だけじゃない
  • 試作とユーザ体験をサポート
    • 量産は?
  • IoT で現実世界の課題を解決できるか
    • 限界集落と連携して、実際に課題解決に取り組んでいる
      • 獣害対策
      • 生活インフラの監視
  • 量産について…など
    • c⌒っ゚д゚)っφ ちょっと分量多いので別途まとめる。Y!さんの資料ってアップされるのかしら…とてもためになるお話でした
  • 安心・安全な IoT を提供するにあたって考えなければいけないことはたくさんある
    • 試作から量産に向けての技術的ハードル
    • 数年前より "試作" のハードルは下がった

【18-C-4】 大規模Redisサーバ縮小化への戦い

株式会社アカツキ 駒井さん。ゲームアプリシステムのはなし

  • Redis ってマージできるの?
    • Redis ドキュメント → のってない
    • AWS ドキュメント → のってない
    • GitHub で見つけたツール → make できない…
    • 結果、自分たちで頑張ってマージ
      • 方法① 単純に K/V を抜き出して別 db へ
        • 全 K/V 走査が必要
      • 方法② dump ファイル(バイナリ)を出力して結合
        • ヘッダとフッタをいじったらいけそう
        • フッタの checksum (CRC64)をちゃんとするの忘れずに
        • dump データのチェックするコマンドがある
          • $ redis-check-dump [dumpファイル名]
  • 1回目の方法 → ②案
    • EC2 サーバ上に redis-server つくって Elasticache Redis の read replica にする(?)
      • dump 取るのにコツがいる?(メモとりそこねた…)
    • dump ファイルを処理
    • S3 上に権限つけて配置
    • Elasticache へリストア(上の S3 からできる)
      • cache.r3.large 8 台に
  • 後日、ゲームイベント時にアプリケーションサーバ追加
    • Redis の connection が上限に達した!
    • maxclient 65000 → AWS はこの値 変更不可
      • $ redis-cli -h {host} -p 6379 info
    • 100 サーバ x 50 Unicorn プロセス x 16 DB = 80000 clients
      • Redis の複数 db 利用したことが仇になった(1 Redis 8 db 利用)
      • 今度は db を減らす必要が出てきた
  • 2回目の方法 → ①案
    • Elasticache から K/V 読みながら処理しようとするとめっちゃ遅い
    • EC2 上の redis-server にリストアして、そこで操作したほうがはやい

タイトル見て、これ以上どうしようもなさそうなキャッシュデータをいかに小さくするか、っていう話を期待したのだけど、「緊急でサーバ増やしたときにゴミデータ大量に作った」「不要データ消した空き領域を潰すためにデータマージする」という話だったのでちょっと違ったかな。

Redis の dump データの構造とか EC2 も使って作業するとかは、興味深かった。

【18-A-5】 Yahoo! JAPANの実践から学ぶ、超大規模Webシステムのフロントエンドとインフラ

2コマセッション。

大規模開発におけるこれからのフロントエンド開発

Yahoo! JAPAN 柴田さん

  • 最近の傾向
    • (略)
  • Yahoo! JAPAN の現状
    • (略)
  • 技術選定の方法
    • 技術進歩の種類
      • 言語仕様
        • 言語仕様の発展
        • polyfill を使って未来を先取りし、プロダクトの寿命を伸ばせる
      • 概念
      • フレームワーク
        • 機能的には近しいものが多い
        • 今後の言語仕様に沿っているかどうかが長生きの鍵
    • いつ取り入れるのか
      • 何事もすぐ取り入れるのは危険
      • バージョンアップも多い
        • 大規模アプリではライブラリのメジャーアップデートはリスク
      • 話題に上がってから半年〜1年でも生きてるとよさそう
  • 大規模アプリケーション
    • 必要なこと
      • 仕組みの共通化
        • 命名規則、コーディング規則 → ESLint
        • テストの構成
        • スクランナー
        • プルリクのフォーマット → CONTRIBUTING.md
      • モジュールの共通化
        • 使っているフレームワークが異なると難しい
        • ディレクトリ構成を出来る限り揃えるだけでも十分効果はある
        • ユーティリティを揃える
      • 属人性の回避
        • 担当プロダクトの専任になりがち
        • 担当者をシャッフル
        • 別プロダクトをレビュする
        • 別プロダクトのテストを担当する
  • まとめ
    • 言語仕様の未来を見据えて技術を選ぶ
    • (他メモ取れず…)

Yahoo! JAPANが実践するOpenStackと大規模環境でのコンテナ利用

Yahoo! JAPAN 伊藤さん

  • データセンタを支える OpenStack 事例紹介
  • アプリケーションレイヤまで継続的なライフサイクル
    • アプリケーションの実行環境は人が選ばない
      • どこでデプロイされるかは関係ない
    • どこで実行されるのか
      • VM
      • コンテナ
      • ベアメタル
    • コンテナのいいところ
    • コンテナの注意点
    • 向き不向き

(全体的に省略…手元のメモ大杉〜)

【18-B-6】 マイクロサービス時代の大規模動画配信基盤 〜 Ruby × Go = ∞

DMM.comラボ 小嶋さん、江藤さん

  • スライドの!マイクロサービスTIPS!を見るんだ!!

個人的には一番良かったなと思った。マイクロサービス化することで、Go が合うサービスでは Go を、RubyRails)が合うサービスでは Rails を使った、という意味で掛け算っぽい。1つのでかいサービスになってたらそんな切り分けもできないという話。

技術選定の仕方とか参考にしたい。あとこの発表見てやっと Go やりたくなってきた。

【18-E-7】 デブサミ恒例!コミュニティLT2016

司会は急遽、楽天の吉岡さんに(予定されてた方は風邪?インフル?だとか?お大事にです…)

各コミュニティ、どれも面白そうだった。興味深い。

秋葉原IT戦略研究所 いいなぁ。オタク文化✕ITいいですよね。でも私最近のアニメはあんまり興味なくて、漫画のほうで何かやりたいんですというか、ちょっと手を付け始めてはいるのだけど…だれか書籍の "シリーズ" データマスタ API とか提供してくれてませんかね…(個人的には "続きが読みたい!" のシリーズ情報がすごく魅力的なんだけどね…)

その他 感想

今回、1万円で個人スポンサーになってみた。VIP 待遇気持ちイイです。雅叙園のスタッフさんが「お席こちらになります^^」ってエスコートしてくれたこの VIP 感よ…

個人スポンサー専用席(電源と机付き!)が各部屋に 15 席〜 20 席くらい用意されていて、各セッションの事前予約不要で、ほぼ確実に好きなセッションが聞ける。事前予約されてる人たちが会場入り(参加証の読み取りをやってるのでそこそこ時間がかかる)してから余裕で入れるので、長めにとられている休憩時間もゆっくりできる。最高。

お昼食べるところなかなか見つけられなくて、入ったはいいけど会計に時間かかって、午後の発表開始ちょっと過ぎてしまったのだけど(それ自体は申し訳ない…)個人スポンサー席のおかげで聞きたい発表を聞くことができてよかった。

1日換算 5,000 円、書籍 30 %OFF付きでこれ、すごくイイと思う。次回参加するときにはまた利用しよう。

😷 👿 😷 👿 😷

それにしても今週は喉の調子を崩してしまって、咳は出るは、声は出ないわ… 発表を聴いてる間もできるだけ抑えてたけど、突発的に咳出てて申し訳なかった。 ブースで話聞いたり、誰か捕まえてご飯行ったり、見かけた人に挨拶したりしたかったけど、喋れないのでなんともできなくてつらたん。

▲ ページトップへ移動