ほげほげふがふがもぐもぐ。

ゆるふわにかいていきたいです。

Serverless Meetup Tokyo #2 いってきたので雑なメモ

これは?

  • 社内向けに書いたmemoを折角なのでここを全然活用できていないので書くかー、みたいな感じで転載してみる。
    • よくよく見てみたら2年くらいたってたし、qiita以外にこっちも書いていかないとな感…(◞‸◟)

Serverless Meetup Tokyo #2

https://serverless.connpass.com/event/44308/

19:00-19:10 Opening: 2017年Serverless化していく世界の概況 吉田真吾 (セクションナイン)

http://www.slideshare.net/YoshidaShingo/welcometoserverlessmeetuptokyo2

  • 自己紹介
  • serverlessconf とは
    • 去年秋口に東京で開催
    • 大阪、札幌でもmeetup開催
    • FBでもコミュニティあり
  • FBでのアンケート紹介
    • serverlessでの開発でどんなツールを利用してるか
      • 1 serverless flamework
      • 2 apex
      • 3 lamvery
      • 4 swagger
      • 5 SAM
      • 6 postman
      • 7 MS VS
      • 8 aws cli
      • 9 エクリプス
    • どんな話ききたい?
      • 1 開発手法、ci/cd
      • 2 vm vs contener vs serverless in 2017版
      • 3 AI系
      • 4 api
      • 5 SPA
      • 6 serverless ストリームデータプロセッシング
  • 告知
    • serverless conf
      • 最初 Austin 4/26-28

Impressions

  • やはり、みんな開発手法とかを知りたがってるんだなぁ感

19:10-19:35 Tune Up AWS Lambda 西谷圭介 (AWS)

http://www.slideshare.net/keisuke69/tune-up-aws-lambda

  • 普段はアーキテクチャだが、今回は lambdaのパフォーマンスの話
  • 自己紹介
  • lambdaにおけるパフォーマンスに関する基本
    • 同時実行数
      • ファンクションの実行数
    • 同時実行数の考え方
      • 大前提
        • 無限ループとか用にセーフティーガードがあり、上限100
      • 大きく分けてイベントソースは2つ
        • ストリーム系(kinesis, dynamodb)の場合、シャード数と等しくなる
        • それ以外は (1sec * 関数の実行時間)
          • 例:1秒辺りのイベント数10件で、平均実行数が3秒の場合、同時実行数は 30となる
    • 同時実行数の制限緩和
      • 可能
      • とはいえ、実績がないとなかなか難しい
        • 実際に処理が行われていること
  • lambda functionのライフサイクル
    • 昔話していたが、改めて説明
    • 裏側ではコンテナとして実行(not docker)
    • 開始・再利用・終了
    • 開始
      • コールドスタート
    • 終了
    • 再利用
      • コードの変更がなく、前回の実行からそんなに時間が経っていない場合、以前のコンテナを利用
      • 再利用は保証している場合ではない
    • 凍結・再開はそんなに関係ない
  • パフォーマンスに関する設定
    • メモリ設定
      • 実際には、関数だけではなくメモリ使用率が増えればCPUも増える
      • CPUが必要な場合増やしておくと良い
    • バッチサイズ
      • ストリーム系の設定
      • 一度に取得する最大のレコード数
      • どちらが最適なのかは、ワークロード次第
  • lambda funcを早くする方法
    • コールドスタートをいかに早くするか
    • ファンクションの実行時間を短くする
    • 同時実効性をあげる
    • コールドスタートを早くする場合
      • コールドスタートを減らす
      • lambdaファンクションに対してpingする
        • 定期実行なイメージ(5分をawsではオススメ)
        • 定期的にinvokeを行うことで、コンテナが破棄されることを回避する
      • コンピューティングリソースを増やす
      • ランタイム(言語)を変える
        • JVMの起動は遅い
        • とはいえ、1度起動すると早い傾向
      • VPCを使わない
        • ENIの生成とアタッチが遅いため
        • コールドスタートを早くしたい場合、datastoreはDynamoDBが鉄則
          • どうしてもVPCの問題で利用したい場合は、DynamoDB streamをオススメしてる
      • パッケージサイズを小さくする
        • サイズが大きくなると、コードのロード、zipの展開に時間がかかる
        • 不要なコードを減らす
        • javaは肥大しがち
        • javaの場合だけ
          • POJOではなく、バイトストリームを使う
    • ファンクションの実行時間を短くする場合
      • コンピューティングリソースを増やす
      • 各言語のベストプラクティスにそうとよい
      • グローバルスコープを有効に使う
    • 同時実効性をあげる場合
      • 同期実効性の高いアーキテクチャに変えて、処理全体のスループットをあげる
      • 同期でimvokeすると、同時実行数の制限にひっかかってつまりがちなので非同期でやる
        • ほとんどのイベントソースからは非同期でトリガーされる
      • 1ファンクションの実行時間は可能な限り短くすること
  • まとめ
    • パフォーマンス関連の基本
    • lambdaファンクションを早くする
    • 同時実効性をあげることで、全体のスループットをあげる

