「JSConf JP(Day2)」に参加してきました

勉強会メモ
  • JSConf JPに参加してきました。
  • 2日目の参加メモです

jsconf.jp

タイムテーブル

時間 タイトル 発表者
11:00- 時間はただの幻想である… JavaScriptにおいては Jennifer Wong
InversifyJSを用いたレイヤードアーキテクチャの構築 奥野 賢太郎
Vue.js で D3.js を使ったインタラクティブなデータの可視化 Shirley Wu
11:30- ストリームの人生 Dominic Tarr
Build and scale multiple Voice application by using TypeScript Hidetaka Okamoto
13:00- Web の体積 Jxck
正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終 Masato Nishihara
パスワードは90年代の代物だ Sam Bellen
13:30- JavaScript, Rust and Wasm Walk into a Ramen Shop ... Irina Shestak
Migration from React Native to PWA ohbarye
npm i -g @next-and-beyond: Building the future of package management Claudia Hernández
14:15- JSConf Panel Talks Jan Lehnardt and Yosuke Furukawa
GraphQLを用いたECサイトにおけるパフォーマンス改善 澤井宣彦
Minimum Hands-on Node.js 栗山 太希
14:45- 悪用された npm パッケージの分析 Jarrod Overson
JavaScriptのままでTypeScriptを始める 高梨ギンペイ
15:30- Browser APIs: 知られざるヒーロー達 Rowdy Rabouw
Your benchmark may not guide a real application performance Tetsuharu OHZEKI
16:00- Anatomy of a Click Benjamin Gruenbaum
JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned. 榊原昌彦
Recruit Speed Hackathon 新井 智士
16:45- AIとJavaScript による生物認識 Jonny Kalambay
大規模アプリケーション開発でのElm実践 海老原 圭吾
17:15- Pika: レジストリの再創造 Fred K. Schott
最新のWeb技術でIoT開発をする 木戸 康平

InversifyJSを用いたレイヤードアーキテクチャの構築

  • 奥野 賢太郎さん

密結合とは

  • 修正を加えた時にその影響箇所が見つけづらい状態
    • 予期しないところに影響が及ぶかもしれない状態
    • DBの構造
    • 外部サービス
    • APIの構造
    • 画面の構造
  • 例
    • 画面の入力フォームの構造のままテーブル設計してしまった
    • 画面の構成変えたけどDBいじる余裕ないから無理やり対応することに・・・
  • 抽象化する中間の層が必要

レイヤードアーキテクチャ

  • DDD
    • Domain Driven Design
  • MDD
    • Model Driven Development
  • Repository

DIP

  • InversifyJS
    • DIの機能を提供するライブラリ
    • constructor injectionできる
    • TypeScriptで書いた方が相性が良い
  • TSyringe
    • Microsoft製
    • InversifyJSと同じ感じのやつ
    • 好みではあるけど登壇者はこっちの方が好き
  • レイヤーごとにmodel objectを用意する
    • バグが起きたときの影響範囲がわかりやすいように寿命を短くするとよい
  • value objectを作るようにする
    • バリデーションはconstructorで
  • knex
    • ORMapper

Build and scale multiple Voice application by using TypeScript

  • Hidetaka Okamotoさん

スマートスピーカーのバックエンド

  • 音声/言語処理系の知識がなくても開発できる
    • Speach To Textや自然言語処理はサービス側の責務
    • バックエンドには処理後のJSONが送られる
  • Webhookの開発と同じような感じ
    • SlackやLINEのbotに近い
  • 文脈を覚えておくためにDBも持っておくことが多い

Alexa開発

  • ask-adkを使う
  • スキルが増えると起こる課題
    • スキルが増えるとLambdaも増えるからruntimeの更新など面倒
    • 同じような処理がいろんなスキルに存在してしまう
  • 多機能な1スキルか単機能な複数スキルか
    • 単機能なスキルの方が使いやすい
    • でも見つけてもらうのが大変かも
  • ServerlessFrameworkを使うと便利
    • 全部yamlで管理できる
    • runtimeのアップデートなども設定かえるだけ

まとめ

  • VUIはWebhookライク
  • in/outのフォーマットが一定のためTS相性良し
  • 汎用FWがまだない

正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終

  • Masato Nishiharaさん

背景

  • Node6を使ってたが2019/4にEOL
  • Node8は2019/10にEOLだったので一気に10に
    • 10のEOLは2021/4

やったこと

  • Node変更差分確認
  • 依存パッケージの変更差分確認
  • 全機能テストを複数回

パッケージの差分

  • 依存ライブラリのリリースノート全部見たりするのは現実的でない
  • Node10に対応しているか明記していないものもあった
  • =>全機能テストで動けばよいとすることに

全機能テスト

  • ブラウザバリエーションもあるので大変
  • 1回目で不具合を出して対応して2,3回目もやった

リリース後

  • CPU100%にはりつくトラブル
  • スレッドの切り替えをする処理が多発していた
    • Nodeはシングルスレッドじゃないのか？
    • 内部的にはマルチスレッドで動くところもある
    • libvuの中でマルチスレッドを利用している
  • このケースでは原因はDBサーバだった
    • 障害のあったサーバからDBサーバへのアクセスが遅延していた

まとめ

  • こまめに上げるようにするとよさそう
  • コアな部分だけでも自動テストはあった方がいい

Migration from React Native to PWA

  • ohbaryeさん

React NativeからPWAへ

  • iOS/Andorid対応のRNアプリをiOS/Android/Web対応のPWAにする
    • 後者のiOS/AndroidはWebViewでPWAを表示する

なぜReactNativeだったか

  • プッシュ通知など使いたいからスマホアプリがいい
  • iOSエンジニアがいなかった

BYOD化

  • 端末を用意してインストールして渡してた
    • 端末配布をやめてBYOD化することにした
    • Android版の提供も始めることにした

マルチプラットフォーム対応

  • iOSで動くのにAndroidで動かないとかがかなりあった
  • JSのエラーなのかライブラリの中身が悪いのかネイティブのレイヤーが悪いのか

パッケージ管理

  • ReactNativeはnpmでライブラリ管理してるがその先にiOS/Androidのライブラリがある

ビルドデプロイシステム

脱ReactNativeの選択肢

  • PWA
  • Nativeで書き直す？
  • Flutter
  • => ブラウザで見たいという要件もあったのでPWAで
    • React使った

通知

  • Push Notificationの実現
    • AndroidはWebでも使える
    • iOSはWebViewとして使うのでネイティブの機能を使う

WebViewで苦労したこと

  • キャッシュのレイヤーが増えることに注意
  • WebViewのキャッシュを無効化するメソッド用意したりとか

PWAで供料したこと

  • Android ChromeだとアイコンにつけるバッヂはまだExperimental
  • フォアグラウンドでの通知がAndroid PWAだけ挙動が違った

テスト

  • cypressでintegrationテスト書いてる
  • ReactNative時代はスナップショットテストとかやってた

運用してみて

  • Webなので即時反映されるのでいい

まとめ

  • チームメンバーのスキルセットにあった技術選定が大事
    • 開発できる = 運用できるではない
  • モバイルアプリに近い体験要求されてもWebでもできるかも

GraphQLを用いたサイトにおけるパフォーマンス改善(ECサイトを題材に)

  • 澤井宣彦さん

背景

  • 歴史が長くページ遷移が遅い
  • 全社のリブランディング
  • ページ遷移の改善
  • 技術スタックの改善

リニューアル

  • フロントはReactをTSで
  • Backendは既存RailsをAPI化
  • API定義はGraphQL
    • トップページをリッチにしたい構想
    • フロント側に自由度をもたせたいから

パフォーマンス改善

計測

  • 実機で行うテスト
  • 合成環境で行うテスト
    • PageSpeed Insighrsを使った

ボトルネックの特定

  • ChromeのAudit
  • Opportunitiesの改善項目

改善

フロント側の改善
サーバ側の改善
  • APMを活用
    • 既に入れていたDataDogを活用
  • N+1のDBアクセス問題
    • batch-loader(rubyの場合)などを使って対応するようにする
QueryとSchemaの改善
  • ページングのない配列のrequest
    • 関連するレコードが全件取得されるので性能が劣化
    • ページングをつけて件数指定する
    • schemaのlinterで未然に防げそう
  • 全く使ってないデータを取得している
    • queryを消せばよい
    • なぜ画面に紐付いてないqueryが書かれてしまうか
    • FragmentとColocation
    • Fragment
      • queryを部分的に切り出したもの
      • 再利用できる
      • 部分定義できる
    • Colocation
      • Fragmentを集約して1つのqueryにまとめる
    • Reactコンポーネントの階層とqueryの階層をあわせるようにする

今後

  • Cacheの活用を検討
    • リアルタイム性が低いコンテンツもある
    • ゲストユーザは同じものが基本的に表示される
    • CDNのレイヤーでHTML/responseどちらもできるはず

JavaScriptのままでTypeScriptを始める

  • 高梨ギンペイさん

TypeScriptのいいところ

  • JSのスーパーセットであること
  • 型を持つこと

Typed-JavaScript

型がつくと何ができるようになるか

  • バリデーションできる
    • 関数を呼ぶ時にどんな引数を渡さないといけないか？
      • ドキュメント見る？
      • 動かしてみる？
      • 型があればすぐに分かる
      • エディタが対応してればその場でわかる
  • エディタの補完がきく
    • 自分で作ったAPIの補完も型を用意しておけば補完される
    • 標準関数なんかもググらなくてもその場で候補がでる
  • リファクタリングがしやすい
    • 変数名後から変えたり型を後から変えたり
    • 変更漏れがあればコンパイルエラーになってくれる

使い方

  • tsconfig.json
    • allowJsをtrueで.js対象になる
    • checkJSをtrueでjsもチェック対象になる
    • noEmitをtrueで型チェックだけするようになる
    • checkJSをfalseにしてチェックしたいファイルにコメントで@ts-checkつけるでもいける

まとめ

Your benchmark may not guide a real application performance

  • Tetsuharu OHZEKIさん

ソフトウェアのパフォーマンス

  • 遅いソフトウェアより速いソフトウェアの方がよい
  • どのように速くするか
    • Dont't guess, measure
  • ベンチマークを使う

ベンチマーク

  • シナリオに沿ったベンチマークになってますか？
  • 一般的な指標はベンチマークの1つでしかない
    • Lighthouseだけやってればいいわけではないケースも多い

JSの最適化

  • 一度の実行だと数ミリsecで差がわかりづらい
    • じゃあ数万回実行しよう
    • =>それでいいの？
      • 何度も実行されるとJSVMが複数レベルで最適化してくれる
      • その処理は何度も呼ばれるような処理なのか？

どのように改善を進めるか

  • プログラムを速くするには遅くなるようなことをやらないことが重要
  • CIとしてベンチマークを計測して継続してプロットするといい
    • 容易に起動できて再現可能であるようにする
    • 細かい上下は必ず起きる
    • 長期での傾向をチェックする

まとめ

  • パフォーマンスを改善するにはリアルなシナリオが必要
  • 闇雲に測定するのではなくリアルなシナリオに基づくこと
  • ベンチマークテストをテストケースの1つとして追加し実行できるようにすること
  • まずはどのように使われていてどのように速くなると嬉しいのか調べるところから

JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned.

  • 榊原昌彦さん

Capacitor

  • Webでアプリを作ってWebViewで表示できる
  • ネイティブの機能にアクセスできる
  • デスクトップアプリとしても作れる

Capacitorの使い勝ったあ

  • @capacitor/core
  • @capacitor/cli

iOS

  • SwiftをどうやってHTML/JSにつなげるのか
    • npx cap init
    • WebViewを100%表示されるものができる
    • Poddileでnode_modulesの中から引っ張ってきてる
  • HTML/JSがどうやってSwiftにアクセスしているか
    • ブリッジがwindowオブジェクトに値を埋め込んでる
  • Androidもだいたい同じ

UI

  • iOS/Androidそれぞれガイドに沿った見た目にできる

「JSConf JP(Day1)」に参加してきました

勉強会メモ
  • JSConf JPに参加してきました。
  • 1日目の参加メモです

jsconf.jp

タイムテーブル

