「Node学園 33時限目」に参加してきました

  • Node学園 33時限目に参加してきました。

nodejs.connpass.com

タイトル 登壇者
汎用木構造データ生成機としてのJSX: JSXをHTML以外に活用する shibukawa
Yahoo!ニュースにおけるBFFパフォーマンスチューニング事例 Mt.Tomo32, @gladenjoy, @oTheRwoRldy
金無し、時間はコマ切れ、リーンにやりたい。そんなチームが使う、リアルな技術選定と、Typescriptの型情報をフロント/サーバーで共有したい需要 @dublook
DCL15秒の見れないサイトを3秒まで改善した話。改善継続中 @mahiguch1
PromiseとNode.jsで解説する Smart Payment Button PayPal 岡村さん

汎用木構造データ生成機としてのJSX: JSXをHTML以外に活用する

  • shibukawaさん

JSX

  • マークアップとViewロジックの分離は関心事の分離ではなく技術の分離
  • JSの中にHTMLを書けてHTMLの中にJSを書ける

HTMLは木構造

  • 他にも木構造のものはたくさんあるので活用できそう

まとめ

  • 構造化データを扱うDSLとしてのJSX
    • 0から言語を作るよりも圧倒的に楽
  • コード量は増えるので付加価値を付けられると使い物になるかも

Yahoo!ニュースにおけるBFFパフォーマンスチューニング事例

  • Mt.Tomo32さん
  • @gladenjoyさん
  • @oTheRwoRldyさん

yahooニュース

  • もともとJavaだった
  • SSRしたくなってNodeで書き直した

Nodeに置き換え

  • そのままではパフォーマンスでなかった

ボトルネックを特定

  • 試したこと
    • console.time/console.tineEnd
    • sjsp
    • node --prof index.js
    • node --process-prof isolate-0xnnnnnnn.log > result.txt
      • => C++のCPU処理が重かった
      • flamebearerによる可視化
    • node --inspect
  • わかったこと
    • axios-cache-dapterによるキャッシュ
      • JSON.parseが重い
    • DIコンテナから取り出すインスタンスがシングルトンでない

axiosのキャッシュパフォーマンス改善

  • 前段にキャッシュサーバなく後段はマイクロサービス
    • JSON.parseが同期なので重い
  • JSON文字列ではなくオブジェクトをキャッシュするように変更

DIコンテナ内のインスタンスをシングルに改善

  • シングルトンスコープでコンテナに登録するように変更

それ以外の改善

  • Clusterモジュールの導入
  • バックエンドAPIへのKeepAlive対応

金無し、時間はコマ切れ、リーンにやりたい。そんなチームが使う、リアルな技術選定と、Typescriptの型情報をフロント/サーバーで共有したい需要

  • @dublookさん

リーンスタートアップと技術選定

  • いきなり作るよりニーズの検証
  • 最初は技術を使わなくてもできることから検証
  • 徐々に技術を使ってスケールさせていく
  • jsonの型がわからなくてつらい
    • TypeScriptを使うことに
  • クライアントもサーバもTypeScript

DCL15秒の見れないサイトを3秒まで改善した話。改善継続中

  • @mahiguch1さん

3年前にリリースしたWeb

  • 気がついたらDOM Content Loadedが15秒かかるようになっていた

改善1

  • scriptタグ減らす(まとめる)
  • scriptタグにasyncつける
  • cssをpreload
  • 画像サイズ最適化
  • => 5%改善

改善2

  • nodeとgulpとTypeScriptのバージョ投げた
  • 劇的に改善

改善3

  • webpackとReactをバージョンアップ
    • tree shakingがきいたからっぽい
  • 劇的に改善

PromiseとNode.jsで解説する Smart Payment Button

PayPalの実装方法

  • JSだけで実装完了
  • Promise対応
    • リダイレクト処理無しで決済結果の描画が可能
  • 各言語のSDKでサーバサイド実装もできる
  • 読み込むURLのパラメータでオプション指定できる
  • 内部でGraphQLを使って効率化

「Cookpad TechConf 2019」に参加してきました

  • Cookpad Tech Conf 2019に参加してきました。

techconf.cookpad.com

タイトル 発表者
クックパッドが目指す、これからのデザインとプロダクトのあり方 宇野 雄
生鮮ECクックパッドマート - サービスの立ち上げから拡大に向けて 長野 佳子
料理の学習体験をデザインする 須藤 耕平
新規サービス開発を加速させる技術とデザイン 藤井 謙士朗
Challenges for Global Service from a Perspective of SRE 2nd season 渡辺 喬之
レシピを解析する!Machine Readable Recipe(MRR: 機械可読なレシピ)の開発 伊尾木 将之
クックパッド動画事業開発のチャレンジ 渡辺 慎也
〜霞が関〜 クックパッドiOSアプリの破壊と創造、そして未来 三木 康暉
スケーラブルなセキュリティ監視基盤の作り方 水谷 正慶
新規アプリ開発を支えるユーザ・決済基盤 宇津 宏一
Re:silience から始めるカオスエンジニアリング生活 小杉山 拓弥
基調講演:なぜ毎日の料理を楽しみにするのか 成田 一生

クックパッドが目指す、これからのデザインとプロダクトのあり方

  • 宇野 雄

Cookpad

  • 毎日の料理を楽しみにする会社
  • 4000万人
  • 71カ国
  • 26言語

クックパッドができてないこと

  • 全社通した横断体験が設計されてない
  • アプリの体験がWeb
  • もっとクックパッドっぽさがほしい
    • 期待値に対するふるまいの享有
    • 見た目は違ってもいい

デザイン

  • 技術の全ては夢物語を現実にするための手段である
  • BTCモデル
    • Business
    • Technology
    • Creative
  • デザインはデザイナーだけが作るわけじゃない
    • 全員で作り上げる
  • Figmaがいい
    • 全員で作り上げてる感じ

生鮮ECクックパッドマート - サービスの立ち上げから拡大に向けて

  • 長野 佳子

クックパッドマート

  • アプリで注文して届けるサービス
    • 家までは届けない
    • 自分で都合のいい時に取りに行く
    • 送料無料
    • 最低注文金額なし

解決する課題

  • 平日買い物できない
  • 受け取りで家にいないといけない
  • 最低注文金額があるのでまとめ買いしないといけない

仮説検証

  • 買い物上手で時間のある主婦が買い物代行
    • 社内でMVP検証
  • Design Sprint
    • 短期間で集中的に検証
  • 今できる最速の方法で検証し仮説の確度を上げる

さらなる改善

  • スマートロックで無人の冷蔵庫
    • アプリで冷蔵庫をあける
  • 売店との連絡等オペレーションを自動化
  • 今はまだiOSだけ

料理の学習体験をデザインする

  • 須藤 耕平

たべドリ

  • おいしい食べ方学習ドリル

難しかった

  • 上達の定義が難しい
  • 定義できないから何を学ぶべきかわからない

どうなりたいか

  • レシピ見なくてもぱぱっと作れるようになりたい
    • 速さとかではなく対応力

新規サービス開発を加速させる技術とデザイン

  • 藤井 謙士朗

komerco

  • 料理が楽しくなるマルシェアプリ
  • 器とか料理道具を買える
  • 現在はiOSのみ
  • 購入用と出品用のアプリ

開発立ち上げ

  • iOSエンジニア4人
  • デザイナー1人
  • ディレクター1人
  • サーバは専任なし
    • Firebaseを使った
  • スピード感が求められt
    • クックパッドで使ってるアイコン使ったり
    • UIは後から詰めていった
    • 正常系のみ

デザインの享有

  • デザインを考えるよりも享有に時間がかかる
  • Sketch + Absstract + Zeplin + Marvel
  • Figma
    • オンラインで同時に編集ができる
    • 変更履歴も管理できる
    • プロトタイプも作れる

コンポーネント

  • AtomicDesign導入
  • 最小単位に区切って再利用性上げた
  • 管理しやすい
  • メンテしやすい
  • 安心しながらいじくりまわせる
  • Figmaとの相性も良い
    • Sketchだと管理が大変だった

開発スピードの向上

UIガイドラインを作成

  • Figma上に作成
  • 色の定義とかmarginとか
  • デザイナーとエンジニアのコミュニケーションを円滑に

アイコンフォントの作成

  • 画像が複数必要
    • @2x,@3xとか
    • 管理するのが大変
  • アイコンフォントならWebとも共通で使える
  • gitで管理してgithub pagesで公開

アニメーションの導入

  • 気持ちのいいインタラクションと開発工数トレードオフ
  • Lottieを使った
    • jsonからアニメーションを実行
    • iOSとWebで使い回せる
  • デザインから実装までデザイナーが完結できる

デザインをコード化

  • デザインデータをReactコンポーネント
  • タップ時の挙動などWeb上で確認できる
  • デザインに関するところは極力デザイナーがやる
    • エンジニアは機能の実装に集中してもらう

Challenges for Global Service from a Perspective of SRE 2nd season

  • 渡辺 喬之

クックパッドのグローバル版

SREの役割

  • SREのユーザはエンドユーザと開発者
  • SREが負担を背負って開発者が快適になるのは継続させることができない

レシピを解析する!Machine Readable Recipe(MRR: 機械可読なレシピ)の開発

  • 伊尾木 将之

レシピのその先

  • レシピの会社ではない
    • 毎日の料理を楽しみにする会社
  • レシピを検索する以上のことができていない
    • スマートキッチンを去年から始めた
  • 自動で調理してくれるもIoT家電もある
    • メーカーに依存する
    • クックパッドのレシピデータを使えないか
      • 人間が書いたレシピを機会が簡単には理解できない
    • => MRR(Machine Readable Recipe)

MRR

  • レシピをグラフ構造で表現
  • 中間ノードで検索

MMRを作る難しさ

  • 材料情報
    • 表記ゆれ
    • 分量の正規化
  • Action情報
    • 焼くとか煮るとか
    • input情報
  • メタ情報
    • 栄養成分

材料名の正規化

  • 醤油だけで200パターン以上
    • 醤油、しょう油、醤油(下味用)
    • 地道に網羅するのは現実的でない
  • 機会がクシュで対応
    • Encoder-Decoder
    • 翻訳でよく使われる技術

分量の正規化

  • おおさじ1、ひとつかみ、2から4人、かぶるくらい
  • BNF
  • 95%の正答率

MRRまとめ

  • スマートキッチンなどさまざまな応用に期待

クックパッド動画事業開発のチャレンジ

  • 渡辺 慎也

クックパッドTV

  • 料理動画事業を切り出した会社
    • 意思決定のスピードを向上するため
    • 独自に採用をするため

cookpad storeTV

  • スーパーの売場にタブレット置いて動画を流す
  • 広告収益モデル
    • 動画の合間に広告も流す

課題

  • 再生数の制御
    • 足りないとクレーム
    • 多いとクックパッドが損する
    • 一定期間で平準化させたい
  • 配信計画、配信比率を出す
    • 正確な在庫から予測できればいいが難しい
    • 実測をもとに計算し変動させていく
    • ログ収集してそれをもとに計算

cookpadTV

課題

  • 大量メッセージ
  • AppSyncを通して配信
    • コメントやスタンプなど
    • 1秒間に何百万のメッセージが送られてしまう
  • メッセージをバッファリングして軽減
    • なるべく遅らせない
    • 順序保証はしない
    • ロストは許容
  • go/gRPC

霞が関〜 クックパッドiOSアプリの破壊と創造、そして未来

  • 三木 康暉

クックパッドiOSアプリ

  • 歴史がある
  • コード量も多い
  • ビルドにとても時間がかかある
    • 1日/1時間費やしている人も
  • Objective-Cが25%残ってる

プロジェクトの改善

  • コードの整理
  • Objective-Cをなくす
  • ビルド時間の短縮

マルチモジュール化

  • キャッシュが効くようになりビルド高速化
  • 古い実装を疎結合

Xcodeプロジェクトの破壊

  • viper
  • xcodegen
    • yamlからxcodeprojを生成

スケーラブルなセキュリティ監視基盤の作り方

  • 水谷 正慶

セキュリティ監視

  • 防御
  • 検出
  • 対応

なぜ監視

  • 完全な防御はありえない
  • 防御より検出のほうが利用者の負担が少ない

スケーラブルな監視

  • サービス規模が大きくなっても対応できること
  • 監視対象が増えても対応できること

Security as Code

  • ログ収集と分析
  • 検知に係る処理をコード化
    • テストできる
    • アラート判定条件の高い記述力
    • 自動化
    • バージョン管理

アラートの検出

  • S3に転送されたログから検出
    • アラート検出のためのLambdaを実行
  • アラート関連情報の収集
    • それまでの操作履歴
    • バイス情報
  • アラートの評価
    • リモートワークの人がたまたまカフェのwifiからアクセスしただけとかそういうのを判断

新規アプリ開発を支えるユーザ・決済基盤

  • 宇津 宏一

モバイルアプリ

  • アプリ間で共通の機能がある
    • ユーザ管理認証
    • アプリ内課金

共通のユーザ決済基盤(クライアント)

  • API通信時に自動で再認証
    • 通信時に認証を意識させない
    • 認証失敗時に自動で再認証
  • アプリ内課金
    • iOS/Androidでぜんぜん違う
    • それぞれ処理フローを標準化
    • 例外的な動作も対応

共通のユーザ決済基盤(サーバ)

  • サーバサイドはマイクロサービス化されている

Organized Around Business Capabilities

  • 各サービスはそれぞれが独立したビジネスをやっている
  • そうでなかったら別の構成になっていたかも

Re:silience から始めるカオスエンジニアリング生活

  • 小杉山 拓弥

Chaos Engineering

  • 分散システムで不安定な状態に耐えることのできる環境を構築するための検証
  • Chaos Monkeyというランダムにインスタンスを落とすツール
  • ランダムにインスタンスを落とすことは重要ではない

クックパッドでChaos Engineeringをやる理由

  • なぜマイクロサービス
    • 開発速度向上
    • リリース速度向上
    • 複雑性は増加してしまう
  • マイクロサービスの課題
    • サービス間通信んお状況がすぐにっわからない
    • 連鎖的障害
    • 個々のサービスの状態はわかってもつながりはわからない
    • => サービスメッシュ
  • サービスメッシュ
    • Envoy
    • サービス間通信の状況がわかる
    • タイムアウトやリトライをアプリではなく中央的に管理できるようになった
  • Chaos Engineering

Chaos Engineeringをどう実践したか

  • Envoyの機能で一定割合を503で返すといったことができる
  • Chaos Engineeringが効果的な領域
    • 障害がおきたときにどんな影響があるかわからないもの
      • Network Fault Injection
    • 障害がおきることを考えたことがないもの
  • 顧客影響が少なからずあると分かっていながら本当にやるか?
    • ステージングでも分かることはあるはず

なぜ毎日の料理を楽しみにするのか

  • 成田 一生

2018年のクックパッド

  • cookpadTV LIVE
  • Komerco
  • cookpad mart
  • Alexaスキルのスペイン語
  • たべドリ
  • cookpad Do!
  • OiCy Platform / OiCy Taste
  • 投稿レシピ数世界で500万品
    • 国内300万品

毎日の料理を楽しみにする

  • 定款の第2条(ミッション)に追加
    • ミンションを達成したら解散することも記載

料理って必要?

  • からだは食べ物でできている

なぜ毎日の料理を楽しみにするのか

  • 楽しみにしてることは言われなくてもやっちゃう
  • おいしい食材を手に入れられるようにする
  • 料理を楽しみにするスキルを身につけられるようにする
    • cookpadTV LIVE
    • たべドリ
    • cookpad Do!
  • ゴールは遠ざかってる
    • それを近づける方法は楽しくすること

「JAWS DAYS 2019」に参加してきました

  • JAWSDAYS2019に参加してきました。

jawsdays2019.jaws-ug.jp

タイムテーブル

10:10~11:00

トラック タイトル 発表者
A AWSからJAWS-UGに向けてのメッセージ 吉江 瞬さん
沼口 繁さん
亀田 治伸さん
B PythonとSageMakerで始める MLチームのみで完結するAPIの構築事例 武田 研恒さん
B メディアによるAI活用(時事クイズの生成と高校野球戦評記事の自動生成) 佐渡 昭彦さん
C サーバレスで動かすトークン発行プラットフォーム 小池 駿平さん
C AWS Serverlessを活用したサービス監視 清家 史郎さん
D 今日からはじめるCI/CD…のためのAWSアーキテクチャ事始め 山﨑 奈緒美さん
波田野 裕一さん
E 1日でSSHをやめることができた話 ~AWS Systems Manager Session Manager 導入と運用Tips~ 金井 栄喜さん
E AppStream 2.0を活用してユーザ端末に依存しない運用にしよう 那須 隆さん
F 新卒一年目のSREがコンテナをデプロイできるようになるまでの道のり 原田 大地さん
坂田 純さん
G 子育てで覚える AWS Organizations 〜ITエンジニア英才教育〜) 九龍 真乙さん
H Amazon Sumerian によるユーザーインターフェイスへのアプローチ 大井 友三さん
I 「AWS IoTのベストプラクティス」それホント!? 森本 良平さん
園田 修平さん
J 音声ではじめる新しいオンライン決済サービス体験ワークショップ Okamoto Hidetakaさん
清野 剛史さん
K リクルートライフスタイルでのクラウドエンジニアのステップアップ方法 山田 雄さん
K 今日、これから「JAWS DAYS 2019」で体験できるSORACOMの展示内容を一気に紹介! 松下 享平さん
K Auth0を使ってAWS上のサービスに対する認証・認可を強化 古田 秀哉さん

11:10~12:00

