この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
遅くなりましたが、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
2