時間 タイトル 発表者
13:00- Opening talk yosuke furukawa
13:30- The State of JavaScript Raphaël Benitte and Sacha Greif
14:15- 「繋がり」の可視化 Nadieh Bremer
WebAuthnで実現する安全・快適なログイン Eiji Kitamura / えーじ
JavaScript AST プログラミング: 入門とその1歩先へ Takuto Wada
14:45- 「オープンソース」の定義 Henry Zhu
覚醒するアクセシビリティ Lena Morita
4年分のプロシージャルなJS Andy Hall
15:30- Building and Deploying for the Modern Web with JAMstack Guillermo Rauch
Wrap-up: High Performance JavaScript Sho Miyamoto
JS開発者のためのSEOテクニック Martin Splitt
16:00- Write What Not How Jorge Bucaran
How to Boost Your Code with WebAssembly FUJI Goro / @gfx
Playing Pokémon Together with Node.js Samuel Agnew
16:45- Deno - JavaScript の新たな道筋 Kitson Kelly
Streams APIをちゃんと理解する 加藤 健志
You might also like... Maria Clara
17:15- Headers for Hackers Andrew Betts
Make it Declarative with React Toru Kobayashi
Web Accessibilityのすゝめ Nazanin Delam
18:45- 予測的 Prefetching によるパフォーマンス改善 Praveen Yedidi
18:55- Web Components era phase 2 Yoshiki Shibukawa
19:05- Cache Me If You Can Maxi Ferreira
19:15- Node.js でつくる Node.js - WASM/WASI ミニミニコンパイラー がねこまさし
19:25- React アプリのライセンス違反について dynamis

The State of JavaScript

  • Raphaël Benitte
  • Sacha Greif

JavaScriptの歴史

stateofjs.com

stateofcss.com

ES2019

  • Array.flat()
  • Object.formEntries()
  • Optional Catch Binding

フレームワーク

  • React
    • 使ってる人多いしそのほとんどがまた使いたいと言ってる
  • Vue
    • Reactよりは少ないけどのびてる
  • Svelte
    • 使ってる人は少ないけど学んでみたいという人は多い
  • Gatsby
    • 横ばい
  • Next.js
    • のびてる
  • ホスティングサービスも充実してきている
    • Netlify
    • Now
  • TypeScriptは60%くらいの人が使っている

WebAuthnで実現する安全・快適なログイン

  • Eiji Kitamuraさん

パスワードの問題点

  • Weak
  • Forgotten
  • Reused
  • Stolen

パスワードどうやって盗まれるか

ハックされる確率

  • キーロガーだと通常の40倍
  • フィッシングだと500倍
    • パスワード以外の情報もとられているケースが多いから
  • 被害の80%がフィッシング

パスワードが盗まれないようにする対策

  • 2段階認証
  • ワンタイムパスワード
    • SMS
    • フィッシングには弱い
    • 短時間有効なパスワードでもその場で送られたら意味がない
  • そこでWebAuthn

WebAuthn

  • これまでよりも強力なブラウザの認証
    • EdgeもFFも対応
    • Safariは部分的（でも時期に対応するだろう）
  • ハードウェアの鍵を使う(Authenticator)
  • 公開鍵暗号を活用した方式
  • Authenticatorにキーペアを作らせる
    • 公開鍵をサービスに送ってRegistrationする
  • 秘密鍵で署名をしてそれをサービスに送る
    • サービスは公開鍵で検証
    • 同じハードウェアを持っている人であると証明できる
  • 鍵はWebサイトのオリジンと紐付いて生成される
    • フィッシングに強い
    • たとえ盗んでも成功しない

二要素認証

  • ハードウェアをもっているという認証 + 記憶による認証
    • 多要素と多段階は違う
    • 記憶、所持、生体といった要素を複数組み合わせるのが多要素認証
  • セキュリティキー
    • PCに接続するとブラウザにポップアップ出る
    • ジェスチャーをすると署名を生成して送ってくれる
    • 名前をつけて登録する
      • キーをなくしてしまったら消せるように
    • SMS Codeも強いけどセキュリティキーの方が強固
  • 署名をサーバに送って登録されているものと同一であることを確認する
    • このサーバをFIDOサーバと呼ぶ

Authenticator

Roaming Authenticator

  • Authenticatorの1つにセキュリティキーがある
    • U2FかFIDO2に対応しているAuthenticatorであれば間違いない
  • R持ち運びできるからoaming Authenticatorと呼ばれる

Platform Authenticator

  • デバイスに埋まってるから専用のものを買わせる必要がない
  • 指紋認証などで使うことも多いけど端末のロックNoなども同等の扱い
  • Local User Verification(LUV)
    • ローカルで生体と所持の二要素認証する
    • スマホで生体認証とかするとこれが実現できる
    • 生体情報はデバイスにしかないから安心(だからLocal User Verification)
      • つまり新しいデバイスに替えたら再登録が必要

再認証(Re-authentication)

  • お金を払う手前とかで再度認証させるやつとか
    • ログインしてる状態でもう一度認証を求めるやつ
  • Pixel4の顔認証はまだ使えないけどChrome79から使える

参考

  • https:/goo.gle/FIDO
  • WebAuthnのコードラボもある

覚醒するアクセシビリティ

アクセシビリティ

  • 蔑ろにされることが多い
    • 不便と思う人を低く見積もりすぎ
    • 誰でも使えるようになることのよさを知らない
  • 障害者/健常者という区別がよくない
    • 環境や状況によって不便に感じることは誰でも起こりうる

Webにおけるアクセシビリティ

  • Webは世界中どこからでもアクセスできる
    • ブラウザの拡張などでカスタマイズできる

広義のアクセシビリティ

Wrap-up: High Performance JavaScript

  • Sho Miyamotoさん

intro

Layers

  • JavaScriptのレイヤー
    • Product
    • Runtime
      • Node
      • ブラウザ
      • Electron
    • Engine
  • JavaScriptの実装
    • サーバサイド
    • クライアントサイド

RuntimeとEngine

  • RuntimeとEngineどう違うか
    • Engine
      • parser/compile/execute
      • JIT/VM
    • Runtime
      • Engineが埋め込まれている
      • プラットフォームそれぞれのGlobalObjectを持っている
      • EventLoopをオーバーライドしてる

Optimization

  • 最適化
    • Product-level
      • memo化
      • キャッシュ
    • Runtime-level
      • 非同期
    • Engine-level
      • インラインキャッシュ
  • 効果
    • Product > Runtime > Engine
  • Micro Optimizationをするな
    • 自分でやらなくてもエンジンがやってくれる

Optimization

Server Side runtime

  • Node.js
  • イベントループ
    • 処理に時間のかかる動機処理があるとループをとめてしまう
    • 非同期でできるものはそうした方がよい
  • StreamAPI
    • Fileの読み出しとかを効率的に行える
    • Streamでないと情報を全てメモリにおいてそれを扱ってとなってしまって効率悪い

Client Side Runtime

  • ブラウザでJSが動くまで
    • fetch -> load -> parse -> compile -> execute
  • できるだけCodeCachingを使う
    • 次使う時にcompile済みになってるようにする
    • 頻繁に使われるものはServiceWorkerでcacheするといい
  • ESModules
    • ブラウザ上でimport/export
    • Preloading scripts
      • 実行はしないけどparseとcompileをしておいてくれる
  • idling
    • Idle Until Urgent
    • requestIdleCallbackを使うとCPUとかが暇な時に実行してくれる

Engine

  • V8
    • たくさん使われた処理ははやくとれるようにとか最適化してくれる
  • Inline Cache
    • Objectにどんな情報があるかを予め用意しておく？
    • ヒットしたらはやい

How to Boost Your Code with WebAssembly

  • FUJI Goroさん

WebAssemblyとは

  • ブラウザに搭載するバイトコードとその処理系仕様
  • JVMに近いけどランタイムはない

WebAssembly前夜

  • EmscriptenによってC/C++をJSにコンパイルすることができていた(2012)
    • ただし動作が非常に遅い
  • WebAssemblyに仕様議論開始(2015)
  • ブラウザにMVPレベルのサポート完了(2017)

WebAssemblyの価値

  • ブラウザにおいてはJSとできることは同じ
  • JSよりも速い
    • それが圧倒的価値
    • JSだと遅くて現実的でないことが可能になる
  • Cよりは数倍遅い
    • 安全性のために未定義動作(UB)をなくしてるから
    • この安全性が大きな利点

WebAssemblyのサポート状況

  • IE11以外は使える
    • 9割くらいのシェアのブラウザで使える

WebAssemblyの事例

  • eBayの事例
    • バーコードスキャナ

tech.ebayinc.com

言語ごとの速度イメージ

  • 1倍: C, C++, Rust
  • 3倍: Java, C#, Go, Swift
  • 5倍: JS(V8), Dart
  • 50倍: Ruby, Python, Perl, PHP
  • WebAssembly
    • WasmをV8で動かすと5倍の中では速い方

Streams APIをちゃんと理解する

  • 加藤 健志さん

StreamAPI

  • Readable Stream
  • Transform Stream
  • Writable Stream

Readable Stream

  • 読み込み可能なストリーム
  • データを分割して少しずつ読み込むことができる
  • fetchAPIのレスポンスのbodyは実はReadableStream

Writable Stream

  • 書込み可能なストリーム
  • pipeTo()を使うとReadableStreemのデータをそのままWritableStremに書き込める
  • 書き込み時にPromiseを返すと解決するまで待つので順序を保証できる
  • 分割されたデータを1つずつ順番に書き込むことができる

Transform Stream

  • 変換ストリーム
  • WritableStreamに書き込まれたデータをTransformStreamで変換してReadableStreamで読み込む
  • ReadableStreamからpipeThrough()でTransfirmStreamに渡してpipeTo()でWritableStreamに書き込める

バックプレッシャー

  • キューに空きがなくなったら通知して止めてもらう
  • Underlying Source
    • Push Source
      • 自発的にenqueueする
    • Pull Source
      • リクエストに応じてenqueueする
  • QueuingStrategy
    • highWaterMark
      • キャパシティを設定する
    • size(chunk)
      • 何をもってキューのサイズを決めるか

Streamsの今後

  • 5Gが来る
    • これまでボトルネックとされていたことが改善される

    • 大容量のファイルを配信できるようになる github.com

      - クライアントがボトルネックになる
    - Streamが役立つ！

Live Demo

「Mercari x Merpay Frontend Tech Talk vol.3」に参加してきました

勉強会メモ
  • Mercari x Merpay Frontend Tech Talk vol.3に参加してきました。

mercari.connpass.com

タイトル 発表者
Creating Serverless CMS from Scratch @sottar_
Vue.jsでのCSS設計 @tacamy
The Challenge of Web re-architecture using GraphQL and Apollo @lightnet328
Practical tips for making a global EC site @yayoc_

Creating Serverless CMS from Scratch

  • @sottar_さん

キャンペーンのページを作るまで

  • 従来のフロー
    • PMからどんなターゲットでどんあんことをしたいか伝えられる
    • デザイナーがコードを書く
    • フロントエンドエンジニアがレビューする
    • PMに返して問題なければリリース
  • 課題
    • デザイナーがコード角の大変(pug/css)
    • フロントエンドエンジニアがレビューするの大変
    • 一文字とか一部分変えるだけでもGitHubでフロー回さないといけない
  • キャンペーンページ作るのに時間かかる
    • 一ヶ月に1,2本くらいしか作れない

CMSを作った

  • コンポーネントを作ってCMS上で組み合わせるようなものがほしい
  • 必要なページ
    • キャンペーンの一覧ページ(過去に作ったものとか)
    • 編集ページ
  • なんでOSSを使わなかったか
  • 考えないといけないこと
    • 権限周り
    • セキュリティ
    • 履歴管理
    • プレビュー
    • => いろいろあるけどまずはMVPを作ってさわってもらう

アーキテクチャ

  • S3にCMSページの静的ファイルを配置
  • Cloud Storageにキャンペーンページを置いておいてそれをdynamic importして表示
  • GCPとAWS混ざってる
    • 基本はGCPを使ってる
    • 社内版GitHubPages的なものをS3で作ってる
  • 認証はAuth0

Vue.jsでのCSS設計

  • @tacamyさん

コンポーネント

  • 機能が自己完結する
  • 再利用できる
  • Vueではscopedをつけると擬似的にスコープをもたせることができる
    • ShadowDOMとは違う

Scoped CSSの留意点

コンポーネントの命名規則

