2018年11月25日日曜日

「HTML5 Conference 2018」に参加しました


矢倉さんのセッションの、「Webは小さな仕様をつくる流れで、ライブラリを作りやすくする低レイヤーを整備(レゴブロックのように)」というのが印象的だった。基調講演のえーじさんの説明と合わせて、Extensible Web Manifestoが今回ようやく腹落ちした。
後は、最後のWebXRの未来感がすごくて刺激になった。

私が参加したのは次のセッション。

基調講演

吉川徹、えーじ、岩井将行



  • 1ヶ月にWebにアクセスするデバイスの数: 50億以上
  • Webの進化
    • 動画、Picture in Picture
    • WebRTC: ビデオ会議など
    • WebXR: WebでAR/VR
    • Web Authentication: 指紋や顔でログイン
    • WebAssembly + Web Audio: EUROPAのデモ参照
  • 仕組みを作る仕組みを、作る仕組みを作る
    • 「仕組みを作る仕組み」= web を作る仕組みを作る
    • オープン性
      • GitHubで議論
      • Browser Feature Status Dashboard
    • 相互運用性
      • 2つ以上のブラウザが実装しないと標準として認めない
      • Origin Trial
        • オリジンを限定(申請)して、新しいAPIを一定期間実験的に試す
        • ベンダープレフィックスによる混乱から生まれた
      • Extensible Web Manifesto
        • 低レイヤーのAPIをまず作る
        • 例)Web Components, CSS Houdini, Service Worker
      • Layered API
        • virtual-scroller: 画面全部のレンダリングをスクロールに応じて動的にして、パフォーマンスを改善(ネイティブやReactでは普通に使われている)
        • async local storage
    • AMP (Accelerated Mobile Pages)
      • ページの高速化
      • 多くの制約(により高速に)
      • Web Componentesベース
      • 課題: URLが変わってしまう(Googleのキャッシュから配信するため)
      • Web Packaging => URLが変わらないようにできる
        • Signed Exchange, Bundled Exchange
      • Feature Policy
        • 利用できる機能を制限、もしくはレポートを受け取る
  • "Web is the only platform no one owns." Dave Winer
    • Webをよりよくするために
      • 勉強会への参加・登壇
      • ブログを書く
      • ドキュメントの翻訳(MDNの翻訳会もある)
      • 仕様やブラウザベンダーへのフィードバック


ZOZOのグローバルECのフロントエンドアーキテクチャ設計

権守健嗣


設計を見直す上で考慮した技術とアーキテクチャー

  • アプリ全体のアーキテクチャーを意識しておらず、フロントがアプリ層、データ層にも、バックエンドがプレゼン層にも介入
    • アプローチ1: フロントエンドがビジネスロジック(アプリ層)を持つ
      • クロスプラットフォーム実装: React Native, Weex, Flutter, Xamarin, NativeScript, Cordova, Titanium Mobileなど
      • Webも使えるもの
        • Cordova: 遅い
        • Titanium Mobile: 情報がない
        • Kotlin/Native, Kotlin/JS: セキュリティを考えると難しそう
    • アプローチ2:それぞれでアーキテクチャーを持つ
      • クリーンアーキテクチャーの思想を導入
      • Vue.jsのコンポーネントがUse Cases(ビジネスロジック)を包含
      • domainディレクトリ配下にRepository, Entityを配置
      • applicationディレクトリ配下にサービスやモデルを配置
    • フロントとバックエンドでAPIに求めることが違う(フロントは一括でほしい、バックエンドはシンプルにしたい)
      • BFF (Backends For Frontend): 実装大変、パフォーマンスに影響
      • GraphQL: フロントはクエリでデータを一括でとれる、バックエンドはシンプルにできる
  • 状態管理: VuexのSingle source of truthを実現できていないため、状態変更が正しく検知できない
    • 状態変更の検知
      • レスポンスで変更したリソースを返す: API内部の非同期変更に対応できない
      • ポーリング: リアルタイム性が増すと、サーバーの負荷が大きい
      • サーバープッシュ: コストに懸念
        • WebSocket, Server-Sent Events, gRPCの双方向ストリーミング
    • 現在は、フロントで適切に情報を取りに行くことに
      • Vuexの使い方: StateをやめてPage単位で管理
      • 共通はcommonを用意
      • ディレクトリ構成を整理



