[Serverless Days Tokyo 2019] 無限のスケーリングと有限の失敗 サーバーレス回復力のレッスン

遅くなりましたが、10/22(火)に開催されたServerless Days Tokyo 2019のセッションレポートです。

登壇者

Microsoft Software Engineer Azure Functions

Katy Shimizu

レポート

  • サーバーレスとは
    • サーバーの抽象化
    • イベント駆動型
    • 従量課金
  • インフラストラクチャは顧客のために維持される
  • データ→イベント→サードパーティAPI→イベント→Fuctions→ DB
    • サードパーティAPIとDBサーバが死ぬとどうなるか
    • 失敗は絶対に起こるため、アプリーションがそれらを処理する必要がある
  • サーバーレス アプリケーションが失敗する場所
    • 依存関係
    • ソースコード
    • 外部依存関係
    • サーバーレス・Fassサービスの障害
    • IaasとかPaasサービスの障害
    • データセンターインフラの障害
  • 失敗例
  • レースコンディション
    • ネットワーク障害
    • レート制限
    • ハードウェア障害
  • 障害に対処する方法
    • クラウドデザインパターンを用いることである程度軽減することが可能
  • 設計パターン: 再試行する
    • 呼び出しが500で失敗したので再実行
    • もう一度500で失敗したので再実行
    • 200で終了
    • 再試行パターンをキュートリガーに追加する
  • 特別な考慮事項
    • レート制限
    • エクスポーネンシャルバックオフ
    • タイムアウト
    • キューを使用
    • サイドエフェクト
    • アイデンポーテンシー
  • 複雑なシナリオ
    • Manageable Sequencing +Error Handling/ Computing
    • Fancing-out & Fancng-in
    • External Events Correction
    • Flexible Automated Long-runnning Process Monitoring
    • Http-based Async Long runnning APIs
    • Human Interaction
  • 設計パターン:サーキットブレーカ
    • 障害が発生するとアプリケーションは再試行を繰り返すが、アプリケーションは失敗がくり返されていることを検知して安全にエラーを処理する、復旧した場合に元に戻す
    • サーキットブレーカパターンを構築するのは困難

感想

英語でのセッションでしたので、スライドベースのレポートになってしまったんですが、サーバーレスの障害にキューを使った再試行パターンやサーキットブレーカパターンなどクラウドデザインパターンを用いて対処する方法について述べられてました。下記のようにAWSのクラウドデザインパターンのサイトがありますが、上記のパターンの他にもかなりの数のパターンがあるため、参考にしたいなと思いました。

http://aws.clouddesignpattern.org/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8