ディレクトリ構成

  • assetsの中にscssに変数とかmixin
    • 実態はcomponentsの中
  • 階層が深くなりすぎないようにした方がよさそう
  • 細かすぎる分割はパフォーマンスにも影響
  • 最初はシンプルに作って規模に応じて変更していくと良さそう

The Challenge of Web re-architecture using GraphQL and Apollo

  • @lightnet328さん

メルカリWebにリアーキテクチャ

  • 新しい技術で作り直してる
    • TS
    • Next
    • React
    • Apollo
    • GraphQL
  • ページごとに部分的に公開している

GraphQLとApollo

  • なぜGraphQL
    • スキーマはドキュメントより実装と乖離するリスクが小さい
    • クエリの可読性高い
  • なぜApollo Clients
    • リモートデータの取得管理を任せたい
    • キャッシュによってリクエストが減る
  • なぜApollo Server
    • BFFとしての役割
      • スキーマをフロントエンドのために整理
      • ロギング
      • 認証
      • 将来的にgRPCでマイクロサービスに接続
      • クライアントが1つのエンドポイントだけ知ってればよい

Practical tips for making a global EC site

  • @yayoc_さん

UNIQLO Global EC

  • 特徴
    • 22カ国
    • O2Oもサポート
    • 機能が国によって異なる
  • これまで
    • 国ごとに異なるアプリ
    • クライアントヘビー
  • これらを解決させるプロジェクト
    • 1つのコードで複数の国対応
    • パフォーマンスはやく
    • a11y
    • コンシューマだけでなく管理画面のUXも改善
  • ページによってSSR
  • 国別にリダイレクトリライト

グローバルサイト構築

URL構造

  • /:country/:language
  • countryなかったらCDNの国
  • languageなかったらAccespt-Languageの言語

SEO

  • GoogleBot以外も考慮
  • JSレンダリングしてくれなかったのでHTML返した方が無難(SSR)

CMS

パフォーマンス

  • 毎日WebPAgeTest/Lighthouseを国別で実行
  • Performance Budget
    • total 200kb
    • chunk 80kb
  • webpack-bundle-analyzer
    • バンドルファイル内の内訳を可視化

ローカライゼーション

  • i18n- webpack-plugin
  • エントリーポイントを分けている
  • ルーティングベースでコードスプリッティングしてるから余計なのは入らない
  • 一部プレースホルダーで出し分け
    • 単数系/複数形とか
  • 決済フローなんかは国によって異なったりするのでコンポーネント出し分けてる
  • minificationで不要なものは削除される

a11y

  • ビジネスサイドからの要件も強い
  • Lighthouseでスコアとるだけでなくそれ以外の項目もチェック
    • 画像説明
    • CSSなしで動くか

画像

  • 一般的に画像が大きいほどコンバージョンは高い
  • CDNでWebPに変換してサイズ圧縮
  • プレースホルダーおいてリフロー防ぐ
  • 遅延ロード

BFF

  • マイクロサービスへのAPIリクエストを束ねる
    • クライアントヘビーな実装軽減
    • クライアントが扱いやすいような構造に整形
  • キャッシュ
    • max-ageを見て設定
  • ロギング
  • HMAC認証をサポート

「PWA Night vol.10 ～PWA × 技術～」に参加してきました

勉強会メモ
  • PWA Night vol.10 ～PWA × 技術～に参加してきました。

pwanight.connpass.com

タイトル 発表者
とある個人開発PWAのSEO奮戦記 大岡由佳さん
PWA×クラウドゲーミング おりばーさん
コードサイズの大きなプログラムのロード時間：WebAssemblyの場合 @chikoskiさん
うわさのJAMStackでPWAをさわってみた のまどまんさん
Monaca × PWA × 3D VMT-Yamashitaさん

とある個人開発PWAのSEO奮戦記

  • 大岡由佳さん(@oukayuka)

Mangarel

  • 個人でPWAなアプリを作った
  • Googleで検索しても3件しかひっかからない
    • 1万ページ以上存在してるのに
    • 最近のクローラーはJS解釈してくれるんじゃなかったのか・・
  • Problem
    • ページがインデックスされない
    • タイトルや詳細が個別に表示されない
    • コンテンツがレンダリングされない

ページがインデックスされない

  • サイトマップを作って送った
  • 正常に処理されましたと返ってきたけど
    • 認識はされるけどExclusionに入ってる
    • 内部リンクされてないのが原因？
  • ページを増やして内部リンクを増やした
    • 少しずつインデックスされるページが増えてきた！

タイトルや詳細が個別に表示されない

  • React HelmetでHTMLヘッダを上書き
    • ブラウザからは書き換わってるけどGoogle上では変わってない
  • CloudFunctionsで動的にヘッダを書き換えた
    • ボットからのアクセスの時だけ発動するように

コンテンツがレンダリングされない

  • SearchConsoleで試してみたらFirestoreからデータをとってくるはずがとってこれてない
    • ページによっては運がよければ表示される
    • レンダリングに時間がかかると諦めてるっぽい
  • Lighthouseで計測したらパフォーマンス50点台
  • TreeShakingした
    • ビルド時に不要なコードを削除
  • CodeSplitting
    • 初回のレンダリング時には必要なJSだけロードしそれ以外は遅延ロード
  • Lighthouse60点台
  • 無限スクロール

PWA×クラウドゲーミング

  • おりばーさん@Black Inc.(@oliver_diary)

クラウドゲーミング

OOParts

  • 開発してるクラウドゲーミング
  • ゲームをWebブラウザでアクセスするときの残念なところ
    • アドレスバーが邪魔
    • 余白がもったいない
    • アクセスするまでの導線が長い
    • => PWA化で解決！
  • 他にも
    • 起動時の初期表示が速い
    • アプリと違って審査いらない
  • PWAとクラウドゲーミングの相性抜群

コードサイズの大きなプログラムのロード時間：WebAssemblyの場合

  • @chikoskiさん

WebAssembly

WebAssemblyのいいところ

  • JSあるのになぜWebAssembly?
    • エコシステム
      • 他の言語の資産を使える
    • パフォーマンス
      • 速いけどそれだけじゃなくてブレが少なくて安定感が高い
  • 音声ファイルの扱い
    • ファイルサイズでかいので圧縮してmp3にして扱いたいとか
    • でもJSだけではできないのでWebAssemblyが役立つ

WebAssemblyの注意点

  • コンパイルするとjsとwasmが出力される
    • ファイルサイズがでかい
    • キャッシュを活用する
    • ネイティブのコードはブラウザにキャッシュされる
  • キャッシュにのったコードをいかに使い続けるか
    • 不必要なコードの変更をしない
      • ドメインとファイルを対応づけて保存されている
      • コンテンツが変わったら破棄されてしまう
    • URLを変更しない
      • クエリも変わらないように
    • ステータスコードを正しく返す
      • 200が返ると新しいコンテンツが来たと認識する
      • 変わってなければ304を返す
    • wasmのファイルを小さくしすぎない
      • 小さすぎるとキャッシュが破棄される(150kb以下くらい)
    • 最適化オプションをつける
    • システムライブラリをシェアする
    • application/wasmをつける
      • 全部のデータをダウンロードする前にある程度溜まったらコンパイルするという動きをしてくれる

うわさのJAMStackでPWAをさわってみた

  • のまどまんさん

JAMStack

  • 動的なデータコンテンツを取り扱う静的サイト
  • 事前に静的ページを生成しておく

JAMStack作ってみた

PWA化してみた

  • GatsbyにPWAのプラグインがある
  • キャッシュ使ったらパフォーマンス上がった
    • コンテンツがユーザ単位などで頻繁に変わる場合はキャッシュが活かしきれないかも

Monaca × PWA × 3D

  • VMT-Yamashitaさん

Monaca

  • ハイブリット開発環境
  • PWAのテンプレートがある

「LINE DEVELOPER DAY 2019 Day1」に参加してきました

勉強会メモ
  • LINE DEVELOPER DAY 2019に参加してきました。

linedevday.linecorp.com

  • セッションの資料はこちらに随時公開されるとのこと

speakerdeck.com

  • 今回はDay1の午後だけ参加してきました
  • 以下セッションのメモです

Inside of Blog; 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦

  • 大森 貴博さん

livedoor Blog

  • 構成
    • LAMP
    • 30近くのサブシステム
  • 15年での蓄積
    • Developper
      • 70+
    • サーバ
      • 750+
      • 200がDB
    • DBテーブル数
      • 550+
    • ファイル数
      • 43500+
    • プログラムファイル数
    • コードの行数
      • 410000+
  • 今動いているブロジェクト

カオスとレガシー

ドキュメントがない

  • セットアップ方法がわからない
  • デプロイ方法がわからない
  • 普段触ってないサブシステムだと特に

開発サーバがない

  • 誰からも忘れられていて安定して動いたサブシステム
    • それに手を入れようとしたら環境がない
  • 開発サーバはあるか?
  • 正常に動いているか？
  • 本番との差分がないか？
  • 本番のデータを使っていないか？

テストがない

DNSレコードが多すぎる

  • 300レコード以上
    • ユーザが設定してる独自ドメインとかは入ってない
    • 調査したら230が不要だった
    • 古い機能とか過去のキャンペーンでの残骸
    • 整理して削除するだけで数ヶ月

機能が多すぎる

  • 目に見えるもの見えないものたくさん削除してる

Perl

  • Perlのバージョンがとても古い
    • 5.6(2002年)
    • ローンチしてから変えてない
  • 新しいバージョンのPerlも一部使ってる
    • バージョンが混在している
    • 環境など全て2倍必要

MySQL

  • MySQLのバージョンが古すぎる
    • 4.0(2003年)
    • ローンチしてから変えてない
  • 4.0でできないこと
    • Online DDL
    • Fast Index Creation
    • Trigger
    • => オンラインでalter tableできない
      • テーブルコピーしてデータ移行して、、と無理やり頑張った(数ヶ月かかる)
      • データが2倍だからディスク容量が逼迫
  • バージョンを上げないのか？
    • サーバマイグレーションのタイミングで考えた
    • ブログの特殊な事情と時間的制約で断念
      • 1つのテーブルに複数文字コードが混ざってる
      • そのせいで正攻法でのバージョンアップができない

LINE BLOG

  • LINEとの連携が強い
  • 2014年リリース
  • 2016年リニューアル
    • 一般公開
    • 独立したサービスに
      • livedoor Blogをフォークした
      • livedoor Blogのカオスとレガシーも引き継いだ
      • => LINEのエンジニアが本気出して数々の問題を解決

Next 15 Yeras

  • 15年後を考えて開発していくことが大切
  • 小さなことからでも始めること
    • コメント一行書くだけでも
    • 不要なファイルを削除しておくだけでも

LINE NEWSの記事配信を支える技術

  • 稲葉 大樹さん

LINE News

  • 2013年開始
  • 2017年からLINEのタブに加わった
  • ニュース以外に運行情報や地震速報なども
  • 月間680万ユーザ
  • インフラ
    • Amon2(Perl) 44台
    • Spring Boot(Java) 30台
  • DB

Personalized Recommendation

  • 多大な記事数ユーザ数をもとに記事をレコメンドしている
  • ML + Manual(運営の手動)
  • 表示対象かつ表示期間中のものがユーザに表示される

MLによるレコメンド

  • 社内のMLチームで生成されたものをもとにレコメンド
    • 1億人超えのデータが入っている
    • ユーザ一人に付き200件の記事を選んでる

手動によるレコメンド

  • 運営チームがCMS上で設定
  • 属性に応じてどの記事を表示するか選ぶ
    • どの媒体をフォローしてるかとかも属性として選べる

MLのレコメンドだけを使っていた時代

  • CDNを活用して記事を取得していた

    • レコメンドを取り入れると属性が必要なのでCDN活用できなくなった

  • ユーザからの記事取得リクエストの流れ

    • Redisにレコメンドした記事を事前に入れておく
    • ユーザから記事取得のリクエストが来るとRedisから取得する
    • 取得した記事をキャッシュに保存しておく
    • 次からはキャッシュにあればそこから、なければMySQLから取得する

ML + Manualでレコメンドしていた時代

  • Central Dogma
    • jsonとかyamlの設定ファイルを管理する
    • 変更をwatchすることができる
  • Datalakeから対象ユーザのIDを取得してCMSにアップロード
  • 記事IDとユーザのマッピングをRedisにあげる
  • Central Dogmaに記事の情報をあげる
  • 課題
    • 記事とユーザのマッピングデータの形式の影響でスケーラビリティがない
    • パフォーマンス