2018年のHTMLやCSSやAPIとか

矢倉眞隆



  • Webは30間近(1989年3月誕生)
  • Webページからはじまり、Web 2.0でJSが再発見、HTML5で勢いづく、最近は落ち着いた?
    • 大きな仕様はつらいので、小さな仕様をつくる流れに
    • ライブラリにやさしく、ライブラリもプラットフォーム、ライブラリを作りやすくする低レイヤーを整備(レゴブロックのように)
  • HTML
    • 画像関連
      • lazyload: 遅延読み込み
      • importance: 読み込みの重要度
      • decoding: 遅延デコード
      • 使い方
        • カルーセルの最後の方の画像のimportanceをlowにする
        • 真ん中くらいの画像はlazyloadをonにして、フッターの画像はimportanceをlowにする
    • フォーム
      • (inputmode)
      • enterkeyhint: Enterキーの見た目を変える
      • passwordrules(提案中)
    • スタイルの共通化
      • <fieldset>と<legend>
      • <button>
      • スタイルのリセットをしやすいように
  • CSS
    • レイアウト
      • Gridが使える
      • Subgrid提案中
      • Flexboxにgapプロパティ(Firefoxのみ)
    • フォント
      • Fonts Module Level 3
      • Level 4のVariable Fontsも対応(MS Edgeのデモサイト参照)
      • ダイナミックサブセッティング(必要なものだけとってくる)の標準化が検討中
    • Scroll Snap
      • スクロールをピタッとさせる(スライドみたいに)
    • Scrollbar styling
      • スクロールバーの色と幅をカスタマイズ(scrollbar-width/color)
    • Houdini
      • WebKitで実装開始
      • Custom PropertiesをCSSだけで書けるように
  • WebComponents
    • WC元年(FF実装、Edgeが実装開始)
    • 検討中の機能もたくさん
      • Form participation
      • Template Instantiation
      • Lightweight default styling
    • WCは「HTML要素をつくる」もの、フレームワークとは補完関係
  • 新しいものを探せそうなところ
    • Google Developers
    • Mozilla Hacks / MDN


Web Components のリアル

aggre

資料:https://speakerdeck.com/aggre/realistic-web-components

  • Web Componentsの近況
    • Chrome, Safari, Firefoxはpolyfills不要、EdgeはDevelopingに
    • polyfills: webcomponents.js
  • Web Componentsの基本
    • Custom Elements
    • Shadow DOM
    • ES Modules
    • HTML Templatesは開発者は直接使わない
    • HTML Importsは非推奨
  • Custom Elements
    • 標準のコールバック機構を持ったクラス
    • constructor()
    • connectedCallback(): 小要素として接続されたとき
    • disconnectedCallback()
    • observedAttributes(): 属性が変更されたとき
    • adoptedCallback(): あまり使わない
  • Shadow DOM
    • DOMをカプセル化
    • CSSが外に影響しない
    • <slot>: Shadow DOMをつけると、元々の中身が消える。消えた中身はslotに入る
  • プロジェクトを超える
    • 例えば、ブランドアセット(<brand-mark>を定義)
    • ライブラリ
      • 例えば、次のようなものは、VueでもAngularでも何でも使える
      • <iron-autogrow-textarea>
      • <pinch-zoom>
    • ライブラリを探す場所
      • Webcomponents.org
      • GoogleChromeLabs
  • マイクロフロントエンド
    • Web Componentsの中にReactを隠蔽することもできる
    • ページの関心事と技術的関心事を分離する
  • SSR
    • SSR用のDOMを用意しておいて、アプリで書き換える。さらに、slotを使うと、Shadow DOMから自由にいじれる。
  • 現実的な手法
    • lit-html: 属性値が文字列になる制約がある、Functional Programingにはおすすめ
    • lit-element
    • Angular/Vue


Web プラットフォーム再考 ~PWA のもたらす未来の光と影 ~

