Serverless Meetup Tokyo #3 レポート #serverlesstokyo

臼田佳祐

2017.07.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

Serverless Meetup Tokyo #3が開催されましたのでレポート致します。

セッションレポート

Serverless x IoT = “IoT scale” backend 松井基勝(SORACOM)

SORACOMはIoTの課題を解決するためにSIMを出した
新しくI,Jにかかるサービスも発表している
ユーザグループもやっているので参加しよう！

IoT

IoTスケールの膨大な数をどうやってさばくのか？その要件は？
- PoC段階ではスモールスタートが重要
- デバイスが増えても同じアーキテクチャで動作する
- 世界中どこでも同じ仕組みが使える
- 社会インフラとなるので対象外性やセキュリティも考慮する必要がある
つまり、オンプレという選択肢はない
- 上記と要件と反する
レガシークラウド(IaaS + RDBMS)
- スモールスタートは可能
- ほかも頑張れば代替可能
- しかし、RDBMSはスケール難しい
サーバレス構成
- クラウドのメリットはそのまま享受
- コストメリットも有利
- 同じ構成を保ったままキャパシティを上げる、並列度を上げていくことでスケールしやすい
IoTでServerlessを適用できる場所
- FaaSとして
  - イベント処理
  - ETL
- NoOps的な意味
  - データのストリーム
  - ストレージやDB
  - ビッグデータ解析
IoTからクラウドを使うには
- データの受信
- データの加工
- データの保存
- データの分析
- データの活用
モノがクラウドに直結したら
- クラウドの計算リソースを使える
- クラウドへの接続が簡単かつ安全に使える
SORACOMのサービスが利用できる
- Beam
  - 汎用プロトコル向けデータ転送支援
  - HTTPなどをHTTPSにする
  - 無線通信はコストが高いが安全なので非暗号化でも大丈夫
  - クラウドから先インターネットへ抜けるときにSORACOMでSSL化する
- CDN as a Service
  - AWS Lambda@EdgeでスケーラブルなIoTバックエンド構築みたいにやりたい
  - まだLambda@Edgeで利用はできない
  - fastlyで対応可能
  - ログをjsonやCSVにしてQueryStringのパラメータを入れてS3へ保存
  - 分析ツールで可視化
  - 実装が楽
- Funnel
  - Partner Hosted Adapter
    - 様々なサービスに簡単に接続できる
  - IoT-scale BigDataパターン
    - Funnelから各クラウドのパイプラインへ流す
Funnelもサーバレスで作られている
- Lambdaのdeployment
  - 基本的にapexを利用している
  - 開発はmacで本番はLinux
    - native buildが必要なモジュールを使うと辛い
  - 複数のアカウント感で環境を分けた運用が辛い
    - マルチクラウド対応の独自拡張を入れたラッパーを作成した
  - でもVPC lambdaのsubnet指定とか辛い
- Kinesis + Lambda構成のチューニング
  - Kinesis Streamのシャード分割
    - 処理レコード数とデータ量を考慮
    - シャードが増えるとLambdaの並列度が上がる
  - Lambda内の処理の高速化
    - とにかく並列処理出来るところはする
    - 再利用可能なオブジェクトはハンドラーの外へ
    - メモリ足りててもメモリ割り当てを上げるとCPUの処理能力も上がる
    - トラフィックがネックになっている場合には上がらないので注意

まとめ

オンプレはつらみしかないのでIoTではServerlessを活用しよう！

感想

Serverless開発のつらみあるあるなお話でした！

全般的な開発につながる部分があると思いますので、参考にしたいですね。

オンプレはつらみしかない！

Serverless in Azure 佐藤直生 (Microsoft)

まずはAzure Functionsを試してみよう
- https://functions.azure.com/tryから利用できる
- 簡単に始められるUI
- ログインもSNSアカウントで簡単に出来る
オンプレミスからIaaS,PaaSを経由してServerlessと環境は変化している
- Serverlessにより作りたいものに集中出来るようになっている
- マイクロサービス化している
Azure のプラットフォーム
- Functions以外にもLogic appsがある
- 視覚的なデザイン
- 100+の様々なコネクターを利用できる
Azure Functionsを詳しく
- みんなが作るのはCode とFunctions
- Codeでは入力、処理、出力を定義する
- 実際の入力物などはfunctionsで指定する
- Usage
  - Brown field
  - Green field
  - IoT
Logic Appsを詳しく
- ワークフローエンジン
- Microsoft FlowをAzureで使えるようなイメージ
  - Microsoft Flowではマイクロソフトアカウントで様々なサービスと繋がれる
  - SAP, Salesforce等
  - 同じように様々なサービスと連携できる
  - 連携できるサービス
何が出来る？
- スケジューリング出来る
  - 例: AccuWeather
