Feedforce Developer Blog

フィードフォース開発者ブログ

Serverlessconf Tokyo 2017 に参加してきました

Serverless

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎

先日のおとうふ先生の記事にもあったように、Serverlessconf Tokyo 2017 というイベントが都内で開催されておりました。

developer.feedforce.jp

11/3(金) のメインカンファレンスには弊社からも5名ほど参加しており、みんな大学生の頃の100倍くらい意識高く勉強して参りました ✌︎('ω')✌︎ お昼ご飯に弁当出たのが嬉しかったです ✌︎('ω')✌︎ あと、馴染みあるメンツでカンファレンス行くと、終わってから飲みに行けるのも良いですね ✌︎('ω')✌︎

さて、今回の記事では当日の発表内容についていくつかダイジェストと感想を書いていきたいと思います。

スライドはこちらのサイトでまとめられているようで大変助かります 🙏

www.n-novice.com

サーバレスアーキテクチャによる時系列データベースの構築と監視

  • Mackerel という監視サービスをどのように監視・管理しているのか、というお話
  • 時系列データベースの構成
    • Kinesis Streams へ保存
    • Lambda で Redis へ保存
    • Redis に一定件数溜まったら DynamoDB へ保存
      • 一度 Redis を挟んでいるのは書き込みコストを抑えるため
    • DyanmoDB の TTL を超えるデータは S3 へ保存
  • データの参照性に合わせて書き込み先を変更しているのはナルホド
  • 監視についてまとめ
    • メトリックを可視化して眺めよう
    • 監視の基礎は平常状態を知ること
    • 系全体の可用性を監視しよう

Serverless を使った具体的な設計例として、とても参考になります。 時系列データベースの実装として、複数のストレージを上手く組み合わせて設計されているのは色々なシーンで応用できる設計例ではないでしょうか。

Java チームが選択したTypeScript による AWS Lambda 開発

Slides | Riotz Works

  • 固定 IP を実現するには VPC lambda が必要
    • VPC の lambda はすごく遅い
    • 固定 IP に対する需要は現在も一定数あるようなので。。。（日本では特に）
  • マイクロ化が過剰で複雑になった
    • どの程度の粒度でサービスを切り分けていくか、というのは相変わらずセンスが問われるな、という印象
  • 言語毎に実行速度がずいぶん違う
    • 一度 Java で実装して、スピードが出ずに TypeScript で実装し直した

Serverlessの世界に特別なことなんて何もなかった

slideship.com

  • Serverless でよくある課題と解決
    • Functionの適切な分割・統合
    • Functionやサービス間のデータの受け渡し
    • 外部サービスの呼び出しとエラーハンドリング
    • テスト
  • スライドに色々な Tips が詳しく書かれているので一読すると吉
    • ただ、紹介されている方法だと Lambda Function の粒度がかなり細かくなるので、その辺の管理は大丈夫なのか気になりました
    • マイクロ化しすぎ問題とかは大丈夫でしょうか？
  • どういうサービスが Serverless に向いているのか、という話も出てくるので参考になります
    • 個人的には特性を押さえた上で、従来の Rails のようなアプリケーションと Serverless をハイブリッドに組み合わせて使うのが良いと考えています

Serverlessとか言う前に知ってほしいDBのこと

slideship.com

  • 一個前のと同じ登壇者の方
  • 非同期で並列数を制限すれば RDS を Lambda から利用しても問題ない
    • 同時接続数が爆発しないように調整して使えば OK
  • DynamoDB でフルスキャンしたら負け
    • この辺は最近自分でも勉強していたので再確認しながら聞いていました（宣伝）

developer.feedforce.jp

真のサーバレスアーキテクトとサーバレス時代のゲーム開発・運用

他の発表と被ってしまったので、当日の講演は見られなかったのですが、ブログの方を見たらとても興味深い内容だったのでご紹介しておきます🙏

gs2.hatenablog.com

実は、私もSaaSはサーバレスなのか？という事に対しては、ちょっと思うところがあります。 私はフルマネージドサービスはサーバレスだと思いますが、マネージドサービスはサーバレスではない。と思っているためです。 また、別の言い方をすると、スケールに限界があるモノはサーバレスではない。と思っています。 つまり、使用方法さえ間違えなければ《勝手に》《無限に》スケールするフルマネージドサービスこそがサーバレス。と言えるのではないか。と思っています。

SaaS の運用・開発してる人だと結構重要なテーマなのではないか、と思います。 SaaS なんだからリクエストどんだけ送っても向こう側で良きに計らってくれるやろ。そう思ってた時期が俺にもありました 😇 とは言え、SaaS 利用者からそう見えるようなサービスにしたい、という思いはあります。SaaS 利用者としても SaaS の裏側のことは一切考えずに利用したいと思うので。。 弊社の ソーシャル PLUS も SaaS ですが、利用して頂いているサイトがイベントなどでアクセスが急騰するケースがありますので、開発・運用ではそういう点に気を遣っています。

  • コールドスタート対策
    • コールドスタートとは
      • Lambda は初回呼び出し時やしばらく呼ばれなかった後に呼ばれたときは response time が長くなる
    • 1 つの Lambda Function に全ロジックを入れる
      • API Gateway のエンドポイント毎にどのロジックを実行するかパラメータで渡している
      • コール比率の低いエンドポイントでもコールドスタートを回避できる
    • パラメータで動作が変わる
      • Rails の Routing のようなものと佐藤は解釈しました
    • 一定間隔で Lambda を起こすように Invoke させる方法もあるが、個人的には Routing やらせる方式の方が良いのではないか、という気がする
      • Lambda Function が大量に作られてしまう（マイクロ化しすぎ問題）と管理が難しくなるのではないか、という思いもあって
      • この方法は実際に試してみたいです

所感

Serverless に限ったことではありませんが、近年登場する新技術はトレードオフな側面が強いように感じています。 一昔前は今までは解の無かった技術的課題を解決する形で新しい技術が登場する、というケースが多かったのではないでしょうか？ 対して今は、既存の技術でもできなくはないけど、特定のケースで困るから、それを解決する新しい技術が登場する、というケースが多いような。 そして、その特定のケースを解決するために、一部のことは許容しなければならない、という印象です。 （まあ単純に僕も歳をとって、保守的な考え方が強くなってきただけなのかもしれません。。）

今回のカンファレンスは実際の開発者からどういうトレードオフがあるか、という話が出てきたことで、自分の中で改めて Serverless と向き合う覚悟というか、モチベーションが出てきたように思います。

とはいえ、個人的には、従来の Rails アプリと Serverless をハイブリッドに使った設計に取り組んでいくのが現時点での最適解ではないかと感じています。 もちろん、設計を考えた上で Full-Serverless が最適となれば、そういうアプリを作って行くつもりですが、それなりに複雑なロジックを考えるにはまだ Full-Serverless は早いのではないかな、と思います。 やはり並列性の高さが Serverless の魅力なので、アプリケーションの基本的な部分は従来通り Rails で作成して、アクセス数が急にスパイクするような場所を局所的に Serverless にするような設計をこれから色々試していこうと考えています。

ただ、Serverless のコンセプトとしては、ソフトウェア開発の生産性そのものを向上させることが目的とのことだったので、将来的にはハイブリッドよりも Serverless に振り切った設計がベストになっていくかもしれません。今後の発展に期待しています。

▲