今後

  • 今はユーザからのレスポンスが反映されるまで1時間かかったる
    • リアルタイムに反映させたい
    • 今ABテストで一部のユーザに適用
  • レコメンド適用範囲の拡大
    • ダイジェストは今全員同じものを出してる

コミュニケーションアプリ「LINE」の機能改善を支えるデータサイエンス

  • 高口 太朗さん

LINE App Improvement Project

  • Uesrs First
  • Data Driven
  • Diverse Team
  • In-houes Developmemt

データサイエンスチーム

  • Data Science And Engineering Center
    • Data Labs
      • Data Science Team
  • Data Science Team
    • LIENマンガ
    • LINEトップ
    • LINE Pay
    • LINE ad

プロジェクトのサイクル

  • ユーザリサーチ -> 計画 -> 開発 -> テスト -> フィードバック -> 計画 -> ...

ユーザリサーチ

  • Focused Interview
  • Online Suvey
  • Dashboard Monitoring
  • 定量と定性を組み合わせる

計画/開発

  • 計画
    • どうデータではかれば良いか考える
  • 開発
    • どのようなログを集めればよいか定義など

テスト/フィードバック

  • テスト
    • オンラインでのABテスト
    • 2018~で20回以上者ABテストをやってきてる

LINEアプリ改善の取り組み

  • LINEアプリならでは
    • ユーザが多い
    • 使い方もさまざま
  • LINEアプリを評価する単独のKPIが存在しない
    • メッセンジャーは無料の機能
    • すでに多くのユーザを獲得してるからユーザ数xx増加とかもやりづらい
  • LINEのコアバリュー
    • LINEのミッション
      • Closing the Distance
    • メッセンジャーアプリにあてはめると
      • 身近な友達と簡単にやりとりできること
    • そのために改善すべき機能を考える
  • 友達ネットワークを分析
    • 社会的なネットワークが反映されている
    • グループ機能の改善がターゲットに

グループ機能の改善

  • ユーザリサーチ
    • グループ作成の手順がわかりづらい
    • 当初
      • グループ名やアイコン決めてからメンバー選択
      • 急にグループ名聞かれても困るのでは
  • 計画
    • グループ名選択よりも前にメンバー選択を持ってくる
  • ABテスト
    • 入れ替えてもグループ作成成功率は変わらなかった
  • フィードバック
    • どこに目をつけるか
      • 成功したユーザに着目?
      • 失敗したユーザに着目?
      • 時間帯に着目?
      • 地域に着目?
    • グループ名アイコンを選ぶ画面まで進んでない人が多い
      • スムーズにメンバーを選べていない
      • テスト期間中に複数回失敗したユーザ30%程度
  • 計画
    • 最近トークした友達を上に持ってくる
    • グループ名アイコンとメンバー選択を一画面で
  • ABテスト
    • 2種類×2の4通りテスト
      • 比較のパターンが多いので偶然の差異を拾ってしまう可能性がある
      • 組み合わせの一つを諦めて3パターンを検証
  • フィードバック
    • 大きな差はでなかった
    • グループ作成までにかかる時間が短くなってれば成功なのでは？
      • 最近トークした友達を上に持ってくると短縮されていた
    • 1画面にした結果はネガティブ
      • メンバー1人でグループ作成が増えた
      • メンバー2人以上だけをみると作成成功率低下
    • 2画面のままで最近トークした友達を上に持っていくのを採用

データサイエンスツール

  • 分析の環境とツールによってこれらの改善は支えられている
  • ABテストするためには
    • 必要なサンプルサイズの選定
    • テストユーザ選定
      • LIBRA
    • モニタリングダッシュボード
      • LIBRA REPORT
        • GitHubを通じて集計に必要なクエリを登録
        • ブラウザベースのダッシュボードに出力してくれる
      • R Shiny
        • より高頻度でチェックしたい
    • テスト結果のレポート

XXE、SSRF、安全でないデシリアライゼーション入門

  • 徳丸浩さん

XXE

  • XML外部実体参照
  • 外部実体参照
    • XMLはentityを定義して参照することができる
  • 攻撃の例
    • SYSTEM /etc/hostsとか指定すると内容がとれてしまう
    • URLを指定するとその内容が読み込まれてXMLに展開される
      • SSRF(Server Side Request Forgery)
  • 原因
    • XMLのもともと保つ機能
  • 対策
    • XMLを使わずJSONを使う
    • XMLを使わなければいけない場合はどうする？
      • Javaの場合DTD(Document Type Definition)を禁止する
      • PHPだと外部実体参照を停止する設定になっている
      • RailsではREXMLを使う
        • nokogiriだとNOENTオプションを設定しない

SSRF

  • Server Side Request Forgery
  • 攻撃イメージ
    • 直接アクセス不可の内部サーバがある
    • 公開サーバを通して内部サーバにアクセスを許可している
    • 公開サーバを踏み台にして内部サーバにアクセスすること
  • 攻撃の例
    • プレビュー機能でのSSRF攻撃
    • http://169.254.169.254にアクセスするとEC2のインスタンス情報をとれる
    • このURLをプレビューするとSecretAccessKeyなどとれてしまう
    • EC2インスタンスを踏み台にしてクレデンシャルな情報にアクセスできてしまう
  • 原因
  • 事例
    • Capital Oneの例はSSRFだった
    • WAFの設定ミスによるもの
    • HostヘッダにEC2インスタンスを指定することによる攻撃
    • WAFの権限がS3へのアクセスなど広く与えられすぎていた
  • 対策
    • ホスト名がIPアドレスであることをチェックするだけではダメ
      • リダイレクトされてしまうなどさまざまなケースが有る
    • ネットワーク的にチェックする
      • 許可されたURLかどうかチェックする

安全でないデシリアライゼーション

  • シリアライズ
    • バイト列に変換してオブジェクトに格納できるようにする
  • 外部から来たシリアライズデータをデシリアライズするとどんなオブジェクトでも作れてしまう
    • メソッドをいじったりとかはできない
      • プロパティを工夫するといろいろできてしまう
  • 対策
    • シリアライズ形式でなくJSONを使う
    • クッキーやhiddenパラメータではなくセッション変数を使う

LINEのメッセージングプラットフォームにおけるマイクロサービス化への長い道のり

  • 井出 真広さん

LINE Messaging Platform

  • 2011年ローンチ当初はモノリシックだった
    • talk-server/redis/msql
    • 1つのチーム/1つのサーバでうまくいっていた
    • どんな機能を追加していくか同じ方向を向いてできていた
  • 追加したい機能がたくさん増えてきてチーム全体で調整する必要がでてきた
    • 速度を持って進められなくなってきた
    • チームを分割してサービスを分けるようにしていった
    • チーム単位でそれぞれコントロールできるようになった
    • スタンプ/メッセージング/認証/...
  • 現在は多くのサービスが連携し合いながら動いている
    • チームごとにやりたいことにフォーカスしながら開発している
  • マイクロサービス化して
    • よかったこと
      • コンフリクトが少なくなった
    • よくなかったこと
      • ネットワークレイテンシ
      • 障害

マイクロサービスを構築するためのツール

  • Coneectivity
  • Directory Service
  • Routing

Coneectivity

  • Armeria
  • 非同期なRPC/RESTライブラリ
  • Java/Netty/HTTP2
  • ロギングや分散トレーシングの仕組み
  • 障害を伝播させないためのサーキットブレーカーの仕組み

Directory Service

  • Central Dogma
  • サービス間で設定を共有したい
  • 通信先のサービスがどこにあるのか把握したい
  • どのホストが度のサービスを配信しているか
  • gitをバックエンドとしたバージョン管理の仕組み
    • どの時点でどの設定だったか管理

Routing

事例

  • スタンプが普及してきた
  • 1ユーザで万単位で持っている人もでてきた
  • スタンプを購入するたびにRedisにスタンプの所有情報を再構築していた
    • その時にスロークエリが発生して一瞬talk-serverが止まる
    • talk-serverにはいろんな場所からリクエストがくる
    • メッセージングプラットフォーム全体の障害となりかねない
  • どこかが一瞬とまるようなことがあっても波及しない構成に再構築
    • サーキットブレーカーなどの仕組みをいれる
    • レイテンシを悪化させないように
    • スケール

「Android Dev Summit 2019 Extended Tokyo #gdgtokyo」に参加してきました

勉強会メモ
  • Android Dev Summit 2019 Extended Tokyo #gdgtokyoに参加してきました。

gdg-tokyo.connpass.com

  • 普段Anrdoidの開発をしているわけではありませんが、新しい機能を知ることができて便利な機能がたくさん登場してきていることを実感できました。
タイトル 発表者
【Session1】Conference Overview & Keynote Session mhidaka
【Session2】Android Studio 4.0 最新アップデート Daichi Furiya / Wasabeef
【Session3】かんたんべんりなMotionEditorの使い方講座 mochico
【Session4】What's new in CameraX Takasy
【Session5】Jetpack Composeの解説です！ Yuki Anzai
【Session6】Jetpack Roomの最新情報が届きます！ Yuichi Araki

【Session1】Conference Overview & Keynote Session

  • mhidakaさん

概要

  • 10/23-24
  • 700人
  • 60セッション

キーワード

  • Modern Development
    • 素早く簡単に
  • Modern distribution channel
    • PlayStoreの強化
  • Modern OS
    • OSのリリース戦略

Keynote

  • Androidはユーザと開発者をつなぐプラットフォーム

Modern Development

  • Innovation
    • 利用シーンの拡大
  • Updatability
    • 柔軟な機能アップデート
    • Android10からAPKだけでなくAPEXに対応
    • APKだとなかなかアップデートしてくれない
    • APEXだと動的に自動でアップデート(ユーザの同意が必要)
  • Secirity & Privacy
    • Popup Block
  • Developer Experience
    • PlayStoreのTop1000のうち60%がKotlin
    • 開発者の53%がKotlinを使用(母数は何？)

Modern OS

  • Android11からα,βといった提供になる
    • 今まではstable1,2,finalみたいな感じだった
  • targetSDKは1つ前までしか認めなくなる
    • どんどん上げていかないといけなくなる

【Session2】Android Studio 4.0 最新アップデート

  • Daichi Furiyaさん

Desugaring in D8 & R8

  • 新たにいろいろなパッケージ、クラスがサポートされた

Multi Preview

  • さまざまな解像度のデバイスでプレビューできる
  • 各国の言語設定でもプレビューできる

Build Speed

  • ビルドのどこにどれくらい時間かかってるか可視化できるようになった

Google Maps Emulator Integration

  • Google Mapsのナビゲーションをシミュレートできるようになたｔ

Proguard Editing

  • コード補完の精度向上
    • クラス名とかきかなかったけど補完されるようになった

Live Layout Inspector

  • エミュレータで動作しているものを3Dで要素の階層とか見られる
    • 要素をクリックするとプロパティが表示されたり
  • Experimentalなので設定をonにしないと使えない

Emulator embedded inside the IDE

【Session3】かんたんべんりなMotionEditorの使い方講座

  • mochicoさん

Motion Editor

  • Motion Layoutを使ってアニメーション
  • Motion Layout
    • ConstraintLaayoutのサブクラス
    • motionをXMLで定義できる

Modern Editorの使い方

  • 要件
    • Android Studio4.0+
    • ConstraintLaayout2.0.0beta3+
  • エディター上でアニメーションのstartとendを設定できる
    • 動かすとアニメーションしてくれる
  • keyframesでもっといろいろ設定できる

【Session4】What's new in CameraX

  • Takasyさん

Camera2 API

  • 高度な機能の実装ができる
  • でも細かなことができるせいで使いづらい
  • 様々なデバイスで動くものを作るのが大変

CameraX 3

  • Camera2をラップしたもの
  • 新機能を追加するときデバイス固有のものを使わないようにしてる
  • 2億台のactiveなデバイスでテストしてるから様々な機種で動く

CameraXのユースケース

  • プレビュー
  • 画像解析
  • 画像キャプチャ
  • CameraViewが簡単に使えて便利

新しいAPI

  • Tap to focus
  • Pinch to zoom
  • Zoom Slider

【Session5】Jetpack Composeの解説です！

Jetpack Compose

  • AndroidのUIを作るためのモダンなツールキット
  • 既存のコードと混ぜて使える(予定)

