2018年9月1日土曜日

「GDG DevFest Tokyo 2018」に参加しました


Quick Start GCP

山内 沙織


  • GCPを使うデモ
    • Cloud Shell
      • Google Cloudを使うためのツールがそろっている
    • サーバレス
      • Cloud Functions, App Engine standard
      • オートスケール、使った分の課金 => サーバレス
    • Cloud Storage
      • Multi-Regional, Regional, Nearline, Coldline
      • アクセス頻度(左がアクセス頻度大)
      • オブジェクトストレージ、SQL、NoSQL
      • SQL: SQL(MySQL, Postgres), Spaner(大規模向け)
      • NoSQL: Datastore, Firestore(FirebaseのリアルタイムDBとDatastoreのいいとこどり) => 将来的に統合


PWAのイマ

takanorip


  • PWAの説明(略)
  • PWAのターゲット
    • 広く広めたい => PWA
    • デバイスのセンサーなどパワフルに使いたい => Native App
    • ロイヤリティでWebとNative Appの中間を埋める
  • ブラウザサポート
    • iOS Safariはプッシュ通知などサポートしてない。Service Workerのみ
  • PWA Checklist
  • PWA Starter Kit
  • pwa-helpers
  • PWAのこれから
    • Webの基盤になる
    • すでにAndroidが優勢な国ではPWAの成功事例が多くある
    • 日本はiPhoneが強いのでまだまだ
    • ネイティブとの棲み分けがはっきりと
  • ページをロードしたときにプッシュ通知の許可を求めるな!
    • プッシュ通知を許可するストーリーがアプリよりも重要に
  • 追加の設計が必要
    • オフライン時
    • 戻るボタンがない
    • スプラッシュ画面


GCPのデータベース・ストレージ

apstnbt


  • GCPのストレージを使う利点
    • 冗長化
      • ノードの冗長化
      • DC間の冗長化
    • スケーラビリティ
      • スケールアップには限界 => スケールアウト
      • シャーディング
    • コスト
      • 最大負荷に備えると普段無駄 => 負荷に応じてスケール
      • オートスケール
  • ストレージオプション
  • Bigtable (NoSQL) => Megastore (制約のあるACID) => Spanner (制約のないACID)
  • GCPのストレージプロダクトの基盤、ルーツなどが論文で公開されている
    • それがわかると、将来の見通しができる

Cloud Kata

sinmetal


  • GCPサービス組み合わせのカタ(デザインパターン)
  • LBを使ったWebアプリ
    • LBでURL分岐 => API(GCE), Video(GCE), 静的コンテンツ(Storage)
    • Cloud Storageで静的コンテンツ配信ができる
    • Cloud Network w/ Edge Cacheを静的コンテンツの前に
    • Logging => BigQuery で分析
    • Traceで詳細モニタリング
  • Queueを利用したkata
    • Push型、Pull型
    • App Engine Task Queue (Cloud Taskになる)
      • Pushの流量調整できる
    • Cloud Pub/Sub
      • Pushはスロースタート
    • Media Storage(Storage) => Push(Pub/Sub) => Watermark(Functions)
      • 大きめのタスクはPushとFunctionsでは厳しい
      • 安価なプリエンプティブVM + Pull Queueで重い動画の加工処理
      • リース期間を指定してタスクをPullして、終了後にタスクをdeleteするので、失敗しても、タスクが未処理でdeleteされることはない
    • IoT core => Pub/Sub => Dataflow 数秒枚に集計
  • 巨大ファイルのコピー: Instanceのsnapshotをとって再現
  • Identity Aware Proxyで認証、KMSで暗号/復号


Introduction of Polymer 3.0

kazuyoshi kawakami


  • Polymer Project
    • Chromeチームの中のプロジェクト
    • 目的:ウェブプラットフォームを進化させる
  • 2012年のWeb Components
    • Custom Element
    • Shadow DOM
    • HTML Imports
  • 2018年のWeb Components
    • すべてのブラウザで使える(FirefoxはPolyfill必要)
    • webcompoments.orgで共有
    • Angular, View.jsでも使える(custom-elements-everywhere.com)
  • Polymerキモい
    • polyfill
      • Polymerは当初はWeb Componentsのpolyfillだった
      • Polymer 2.0からpolyfill部分を切り離した
    • bower
      • 当時一般的。クライアントサイドのパッケージマネージャーとしてあっていた
    • HTML Import
  • Polymer 3.0
    • bower => npm
    • HTML Imports => JavaScript Module
    • TypeScript, Webpack, Rollupに対応
    • Polymer 3.0で完成
  • Next Polymer Project
    • Lit-html/Lit-Element
      • 軽量化したPolymer Element
    • Material Web Components
    • Polymer Starter Kit

