【レポート】Serverless Meetup Osaka #5 に参加してきました! #serverlessosaka

2019.08.04

どうも!大阪オフィスの西村祐二です。

すこし時間がたってしまいましたが、 2019/8/1に開催されました「Serverless Meetup Osaka #5」に参加してきましたので、レポートブログとしてまとめたいと思います。

開催場所

chatbox様の天満橋オフィスで開催されました!

セッション

Serverless Framework を使ってみよう

※資料は公開され次第更新します

今回の勉強会の主催者でもあるmikakaneさんからの発表でした。

セッションをきいての所感

サーバレスアーキテクチャを使った事例の紹介や、今回勉強会を開催することに至った経緯などが含まれた発表でした。

構成図などが多く出てきて、これから、サーバーレスの案件やろうという方にはとても参考になる内容だったと思いました。

やはり、銀の弾丸はなく、つらみなどがあったためそういった知見をみんなで共有したい」という思いから今回の勉強会開催につながったとのことでした。

私もサーバーレス案件を担当することもあり、サーバーレスのつらみやハマりどころを共有して、もっと盛り上げていきたいと思いました。

概要メモ

  • 前回から約2年の月日がたって今回の第5回目が開催された。

  • IoT with Serverless

    • 大量に存在するデバイスからのMQTT送信をきれいに処理するにはServerlessがとても便利
    • もともとApexを使っていた
    • ただ、マルチアカウントでのデプロイなどつらいときがあった
  • Serverless with EC
    • 基幹のデータをDynamoに格納してmaster系のREST APIとして活用
    • 大きなSVデータを処理するのが大変
    • sjisの処理
  • Serverless Framework
    • マルチアカウントでも運用が楽
  • Serverless vs Serverfull
    • どちらがどちらかを代替するのではなく、
    • どちらにも一長一短
  • Serverless with 辛み
    • 共有できる場がほしい
    • 今回の勉強会の開催につながった

あなたはどれだけLambdaのことを知ってますか?

いずりょーさんによるLambdaの基礎から裏側の豆知識的な内容も含まれた発表でした

登壇資料はこちら

セッションをきいての所感

Lambdaをなんとなく今まで使ってきたという人にピッタリな発表でした。

もちろん、今までLambda触ってきて中身もある程度理解しているよ!って人にとっても知識の整理や復習にちょうどよい内容だと思います。

Lambdaのライフサイクルやコールドスタート、どんな環境でLambdaが実行されているのかは、利用者にとっては気にしなくても十分に利用できますが、さらに一歩踏み込んで活用するであったり、障害時のトラブルシューティングの助けになるはずです。知識として持っておいて損はありません。

登壇資料も公開されているので、是非確認してLambdaの理解を深めましょう。

概要メモ

  • Lambdaユースケース
    • REST API
    • バッチ処理
    • IoT
    • etc...
  • Lambdaの基礎について

  • Lambdaのライフサイクル

    • 1.ENI作成
    • 2.コンテナ作成
    • 3.デプロイパッケージのロード
    • 4.展開
    • 5.ランタイムの起動・初期化
    • 6.関数・メソッドの実行
    • 7.コンテナの破棄
  • ライフサイクルの1から実行するのがコールドスタート
    • Lambda関数の更新をしたときなどで発生
  • Lambdaの呼び出しタイプ
    • 同期呼び出し
      • 同期呼び出し、ポーリングベースとストリームベース
    • 非同期呼びたし
  • エラー時リトライの挙動
    • 非同期呼びだしのリトライ
      • 自動的に2回
    • 同期呼び出しのリトライ
    • データの有効期限が切れるまでリトライする(Kinesisなど)
    • 失敗したレコードの有効期限
  • Lambdaの実行環境
    • MicroVM上で実行される(Dockerじゃない)
    • 最近はFirecrackerが使われている(OSSで公開されている)

「VPCLambda × RDSのデメリットを正しく理解しよう!」

弊社の岩田による登壇です。 別途ブログが投稿されているので、そちらもご確認ください。

セッションをきいての所感

Lambdaを中心としたシステムを今まで構築してきましたが、可能な限りVPC Lambdaを避けるのがベターという風潮のもとDBはDynamoDBを選択することがほとんどでした。

ただ、DynamoDBはNoSQLという特性もあってどうしても要件を満たせない場合であったり設計が難しい場面がありました。

こんな自分にとってこのセッションは目からウロコな内容でした。

VPC Lambdaのどこに懸念点があるのか、どういう仕組みでVPC Lambdaが動いているのかわかりやすく解説されているので、この資料をもとに要件をみたせるか、VPC Lambda + RDSのデメリットをカバーできるか改めて考え直したいと思います。

