ServerlessDays 20230923

サーバーレスな開発ライフサイクルの モメンタムの変遷 （吉田真吾） + 秋のサーバレス運動会 （亀田治伸） Cloudflare Japan株式会社 エバンジェリスト 亀田 治伸

Our Vision 安全性、信頼性 と パフォーマンス、高速性 の両立 To help build a better internet 1,260 95 億 % 50ミリ秒圏内に世界のインター ネットユーザーの95%が存在 100 % アップタイム SLA 1日あたりの サイバー脅威ブロック数 世界のインターネットトラフィック全体の ~25% を支えるCloudflare

Global Network Footprint 300 都市以上 100か国以上 500 Pops 10 PoPs 日本国内に存在する Point of Presence 12,500 以上 の ISP、クラウドプロバイダー、 大企業を含むネットワークと グローバルに相互接続 209Tbps のネットワーク容量は、 さらに拡大中

Developer Platform

Developer Platform Workers Compute サーバレスなエッジ コンピューティング Chromium v8ベース Durable Objects KV R2 Storage D1 CDN Load DNS Balancing Network Pages Wrangler Developer Experience 永続ストレージ グローバルネットワーク ホスティングと開発環境 Durable Objets: Object KV: Key Value R2: S3互換Object D1:SQL Lite WAFやDDoS対策など Pages: JAMstack Hosting Wrangler: 開発用CLI

Workersの特徴 300都市以上の Edgeにデプロイ 通信料の課金なし シンプルな価格帯 デプロイは数秒 コールドスタート無し 汎用的な 実行エンジン

AWS Lambdaとの違い Region / VPCが存在しない Cloudflareのほぼ全てが同じ Node.js サポートは限定的 Nodeモジュールはポリフィルで読み込み可能（容量に注意） AsyncLocalStorage, EventEmitter, Buffer, assert, util, Crypto Diagnostics Channel, path, process, Streams, String Decoder のみサポート Service Workers + Web Workres ベースでJavaScriptを実行 Node.js ≠ Server Side JavaScript 、非同期処理を可能とする Service Workers Web Workers = ページに対するプロキシとして通信に割込みが可能 = マルチスレッドによる並列処理

AWS Lambdaとの違い Region / VPCが存在しない Cloudflareのほぼ全てが同じ Node.js サポートは限定的 Nodeモジュールはポリフィルで読み込み可能（容量に注意） AsyncLocalStorage, EventEmitter, Buffer, assert, util, Crypto Diagnostics Channel, path, process, Streams, String Decoder のみサポート Service Workers + Web Workres ベースでJavaScriptを実行 Node.js ≠ Server Side JavaScript 、非同期処理を可能とする Service Workers Web Workers = ページに対するプロキシとして通信に割込みが可能 = マルチスレッドによる並列処理

Event Trigger
export default { HTTP/Fetch
async fetch(request, env, ctx) {
return new Response('Hello World!');
},
};
export default { Cron
async scheduled(event, env, ctx) {
ctx.waitUntil(doSomeTaskOnASchedule());
},
};
export default { Queue
async queue(
batch: MessageBatch, env: Environment,
ctx: ExecutionContext
): Promise<void> {
for (const message of batch.messages) {
console.log('Received', message);
}
},
};

export default { Alarm
async fetch(request, env) {
let id = env.BATCHER.idFromName("foo");
return await
env.BATCHER.get(id).fetch(request);
},
};
export default { Email
async email(message, env, ctx) {
if (allowList.indexOf(message.from) == -1) {
message.setReject("Address not allowed");
} else {
await message.forward("inbox@corp");
}
}
}

