毎年参加しているServerless Conf Tokyoです。3回目になります。 集中力の限界なので、ここで終わりです。
他のセッション
- http://tech.guitarrapc.com/entry/2018/09/29/110107
- http://tech.guitarrapc.com/entry/2018/09/29/114953
- http://tech.guitarrapc.com/entry/2018/09/29/124659
- http://tech.guitarrapc.com/entry/2018/09/29/141039
- http://tech.guitarrapc.com/entry/2018/09/29/151114
- http://tech.guitarrapc.com/entry/2018/09/29/154004
引用は私のコメントです。
- Title
- Speaker
- Slide
- 前提
- Serverless で Microservice アプローチで問題なりやすいのは?
- FaaS と DB
- 目的のために最適化は違うことを踏まえる
- すべてのサービスはEventとActionの組み合わせ
- どのように管理スべきか
- アプリケーション設計時のこつ
Title
Serverless Architecting and NoSQL Data Modeling for Successfully Microservices
Speaker
Masashi 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
[ここで限界を迎えたのでおわり]