ものえおさむ、eegozilla、chikoski



  • PWAの基本
    • PWA: ネイティブアプリのようなUXを提供するWebアプリの概念
      • オフラインサポート
      • プッシュ通知
      • バックグラウンド処理
      • アイコンの追加(インストール)
    • PWAの価値を高めるAPI: CSS3, WebAssembly, WebVR, Web Payment
    • PWA採用例: Twitter Lite, Instagram, Googleマップ
  • PWA vs モバイルWeb vs モバイルApp
    • 機能: Web = PWA < Native
    • 開発
      • Web/PWA: JS / 任意エディター / Webブラウザ配布
      • Native: PFごとの言語 / PFごとのIDE / PFごとのアプリストア
    • ユーザー体験
    • アプリの審査、購入と課金: アプリストアがやってくれていることも多い
  • PWAはユーザーにメリットがあるのか?
    • Packt(電子書籍)
      • プッシュ通知でのセールおしらせは便利
      • タブと検索窓がないのがつらい
    • Qiita
      • ググった後、強制的にPWAに飛ばされる
      • 記事をタブで残しておけない
    • Yahoo! JAPAN
      • ホームアイコンのオファーがうざい
      • ながら見なので、ホーム画面においてもメリットない
    • ABC 2018 Spring(発表者自作のイベントサイト)
      • キャッシュのせいで思ったように更新されない
      • 端末ごとの挙動の差
    • ユーザーにとってのメリットをよく考えないとかえってUXが悪くなる
    • パフォーマンスがPWAがネイティブに勝ることはない
  • ユーザーのパラダイム(マジョリティのマインド)を理解して、PWAの機能を使うべき(自分のプレゼンスのためではない)

WebXR: Beyond WebGL

小山田晃浩



  • WebXR Device API
    • ARとVRの両方のAPI
    • KhronosのOpenXRとも連携している?
    • Chrome Canaryでhttps/localhostで動く
  • ARのレイヤー
    • XR imaginary
    • WebGL scene
  • デモ
    • ARで床にキューブをおく
    • ARで床にきのこをはやす
    • ARで床にりんごをおく
  • glTF
    • 3Dモデルのフォーマット
    • Facebook、MS Officeなどが対応
    • Facebookに投稿
    • パワポにはりつけてアニメーション
    • CodeGridのglTF入門の記事参照
  • セキュリティ
    • 視線トラッキング
      • バーチャルキーボードの入力をチート
      • 視線から状況をチート
    • etc
  • まとめ
    • WebXR Device APIでブラウザさえあれば、WebでVR/ARが可能になる
    • iOSでは、制限はあるがすでに実現されている
    • glTFが重要な標準になる


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分ではばらつく
    • 本番環境でやるべき
      • テスト環境とは差異がある
      • トラフィックが違う
  • 今後の課題
    • トラフィックのルーティング方法の見直し
    • イベント選定とツールの再検討
    • 実験の自動化
      • セットアップ
      • 緊急停止

2017年11月18日土曜日

「秋のJavaScript祭 in mixi 2017」に参加しました


知らなかったことも色々とあって、とてもよい勉強会でした。新しく知ったキーワードはちゃんと調べなければ!

p5.jsによるサウンドパフォーマンス
Processing的に書いたコードを実行できるJavaScriptライブラリ「p5.js」は、グラフィカルな表現を簡単に表現できるだけでなく、p5.soundライブラリを使うことで、音楽的な表現も手軽に実現できます。
JavaScriptでの表現では、音が扱われることはあまり多くないように思いますが、p5.jsを使ったサウンドパフォーマンスを通じて、楽しみながら、音のプログラミングへのきっかけになればと思います。
Webサイト 佐藤 好彦
iPadを動かしならが音の高低などを変えるデモからはじまって、ノイズなMIDIなど様々な演奏をキーボードで。もはや、Webで楽器がつくれる時代に。

演奏は次のサイトで試せる!

Nuxt.jsで変わる開発フローとUniversal JavaScriptのイマ
Vue.js で作られたフロントエンド開発のフレームワーク Nuxt.js の正式版がいよいよ公開されようとしています。
ここ1年ほど、徐々に実例が増えてきたサーバーサイドレンダリング。そのサーバーサイドレンダリングを簡単に行うことができ、かつフロントエンドとサーバーサイドレンダリングを共通のコードで動かすことが可能な「Universal」なSPAを開発する第一歩となればと思います。
花谷 拓磨
HTML5Experts.jpでNuxt.jsの基本を紹介。今日は概念的な話。Isomorphicと呼ばれていた概念が、Universalに形を変えた。今はSSR(Server Side Rendering)は自作しないことが多い。React向けのSSRエンジンとしNEXT.jsが、Vue向けのSSRエンジンとしてNuxt.jsがでた。これらを使うと、コマンド一発でSSRできる。SSRは作るモノから自然とついてくるモノに。

