一旦、走り書き
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は特別ではない
信頼性はちゃんと自分で考えて作ろう