tech.guitarrapc.cóm

Technical updates

Serverless Conf Tokyo 2018に来ている記事7 - Serverworks Session

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

http://tokyo.serverlessconf.io/

他のセッション

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

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

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