Nuxt.jsはSSRのためだけのものではない。Babel、webpackなんかの面倒な作業をまとめてやってくれる。starter-templateも充実。SPAを静的サイトとして書き出しすこともできる。SPAのヤクの毛刈り、SEO対策などの面倒な問題を解決してくれる。

Vueの開発パターンの統一、静的サイトジェネレータの必要性、SEO対策を解決。Nuxtによって、コーダー的なWeb屋もSPAエンジニアもどちらもハッピーになる。

three.js基礎
ブラウザだけで本格的な3D表現ができる、threejsについて話します。はじめにthree.js公式のhello worldを教材として、必要となる基本的な考え方を説明します。次に自作モデル読み込み方法、テクスチャアニメーション、HUDレイヤ作成等のthree.jsのTIPSを紹介します。
株式会社オープンストリーム 竹内 佑介
立体がくるくる回るHello World的なコードでさえ複雑。しかし、難しく見えるのは3D特有の概念を知らないから。Render、Camera、Scene、Mesh、Geometry、Materialの6つの概念。

これがわかると、難しくみえたコードも、6つの概念を初期化とrequestAnimationFrameを使った無限ループだけ。

キャラクターのアニメーション、画面を動かしても固定にするゲージなど、各種Tipsは以下のサンプルで。

ゼロから始める? Service Worker
Webkit の Indevelop 事件以来、Service Worker に希望が持てるようになりました。Service Worker で何ができるのか、基本的な機能や挙動から導入の際の注意などをお話します。
株式会社 Nagisa 宮崎優太郎

Service Workerはブラウザとサーバーの間に位置する。主にCacheやWeb Pushで使われる。同一オリジンのスクリプト、HTTPSが必要がある。

ライフサイクル。Resister, Installed, Activatedで一度止まる。2回目のアクセスから有効になる。初回から有効にするには、clients.claim()を使う。アプリを使っている途中でふるまいが変わるおそれがあるので、なるべくならclients.claim()を使わない方がよい。

バージョンを上げるなどの条件で、Updateが走る。そこで一度止まる。理由は同じ。skip.waiting()を使うとこれもスキップできる。

Pre CacheはSWインストール時にキャッシュ。Runtime CacheはFetchイベント時にキャッシュ。これらのコードは単調なので、GoogleChrome/workboxなどのツールを使うとよい。webpackだったら、workbox-webpack-pluginなどを使うとよい。

Web Pushは、通知の送信者、受信者に加えて、Push ServerやブラウザベンダーごとのGatewayがあり、なかなか難しいので、PushWooshなどのサービスを使うことが多い。

Polymer の update に見る Web Components の過去/現在、そして未来
Polymer Summit 2017 にて Polymer 3.0 の tech プレビュー版が発表/公開されました。そこで見えてきたのはブラウザサポートにおける Web Components 仕様の変化でした。
本セッションではそれらを含めたWeb Componentsの過去から未来まで解説します。
永和システムマネジメント
ブログ@sizuhiko
岸田 健一郎
スライド「Polymer の update に見る Web Components の過去/現在、そして未来 / jsfes-2017-autumn」

Web ComponentsはCustom Elements, Shadow DOM, HTML Templete, HTML Importsの4つの仕様からなる。これらを簡単に使えるのがPolymer。仕様が変わったりしても、Polymerを使っていれば吸収できるメリットもある。

今や8割がアプリからのアクセスでWebからのアクセスは2割のみ。それをなんとかしようとWebの人がPWAなどでがんばっている。日本では、Polymer Japanというコミュニティができた。

PolymerはHTML Importsではなく、JS Modulesを採用した。これによって、ほぼ全てのブラウザで動くことに。
最新のPolymerでは、BowerからYarn + npmに変更された。Yarnは使わなくなるかもしれない。
Polymerは他のフレームワークからも使える。Angular, Vueは問題なし。Reactは少しうまくいかないことも。

