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
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...
3. 3 後ほど資料は公開します！
4. 4 Agenda
5. 5 Agenda 01 • Serverlessを取り巻く現状 02 03 • All Serverlessでサービスを構築する苦労 • Wrap up
6. 6 Serverlessを取り巻く現状
7. 7 Serverlessを取り巻く現状は大きく2つの観点から進化している。 A. Serverless製品自体 Google Cloud Platfrom(GCP)やAmazon Web Service(AWS)が提供してい る製品のアップデート・追加されたもの B. Serverlessに関連する機能 直接的ではないが、間接的にServerlessに対して機能が追加・改善されたりされた もの Serverlessを取り巻く現状
8. 8 A. Serverless製品自体の進化
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/
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/
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/ 新しいプラットフォームが出てくるかも
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. イベントソースの多様化 更新を通知 よりいろんなイベントでトリガーできるようになるかも
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. 開発方法の変化
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. 開発方法の変化 より開発コストが小さくなっていく
15. 15 2. サーバーレスの開発を支援するサービス。 一気通貫にServerlessを使ったサービスを構築できる。 a. Vercel b. dapr c. Nuawba d. Nimbellaなど 5. 開発方法の変化 Ref: https://nimbella.com/platform
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
17. 17 B. Serverlessに関連する製品のアップデート
18. 18 Serveless製品はクラウドプロバイダ側のネットワーク空間にあるため、開発者のネットワーク空間にある データベースなどのリソースへアクセスするにはインターネットを介する必要がある。 • GCP Serverless VPC Access connector • AWS VPC to VPC NATなど これらのリソースを使って 開発者の ネットワーク空間にあるリソースに プライベートアクセスをすることができる 。 1. Private access
19. 19 Serverless製品は既存の製品より制約が多く、機能不足なところもあって使いづらかった。 しかし、徐々に機能やサポートが追加され、広く使えるようになっている • GCP Serverless NEG • AWS API Gateway with Lambda AWS WAF、GCP Cloud Armorなど サービスを構築するために欠かせない リソースがServerlessもサポートするように なった。 2. ネットワークリソースの追加・改善 Ref: Serverless NEGでシステム開発をより柔軟に
20. 20 GCP Cloud WorkflowはYAMLによってワークフローを定義し、一連の処理を行うことができる。外部 API はもちろんのこと、Cloud RunなどのServerless製品を組み合わせることができる。 3. ワークフロー定義サービス YAML Workflow
21. 21 これらを取り入れることによって よりServerless製品を効率的に使うことができる
22. 22 これらを取り入れることによって よりServerless製品を効率的に使うことができる 時々刻々と進化するServerless技術に合わせて サービスのアーキテクチャなどを構築しないといけない
23. 23 All Serverlessでサービスを構築する苦労
24. 24 開発・運用しているAll Serverlessサービス Wi-Fi Attendance System Wi-Fiによる勤怠打刻システム
25. 25 メルカリの全国のオフィスで使われているすべて Serverlessでできている打刻システム。 新型コロナウィルスの影響もあって、ほぼ全社員が毎日使っている。 WIASとは
26. 26 イベント数には特徴があり、出退勤と相関がある。 Serverlessと相性が良く、コストも非常に抑えられている。 WIASとは PubSubのメッセージ数 請求額
27. 27 SlackのSlush commandのバックエンドとして Cloud FunctionsやCloud Runを採用。 3000ms以内にレスポンスを返さなければタイムアウトしエラーになる。 1. Cold Startによるタイムアウト問題 3000ms以内
28. 28 SlackのSlush commandのバックエンドとして Cloud FunctionsやCloud Runを採用。 3000ms以内にレスポンスを返さなければタイムアウトしエラーになる。 Cold Startだけでも苦しいが、データベース接続や認証を挟むともっと厳しい。 1. Cold Startによるタイムアウト問題 3000ms以内
29. 29 1. Cold Startによるタイムアウト解決方法 • Node.jsランタイムの採用、常に最新 Runtimeにアップデートしておく (Cloud Functionsだと Node.js 12(Beta)など) • Slackのバックエンドリージョン近くへデプロイ • 必要最低限だけの処理を行い、早めにレスポンスを返したあとに後続の処理を行う。 (=実行時間を減 らす) Serverless製品を使わずCold Startがないとしてもタイムアウトは気にしないといけないのでとりわけ特別 ではないが、Serverlessはもっとシビアなので要注意する必要がある。
30. 30 Serverless製品はで、開発者が使用しているネットワークへアクセスすることは難しく、その特性から IP固 定化をするのが難しい。 2. Internetを介したアクセスを強いられるケースがある My project 外部リソース IP???
31. 31 Serverless製品はで、開発者が使用しているネットワークへアクセスすることは難しく、その特性から IP固 定化をするのが難しい。 2. Internetを介したアクセスを強いられるケースがある My project 外部リソース IP???
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などでも同様になり、改めて意識をし ないといけない。 外部リソース
33. 33 Cloud Functionsなどはカナリアなどをサポートしていないので、リスクの高いデプロイをしていた。 3 リスクの高いデプロイ V1
34. 34 Cloud Functionsなどはカナリアなどをサポートしていないので、リスクの高いデプロイをしていた。 デプロ イに失敗するとサービスが落ちてしまう 3 リスクの高いデプロイ V2 ❌
35. 35 Cloud Functionsなどはカナリアなどをサポートしていないので、リスクの高いデプロイをしていた。 デプロ イに失敗するとサービスが落ちてしまう 3 Serverless NEG 90% 10%
36. 36 Serverless製品はFaaSなどを代表に、小さなコンポーネントで構築されているため一つ一つの管理が難し くなる。一つ一つの要素が大きくなれば Cold Startが悪化する。 それぞれのRepositoryを作ると大変なことになる。 Project • service-A/ • service-B/ • … • service-N/ 4. 小さなコンポーネントが大量にできる それぞれで CI/CDしたい！
37. 37 4. Monorepoで管理しGitHub ActionsでCI/CD GitHub Registry service-A/ service-D/ Developer CircleCIを使っていたが「特定のディレクトリ以下で変更されたら XXX」のようなモノレポ用途だと難しく、 GitHub ActionsはPathを指定することができるため GitHub Actionsに全移行。
38. 38 4. Monorepoで管理しGitHub ActionsでCI/CD CircleCIを使っていたが「特定のディレクトリ以下で変更されたら XXX」のようなモノレポ用途だと難しく、 GitHub ActionsはPathを指定することができるため GitHub Actionsに全移行。
39. 39 Wrap up Serverlessを取り巻く現状(Saasのプロダクトなど)は日々、変化している。 それに伴って、Serverlessアーキテクチャは変化をしてきている。 実際にAll Serverlessでサービスを運用していると色んな苦労がある : • どうしても伴うCold Startの対策 • Serverlessではないプロダクト(GCPでいうとGCE, GKEなど)に対して機能不足の補填 • 小さなコードの管理など Servelessの特徴と上手く活かす、かつ、 Serverlessの変化を取り込みやすいアーキテクチャにするとより Serverlessの恩恵を受けることができる。 
 
 

40. 40 Thank you!