トラック タイトル 発表者
A AWS環境のセキュリティ運用(設計)をはじめてみよう 臼田 佳祐さん
B Presentation / Demonstration Vit Niennattrakulさん
B talk with demo Thomas Mitchellさん
C 鉄道会社がつくったAI企業 〜クラウド環境はFull AWSではありますがAWSのAIネタはありませんスペシャル〜 虻川 勝彦さん
C 機械学習における AWS を用いたマイクロサービスアーキテクチャ 中川 裕太さん
D EC2 T2インスタンスでつまづきやすいCPUクレジット〜EC2でチャットボット作って運用でハマって学んだ話〜 武田 可帆里さん
D モバイルアプリのバックエンドをEC2で運用している話 勝部 俊介さん
E Well-Architectedな組織を実現するためのチャレンジ - なぜ、CA W-Aを作ろうと思ったのか – 柘植 翔太さん
F Community Friendship Showcase「うちのコミュがすみません!」 チャラ電Mitzさん(司会)とCommunity Friendshipな人たち
G RDBリファクタリングと異種間DB移行の戦い – Amazon DMSを使った止めずにリファクタリングする手法 曽根 壮大さん
H エッジコンピューティングと機械学習の効果と考慮点 榎並 利晃さん
H SORACOM LTE-M ボタン powered by AWSの活用100連発 片山 暁雄さん
I クラウドからオンプレを管理する! AWS の Management Tools を使ったハイブリッドアーキテクチャ 大村 幸敬さん
K CircleCI Orbsを使ってAWSへ簡単デプロイ Kim, Hirokuniさん
K ヤプリの完全にモダンとは言いづらいけど、そこそこ攻めてるインフラ環境をもっと良くしたいエンジニアを募集しています。 羽渕 元紀さん
K KDDIにおけるAWS×アジャイル開発 須田 一也さん
松本 健太郎さん

12:15〜12:30

トラック タイトル 発表者
A AWS で作る AI 研究開発のための基盤サービス 山口 陽平さん
B サーバーレスでセキュリティ監視 井原 康博さん
C 情シスでモバイルと機械学習働き方改革を推進している若手の話 勝部 俊介さん
D AIに興味あるエンジニア集まれー 大田黒 紘之さん
E コンテナベースな次世代型 WAF でよりスマートかつ効果的なセキュリティ対策を施そう 近藤 学さん
F JAWS-UG on ASCIIでどんな記事が読まれてるか気にならない? 大谷 イビサさん
G 実践!CloudFormation Best Practice ~CloudFormationで始める組織改革~ 村本 雄太さん
H “Spotinst”でEC2をもっと安く、コンテナ運用をより効率的に! 宮野 真冬さん
I メディア向けデータストアサービスをリリースして直面したツラミ 〜X-Tech後日談〜 村田 靖拓さん

12:30〜12:45

トラック タイトル 発表者
A アールスリーのご紹介 沖 安隆さん
B 顧客が本当に必要だったもの -CIer前日譚- 石田 知也さん
C AWS WAFのマネージドルールって、結局どれを選べばいいの?AWS WAFのことならCSC! 渡辺 洋司さん
D あらゆるデータを分析・可視化!明日から始められるSumo Logic 加藤 諒さん
E Kinesis→Redshift連携を、KCLからFirehoseに切り替えたお話 佐野 玄さん
F AWSからメール送るならSendGrid一択ですよね 中井 勘介さん
G エウレカのデータミッション kaneshinさん
H Terraformを活用した自社SaaS展開事例について 横井 公紀さん
I 技術力を上げたい!どうやって? というか技術力って一体何なんだっけ? – ハートビーツの場合 馬場 俊彰さん
K EC2、コンテナ(EKS、ECR、ECS)、サーバーレス、全員集合!AWSのセキュリティはトレンドマイクロにお任せあれ! 姜 貴日さん

12:45〜13:00

トラック タイトル 発表者
A Sansanという会社がどのようにAWSと向き合っているのか 間瀬 哲也さん
B ○○さんに似てますよね? (またか……) 古寺 克行さん
C (Un)Managed Blockchain 高橋 慎一さん
D Amazon DocumentDB(with MongoDB Compatibility)入門 菊池 修治さん
E AWSマネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ 田中 清さん
F DruvaのEC2、IaaS/PaaS/SaaS データ保護ソリューション 三輪 賢一さん
G クラウド時代のモニタリングといえばDatadogだよね 池山 邦彦さん
H セキュリティ・テストの自動化によるDevSecOpsの実現(デモ有) 伊藤 俊廷さん
I DeepLearningの本番環境にSagemakerを利用してる話 Yoshiaki Otaさん

13:10~14:00

トラック タイトル 発表者
A IoT野郎が語り合う、IoTの今と未来、そしてエコシステム 榎並 利晃さん
片山 暁雄さん
松下 享平さん
辻 一郎さん
B AI/MLシステムにおけるビッグデータとの付き合い方 鈴木 翔太さん
B DevOps On AWS Changhoon Hyunさん
C Welcome to AUSG! (Why University Students is important in AWS Community) Jaehui Kimさん
D 至高の CI/CD パイプラインを実現する5つの約束 ポジティブな Toriさん
D なぜパイプラインが神なのか 小西 宏樹さん
E レガシー化したアプリケーションをAWSを使って3ヶ月で刷新した話 井上 心太さん
E 金融APIAWSを使う上での利点と欠点 佐藤 維人さん
F 非エンジニアの皆様に贈るAlexaスキル開発ができるようになるまでのリアルな道のり 河本 貴史さん
F 視覚障害学生のチームによるAlexaスキル開発―スマートスピーカーでワクワクしよう― 筑波技術大学Alexa開発チーム
G ハイブリッドクラウド構成ガイド〜 2019年の今ならこう作る 菊池 之裕さん
G オンプレと密に連携が必要な Wi-Fiシステムを クラウドに移行するのは大変だった話 加藤 孝司さん
H GitHub Actionsを使って、ワークフローもプルリクベースで開発しよう! 池田 尚史さん
I サービスダウンから生まれたSWATチームが手掛けるクラウド移行への道 辰巳 琢弥さん
関藤 寛喜さん
J 講師と対戦 亀田 治伸さん
K Veeam Backup & Replication + AWSで簡単バックアップ、リストアことはじめ 飯尾 旭さん
K 旅行会社のSEがAWSを使って内製化をはじめてみた 磯野 敬汰さん
K 「仮想通貨交換取引所 × AWS」私達と一緒に働きませんか?どうやってAWSを使っているのか話します! 吉田 裕貴さん

14:10~15:00

トラック タイトル 発表者
A 創業から10年で4,000名規模となったオンプレ製品の会社における、クラウド活用とビジネスの変化 島崎 聡史さん
B 三題噺「F-Secure 基幹システムは Serverless !あと IoTセキュリティとAWSセキュリティ」 河野 真一郎さん
C 運用自動化支援するクラウドサービス「SIOS Coati」をサーバレスアークテクチャで全部作り直して、本当に良かった話 吉岡 大介さん
D AWSのサーバ管理でsshを使わない管理手段を実現しよう 岸上 健太郎さん
E EC2からKubernetesへの移行をセキュリティから考える 杉浦 英史さん
E freeeにおける Kubernetes監視基盤 河村 篤志さん
F コンタクトセンター業界 波乱注意報! Amazon Connect の本気を見逃せない 丸山 麻衣子さん
G AWS Transit Gateway を使った新しいセキュリティ手法を試してみた 伊藤 悠紀夫さん
H 【AWSセキュリティ入門】徒然なるままに責任共有モデルの下から上までそこはかとなく解説 大竹 孝昌さん
I 自社基盤で運用していた事業用サービスをAWS Fargate/Lambda等を活用しAWS上で再構築!苦労話もあるよ。 平山 智史さん
東川 寿充さん
K あなたが使っているWi-FiAWSとの深ーい関係 小松 直人さん
K CI/CD事例をご紹介!〜アプリエンジニアが輝けるAWS事業の魅力〜 棚田 美寿希さん
K 教えて!DI本部長 小松さん! 小松 哲平さん

15:10~16:00

トラック タイトル 発表者
A AWS x JAMStack で構築・運用するサーバーレスなWeb Front 江藤 武司さん
A 見せてやろう…Serverlessの本当の力を…!! 照井 将士さん
B Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する 村主 壮悟さん
C エンジニアが正しく成長するための、脱昭和&平成ワークスタイル 沢渡 あまねさん
黒須 義一さん
山﨑 奈緒美さん
D EC2からECSへ移行を始めたお話 吉岡 隆行さん
D Kubernetes を使ってエンジニア組織の生産性を上げよう 坂井 学さん
E 商業空間や家庭などの設備がAIやIoTによって制御される未来に関係する技術 Takahiro nakahataさん
F ukkaが取り組む一次産業の課題 〜 日本一遅い農産物の通販 OWNERS をAWSで実現している話 小林 俊仁さん
植本 裕紀さん
F アニメ・漫画 企業でITを活用してオタク業界の未来を変える取り組み (Anitech) 野田 純一さん
G SaaSを海外展開するために役立つインフラTips 友田 敬人さん
H PenTesterが知っている危ないAWS環境の共通点 ~攻撃者視点よりお届けする狙われやすいAWSの穴~ 洲崎 俊さん
一ノ瀬 太樹さん
北原 憲さん
I 数十億レコードのRDS MySQL5.6を1週間程でAurora MySQL5.7へ移行した時の話 金井 栄喜さん
I 医療ビッグデータをAWSとオンプレ基幹システムで共存運用 小森谷 一生さん
J SORACOM LTE-M Button powered by AWSハンズオン 松下 享平さん
辻 一郎さん
K AWSの運用最適化のためにNHN テコラスがお客様に提案していること 瀧川 真之さん
K JAWS-UGとAWSJの歩み 沼口 繁さん
K AWSへのシステム移行に伴うクラウドマインドへの移行 山下 光洋さん

16:10~17:00

トラック タイトル 発表者
A Kubernetes on AWS/EKSベストプラクティス Yusuke Kuokaさん
B AWS All Stars 浅野 佑貴さん
福井 厚さん
深森 広英さん
関山 宜孝さん
三上 卓也さん
中武 優樹さん
大井 友三さん
菊池 之裕さん
清水 毅さん
高山 博史さん
園田 修平さん
畑 史彦さん
塚越 啓介さん
篠原 英治さん
C Alexaスキルのグロースハック 伊藤 清香さん
C 「Alexaスキルを安心・安全に開発運用するためのAWS自動化ソリューション」 清野 剛史さん
D AWS CLIではじめるコマンドラインライフ 〜 正しい「運用自動化」への第一歩 波田野 裕一さん
E 我々はこうして「AWS本」を書いた! 〜十人十色〜 大串 肇さん
湊川 あいさん
長村 ひろさん
村主 壮悟さん
mochikoAsTechさん
野田 純一さん
吉江 瞬さん
佐々木 拓郎さん
馬勝 淳史さん
minamoさん
takipone(大瀧隆太)さん
F Build and Scale SaaS product by Serverless technologies. Okamoto Hidetakaさん
F Node.jsでのAWSサーバレスアプリプログラミングを簡単にする技術の研究紹介 木村 功作さん
G いま忙しいですか?AWS で Blockchain な事例を聞きたいですか? 塚田 朗弘さん
城竹 公仁さん
Jeff Wentworthさん
H AWS提案ワークショップ」RFPを元にチームでディスカッションしよう!!発表もあるよ JAWS-UG Sales
I 働くことや学ぶことを見つめ直してみませんか?presented by クラウド女子会 多田 歩美さん
K KUSANAGI for AWSWordPressを始めとしたCMSを簡単スタート! 楠木 大三郎さん
K エンタープライズのオンプレWAFをAWSに移行したらこうなった話 小出 淳二さん
K ムシと戦うAI+IoTサービスをサーバレスで作った話 堂端 翔さん

PythonとSageMakerで始める MLチームのみで完結するAPIの構築事例

  • 武田 研恒さん

データ分析で求められること

  • 検証結果をAPI化して使ってもらうことでで価値が生まれる
  • API構築はスキルセットが違う
  • 本業に集中できずに生産性が落ちてしまう
  • => SageMaker

SageMaker

  • フルマネージドな機械学習サービス
    • 検証からAPI化までを高速化できる

特徴

  • 調査・分析
    • jupyter notebook
  • 開発・学習
  • デプロイ・運用
    • フルマネージド

アルゴリズム

得られた効果

  • MLチームだけでAPI構築完結
  • 検証用コードの改変自由度が高い
  • 過去に作成したエンドポイントへの切り替えが簡単
  • スケールアウトも勝手にやってくれる

メディアによるAI活用(時事クイズの生成と高校野球戦評記事の自動生成)

朝日新聞の研究開発

  • 編集業務の生産性向上
  • 自動見出し生成、自動要約、自動校正
  • 時事クイズ自動生成
  • 高校野球選評の自動生成

時事クイズ自動生成

  • 毎日の大量のニュース記事をもとに自動でクイズを生成

なぜ作った?

  • ニュースを読まない学生が多い
  • 時事ニュースに触れる機会を増やす
  • Qrich

技術革新のスピード

  • 重要語抽出
  • AWS Comprrehendは日本語未対応
  • 東大・横大のOSS「専門用語自動抽出システム」
  • 単語ベクトル
    • 類似度の近い言葉を検出できる
    • 人名地名などの固有名詞は考慮が必要
    • 答えがソフトバンクのときに選択肢で野球チームを候補にしてしまうとか

構成

  • フロントはGCP
    • FirebaseのGmailとかTwitter連携が便利だったから

高校野球選評の自動生成

  • 事実しか書かないものだと記者が書いたものと判別がつかないレベル
    • インタビューした内容とかは記者が書かないと入れられない
  • スコアブックが電子化されてそれをもとに記事を作ることができるようになった

構成

  • EC2一台だけ

今後

  • 2ランスクイズのような稀なパターンがない
  • 変化球を軸にといったようなスコアブックから読み取れない情報

まとめ

  • AIを活用して新しいことに挑戦
  • AWSを含めたインフラやツールは適材適所
  • AWSサービスの進化に期待

エッジコンピューティングと機械学習の効果と考慮点

機械学習を用いた異常検知

  • 製造業
  • 設備のアフターサポート
  • 劣化診断
  • 建設現場の予防保全
  • システム/ネットワークのサイレント障害検知
  • ITセキュリティ

事例

  • タービンに加速度センサーつけて予兆検知
    • データを全部クラウドにあげると量が多すぎる
    • => エッジコンピューティング
  • 食品の外観チェック
    • 画像処理と分類で異常検知

エッジコンピューティングのニーズ

  • IoTクラウドにつながるのは当たり前でどう使おうというフェーズになってきている

メリット

  • クラウドを使うことによるリソースの柔軟性
  • データを集めて共有できる
  • レイテンシの問題
    • 少しでも速く異常検知したい
    • エッジサイドで処理
  • クラウドに依存しない
    • 何かあっても継続するためにエッジコンピューティング
  • データ量の問題
    • 全部クルドに送ると多いのでエッジサイドでも処理

AWS IoT Greengrass

  • ハードウェア上でLambdaを動かせるようなイメージ
  • サーバにつながってなくても動かせる
  • セキュリティ面の機能

至高の CI/CD パイプラインを実現する5つの約束

  • ポジティブな Toriさん
  • 小西 宏樹さん

テーマ

パイプラインファースト

  • いきなりアプリ開発に着手しがち
  • CICDが後回しになって手作業になりがち
  • 理想は一発目のデプロイからパイプラインを通す
  • プロジェクトnewしてすぐでデプロイすること!
    • コンフィグの書き換えとかも初回デプロイの後
    • ブラウザでエラー出る状態でも構わない
    • 最初にパイプラインを通すことが大事
  • 最初からちゃんとしったパイプラインである必要はない

自動化されたパイプラインの維持

  • 要求の変化に応じてシステムも変化
    • 油断すると自動化できなくなる
    • 自動化が難しくなる変更を避ける
  • パイプラインをシンプルに保つ
    • アプリの都合をパイプラインに押し込まない

柔軟なパイプラインの維持

  • プロジェクト似合わせてパイプラインも変化が必要
    • 継続的な変化を受け入れられるようにシンプルに
  • 変化
    • ビジネス要求の変化
    • ポリシーの変化
  • パイプラインもコード化してリポジトリ管理
    • 同じものを再現してそっちで試せる

パイプラインのUXを継続的に改善

  • パイプラインはチームに対して提供するサービス
    • 実行内容やどこで落ちたかなど誰が見てもわかるように
    • 処理時間の維持短縮
    • よくわからないパイプラインは使わなくなる
  • 過渡な作り込みは避ける

パイプラインが唯一のリリース手段

  • パイプラインを通さないデプロイは禁忌
    • 今回だけは手作業でを断固避ける
    • パイプラインを使わない人が出てきてしまう
  • パイプラインを通さない例外
    • ビジネスが危機的状況にある場合だけ

事例紹介

  • 技術
    • Microservices
    • Serverless
    • AWS
  • 運用
    • 機能開発スピード重視
    • 密結合なサービス群
    • チームごとに運用レベルまちまち

現場の課題

  • 無停止デプロイ困難
  • デプロイ時間かかる
  • 人的オペレーションによるミス
  • その場対応の積み重ね
  • 職人が生まれ他の人がやるとまた見する

失敗から学んだこと

  • ビジネス要求は絶えず変化する
  • 一つ疎かにすると大きな技術的負債となり得る
  • 多くの人が見える場で議論すること

ビジネス層に理解してもらうために

  • 常にビジネス層と議論
  • 簡単にYESと言わない
  • 見える化する

CloudNative

  • 疎結合
  • 回復性がいい
  • 管理されている
  • 可観測である
  • 堅牢な自動化
  • 大きな変更を最小限の労力で

