Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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...

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

4 Agenda

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

6 Serverlessを取り巻く現状

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

8 A. Serverless製品自体の進化

Slide 9

Slide 9 text

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/

Slide 10

Slide 10 text

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/

Slide 11

Slide 11 text

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/ 新しいプラットフォームが出てくるかも

Slide 12

Slide 12 text

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. イベントソースの多様化 更新を通知 よりいろんなイベントでトリガーできるようになるかも

Slide 13

Slide 13 text

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. 開発方法の変化

Slide 14

Slide 14 text

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. 開発方法の変化 より開発コストが小さくなっていく

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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などでも同様になり、改めて意識をし ないといけない。 外部リソース

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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


Slide 40

Slide 40 text

40 Thank you!