Jetpack Composeはやりたいこと

  • シンプルにしたい
    • UIを作るのにたくさんコード書かないといけない場面がある
    • フレームワークからはさわれるけど3rdパーティからはさわれないとかいう場面がある
    • Material + AnimationなUIを作りたい
  • Single Source of Truethにしたい
    • CheckBoxの状態とModekの状態どっちが正しいの？ってなっている
  • ReactiveなUIにしたい
    • Modelで状態を管理し変更されたら再描画
  • UIパーツの再利用性高めたい
    • 従来はカスタムViewあるけど作るの大変
    • 小さなcomponentを組み合わせてUIを作っていく

Jetpack Composeの今後

  • まだ開発中
    • 本番で使うな危険
  • 来年betaが出る(来年のいつだかは不明)

【Session6】Jetpack Roomの最新情報が届きます！

  • Yuichi Arakiさん

Jetpack Room

  • N対Nにも対応するようになった
  • デフォルト値設定できるようになった
  • Incremental Build
    • Buildがはやくなる
  • Expand Projection
    • select文の結果で一部のカラムしか必要ない時に対応できるようになった
    • 空気を呼んで全カラム返さなくなる

「LINE API × Tech API Vol. 1 Powered by AWS」に参加してきました

勉強会メモ
  • LINE API × Tech API Vol. 1 Powered by AWSに参加してきました。

linedev.connpass.com

後半のハンズオンではLINE botを作成してバックエンドにAWSを使いました。 コピペ部分も多かったですが、初めてCloud9を使ったりLINE botを作ったりいい経験になりました。

タイトル 発表者
What and Why AWS Serverless Satoshi Suzuki
サーバーレスだからこそフロント実装もカジュアルに！LINE APIでAWS上でアプリを作ろう！ 比企 宏之
LINE APIとAWSを使ったハンズオン Satoshi Suzuki

What and Why AWS Serverless

  • Satoshi Suzukiさん(AWS)

トレンドのワード

  • microservices/serverless
  • それぞれ2014年くらいから伸びている

サーバーレスとは

現場のニーズ

  • Business Personの気持ち
    • 早くリリースしたい
    • 新機能ほしい
    • スタートアップ時にインフラコスト抑えたい
  • Developerの気持ち
    • インフラ管理したくない
    • ビジネススケールしたときにサービススケールさせるの大変
  • ビジネスロジックに集中したい
    • => サーバーレス

サーバーレスの特徴

  • インフラのプロビジョニング管理が不要
    • マシンの事前調達不要
  • 自動でスケール
  • 価値に対する支払い
    • 実行した分だけ払う課金体系
  • 高可用かつ安全
    • メンテナンスや定期的なダウンタイムはない

AWSのサービス

  • 処理
    • Lambda
  • 外部I/F
  • 認証
    • Cognito
  • ストリーム
  • データ保持管理
    • DynamoDB
    • RDS
    • Aurora
    • SQS
    • S3

Amazon API Gateway

  • インターフェースの抽象化
  • HTTPのエンドポイントを作れる
  • リクエストを受け付けてどこにパスするか設定できる
  • 作成可能なAPIの種類
    • REST
    • WebSocket
  • メトリクスも確認できる

AWS Lambda

  • リソース管理
  • リトライ
  • ログ出力
    • Cloud Watch Logsに書き出してチェックできる
  • いろんなイベントをトリガーに実行できる
    • API呼び出し
    • データの変更
    • ファイルの配置
  • 処理対象
    • 自由に処理を書ける
    • DBアクセス
    • ファイル出力
  • 負荷に応じて柔軟にスケール

Amazon Simple Que Service

  • メッセージングキューをハンドリングするサービス
  • 標準キュー
    • 少なくとも1回は配信
  • FIFOキュー
    • 順序保証と1回限りの配信

Amazon Simple Storage Service

  • オブジェクトストレージ
  • 安価なストレージサービス

サーバーレスだからこそフロント実装もカジュアルに！LINE APIでAWS上でアプリを作ろう！

  • 比企 宏之さん(LINE)

ITシステムの運用コスト

  • 運用と保守で75%

LINEのフレームワーク

  • LIFF(LINE Frontend Framework)
    • LINE内で動くWebアプリのプラットフォーム
    • HTML/JSで書ける
    • バックエンドAWSつないだりとかも自由にできる
    • LINEは8200万人のユーザがすでにインストールしてくれている

LINE Things

  • IoTアプリ

「FRONTEND CONFERENCE 2019」に参加してきました

勉強会メモ
  • FRONTEND CONFERENCE 2019に参加してきました。

2019.kfug.jp

タイムテーブル

11:00〜

タイトル 発表者
モダンJavaScript再入門 尾上 洋介
デザイン・設計の体幹とスキル 山下 一樹
PWAとCache API 田口 航

11:45〜

タイトル 発表者
ディレクトリ構成ベストプラクティス 〜 Angularアプリを作り続けてわかったこと okunokentaro
事例からみるアプリデザインの成長戦略とWeb Native Platform 榊原 昌彦
JavaScript も jQuery も未経験の新人エンジニアが 1 年間 Vue.js を学習して感じた話 川又由雅

13:00〜

タイトル 発表者
Adobe XDで作るマイクロインタラクション 松下 絵梨
UIデザイナが実装できる良さ コンチ
レガシーなフロントエンドをリプレイスする 小島大基

13:45〜

タイトル 発表者
2019年のUIパフォーマンス キリル ワシルツォフ
Nuxt.js + Firebaseでの開発と高速化に挑んだ話 カンボ@沖縄(鈴木孝之)

14:30〜

タイトル 発表者
AWSを活用したフロントエンド開発 前田 圭介
高齢者でも使えるプロダクトUIの挑戦 神保嘉秀

15:15〜

タイトル 発表者
私たちはなぜ SPA で開発するのか 花谷拓磨(@potato4d)
プロダクト開発とFigmaのより良い関係を求めて 大木尊紀
React Hooksで<video>を乗りこなす 浜田 真成

16:00〜

タイトル 発表者
フロントエンドエンジニアのためのセキュリティ対策 平野 昌士
Flutter For Webを用いて居酒屋で使えそうなゲームを作ってみた備忘録 大西 優司
Web 制作現場のディレクションを支える GitHub 後藤知宏

モダンJavaScript再入門

  • 尾上 洋介さん

なぜJS

  • 本格的なSPAが作れる
  • モダンなツールやフレームワークを学ぶのにJSの知識が必要なものが多い
  • ツールが移り変わっても通用する技術

基本的なオブジェクト

  • 数値/文字列/配列/オブジェクト

変数の宣言

  • const/let
    • 基本はconst
    • 再代入必要な時だけlet
    • varは使わない

アロー関数

  • 関数は第一級オブジェクト
    • 変数に入れたり関数へ渡したりできる

非同期処理

  • asyncをつけた関数内ではawaitが使える
  • awaitつけるとPromiseが解決されるまで待ってくれる

レガシーなフロントエンドをリプレイスする

  • 小島大基さん

レガシーとは

  • 古い
  • 代替すべき新しいシステムがある
  • フロントエンドにおいて
    • 新しい技術がすぐに入ってくる

アーキテクチャ

  • UIとロジックのディレクトリ(ファイル)を分ける
    • UIライブラリが変わっても使い回せる状態に
  • コンポーネントはなるべくステートレスに

テスト

苦労したところ

  • ライブラリのバージョン上げたらテストが通らなくなった
    • BootstrapVue 1.5 -> 2
  • class style apiが非推奨になってしまった

Nuxt.js + Firebaseでの開発と高速化に挑んだ話

  • カンボ@沖縄(鈴木孝之)さん

なぜFirebase

  • RDSも使ってる
    • FirebaseはChatの部分だけ
  • 使っているサービス
    • Firebase Authentication
    • Cloud Firestore
    • CloudFunction

チャット機能をFirebaseで

  • 候補
    • WebSocket
    • ロングポーリング
    • Firebase
      • Firebaseに決定
      • 導入コスト低くてメンテコストも低い
      • 採用のウリになりそう
  • 導入前の懸念
    • DBの無料枠1GB
    • 検索条件に制限

Firebase導入してどうだったか

  • Firestoreの構成
    • usersコレクション
    • roomsコレクション
    • usersのサブコレクションにrooms
      • 深い層への検索がやりづらそうだったから
  • CloudFunctionの初期起動遅い
    • 一定時間アクセスがないとスリープモードになる

ビルド高速化

  • Webpack Bundle Analyzer
    • webpackの処理で遅いloaderやpluginが分かる
    • bundleしたファイルがどのライブラリがどれくらい占めてるか分かる
  • バンドルサイズ
    • Chart.jsが重い
    • memoment.jsが重い
      • 不要なlocaleも入ってて重い
    • lodashが重い
      • ほとんど使ってないから消そうとした
      • 関数単位でimportするやり方があったからそれにした

AWSを活用したフロントエンド開発

  • 前田 圭介さん

AWS

  • 使ってるサービス
    • S3
      • ストレージ
    • Cognito
      • 認証サービス
  • 今後よさそう
    • AppSync
      • GraphQLでやりとりする
      • リアルタイムデータアクセス
      • オフラインのデータ同期

導入編

  • AWS Amplify
  • amplify initで雛形生成できる
    • Auth.signin()でCognito Signin
    • GraphQLのqueryを生成したりもできる
  • amplify pushでデプロイできる

まとめ

  • Amplifyで簡単に認証からAPI作成・実行Storage利用ができる

私たちはなぜ SPA で開発するのか

  • 花谷拓磨(@potato4d)さん

なぜSPAを選定するのか

  • User Experiences(UX)
    • 要件を満たすための選ぶ場面
  • Developer Experiences(DX)
    • 開発効率を上げて生産性を上げる
    • エンジニアを確保するために新しい技術を使う

UX要件の強い事例

  • InstagramがPWA/SPAで提供している
    • 新興国での利用など考慮してWebで提供
    • twitterも同じようなことしてる
  • ページ遷移にアニメーションをつけたりリッチにしたいけど各ページでURLは持ちたい

DX要件の強い事例

  • コーポレートサイトをSPAで作成
    • コンテンツのアップデートを簡単にやりたいからSPAを選択

SPAの技術をどこまで使うか

  • SPAに付随してくる技術はすべて必要？
    • たとえばReduxとか
  • 要件ごとに検討していく必要がある
    • 常にバランスが大事

間違った技術選定

フロントエンドエンジニアのためのセキュリティ対策

  • 平野 昌士さん

Webのセキュリティ動向

  • IPAが出している脆弱性届出受付数
    • Webがソフトウェアの倍以上
    • XSSが半分を占めている
  • 脆弱性の多くはWebサイトでXSSが多い

脆弱性(XSS)の仕組みと対策

XSS

被害例
XSSの種類
主な対策
  • 特殊文字のエスケープ
    • & -> &amp;とか
  • 危険な文字列の削除
    • javascript:alert()とか入ってたら消すとか
    • 自前でやれなくもないけど大変
      • OSSなどを活用しましょう
      • 例えばReactはデフォルトでいろいろやってくれる
      • DOMPurify
  • ブラウザの機能を使う
    • Content Security Policy
      • HTTPレスポンスヘッダーに入れる
      • <meta>でも指定できる
    • Content-Security-Policy-Report-Only
      • レポートをとれるから本番適用前に確認すると良い
    • nonce
      • metaタグで設定したnonce値と同じ値が設定されたscriptタグしか実行できないようにする
      • nonceはリクエストの都度変える必要があり推測困難なランダムな値にする
    • Trusted Types
      • URLの文字列を安全な型に検証して扱う
      • まだexperimentalな機能
        • chromeはflag立てれば動く
        • Polyfillもある

セキュリティへの意識

  • 脆弱性とは悪用できるバグ by 徳丸先生
  • セキュリティに関しても
    • 要件定義でfixする
    • セキュリティテストする
  • どうやってチェックする?

「#webauthn_study」に参加してきました

勉強会メモ

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

web-study.connpass.com

タイトル 発表者
WebAuthN を入れるには何を考えるべきか @ritou (mixi)
WebAuthN を実際に入れてみてどうだったか @kasecato (nulab)

WebAuthN を入れるには何を考えるべきか

  • @ritouさん(mixi)