- Azure service event processing
- Serverless Mobile back ends
  - webhookから保存とリサイズのフローを定義する等
  - それぞれの処理を非同期に簡単に連携することが出来る
- single page applications
- リアルタイムストリーム
Serverless Design PatternsをAzureではどう実装するか
Azure Functionsは基本ステートレス
Functionsの新しい機能
- Durable Functions
  - アルファプレビュー
  - 詳細なドキュメント
  - ASync
  - Fan-Out
  - 等など

感想

簡単にサービスを利用できる事は素敵ですね。

新しいサービスは既存サービスとどのように使い分けられるかが気になりますね。

バイタルデータの意味付けという荒波を乗り越える! 適切な処理分担のためのサーバーレスアーキテクチャー菰田泰生(ジンズ)

AWS Summitの資料がある
- https://aws.amazon.com/jp/summit2017-report/devday/
- https://d0.awsstatic.com/events/jp/2017/summit/devday/D4T8-2.pdf
JINSではいろんなアプリを作っている
- https://jins-meme.com/ja/meme/
- まだ実験段階
- センサー
  - 瞬きや目の動きを検出
    - 集中や覚醒等をアプリで解釈する必要がある
    - 瞬きの回数だけではなく強さも見れる
      - 疲れたら波が小さく
      - 眠いと波が広く
  - 加速度ジャイロ
- SDKを提供している
  - しかし、データを利用するためには別のスキルセットが必要になる
  - なるべく別の使いやすいデータにして提供したいので、その段階を作成している
  - 例
    - 覚醒
    - 没入
    - 落ち着き・緊張
    - 注意・コミュニケーション
    - 前傾角度
    - 等など
- 目指すもの
  - パフォーマンスのアップ
  - 健康寿命のアップ
- 今後もハード・アプリの改良を継続的に進めていく

ウェアラブル x バイタルデータ

IoTのキラキライメージ
- センサーから情報が集まって処理される
エッジのデータにバイタルデータはあんまり聞かない
何故か
- 面倒くさい
  - ノイズが多く信頼出来る教師データが無い
- 多段処理が必要でエントロピーを上げないと通信帯域が引っかかる
- エッジのプロセッサに意味付けが難しい
バイタルの面倒くさいデータ
- モーションは止まっていると何も取れない
- 心拍・脈拍は1次元なので複数の要因に紐付けるのが難しい
- 眼電位は比較的意味は重要だがノイズが多い
- 心拍は周波数解析があるので、パターン認識できる
- 眼電位は多段ルールを定義して統計/MLしなくてはいけないので面倒くさい
バイタルのレイヤー
- 生データ
  - 25,000bps
  - そのままのデータ
- 半生データ(瞬き抽出)
  - 3200bps
  - 特徴点の諸元を抜き出したデータ、イベントデータ
- 中間データ(区間区切り)
  - 150bps
  - 指標値に変換できるが自身では意味はない
- 指標値
  - 50bps
  - ある程度使えるデータ
アルゴリズムの制約
- ラズパイで利用するプロセッサ等もウェアラブルでは利用できない
- 浮動小数点数計算が出来ないなど
- その中でエントロピーを上げる必要がある
将来JINS MEMEではどうするか
- エッジでは出来る範囲で頑張る
- スマホで意味付けを行う
- クラウドで随時&ステートレスで処理
リアルタイム&ステートレス化のための差分更新アルゴリズム
- 長周期の平均値は移動加重平均を使用する
- 厳密な平均の差分処理は合計値・n数で分解して持つ
- 標準偏差のさ分処理は統計の式を素直に使う

サーバレスアーキテクチャ

初期はログを安く蓄積。でも必要になったときに取り出しやすいように
初期はEC2 + Dynamo, S3
Kinesis + Lambdaに移行した
アーキテクチャとして考えたこと
- ラムダ
- マイクロサービス
  - 最初から採用
- データレイク
  - S3に蓄積
  - 簡単に抽出できるように
初期はMQTTなどを想定していた
最新のサービスのアーキテクチャ(FOCUS CLOCK)
- リアルタイムや日別、週別の集中時間のデータなどが表示される
- KinesisからLambda, DynamoDB
- そこからそれぞれの処理のLambdaへ移行
データレイクのアーキテクチャ
- Amazon Auroraに近い
- DynamoからS3に入れるときにパーティション分割

開発プロセス

スピード重視、2-Phaseでツールを使い分け
- プロトタイピング
  - データをクラウドに上げるだけのアプリ
  - Shiny利用
  - うまく行ったらサーバレスで本番に落とし込む
- ステージング・本番
Shinyapps.io
- 時間課金
- Rスクリプトをコマンド一発でデプロイ
- web画面で利用できる

まとめ

バイタルデータは制約が厳しい、それに合わせてアルゴリズムを配置する
サーバレスは有効
新しいツールを取り入れることが大事
サーバレスを楽しもう！

