「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のナビゲーションをシミュレートできるようになたt

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 APIAWS上でアプリを作ろう!

  • 比企 宏之さん(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で抽象化はできる