Impressions

  • 元々興味があってもおもしろい
  • ベースの考え方は同じ感じで、あとはlambdaの制約などを理解すると当然よいな、という感じ
  • ここら辺の考え方はコンテナで動いてるということもあり、dockerなりにも思考パターンの応用として使えるのかな?

19:35-20:00 2017年のサーバレスアーキテクチャを考える - AppService/Event Hubs/Stream Analytics/Data Lake + カスタマー事例 久森達郎 (Microsoft) & 東聡志

http://www.slideshare.net/myfinder/2017-webappsevent-hubsstream-analyticsdata-lake-functions

  • インフラエンジニアリングレスアーキテクチャを考える
  • 自己紹介
    • azureは一昨年から
  • FaaSの意義って?
    • サービス単体では意味がない
    • 組み合わせることに意味がある
  • webアプリ難しい
  • コンテナも難しい
  • Azure WebApps on Linux ?
    • 現在プレビュー中
    • herokuとかに近い
    • docker hub, privateレジストリからも可能
    • dockerコンテナを投げ込める PaaS
  • DB, cacheなどのデータストアも難しい
  • ログストリーム系
    • event hubs, Stream analytics
  • ラムダアーキテクチャ
    • ログがずっと流し続けたい
  • データ処理フローの中でうまいことやりたい
  • event hubs, Stream analytics
    • kafka streamに近い
  • タイムウインドウベースの処理
  • data lake store
  • 活用のシナリオ
    • サーバーレスモバイルバックエンド
    • リアルタイムbotメッセージング
  • functionsのプログラミングコンセプト
  • サポート言語
  • サーバーレスとはなんだったのか
    • を受け取って、処理
    • つまり、サーバーレスとは21世紀のCGI

      ここから実際のユーザーにバトンタッチ

      通知周りの仕組みを azure functionで組んだ話

  • 自己紹介:@ytnobody
  • 背景事情
    • 通知サービスの選定に迷っていた
      • 一昨年の時点で契約していた
  • この手の話でよくいわれる「なんでazureに?」
    • メインのインフラがオンプレ
      • オンプレの面倒に消耗
      • 秘伝のタレ化したオンプレ
  • 通知システムの構成
    • 既存インフラ
    • azure上に新規構築
      • EventHubs / functionApp / notificationHubs / queue storege
      • functionApp
    • Event Hubs
  • 2ヶ月運用して
    • 処理数 平常時 1200件/分ほど
    • 見込んでた費用が3,40万/月くらい
    • 実際は20万/月くらい
  • まとめ
    • azureで図らずもサーバーレスアーキテクチャしていた
    • push送信は難しい
    • functionAppが簡単だった
    • だいたいみんなこんな感じのアーキテクチャになるのでは

      ここから久森達郎 (Microsoft)さん に戻る

  • インフラエンジニアリングレスアーキテクチャとは
    • インフラエンジニアをなくそう、ではなく、適材適所でやっていこう
  • もっと知りたい方は
    • 最近書籍を出した

Impressions

  • 純粋に、azureのサーバーレス周りや他のサービスを知らなかったので面白かった
  • bash serverlessは面白い
  • 安い、という話だけれど、lambdaとの比較だとどうなんだろうなー

20:10-20:30 サーバーレスAWS構成でセキュアなSPAを目指す - Cognito+API Gateway+Lambda+DynamoDB+KMS 加藤雅之 (ハンズラボ)

