【Sls Popular Talks 2017メモ】Applied Serverless Design Patterns

　この記事は、

www.ketancho.net

の一部です。サーバレス関連の良い発表を理解していくことで、知見を溜めていきたいとかんがえています。

　この記事で取り上げるのは、下記のサーバレスデザインパターンに関する発表についてです。

Applied Serverless Design Patterns by Yochay Kiriaty www.youtube.com

メモ

  • Function 設計
    • Function は1つのことのみやらせること。複数の責務を与えないこと。
    • Function はなるべく早く完了するように構築すること。
    • Function はステートレスであること
    • Function は冪等であること
  • Design Pattern
    • Pattern #1: Function Chaining
      • Function を細かくするということは、Function が他の Function を呼び出していくことになる。 このときの問題として、
        • 関数間の関連性が見えなくなる
        • エラーハンドリングが難しくなる
        • ロールバックをどうするか などが挙げられる。
      • そこで、Function が他の Function を呼び出す際は、 コーディネートするサービスを使うことを心がけるべき。
        • Azure Logic App
        • AWS Step Functions
      • 後半の Function ロジックの中で、前半の Function の実施結果をロールバックしたいときは、 エラーハンドリング用の Function を用意することで全体を統制するようにする。・・・★
        • これを用意してしまうと、コーディネートをコーディネートサービスに一元化できてないのでは？
      • トランザクションがないのでどうするか？
    • Pattern #2: HTTP Async Response (HTTP 202)
      • 非同期なワークフローを構築したい時に、Promise 的な処理をどのように構築するか
        • Queue や DB? に前段の状態を挿入する
        • 後続の処理については、前段が完了したかをチェックしてから処理を行う
    • Pattern #3: Fun-Out
      • 数千オーダーのメールを送るなどの処理をどのようにスケールさせるか
      • シーケンシャルに実施するのではなく、キューに挿入した上で後続の Function が並列に処理を進めるように設計する
      • Fun-in についても考える必要がある
        • 並列でなにかの処理をしたあとに、それを合流させる処理をどのようにするか
        • 後続処理用のステートを管理するキューなりDBなりを用意して、・・・★ 最終処理を行う Function が起動するようにする
    • 他にも様々なパターンを GitHub に用意しているので、確認してみてください。

感想／疑問点

　ついつい複雑な Function を作ってしまうので、最初の4つの設計指針は改めて心がけたいと感じました。

　基本的には、ステートを管理するのは他のサービスにまかせて、Function は疎にしましょうという理解をしたのですが、★の部分である Function が他の Function の結果を意識するような設計になっていたのですが、ここがやや矛盾してしまうのでは？と感じたのですがどうなのでしょうか。。