リカバリーの話

  • 無効化/再設定
    • パスワード
    • TOTP
    • リカバリーコード
    • Auhtenticator
  • 別の認証方式or複数登録

パスワード認証におけるリカバリー

  • 忘れた
    • 別の認証方式 + 再設定

SMS通知におけるリカバリー

  • 番号/アドレスが変わった
    • 別の認証方式 + 無効化/再設定

FIDOにおけるリカバリー

  • 紛失盗難
    • 別の認証方式 or 複数登録可能にして無効化/再設定
  • FIDOだからといってそんなに問題ではない

導入事例

  • Google, GitHub
    • パスワード認証との組み合わせ
    • 2段階認証

2段階認証としての導入

導入時にどこに手を入れるか

  • アカウント設定
    • 追加認証を有効にする
    • リカバリー設定
      • 別の認証方式を登録
  • 認証
    • パスワード認証 + 追加認証を要求するように
    • 複数ある場合はどの方式か切り替えられるように
  • 再認証
    • GitHubではパスワード確認の場面でWebAuthnが利用可能に

検討事項

  • リカバリーの認証方式でカスタマーサポートの負担が決まる
  • 利用可能な環境の制限
    • user-agentによる判別
    • platform
    • Attestation
  • 追加認証要求のタイミング
    • パスワード認証に成功したら
    • パスワード認証の結果に関わらず
    • パスワード認証前に

パスワードレス認証としての導入

  • パスワードレスとは？
    • パスワードを使わない
      • 所持 or 生体 or 記憶
    • FIDO UV相当
      • 所持 + (記憶 or 生体)
  • 新規登録
    • リカバリーを考慮して効率的に2種類の認証方式を設定するには?

WebAuthN を実際に入れてみてどうだったか

  • @kasecatoさん(nulab)

WebAuthN導入前の話

WebAuthN導入のモチベーション

  • セキュリティキーや顔認証でログインしたい
  • 社内ハッカソンで作ってみた
  • しかし当時は仕様変更が続いていて不安
  • 今では2019/3にW3C仕様勧告

WebAuthN導入中

認証フローの設計

  • 2要素認証
    • 利便性の改善にはつながらない
  • 単要素パスワードレス認証
    • 多要素を強制したいフローで困る
  • 多要素パスワードレス認証 - 採用
    • 利便性と安全性を両立
  • ユーザネームレス認証
    • windows10以外で普及したと思えなかった
  • Email First Sign-in Flowを参考に実装

アカウントリカバリの設計

  • 盗難紛失
    • 従来のパスワード認証でログインし認証器の無効化
  • パスワードを削除したユーザ
    • リセットのEメールを送信

実装が困難だった点

  • macのtouchID複数登録の後勝ち問題
  • アカウント新規作成でパスワードレス

WebAuthN導入後

サポートへの問い合わせ

  • 指紋が変わって生体認証使えなくなったらどうすればいいか
    • PINで認証器解除して再登録をしてもらう

パスワード削除でモバイルから使えない

  • パスワード削除したらパスワードでログインしてるものを全部サインアウト
  • モバイルはFIDO対応してないからパスワード再発行しないといけない

Touch IDが使えなくなった

  • 公開鍵クレデンシャル登録時のChromeのProfileに紐づく

使用可能な認証器がわからない

  • いろんな認証器がある
  • これ使えますか？と問い合わせがくる

「ServerlessDays Tokyo 2019」に参加してきました

勉強会メモ
  • ServerlessDays Tokyo 2019に参加してきました。

tokyo.serverlessdays.io

  • 事例紹介のセッションではかなり踏み込んだ設計の話をしてくれることが多く参考になることが多かったです！
タイトル 発表者
10x Serverless Product Development for a Startup with Microsoft Azure Yutaka Tachibana(EBILAB)
Keynote Keisuke Nishitani (AWS)
Keynote: Infinite Scaling, Finite Failures: Serverless Resiliency Patterns and Lessons Learned Katy Shimizu (Microsoft)
グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例 Yuya Urayama (TOYOTA), Takanori Suzuki (Acroquest Technology) and Eiichiro Uchiumi (AWS)
All You Need Is JavaScript Jensen Hussey / Cloudflare
Zero Scale Abstraction in Knative Serving Tsubasa Nagasawa (CyberAgent)
空調設備向けIoTシステムにおけるクラウドランニングコスト 野原 健太 / ダイキン工業株式会社
ISPがサーバレスに手を出した 伊藤良哉 & 松田丈司 (NTTコミュニケーションズ)
AWS Lake Formation で実現、マイクロサービスのサーバーレスな分散トレーシング 江藤武司 & 岩井良和 (Sony Corporation)
Don’t think Serverless Security, think Application Security Ido Neeman (Nuweba)
Azure でサーバーレス、 Infrastructure as Code どうしてますか？ Kazumi Ohira
The hidden cost and technical debt of running huge Serverless service on production James Nguyen / MaaS Global

10x Serverless Product Development for a Startup with Microsoft Azure

  • Yutaka Tachibana(EBILAB)

スタートアップ × Microsoft Azure

EBILAB

開発しているもの

  • BIツール
    • どれくらいの人が来客するか予測
  • 画像解析
    • 入店客の人数や属性をカウント
    • 通行人数もカウント

Microsoft Azureのサーバーレスコンポーネント

  • Functionse
    • DBにデータを入れるところまで
    • LogicApp
  • PwoerBI
    • エクセルのデータをもとに表示することもできる
    • DBとかAPIから取得したJSON
  • WebApp
    • Nuxt
    • Laravelで認証
    • PwoerBIで作ったレポートをiframeで呼び出し

サーバーレスで作ったメリット

  • 開発運用コストが従来のモノリシックより少ない
  • 責務分離が自然と行われる
  • 将来的にスケールしても問題ないと楽観視できる
  • 不要になったパーツを捨てやすい
  • 分業協業しやすい

Keynote

  • Keisuke Nishitani (AWS)

Event Driven

  • LambdaはサーバーレスよりもEvent Drivenをキーワードにしたサービスだった
  • 状態の変化をイベントとして捉えて処理を実行する
  • Event Driven出ない場合処理が増えると呼び出し元にも手を入れないといけない
  • Event Drivenならサブスクライブを追加するだけ

Lambda

  • 2014年に発表
  • 当初はEvent Drivenや関数実行がキーワードだった
  • 2015年にAPI Gatewayが出てきてサーバーレスという言われ方をし始めた

Lambdaのネットワーキング

  • Lambdaの実行環境ははサービスチームのVPCで動いている
  • ユーザのVPCにElastic network interfaceを通じて接続できる
  • スケールするとサブネット内のIPアドレスを使っていく
  • ENIの作成に10~30秒時間がかかる

AWS Hyperplane

  • internal network load balancing service
  • 内部的に動いてるサービス
  • ユーザは使えない

VPC環境の改善

  • AWS HyperplaneをベースにしたVPC to VPC NATを使う
    • コールドスタートレイテンシの改善
    • ネットワークインターフェースの共有
    • スケーリング
  • LambdaからRDSへの接続
    • VPCのコールドスタート問題が解決する

モダンアプリケーション

  • 特徴
  • アプリケーション実行環境
    • EC2
    • ECS/EKS/Fargate
    • Lambda
  • マイクロサービス
    • サービスごとにデータを永続化するので疎結合
  • APIはマイクロサービスの玄関
  • メッセージングを活用してコードからステートを取り除く
  • クラウドネイティブなアーキテクチャ

Keynote: Infinite Scaling, Finite Failures: Serverless Resiliency Patterns and Lessons Learned

サーバーレス

  • サーバの抽象化
  • イベント駆動型
  • 従量制課金

すべての依存は障害になりうる

  • レースコンディション
  • ネットワーク障害
  • レート制限
  • ハードウェア障害
  • => 再試行のデザインパターン

グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例

  • Yuya Urayama (TOYOTA)
  • Takanori Suzuki (Acroquest Technology)
  • Eiichiro Uchiumi (AWS)

はじめての大規模アジャイル

トヨタのコネクティッドサービス

  • 車載デバイスがネットワークに繋がる
  • 車のヘルスチェックがスマホでわかる
  • 盗難の検知追跡エンジンの再始動停止

サーバーレス

  • 日中と夜でアクセス数の差が顕著
    • 通勤や業務で車に乗る人が多い
    • サーバーレスなら不必要にリソースを確保しなくていい
  • ライフサイクルが長い
    • 買い換えるまで7〜8年
  • コネクティッドカー国ごとにまだ法規制が違う
    • 国ごとにプラットフォームを確保
    • サーバーレスならシェアの大きい地域と小さい地域に合わたサイズにできる
  • データは蓄積せずにリアルタイムで流している

アーキテクチャ

指針

  • 十分にシンプルな粒度
  • ライフサイクルが異なるコンポーネントを自立
  • プロセスをステートレスに

アーキテクチャスタイル

  • Nティアー
    • 役割に応じていくつかの層に分割
    • Gateway
    • Logic
    • Data
  • ウェブキュー/イベントドリブン
  • マイクロサービス
    • ライフサイクルを共有できる単位のまとまり
  • 車載デバイスと地域サービスをつなぐプラットフォーム

AWSのサービス

開発の課題

クラウドで動かさないといけないのでテストしづらい

  • CI/CDでテスト実行環境整備
  • サービス単体テスト
    • LocalStack
    • プロキシで向き先無理やり変えてテストしてる
  • サービス間連携テスト
    • Karate

全体のトレーシングが難しい

  • ログはCloudWatchに
  • 想定以上にコストが高くなるから注意
  • X-Rayで分散トレーシング

自動スケール便利だが問題になるケースも

  • Lambda失敗して再試行するようにしてた
    • 再処理のLambdaが数千実行されてしまった
    • 同時実行数の上限はアカウント単位
    • 他のLambdaの起動を妨げる危険性
    • 変に上限までいかないように関数ごとに設定する

All You Need Is JavaScript

  • Jensen Hussey / Cloudflare

Cloudflare

  • 世界中にデータセンターがある
  • ユーザに近いデータセンターでJavaScriptを実行することができる

なぜJavaScript

  • 一番使われている言語だから
  • サーバーサイド
    • Node
  • モバイル
    • ReactNative
  • ネイティブ
    • Electron
  • サーバーレス
    • Cloudflare Workers

Cloudflare Workers

  • ServiceWorkerをベースに考えられたもの
  • v8で実行される
  • WebAssemblyにも対応している

Zero Scale Abstraction in Knative Serving

Knative

  • Build
    • 卒業してなくなった
    • Tektonになった
  • Serving
  • Eventing

Knative Serving

  • HTTPリクエスト駆動でスケールする
  • 素のk8sを使うとyamlをたくさん書かないといけない
    • Knative使うと簡単になる
  • Kanative Serviceを書いていく

事例

  • なぜKnative？
    • k8sを抽象化できるから
      • ネットワークのレイヤーも含めて抽象化
    • yaml地獄から脱却
    • ゼロスケールできること
      • パフォーマンス < 可用性 のサービス
    • Dual Stack
      • knativeとk8sのリソース併用
    • Portability
  • イベントを受けて処理をするところだけzero scalingを使う
  • Eventingはまだ未成熟だから採用見送り

空調設備向けIoTシステムにおけるクラウドランニングコスト

ダイキン工業とIoT

システム規模

  • 各機器から毎分データ発生
    • 膨大なアクセス
    • 高い処理性能とスケーラビリティ
    • 無限に発生するデータを扱えるストレージ
  • スモールスタート
    • 徐々に接続する機器を増やしていく
  • => サーバーレスでNoSQLで

サーバーレス開発

  • サーバーレス開発はクラウドランニングコストとの戦い
    • 目標のランニングコスト以内で動くシステムを作れるかどうか
    • IoTのように負荷が高いシステムだと従量課金でもコストは嵩む
    • サービスごとの課金体系を把握し設計する

システム構成

空調機 -> AWS

  • 変化のあった項目を毎分送るようにした

アプリ -> AWS

  • 一度のコールで同時に複数機器のデータを取得
  • 毎分データを取り出す

ランニングコスト

  • コストのかかる部分
    • Dynamoへの書き込みでのWCUコスト
    • データ取得時のLambdaの処理時間
  • DynamoDBのデータ構造が肝になる