GCPでつくるデータ処理パイプライン

永井 洋一


  • バッチ処理とストリーム処理両方を扱うケースが多い
    • イベント検知
      • ログ異常検知、トレーディングボット
      • 基本ストリーム処理だが、しきい値の調整にはバッチも必要
    • 機械学習の特徴量生成
      • リアルタイム・レコメンド、FX自動売買ボット
      • 学習データはバッチ、予測はリアルタイム
  • バッチとストリームを扱う場合の問題:別の環境が必要
    • プログラミングモデル:Apache Beam
    • 分散実行インフラ:Dataflow
    • その他
      • Dataflow + Beam:データ処理と分析
      • Dataprep:非プログラマ向け
      • Dataproc + Hadoop:Hadoop/Sparkユーザー向け
  • Apache Beam
    • 抽象データ(PCollection)と処理(PTransform)
    • PTransformのサブクラスによく使う処理がSDKで用意されている
    • I/Oに対応
  • Google Cloud Dataflow
    • 特徴
      • サーバーレス(処理で立ち上がり、終わると消える)
      • オートスケール
      • 負担の大きいタスクを動的にリバランス
    • 例:Wikipediaの日本語ページ230万ページの形態素解析が17分で$0.54
    • GCP連携:I/O対応、パイプラインのTemplate


Auto ML Overview

永井 洋一


  • Cloud Machine LearningとTensorFlowは難しく、APIは一般的すぎる
  • その間を埋めるAutoML:職人技を自動で
    • DeepLearningのハイパーパラメータの調整
    • ネットワークの構造の調整
    • ノード数、レイヤー数の調整
  • AutoMLを支える(と思われる)技術
    • 転移学習
    • Learning to Learning
  • AutoMLシリーズ
    • Vision
    • Natural Language
    • Translation
  • 使い方
    • プログラミング不要
    • 学習データ(入力とラベル)
      • 裏で、学習用80%、評価用10%、テスト用10%に分けられる
      • 分割を明示的に指定もできる
      • ラベルごとに100以上あると望ましい
    • 学習実行
    • 予測モデルをAPIで利用
  • お金をかければ、簡単に機械学習モデルが作れる
  • 用途は限定的で、分類問題がメイン



2018年4月26日木曜日

「第1回 カオスエンジニアリング入門 × 最新動向 × 実践知」に参加しました


NetflixやAmazonでカオスエンジニアリングを実践し、カオスエンジニアリングの第一人者であるGremlin社のCEOから情報がつまったカオスエンジニアリング概要が聞けました。
富士通の事例は、Gremlinを使って、モノリスの古いシステムをお試し環境でやってみた事例。モノリスでも効果があるとのこと。
ドワンゴの事例は、本番環境で実施した事例。メトリクスをしっかり検討していて、すばらしい第一歩のカオスエンジニアリング報告でした。

講演1-1:「カオスエンジニアリング概要」Kolton Andrus(Gremlin, Inc.)

当日流れた動画



---


カオスモンキーはカオスエンジニアリングを広めたけれど、ランダムに無計画にアタックするのがカオスエンジニアリングだと誤解をさせてしまったマイナス面もある。カオスエンジニアリングは計画的に実施して、学習するもの。

カオスエンジニアリングはコラボレーティブに行うもので、むやみに打ちまくるものではない。

カオスエンジニアリングという名前は、やんちゃな印象の「カオス」と洗練された印象の「エンジニアリング」が組み合わせっている。

なぜ今なのか。今は昔と違って、様々なソフトウェアに依存し、内部でマイクロサービスと連携し、外部SaaSと連携し、完全にコントロールできない。障害を予測するのは天気の予測と似ている。予測が難しい。ただ、天気と違って、ソフトウェアは実験ができる。