感想

バイタルデータをどのように活用していくかという話と、開発をどのように行っているかという話が段階的にしっかり説明されていて面白い話でした！

JINSさんの今後の活用できるデータやアプリの提供が楽しみです！

IoTとエッジコンピューティングの時代 AWS Greengrass GA祝い亀田治伸(AWS)

AWS IoT

豆知識
- 大体単独で成り立つサービスはAmazon○○という名前
- AWSサービスを利用して成り立つものはAWS○○という名前
IoTサービス構造
- インフラ
- ネットワーク
- フィールド
- 下に行くほど帯域が細くなる
- 今後はEdgeをどうするかが重要

AWS Greengrass

AWS GreengrassはLambdaで出来ている
Edgeが重要視される今後に活用できるサービス
IoTはエッジでの処理の必要性が今後増えてくる(戻ってくる)
ローカルで処理する価値
- 物理法則
  - 通信速度
  - レイテンシ
- 経済の法則
  - 回線
Lambdaはイベントベースでコードを実行
Lambdaをエッジで実現するのがGreengrass
- 処理をローカルで実行
コンポーネント
- Greengrass Core
  - Lambda実行
  - メッセージング
  - Local Lambda
    - Python 2.7だけ
    - メッセージング / shadow updateを景気にLambda実行
    - 開発はクラウドで行う
  - Shadowで出来ること
    - Deviceの状態
    - 頻繁なデータ通知
    - configパラメータ
開発
- Lambdaプログラミング
  - greengrassSDKを使用する
  - whileループが可能
    - ダミーのイベント定義をする
    - イベントがあっても実際にはInvokeされない
デプロイフロー
- Greengrass Core組み込み
  - ダウンロードしてエッジデバイスに入れる
- AWS IoT連携設定
  - デバイスごとの電子証明書を組み込む
  - AWS IoTエンドポイントを設定
- Greengrass Daemon Start
  - MQTTでPolling開始
マネジメントコンソールの画面
- デバイスをグルーピング出来る
- コンソールから簡単にLambdaをデプロイ出来る
- デバイス数など増えたらAPIを利用しよう

感想

エッジでの処理は今後の課題ですが、既存のLambdaと同じ感じで開発できることは非常にいいですね！

GAされたので今後ますます活用例が増えてくると思うので楽しみです！

なぜ、サイバーエージェントにいながら、「サーバレス」という選択をしたのか、システム開発の苦悩とServerless Frameworkの魅力末松美樹雄(サイバーエージェント)

AbemaTVではテレビのような体験を提供することを目指している
AbemaビデオとしてVODサービスも開始
独自番組も制作している
AbemaTVのマネタイズの一つがCM
AbemaTVの広告局のプランニングツールの裏側がサーバレス
苦悩
- AbemaTV自体の開発と広告は別
- 広告側の開発は少ない
- CA自体のエンジニアはなかなか来てくれない
限りなく人手を少なくするためにサーバレスを選んだ
基本コンセプト
- 全てのロジックで状態は保持しない(ステートレス)
最初はJenkinsからLambdaプラグインでデプロイ
- SwaggerファイルでAPI Gatewayを管理
- しんどい
Serverless Frameworkを使った
- Serverless.ymlはSwaggerと比べてわかりやすい！
  - yamlだし
- scalaを利用しているが、起動時間を踏まえるとnodeが早い
- 常に起動するものはscala
テストコードもSpecでかける

まとめ

サーバレスは人的リソースを解消する一手となる
一般的な言語ならサーバレスを採用できる
Serverless Frameworkを使えば管理が楽
Scalaならテストコードも簡単にかける

Auth in a serverless world　(古田秀哉(Auth0))

Auth0は2013年設立
認証認可のサービス
- OpenID Connect
- OAuth2.0
認証機能を組み込むのは難しい
IDaaSを提供
なんでAuth0がServerless
- フレキシブルで拡張性の高い事が特徴
- 利用するにはサンドボックス的な環境が必要
Webtaskとは
- 信頼できないコードをセキュアな方法で開発する
- webtask.io
  - CentOS上にDocker,etcd,fleetをベースにして構築
    - 他の環境に影響を与えない
    - 結果はJSON
  - ランタイムはNode.jsベース
  - 各クラスタ上でPre-warmで動作
既存のサーバレス
- node-sandbox
  - isolationが弱い
  - レイテンシの課題がある
- HerokuやAzure
  - PaaSも考えた
  - isolationは解決できそうだがコスト的に厳しい
- Lambda
  - LambdaはAsyncで方向性が違う
結局自前で作った
デモ
- FBやGithub等との連係はボタン一つで簡単にできる
- 最近はdocomoのアカウントとの連係も開始した
使ってみたはこちら