MongooseOSでJavaScript IoT事始め
MongooseOSは、マイコンに直接書き込むことのできるIoT特化型OSです。ブラウザ上でJavaScriptを使ってIoTプログラミングをすることができます。
今回はMongooseOSを使ったJavaScript IoTの紹介と、その技術を応用した実際のモノづくり事例をお話します。
オイシックスドット大地株式会社 Engineer 
篠原弘光
スライド「Mongoose OSとIFTTTでJavaScript IoT事始め / IoT with Mongoose OS and IFTTT」

IoTはハードウェア、組み込みといったイメージがある。フロントエンドの技術で手軽にIoT開発ができる。

Wi-FiとBluetoothを搭載した開発ボード(ESP32など)が3000円くらいで手に入る。また、Grove Systemというものがあり、差すだけで簡単につなげられるセンサーがたくさんある。

MongooseOSはコマンド一発で開発ボードにOSを書き込める。MongooseOSエディタでを起動すると、すぐにJavaScriptで開発ができる。

IFTTTのWebhooksをたたいて、イベントをおこす。例えば、Push Bulletというサービスにつなげば、Push通知がだせる。

RxJSで始めるリアクティブプログラミング
Angularが正式採用したことから注目を浴びている「RxJS」。RxJSは多機能で色々な事ができる反面、慣れるまで使い所が難しかったりします。今回はそんなRxJSの基本と学び方、そして使い方などのお話をいたします。
株式会社トゥーアール 
to-R
西畑 一馬
RxJSは敷居が高い。サンプルコードをみると、jQueryだと簡単なものもたくさん書かなければならないので、面倒そう。100種類位の関数があるのでそれを使いこなす必要がある。Lean RxJSというページが便利。

RxJSの利点はある程度使いこなさないとみえてこない。ただし、そこまでいくのは大変。理解するポイントは3つ。非同期、リアクティブ、データストア。

非同期は、forkJoin、concatAllなどを使う。JSでもできるが、非同期処理をうまくさばける。
リアクティブは、ストリームの値に応じて処理を実行するということ。一つのイベントで複数の処理をできるのも特徴。SPAでは1つの情報変更で多くの処理が発生。
データストアは、Angularでデータストアのために使える。

GAS(Google Apps Script)がつくりだすJavaScriptとIoTハードウェアの禁断の関係 
JSでIoTというと、Johnny-Fiveが有名です。しかし、安価なマイコンボードでは、Johnny-Fiveをその上だけで動かすことは困難で、必ず母艦となるPCなどのデバイスが必要になってきます。
そこでGASのWebAPI機能を使って、母艦のPC不要を不要にしつつ、マイコンボードへのプログラミングを最小限にして、メインのロジックをGAS上で書く手法を紹介します。
ブログ 
Twitter
ポキオ
今、WiFiが使える安価なマイコンボードがいっぱいある。Rasbrry Pi, ESpr, Nefry, ESP32など。

マイコンボードによっては母艦PCが必須に。ラズパイとJonny-FiveがあればOK。非力なマイコンボードでどうするか?

例えば、外部のサーバーからAPIでデータをとると、認証とかパースとかが大変。それを、GAS (Google Apps Script)でやるとマイコンボードはハードに関する処理だけに。GASはWeb APIを簡単につくれるのでいろいろとできる。

サンプルコード
https://github.com/pokiiio/2017-11-19_JSFES

2017年5月30日火曜日

「Mesos Meetup Tokyo #1」に参加しました


「Mesosってなに」からデモもあって初心者にとってはとてもわかりやすいMeetupで、非常に勉強になりました。資料だけでなく動画もイベントページで公開とのこと。すばらしい!

Opening、会場説明


Mesos User Groupsは世界で25都市が登録。Mesos Conなどが開催されている。
Mesos User Group Tokyoは、2ヶ月に1回位勉強会を実施予定。

Mesosは、2009年の論文からスタートし、2016年頃にコンテナ技術の発展とともに盛り上がり始めた。今、最も注目されている技術の1つ。

Mesosってなに



質問「Mesos使ったことある人?」 => 半分くらい

Apache Mesosの概要


仮想化環境のシステム管理では、クラスタのリソースを効率的に管理するのが難しい。今までは、クラスタは組めても、クラスタ個別の最適化まで。
データセンターのリソース全てを管理するのがMesos。Lunuxカーネルのリソーススケジュールと同じ原理でデータセンター全体を管理する。