http://www.slideshare.net/masayuki-kato/serverless-awsspa

  • 自己紹介
  • 今日話す
    • サーバーレスAWS構成でセキュアなSPAを目指す
      • の紹介ではなく
        • 東京ハンズの考え方
          • ヒント・マーケット
          • そんな思いをここでも
  • まずはSPAのベースとなる静的サイト
    • html, jsなどをS3へ
    • より多くアクセス可能なようにCFかます
    • route53を利用
    • ACMhttps
  • 動的な情報をjsonで返すapiの入り口
  • 動的な情報を処理するfunction
  • 情報保持
    • dynamoDB
  • api gateway
    • 適切なリソース、メソッドでlambdaを紐付け
      • RESTfulな思想
  • XSS対策のために
  • 以上で、動的でセキュアなSPA完成
  • いよいよ個別ユーザー機能
    • cognito で用意されている user poolsを使用していいが、今回はfederated identitiesを使用
  • developer authenticated identityの仕組み
    • 認証フローは複数あるが、拡張人疎湯フローを使用
    • userはうけとったtokenをSTSで使用
  • cognitoの登録
    • federated identitiesより、identity poolを作成
  • ユーザー登録lambda
    • ID/PASSのユーザー登録
  • ユーザー認証lambdaを作成
    • 作成したcognitoに対して処理を行う
  • クライアント処理とセンシティブなAPIの保護
    • 返却されたcognito tokenをクライアントに保存
    • getCredentialsForIdentityを使用
  • 有効期限に注意
    • STS Credential有効期限は最大1時間
      • cognito tokenで再取得
  • ならば json web token
  • JWTの何がいいの?
  • KMS
  • 暗号化:独自JWTの検証lambda
  • 認証を行いたいapiへ実装
    • api gatewayにてオーソライザーとしてlambdaを登録
  • 以上で、セキュアなサーバーレス
  • cognito でこんなセキュアなことも
    • S3プレフィックス

Impressions

  • 結構実運用よりな感じの話をステップ事に説明されていて面白かった
  • ここら辺の流れを再度理解していくために、スライドは何回か読み直したい

20:30-20:50 データ処理プラットフォーム in Serverless - AppEngine/Pub/Sub/Dataflow/BigQuery 福田潔 (Google)

http://www.slideshare.net/kiyo0123/noops-bigquery-cloud-dataflow

  • data + no-ops
  • 自己紹介
  • data makes software great
  • better software, faster
    • no-opsにするためには、自分たちでプラットフォームを作らなくてもいい時代へ
  • 分析に費やす時間を増やす
    • インフラではなく、データから知見を導くところにフォーカスする
  • google in 1 minute
    • googleは大きなデータに強い
    • 3M searcher, 100 hoursなどなど
  • mapreduce 後のイノベーションの歩み
    • 自分たちで使うために開発してた
  • 15年以上、データの問題に向き合ってきた
  • プロダクトにマップすると
    • 収集、保存、処理、分析、可視化
    • apache beamが正式プロジェクトに
  • BigQueryとは?
  • unstructured data accounts for 90% of enterprise data
  • Cloud Dataflowとは?
    • バッチ処理の問題点などを解決
    • Dataflowは新しいデフォルト
      • googleでは mapreduce を直接触ったりすることはもうやっていない
  • Dataflowモデル及び、Cloud Dataflow
  • spotify事例
  • シンプルに始める
    • どこから始めるかだとやはり BigQueryから始めるのがシンプル
    • 次にETLを追加
    • ストリームに対応
  • 結果は?
    • 1PBで131秒で処理が終了

Impressions

  • ところどころ、仕事できちんときけてない部分があり残念(☝◞‸◟)☝
  • あとでまた読み返して理解していきたい(☝◞‸◟)☝

21:00-21:10 Firebase+Railsのハイブリッドだからこそできた2ヶ月で2つのチャットアプリを開発した話 安尾友佑 (Redish)

