AWS

JAWS DAYS 2018 レポート Enterprise Serverlessを実現するための信頼性エンジニアリング

一旦、走り書き

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等)
  • 進行度の把握にも使える
  • 全てのイベントも出力しておくと再現しやすい
  • 1度だけ処理させるチェックにも使える(冪等性担保等)

データモデリング

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

実装

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

監視

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

まとめ

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