一旦、走り書き

Serverlessってなんだっけ？

CNCF Serverless Whitepaper v1.0

• サーバーのオペレーションは不要(システムのオペレーションは必要)
• アイドルの時間は課金されない(使用した分だけ)

ユースケース

• ステートレス
• 並列性
• イベントドリブン

とはいえ

並列実行やステート持たないことって現実的じゃないよね？
イベントドリブンはちょっと・・・・

Serverlessの信頼性

RASIS

信頼性を担保するのは難しい？

• BaaSやFaaSに依存する
• ログの管理や監視が難しい(問題の切り分けや追跡)
• 今までのアーキテクチャと違う
• RDBとの相性が悪い（NoSQLでのデータ整合性担保等が難しい）

FassSのよくある課題

• テストは？
• ファンクション粒度
• 各サービス間の連携
• エラーハンドリング
• ログ管理
• モニタリング
• たくさんあるサービスからなにを選ぶ？

Serverlessの実態を捉える

FaaS is コンテナ内で非同期に呼ばれる関数
BaaS is フルマネージドで抽象化されたミドルウェアやライブラリ
Serverless is 抽象化されている関数とミドルウェアで出来ている

信頼性の考え方

• 最終的には自分たちで信頼性は考えて担保する
• シンプルに考えよう（今までの考えは結構適応できる）
• シンプルさを保つ
  • ファンクションの数が増えるのを恐れない
  • 恐れるべきはアーキテクチャが複雑になること
• マインドチェンジ（アプリケーション層で解決する）

イベントは単一方向で流す

結果が必要なら同期で返さず取りに行かせる

• 自然と非同期関数になる(リトライなども出来る)
• 取りに行く場合はポーリングが必要
  • 結果ができたらプッシュ通知して取りに行かせるほうがよい(Firebase等を使う)

サービス間のエンドポインﾄは集約する

• ドメイン毎にマイクロサービス
• キャッシュやトラフィックコントロールしやすい

一連の処理には同じIDを付与

IDでトレースして様々な問題を調査できる

• ログにIDを出力することで後から調査しやすくなる(ElasticSearch等)
• 進行度の把握にも使える
• 全てのイベントも出力しておくと再現しやすい
• １度だけ処理させるチェックにも使える（冪等性担保等）

データモデリング

Dynamoの設計（GSIやLSIの活用）
意図的に非正規化して整合性を担保する
どうしても難しいなら非同期でRDBに書き込む

実装

ファンクションの粒度はユニットテストが可能な範囲
Serverless/SAM等のフレームワークを使う
継続的なE2Eテストをする（テスト用のトレースIDを用意する）

監視

どこでエラーが起きているかモニタリングや通知の仕組みを組み込む
サービスのメトリクス監視は重要（APIによってはレートリミットがあるので把握する）
E2Eテストやろう

まとめ

Serverlessは特別ではない
信頼性はちゃんと自分で考えて作ろう