「UIT#6 進化する React.js」に参加してきました

  • UIT#6 進化する React.jsに参加してきました。

uit.connpass.com

タイトル 発表者
Hooks で作る React.FC Takepepe
Page Stack again in React sunderls
現場から届けるReactの悩みと改善 sakito

Hooks で作る React.FC

  • Takepepeさん(DeNA)

サービスフロントエンドアニメーション

  • アニメーションネガティブ要因
    • ただ派手なだけ
    • 予測不能な動き
    • テストつらい
  • 速度 === UXなアプリもあればそうでないアプリもある
  • アニメーションが向かないアプリ
    • 読み物系
    • 遷移が多い
  • 明確なユーザストーリーが描けるものは活用するべき

機能としてのアニメーション

通知機能

  • 利用者が興味がないフェーズ
  • 悪目立ちさせない

補佐機能

認知機能

対話機能

  • 利用者と対話するフェーズ
  • 従順な反応
  • リアルコミュニケーションと同じ

耐火機能

  • 利用者が評価するフェーズ
  • アプリからの要求対価

React Hooksとアニメーション

従来のReactとアニメーション

  • アニメーションは非同期
  • classにする必要ある
  • cssに関する知識がいる

React Hooksとアニメーション

  • Classが不要に
  • メモ化が簡単
  • アニメーションもやりやすくなった
  • useContextで0~1の係数を管理して子に伝播する
  • function componentに気軽に後からアニメーション追加できるのがいい

Page Stack again in React

  • sunderlsさん(LINE)

アプリとWeb

  • アプリとWebどちらがいいか?
    • ユーザは気にしない
  • googleとかinstagramはアプリを推してる

アプリの何がいいのか

  • 速いのがいい?
    • twitterのアプリとWebを比べるとあまり変わらない?
  • アプリの方がトランジションがあってよい
    • Webでもがんばればできる
  • アプリはページ遷移がスタックされてる

現場から届けるReactの悩みと改善

  • sakitoさん(yahoo)

担当のプロジェクト

  • フロントエンド15人
  • BtoB

刷新

  • React + TypeScript
  • SassからEmotion

TypeScript採用前

  • 採用前はJSDocを頑張って書いてた
  • 更新されずに放置される
  • propsを確認するUnitTestメンテ辛い

TypeScriptの採用

  • TypeScript採用で実装スピード遅くなってしまわないか?
    • コンパイルでエラー分かるのが効率的だった
    • 修正箇所がわかりやすい
    • propsのデータがわかるから開発しやすい
  • 使えないライブラリないか
    • そんなことなかった
    • 今どきのReactライブラリはTypeScript対応してる

SassからEmotion

  • ファイルサイズが小さい
  • styled-componentsのようなstyled記法だけでなくCSS Props記法が使えるのがいい
  • コンポーネントCSSが一対一になったので削除しやすい

ReduxFormからFormikへ

  • ReduxFormつらかった
    • バリデーションは拡張しないとつらい
    • 簡単なフォーム作るには便利
  • Yupというバリデーションライブラリと合わせて使うとやりやすかった

Reduxの構成変更

  • 従来は1ページ1store
    • コピペが乱立
  • re-ducks
    • ducksを拡張していい感じにしたもの
    • それぞれのファイルの責務がわかりやすくなった
    • テスト書きやすくなった
    • そこそこ規模大きめな時に向いてるのかな?
  • Immerを採用
    • ImmutableJSはハードル高い
      • Redux周り以外にも影響ある
    • Storeのデータ構造の操作が見やすくなった
    • 開発メンバー多くてもimmutableな状態を保ちやすい
    • レビューもしやすい

「Frontend de KANPAI! #6-みんなのサービスづくり-」に参加してきました

  • Frontend de KANPAI! #6-みんなのサービスづくり-に参加してきました。

frokan.connpass.com

タイトル 登壇者
note を Nuxt.js でリプレイスしている話 石川 大地さん
サービスドリブンな開発 森口 慎哉さん
WebXR Device API 株式会社小山田 晃浩さん
開発を担当した三年間の振り返り takepepeさん
プロダクト開発におけるスキルと肩書 谷口 祐貴さん
体験と設計 フロントエンドエンジニアの二つの責務について potato4dさん

note を Nuxt.js でリプレイスしている話

noteリプレイス

  • AngularJS -> Nuxt
  • Elastic Beanstalk使ってる
    • Lambda使ってたけどaws-serverless-expressでエラー
  • 二重メンテつらいけど徐々に移行してる

サービスドリブンな開発

  • 森口 慎哉さん(株式会社ZOZOテクノロジーズ)

開発体制

  • サービス単位でチームがある
  • やりとりはslackなどでオープンに

フロントエンド環境

WebXR Device API

  • 小山田 晃浩さん(株式会社ピクセルグリッド)

WebXR Device API

  • 2019/2ファーストドラフト
    • GoogleCanaryでも使えない
    • 前はflag立てればいけたけど変わった
  • OpenXR

HitTest

Quic Look

  • iOSの床を認識する機能

開発を担当した三年間の振り返り

技術選定

  • DeNAはVueが多め
    • Reactの知見も作りたいのでReactを選択
  • 型システム
    • ReactならFlow(という時代だった)
    • 今はTypeScript
    • 型があるから長期運用できている
  • フレームワークに知識を載せすぎるとつらくなる
  • 賢いUIは移植が大変
  • ライブラリの作法には乗ったほうがいい

プロダクト開発におけるスキルと肩書

モダンなプロダクト開発のフェーズ

  • Discovery
    • 課題の発見アイデアの探求
    • プロトタイピング
    • デザイン思考
  • Delivery
    • ものを作って届ける
  • どちらに情熱を注ぐか

ユーザ体験を構成する段階

  • 五段階
    • Surface(表面)
    • Skelton(骨格)
    • Structure(構造)
    • Scope(要件)
    • Strategy(戦略)
  • どこに興味があってどこができるか考えてキャリアを考えると良い

体験と設計 フロントエンドエンジニアの二つの責務について

  • potato4dさん(LINE株式会社/ElevenBack)

フロントエンドエンジニアの責務

  • アーキテクトとして持続可能な開発体制を作る責務
  • より良い体験を提供する責務

より良い体験を提供する責務

  • フロントエンドエンジニアが一番インターフェースをさわってる

フロントエンドエンジニアだからこそできること

  • フロントエンドエンジニアは器用貧乏
    • サーバサイドほどアーキテクチャに時間をとれない
    • デザイナーほどUI/UXに時間をとれない
  • どの領域も基礎知識があって掛け算できるのが強み

「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やコード補完も今後対応しないといけない