EC2からKubernetesへの移行をセキュリティ/モニタリングから考える

  • 杉浦 英史さん
  • 河村 篤志さん

freee

  • クラウド会計ソフト
  • 金融機関と連携
  • 機密な情報を扱っている

なぜマイクロサービス化?

  • アプリが大きすぎる
    • 開発者100人以上
    • 一日2回しかデプロイできない

AWSk8sクラスタ

  • kube-aws
    • ECSはWorkerノードまで
    • Fargateとの違い
      • プロダクション向けの機能が豊富
    • k8s自分でやらないといけない設定が多い
  • EKS
  • kubectlの嵐つらい
    • eksctl

監視

  • なぜ監視
    • 予防保守
      • 近い将来起こりうる問題をすくい上げる
    • 異常検知
      • サービスの継続に係る障害をすぐに検知
    • 改善指標
      • なにか新しい施策をしてもmetricsがとれていないと効果がわからない

監視システム

  • データ収集
  • ストレージ
  • 可視化
  • 分析
  • アラート

k8sでの監視

  • 監視対象
  • 多様性
    • padが大量かつ多様
    • 個別設定入れていくのは無理
  • 自動スケール
    • ノードもpodも自動スケール
    • 監視システムも自動で追従しないと

ElasticStack

  • Elasticsearch
  • kibana
  • Logstash
  • Elastic Beats

商業空間や家庭などの設備がAIやIoTによって制御される未来に関係する技術

  • Takahiro nakahataさん

設備

  • 設備にはとてもお金がかかる
  • 日々莫大な金額が動いている

新しい技術

  • すでに大きなお金が動いてるビジネス
  • これから大きなお金が動くビジネス
  • これらをつなげる

設備の変化

照明

  • 「明るくする」ことと「伝えること」の2つの役割がある
  • デジタル化されたことで2つを同時に実現できるようになった
  • 例えば
    • 駅のホームで空いている車両がどこか照明で伝える
    • イベントで混雑する中出口がどこか照明で伝える
  • 設備が新たな意味と価値を持ち始めた

Society5.0

  • Society4.0 => 情報化社会
  • Society5.0はその次の時代
    • サイバー空間とフィジカル空間の高度な融合
    • 経済発展と社会課題の解決を両立する
    • 成功の鍵は設備を制御すること

ITと設備をつなげる

  • どうやってつなげる?
  • 既存の設備でつながる?
    • つながらない
    • 改修のタイミングで対応することになる

まとめ

  • 設備をつなげてビジネスにつなげよう
  • 時代がそうなってきた

Build and Scale SaaS product by Serverless technologies.

  • Okamoto Hidetakaさん

Serverlessのバックエンド

  • Auth: Congnito
  • API: API Gateway & Lambda
  • Batch: Lambda & Step Function
  • Front: React & Amplify
  • Netlify
  • Build & Deploy: CircleCI & Netlify
  • Payment: Shifter

なぜServerless/FaaSなのか

  • 巨人の方に乗る
  • 個人情報管理やランタイムの管理など責任を分散する
  • 使った分だけ課金

疎結合ですばやくtry & error

アウトプットの重要性

  • 半年前にやったことは覚えてない
  • どこかに記録しておく
  • できればオープンなところに
    • 間違ってたりもっとよくする方法を教えてくれることも

Node.jsでのAWSサーバレスアプリプログラミングを簡単にする技術の研究紹介

  • 木村 功作さん

JavaScriptの非同期処理

  • 古くはコールバック地獄
  • Promiseの登場
  • async/await
    • これで解決!?
  • まだ考えないといけないことはある

Escapin

  • 独自のライブラリ
  • 非同期処理をより簡潔に書ける

まとめ

  • もっと広く検証する必要あり
  • linterやコード補完も今後対応しないといけない

「PWA Night vol.1 ~PWAのミライや活用方法をみんなで考えよう~」に参加してきました

  • PWA Night vol.1 ~PWAのミライや活用方法をみんなで考えよう~に参加してきました。

pwanight.connpass.com

  • PWAだけにフォーカスした勉強会は今まであまりなかったのでとても楽しかったです。毎月開催ということで今後も期待しています。
  • PWAの良さはだいぶ広まってきましたが、TWAにするとアイコンにバッヂをつけられるなど更に便利なところもあるということでもっと深く調べてみたいなと思いました。
  • ネイティブ vs PWAの文脈で語られる場面が多かったですが、対立するものではなく選択肢が増えたということなんじゃないかと思うので、アプリの性質や戦略に応じて使いこなせていけるといいのかなと感じました。
タイトル 発表者
PWAの今とこれから 宍戸さん@Google
PWA はビジネス的に美味しいか? 橋本さん@パラダイスウェア
リーンスタートアップとPWA~Webサービス立上げ時こそPWAを検討したい!~ 角谷さん@TAM
PWA×CMS活用アイデア 早瀬さん@シックス・アパート

PWAの今とこれから

PWAの効果

  • PWAにすると平均コンバージョン率+20%
    • 統計のデータ
  • スターバックス
    • ブラウザで注文して店舗で受け取る
    • payment request
    • add to home screen
    • デスクトップ版もワンソースで
  • Google Maps Go
    • アプリ版は機能が多くて重い

PWAの特徴

  • 高速な表示
  • 信頼性
  • エンゲージメント性

高速な表示

  • 53%の人は表示3秒遅れると離脱
  • 79%はパフォーマンス悪いサイトに戻らない
  • 表示が1秒遅れるとコンバージョン率7%下がる

信頼性

  • ServiceWorker
    • ブラウザに対して一つ起動できる
    • リクエストをキャッシュしたり加工したり
  • Workbox
    • ServiceWorkerをラップするライブラリ
  • オフライン時はフォールバックページを返す
  • メジャーなブラウザではServiceWorkerは動作する

エンゲージメント性

  • ホームスクリーン追加
  • Androidだとホームに追加のバナーが勝手に出てしまう
    • beforeinstallPromptイベントを拾うことで制御できる
    • appinstalledイベントでインストール完了をひろえる
  • プッシュ通知
    • 通知がほしいと思える場面で許可プロンプト出すと良い
  • ログイン
    • 92%はID/パスワード思い出せないときに諦めてしまう
    • Credential Management API
    • Web Authentication API
  • 支払い
    • Payment Request API
    • ブラウザに記憶させた支払い情報を使ってフォームを統一

今後

  • モバイルのユーザ数がのびてる
    • デスクトップものびてる
  • デスクトップPWA
    • Cross Browser & Cross OS
  • PWAをGooglePlayで配信
    • WebViewではない
    • ChromeCustomTabsを使ってる
    • => TWA
  • TWA(Trusted Web Activities)
    • 開発者が保証されたWebページをAndroidのネイティブと同じように開くことができる
    • Wake Look
    • Badgingも使える

PWA はビジネス的に美味しいか?

  • 橋本さん@パラダイスウェア

PWAのイメージ

  • 従来のWeb -> PWA -> ネイティブアプリ
  • PWA = アプリ未満

PWAのイメージ

  • アプリよりも低工数(開発/運用)
  • 体制張りやすい
  • 後からアプリ化できる
  • 審査が必要ない
  • Google/Apple税も不要

B2B新規事業あるある

  • 課題
    • 要件定義に時間がかかるし仕様変更も多い
    • システム間連携にコスト
  • PWAを使うと
    • 早期に動くものが作れる
    • フロントとサーバを分離しやすい
  • プロトタイプ例
    • Vue + Firebase + twilio(SMSでiOSの通知の代替)

リーンスタートアップとPWA~Webサービス立上げ時こそPWAを検討したい!~

  • 角谷さん@TAM

不確実性の高い世の中

リーンスタートアップ

  • MVPを作る
    • 最低限実用に足る製品を作って成長させていく
  • MVPの種類
  • iOS/Androidアプリで完全版をいきなり作るのではなくPWAで小さく成長させていく

ネイティブあるある

  • 最初だけでなく全てがダブルコスト
  • ちょっとしたことで予算がなくなる
  • 審査があるからスピード感落ちる

PWA×CMS活用アイデア

PWAのメリット

  • 読み込み速い
  • オフラインで動く
  • インストール不要
  • プッシュ通知

PWAの要件

PWAの普及

  • PWAが思ったより普及してない理由
  • iOSの対応が充実すればとても便利になる

PWAを作るサービス

movabletype.net

「Chrome Tech Talk Night #12 ~ #perfmatters」に参加してきました

  • Chrome Tech Talk Night #12 ~ #perfmattersに参加してきました。

events.withgoogle.com

タイトル 発表者
Introduction to Performance APIs Shogo Sensui (@1000ch), Merpay, Inc.
Start Performance Budget Shunya Shishido (@sisidovski), Google
Tools for Performance Budgeting Katie Hempenius (@katiehempenius), Google

Introduction to Performance APIs

  • Shogo Sensui (@1000ch), Merpay, Inc.

Lazy Loading

Intersection Observer

  • viewport内に入ってるかどうか検知できる
    • 検知してから(必要になった時点で)読み込む
  • Webkitにも入った(safari!)

Intersection Observer v2

  • 表示されてるかどうかまでチェックできる

Browser native lazy-loading

  • ブラウザの機能ででlazy load
  • lazyload=onという属性
    • imgとかiframeにつけられる

Prefetch

Priority Hints

  • 並列で通信処理するときの優先度の指定
  • importance属性でつける
  • fetchのオプションでもしていできる

Resource Hints

  • ブラウザが暇してるときに読み込んでおく
    • ページを読み込み終わった後の次になにするかにフォーカスしてる機能
  • DNS Prefetch
  • Preconnect
  • Prefetch
    • quicklink
      • viewportに入ったaタグのリンク先を自動でprefetch
      • ネットワーク状況なんかも見てくれる
    • nuxt v2.4はquicklinkに影響を受けて同じような機能を入れてる
  • Prerender
    • chromeは内部で勝手にやってる

Preload

  • リソースからリソースを読み込むことが多くなってる
  • 順番待ちしないように先に読み込ませるようにする

Web Packaging

  • Signed HTTP Exchanges
    • AMPのURLがgoogleになってしまう問題を解決できる
  • Bundled HTTP Exchanges
  • Loading Signed Exchanges

Off The Main Thread

  • 最近のWebは重くなってきてる

Main Thread is busy

  • Loading
    • HTMLとってきて
    • HTMLパースして
    • CSSとってきて
    • CSSパースして
    • Eval heavy JavaScript
    • .....
  • Runtime

Performance metrics are changing

  • サーバサイドだけでなくクライアントサイドの指標も見るようになってきた

DOM manipulation is heavy

  • Virtual DOM
    • 最小限のdiff patch
  • Virtual DOMのdiffアルゴリズム重い
  • Split DOM manipulation
    • React Suspense
    • use requestIdleCallback
    • workerでDOMを処理とか

Off The Main Thread(inner browser)

  • ブラウザの中の処理をメインスレッド使わないように
    • V8の中でやってたり
  • Worklet

Off The Main Thread(web page land)

postMessageが使いづらい

Start Performance Budget

  • Shunya Shishido (@sisidovski), Google

Speed equals Revenue

  • スピードは収益につながる
  • モバイルブラウザだと顕著

Performance Budgetの事例

Pinterest

  • Budget
    • < 200kb JS
  • 結果
    • 44% Revenue

Tinder

  • Budget
    • < 160kb JS
    • <50kb lazy loaded JS
  • 結果
    • TTI = 6s(3G)

なぜパフォーマンスは悪化するか

  • Webはモバイルにおいては遅くなっている
  • リソースのサイズが大きくなってきている
  • チームにパフォーマンス改善の経験がない
  • 仕組みで解決せずに一時的な解決策になっている
  • 継続的なモニタリングをしていない
  • 変化に対する抵抗感

ビジネスとパフォーマンスのバランス

  • 会話の土台としてPerformance Budget
  • 開発者だけでなく周りを巻き込んでいかないといけない
  • 技術でなくビジネス上の課題を解決することを考える

Introducing Performance Budget

  • パフォーマンスの要件の閾値
  • Budgetの範囲内でよいUXを提供していく

Performance Budgetのメトリクス

Budgetの計算の仕方

  • サイトの特性によって変わってくる
  • 2つの方向性で考えると良い
    • Budgets
    • Goals

Budgets

  • いきなりゴールを目指すのは難しいので現実的な値を設定する
  • Budgetに収まった状態で改善を進められると良い

Goals

  • 最終的に目指したい値
    • 現状との比較
    • 競合との比較

20%ルール

  • 20%以上差があると違いを認知できる
  • 競合と比較して20%差をつけられると利用者にも認知してもらえる

ネットワーク

  • 日本では90%が4Gで10%が3Gというデータ
    • 日本向けなら4Gをターゲットとするとよい

3rdパーティスクリプト

  • 3rdパーティスクリプトのサイズも考慮する
    • それを含めてどれくらいのbudgetが残されているかを見る

Performance Budgetの運用

  • 開発に入る前の段階からパフォーマンスについて考えておくべき
  • Budgetが超過したらどうするか?
    • 既存機能を改善
    • 古い機能をを削る
    • 新しい機能を追加しない
  • 開発者だけでなくステークホルダーも含めて考える
  • モニタリングツールは必須
    • 定期的なメトリクスの取得
    • 競合との比較
    • 通知
    • SpeedCurveがいい
  • SpeedDemon
    • 無料なのがいい

Tools for Performance Budgeting

  • Katie Hempenius (@katiehempenius), Google

Understanding Performance Budget toolts

  • Performance Budget = Performance Goals
  • 計測 + CI and/or 通知

Lab Data vs Field Data

  • Lab Data
    • simulated users
    • 例えばlighthouse
    • 開発中に見える
  • Field Data
    • actial users
    • 例えばGoogleAnalytics
    • リリース後に見える

Timing metrics

  • Timing metricsは分散しがち
    • maxとかmedianとか見ていく

Resource based metrics

  • devtoolsで見れる
    • request count
    • request size
  • js/css等どこがボトルネック化見れるといい
  • JavaScript is expensive
    • parse
    • compile
    • excute
  • 27%のサイトは90-99%が3rdパーティコンテンツ

Score based budget

  • 計測ツールを使う
    • lighthouse
    • WebPageTest
  • わかりやすい
  • budgetを設定しやすい

Using Performance Budget tools

bundlesize

webpack

  • hints: 'error'
  • maxEntryoiuntSizeの設定
  • maxAssetSizeの設定

Lighthouse

Google Analytics

PageSpeedd Insights(API & Website)

  • Lighthouse + Chrome User Experience
    • => Lab Data + Field Data
  • First Input Delay(FID)

「Developers Summit 2019(2日目)」に参加してきました

event.shoeisha.jp

codezine.jp

タイムテーブル

10:00~10:45

タイトル 発表者
ドラゴンクエストXを支える失敗事例 青山 公士[スクウェア・エニックス]
エンジニアの知的生産術 ビフォー・アフター 西尾泰和[サイボウズ・ラボ]
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて - 澤田 雅彦[NTT]
プロダクトマネージャーという生き方 熊谷 亘太郎[楽天]
ソフトウェア開発の「今ココ」に適応するために― カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 ― 資料1 資料2 市谷 聡啓 [ギルドワークス]
新井 剛 [ヴァル研究所・エナジャイル]

11:05~11:50

タイトル 発表者
IBM Q - 量子コンピューターの最前線 小野寺 民也[日本アイ・ビー・エム]
メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと 山本 学[ヤフー]
デベロッパーのためのAzureクラウドネイティブスタック 〜 提供したい価値からはじめる高速+高可用+高付加価値ソリューション 川崎 庸市[日本マイクロソフト]
デンソーのMaaS開発~アジャイル開発で顧客との協調・チームビルディング・実装概要~ 佐藤 義永[デンソー]
冨田 進[デンソー]
CI/CDを使い倒して数段上のソフトウェア開発をしよう! 金 洋国[CircleCI]

12:10〜12:40

タイトル 発表社
モンスターストライクにおける負荷対策 ~エンジニアリングチームの挑戦~ 白川 裕介[ミクシィ]
【導入事例】Lychee Redmineのユーザが語る!トラブル予防としての使い方 稲垣 哲也[フューチャーアーキテクト]
機械学習システムのアーキテクチャ アラカルト ~ BrainPad における実例を交えて~ 太田 満久[ブレインパッド]
外食の「明るい未来」にむけたトレタの新たな取り組み 吉田 健吾[トレタ]
Entertainment x Tech~多くのアーティストとファンを繋ぐ技術と組織~ 山田 真一[エイベックス]

13:05~13:50