DynamoDBのデータ構造

  • 数十kmの項目があると一部だけ更新する場合もWCUを消費してしまう
  • 運転データごとにアイテムをわける
    • 1機器Nアイテムとしてデータを持つ
  • Lambdaからアクセス時に機器数×N個分アクセスしないといけない
    • Partition Keyを建物IDとして建物ごとにまとめて取得できるようにした

まとめ

  • 今回の要件は書き込みは少しずつ、読み込みはまとめて
  • 要件にあった構成にすることでコストを削減できる
  • DynamoDBは書き込みのほうが読み込みより10倍課金額が高い

ISPがサーバレスに手を出した

ISP

  • Internet Service Privider
  • 家 - 回線 - ISP - インターネット

サーバーレスどこで使ってるか

  • 通信する前にルールを取得する必要がある
    • そのAPIをサーバーレスで作ってる

サーバーレス以外の選択肢

  • 選択肢
    • 物理サーバ
    • 自社IaaSサービス
    • 他社IaaSサービス
  • 納期3ヶ月
    • サーバーレスじゃなきゃ無理

社内基準と通信事業としての基準

  • 社内クラウドを使わない理由
    • IPv6対応してなかった
  • 信頼性の担保
  • 100万ユーザついているサービスが1時間止まると総務省に報告しないといけない

IPv6の受難

リリース後

テストの自動化

  • 全般
    • ローカルで軽量に行えること
    • デプロイして行うテストは最小限に

ローカルでテスト

  • Serverless Frameworkとプロアグ員を駆使
    • serverless-offline
    • serverless-dynamodb-local

負荷試験/長時間試験

  • Gatlingで叩いてる
    • レポートが見やすい
  • テストをやって・・・
    • DynamoDBのaute-scaling忘れに気がつくことができた

CIパイプライン

  • GitLab CI/CD
    • ローカルでしか動かないということがないように
    • dockerコンテナで実行することで環境が汚れない
    • commitとテスト結果をバインドすることで証跡を残せる
  • serverless-offlineのテストとかをCIで動かしてる

Infra as Code

  • Serverless Frameworkとにかく便利
    • ローカルでのテスト
    • 本番へのデプロイ
  • Azureは対応してるのが多くない
  • AWSもすべてをコード化できるわけではない
    • sls deployのあとにaws-cli使ってるところもある
  • 構成変更
    • 移行後の構成をsls deploy
    • 切り替えて古い方をsls remove

AWS Lake Formation で実現、マイクロサービスのサーバーレスな分散トレーシング

背景

  • aiboやMultifunctional Lightなどのバックエンドをサーバーレスで作ってる
  • マイクロサービス構成
  • 呼び出しチェーンが長い
  • 非同期も多い
  • クロスアカウントやオンプレとの連携も
  • 1ヶ月立ってから問い合わせや障害のトレースをすることがある

分散トレーシング

  • 分散アーキテクチャの処理の可視化や追跡性を向上させるための仕組み
    • どのサービスをどういう経路でたどったか
    • どこにどれくらい時間がかかったか
  • 共通のIDを受け渡していって経路を特定できるようにする

Lake Formation

  • 複数のAWSアカウントにまたがったログを集約分析できる
  • サーバーレスで実現できる
  • リアルタイムな分析はDataDogで長期的に残しておくのはLakeFormation

トレーシング基盤の構成

  • Step Functionsでログの出力
  • Lake Formationで各アカウントからログを集約

トレーシングIDの取得と伝播

  • X-Rayだけでは非同期イベントのトレースが困難
  • それぞれ工夫して対応した

Don’t think Serverless Security, think Application Security

  • Ido Neeman (Nuweba)

サーバーレスは新しい攻撃の窓口になりうる

  • イベント駆動アーキテクチャはサーバーレスに限った話ではない
  • むしろサーバーレスの方がセキュアな場面もある

サーバーレスはマネージしにくい

  • 小さい単位の関数にすることで管理しやすくなる

サーバーレスで過剰なアクセスがきたらどうするか

  • スケールするのが仇となって大量の課金につながる
  • 関数ごとに制限を設定しておく

サーバーレスの実行権限が広くなりすぎないか

  • IAMの権限を最小限にしぼっておくこと

Azure でサーバーレス、 Infrastructure as Code どうしてますか？

  • Kazumi Ohira

Infrastructure as Code

  • インフラのリソース構成/管理をコードで行うこと
  • メリット
    • 自動化できる
    • ミスが減る
    • レビューしやすい
    • バージョン管理できる

クラウドにおけるリソース管理

  • IaaS
    • Terraform
    • AWS Cloud formation
  • Container
  • Serverless

AzureでIaC

  • ARM templateを使う
    • 冪等性を管理してくれる
    • エラーハンドリングしてくれる
    • 差分デプロイ並列デプロイできる

The hidden cost and technical debt of running huge Serverless service on production

  • James Nguyen / MaaS Global

クラウドサービスを使うこと

  • クラウドベンダーに預けてるデータが壊れたら？
    • 最近もAWSの大規模障害があった
  • 技術的制約
    • Lambdaで最新のNodeが使えるようになるまで3ヶ月くらいかかる
    • 最新の情報を入手してアップデートし続けないといけない
      • 知らないところでAPIが廃止されてしまわないように
    • よりよいサービスに置き換わっていくこともある
      • 状況に合わせて移行していく必要がある
  • ベンダーロックイン
    • マルチベンダーは簡単ではない
    • Serverless Frameworkで抽象化はできる

「GitHub Actions Meetup Tokyo β」に参加してきました

勉強会メモ
  • GitHub Actions Meetup Tokyo βに参加してきました。

gaugt.connpass.com

タイトル 発表者
新GitHub Actions のはじめかた @miyajan
GitHub Actionsで WebDriverどこまでやるの？ @hiroshitoda
GitHub Actions Parallel Testing @yasuhiroki
GitHub Actionsと(主にreviewdogを使った)Automated Code Review @haya14busa
他のCIサービスと比較してできることできないこと @Kesin
Github Actions でハマった点と解決方法 @kawasin73
自作Github actions入門 @Naturalclar

新 GitHub Actions のはじめかた

  • @miyajanさん

GitHubActionsをはじめるとき

既存のワークフローを探す時

アクションを作る時

既存のアクションを探す時

予想外の挙動で困った時

GitHub Actionsで WebDriverどこまでやるの？

  • @hiroshitodaさん

GitHubActionsが動く基盤

GitHubActionsで最初から使えるソフトウェア

Appiumの利用とNested Virtualizationの壁

  • Androidエミュレータを動かせるのはmacOSだけ
    • Linux/Windows環境がNestedVirtualizationに対応してないから
  • 公開Dockerイメージを使える
    • AppiumでもDocker使っていい感じにしたい
    • NestedVirtualization問題
    • やるならmacOSで
    • budtmo/docker-android
      • 5~6GB
      • 2分くらいでpullできる
    • bitriseio/docker-android
      • 26~27GB
      • キャッシュできない環境では実用に耐えない

GitHub Actions Parallel Testing

  • @yasuhirokiさん

並列テスト

複数のテストを分割して並列に実行したい

  • matrixを使うとできる
    • 自分でコードもちょっと書かないといけない
  • CircleCIは実行時間が均されるように自動で振り分けてくれる
    • knapsackを使うといい感じにできる

テスト結果を集計したい

  • artifactを使う
    • それぞれのノードで見えるディレクトリにファイルをアップロード
    • それらをダウンロードして集計する

Tips

GitHub Actions と (主に reviewdog を使った) Automated Code Review

  • @haya14busaさん

GITHUB_TOKEN

  • secret.GITHUB_TOKENを明示的に指定したときだけ使える
    • forkしたリポジトリからはちゃんと見えないようになってる
  • リポジトリにインストールされたGitHub Appのアクセストークン

Check API

  • コードにコメントをつけられる
  • Review APIより使いやすい
  • reviewdog

他のCIサービスと比較してできることできないこと

  • @Kesinさん

ビルドキャッシュとアーティファクト

マトリックスビルド

  • nodeの複数バージョンでJobを実行といったことができる

マトリックスビルドとconainter

  • マトリックスで指定したイメージ上でテストが実行できる
  • actions/setup-xxxを使わなくてもよくなる

Github Actionsでハマった点と解決方法

  • @kawasin73さん

プライベートリポジトリ

  • プライベートリポのインストールが難しい

3rd Party Action信頼できない

  • 大もとはGitHubリポジトリ
    • 差し替えられても気づけない
  • フォークして使いましょう
    • 中身を確認して使う

git cloneに失敗する

  • サーバ鍵の検証を諦めて無視した
  • GitHubないからGitHubのリポジトリにアクセスするので中間者攻撃はないだろう

セマンティクスバージョニングがない

  • v0.1はv0.1.0にならない
  • Actionsのバージョンはタグとの完全一致

自作Github actions入門

  • @Naturalclarさん

actions-toolkit

github.com

  • @actions/core
  • @actions/exec
  • @actions/io
  • @actions/github
  • @actions/tool-cache

「CROSS Party 2019」に参加してきました

勉強会メモ
  • CROSS Party 2019に参加してきました。

2019.cross-party.com

業務ハック 〜業務効率化にコミットする職人達の世界〜

  • 野秋 拓也さん(DMM.com)
  • 廣氏 宣勇さん(DMM.com)
  • 廣野 美里さん(freee)
  • 髙木 咲希さん(SonicGarden)

業務ハック

  • 業務改善をエンジニアリング行うこと

事例

  • Slackで相手の名前とか入れると参加者の開いてる予定検索して提示してくれる
  • 受託開発で業務ハック
  • slackとかgsuiteと使うようになって業務ハックしやすくなっている
  • 全部自分でゴリゴリに作るとかはそんなない
    • いろんなサービスを組み合わせて解決させる
  • kintone
  • Zpier

[基調講演] 夢を形にする技術 〜 大規模開発におけるサイエンスとエンジニアリングの境界を科学する

はやぶさプロジェクト

  • 無人探査機によるサンプルリターンミッション

ユーザ要求

  • IT
    • 自分たちもユーザ
    • 自分たちが使いたいもの
  • 探査プロジェクト
    • イノベーションは技術が主導して立ち上げるもの
    • 顧客は今しかみてないからそのニーズに答えるだけでは発展しない

技術の継承

  • IT
    • 多くのシステムが負債化している
      • 古い技術が動いているからといって放置されている
      • 開発できるエンジニアを持っていなくて委託しているからノウハウのある人がどこにいるかわからない
      • 人材の流動が激しいと数年でいなくなることを想定して作れる
    • ペアプロ、モブプロ
  • 探査プロジェクト
    • 親方と弟子の関係
    • コーチングして技能は得られるが使えるものは得られない
    • 自ら獲得しないといけない
    • はやぶさとはやぶさ2の間は10年以上
    • 若いうちからプロジェクトに参加して見せていきたい

チームビルディング

  • IT
    • 同じ方向を向ける中で多様性を持つことが重要
    • 根本から違う方向向いてしまうのは採用ミス
    • 考え方の違う人を入れてしまうよりも才能をある人を貶してしまう方がましというくらい
    • ローコンテキストを前提にビジョンを共する有
  • 探査プロジェクト
    • 向いているところに向いている人を配置する

緊急企画！漫画村再検証！

漫画村

  • 海賊版サイト
  • 政府がサイトのブロッキングを実施
  • 4つの闇
    • 法解釈の闇
    • 法改正の闇
    • 報道の闇
    • 広告の闇

海賊版サイト対策検討会議はなぜ紛糾したのか

事務局による進行の問題

  • 「著作権侵害のブロッキングは世界42過酷で導入されているだから日本もやるべき」
    • 2001年にEUが司令を出してEU各国で法制化
    • 法制化されているが実施したことある国は半分くらいしかない
    • EUで28カ国が法制化17年間実績なしの国が15カ国

被害額3000億円

  • 漫画村の被害額が3000億円という試算は本当か
  • 年間コミック市場は4000億前後
  • 総アクセス数に単価をかけたのが3000億円
    • アクセスが有った分全部売り上げた前提

Coinhive事件/WizardBible事件にみる不正指令電磁的記録に関する罪

法が問題としていること

  • 意図に沿うべき動作をさせず不正な司令を与える電磁的記録

事件

  • Coinhive事件
    • 自分のページにWebブラウザにマイニングさせるJSを貼った
  • WizardBible事件
    • リモートシェルを埋め込み
  • アラートループ
    • アラートを閉じてもアラートが出続ける