Workers Connect () OutboundのTCPソケット通信が可能に（従来はHTTP のみ）(QUIC未対応） SSH, MQTT, SMTP, FTP, IRC, SQL 等 Pgに対応済、mysql, mysql2は開発中 mTLS, StartTLS, RTT-0に対応 インバウンドTCP,UDP, アウトバウンドUDPは開発中

Cloudflare Workers Smart Placement

Cloudflare Workers Write Code. Deploy. Done. Modern Developer Ecosystem Cost efficient JavaScriptに加えてWeb Assemblyをサポート Rust、Python、Scala、Reason、FSharp、Dart、Kotlin、COBOL、Perl、PHP、C++ Go、C＃/NET、Haxe、Java、Kotlin、TypeScript、Elixir 等 Chromium V8エンジンを使用

秋の Serverless 運動会

秋の Serverless 運動会

秋の Serverless 運動会 １から１億まで足しこむと一番早いのは？その理由は？ (Request + Responseの時間を含む） Cloudflare Workers JavaScript Cloudflare Workers Rust (WASM) AWS Lambda Node.js w/ Cold Start w/HTTP URL AWS Lambda Node.js w/o Cold Start w/HTTP URL Amazon CloudFront Lambda@Edge w/ Cold Start Amazon CloudFront Lambda@Edge w/o Cold Start Amazon CloudFront Functions

秋の Serverless 運動会 １から１億まで足しこむと一番早いのは？その理由は？ (Request + Responseの時間を含む） Cloudflare Workers JavaScript Cloudflare Workers Rust (WASM) 601 ms 196 ms AWS Lambda Node.js w/ Cold Start w/HTTP URL AWS Lambda Node.js w/o Cold Start w/HTTP URL 2.43 s 997 ms Amazon CloudFront Lambda@Edge w/ Cold Start Amazon CloudFront Lambda@Edge w/o Cold Start 2.12 s 215 ms Amazon CloudFront Functions Limit Exceeded

秋の Serverless 運動会 １から１億まで足しこむと一番早いのは？その理由は？ (Request + Responseの時間を含む） Cloudflare Workers JavaScript Cloudflare Workers Rust (WASM) 601 ms 196 ms AWS Lambda Node.js w/ Cold Start w/HTTP URL AWS Lambda Node.js w/o Cold Start w/HTTP URL 2.43 s 997 ms Amazon CloudFront Lambda@Edge w/ Cold Start Amazon CloudFront Lambda@Edge w/o Cold Start 2.12 s 215 ms Amazon CloudFront Functions Limit Exceeded

秋の Serverless 運動会 １から１億まで足しこむと一番早いのは？その理由は？ (Request + Responseの時間を含む） Cloudflare Workers JavaScript Cloudflare Workers Rust (WASM) 601 ms 196 ms AWS Lambda Node.js w/ Cold Start w/HTTP URL AWS Lambda Node.js w/o Cold Start w/HTTP URL 2.43 s 997 ms Amazon CloudFront Lambda@Edge w/ Cold Start Amazon CloudFront Lambda@Edge w/o Cold Start 2.12 s 215 ms Amazon CloudFront Functions Limit Exceeded Amazon CloudFront Lambda@Edge after 2nd execution 36.6 ms

Storage オプション Workers KV Durable Objects R2 D1 (open alpha) Key Value型 結果整合性モデル ほかのエッジからのレイテンシ あり オブジェクトストレージ 最初にR2が作成アクセスされた リージョンにストレージが作成 （リージョン選択不可） ほかのエッジからのレイテンシあ り Objectは世界中に分散 Objectはリージョンに集約 オブジェクトストレージ 一番最初にアクセスされた エッジにオブジェクトが作成 SQL Lite Durable Objects上で動作 マルチマスター バックアップはR2 （ローカルも可） 19

Storage オプション Workers KV Durable Objects R2 D1 (open alpha) Key Value型 結果整合性モデル ほかのエッジからのレイテンシ あり オブジェクトストレージ 最初にR2が作成アクセスされた リージョンにストレージが作成 （リージョン選択不可） ほかのエッジからのレイテンシあ り Objectは世界中に分散 Objectはリージョンに集約 オブジェクトストレージ 一番最初にアクセスされた エッジにオブジェクトが作成 SQL Lite Durable Objects上で動作 マルチマスター バックアップはR2 （ローカルも可） 20

Cloudflare Pages ⚫ CI/CDの自動化： ビルドコマンドを選択してデプロイすれば、 実行・運用は自動化 ⚫ 無限に広がるステージング: すべてのブランチにステージング環境を提供 ⚫ 保護されたプレビューリンク: コミットごとに生成されるURLで、 コラボレーション用に共有可能、 Cloudflare Access(ZTNA)によって保護

Workers + Pages Pages Functions 概要：Server-Side Rendering (SSR) の実現 理由：プロジェクトにダイナミックな機能と バックエンドロジックを簡単に追加できる How:プロジェクト内の functionsディレクトリがWorkers実行環境 静的アセットと一緒にFunctionsをデプロイ

Pages Functions Workers でできるこ となら何でも REST APIの構築 A/Bテストの実施 サードパーティとの連携 認証の追加 支払い処理 デベロッパープラットフォーム 製品との連携 Workers KV Durable Object R2 D1 3rd Party data source フルスタックフレームワーク との連携 Next.js、Remix、SvelteKit、 Nuxt、Astro、Qwik サーバーサイドレンダリング を追加

Next.js Edge Runtime Vercel の Edge Runtime モードはWorkres上で動作 それ以外はAWS上で動作 個人的にはNext.jsを 使うならVercelおススメ

Workers はデフォルト毎回実行 export async function getServerSideProps() { // Fetch data from external API const res = await fetch(`https://.../data`) const data = await res.json() // Pass data to the page via props return { props: { data } } 仕様通り実行 SSR } export async function getStaticProps() { // Call an external API endpoint to get posts const res = await fetch('https://.../posts') const posts = await res.json() // By returning { props: { posts } }, the Blog component // will receive `posts` as a prop at build time return { props: {posts,},} } 毎回実行 SSGやISRは Cache APIを使う

Why Edge Computing ? 1 イノベーションのジレンマ Enterpriseグレード機能の具備 開発体験の低下, 多くのServerlessベンダーが通る道、先人から学ぶ 2 CDNの進化とプログラム実行機能の解放 CDNはWebの高速化ツールから進化を続ける 3 通信プロトコルの進化と取り残されるオリジン Cloudを使っても、オリジンは取り残されるパターン

Why Edge Computing ? 1 イノベーションのジレンマ Enterpriseグレード機能の具備 開発体験の低下, 多くのServerlessベンダーが通る道、先人から学ぶ 2 CDNの進化のプログラム実行機能の解放 CDNはWebの高速化ツールから進化を続ける 3 通信プロトコルの進化と取り残されるオリジン Cloudを使っても、オリジンは取り残されるパターン

You Build, You Run it © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.

AWS Services Event Databases Lambda Function Etc.

2014 対応イベントソース Amazon S3 Amazon Kinesis Amazon DynamoDB AWS Services Event Up to; 1GB Memory, 256 threads 5 分 最大実行時間 25 同時実行 Databases Lambda Function Etc. VPC へのアクセスも未対応 Amazon API Gateway Amazon Event Bridge はサービスそのものがなかった

Heavy Cold Start しばらくの間

Lambda function boundary Function, layer code Function, layer code Function, layer code Function, layer code Lambda runtime Lambda runtime Lambda runtime Lambda runtime Container Isolation Container Isolation Container Isolation Container Isolation Micro VM Host OS Lambda worker EC2 Instances AWS account boundary 専用 EC2, 費用請求なし

Nitro System Firecracker

過去 and 現在 Lambda function boundary Function, layer code Function, layer code Function, layer code Function, layer code Lambda Runtime Lambda Runtime Lambda Runtime Lambda Runtime MicroVM MicroVM MicroVM MicroVN Firecracker Firecracker Firecraker Firecracker Light Host OS + KVM Lambda worker EC2 Bare metal Instances AWS account boundary

VPC / Database アクセスへの苦難の道 Lambda Resources inside VPC

Relational Database は常に VPC の中 Corporate data center AWS Cloud リージョン インターネット Availability Zone VPC Private Subnet Public Subnet Amazon EC2 Direct Connect ? ? Amazon RDS Internet gateway

Lambda 関数はどこ ? Corporate data center AWS Cloud リージョン インターネット Availability Zone VPC Private Subnet Public Subnet Amazon EC2 Direct Connect ? ? Amazon RDS Internet gateway

Lambda (隠れた) VPC. Released at February 2016 Lambda Service VPC Your VPC Execution Environments Lambda function Same VPC Config Your Subnet Execution Environments Elastic Network Interfaces Cold Start 数十秒 Different VPC Config Execution Environments Lambda service API

VPC Sharing for multiple AWS accounts AWS Organization Account A (VPC owner) Shared VPC Public subnet Account B (VPC participant) Account C (VPC participant) Internet gateway NAT gateway Private subnet (shared) Instance Instance Virtual private gateway AWS Resource Access Manager Instance

AWS Hyperplane and V2N (VPC to VPC NAT) AWS Organization Account A (VPC owner) Shared VPC Public subnet Internet gateway NAT gateway Private subnet (shared) Instance Account B (VPC participant) Account C (VPC participant) VPC共有は2018年11月に発表 各ネットワークコンポーネントが高度に仮想化されたことで実現 Hyperplane はAWS内部でもう一度 ネットワークオブジェクトを仮想化。長期の Keep Alive を実現 EFS NAT GW NLB Private Transit Link GW Instance Virtual private gateway AWS Resource Access Manager Cloud WAN Lambda And more VPC Instance

V2N (VPC to VPC NAT) Lambda Service VPC Hyperplane Your VPC Warm pool of ENI Virtualized ENI Your Subnet Execution Environments Lambda function Same VPC Config Execution Environments Elastic Network Interfaces V2N (VPC to VPC NAT) Lambda service API Virtualized ENI Different VPC Config Released at September 2019 Execution Environments

3 つの起動タイプ event response event internal queue Synchronous Asynchronous 呼び出し元が、 リアルタイムの レスポンスを期待 呼び出し元が レスポンスを 必要としない Event Source Mapping 呼び出しの 制御が必要な場合 Synchronous under the hood.

AWS Lambda under the hood and more Event Source Mapping Sync or and more Async Frontend AWS Lambda Workers Internal queue microVM microVM Execution Environment Execution Environment microVM microVM Execution Environment Execution Environment

Why Edge Computing ? 1 イノベーションへのジレンマ Entepriseグレード機能の具備 開発体験の低下, 多くのServerlessベンダーが通る道、先人から学ぶ 2 CDNの進化とプログラム実行機能の解放 CDNはWebの高速化ツールから進化を続ける 3 通信プロトコルの進化と取り残されるオリジン Cloudを使っても、オリジンは取り残されるパターン

How CDN evolved ?

SSL / TLS 脆弱性の歴史 1995年 SSL2.0誕生 2006年 TLS1.1誕生 2014年4月 Heartbleed脆弱性 2013年 TLS1.3検討開始 Web通信暗号化技術の進化 1996年 SSL3.0誕生 2008年 TLS1.2誕生 1999年 TLS1.0誕生 2016年3月 DROWN脆弱性 2015年 FREAK脆弱性 脆弱性との戦い 2011年 BEAST脆弱性 2014年9月 POODLE脆弱性

Cloudflare サービス群 Cloudflare Platform 1 Cloudflare One Cloudflare Zero Trust Services Cloudflare Network Services Cloudflare Application Services Zero Trust Network Access WAN-as-a-Service WAF with API Protection Secure Web Gateway Firewall-as-a-Service Rate Limiting Cloud Access Security Broker L3 & L4 DDoS Protection Load Balancing Cloud Email Security Network Interconnect Bot Management Remote Browser Isolation Smart Routing L7 DDoS Protection Data Loss Prevention IDS/IPS CDN and DNS Cloudflare Edge Developer Platform Workers Cloudflare Global Network Compliance/Privacy: FedRAMP, ISO, SOC, PCI, GDPR compliant, Logs & Analytics, Data Localization Suite Pages R2 Workers KV Durable Objects Images Stream

Turnstile Apple Private Access Tokens Google Picasso ・IPアドレス等を隠匿した匿名トークン ・iOS16 / Venturaから対応 ・１年の有効期間

Why Edge Computing ? 1 イノベーションへのジレンマ Entepriseグレード機能の具備 開発体験の低下, 多くのServerlessベンダーが通る道、先人から学ぶ 2 CDNの進化のプログラム実行機能の解放 CDNはWebの高速化ツールから進化を続ける 3 通信プロトコルの進化と取り残されるオリジン Cloudを使っても、オリジンは取り残されるパターン

Internet 最新規格への Journey IPv4 → IPv6 HTTP2/TCP → HTTP3/QUIC

TCP と UDP の違い TCP UDP Server Client Server Client HTT3 QUIC HTTP1.1 HTTP2

IPv4 → IPv6 50.9% HTTP2/TCP → HTTP3/QUIC 38.7%

IPv4 → IPv6 Mobile 50.9% HTTP2/TCP → HTTP3/QUIC 38.7% Gateway Origin PC ISPs

IPv4 → IPv6 50.9% HTTP2/TCP → HTTP3/QUIC 38.7% Latest Mobile Gateway Origin PC ISPs Mixed Legacy

What’s next

ありがとうございました