Serverlessを取り巻く現状とAll Serverlessでプロダクトを構築する苦労

CloudNative Days Tokyo 2020

Transcript

1. 1
   Serverlessを取り巻く現状と
   All Serverlessでプロダクトを構築する苦労
   Merpay SRE ・Microservices Platform CI/CD Team
   Keisuke Yamashita(@_k_e_k_e)
   CloudNative Days Tokyo Track A 17:20-17:40
   2020/09/08
   

   View Slide

2. 2
   Keisuke Yamashita(@_k_e_k_e)
   Merpay SRE ・Microservices Platform CI/CD Team
   Like
   Kubernetes, Hashicorp Products(Terraform, Vault)
   Spinnaker , Open Policy Agent, CircleCI, GitHub Actions,
   Istio, Envoy, Serverless etc...
   

   View Slide

3. 3
   後ほど資料は公開します！
   

   View Slide

4. 4
   Agenda
   

   View Slide

5. 5
   Agenda
   01 ● Serverlessを取り巻く現状
   02
   03
   ● All Serverlessでサービスを構築する苦労
   ● Wrap up
   

   View Slide

6. 6
   Serverlessを取り巻く現状
   

   View Slide

7. 7
   Serverlessを取り巻く現状は大きく2つの観点から進化している。
   A. Serverless製品自体
   Google Cloud Platfrom(GCP)やAmazon Web Service(AWS)が提供してい
   る製品のアップデート・追加されたもの
   B. Serverlessに関連する機能
   直接的ではないが、間接的にServerlessに対して機能が追加・改善されたりされた
   もの
   Serverlessを取り巻く現状
   

   View Slide

8. 8
   A. Serverless製品自体の進化
   

   View Slide

9. 9
   ハンドシェイク時にバックエンド (Worker)にWarm upをすることによって5ミリ秒くらいでリクエスト処理を 実
   行できる。Cold Startがなく高速に起動されてリクエストが処理される 。
   リクエスト数による従量課金モデル 。
   Serverless固有のCold Startによる
   タイムリミット超過などに対して非常に
   有効である。
   ● Cloudflare Worker
   依然としてCold Startはあるが、改善例として
   VPC内のAWS Lambdaがある。約1秒くらいの
   起動時間。
   今後は、Cold StartのないServerlessが多くなる？
   1. Cold StartのないServerless製品
   Ref: “Eliminitating cold starts with Cloudflare Workers”, https://blog.cloudflare.com/eliminating-cold-starts-with-cloudflare-workers/
   

   View Slide

10. 10
    ユーザーに近いロケーションで処理し応答性が上げ、ユーザー体験を向上できる製品が出てきてる。
    Serverless製品を使って世界規模のサービスを構築することも
    できるようになっている。クラウドプロバイダのネットワークが大きな鍵になる。
    ● AWS Lambda@Edge
    ● Cloudflare Worker
    ● Fastly Compute@Edge
    ● …
    より多くのユースケースで採用される可能性
    2. Serverless on Edge製品
    Ref: “CloudFront redirections for your SPA using AWS Lambda (A/B testing, maintenance page,…)”,
    https://codeandtechno.com/posts/cloudfront-redirections-lambda/
    

    View Slide

11. 11
    動作するプラットフォームが多様化している。
    ● 大手クラウドプロバイダ
    ○ Google Cloud Platform(GCP)
    ○ Amazon Web Service(AWS)
    ○ Microsoft Azure, Tencent Functionsなど
    ● 他のSaaS
    ○ Nimblella
    ○ Nuwebaなど
    ● Kubernetes
    ○ Knative
    ○ Kubeless, Open FaaSなど
    ● ブロックチェーン
    ○ ChainFaas
    ● 機械学習
    ○ Algorithmia
    3. Serverlessプラットフォームの多様化
    Ref: 図上: https://sara-dev.com/
    新しいプラットフォームが出てくるかも
    

    View Slide

12. 12
    Serverless製品をトリガーさせることのできるイベントソースが変化している。
    ● HTTPリクエスト
    ○ Cloud Functions, Cloud Run
    ○ AWS Lambda with API Gatewayなど
    ● WebSocket
    ○ AWS Lambda with API Gateway
    ● プラットフォームのイベント
    ○ Netlify Functions
    ○ MongoDB Atlas Serverless
    ○ Cloud Functions for Firebase
    ○ Twilio Functions
    ● 任意のイベントリスナー
    ○ Knative
    ■ Falco + Knative, Kafka + Knativeなど
    4. イベントソースの多様化
    更新を通知
    よりいろんなイベントでトリガーできるようになるかも
    

    View Slide