この状況が続くと

  • サイバーセキュリティ分野の活動が衰退する懸念
  • 海外に優秀な人材が(今以上に)流出

フロントエンドエンジニアがこの先さらに生き残るには

  • mizchiさん(plaid)
  • lacoさん
  • 奥野賢太郎さん(クレスウェア)

働き方のスタイル

  • フリーランスになった
    • もともとのつながりで仕事を得られた
  • 週1日副業
    • サラリーマン感なくなった
  • フリーランス時代の仕事
    • フロントエンドは管理画面の需要が高い
    • エクセル再実装

フロントエンドエンジニアの尖り方

日本人がOSSにあまり貢献していない

  • 一部貢献している人がいてもスター扱いしてそれで終わってる
  • OSSは大企業が作るものに集約されてきていってる
  • バグバウンティの方がまだある
  • 翻訳のコントリビューションする人はけっこういる
  • GitHubのトレンドに日本人作者のライブラリがのることがほとんどない
    • 最近だとhiroppyさんのfusuma
    • 中国勢が強い

フロントエンドのカバーする領域

  • フロントエンドがサーバーサイドに入り込むようになってきた
    • Next.js, Nuxt.js
    • BFF
    • FaaS
  • フロントエンドの大事なところはフロントエンドであることユーザに最初に触れるところ
    • パフォーマンス
    • デザイン
    • UX
    • その反対側にデータを堅牢にする役割の人も必要
  • SPAを作るのが大変だった時代から当たり前に作れる時代になった
    • 注力できる範囲が広がってきてカバーできる領域が増えてきた

フロントエンドのDeveloperExperience

  • webpackのビルド時間が長すぎて改善の妨げになっていたり

次にくるものは

  • 数年前にReactの仮想DOMに魂が震えた
  • 次はWebWorker
    • off the main thread
    • メインスレッドの奪い合い

Rust

  • 今のWebをRustで書くことは今はなさそう
    • ライフタイムとかフロントエンドとは違った難しさ
    • ゲームとか作るのにはいいかもしれないけどメインでやることはなさそう
  • メインスレッドに登場してくることはなさそう
    • workerで動かす処理を書くとかはありそう
    • Backend in Frontend

フロントエンドの技術選定

  • TypeScriptは大前提
  • フレームワークを使うかどうかから
    • ampを使うとか
  • 複雑にならないからと思っても作り変えるときは絶対来る
  • バックボーンの成り立ちや考え方を気にしてもいいかも

「Meguro.css #7 @ ラクスル」に参加してきました

勉強会メモ
  • Meguro.css #7 @ ラクスルに参加してきました。

megurocss.connpass.com

  • 初めて知った記法や、普段当たり前に書いている変数名やライブラリへの問題提起など、学びがとても多かったです。
  • 次回もまた参加したいです！
タイトル 発表者
react-nativeにおける、Styleとの向き合いかた Naturalclar
Design Tokensを考える前に俺たちは変数名について考え直すことがあるのではないか yamanoku
詳細度調整擬似クラス ShoEzawa
Chrome 78 Betaで試すCSS Properties and Values API あらや
Stylelintの取扱説明書 moro
Sassに頼らないCSS設計 takanorip

react-nativeにおける、Styleとの向き合いかた

  • Naturalclarさん

React Native

  • Reactライクな書き方でiOS/Androidアプリが作れる

React NativeのStyle

  • WebではないからCSSではないけど同じような感じで書ける
  • CSS in JSで書くことになる

React NativeとWebの差

  • Displayは基本flex
  • flexDirectionのデフォルトがColumn
  • marginなどのショートハンドが使えない
    • marginVerticleなど独自のものもある

Design Tokensを考える前に俺たちは変数名について考え直すことがあるのではないか

  • yamanokuさん

デザインシステム

  • 一貫性が保たれたUIUXを提供できるもの

Design Tokens

  • デザインシステムにおけるスタイル変数集
    • CSS variables
    • SASSの変数とか
    • json読み込んだりとか
  • 色の変数名にwhiteとかつけるのはどうなのか
    • Atlassianのデザインシステムはカラー名が色の名前に準拠してない
  • 変数名が教養があるかどうかになるのも何か違う

詳細度調整擬似クラス

  • ShoEzawaさん

詳細度調整擬似クラスとは

  • :where()
  • 引数として与えたセレクタを詳細度の計算で無視する

使い所

  • !importantと同様詳細度に鑑賞するので乱用は危険そう？
  • ちゃんと使えば便利になりそう
  • 擬似クラスや属性セレクタを使うと詳細度が高くなりがちなので使えそう
  • 用途を限定して使うとよさそう

Chrome 78 Betaで試すCSS Properties and Values API

  • あらやさん

CSS Properties and Values APIとは

  • CSSのCustom Propertiesを構造化するためのAPI
  • CSSのCustom Propertyに初期値とsyntax(型のようなもの)を指定できる
  • Chrome78から使える

API

  • window.CSS.registerProperty
  • syntaxにnumberとかcolorとか設定できる
  • 一度定義すると再registerできない
  • syntaxに一致しない値を設定するとErrorがでる
window.CSS.registerProperty({
  name: '--property-name',  // 対象のcustom propertyの名前
  syntax: '*',              // 値をどうパースするか
  inherits: true,           // 親要素の値を継承するか
  initialValue: '',         // 初期値
});

Stylelintの取扱説明書

  • moroさん

Stylelintとは

  • cssの潜在的なエラーの事前検知や一貫性を保てる

Stylelintの使い方

  • stylelintをinstall
    • npm i -D stylelint
  • configを作成
  • 公式が提供するlintルール
    • stylelint-config-standard

上手な使い方

  • メッセージをカスタマイズできる
  • huskyとlit-staged
    • commitやpush前にタスクを走らせてそこでlintチェックする
    • 必ずlintがかかるようにできる

Sassに頼らないCSS設計

  • takanoripさん

Sass

  • 便利だけど機能が多すぎる
  • 便利だけど注意が必要な機能もある
  • Sassの機能を使うことが目的になってませんか

上書きをなくす

  • 詳細度で値を上書く
    • 詳細度との戦いが始まるのでよくない
  • 過度な共通化をしてると起こりやすい

Custom properties

  • CSSの変数のようなもの
  • 標準のCSSで使える
:root {
  --primary-color: ##ff0000
}
.hoge {
  color: var(--primary-color)
}
  • 色や大きさなど定義しておくことで統一したstyleにできる
  • 上書くだけではないのでよい

ScopedなCSS

フラットなCSS

  • ネストが深いと検索しづらくて開発効率が落ちる
  • 詳細度との戦い
  • Sassはネスト使えちゃうので使っちゃう

「JSUG勉強会 2019その9 Spring＆AWS」に参加してきました

勉強会メモ
  • JSUG勉強会 2019その9 Spring＆AWSに参加してきました。

jsug.doorkeeper.jp

  • Springの勉強会ですが個人的にECSの話をきけたのがとても勉強になって嬉しかったです。
タイトル 発表者
Spring BootをKotlinで作成し Amazon Elastic Container Service (ECS) で稼働させる話 白山 文彦 (Fumihiko Shiroyama)
AWSで作るクラウドネイティブアプリケーションの基本とDevOps 川畑 光平 (APN AWS Top Engineers & Ambassadors)

Spring BootをKotlinで作成し Amazon Elastic Container Service (ECS) で稼働させる話

  • 白山 文彦 (Fumihiko Shiroyama)

Kotlin

  • いわゆるAlt Java
  • 完結で強力な記法
  • Null安全
    • 型の時点でnullが入りうるかわかる
    • 自然な形で具象型にできる
  • JetBrains製

Spring with Kotlin

  • Spring Initializr
  • Docker化
    • 簡単に捨てられる開発環境
    • ステートレスなアーキテクチャの強制
    • 本番運用を見据えられる
  • DBもDocker化
  • AWSにデプロイ

Spring on AWS

Amazon Aurora

  • 自動でスケールする(RDSでは昔はできなかった)
  • マルチリージョン
  • 1つのライターと複数のリーダ
  • 書き込みエンドポイントと読み込みエンドポイントが違う
  • ローカルからでもアクセスできる

Amazon ECS

概要
  • Dockerコンテナを簡単にデプロイ管理するためのサービス
  • コントロールプレーンはECS or EKS
  • データプレーンはEC2 or Fargate
    • Fargateは中を意識しないで簡単に使える
    • EC2は自分で好きなようにできる
  • Fargateを使うとリソースを意識する必要ない
使い方
登場人物
  • タスク
    • Dockerコンテナ
    • タスク定義から作る
  • サービス
    • タスクを複数束ねる
    • 「APIサーバ」や「HTTPサーバ」のような役割の単位
  • クラスタ
    • 複数のサービスを束ねる

まとめ

  • ローカルから段階的にDocker化することで簡単にECS化できた
  • Fargeteは簡単にコンテナを扱える
  • CI/CDツールと連携するとECSの作成やデプロイを自動化できる

AWSで作るクラウドネイティブアプリケーションの基本とDevOps

  • 川畑 光平 (APN AWS Top Engineers & Ambassadors)

AWSで作るクラウドネイティブアプリケーションの基本

news.mynavi.jp

「Serverless Meetup Tokyo #14」に参加してきました

勉強会メモ
  • Serverless Meetup Tokyo #14に参加してきました。

serverless.connpass.com

タイトル 発表者
機械学習MVPにServerless Frameworkがオススメな理由 池田 雄太郎（株式会社 KaizenPlatform）
今Serverlessが面白いわけ（v19.09） 川崎 庸市（Microsoft Corporation）
AWSで開発するサーバレスAPIバックエンド 三宅 暁（フリーランス）
F-SecureのServerlessなSecurity 河野 真一郎（エフセキュア株式会社）

機械学習MVPにServerless Frameworkがオススメな理由

  • 池田 雄太郎（株式会社 KaizenPlatform）

ML/DLプロダクト開発におけるストレス

コンピューティングリソースの短期的ダイナミクス

  • 学習などで一時的に大量リソースほしい
    • => 柔軟なスケールイン/スケールアウト機構が必要

コンピューティングリソースの長期的ダイナミクス

  • ビジネス的な成長予測ができないのでどれくらい使われるかわからない
    • => インフラに関する高い知識が求められる

Serverless

  • リクエストに応じて必要なだけのリソースをリアルタイムに確保する
    • リソース確保が柔軟
  • ML/DLプロダクト開発と相性がいい

Serverless導入の悩み

  • 設定/デプロイに関するデメリット
    • 使うBaaSが多くなり勝ち
      • AWSとかいろんなサービスがある
    • DevOps環境構築のハードルが高い
      • ロジックの実装はJupyterNotebookが多め
  • そこでServerless Framework

Serverless Framework

  • Serverlessアプリの構成管理ツール
  • CloudFormationの定義したリソースをLambdaを中心に一括で設定できる
  • ステージング環境の分割など簡単にできる

今Serverlessが面白いわけ（v19.09）

世の中の動向

  • 人類の問題
    • アジリティがほしい
    • 高い生産性効率性がほしい
    • 運用コストを下げたい
  • ビジネスの傾向

FaaSを支える技術

  • インフラ技術の進化の賜物
  • 一般的にコンテナ相当の技術が基盤に使われる
    • 使った分だけ課金
    • 高速にスケーリング
  • データストアの進化
    • ステートフル/データ永続化対応
    • スケーラブルなデータストア
    • NoSQL型がフィット
  • プラットフォームの進化の方向性
    • 自動化
    • 抽象化
    • 標準化
  • Serverlessにおけるクラウドベンダーの実情
  • Knative
  • KEDA
  • Virtual Kubelet

AWSで開発するサーバレスAPIバックエンド

ノーコーディングでバックエンドAPIを作る

  • Amplifyは使わない
    • ベンダーロックインしないように
    • Apollo Clientを使う
  • Cognitoは使うがOpenID Providerとして使う
    • react-oidc-contextを使う
  • serverless-appsync-plugine
    • AppSyncの設定を完結に定義してデプロイできるServerlessFrameworkのプラグイン

F-SecureのServerlessなSecurity

Serverlessでセキュリティ

  • インフラは提供者が担保
  • エンドユーザがアップロードしてきたファイルは安全か?
    • アップロード時にF-Secureと連携してセキュリティチェックしてくれる
    • API連携でセキュリティチェックができる