$30 off During Our Annual Pro Sale. View Details »

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

Keke
August 14, 2020

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

CloudNative Days Tokyo 2020

Keke

August 14, 2020
Tweet

More Decks by Keke

Other Decks in Technology

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