13. 13
    1. Frameworkの台頭
    a. Serverless Framework
    i. Cloud FunctionsやAWS Lambda、Azuru Functionsに限らず、クラウドプ
    ロバイダのServerless製品に対して使えるフレームワーク
    b. AWS SAM
    c. Chalice
    i. AWS Lambda用のPythonマイクロフレームワーク
    d. Architect
    i. AWS Lambda用のNode.js ヘルパー
    e. Sparta
    i. AWS Lambda用のGoフレームワーク
    f. Google Functions framework
    i. GCPのCloud FunctionsやCloud Runを開発するために使えるフレームワー
    ク
    5. 開発方法の変化
    

    View Slide

14. 14
    1. Frameworkの台頭
    a. Serverless Framework
    i. Cloud FunctionsやAWS Lambda、Azuru Functionsに限らず、クラウドプ
    ロバイダのServerless製品に対して使えるフレームワーク
    b. AWS SAM
    c. Chalice
    i. AWS Lambda用のPythonマイクロフレームワーク
    d. Architect
    i. AWS Lambda用のNode.js ヘルパー
    e. Sparta
    i. AWS Lambda用のGoフレームワーク
    f. Google Functions framework
    i. GCPのCloud FunctionsやCloud Runを開発するために使えるフレームワー
    ク
    5. 開発方法の変化
    より開発コストが小さくなっていく
    

    View Slide

15. 15
    2. サーバーレスの開発を支援するサービス。
    一気通貫にServerlessを使ったサービスを構築できる。
    a. Vercel
    b. dapr
    c. Nuawba
    d. Nimbellaなど
    5. 開発方法の変化
    Ref: https://nimbella.com/platform
    

    View Slide

16. 16
    ただのバックエンドだけでなく、サービスの開発ライクサイクルを支えつ
    CI/CDもサポートする。
    ● Cloud RunのTraffic Splitting, RevisionごとのURLなど
    ● AWS Lambda with AWS CodePipeline
    ● SpinnakerのCDプラットフォームの利用*
    6. CI/CDのサポート
    * Spinnakerを自分で拡張する必要があります
    90%
    10%
    v1
    v2
    

    View Slide

17. 17
    B. Serverlessに関連する製品のアップデート
    

    View Slide

18. 18
    Serveless製品はクラウドプロバイダ側のネットワーク空間にあるため、開発者のネットワーク空間にある
    データベースなどのリソースへアクセスするにはインターネットを介する必要がある。
    ● GCP Serverless VPC Access connector
    ● AWS VPC to VPC NATなど
    これらのリソースを使って 開発者の
    ネットワーク空間にあるリソースに
    プライベートアクセスをすることができる 。
    1. Private access
    

    View Slide

19. 19
    Serverless製品は既存の製品より制約が多く、機能不足なところもあって使いづらかった。
    しかし、徐々に機能やサポートが追加され、広く使えるようになっている
    ● GCP Serverless NEG
    ● AWS API Gateway with Lambda
    AWS WAF、GCP Cloud Armorなど
    サービスを構築するために欠かせない
    リソースがServerlessもサポートするように
    なった。
    2. ネットワークリソースの追加・改善
    Ref: Serverless NEGでシステム開発をより柔軟に
    

    View Slide

20. 20
    GCP Cloud WorkflowはYAMLによってワークフローを定義し、一連の処理を行うことができる。外部 API
    はもちろんのこと、Cloud RunなどのServerless製品を組み合わせることができる。
    3. ワークフロー定義サービス
    YAML
    Workflow
    

    View Slide

21. 21
    これらを取り入れることによって
    よりServerless製品を効率的に使うことができる
    

    View Slide

22. 22
    これらを取り入れることによって
    よりServerless製品を効率的に使うことができる
    時々刻々と進化するServerless技術に合わせて
    サービスのアーキテクチャなどを構築しないといけない
    

    View Slide

23. 23
    All Serverlessでサービスを構築する苦労
    

    View Slide

24. 24
    開発・運用しているAll Serverlessサービス
    Wi-Fi Attendance System
    Wi-Fiによる勤怠打刻システム
    

    View Slide

25. 25
    メルカリの全国のオフィスで使われているすべて Serverlessでできている打刻システム。
    新型コロナウィルスの影響もあって、ほぼ全社員が毎日使っている。
    WIASとは
    

    View Slide

26. 26
    イベント数には特徴があり、出退勤と相関がある。
    Serverlessと相性が良く、コストも非常に抑えられている。
    WIASとは
    PubSubのメッセージ数 請求額
    

    View Slide

27. 27
    SlackのSlush commandのバックエンドとして Cloud FunctionsやCloud Runを採用。
    3000ms以内にレスポンスを返さなければタイムアウトしエラーになる。
    1. Cold Startによるタイムアウト問題
    3000ms以内
    

    View Slide