Apache Mesosのメリット


これまではクラスタ個別の管理のため、リソースの有効活用に限界があったが、Mesosを使うと、データセンター全体でリソース配分ができ、データセンター全体で最適なリソース配分ができる。

Apache Mesosの生い立ち


2009年の論文がスタート。
2010年にはTwitterが使い始める。
2011年にMesosという名称になり、データセンターのリソース最適化というコンセプトになる。
2013年にMesosphereという会社が立ち上がる。
2016年にコンテナオーケストレーションが盛り上がり、その1つとしてMesosも盛り上がりはじめる。

Apache Mesosの主な特徴


http://mesos.apache.org/


  • LINEAR SCALABILITY
  • HIGH AVAILABILITY
  • CONTAINERS
  • PLUGGABLE ISOLATION
  • TWO LEVEL SCHEDULING
  • APIS
  • WEB UI
  • CROSS PLATFORM


Mesosの導入企業


airbnb, NETFLIX, UBER, Twitter, yelpなどモダンなサービスの多くでは既に採用されている。

Apache Mesosのアーキテクチャー


基本はこの3つ。

  • Mesos Masters
    マスターはスレーブのタスク調整と管理を行う。スレーブ、フレームワークを管理し、リソースの割り当てと最適配置を行う。冗長化構成が基本で、ZooKeeperを用いて冗長化を実現している。
  • Mesos Slaves
    スレーブはどれだけタスクを処理できるかをマスタに報告し、マスタからの要求に応じてタスクを実行する。タスクの1つ1つをコンテナ化して実行するため、コンテナオーケストレーションの技術と言われることがある。
  • Framework
    ユーザーが利用するインターフェイス。SchedulerとExecutorで構成される。SchedulerはMesosマスターへのJobの登録を担当し、オファーを処理。Executorはタスクをs実行するスレーブ上のプログラム、コマンドなど。DevOps tooling, Long Running Services, Mechine Learning, Big Data Processing, Batch Scheduling, Data Storageなどの分野で多くのツールがMesosに対応しており、Mesosのフレームワークとして用いることができる。


重要なフレームワーク



  • Marathon
    長期実行アプリを起動するよう設計されたフレームワークの1つ。Mesosを使うならMarathonも使うというくらい定番。コンテナオーケストレーションには必須。


  • Chronos
    バッチアプリを起動するように設計されたフレームワークの1つ。Airbnbによってcronの代わりに開発されたフレームワーク。

Mesosphere DCOS


Mesosをカーネルとするならば、MesosphereはデータセンターOS。Mesosの上にMesos SDK, Marathon, Chronosが乗っている。MEsosphere Enterprise DCOSは、Enterprise製品としてのMesosのディストリビューション。
Mesos単体ではカーネルレベルなので活用が難しい。MesosphereにはOSS版もある。

MesosとDCOSで実現できるあんなことこんなこと


Mesosのデモ。
MesosはThoughtWorks Tech Radar Vol.16でも紹介されている。

AWSからDC/OSをインストール


https://dcos.io/install から。
入力項目はほとんどない。お金がかかるので注意。

クラスタ環境へのアクセス方法いろいろ


ブラウザからのアクセスが簡単。慣れてくるとCLIが便利。

サービスの起動方法いろいろ

  • App JSON
    JSONでサービスを定義してコマンド1発で起動できる。
  • Universe
    GUIでパッケージを選択して簡単に起動できる。

コマンド1発でAzure上にDC/OS環境を作る方法


https://www.slideshare.net/ToruMakabe/1azuredcos

Azure上にDC/OS環境を作るデモ。
先程のプレゼンでAWSは15分だったけど、Azureはコマンド1発でいける。10分以内でできる。 => 今回は7分41秒で成功!

Azure Container ServiceはIaaS+。Managed PaaSではない。インフラとDC/OSの環境構築を楽に早く作る仕組み。DC/OS、Kubermetes、Docker Swarmを選択可能。




Mesos・DCOS Deepdive(English)


データセンターは、ハード、OS、アプリという単純な構造から変化している。マイクロサービスによって柔軟で、効率的で、頑強で、個別にスケールできるより複雑な構造になっている。アプリの言語の種類もバージョンも違う。全てがコンテナの上で動く。

