tech.guitarrapc.cóm

Technical updates

Serverless Conf Tokyo 2018 に来ている記事7 : Serverworks Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。 集中力の限界なので、ここで終わりです。(途中で力尽きた

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

他のセッション

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

引用は私のコメントです。

目次

Title

Serverless Architecting and NoSQL Data Modeling for Successfully Microservices

Speaker

Masashi Terui

@marcy_terui

Slide

前提

AWS です。

Serverless で Microservice アプローチで問題なりやすいのは?

Function の粒度、切り方 サービスとしてのトレース

これらがいわゆるMicroservice と同様に懸念としてデてくる。

FaaS と DB

FaaS とRDBの相性は悪いのか

コネクションが都度破棄されるのでプーリングどうする? セキュリティ どうする? (VPCつなげないと認証強度あれ.....) VPCに入れるとENI作成のオーバーヘッド..... スケーリングが、厳しい.... まず垂直から検討になる。

FaaS とNoSQL の相性はいいのか

コネクションモデル がステートレス + HTPS IAM だでセキュリティ担保だよね。 スケーリングです。

で、どうしていく

という話ができないと、使い分けなんですよ、ではだめぽ。

目的のために最適化は違うことを踏まえる

やりかたはいろいろ

  • モノリシックに1つで処理
  • バックエンドAPIに分割
  • Microservice に分割して、データドリブンにつなげる

ここで話題とするのは、FaaS ごとにMicro Service にしてイベントドリブンにつなげましょう。

すべてのサービスはEventとActionの組み合わせ

Event をどのように処理すべきか。

原則として、Serverless のスケールアウトメリットを活かすなら非同期ベースに考える

  • 同期
    • API Gateway
  • 非同期
    • 直列
      • Kinesis Streams
    • 並列
      • SNS
      • SQS
      • StepFunctions

不安なのは、エラーハンドリングとなる。

  • 大事なのは、リトライできる仕組みにする。(リトラできないエラーは、1つのイベントとして通知させる)
  • モニタリング、トレーシングで必要な情報を集める

リトライアビリティはクラウドの基本だけど、冪等性、あるいは入力に対して常に同じ結果となるようにするのが重要。

どのように管理スべきか

  • Cloud Formation がいいと考えている
    • SAM / Serfverless Framework で管理すると楽

なぜかというと、Service の管理ができるから。

  • Event Srouce -> Action (Lambda) で紐付けられる
  • 宣言的
  • ImportValue /Ref

この意味で、CloudFormation はよくできている(書きにくいけど

ポイント

Event Source と Action 単位でStack を分けるのがいい。 EventSource を接続点として依存関係を集約できる。 非同期な関係性を重視することで依存関係の向きが揃う(循環依存がなくなりよい)

なぜここでClean Architecture をもってきたのか..... 文脈ちがうでしょ

Integration Test

SAM で、ステージ名をパラメータ化して、ステージごとのEventSour¥ce入れ替え。Mockを使ってDBを偽装。 入力をMock化するのでテストしやすい。 時間はかかるので基本CI化

Jenkisn や CircleCI のIDで一意なIDを取得、設定することで追跡も可能ですよ、と。

アプリケーション設計時のこつ

アプリケーション + DynamoDB 設計時のコツ

  • アプリケーションとデータモデルは同時に設計する
  • 書き込みと読み込みで都合いいデータを扱う
    • アイテムにまとめることで整合しを守る
    • 呼び込みは結果整合を受け入れて効率のよいジョインを

アプリケーション +RDS 設計時のコツ

Kibesis を噛ませてコネク暑中をおさえるのがいい。

Lambda に困っているるわけではない。

しっておくこと

  • 各データストアの特性
  • データ整合性を守る仕組み
    • ACID
  • データアクセス
    • B+ Tree Index

[ここで限界を迎えたのでおわり]