28. 28
    SlackのSlush commandのバックエンドとして Cloud FunctionsやCloud Runを採用。
    3000ms以内にレスポンスを返さなければタイムアウトしエラーになる。
    Cold Startだけでも苦しいが、データベース接続や認証を挟むともっと厳しい。
    1. Cold Startによるタイムアウト問題
    3000ms以内
    

    View Slide

29. 29
    1. Cold Startによるタイムアウト解決方法
    ● Node.jsランタイムの採用、常に最新 Runtimeにアップデートしておく (Cloud Functionsだと
    Node.js 12(Beta)など)
    ● Slackのバックエンドリージョン近くへデプロイ
    ● 必要最低限だけの処理を行い、早めにレスポンスを返したあとに後続の処理を行う。 (=実行時間を減
    らす)
    Serverless製品を使わずCold Startがないとしてもタイムアウトは気にしないといけないのでとりわけ特別
    ではないが、Serverlessはもっとシビアなので要注意する必要がある。
    

    View Slide

30. 30
    Serverless製品はで、開発者が使用しているネットワークへアクセスすることは難しく、その特性から IP固
    定化をするのが難しい。
    2. Internetを介したアクセスを強いられるケースがある
    My project
    外部リソース
    IP???
    
    

    View Slide

31. 31
    Serverless製品はで、開発者が使用しているネットワークへアクセスすることは難しく、その特性から IP固
    定化をするのが難しい。
    2. Internetを介したアクセスを強いられるケースがある
    My project
    外部リソース
    IP???
    
    

    View Slide

32. 32
    2. Serverless VPC Access connectorによるPrivate
    Access
    Serverless VPC Access connectorによってCloud SQLやGCEなどのリソースにPrivate IPを使ってア
    クセスをすることができて、 Cloud NATなどによってIPを固定化できる。
    GCEがネットワーク内のCloud SQLなどにアクセスするような感じで同様に Serverless製品(Cloud
    FunctionsやCloud Run)からアクセスをすることができる。
    Serverless製品のこのようなネットワーク問題は GCPに限らずAWSなどでも同様になり、改めて意識をし
    ないといけない。
    外部リソース
    
    

    View Slide

33. 33
    Cloud Functionsなどはカナリアなどをサポートしていないので、リスクの高いデプロイをしていた。
    3 リスクの高いデプロイ
    V1
    

    View Slide

34. 34
    Cloud Functionsなどはカナリアなどをサポートしていないので、リスクの高いデプロイをしていた。 デプロ
    イに失敗するとサービスが落ちてしまう
    3 リスクの高いデプロイ
    V2
    ❌
    

    View Slide

35. 35
    Cloud Functionsなどはカナリアなどをサポートしていないので、リスクの高いデプロイをしていた。 デプロ
    イに失敗するとサービスが落ちてしまう
    3 Serverless NEG
    90%
    10%
    

    View Slide

36. 36
    Serverless製品はFaaSなどを代表に、小さなコンポーネントで構築されているため一つ一つの管理が難し
    くなる。一つ一つの要素が大きくなれば Cold Startが悪化する。
    それぞれのRepositoryを作ると大変なことになる。
    Project
    ● service-A/
    ● service-B/
    ● …
    ● service-N/
    4. 小さなコンポーネントが大量にできる
    それぞれで
    CI/CDしたい！
    

    View Slide

37. 37
    4. Monorepoで管理しGitHub ActionsでCI/CD
    GitHub
    Registry
    service-A/
    service-D/
    Developer
    CircleCIを使っていたが「特定のディレクトリ以下で変更されたら XXX」のようなモノレポ用途だと難しく、
    GitHub ActionsはPathを指定することができるため GitHub Actionsに全移行。
    

    View Slide

38. 38
    4. Monorepoで管理しGitHub ActionsでCI/CD
    CircleCIを使っていたが「特定のディレクトリ以下で変更されたら XXX」のようなモノレポ用途だと難しく、
    GitHub ActionsはPathを指定することができるため GitHub Actionsに全移行。
    

    View Slide

39. 39
    Wrap up
    Serverlessを取り巻く現状(Saasのプロダクトなど)は日々、変化している。
    それに伴って、Serverlessアーキテクチャは変化をしてきている。
    実際にAll Serverlessでサービスを運用していると色んな苦労がある
    :
    ● どうしても伴うCold Startの対策
    ● Serverlessではないプロダクト(GCPでいうとGCE, GKEなど)に対して機能不足の補填
    ● 小さなコードの管理など
    Servelessの特徴と上手く活かす、かつ、
    Serverlessの変化を取り込みやすいアーキテクチャにするとより
    Serverlessの恩恵を受けることができる。
    

    

    

    

    View Slide

40. 40
    Thank you!
    

    View Slide