データ処理は、バッチ、マイクロバッチ、イベントプロセッシングと変化している。イベントプロセッシングはマイクロ秒のレベルの高速処理。

Apache MesosはTwitterが採用し、今ではApacheのトッププロジェクトで、多くの先端企業が採用している。

DC/OSはモダン分散アプリケーションを可能にする。コンテナ上のマイクロサービスとビッグデータ分析を実現する。

ユースケースの1つ。esriはScalaでイベントソーシング、Kafkaでメッセージブローカー、Spark、Elasticsearch、JavaScriptの地図アプリというスタックで処理をしている。=> デモ

設定変更、バイナリの変更、クラスターのメンテナンス(バックアップ、リストア、再起動)などを管理することができる。

多くのコンテナで動くサービスにおける、モニタリング、ログ分析、アップグレード、障害対応、トラブルシューティングなどの課題に対処できる。

DC/OSの中のクラスターは他のクラスターからアクセス可能な仮想IPを持つ。DNSが仮想IPを指し示すことでServieに名前でアクセスできる 。

LT: おぷすた開発者がDC/OS on OpenSUSEでMesosに入門してみた的ななにか


Meoss, DC/OSをOpenSUSE(Linux)上で動かす。OpenSUSE, VirtualBox, Vagrant, DC/OSとインストール。 いろいろ大変だけど、なんとか動くよ。

LT: RancherでMesosクラスタをデプロイしてみる的ななにか


Rancherを使ってMesosを簡単に立ち上げるデモ。Rancherはコンテナ環境を管理するためのOSS。RancherでGUIでコンテナを立ち上げて、監視もできる。
Rancher ♡ Mesos

LT: サービスカタログと夏フェスにまつわるなにか


https://www.slideshare.net/cyberblackvoom/ranchermesosmarathon?next_slideshow=1

初心者が、Mesosを学ぶための情報紹介。

  1. Mesosってなに?のリンク集。
  2. RancherとMesos。Rancherにはオーケストレーション環境を簡単に構築できる環境テンプレートがある。Mesosも。本家のカタログもコミュニティのカタログもある。
  3. Rancher, Mesos, Marathonをつくる手順。



2017年2月23日木曜日

「Polymer.co-edo meetup #1」に参加しました


Reactでアプリつくって、最初はよかったんだけど段々と「うーん」となって、Vue.jsやRiotがいいと聞いてさわってみても「うーん」で、Angular2はTypeScriptが苦手なので「うーん」で、そういえば、昔Polymerさわったなぁと思っていたらちょうど勉強会があったので参加してみました。
結果、とても好きになりました。なんでPolymer0.5のときイマイチと思ったのかなぁ。


Extensible Web


Polymerの説明の前に主催者の岸田さんからExtensible Webの話がありました。
その詳細はオリジナルをみてもらうとして、私は次のムーブメントだと理解しています。

Web 標準化団体がWebをつくるのではなく、全てのエンジニアでWebをつくっていこう

これまでも、jQueryなど外部のライブラリで実現されていたことが標準仕様に取り込まれてきた歴史はあるけれど、はっきりと変えていこうという意思表示に美しさを感じます。


Web Components / コンポーネント指向


Extensible Webの次はWeb Components。
Web Componentsが何かというのはW3Cの仕様のとおりということになります。
Web Componentsはコンポーネント指向の仕様で、Webのコンポーネント指向について、私は次のように理解しています。

開発者が(HTMLとCSSとJSを使って)新しいコンポーネント(タグ)を定義して再利用できるようにする

この考えにあてはめると、ReactもVue.jsもRiotもコンポーネント指向です。
でも、これらはW3CのWeb Components仕様に準拠しているわけではなく、準拠しているものには、MozillaのX-TagsやGoogleのPolymerなどがあります。
X-TagsとPolymerを比べると、Polymerの方はGoogleらしく、Material Design、Google API、Progressive Web Appsを取り入れたものがすぐ使えるという特徴があります。


Progressive Web Apps


Progressive Web Appsは、Googleが提唱しているWebアプリです。
仕様がある訳ではないようですが、私は次のとおり理解しています。