カオスエンジニアリングを実施するプロセスをGameDayとよんでいる。第一ステップは全員を集めること。ホワイトボードにアーキテクチャーを書く。エクサザイズの1つとして、ネットワークのあるところをみて、障害が起きたらと考える。こんな風に、異常がおきそうなところをリストアップする。

2013年のNetflixの1日の停止は非常に損害の大きい障害。稀にしか起きないが損害の大きい障害とのバランスも考慮したい。

カオスエンジニアリングに開発が必要ならやらないと言われたら、ダウンタイムでどのくらいの損害があるか考えさせる。

進め方。1つめは、関係者全員とのコミュニケーション。コマンドセンターが用意されるのが望ましい。Slackでもよい。ダッシュボードでメトリクスをみる。

基本的に本番環境からははじめない。開発環境、ステージング環境、シングルコンテナから始める。そして、測定する。中止の条件も定義する。カスタマーに被害を与えない。

実験の成果は予想していなかったこと。よく調査し、修正する。うまくできたら実験をスケールする。自信を持てたら広げる。スモールスタートでスケールさせていく。システムが正しく設定され、正しく動作することを確認することが重要。

午前2時にやるのではなくて、日中にやる。カオスをおこしても影響がないように。休みの前に上司に大丈夫かと聞かれたら自信を持ってYESと答えられるように。

講演1-2:「Gremlinご紹介」Matt Fornaciari(Gremlin, Inc.)


  • Gremlinは3つのコアでちょっとしたパラダイム変化をおこした。
    • Safety
    • Security
    • Simplicity
  • 3つのコマンドでインストールできる。
  • 2番目のステップはsyscheckコマンド。
  • 3番目のステップはクライアントの登録。


講演1-3:「SREcon Americas 最新動向報告」Tammy Butow(Gremlin, Inc.)


  • SREコン2018のトレンド。k8s & コンテナ、カオスエンジニアリング、SREチームの育成など6つ。
  • カオスエンジニアリング・ブートキャンプは250人くらい参加。その中で経験者は3人。
  • SLOはSREの重要なコンセプト。詳細はGoogle SRE本で。
  • SREコンの内容はWebサイトからみれる。
  • カオスエンジニアリングのslackコミュニティがある。
  • はじめてのカオス・コンが9月にサンフランシスコで開始される。

講演2:「ProjectWEBでのカオスエンジニアリング実践」延川 隆(富士通株式会社)



  • 1998年から続いている富士通のサービスProjectWEB。古いが利用者は多い。
  • システム構成はクラウドへの完全移行の過渡期で、オンプレとクラウドのハイブリッド
  • クラウド移行と信頼性を両立させるため、カオスエンジニアリングに注目
  • 原則で注目すべきは、本番環境で実施と影響を最小限にするということ
  • といっても、開発環境からはじめて、成熟してから本番環境へ
  • 海外では、金融機関などでも実施
  • 見える化、優先順位づけ、仮説立て、実施、測定、学習と改善 のループをまわす
  • プラクティス
    • チーム横断コミュニケーション
    • スモールスタート
    • ポストモーテム
  • ツール
    • コマンドセンター
    • ダッシュボード
  • 中止の条件を明確にしておくことが重要
  • マイクロサービスでは、サービス同士の接合点が増える。ここでカオスエンジニアリングが有効
  • モノリスでやって意味があるの?と思いつつ実施するはめに
  • とりあえず、簡単な環境を用意してGremlinを使ってみた
    • 簡単
    • できることも多い
    • DBにレイテンシを起こすアタックのデモ
  • Gremlin使うと簡単にはじめられる
  • やってみると面白い!でも、本番環境ではそうはいかないだろう
  • メンバーは新規と古参とどちらもいるとよい。お互いに補完できるから。
    • 新規はシステムの勘所がわからない、あるべき姿を提言しやすい
    • 古参はシステムの勘所がわかる、敬意を知りすぎているので、課題を課題と感じない
    • ただし、対立の構図にならないように注意
  • 次は冗長構成をつくって試した
    • GameDayのテンプレートを使った
    • 準備万端でGameDayに臨む
  • 環境の準備が大変。本番と違うので、動作が違うので、確認作業に時間がかかる。同時に、本番環境でやりたいと自然に思い、成熟度モデルは必然だと感じた
  • モノリスだから用意に制御できると考えるのは過信で、モノリスでも意味がある
  • 一目でわかるモニタリングは必須。技術のない人でもわかるレベルに
  • ミラーリングシステムで不整合が発生した場合の復旧作業が煩雑であることが判明
  • 煩雑な職人技こそ自動化する意義が大きい
  • 今後は、Docker環境でやりたい
  • まとめ
    • 分散システムでなくても効果がある
    • 必要なものは実施環境とモニタリング