タイトル 発表者
3周年に突入するAbemaTVの挑戦と苦悩 山中 勇成(みゆっき)[サイバーエージェント
エンジニアの皆さんに贈る最速キャリア戦略 松本 勇気 [DMM.com]
ゲームQAを支える技術~前処理・後処理は大変だが役に立つ~ 太田 健一郎[スクウェア・エニックス]
OSS開発スタイルを取り入れて、効率的な開発を!~InnerSourceのススメ~ 田中 裕一[GitHub]
中国・深センのテクノロジー最新事情 資料1 資料2 ちゃんとく[dotstudio]
寺尾 英作[SBクラウド]

14:10~14:55

タイトル 発表者
ゲーミフィケーションエバンジェリストが説く、アプリ開発で見落としがちな「おもてなし」とは~面白さを伝える × 面白く魅せる~ 仲 功児[ナノコネクト]
Site Reliability Engineering at Google 中井 悦司[グーグル・クラウド・ジャパン]
今からでも遅くない!?Azureで学ぶ実用Blockchain 廣瀬 一海(デプロイ王子)[日本マイクロソフト]
太田 寛[日本マイクロソフト]
これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ - 幾田 雅仁 [gumi]
Less Code & Have Fun! IoTアプリ開発をはじめる際のポイント 山崎 亘[ウフル]
IBM Q 量子コンピューターハンズオン 小林 有里 [日本アイ・ビー・エム]

15:15~16:00

タイトル 発表者
プロダクトをGrowthさせるデータ駆動戦略の基礎知識~DMM.comにおけるユーザーレビュー基盤のKPIツリー公開~ 石垣 雅人[DMM.com]
サーバーレスで最高に楽しめるアプリ開発 江藤 武司[Riotz Works]
「仕事なんか楽しいはずないやん」に反発し「ええと思うなら、やったらよろしいやん」を胸に歩んできた話 中村 洋[ギルドワークス]
ことばだけでは足りません、描いてシェアして伝えていこう! 高野 明子[Sider]
システムエンジニアは空を飛ぶ夢を見れるのか~普通のSEがドローン系SEになるまで~ 佐藤 明
Kubernetesを短時間で体験。IBM Kubernetesで遊んでみよう! 斎藤 和史[日本アイ・ビー・エム]
今関 靖一郎[日本アイ・ビー・エム システムズ・エンジニアリング]

16:20~17:05

タイトル 発表者
Webサーバー利用だけではないNGINXソリューション 田辺 茂也[NGINX]
無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜 池山 邦彦[Datadog]
GKEとIstioで構築するクラウドネイティブ・アプリケーション - What, Why, Where and How to use Istio? 福田 潔[グーグル・クラウド・ジャパン]
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング 森廣 隆行[リクルートテクノロジーズ]
セキュアな環境でDevOpsを実現する厳選ツール 根本 竜也[マクニカネットワークス]
上田 展生[セガゲームス]

17:25~18:45

タイトル 発表者
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方 よしおかひろたか[東京大学大学院]
Webアプリのチューニングバトル「(社内)ISUCON」の魅力と楽しさ 資料1 資料2 資料3 櫛井 優介[LINE]
古川 陽介[リクルートテクノロジーズ]
南 直[Wantedly]
とにかく明るい!「Fun! Done! Learn!」でデブサミを振り返ってみましょう! ヴァッサー ジャンバティスト[yamaneco]
安井 力
川口 恭伸[アギレルゴコンサルティング]
有野 雅士[アトラクタ]
エンジニア採用パネルディスカッション――困難きわまる人材確保、だが成功する方針・施策とは 【モデレーター】市古 明典[翔泳社]
小野 和俊[セゾン情報システムズ]
松尾 奈美[リクルートテクノロジーズ]
三木 明[Repro]
アウトプットのススメ ~技術同人誌・LT登壇・Podcast~ おやかた
ariaki
hekitter
mochikoAsTech
KANE
長村ひろ
erukiti
私たちはどんな課題を解決すべきなのか? - 自然災害救援のために開発者ができること「Call for Code」 戸倉 彩[日本アイ・ビー・エム]
関 治之[コード・フォー・ジャパン]
小和田 香

デンソーのMaaS開発~アジャイル開発で顧客との協調・チームビルディング・実装概要~

アジャイルチーム

  • 2年前にアジャイルチーム発足
  • 今では6チーム
  • プロジェクトが終わったら解散ではなくチームに対してプロジェクトをアサインしている

mobi-Crews

  • 採用技術
    • Beanstalk
    • Terraform
    • Docker
    • Rails
    • CircleCI

開発の立ち上げ

開発の進め方

  • 次スプリントのバックログにready/not readyの印をつけておく
  • カンバンの一番上は改善タスク
    • 改善することでその後の作業が効率化されるはずなので一番先に
  • プランニング
    • 速くて2時間長いと3,4時間
    • スプリントのサイクルは1週間
  • スプリントレビュー前日の午後は開発チーム内でレビュー
  • 動くものを見せることが大事
    • 出来てないからドキュメントでデモとかやりだすとダメ
    • 全部出来てなくても見せる
  • メンバの追加はせずにスコープ調整が理想
    • そうもいかないことが多い
    • 複数チームにして拡大
    • POは個別に割当

インフラ

  • コード化する
    • Terraformを採用
  • 横展開可能なテンプレート化
  • 極力マネージドサービスを使って負担をへらす
    • Beanstalkを採用

リリースが近づいて

  • 課題
    • 監視
      • 必要なメトリクス洗い出して横展開
    • 性能
      • 性能評価環境を要しし定期的に測定
    • セキュリティ
      • 外部機関と連携して評価
  • プロジェクト横断のチームを結成
    • SREチーム

3周年に突入するAbemaTVの挑戦と苦悩

AbemaTV

  • 特徴
    • 無料
    • 会員登録なし
    • 24時間
  • 2015/10 開発開始
  • 2016/3 仮開局

プロジェクト横断のチームを結成

  • 開発メンバー
    • 当初14人 -> 今90人超
  • Web/iOS/Android/新デバイス/Streaming Client
  • プロジェクト管理
    • クライアントは2週間のスプリントで開発リリース
  • 勤務体制
    • 週一リモート推奨

アプリケーション

GCP

  • 高機能L7ロードバランサ
  • GKE/K8s
  • ネットワーク帯域に対するコストの安さ
  • ログ収集サービスの充実

言語

  • CAのバックエンドはではJava -> Node -> Go
  • Goを採用

アーキテクチャ

  • Microservices
    • 約80サービス
    • コンテナ化でリソース有効活用
    • サービス間通信はgRPC
    • Gateway Pattern
  • Go + Microservicesの課題

    • パッケージ管理
    • Goのバージョン管理
    • 共通ロジックどこにまとめるか

      データベース

  • MongoDB

  • シャーディングによる分散とレプリカセットで冗長化
  • コネクションプール管理

キャッシュ

  • In-Memory
  • Redis
    • 開発当初GCPでマネージドなものがなかったから
    • セッション管理
    • ロック目的
    • ネットワーク負荷軽減

構成管理

  • Terraform
    • インフラ構築を自動化
  • Packer
    • マシンイメージの作成起動

ネットワーク

クライアント/サーバ間通信

  • gRPCも検討したが
    • 当時http2での通信に対応してなかった
  • 通信フォーマットはProtocol Buffers

CDN

  • Akamai Media Delivery
    • 映像配信に特化したものが少なかった
  • Cloud CDN

開発支援

CI/CD

  • Codeship
    • バックエンドのテストやイメージの作成
  • Deploykun
    • 内製のchatopsツール

モニタリング

監視

  • bugsnag
  • Google Cloud Monitoring
    • GCE/GKEの挙動監視
  • Slack連携
  • PagerDuty
    • インシデント管理ソリューション
    • SREチームで1次対応

ログ

  • アプリログ
    • Goの標準出力にJSONで出力
    • GKEのfluentdで収集
    • StackDriver Loggingで表示
  • アクセスログ
    • 当初はfluentd
      • Goとの相性
    • CloudPubSubとBigQueryへ変更
      • Streaming Insterterの運用管理
      • BigQueryのStreaming Insertのキャパシティ
    • => 今はCloud Dataflow + Apache Avroへ変更

メトリクス

  • Redis/MongoDBはStackdriver
  • 各アプリはPrometheus + Grafana

今後

  • サービス規模の拡大
  • さらなる安定化の追求
  • 既存システムの老朽化対応

目指すアーキテクチャ

  • 配信レイヤーの全二重化
    • サーバや回線等ユーザの直前まで全て
  • チャンネル別リソース
    • RedisやMongoDB等のリソースをチャンネルごとに分ける
  • 実績と予測に基づいたオートスケール
    • 過去実績や時間帯をもとにオートスケールさせたい

Site Reliability Engineering at Google

Googleについて

  • 担当していないサービスでも全てのコードを見ることができる
  • 目指すところ
    • 世界中の情報を整理し世界中の人ボトがアクセスできて使えるようにする
  • 世界中専用回線でつながってる
  • 世界中のデータセンターに巨大なk8sクラスタっぽいものがある
    • 標準化されていてどこも同じ
  • ミドルウェアのレイヤも標準化されている
  • GCPは社内で使われていたものをオープンにしたもの
  • プロジェクト外のソフトウェアもコード修正・改善案を自由に出せる

SRE

  • リリースしたサービスをいかに安定して運用し続けるか
  • システムを運用するだけでなく安定運用するために必要なソフトウェア開発をあわせて行うチーム
    • => Site Reliability Engineering

50%ルール

  • 50%以上をシステム安定に関わるプロジェクト活動にあてる
  • 障害対応等々は50%以下にする
  • 障害が多い/マニュアル作業が多すぎて50%ルールが厳しくなるシステム
    • 開発側に突き返す
    • システムを改善する

SREが見る範囲

  • 運用範囲
  • 運用範囲外
    • 小規模で重要度が低いアプリ
    • 安定運用できてるシステム

SREの活動原則

SLO

  • 何を持って「安定」というか
  • Service Level Objective
  • システムの安定稼働の目標値
  • エラーバジェット
    • エラーバジェット = 1.0 - SLO
    • 消費状況をモニタリング
    • エラーバジェットがなくなりそうになったら新機能の開発はストップして改善に注力

Toil

  • 労力のかかる作業の削減

Postmortem

  • 障害対応が終わった後の文書
    • 発生要因
    • 反省点
    • 改善点
  • 個人を非難する内容は絶対に書かない
  • 障害報告ではなく未来につなげるための知見とする

プロダクトをGrowthさせるデータ駆動戦略の基礎知識~DMM.comにおけるユーザーレビュー基盤のKPIツリー公開~

データ駆動戦略とは?

  • データドリブンで戦略を組み立てる
  • 不確実性につい良い組織にする

なぜデータ駆動戦略?

  • 直感に頼るとプロダクトバックログが肥大化し開発者を圧迫する
  • データがないとなぜうまくいった/いかなかったが分からない

データ駆動戦略のなにがいいか?

  • プロダクトの状態を可視化できる
  • 意思決定を高速化できる
  • 意思決定を定量的に共有できる
  • 未来を予測して戦略を作れる

どうやってデータ駆動戦略?

DMM.comのデータ駆動戦略

  • SoEとSoRな領域がある
  • 40種類以上のサービス
  • ドメインごとにスクラムチーム
  • データアナリストがPOを支える

データ分析基盤

  • データを提示できないといけない
    • 分析しやすいデータ分析基盤が必要

優れた指標

  • データが駆動する
    • データを見ることで次の行動につながること
  • 3つの土台
    • 比較できる
    • わかりやすい
    • 比率や割合である
  • 4つの指標
    • 定量的指標と定性的指標
      • 主観的/科学的数値
    • 虚栄の指標と本物の指標
      • 次の行動につながる/つながらない
    • 先行指標と遅行指標
      • 未来の予測/変動後の数値
    • 相関指標と因果指標
      • AとBが関係/Aが起こるとBが起こる
      • 因果関係を探すために相関関係のある数値をを観察

開発プロセス

最後に

タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング

背景

  • 入稿システムはリボンモデルの根幹の部分
  • ディフェンシブで既存システムに手を加えるのではなく新規で作ることが多い
  • 急激な性能劣化
  • リプレイスでは時間がかかりすぎる

性能改善

  • 過去の技術的負債を分析し改善
    • 泥臭い作業で改善を重ねた
  • 品質の担保
    • 本番データと突き合わせて確認
    • オフショア使って力技で

まとめ

  • リビルドリプレイスに頼らなくても効果は出せる
  • システム単体で最適だったとしても経年劣化を考えるとそうでない

Webアプリのチューニングバトル「(社内)ISUCON」の魅力と楽しさ

ISCONの誕生

  • 2011年の夏
  • tagomorisさんが発起人
    • 「言い訳できない環境で1番を決めたい」
  • 当時のライブドア

名前の由来

  • 当初lpc
  • パフォーマンス遅いと椅子投げるといっていた
    • ISU
  • Iikanjini Speed Up Contest

概要

  • 制限時間8時間
  • 与えられたWebアプリを高速化する

今年のISUCON

R-ISUCON

なぜR-ISUCONはじめたか

  • ISUCONで勝てない..
  • 過去出題している人たちが強い
  • やってみると方向性が変わってきた

本家ISUCONとの違い

  • 本家は出題する会社がそれぞれお題を出す
    • 会社の特色が出る
  • リクルートなりの問題を作った
    • 本家はバックエンドの要素が多いがフロントエンドの要素も入れた
      • CSS/JSをあえて重くしたり
    • 社内で実際に起きたり困ってたりすることをお題に
  • 本家は8時間だけどR-ISUCONは合宿で1泊2日
  • 教育的な側面も強いが障害振り返り的な側面も強い

これまでの振り返り

スピードハッカソン

  • 仮想サービスでなく本物のサービスでISUCONする
  • 実際のサービスでの制約を度外視して試せる

PIGICON

IMOCON

その後

  • みんなに学んでほしいことをコンテキスト形式にする流れができた
  • 実際のアプリにも効果が出せた

新卒研修でISUCON

  • Wantedlyで新卒研修でISUCONした
  • パフォーマンス改善は学ぶのが難しいし実践できる機会が少ない
    • ISUCONで体験してもらう
  • 幅広い技術にふれてほしい
    • 高速化にはあらゆるスキルが必要

新卒ISUCONの運営

  • 問題と環境があればできる
  • 問題
    • Webアプリとベンチマーカー
  • 環境
    • アプリを動かす環境
    • スコアボード
    • 場所

今後

  • 企業横断での新卒ISUCONとかできると面白うそう

「Developers Summit 2019(1日目)」に参加してきました

event.shoeisha.jp

codezine.jp

タイムテーブル

10:00~10:45

タイトル 発表者
❤一生エンジニアを楽しもう❤夢中が最高!! 漆原 茂 [ウルシステムズ]
エンジニアリングマネージャー・パネルディスカッション 織田 晃弘[富士通クラウドテクノロジーズ]
及川 卓也[Tably]
竹迫 良範[リクルートテクノロジーズ]
広木 大地[レクター]
ひらい さだあき[メルカリ]
是澤 太志[メルカリ]
イノベーションを支えるアマゾン文化 西谷 圭介[アマゾン ウェブ サービス ジャパン]
Scrum@Scale入門 原田 騎郎[アトラクタ]
Amazonの文化をハックせよ。AWSをフル活用して無人レジの仕組みを作ってみた~横田deGoプロジェクト~ 横田 聡[クラスメソッド]
始めてみようSalesforce - コード書かなくてもここまでできるクラウドアプリ開発 - 宮本 隆人[アクセンチュア]
小坂 駿[アクセンチュア]
本橋 孝昭

11:05~11:50

タイトル 発表者
GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化 池田 尚史[GitHub]
Cloud Native アプリケーションに最適!Oracle Cloud Infrastructureの魅力! 丸川 祐考[日本オラクル]
茂 こと[日本オラクル]
Hack your career! ― アカデミックからビジネスへ向かったワケ ― 宇都宮 聖子[アマゾン ウェブ サービス ジャパン]
Alexaスキルで収益化を目指そう 畠中 俊巳[アマゾンジャパン]
レガシー開発からモダン開発への挑戦 資料1 資料2 左近充 裕樹[ブロードリーフ]
松本 宏紀[ブロードリーフ]

12:10〜12:40

タイトル 発表者
GCPに恋してHashiCorpを愛して起業したエンジニアのお話 長谷川 祐介[grasys]
幸せなエンジニアのキャリアの組み立て方 泉 雄介[ラクスル]
サポートを、上手く使って迅速解決!‐現場が泣いて喜ぶ問い合わせ方法- 伊藤 裕史[アマゾン ウェブ サービス ジャパン]
インフラエンジニア様の時間を、単純作業にとられるなんてもったいない!機能的なインフラと管理ロボットを導入してみた! 宇野 素史[クララオンライン]
島崎聡史[ニュータニックス・ジャパン]
セキュリティ・テストの自動化によるDevSecOpsの実現 (デモ有) 吉井 雅人[日本シノプシス]
パネルディスカッション - 他では味わえない!? Salesforceエンジニアの世界 - 岡本 充洋[セールスフォース・ドットコム]
小坂 駿[アクセンチュア]
小林 亮理[フレクト]
前田 ゆり子[日本システムデザイン]
山田 真也[ウフル]

13:05~13:50

タイトル 発表者
Cloud Native時代における Docker / Kubernetes による開発 青山 真也[サイバーエージェント]
日経電子版のマイクロフロントエンドとPWAによる改善事例 宮本 将[日本経済新聞社]
大規模分散データベースサービス - 世界で使われるAmazon DynamoDBを改めて知る - 成田 俊[アマゾン ウェブ サービス ジャパン]
大学におけるイマドキのエンジニア教育 資料1 資料2 角 征典[ワイクル]
永瀬 美穂[アトラクタ]
ブロックチェーンでエコシステムはどう変わるのか - コミュニティのこれまでとこれからを徹底議論! 池内 孝啓[catabira]
生田 和希[LayerX]
上坂 明日香[Omise Japan]
石井 壮太[ALIS]
始めてみようSalesforce - No CodeでEinstein Botを構築してみよう - 山田 真也[ウフル]

14:10~14:55

タイトル 発表者
ビズリーチは新規事業でなぜKotlinを選んだのか〜企業をアップデートする「Human OS」の技術選定について〜 大谷 弘喜[ビズリーチ]
一エンジニアが伝えたい、プロジェクトや組織の運営を理想に近づけるための考え方 宮下 崇[ディライトワークス]
入社半年での開発ストーリー - 千人規模の顔認証受付サービスを1ヶ月で作った話 - 針原 佳貴[アマゾン ウェブ サービス ジャパン]
新技術導入を成功させる組織のつくりかた ~spanner、GKE導入の実体験から得たこと~ 廣本 洋一[コロプラ]
APIを活用したフォントの使い方 ~MR(Mixed Reality)の実例紹介~ 相川 晴俊[モリサワ]
堀尾 風仁[神戸デジタル・ラボ]

15:15~16:00

タイトル 発表者
レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜 福田 剛広[VOYAGE GROUP]
小林 徹也[VOYAGE GROUP]
駒崎 大輔[VOYAGE GROUP]
ヤフー株式会社におけるフロントエンドの取り組み 向井 咲人[ヤフー]
森本 恭平[ヤフー]
平山 涼也[ヤフー]
パケットの気持ちになってみよう -クラウドを支えるネットワーク- 荒木 靖宏[アマゾン ウェブ サービス ジャパン]
不安をFUNへ!VP of Engineeringとしての組織変革への挑戦 里山 南人[ビデオマーケット]
開発者の第三のキャリアパスエバンジェリスト/アドボケイトとは何者か?~ 中津川 篤司[MOONGIFT]
開発者に贈るSalesforceプラットフォーム概論と最新動向 齋藤 俊[フレクト]
小林 亮理[フレクト]

16:20~17:05

タイトル 発表者
ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話 塩崎 健弘[ZOZOテクノロジーズ]
★The DEMO Show★ Visual Studio & .NET Core の進化とクラウド ネイティブ開発 井上 章 (チャック)[日本マイクロソフト]
コンピュータビジョンを支える深層学習技術の新潮流 鮫島 正樹[アマゾン ウェブ サービス ジャパン]
【祝】k8sデビュー! エンタープライズ巨大アプリをマイクロサービス・コンテナ化。段階的移行(中)の全記録を追う。 石田 健亮[ドリーム・アーツ]
カオス化した組織とエンタープライズシステム群を、モダン化したい!ノンIT企業のシステム企画開発を、ドメイン駆動型に組織ごと変えるまでの道のり 内藤 千稔[パーソルキャリア]
Salesforceプログラミング - Web Componentsをベースにしたアプリの開発手順 - 岡本 充洋[セールスフォース・ドットコム]
稲葉 洋幸[セールスフォース・ドットコム]

17:25~18:45

タイトル 発表者
「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2019」プレゼン大会 【司会】高柳 謙
【特別ゲスト】平木 啓太 [丸善ジュンク堂]
【特別ゲスト】瀬尾 傑[スマートニュース]
【特別ゲスト】永瀬 美穂[アトラクタ]
若手エンジニアの登竜門「Developers Boost」優秀セッション再演! Edward Fox [Repro]
本多 広晃 [ナビタイムジャパン]
五十幡 直洋 [パーソルキャリア]
みんなの暮らしを支えるAmazon S3の裏側、お伝えします 焼尾 徹[アマゾン ウェブ サービス ジャパン]
楽しい場所でカンファレンスをする~スタジアムと岡山城 小西 宏樹[エムオーテックス]
uzulla
身近な業務を改善して楽しもう! ~ 業務ハックLT 【司会】菅原 のびすけ
野秋 拓也[DMM.com]
ポキオ
廣野 美里[freee]
菊池 健人[ハンズラボ]
高山 和幸[ウェルスナビ]
髙木 咲希[SonicGarden]
やまちょ

Scrum@Scale入門

  • 原田 騎郎[アトラクタ]

Scrum@Scale

アジャイルチーム

  • 人数が多いとコミュニケーションパスが多い

Agilityをスケールさせるには

  • コピペチームは作れない
  • スケールアップ/スケールアウトしかできないなら膨張してるだけ

スケールする前に

  • うまくいってるチームを2つ育てること
    • プロダクト、プロセス、チームの改善方法を知って経験しているチーム

Scrum@Scaleの定義

スクラムマスター

  • Scrum of Scrums
    • Scrumをスケールさせる
    • Scrum of Scrum of Scrums...
    • EAT(エグゼクティブアクションチーム)
      • 経営層が入る
  • SAAB Technologies社の事例
    • 2000人を1.25時間で同期
    • 7:30 DailyScrum
    • 7:45 Scaled DailyScrum
    • ...
    • 8:30 Executive Action Team

プロダクトオーナー

  • POをスケール
    • プロダクトオーナー
    • チーフプロダクトオーナー
    • チーフチーフプロダクトオーナー

SMとPOのスケーリングの違い

  • SM
    • ベストプラクティスの共有
    • 協力して障害除去
  • PO
    • 意思決定
    • 上位のPOの決定が強い

GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS

GitHub

  • 2008年にPullRequestが登場
    • ソフトウェア開発に大きな影響を与えた
  • ツールが多くて使いこなすのが大変
    • なんとかしたい
    • ワークフローはモジューラ化されてるべき
    • => GitHub Actions

GitHub Actions

  • コンテナ技術ベース
  • ワークフローをモジューラ化して構築できる
    • 再利用できる
  • GUIでワークフローを組み立てられる
    • 実態はテキストだから管理できるしプルリクだしてレビューもできる
    • ワークフローasCode
  • 個々のActionは単なるDockerfile
  • ワークフローにhookできるイベントは26ある
    • pushとか

現状の仕様/制限

  • 実行時間max58分
  • ワークフロー1つにつきAction100個まで
  • 並列実行は1repoあたり2つまで
  • APIコールは1repoあたり1時間1000回まで
  • Dockerでできることはだいたいできる
  • 環境変数渡せる
  • ベータ版なのでどんどん追記されてる

便利なAction

まとめ

  • ワークフローは自由になる
    • モジューラ化され
    • OSSとして作り上げる
    • ソフトウェア開発の世界に新しい1ページ

日経電子版のマイクロフロントエンドとPWAによる改善事例

日経電子版のフロントエンド

  • SPAではない
  • ページ単位で性質がことなる
  • アプリケーションというよりドキュメント寄り

マイクロフロントエンド

アーキテクチャ

TS

  • TS入れた
    • tscするだけ
  • トランスパイルはbabelのままで
  • 型付け頑張りすぎない
    • 依存モジュールの扱いとか

JSX

  • handlebarsからJSXへ
    • Reactを使ってるわけでない
    • 補完が効く
    • 型で縛れる

PWA

  • 確実性
  • 速さ
  • 魅力

Fast and Engagement

マイクロフロントエンドとPWA

  • ServiceWorkerがモノリス化する
    • 修正時の影響が広くて怖い
  • ServiceWorkerをマイクロサービス化
    • それぞれScopeを区切った

ヤフー株式会社におけるフロントエンドの取り組み

  • 向井 咲人[ヤフー]
  • 森本 恭平[ヤフー]
  • 平山 涼也[ヤフー]

背景

メディアカンパニーの取り組み

  • lint/prettier
    • レビューの効率化
    • コーディングガイドはgitbookで管理
  • Danger
    • プルリクへのラベル付
  • TypeScript
    • 静的型付け
  • AtomicDesign
  • Storybook

コマースカンパニーの取り組み(Yahoo!ショッピング)

  • UIパーツを抽出して共通化
    • AtomicDesign
    • Storybook
  • 技術
    • React
    • TypeScript
  • UIパーツ集をnpmで社内に配信
    • Reactを使ってれば使い回せる
    • エンジニアも気軽にデザインを作れる
    • Material Designの社内版みたいな

Webフロントエンド技術室の取り組み

  • 横断的な組織
    • ヤフー全体のフロントエンドの課題を解決
    • フロントエンドエンジニアが少ないようなサービスもある
  • ライブラリの効率化
  • 統一的なパフォーマンス計測方法の検討
  • ヤフーのWebフロントエンドの状態把握
  • 技術選定と浸透

技術の統一

コンピュータビジョンを支える深層学習技術の新潮流

  • 鮫島 正樹[アマゾン ウェブ サービス ジャパン]

コンピュータビジョンとは

  • 人間のようにコンピュータに視覚をもたせようとする技術

コンピュータビジョンの動向

  • 精度やスピードが飛躍的に向上
    • 画像認識
    • 物体検出
    • セグメンテーション
  • 少量データに対する挑戦
  • 敵対的画像の生成と防御
    • DeepLearningのモデルはノイズに弱い

コンピュータビジョンの開発技術

ハイレベル実装を実現するFW

  • FW
    • TensorFlow
    • Gluon
    • Chainer
    • PyTorch
  • 実装/学習済みモデルを配布

ONNX

  • Open Neural Network Exchange
  • 各種FWのモデルをONNXに変換
  • ONNXから各種FWへ変換

Define-and-runとDefine-by-run

  • Define-and-run
    • ネットワークを定義してからデータを入力
  • Define-by-run
    • ネットワークを定義しながらデータを入力
  • Define-by-runの方が効率的
    • デバッグしやすさだけでなく実行効率も良い

AutoML

  • 必要なタスクを自動化うするAutoMLの研究が進む
  • 自動でデータ収集・整備
  • 自動で最適な機械学習を実行

コンピュータビジョンの運用技術

  • 運用の課題
    • モデルを効率よく推論する環境を容易に構築したい
    • モデルの推論結果の妥当性を評価できない
      • Interoretable ML

Model Server

  • 効率のいい推論環境を構築できる
  • REST/RPCでアクセスできる
  • TensorFlow Serving
  • MXNet Model Server

モデルコンパイラ

  • ハードウェアに応じてモデルを変換
    • 推論速度向上
  • 軽量なランタイムでも実行可
  • SageMaker Neo
  • TensorRT

Interoretable ML

  • 単純なモデル(決定木、SVM、GBT)
    • どのデータが予測/分類に有効か知ることができる
  • 深層学習(compute vision)
    • モデルの直接的な解析は困難
    • 画像を一部欠落させても正しく認識すれば残った部分が重要な箇所

コンピュータビジョンを支えるハードウェアの展開

  • 推論用チップ
    • AWS Inferentia
    • Intel Nervana
    • 学習用チップとは用途が違う
  • FPGA
  • エッジデバイス

まとめ

  • 精度速度の工場だけでなくアウリの幅も広がってる
  • 開発運用の効率化が注目されている
    • AutoMLといった自動化の研究も
    • AIの民主化
  • 深層学習によるコンピュータビジョンも実世界に応用するフェーズ
    • 推論チップエッジデバイスが今後活躍

みんなの暮らしを支えるAmazon S3の裏側、お伝えします

  • 焼尾 徹[アマゾン ウェブ サービス ジャパン]

Amazon S3の概要

  • Amazon Simple Storage Service
    • 安全に容量制限なくデータ保存可能
    • 2006/3リリース
  • Amazon Glacier(S3 Glacier)
    • 安全性とコスト効率を重視したアーカイブ向けストレージ
    • 2012/8リリース

Amazon S3の裏側

  • リクエストレート
    • 秒あたり100 PUT/POST/DELETE(書き込み)
    • 秒あたり300 GET(読み込み)
    • => 2018.7に大幅に上限上がった(3500 PUT*/5500 GET)
  • リクエストレートが上がってもレイテンシが直接的に短縮されるわけではない
  • S3の金額はオブジェクトの数とサイズ
  • ECRを使うと裏でS3が使われてる
    • ECR・・・コンテナイメージ置き場

「React.js meetup #6」に参加してきました

  • React.js meetup #6に参加してきました。

reactjs-meetup.connpass.com

  • @koba04さんのライブコーディングがいい刺激になりました!suspenseはまだunstableとのことですが早く使えるようになってほしいです!
  • Apolloはちょっとさわったことありましたが、Reduxの面倒なとこが減りそうだなという期待が広がりました!
タイトル 発表者
読みやすいコードの書き方のススメ @hmktsu
React HooksとReduxとProxy @dai_shi
ちょっと先のReact @koba04
ApolloとReactを使ったアプリケーション設計 @about_hiroppy

読みやすいコードの書き方のススメ

  • @hmktsuさん
  • 株式会社g&h

読みやすいコード

  • 他の人と作業する時流れが理解しやすい
  • 久しぶりに見ても迷わない

Reactのコードを読みやすくするポイント

eslint-config-airbnb

  • ルール厳し目
  • 誰が書いても似たようなコードになる
  • VSCodeの拡張と組み合わせてauto-fixもおすすめ

defaultProps

importの整理

  • 順番が適当だと分かりづらい
  • 順序のルールを決めておく

React HooksとReduxとProxy

  • @dai_shiさん

React HooksとReduxとProxy

  • function componentsで全て完結する仕組み

Redux とReact Redux

  • Reduxは99行だけ
    • React関係ない
  • React Redux
    • Reactに依存したライブラリ

React Reduxの代替

  • Reduxを使わずにHooksで同じようなことを実現
  • Reduxは使うけどReact Reduxは使わずに実現

Reduxの問題点

  • stateはグローバル
  • stateの一部の変更で関係ないcomponentまでレンダリングされてしまう
    • selector指定
    • memorizeする
    • auto-detectする

auto-detect

  • 何もしなくてもselectorを指定したときと同じように動かす
  • Proxyを使う
    • stateのうちどの部分が使われたか知ることができる
    • Proxyが重いけどなんとか使えるレベルでは動いてる

ちょっと先のReact

  • @koba04さん

ライブコーディング

コード

github.com

ApolloとReactを使ったアプリケーション設計

  • @about_hiroppyさん

GraphQL

  • サーバサイドでqueryを定義
  • エンドポイントは一つだけ

Apollo

Apollo Client

  • queryをサーバに投げる
  • 結果をUIに返す
  • キャッシュとかもやってくれる

apollo-link-state

  • ローカルの状態をGraphQLのクエリを使い処理する
  • mutation投げるときにローカルの処理もできる

ApolloとRedux

  • Reduxと比べてApollo
    • fetchのフラグ管理がとても楽
    • 部分更新が簡単
    • リモートとローカルを同一クエリで表現できる
    • 複雑な処理を書くのはあまり向いてない

まとめ

  • Apolloはエコシステム含めて充実している
  • Reduxのコード減らせる可能性高い

「Yahoo! JAPAN Tech Conference 2019」に参加してきました

  • Yahoo! JAPAN Tech Conference 2019に参加してきました。

techconference.yahoo.co.jp

  • 昨年参加してとても面白かったので今年も参加しました。
  • 技術の話だけでなく、それを使って何を目指しているかまで話してもらたえたセッションが多くありとても勉強になりました。
  • 講演中にも資料を見られるように事前に公開してくれたり、twitterのモーメントを即時に作成してくれたり参加者への配慮がありがたかったです。
タイトル 発表者 タイトル 発表者
13:00 基調講演 - (twitterまとめ) 藤門 千明 / 仲原 英之
14:00 もう道に迷わない! Yahoo! MAPにおけるAR体験 - (twitterまとめ) 徳元 健太 / 廣橋 孝紀 パスワードレス普及への取り組み/ヤフーのデータ戦略を支えるID連携 - (twitterまとめ) 三原 一樹 / 本間 洋光
15:00 ライブクイズ「ワイキュー」を生み出した"内因的モチベーションドリブン"/ワイキューが目指した"楽しい時間を作るデザイン" - (twitterまとめ) 善積 正伍 / 染矢 沙織 データの力で実現するYahoo!ショッピングのCRM - (twitterまとめ) 市丸 数明
16:00 ユーザーコミュニケーションの新たな武器、けんさくとえんじんの秘密 - (twitterまとめ) 武井 友里恵 ライブ動画配信サービス「ワイキュー」の作り方 - (twitterまとめ) 石井 直矢
16:25 LEAN XPを活用したユーザーの声を聞くものづくり 〜Yahoo! JAPAN タブレットアプリのリニューアル〜 - (twitterまとめ) 馬場 敬寛 豊かなスポーツライフの実現を目指す、スポーツナビのシステムアーキテクチャ - (twitterまとめ) 北村 央斗
17:00 拡張性あるデザインシステム構築から挑む、GYAO!のウェブリニューアル - (twitterまとめ) 浜田 真成 Kubernetesで実現したYahoo! JAPANの次世代開発環境 ~ 100以上のクラスタを少人数で運用する秘訣 ~ - (twitterまとめ) 稲津 和磨 / 勝田 広樹
18:00 CtoC配信サービスのバックエンドからiOSアプリまで ~ヤフオク!ライブの全貌とXP開発~ - (twitterまとめ) 出水 厚輝 / 大西 智也 / 山下 真一郎 Yahoo! JAPANの巨大インフラの運用と展望 - (twitterまとめ) 奥村 司 / 神尾 皓 / 安藤 格也

基調講演

テーマ

  • 未来につづく話をしよう

yahooの取り組み

  • インターネットを通じていろいろなサービスを提供している
    • Search, Know, Read, Pay, Notify, etc...

Technology

  • いろんな技術
    • Search-Tech
    • AD-Tech
    • UI/UX
    • Security-Tech
    • Recommend-Tech
    • Fni-Tech
  • 共通点はデータxAI
    • データからよりよいモデルを作る
    • よりよいコンテンツでユーザが増える
    • データが増えるのでよりよいモデルを作れる
  • 足りなかったもの

kukai

  • 2015年から開発してる
  • 2017年リリース
  • GPUのサーバ
  • 液体につけて熱を冷ましてる
    • どうしても電気代がかから
    • 電力使いすぎは持続性がない
  • スパコンのノウハウない
    • 「データとAI」でチューニングに挑戦

kukaiを使った効果

ヤフオク

  • 不適切な商品が出品される
  • kukaiでAIを使った
    • 排除の量が3.1倍
    • モデルのビルドが1.5hで終わる
      • 毎日モデルを変えられる
      • 従来は100h

yahoo知恵袋

  • 不適切な質問や回答がある
  • kukaiを使ってランキングが上に来ないようにとか隠すことができた
  • 全質問回答(6億)を学習させた

大切にしてる技術

  • Security-Tech
  • 安心して使ってもらうために必要

セキュリティの取り組み

  • セキュアな通信レベル向上
  • 2018/6~TLS1.2に切り替え
  • 暗号化すると通信量が増えるコストが増加する

yahooの取り組み

  • HTTPS
    • 2017年中に全サービス移行済み
  • TLS1.2
    • 2018/6までに決済サービス移行済み
    • 2018/10に全サービス移行済み

TLS1.2へ

  • TLS1.2にする不都合
    • 対応していなブラウザを使ってるとみれなくなる
    • 全体の3%
  • 移行の戦略
    • 売上よりも安全を優先
    • 全サービス移行
      • 決済系以外も
    • 早めに広く告知
  • 次はTLS1.3
    • OpenSSLのバージョンを1.1にあげないと使えない
    • 今後取り組んでいくことになる

CI/CDの重要性

  • セキュリティの対応はすぐに反映させないといけない
  • CI/CDがととのっているとすぐにリリースできる
  • CIの中で問題を事前に検知できる取り組みも進める
  • DevSecOps

パスワードレス普及への取り組み/ヤフーのデータ戦略を支えるID連携

  • 三原 一樹さん
  • 本間 洋光さん

Yahoo! Japan IDの現状

  • ヤフー
    • EC事業
    • メディア事業
  • ヤフーIDユーザ
    • 4587万

これまでのパスワードレスの取り組み

課題

  • セキュリティとユーザビリティの両立
  • パスワードを忘れたことがある:96%
  • パスワード使いまわしてる:73%
  • => ログインが手間、不正アクセスのリスク

解決策

  • パスワードレス化

SMS認証

  • パスワードをそもそも設定させない
  • ID入れるとスマホにメール
  • 確認コード入力しログイン
  • ユーザビリティ面でまだ改善余地あり

生体認証

  • FIDO
    • セキュリティと利便性の両立を目指す
  • パスワード認証
    • ユーザの入力とサーバが保持しているものを検証
  • FIDO認証
    • 端末で検証し端末上の秘密鍵で暗号化
    • サーバ側で公開鍵で復号できれば認証
    • サーバに生体情報が送られるわけではない
    • Webで実現する -> FIDO2

今後

  • パスワードレスログインの訴求
  • 対応デバイス拡大(今はAndroidでしか実現できない)

yahooのデータ戦略とID

  • 提供サービス100以上
  • ヤフーID連携で他サービスと連携
    • データの蓄積
    • データの活用

アプリ利用の促進

  • ブラウザのログインを引き継ぐ
  • ログインしてるからこその機能を提供
  • ヤフーIDを使うアプリのどれかでログインしてればそれが引き継がれる
  • 月間4587万ユーザ

ヤフーID連携

  • OpenID Connectを使っている
  • Webもアプリも同じIDでログインできる

他サービスでの利用

  • ヤフーIDでログインできるようになる
  • ヤフーIDに紐づく情報が連携可能

事例

  • ヤマト運輸
  • ヤフーIDでクロネコメンバーズにログインできる
    • ログイン時に住所等の提供の同意画面
    • クロネコ側でヤフーに登録してる情報を使える
  • クロネコ側での配送予定情報をヤフーに提供
    • ヤフーアプリのプッシュ通知で配送予定を知らせる
    • 配送情報の提供もID連携時に同意をとる

まとめ

  • データ活用にはログインしてもらうことが大切
  • 社外と連携することでできることが増えてくる

データの力で実現するYahoo!ショッピングCRM

  • 市丸 数明さん

Yahoo!ショッピングCRM

  • CRM - 顧客関係管理
  • ユーザの行動属性を分析
    • ユーザの買い物の満足度を上げる
    • 売上を最大化する
  • データをもとにユーザにフィットした対応をする
    • 通知を無視し続けるひとは自動で配信停止するとか
  • リアル店舗にはできないCRMを実現する
    • 1 to 1の対応はリアルに勝る

CRM実現の仕組み

  • CRM5w1hで考える
  • UI - 接点
    • Web、アプリ、通知
  • EDW - データ
    • ユーザのデータをためてる
  • CRM - 施策管理

Yahoo!ショッピングならではのしくみ

  • 一周たりともページを止めてはならない
    • フロントとバックのJSを分けてる
  • 非機能要件のSLAが高い
    • 数万qpsを捌く
    • 200ms以内
  • 数千万件のユーザにPush配信を行う
    • 同じオファーを二回送ってしまうとかは絶対ダメ

事例①

  • 離脱直前ユーザへのオファー
  • CVRを確認すると特定のPV数で一回落ち込む
    • 離脱しやすさにスコアをつける
    • スコアが一定以上になったらオファーを出す

事例②

  • 定期購入リマインド
  • 定期購入対象の商品の定義
    • 同じカテゴリに属する商品を2回以上
    • 多くのユーザが該当するもの
  • 再購買時期の予測
    • サンプルユーザのデータをもとに分析
    • 商品に応じて通知するタイミングをチューニング

これからのCRM

  • Whenの最適化
    • データ分析・利活用をリアルタイム化
    • 今は毎日バッチで処理
  • サービス間のデータを相互利用
    • 他サービスのデータをもとにオファー
    • 似たユーザの統計情報をもとにオファー
  • システムをマイクロサービス化
    • CRMはモノリシック
    • DDDでリプレイス中

まとめ

  • yahoo全てのデータを活用
  • リアルタイム化
  • 最新アーキテクチャで実現
  • 究極の1 to 1へ

ライブ動画配信サービス「ワイキュー」の作り方〜優れた社内技術で実現する、少人数のサービス開発〜

  • 石井 直矢さん

ワイキュー

  • 3人だけでで開発してる
  • ライブ動画配信
  • コメント
  • 出題/回答
    • 短時間にアクセスが集中する
  • Tポイント
    • リアルタイム性より堅牢性

まとめ

  • 多くの機能が社内のプラットフォームで提供されている
    • ライブ配信とか不正ワード検知とか
    • ログインとかCI/CDとかも
  • 機能ではない部分を考えることにも集中できた
    • どうやって楽しく使ってもらうか

豊かなスポーツライフの実現を目指す、スポーツナビのシステムアーキテクチャ

  • 北村 央斗さん

スポーツナビ

  • 月間平均PV:46億
  • 月間平均UB:5710万
    • UniquBrowser

スポーツナビのシステム

  • 豊富なデータを使うシステム
    • 幅広い競技の情報
    • 競技に特化した詳細な情報
  • データ提供元と連携して表示している

プロ野球速報アプリ

  • 一つの画面に様々なデータ
  • 一球ごとの結果をリアルタイムに届ける
    • 提供元から受け取ったデータをすぐにアプリへ届ける

今後

  • データが増えても保守し続けられる仕組み
  • 取り扱う競技を拡充しやすくする仕組み
    • 競技横断のシステム

スポーツナビの運用

  • 特定のタイミングで負荷増
    • オリンピックの羽生結弦の登場タイミングとか
  • CaaS/PaaSへの移行を進行中

拡張性あるデザインシステム構築から挑む、GYAO!のウェブリニューアル

  • 浜田 真成さん

GYAOのリニューアル

  • レガシーWebからの脱却
    • 10年続くモノリシック
  • 既存プロダクトを維持して事業目標を達成

課題

モノリシック(FatView)

  • ロジックとViewが混ざってる
    • リファクタできない
  • ロジックが局所化

テストの欠如と手動リリース

  • テストは手動で
  • リリース作業1時間

セマンティックWeb

UI一貫性の破綻

  • 同じような部品

パフォーマンス

  • 初期描画が遅い

仕様の複雑化

  • 暗黙の了解で仕様が分からない
  • ドキュメント内

複雑なワークフロー

  • 直列なやりとり

技術戦略

Webアーキテクチャの段階移行

  • 段階移行
    • 並行稼動期間がある
  • phase1
  • phase2
  • pahse3
    • PaaSへ移行
    • TypeScript導入

パフォーマンス改善

  • パフォーマンス指標
    • RAILモデルをベースにサービス固有のものを追加
      • 動画の開始は2秒以内
  • 初期表示の速度改善
    • TTIやFMPの指標を重視
  • APM採用

コンポーネントシステム

  • AtomicDesignの思想をベースに
    • Page - Layout - Components - Basic
  • 関数型的なinputに対してoutputが一意になるコンポーネント

デザインシステム

  • デザインをプロダクトに届けるまでのプロセスを「仕組み」にする
  • 仕様の更新と開発をあわせて行う
  • ポイント
    • 常にコンポーネントの粒度で考える
    • 信頼できる唯一の情報源を作る
    • UI/UXの意図を残していく

組織を変える

  • 運用を止めない
    • システムの考え方を普及させる
    • システムを学ぶバックアップ体制

まとめ

  • 負債を確実に解消
  • 技術選択と移行プロセスを見極めよう
  • デザインシステムによってプロセスを構築する

今後

  • マイクロサービス化
  • パフォーマンスのさらなる改善
  • PWA(キャッシュの有効活用)

CtoC配信サービスのバックエンドからiOSアプリまで ~ヤフオク!ライブの全貌とXP開発~

  • 出水 厚輝さん / 大西 智也さん / 山下 真一郎さん

ヤフオク

  • 1999年から続くCtoC ECの老舗
  • 一分間に2000個出品
  • 年間8800億円の流通

ヤフオクライブ

  • リアルタイムに動画配信しながらオークションできるサービス

バックエンド

リアルタイムコミュニケーションシステムをどう構成するか

  • 不特定多数ユーザの双方向通信
    • いいねとかコメントとか
  • サーバ側からのプッシュ送信
    • 商品の追加/入札/落札
不特定多数ユーザの双方向通信
  • WebSocketで双方向通信実現
  • 膨大なユーザをどう扱うか
    • 複数台のサーバどう同期するか
    • RedisのPubSubを使ってる
サーバ側からのプッシュ送信
  • RedisのPubの部分を使ってる

ヤフオク!の既存機能値どのように共存させるか

アーキテクチャ
  • モノリシック
    • 多人数で開発するとコンフリクト
    • 通信レイテンシは小さい
    • プログラム肥大化
  • マイクロサービス
    • 多人数での並行開発が容易
    • 各プログラムを小さく保てる
    • サーバ間の依存性の管理が複雑化
  • マイクロサービス化へ
バックエンドの構成
  • ヤフオクだけで40機能がある
    • そこにライブの機能を追加
    • 商品へ依存が集中してしまう
    • 更新がいらない情報は各機能がコピーを作ってそれを使う
  • 機能ごとにプラットフォームを選択できる
    • FaaS/PaaS/CaaS/IaaS
    • マイクロサービス化されたからそれぞれ選べる

iOSアプリ

  • WebSocketでやりとり
  • リアルタイムなUIの変化
    • タイミング
    • 画面の状態
    • 大量・連続
  • アニメーション
    • 自前で実装
      • ユーザのインタラクションが発生するもの
    • Lottie
      • jsonをもとに作る
      • デザイナーが自由にこだわることができる

分析の取り組み

  • 配信者の声をもとに改善したい
    • 全部見るわけにもいかない
    • 文字起こしする(Speech to Text)
    • それを分析にかける(形態素解析)

開発手法

課題

  • 開発効率低下
  • 品質低下
  • 属人化

解決法

まとめ

  • テストがあれば細かいバグにも気づける
  • テストがあるから自身を持ってリファクタできる

「Bonfire Frontend #3」に参加してきました

  • Bonfire Frontend #3に参加してきました。

yj-meetup.connpass.com

タイトル 発表者
技術刷新から考えるWeb開発のプロダクティビティ改善 竹野 峻輔 / Retty 株式会社
一休.comのフロントエンドパフォーマンス改善 宇都宮 諒 / 株式会社一休
パフォーマンス改善の具体例とサービスへの売上貢献 笹原 翼 / ヤフー株式会社

技術刷新から考えるWeb開発のプロダクティビティ改善

  • 竹野 峻輔さん(Retty 株式会社)

フロントエンド戦国時代

  • 一昔は
  • 今は
    • BFFとかFluxとか
  • 明らかなパラダイムシフト
    • サーバ主体からクライアント主体へ
  • Rettyの現状
    • モノリシックが不便になってきた
    • 中長期的な視点で改善したい
    • アーキテクチャ

なぜリアーキテクチャ?

  • なぜ?
    • パフォーマンス改善(UX)を持続的に行うための土壌(DX)を築いて行く取り組み
  • マイクロサービス化
    • ただ分割するだけではだめ
    • 境界に注目する
  • 凝集化と分割(modukaruze)
    • 性質が近いものをまとめる
  • 持続的な変更可能性の確保(sustainability)
    • 拡張削除がしやすいように
  • プロダクトもチームも作り変える
    • コラボレーション
    • 親和性
      • チームとして力を集約する

一休.comのフロントエンドパフォーマンス改善

一休のサービス

  • 一休.com
    • ユーザ単位でのコンテンツ出し分け
    • 広告はなし
  • 一休コンシェルジュ
    • WordPressベース
    • ログインなし全員同じコンテンツ

最適なパフォーマンス

最適化のものさし 

  • Lighthouse
    • いろんなところに組み込まれるようになってる
    • 毎回同じ環境で測定するのがいい
    • PageSpeed Insightsなど
  • PageSpeed Insights
    • URLを入れるだけ
    • 細かい設定はできない
  • WebPageTest
    • 環境の条件を設定できる
    • デフォルトで3回計測してくれる

Lighthouseのスコア

  • スコア
    • 0-49: Slow
    • 50-89: Average
    • 90-100: Fast
  • 指標
    • TTIが一番重みが強い
  • スコアと指標どっちみる?
    • スコアはいろんな指標の組み合わせ
    • 仕様変更でも変わる
    • 具体的な指標を見た方がいい
    • スコアは他のサイトとの相対評価で便利
  • ECサイトなら
    • 50こえれば速い方
    • 70超えたら業界トップクラス
  • メディアサイトは
  • 30-40くらいが多い
    • 最適化をあまり頑張っていないようなところがこの辺

Webサイトの一般的な最適化

  • 速くするより遅い要素を減らす
  • 遅い要素
    • サイズの大きな画像/フォント
    • JS
    • 大量のHTTPリクエス
    • 重いDBアクセス
  • 一休.comの場合
    • キャッシュきかせづらい
      • リアルタイム性が重要
      • 検索クエリ
    • 画像サイズ適正に
      • Imgix
      • 欲しいサイズのパラメータつけて取りに行くと加工して返してくれる
      • https://www.imgix.com/
  • 一休コンシェルジュ
    • 全員同じコンテンツを返すのでキャッシュしやすい
      • Fastlyでキャッシュ
      • TTFB最小化10-20ms
    • 画像最適化
      • Imgix
    • JSできるだけ使わない
    • AMPの活用

パフォーマンスのためのアーキテクチャ

  • パフォーマンスに影響のある要素
    • SPAかMPA
    • SSRするか
    • CDNキャッシュ戦略
    • ServiceWorkerの活用
  • JAMStack
    • サーバサイドはAPIのみ静的HTMLのみ
      • SSRしない
      • キャッシュがきくようになるから
    • レンダリングは全てJSということ
      • SEO問題
      • DynamicRendering
        • Googlebotに対してJS描画済みの静的HTMLを返す
        • 実験中

まとめ

  • パフォーマンス最適化は計測から始まる
  • パフォーマンスの伸びしろは要件次第
  • 大幅なパフォーマンス改善にはアーキテクチャレベルの変更が必要

パフォーマンス改善の具体例とサービスへの売上貢献

  • 笹原 翼(ヤフー株式会社)

ヤフーショッピングのパフォーマンス改善

  • ヤフーショッピングのパフォーマンス改善
    • => ページの表示速度アップ
  • 半年でCVRが110%へ

なぜパフォーマンス改善

  • 改善前
    • FirstViewをAmazon楽天と比べると3位
    • 表示速度0.1廟宇減ると売上1%増加(Amazon)
  • ヤフーショッピングでの進め方
    • 速度とKPIの相関をABテストで証明

どこでパフォーマンス改善

  • どのページ
  • Frontend/Backend
  • クライアント/サーバ

どのページ

  • アクセスが多いページ
  • そこを通って買う人が多いとこ

Frontend/Backend、クライアント/サーバ

  • SpeedCurve
    • 定期実行できる
    • グラフ化できる
    • 色んな指標とれる
    • 競合比較できる
    • 改善結果が見やすい
    • 5万回まで測定可で月5万

どんなパフォーマンス改善するか

  • どの指標を見ていくのか決める
  • 安定した測定環境を整える

遅い/直列APIの非同期化

  • ファーストビューの扱いは注意

間違った非同期

  • 画像は全部lazyloadingすればいいわけじゃない
  • 思考停止lazyよくない

画像のpreload

  • 読み込み開始が速い

JSとCSSのpreload

  • 前のページで次のページのリソースとっておく

JSとCSSの非同期読み込み

  • 無理なら1ファイルの容量を減らす

画像の最適化(画質)

  • 画質90 -> 85に変更
    • 容量40%減
    • 50ms減

画像の最適化(解像度)

  • Retina対応
  • 適したサイズを

ハードのリプレイスすけ^ルアウと

  • 高スペックで高速化

JSとCSSの軽量化

  • カバレッジを見て使ってないリソースは削る
    • Devtoolsで見られる

どんな効果があったか

  • 競合3社中2位に
  • CVRが110%へ
  • SEOにもいい影響
    • クロール量の増加

今後

  • 更にパフォーマンス改善
  • AMP?
  • 計測は実ユーザデータ使いたい

「Cloud Native Meetup Tokyo #6」に参加してきました

  • Cloud Native Meetup Tokyo #6 KubeCon + CNCon Recapに参加してきました。

cloudnative.connpass.com

  • あまり詳しい領域ではないですが情報キャッチアップのために参加しました。
  • みなさん説明が論理だっていてわかりやすく雰囲気をつかむことができました。資料公開されているものは改めて確認したいと思います。
タイトル 発表者
Cortexの話をKubeConで聞きたかったっていう話 Shinya Uemura(@uesyn)
KubeCon + CNConに見るetcdの未来 Akihiro Ikezoe(@zoetro)
Monitoring Kubernetes Audit Log by Falco Makoto Hasegawa(@makocchi)
KubeCon + CloudNativeCon 2018 Seattle Recap ~Vitess~ Yutaka Ichikawa(@cyberblack28)
KubeCon + CNConでみたPrometheusの今後 Yoshi Shota(@yosshi_)

Cortexの話をKubeConで聞きたかったっていう話

  • Shinya Uemura(@uesyn)
  • KDDI & Creationline

KubeCon

  • Cortexのセッション一つ

Prometheus

  • メトリクス収集してローカルストレージに保存する
  • Long-term Storageではない

Cortex

  • Prometheusメトリクスのストレージ
  • マルチテナント型のモニタリングサービスを実現する

アーキテクチャ

  • 長期データS3やGCSに保存
  • chunkデータはDynamoDBやCassandraに保存

github.com

マルチテナント

  • リクエストヘッダ内のIDでテナント判断
  • テナントIDをもとにprometheusがふりわけ
  • 認証認可の機能はないのでIDを付与して送る実装を自前でする必要がある

kubernetes上で動かす

  • 「人類にははやすぎる」
  • まだリポジトリにreleaseブランチないしtagもついてない
  • 公式の入門ドキュメントまだない
  • フロント自前実装しないとマルチテナント使えない
    • nginxでやると楽だった

まとめ

  • cortex情報まだ少なめ

KubeCon + CNConに見るetcdの未来

  • Akihiro Ikezoe(@zoetro)
  • Cybozu

KubeCon

  • KubeConでetcd関連のセッション5つ

etcd

  • 分散キーバリューストア
  • HighAvailable
  • 強い整合性
  • Raftによる分散合意
  • k8sやVitessやCoreDNSなど多くの分散システムのバックエンドで使われてる

etcdの未来

  • CoreOS(Redhatに買収された)が作ってる
  • Container Linux
    • Fedora CoreOSが後継
    • 2020年いっぱいはメンテされる
  • rkt
    • Redhatとしては開発ストップ
  • etcdは?
    • CNCFのプロジェクトに採用
    • RedhatからCNCFに寄贈
    • CoreOSの外のメンテナ多いので体制に変化はなさそう

etcdの新機能

  • Raft Learner
  • etcd operator
  • Server Downgrade
  • Cluster init

Raft Learner

  • etcdはRaftという分散合意アルゴリズムを使ってる
  • クラスタからリーダーを選出
  • リーダーがメンバーにハートビート
    • リーダーは常に一つ
  • 問題点
    • データ同期中はI/O負荷高い
    • 同期中にネットワーク分断すると障害起きてしまう
  • Raft Learner
    • 同期中はLearnerという状態になる
    • その間は分散合意のメンバーとしてカウントされない

Cluster init

  • etcdの起動オプションいろいろ設定めんどくさい
  • 自動的にメンバーごとの名前やリッスンするアドレスなどを解決

etcdadm

  • etcdの運用大変
  • k8s上にetcdクラスタの運用
    • etcd operator
  • etcdadm
    • 実機やVMで動かしているときに使う
    • k8sに特化
    • etcdのクラスタの構築運用を自動化してくれる
      • メンバー追加/削除
      • バックアップ/リストア
      • アップグレード/ダウングレード
      • 証明書の管理

トラブルシューティング

  • etcdctl
  • auger
  • etcd-dump-logs

まとめ

  • etcdはk8sをはじめいろいろなところで使われている
  • CNCFに加わりメンテは安心して良さそう
  • 今後は運用者向けに嬉しい機能が出てきそう

Monitoring Kubernetes Audit Log by Falco

概要

  • Falco Deep Diveのセッション内容の紹介

Falcoとは

  • Container Native Runtime Security
  • コンテナ環境のセキュリティをモニタリング
  • CNCFのsandboxプロジェクト
  • モニタリングするだけ遮断とかはしない
  • 検出された時には手遅れだけど検出できる仕組みをつくることは重要

モニタリング

  • DKMS(Dynamic Kernel Module Support)によってmoduleがbuild/installされる
  • Ruleをyamlで書くことでモニタリングするイベントを定義

通知

  • 検知時にプログラム実行できる
  • webhookすればslack通知なんかもできる
  • Falco.yamlに設定

medium.com

k8sのaudit logをモニタリング

  • k8sのaudit log
    • k8s APIの呼び出しを時系列に記録
      • 怪しいリクエストの調査
      • 統計情報の収集
    • ファイル書き出し以外も対応(webhook等)
  • GKEではdefaultで有効になってる

k8sにfalcoを入れる

  • docker runでも動く
  • Helmのchartがあるのでそれが楽
  • falco operatorもある

KubeCon + CloudNativeCon 2018 Seattle Recap ~Vitess~

  • Yutaka Ichikawa(@cyberblack28)
  • APC

セッションサマリ

  • KubeCon
    • Vitess関連は3つくらい
    • 移行事例のセッションも
    • Intro
    • Deep Dive

Vitess

  • MySQLのshardingで水平にスケールするクラウドネイティブなDBクラスタ
  • goで出きててgRPCで通信
  • 事例
  • Sharding
    • 2つ以上のDBに分割してデータを格納
    • パフォーマンス向上
    • 垂直
      • テーブルごとに複数DBに格納
    • 水平
      • 1つのデーブルを複数Shardに分割して格納

HubSpotの事例

  • 10年間AWSを利用
    • 30日でGCP + k8s + Vitessに移行
  • なぜ?
    • シャーディングが魅力的だった
    • k8sとの親和性
    • OSS
  • 500データベースをアップデート

まとめ

  • youtubeの実績は強い
  • プロダクション事例増えつつある
  • k8sとの親和性の高さ
  • システムに合わせてチューニングは必要
  • Vitess as a Serviceなるものが生まれてきそう!?

KubeCon + CNConでみたPrometheusの今後

  • Yoshi Shota(@yosshi_)
  • NTT Communications

Prometheusの課題

  • 長期保管機能ない
    • 保管期間のばすと性能劣化
    • -> アダプターを使ってサードパーティストレージに保存
  • デフォルトで冗長構成がない

長期保管

  • Thanos
  • Cortex
  • M3

Thanos

  • 複数のPrometheusを横断して収集したい
  • 無制限に保管したい

Grafana Loki

  • ログの収集と可視化ツール
  • メトリクスだけではインシデントの全容の半分しかわからない
  • メトリクスとログの参照切り替えコストを最小限に抑える
  • まだAlpha版なのでproductionでは使っちゃだめ

Demo

https://grafana.com/video/loki_intro.mp4

「第1回AtomicDesignについて考える会」に参加してきました

  • 第1回AtomicDesignについて考える会に参加してきました。

thinkatomicdesign.connpass.com

  • AtomicDesignに関して様々な視点からの考えが聞けて学びが多かったです。
  • エンジニアとデザイナーあわさって、共通の考えを持って取り組むのがよいという意見が多かったです。
  • AtomicDesignにこだわりすぎずプロジェクトの中での共通認識のベースにしていくというのが良さそうと感じました。
  • パネルディスカッションでの質問の多さからもみんな悩んでるんだなってのを実感できました。
タイトル 発表者 ロール
コンポーネント指向から見るAtomic Design camcam_lemon (camcam_lemon) フロントエンドエンジニア
デザイナー・エンジニアのコンポーネント分割境界と、その理想郷 resessh (resessh) フロントエンドエンジニア
AtomicDesignを導入する理由と悩み sakito (mki_skt) フロントエンドエンジニア
手戻りが少ないアトミックデザインの導入 fujiken (kenshirof) デザイナー
Redaing The Atomic Workflow 腹筋ローラーの力を信じろ (8845musign) デザイナー
StorybookでAtomicDesignなコンポーネント管理してる話 masaya (msykd) フロントエンドエンジニア
サーバーサイドエンジニアがAtomicDesignを学んでみた remsleep_zzz (remsleep_zzz) サーバーサイドエンジニア
Atomic Design との上手な付き合い方 takanorip (takanori_oki_9) フロントエンドエンジニア

コンポーネント指向から見るAtomic Design

  • camcam_lemon (camcam_lemon)
  • フロントエンドエンジニア

AtomicDesign

  • 考えること多い
  • よく分かってないままアプリ単位で採用してるから
  • チームに合った設計を取り入れるのが正解ではないか

コンポーネント指向

  • UIパーツを部品として使う
  • 見た目と機能をカプセル化
  • 粒度が小さいほど再利用性が高まる

UIライブラリ

  • よく使うUIパーツを提供
  • AtomsかMoleculesを提供する
  • 再利用性に極振り
  • ロジックは入り込まない
  • UIライブラリのパーツに加えて再利用されないAtomsやMoleculesをアプリで作る

まとめ

  • 小さい単位で考えると悩みが減る
  • 再利用性に特化したUI設計に集中
  • 小さく始めて大きくスケール

デザイナー・エンジニアのコンポーネント分割境界と、その理想郷

  • resessh (resessh)
  • Retty
  • フロントエンドエンジニア

デザイナー視点

  • ユーザ行動をベースに考える
    • 画面を開いて関心のあるコンテンツを探す
    • コンテンツを理解
    • 手順を理解
    • アクションを実行する

エンジニア視点

  • コンテンツ内のレイアウトとコンテンツ外のレイアウト
    • 外 -> サイドバーとかヘッダーとか
  • データソースが決まったコンポーネントとそうでないコンポーネント
    • Storeにアクセスできるかどうか
    • Container Component / Presentational Component

コンポーネントの分類

  • Organisms
    • URLを持っていることが多い
    • アクションも付随していることが多い
    • 特定のデータソースに依存してもよい
  • Molecules
    • コンテンツが一つで完結しない
    • 特定のアクションを行うUI
    • 特定のデータソースに依存しない
  • Atoms
    • HTMLのタグに対応
  • 迷う時は
    • デザイナーとエンジニアが分類について対話できる環境があるとよい

AtomicDesignを導入する理由と悩み

  • sakito (mki_skt)
  • Yahoo
  • フロントエンドエンジニア

なぜ導入したか

  • デザイナーとエンジニアでコンポーネント分割の考え方が違う
  • 人数が多くて指標がなかった
    • 個人に依存
  • 導入して指標ができた

導入して抱えた悩み

  • PagesとOrganismsどの単位でReduxをConnectするか
    • プロジェクトの規模によりけり
  • AtomsなのかMoleculesなのか
  • エンジニアだけで導入してもダメ
    • デザイナーのアウトプットとの認識齟齬があってはいけない

まとめ

  • デザイナーとエンジニアで密にコミュニケーションをとる大事さは変わらない
  • チームにフィットした形で柔軟に返ることも大事

Redaing The Atomic Workflow

  • 腹筋ローラーの力を信じろ (8845musign)
  • デザイナー

The Atomic Workflow

  • 静的なカンプではなくブラウザに早く持っていくべき
  • Role
    • UX Designer
    • Visual Designer
    • Frontend Developer

UX Designer

  • コンテンツの並びを書いたもの
  • ページの構造と階層
  • レイアウトを作らずに議論できる

Visual Designer

  • The 20 second gut test
  • Style Tiles
    • 色とかフォントとかをまとめたもの
    • ビジュアルの洗練なしにレイアウトについて検討できる
  • 静的カンプ
    • 作らないわけではない
    • 全体像を描くのには有効
    • 段階が進んでからかく

Frontend Developer

  • デザイナーと近い席に座るべき
  • デザインプロセスのコアパート
  • 先行してマークアップしていくべき

ワークフロー

  • ブラウザでイテレーションすること
    • 一度ブラウザでデザインしたらブラウザにとどまり続けるべき
    • 意思決定を動くものでするべき
  • パターンベースで回す
    • 使い回せる

まとめ

  • ブラウザで生きた設計を
  • 常に全体を見て設計を
  • AtomicDesignの本質はステークホルダー全員との合意形成プロセス

手戻りが少ないアトミックデザインの導入

開発初期

  • 新規事業でAtomicDesignを導入
  • デザイナー一人
  • デザインデータが管理しきれなくなる
    • このデザインどっかで使ってたけどどこかにあるか分からん

導入前

期待

  • 管理が楽になる
  • 使い回しの適用がしやすくなる
  • スピードがあがる

導入してみて

導入するなら

  • カトナ期待はせずに
  • 定期的な整理整頓が待ってる
  • 整理で進捗が止まることを伝えておこう

導入中

  • 整理整頓そんなにうまくいかない
  • 整理整頓してる暇がなくて大きくなってしまう
  • コンポーネント化しすぎて無駄に時間かけすぎた
    • 適度にやることが大切

導入後

  • 曖昧さを許容すること
  • コンポーネントの粒度どうしてますか?
    • デザイナーとエンジニアで話し合ってる
    • 見てる視点が違うから理解し合うことが大切
  • 最初は特定の動作に特化した部品
    • 徐々に汎用的な部品に
  • ほとんどのデザインはすぐに消える

まとめ

  • 導入前:覚悟をもとう
  • 導入中:タイミングと量に注意
  • 導入後:曖昧さを許容しよう

StorybookでAtomicDesignなコンポーネント管理してる話

  • masaya (msykd)
  • モノオク株式会社
  • フロントエンドエンジニア

モノオク

  • モノの保管場所に困ってるユーザとスペースが余ってるホストをマッチング
  • React/Redux

Storybook

Storybookいいところ

Storybookつらいところ

  • メンテがめんどくさい
  • 開発に追われていると時間がない
  • コンポーネントマネージャーをおいた

まとめ

  • Storybook便利
  • 1,2人くらいのチームだとメンテコストのほうが高い
  • 他と比べてメンテの優先度下がりがち
  • 目的をもって運用方針を考えるべき

サーバーサイドエンジニアがAtomicDesignを学んでみた

  • remsleep_zzz (remsleep_zzz)
  • CyerBuzz / STARACT
  • サーバーサイドエンジニア

導入事例

  • うまくいった
    • デザイナーがReactかけたり
    • フロントエンドがAPI書いたり
    • といった環境だったから

サーバサイドから見ていいところ

  • 共通言語として使える
    • 学習コスト少し高い -> 習得後のブレが少ない
    • プロジェクトの途中から導入するるのはとても大変
  • 開発速度の向上
    • organismsとpagesだけにstateをもたせる
    • それよりも小さい粒度はstatelessなので爆速で作れる
    • Reduxみたいなところはフロントエンドエンジニアにまかせてコンポーネント単位で作り込める

まとめ

  • サーバサイドエンジニアからみてAtomicDesignのメリット
    • 共通言語としての役割
    • 粒度間違えなければ開発爆速

Atomic Design との上手な付き合い方

  • takanorip (takanori_oki_9)
  • フロントエンドエンジニア

思うこと

  • AtomicDesignに真面目すぎる
  • 設計の手助けのはずが難しくしている
  • 大雑把に付き合うことが大切
    • そこが本質ではない

意識すること

  • 最小単位(Atoms)を意識すること
    • それ以外はある程度全体見えてきてからでよい

なぜつらい

  • 考えることが多いから
  • ルールを整備することで考えることを減らせる
  • 再利用しないものとしてコンポーネントを作る
    • 通化しすぎると捨てづらくなる

責務を分ける

  • Pages/TemplatesとOrganisms以下の責務の分離

デザイナーを巻き込むこと

  • エンジニアだけでこういう話をするのは良くない
  • デザイナーにAtomicDesignの概念をフローに入れてもらう
  • 単位はデザイナーに決めてもらうのがいい

コンポーネントのデザイン

  • デザイン管理はFigmaが優秀
  • StoryBookもあるけどデザイナーが使うことも考えるとFigma

パネルディスカッション

  • コンポーネントガイドないとつらいですか?
    • レビュアーがつらい
    • PR出された時にそれもうありますって言えないとつらい
    • Storybookはディレクトリ構造をしっかり練ることが大切
  • コンポーネント命名規則
    • MoleculesはInputWithButtonのようにelement名をつけるようにするとわかりやすい
    • 使う時はSerchFormみたいな名前になるかもしれないけど

「Repro Tech : Frontend Reliability support NAVITIME」に参加してきました

  • Repro Tech : Frontend Reliability support NAVITIMEに参加してきました。

repro-tech.connpass.com

  • フロントエンドのreliabilityがテーマということでリアルな開発現場の苦労話を多く聞けました
  • Reproのイベントでしたが半分は豪華なゲストスピーカーということでバランス良かったです
タイトル 発表者
E2Eテストを継続するために brn
ReproのWeb SDK開発を支える技術 cheezenaan
続・Vue.jsによる大規模開発 kazupon
フロントエンド開発の土台としてのチーム作り 渡部啓太
クックパッドにおけるwebフロントエンドの改善 @hokaccha
フロントエンドと向き合う @treby

E2Eテストを継続するために

E2Eテスト

  • ユーザと同様に操作して機能を確認するテスト
  • Selenium等で自動で打鍵
  • メリット
    • ユーザが触る画面を直接テストするので確実性高い
  • デメリット
    • 遅い
    • アニメーションとかAPIアクセスとか遅い
    • 謎のエラーで失敗したり不安定
    • メンテナンス大変

E2Eのメンテ

  • CSSセレクタでDOMを選択
    • 変化が多いから大変
  • styled-components使ってるとE2E用にクラスつけないと
    • 自動生成のクラスが付与されるから
  • -> 放置されがち

デメリットの解決策

  • 遅い
    • アニメーション等はクラス名変えて停止してテストするとか
  • 不安定
    • リトライ入れて対応する
    • BrowserStack等外部環境を利用するとか

メンテナビリティ

  • メンテナビリティを実現するにはHTMLの構造に立ち入らないこと

VisualRegressionTest

  • スクショとって画像で比較
  • 前回と比較して変化がないかテストする
  • 変更ないのに差分検知してしまうことも
  • 失敗した理由がわからない
    • 結果しか見えないから
    • 目で見るようにする
    • 部分実行できるように作る

ブラウザ操作レイヤーの抽象化

  • ページ遷移とかはボタン押したりするのでHTMLの構造に依存してしまう
  • Graph Based PageObject
    • ユーザの操作単位でメソッドをきる
    • 部分的な実行もしやすくなった

まとめ

  • CIの整理やレビュー体制等のプロセスが大事
  • プロセスがアウトプットの品質を決める

QA

  • E2Eどれくらい時間かかってる?
    • CIで回してて30分くらい
    • mergeするタイミングで回してる
  • IE対応どうしたらいい?
    • BrowserStack使うか
    • Windowsサーバ立てるか
    • IEだけ手動でもいいと思う
  • SeleniumIDEどう?
    • その時通るテストしか作れないから手直し出てしまう
    • 雛形作るものとしては使えるかも

ReproのWeb SDK開発を支える技術

  • cheezenaanさん(Repro)

Web SDK開発

SDK

  • Software Development Kit
  • アプリ提供者向けの便利なライブラリ集

Web SDK

  • ブラウザ上でで動くSDK
  • ネイティブアプリと比べるとブラウザの分一層多い
    • ブラウザの種類・バージョンの差異がつらい

ReproのWeb SDKに求められること

  • 安心安全で信頼できるSDKを提供したい
  • なるべく多くのブラウザで動かしたい
  • プラットフォーム・バージョンどこまで対応する??
    • ビジネス要求と開発リソース次第

実際の取組み

  • ほぼ最新Chromeを基準にGraceful Degradation
  • 標準化されてないブラウザAPIは過信しない
  • 外部ライブラリへの依存を極力減らす
    • 使ってるライブラリ
  • ファイルサイズは小さく保つ
    • polyfill入れるくらいなら自分で書く
  • UnitTest手厚く
    • ブラウザ差異はE2Eで
    • 浅く広く作ってる
  • E2E

まとめ

  • ブラウザという壁から逃げずに向き合うことが大事
  • 依存少なくテスト手厚く

QA

  • WebSDKのE2Eどんなことやってる?
    • サンプルアプリに適用してテストしてる

続・Vue.jsによる大規模開発

  • kazuponさん

Vue

中大規模向け開発

  • 複数人で開発する
  • 生産性やメンテナンス性を考慮
  • 最初からフルスタックにはサポートしない
  • 公式にライブラリは提供してる

開発環境セットアップ

Vue CLI 3

  • プラグインベース
  • 構築拡張メンテが楽
  • VueCLIのレールから外れることはできない
  • ts対応
  • prettier
  • cypress

Vue CLI UI

  • ブラウザ上でVueCLIでできることは一通りできる
  • プロジェクト管理
  • GUIベースで設定
  • コマンドライン苦手な人に優しい

その他

  • VSCode + Vetur(VSCodeプラグイン)
  • eslint-plugin-vue
  • 通信
    • REST -> axios
    • GraphQL -> vue-apollo
  • 状態管理
    • VuexはTSだとつらい
  • E2Eテスト
    • cypressも使えるようになった
    • NightWatch

アプリ設計

コンポーネント設計

  • AtomicDesignに従いSFCを抽出
  • 秩序がたもてるなら無理にAtomicDesignに従わなくてもいいと思う

状態モデリングとデータフロー

  • UI使用から状態に落とし込む
  • モデルとAPI仕様はバックエンドと認識齟齬ないように工夫が必要
    • swaggerやOpenAPI Generator
    • Consumer Driven Contruct

ルーティング設計

  • スクロール位置喪失問題

アプリ実装

  • TS入れるといい
    • VueCLI3なら簡単に導入できる
  • TDD
    • テストはjestを推奨
      • スナップショットテストが便利
    • コンポーネント、データフロー、ルーティング全部TDDやる必要はない

デバッグ

  • Vue Devtools 5でより便利に

まとめ

  • VueCLI3で環境構築が楽になった

フロントエンド開発の土台としてのチーム作り

組織作り

  • すべての人間が同じ方向を向くことが大事

以前

  • お互い何をやってるか分かってなかった

やったこと

  • 情報の同期
    • ファイブフィンガー朝会
  • 情報の共有
    • 自分は何が得意
    • 何を期待する
    • 偏愛マップ
    • 自分の取説
    • スキルマップ
  • 目的の明確化
    • 我々はなぜここにいるのか
  • 毎週振り返り

今後

  • ビジネスサイドとの協働
  • 高負荷の解消

まとめ

  • チーム力は開発力の土台
  • チームと個人を向き合わせる
  • 振り返りでカイゼン

クックパッドにおけるwebフロントエンドの改善

クックパッド

  • Rails化して10周年
  • いろんな負債が積み重なってる

クックパッドのフロントエンド

  • Performance
  • Productivity

performance

techlife.cookpad.com

Productivity

  • 生産性をいかに上げるか

エラートラッキング

  • 全社的にsentry使ってる
  • ノイズがひどいので対応中

コードの整理

  • 現状
    • どこに何書いてあるか分からん
  • 対応
  • 既存コードを動かしながら対応するのは大変

モダン化

今後

  • 各チームが自由にライブラリ選定できる体制にしたい
  • Micro Frontendとか
    • 理想だけど難易度高そう

フロントエンドと向き合う

  • @trebyさん(Repro)

フロントエンド

  • フロントエンドはこわれる
    • ES2015でまともになってきた
  • 変化が激しい
  • テスト充実させたい
    • フロントエンドは簡単に壊れる
  • 3つの柱
    • 技術
    • チーム
    • 根性

「UIT#5 わたしたちにとってのVue.js」に参加してきました

  • UIT#5 わたしたちにとってのVue.jsに参加してきました。

uit.connpass.com

  • UITは#2から毎回参加していて4回目の参加でした(#4の参加レポート)
  • 今回はVueにフォーカスした勉強会で、事例を中心に技術選択の参考になるお話を聞けました。
タイトル 発表者
ゆるふわに既存Vue(Nuxt)プロジェクトをTypeScriptに移行してみた @Motonori Iwata
カメラを利用したアプリを作って約1,000人で遊んだ話 @KenjiroKubota
jQueryからVue.jsへリファクタしたPJの話 @tak
さくらのフロントエンド さくらの Vue.js @ravelll
Vue.jsは裏切らない @Yuji Yamaguchi
building better Vue components with storybook @julien

ゆるふわに既存Vue(Nuxt)プロジェクトをTypeScriptに移行してみた

  • @Motonori Iwata

TSへの移行

  • 社内ツールをTSに移行
  • Nuxt
  • Firebase
  • コンポーネント23個
  • 新規開発は停止
  • 4週間で移行完了

移行の順序

  • components -> utils/plugins/middleware -> store -> test
  • testが通ること確認しながら

設定

  • tsconfig.json
    • alloJSは一時的にtrueで
    • implicit anyは弾く

Linter

  • Xoを使ってる
  • https://github.com/xojs/xo
  • 型引数にしか使ってない変数がエラーになる
    • no-unused-varsをoffにして対応
  • 結構罠がありそうだからTSLintの方がいいかも

Components

  • vue-shims.d.tsをおく
  • vue-convertを使ってclassに変換

Test

  • jest使ってる
  • ts用のjestを追加

カメラを利用したアプリを作って約1,000人で遊んだ話

  • @KenjiroKubota(株式会社アイスタイル)

社内のイベントでアプリを作った

  • 表情を検出して笑顔度を測るアプリ

技術

WebRTC

  • WebRTC API
  • videoのリソース開放も忘れずに
  • requestAnimationFrame()
      • beforeDestroyで都度終了させないと重くなっていく

まとめ

  • Vueはググれば情報豊富
  • VueCLIのおかげでwebpackの苦労が不要
  • Firebaseすごい

jQueryからVue.jsへリファクタしたPJの話

  • @tak(LINE)

背景

  • 古い技術スタックのプロジェクトを担当した
  • どうやってリプレイスしていったのか

現行とゴール

  • LINE Webログイン
    • SSOを実現するページ
  • 現行ページ
  • 新ページ(順次公開予定)

なぜ置き換える必要あったか

  • 既存コード
    • 複雑に絡み合っていた
    • 担当者のスコープや責任が明確になっていなかった
      • CSS/HTMLの変更でもサーバサイドに手が入る
  • データやイベント発火フローの確立
  • 今後のリッチなUIへの対応
  • jQuery -> Vue
  • VueCLI3
  • バックエンドではエントリーポイントのルートコンポーネントだけ作成

リプレイス方法

  • $('xxx').on -> v-on
  • $('xxx').hide -> v-if
  • 等々

移行の例外

  • グローバルなメソッドを使った暗号化処理
  • 無理せずそのままにした
  • 外部ライブラリ的に使えるようにした

まとめ

  • データフローが明確になって運用コスト下がった(はず)
  • リファクタリングが危険な道は回避することも大事

さくらのフロントエンド さくらの Vue.js

さくらのフロントエンド

  • サーバ屋さんのフロントエンド
  • Vueがけっこう使われている
  • Vueの使い所
    • コントロールパネル
    • 問い合わせ/申し込みフォーム
    • 社内向けツール

なぜVue

  • デザイナと協業しやすそう
  • 公式からツールが出てる安心感
  • 日本語ドキュメント充実

事例

  • サービスコトロールパネルを刷新した
  • メンテしづらく属人化
    • Vueにリプレイス

技術スタック

  • Vue + Vue Router + Vuex
  • SPA, 非SSR, 非Nuxt

ディレクトリ構成

  • components
    • storeにはアクセスしない
  • pages
  • plugins
    • アプリ全体の挙動を変更する実装
    • Vue.useして使うもの
      • Vuelidateとか
  • utils

エラー検知

  • Sentry
    • 導入簡単
    • 401(セッション切れ), 422(APIのバリデーションエラー)以外を記録

テスト

  • コンポーネントのテストは複雑なとこだけ
  • データフロー以外のロジックを含むStoreのメソッド
  • jest使ってる

パッケージアップデート

  • yarn upgradeしてPR投げるCIを週一で
    • これはマイナーバージョンだけ
  • メジャーバージョンは手動

困りごと

  • デザイナーとの協業
  • コンポーネントの細かい挙動をSketchで伝えるのが大変
  • storybookを導入しようとしてる

Vue.jsは裏切らない

事例

従来

  • jQueru製の独自FW(2014末)
  • BabelifyでES6化
  • 秘伝のタレの積み重ねで完成度は高い
    • でも継続性に不安

やったこと

  • Browserify -> Webpack
  • Grunt -> Gulp/npm script
  • Mocha -> Jest

心がけたこと

  • 小さく移行する
    • 稼働してるプロジェクトだから
  • 画面ごと部品ごとに
  • さわるところだけとかリファクタリングだけとか
    • I/Fが変わらないことが大事
  • レガシーコードでもロジックは資産

良かったこと

  • バックエンドから転向組でもスムーズだった
  • template/script/styleのSFCわかりやすい
  • 人材が少ない中で誰でもそれなりに

難しかったこと

  • 自由にできすぎる
  • やらないことを決めるのも大事

まとめ

  • 利益をだしてるサービスの継続性は重要
  • Vueなら徐々に移行できた

building better Vue components with storybook

  • @julien(LINE)

Atomic Design

Vueに適用

  • 親から子はproperty
  • 子から親はイベント
  • propertyは一番シンプルに
  • 兄弟要素で相互に通信するのはだめ
    • 親を介してやりとりする

Storybook

  • 簡単にインスール/セットアップできる
  • whiteroom
    • Vueで作ったStorybook
    • Storybookの足りないところがあったから自作した
  • Vueで作ってるからライフサイクルを意識する必要がない
  • イベントも全部見れる
  • propertyとeventを同時に見ることができる

「Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状」に参加してきました

  • Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状に参加してきました

cookpad.connpass.com

  • Cookpadにおけサービスメッシュ、gRPC、ECSの導入事例を紹介してもらいました。
  • gRPCやEnvoy等気になっているサービスの話を聞くことができて参考になりました。
  • 講演だけでなくQAセッションもあり、採用する技術に対する深い話も聞くことができてとてもよかったです。
タイトル 発表者
クックパッドでのサービスメッシュについて 小野大器
gRPC in Cookpad 岩間雄太
Amazon ECS の安定運用 鈴木康平

クックパッドでのサービスメッシュについて

背景

  • 開発者200+
  • サービス100+
  • 色んな開発チームとSREチーム
    • 運用をSREチームから各チームへ移していきたい

課題

  • 昔は大きなモノリシック
    • 今は100近いアプリが相互に連携通信している
  • マイクロサービス内でインシデント起きた時の特定が大変
  • キャパシティプランニングも難しい
  • 何が起きているか見えるようにしたい

解決策

  • Expeditor
  • aws-xray
    • 分散トレーシング
  • ruby以外も各々作って改善を続けていかないといけない
  • ネットワークプロキシを挟んでそこでやらせればいいのではないか
    • サービスメッシュ
    • 2017年ころから

導入と運用

  • 2017年はじめに計画
  • 2017年終わりにMVP作った
  • 2018年から利用

Envoy

  • 当時使えるもので一番良かった
  • Istioはまだなかった
  • AmazonECSを使っていた
    • IstioはKubeが前提だから使えないかも

ゴール

  • 各アプリで管理するのではなく中央で制御したい
  • メトリクスはPrometheus
  • 運用コストを抑えたい

運用

結果

  • 一時的なエラー率上昇がタイムアウトリトライの設定で回避できるようになった
    • SREチームの負荷が下がった
  • 設定が中央に集まったのでレビューしやすくなった
  • Observability
    • 情報が可視化されるようになった

QA

  • 冪等性をどう担保している
    • GET/PUTは自動でリトライ
    • POSTとgRPCはリトライできると分かったるものはリトライ
      • デフォルトはリトライオフ
  • Istio使わない?
    • 今の構成で安定してるから今はこのまま
  • マイクロサービスを導入するタイミングは?
    • 組織が大きくなってきてコミュニケーションコストが大きくなってきたとき
    • 明らかペイするのは2000人とかの規模

gRPC in Cookpad

これまでのCookpadのサービス感通信

CookpadでのgRPC

gRPC

  • IDLとしてProtocol Buffersが使える
  • Protocol Bbufferでクライアント/サーバのコード生成
  • 多言語対応
  • HTTP2上で動作
  • Interceptorでログ、認証、エラー処理など

gRPCの運用

  • 基本的にhako上で
  • cookpad.comでも使ってる
  • Envoy経由でリクエストを受ける

サービス定義(ProtocolBuffer)の管理

  • 1つのリポジトリで管理
  • サービスごとにディレクトリを切ってる
  • ciでlintも入れてる
  • ドキュメントもciで自動生成
    • protoc-gen-doc

メトリクス

  • Envoyコンテナでメトリクス取る
  • Prometheusに入れてGrafanaで見る

rubyでgRPC

  • grpc gem
    • C, C++で作られたものをRubyの拡張として使用
    • マルチスレッド(シングルプロセス)
  • grpc-tool gemでクライアント/サーバのコード生成
  • 公式のgRPC実装を使用してる

今後

  • Envoyの機能を使ったかなりあリリース
  • 自作gRPCライブラリへの移行
  • grpc-gatewayの導入

QA

  • gRPCをRESTで叩くことはしてない
    • gRPC使う時はクライアント/サーバどちらもgRPCでやってる

Amazon ECS の安定運用

前提

  • ほとんどのアプリがECSで動いてる
  • hakoを使ってデプロイやバッチ起動
  • ECSインスタンス 40
  • ECSサービス 500
  • 1日あたりのRun Task 80000

コンテナインスタンスの管理

  • オンデマンドインスタンスはAutoScalingGroup
  • スポットインスタンスはSpotFleet
  • オンデマンド:スポット=1:4
  • Fargate
    • 一部使ってるけど基本自前管理
      • 自前のほうが安いから
      • 起動が遅いし起動時間が安定しないから
    • 使うケース
      • ECSクラスタのオートスケールするジョブ
      • 特別大きいCPUリソースを使うジョブ

オンデマンドインスタンス

  • 自前でオートスケール
  • AutoScalingGroup

スポットインスタンス

  • オートスケールは自前
  • SpotFleet

オートスケーリング

スケールアウト
  • CloudWatchの値をチェックして閾値を超えたらスケールアウト
  • 各サービスの値をチェックしてスケールアウト
  • hako oneshotがリソース不足で失敗したときにSQSで通知を受け取ってスケールアウト
スケールイン
  • CloudWatchの値をチェックして閾値を下回ったらスケールイン

ログ

  • fluentd経由でS3に保存
  • Athenaで簡易検索できるようにしてる

CloudWatch Logs

  • 量が多すぎてピークタイムではリアルタイムにに入りきらない
  • スケーラブルで安価なS3を使うことに

ログ配送

  • 各コンテナからfluentdの集約ノードへ転送
    • 集約ノードには大量のログが来ることになる
  • 集約ノードのfluentdが1分毎にログをS3へ

ログ検索

  • Athenaで検索できるようにGlueでカタログを日時更新

モニタリング

  • CloudWatchにサービス単位のメトリクスはある
    • タスク単位やコンテナ単位はない
  • アプリ開発者はアプリコンテナのメトリクスだけ見たい
  • cAdvisorでメトリクスを取得しPrometheus送りGrafanaで可視化

QA

  • なぜECS?なぜkubeでない?EKSは?
    • 運用する人が多くないからできるだけマネージドがいい
    • EKSがECSくらい使いやすくなったら使うかも
      • 今はECSほどマネージドではない
      • 今すぐ移行するというほどではない