概要メモ

  • VPC Lambda + RDSのデメリットをよく理解して、効率よく開発しよう

  • Lambdaの内部の構造について

    • 「Security Overview of AWS Lambda」という資料に詳しくのっている
  • VPC Lambda + RDSのデメリット
    • コネクションプーリングの問題
    • 同時接続数の問題
    • IPアドレス枯渇問題
    • NAT Gatewayが必要
    • コールドスタート問題
  • コネクションプーリングによって初期処理を省略することができる

  • handler内で毎回RDSに接続しても、10~100msほどでそこまで遅くない(PostgreSQL)

    • 本当にコネクションプーリングが必要か、検討しよう
    • handlerの外で接続すると接続を使い回すことができるが、明示的に断する処理がないので
    • TCP周りのパフォーマンスは気にする必要があるかも
  • 同時接続数の問題
    • RDBのインスタンスクラス、db.r5largeでmax_connectionsは1600で基本接続要求エラーにはならない
      • 接続でエラーとなる場合は別の要因が考えられる
  • IPアドレス枯渇問題
    • ENIはWorkerにアタッチされる
    • Lambdaのコンテナ1つにつき1つのENIを消費するわけではない、計算式が公開されている
  • コールドスタートの問題
    • ENIの作成は遅い(10秒から20秒ぐらい)
    • コールドスタートの遅延については改善される予定なので今後に期待
  • ENI作成を伴わなければ現状でもVPC Lambdaは十分高速

ハッカソン的 に作ったプロダクトを改善し、Firebaseを「ちゃんと」使っていく話

HANATANI Takuma(@potato4d)さんによる発表で今まではAWSの話だったのですが、このセッションはFirebaseの話でとても新鮮でした。

セッションをきいての所感

Firebaseはまともに触ったことがなく難しいところもありましたが、短期で作ったシステムをどのように改修したか、どういう考えのもとCloud FunctionsやFirestoreを使い分けたか、どういう問題にぶつかったか、実体験をもとにした内容だったので参考になる方は多いのではないかと思いました。

今後、Firebaseを使ったシステムを構築する機会がありましたら参考にしたいと思います。

概要メモ

  • 1st release
    • SPA/API + Firebase構成
    • SPAはNuxt.js、APIはCloud Functions,認証はFirebase Auth
    • 決済関連を含むのでFirestoreの直接アクセスは封印
  • 課題
    • Cloud FunctionsのHTTPフック使いすぎ問題
    • 妥当性やパフォーマンスが課題
  • 管理画面
    • 運用するにつれてDBを触って欲しい人が複数人になった
    • 権限管理をはじめに考慮しておくべきだった
    • RDBなどと違ってシステムのユーザで権限を管理できないのではじめから設計しておく

LT

「Serverless Performance 実測比較」phonypianist

阪本雄一郎さんによるLT発表です

セッションをきいての所感

言語別にパフォーマンスチェックを行ったという内容でとても興味深い内容でした。言語ごとに得手不得手があって一概にどれがベストかは言えないですが、一回自分でもこのようなパフォーマンステストをやってみようと思います。

概要メモ

  • Lambdaで注意するべきポイントの1つ
  • 「コールドスタート問題」
  • 言語別にパフォーマンスをチェック

  • 計測方法

    • 500万件の要素の線形検索:CPUを使う処理の模倣
    • スリープ100ms:IO待ち処理の模倣
  • 計測対象
    • Node.js
    • Python
    • Java
    • Go
  • 計測結果
    • JavaはVMをたてる処理がある場合は遅い
    • Goははやかった
      • Cold Startでも速かった
    • Pythonはリスト生成にかなりメモリを消費する
      • numpyをつかうとJava並の時間になった※追記されていました。
  • 今の所の所感
    • 安定したレスポンスを求める場合 => Go
    • スクリプトで手軽に書きたい場合 => Node.js

「FirebaseでWebApp開発を通して感じたNoSQL設計の反省」Takahiro.dev

※資料は公開され次第更新します

Takahiro.devさんによる発表です

セッションをきいての所感

AWSではDynamoDBがNoSQLでいつも苦労しているので、すごく共感できる内容でした。

Firebaseでもほぼ同じ問題が起きるようなので、汎用的な知識と解決策を持っておきたいと思います。

概要メモ

NoSQLの設計

  • あとから想定外の型が挿入
  • 非正規カラムの乱立
  • 更新処理が複雑に

  • 反省点

    • 事前にソフトスキーマ入れる
    • データ構造をシンプルにしてAggregatesでデータを取り扱う
    • ネストを浅くすると分散するので、どれが正解か答えは出ていない

選ばれたのはNetlifyでした

※資料は公開され次第更新します

ririkoさんのLT発表です

セッションをきいての所感

非エンジニアからの目線の内容で気付かされることが多かったです。サービスを作る上でどうしてもいろいろ機能を盛り込みがちですが、ターゲットととするユーザは誰なのか、ユーザが達成したい目的は何かを定めて、それを達成するための手順をなるべく減らすことが重要なのかなと思いました。

概要メモ

  • デザイナー目線の発表
  • 個人のブログを運用している
  • AWSで構成するとどんな感じなのか
  • AWSでつくるならサービスを組み合わせて構築する必要がある、大変
  • NetlifyならAll in One!
  • 選んだ理由UIがシンプルでわかりやすいから!

さいごに

AWSの話だけではなく、Firebaseに関する話もきけてとても勉強になりました。

今後も継続して開催予定とのことなので、次回も継続して参加して行きたいと思います。