https://docs.google.com/presentation/d/16C2Y-W2nzbTpDS0_Y6DWxADYG7z84eFgR069-2P57Bw/edit#slide=id.p

  • 自己紹介
    • 会社説明
  • 入社時の状況
    • 2016/08に入社
    • お客さんは賛同してた状態
  • 課題
  • Firebaseとは
    • リアルタイムデータベースとは
      • 任意のJSONをツリー上に保持
    • リアルタイムデータベースの使い方
  • Railsでの開発
    • コア機能はRailsで実装
  • カスタム認証
    • Firebase authentication
  • 完成イメージ
  • 現在
    • 周辺の粗結合なところをaws lambdaとかに
  • push通知
    • google公開のツール?を利用
  • まとめ
    • firebaseは既存のシステムとハイブリッドで利用しやすい

Impressions

  • Firebaseはちょっと面白そう(小並

21:10-21:15 Very Special LT about Apache OpenWhisk 常田秀明 (日本情報通信)

http://www.slideshare.net/hideakitokida/serverless-meetup02-openwhisk-71089759

  • 自己紹介
  • 1分でわかる OpenWhisk 背景
  • 1分でわかる OpenWhisk プログラミングモデル
  • update
    • 公式サイト
    • api gateway
      • ワンポイント機能紹介
  • お知らせ
    • ハンズオンとかやるよ

Impressions

  • オンプレ serverlessは面白そう(小並
  • 会社にあったら喜ぶ人はいそう(小並

21:15-21:20 Real World Serverless nasa (freee)

https://docs.google.com/presentation/d/1_-woxhX71qGAFFKsSXBWW6B36AOeKAemsaVTsiMfaF0/edit#slide=id.p4

  • 自己紹介
  • freeeでの利用例
    • レシート・請求書のメール転送で利用
  • 利用
    • aws lambda, sqs, s3, dynamodb, apex, lambda-local
  • 工夫したこと1
    • 既存のシステムに影響しないように
      • 不正メールが大量にきたときなど
        • dynamodb
  • 工夫したこと2
    • retryを前提
      • 合計3回
  • その他
    • リージョンをどこかのタイミングで超える必要があった

Impressions

  • リージョンまたぎの話、リトライの話は面白かった
  • もうちょっと詳しく話をきいてみたさがあった

21:20-21:25 Operation and Management with Azure Functions 工藤淳 (cloudpack)

http://www.slideshare.net/jkudo/operation-and-management-with-azure-functions

  • 自己紹介
  • 本題
    • serverless運用するのにサーバーたてる?
      • azureに限らず、ログやシステム監視でたてる必要がある
  • azure functionsの場合
    • ログが便利
    • azure functions pulse
    • azure cli
      • tailで流すことも可能
    • azure powershell
  • ログの保存
  • application insightsと連携するといい感じにできる
    • datadog, pagerdutyなども使える
    • スマート検知機能ある
  • OMSを利用してる
  • OMS Log Analytics > アラート
    • PoweBI - excelエクスポートもできる

  • azure functionsを起点にすることで、lambdaよりは Serverlessな運用が可能

Impressions

  • 運用周りの話はそんなに聞くことがなかったので面白かった
  • lambdaというか、awsでのパターンも知りたいし、考えたい

21:25-21:30 SEO対策したサイトをAPI Gateway+Lambdaで作ってみた話 平田貴大 (カラダメディカ)

http://www.slideshare.net/ssuserb2e85a/seoapi-gatewaylambda

  • 自己紹介
  • CaraCoroというプロダクトの説明
  • 今日伝えたいこと
  • 開発環境
    • Serverless flamework など
  • 本題
  • API GatewayでHTML返せばよい
  • サーバーサイドレンダリングをやるように
    • 問題はまだある
      • パフォーマンスが悪い
    • レイテンシ
  • まとめ

Impressions

  • とくになし

さいごに

  • 次回は日程未定・会場未定だが、3月くらい

全体感想

  • やはり、aws周りは実例、実運用の話が結構増えてきてて、面白かった
    • とはいえ、まだまだアーキテクチャ自体が過渡期なので、みんな苦労してる感
  • azureはazureで結構頑張ってるんだなーという印象
    • 自分がそんなに追っていないのもあるので、awsと比べた時のコストや機能などの比較はちょっと知りたい
  • google事例がなかった感じなのは、ちょっと意外
    • ここら辺も次回とかできいてみたい