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

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

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

他のセッション

tech.guitarrapc.com

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

目次
Title
Speaker
Slide
前提
Serverless で Microservice アプローチで問題なりやすいのは?
FaaS と DB
目的のために最適化は違うことを踏まえる
すべてのサービスはEventとActionの組み合わせ
どのように管理スべきか
- ポイント
- Integration Test
アプリケーション設計時のこつ

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

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

tech.guitarrapc.cóm

Technical updates