講演3:「The Road to Chaos - Great First Step」本間 正大(株式会社ドワンゴ)


  • ドワンゴのシステム障害との戦い
    • SPFをつくらない、冗長構成に
    • マスターが落ちたり、再起動で同期が切れたり
    • テスト環境で障害テスト
    • 冗長構成では防げない問題がある、より洗練された障害テストが必要
    • そこでカオスエンジニアリングと出会った
  • 実践の4ステップ
    • 定常状態を定義
    • 障害を発生させても定常状態は変わらないという仮説を立てる
    • 障害を発生させる
    • 仮説を反証する
  • 定常状態とは正常稼働している状態
  • メトリクス
    • システムメトリクス
    • ビジネスメトリクス
  • 定常状態を定義するのに重要な特徴
    • カスタマの満足度と強い相関
    • リアルタイム性が高い
    • 計測が簡単
  • Netflixでは動画再生回数をメトリクスに、先週の波形を定常状態に
  • 5つの原則
    • 定常状態の振る舞いに仮説を立てる
    • 多様なイベントを取り入れる
    • 本番環境で実験
    • 継続的実行のため自動化する
    • 爆発半径を最小限にする
  • ドワンゴジェイピー、楽曲配信サービスで実践
    • SLA: 99.95%
    • 年商: 約70億
    • 機会損失率 x 単位営業実績 + 工数 = カオスコスト
    • カオスコストを教育費として承認をもらった
  • メトリクス
    • コンテンツのDL数:3つの特徴全てOK
    • システムの稼働率:3つの特徴全てOK
    • Apdex Score:3つの特徴全てOK
      • レスポンスタイムやエラーを考慮してユーザー満足度を測る指標
  • コンテンツデリバリーシステムのWebサーバを対象に
    • メインクラスタが96%、コントロールクラスタ2%、エクスペリエンスクラスタ(カオスを起こすクラスタ)2%でトラフィックをわける => 爆発半径の最小化
    • コントロールクラスタと比較する
  • 仮説
    • Chaos Lambda: AWSのEC2インスタンスを停止するツール
    • EC2の突然死を選んだ理由
      • よく発生する
      • 実験が簡単
      • ツールがすでにある
      • 予想&制御しやすい
  • 障害を発生させる
    • 前準備 => 実験実施 => 実験終了
    • 前準備
      • メトリクス選定の仕組みを実装
      • コントロール/エクスペリメントクラスタの作成
      • R53でトラフィックを制御
    • 実験実施
      • 12:00 - 18:00に30分感覚で実施
      • 既存監視のアラートがあがったら強制終了
      • メトリクスの逸脱は目視
    • 実験終了
      • 準備の逆
  • 仮説を反証する
    • コンテンツのDL数:障害がなくても定常状態が一致せず、定常状態に使えず
    • システムの稼働率:障害による変化なかった
    • Apdex Score:障害がなくても定常状態が一致せず、定常状態に使えず
    • ドワンゴジェーピーのコンテツデリバリーシステムはEC2の突然死に強い
  • 得られた知見
    • 物分かりのよいマネージャーが必要
      • コストのコンセンサス
    • 組織的なやりとりや文化づくりが重要
      • 安全な実験の責任を持つ
      • R53の設定でサービスに影響がでてしまった
    • 実験環境セットアップの自動化が必要
    • 正常に実験できていることを確認できる機構が必要
    • 緊急停止の自動化が必要
    • 実施前に実験手法の妥当性を確認すべき
      • R53のトラフィック分散は1日単位ではよいが、30分ではばらつく
    • 本番環境でやるべき
      • テスト環境とは差異がある
      • トラフィックが違う
  • 今後の課題
    • トラフィックのルーティング方法の見直し
    • イベント選定とツールの再検討
    • 実験の自動化
      • セットアップ
      • 緊急停止