ネイティブアプリと同じように、インストールできて、ホームから素早く起動できて、オフラインでも使えて、プッシュ通知もできるなどの特徴を兼ね備えたWebアプリ

Googleのサイトに従ってやれば、できなくないですが、Polymerを使うとPWAが簡単にできるとのこと。


Polymerを使ってみる


岸田さんがGoogleのCodelabsに登録されているチュートリアルのうち、 Polymerに関連したものピックアップしてくれています。
今回は「コーディングなしでGoogleMapを作ってみよう」をやってみました。

Polymerには、すぐに使えるWeb Componentsが用意されているので、HTMLとCSSがわかれば、JSを使わなくてもある程度のことができてしまいます。
その他のWeb Componentsも使えて、WEBCOMPONENTS.orgでは開発者が自作のweb componentsを公開できるそう。


Polymer.co-edo meetupは定期的に開催するそうだし、Polymer 2.0は2017年の第1クオーターのリリースを目指しているそうなので、今年中に何かアプリをつくってみようと思います。

2016年12月19日月曜日

優秀なエンジニアになる方法

最近、私なりに優秀なエンジニアになる方法がみえてきた。
優秀なエンジニアといってもレベルはいろいろあるけれど、ここでは、仕事をする中で、複数の人から「あの人は優秀」と言ってもらえるという基準で考えてほしい。

どれも、普通のことだけど、この普通のことを続けるかどうかで大きな差が生まれるのだと思う。
大切なプロジェクトから去るにあたり、後を任せる若い2人に向けてこの気づきをシェアしておく。

技術書を読む


昔、先輩にこんなことを言われたことがあった。

気になった本があったらすぐ買え。
積読でもいい、わからなくてもいい、はずれでもいい。
後から役に立つものもあるし、ずっと役に立たないものもある。
それでも気にせず、気になった本があったらすぐ買え。 

結局、本が一番学習のコスパがいい。
若くてお金がないうちは、ハズレの本を買ってしまうと損をしたと思ってしまうかもしれないけれど、トータルで考えると決して損をすることはない。

勉強会にでる


勉強会にでるだけで優秀になるということはない。
勉強会のよいところは、新しい技術のキーワードをひろえたり、ファーストステップを楽しくクリアできることと、社外の優秀なエンジニアとのネットワークが築けることだ。
単純に、楽しいのでモチベーションがあがるという効果もある。

知識があまりないうちは、有名そうな勉強会やカンファレンスにでてキーワードを拾ってくるだけでいい。
ハンズオン勉強会があれば、積極的にでるといい。
新しい技術を学ぶときは、ハンズオン勉強会にでると、変なところでつまずいて嫌にならないのでとてもおすすめだ。
まずは、勉強会の情報をチェックできるようにすることだ(dots.とかを使って)。

実際にサービスやツールをつくってみる


学んだことを活かして、小さくてもいいから、サービスやツールを自分でつくってみると、世界が広がる。
何をつくっていいのかわからないのなら、ハッカソンにでてみるのがおすすめだ。
初心者歓迎のハッカソン(はじめてのハッカソンとか)もあるので、臆せずに飛び込むといい。

自分で何か思いついたら、大したものでなくても、似たようなものがあっても、気にせずにとにかくつくってみる。
学習という意味では、車輪の再発明は決して悪くない。
必ず得るものがある。

コミュニティにとびこんでみる(ウィークタイズ)


興味をもって学んでいくと、気になるコミュニティがでてくる。
そのときは、自分の実力なんて気にせずにとにかくドアをノックしよう。
多くの場合、優しく受け入れてくれるし、強く束縛されることもない。
最近では、こういった弱い結びつき(ウィークタイズ)がとても重要だということがわかってきているらしい。

ワークライフシナジー


そんなことをやっていると、ただでさえ忙しいのにプライベートの時間がなくなってしまう。
ワークライフバランスといって、ワークとライフを分けてバランスをとるのはエンジニアには難しい。
その代わり、エンジニアはワークライフシナジーをしやすい。
今やITはライフと密着しているので、エンジニアとして成長すると、ハッカソンにでてライフを楽しくするアプリをつくったり、自分で自分の趣味に役立つアプリをつくったりできる。
ワークでもない、ライフでもない、ワークとライフが混ざりあった領域をつくって楽しめるエンジニアになるのが一番だと思う。