Everything will be SERVERLESS — 信じて運用した10年の経験値 / Everything Will be Serverless — Lessons Learned from 10 Years of Operational Experience

by shiro seike

Embed

Start on current slide

Slide 1

Slide 1 text

OSEKKAI × TECHNOLOGY Everything will be SERVERLESS 〜信じて運用した10年の経験値〜 ServerlessDays Tokyo 2026 2026-09-19 株式会社Fusic / 技術コミュニティ統括室長 / シニアエバンジェリスト清家史郎 (@seike460)

Slide 2

Slide 2 text

自己紹介 OSEKKAI × TECHNOLOG Y 清家史郎 (@seike460) SHIRO SEIKE 技術コミュニティ統括室長 / シニアエバンジェリスト・2026 Japan AWS Ambassador ・AWS Community Builder (Serverless) ・Japan AWS Top Engineers 2025・2026 — コミュニティ・JAWS-UG Fukuoka Co-Organizer / JAWS DAYS 2026 実行委員長・ServerlessDays Fukuoka 2019 実行委員長・ServerlessDays Tokyo（2019 スタッフ / 2022–2026 運営） 2 ©Fusic Co., Ltd.

Slide 3

Slide 3 text

1 2016–2022：衝撃と言葉、そして結果受け取る 3 ©Fusic Co., Ltd.

Slide 4

Slide 4 text

初めてのAWS案件で、上司の提案からLambdaを選んだ上司の提案 AWS LambdaでServerlessで組めばいいじゃんインフラの管理 Fusicに入社前々職・前職 2016年6月・初めてのAWS案件 Lambdaを採用サーバー管理なしでコードを実行学び：選択は、誰かの一言で始まる 4 ©Fusic Co., Ltd.

Slide 5

Slide 5 text

ワークショップ優勝の翌日、洗礼のような衝撃を受けた浮かれた自分への洗礼 ServerlessConf Tokyo 2018 ワークショップで優勝し、浮かれた翌日規模も視点も違う構成を見た 5 ©Fusic Co., Ltd.

Slide 6

Slide 6 text

2018年に相談し、翌年ServerlessDays Fukuokaを開催した ServerlessDays Fukuoka 2019 を開催した 2018年の懇親会で、福岡開催を相談した Tokyo 2019はスタッフとして参加した日本初の地方開催の実行委員長声をかけた翌年、私は実行委員長だった 6 ©Fusic Co., Ltd.

Slide 7

Slide 7 text

2019年、福岡でこの言葉を受け取った「 Everything will be Serverless 」 — 西谷圭介 ServerlessDays Fukuoka 2019 基調講演 7 ©Fusic Co., Ltd.

Slide 8

Slide 8 text

僕の最初のLambda APIは、リクエスト数約73倍でも保守者は1人だった上司の提案で選んだ、あのAPIのその後月間リクエスト数の増加約 73 倍 21,172件（当初）→ 1,543,602件（2022年時点）保守する人 1 人増加後も、担当者は同じ 8 ©Fusic Co., Ltd.

Slide 9

Slide 9 text

2 2019：自作を捨て、コミュニティに頼る頼る 9 ©Fusic Co., Ltd.

Slide 10

Slide 10 text

JAWS DAYS 2019で、複数案件を監視するFictionBaseを紹介した agent / monitor API Gateway CloudWatch SQS Lambda router DynamoDB S3 Slack 通知Lambda JAWS DAYS 2019 の登壇で発表した構成を再現 10 ©Fusic Co., Ltd.

Slide 11

Slide 11 text

JAWS DAYS 2019で、自作のYAMLをOSSの設定に置き換えた JAWS DAYS 2019のFictionBaseより。API GatewayとSQSの接続設定を、自作のYAMLからコミュニティのプラグインへ置き換えの設定例 # plugin README SQS custom: apiGatewayServiceProxies: - sqs: path: /sqs method: post queueName: {'Fn::GetAtt': ['SQSQueue', 'QueueName']} cors: true resources: Resources: SQSQueue: Type: 'AWS::SQS::Queue' 11 ©Fusic Co., Ltd.

Slide 12

Slide 12 text

3 2021：常時起動をやめるやめる 12 ©Fusic Co., Ltd.

Slide 13

Slide 13 text

AWS DevDay 2021で紹介した検索環境は、維持する対象が多かった ALB React + Amplify Fargate / Go API Amazon RDS 検索データ解析実⾏中間データ維持していた対象: ALB・Fargate・RDS ＋ Goコード・コンテナの保守 Step Functions AWS Batch S3 / 13 ©Fusic Co., Ltd.

Slide 14

Slide 14 text

同僚の登壇を聞き、S3 Selectを検討し始めた知っていた登壇を聞いた S3 Selectの存在 JAWS DAYS 2020 同僚の内田さん実データで検証 S3 Select＝S3上のデータをSQLで絞り込む機能登壇テーマ「サーバーレスの新しいデータストアの選択肢 S3 Selectの魅力」学び：存在を知っていたことと、自分の設計で使えることは別 14 ©Fusic Co., Ltd.

Slide 15

Slide 15 text

1レコード1MBの制約を確認し、Fargate環境を廃止した変更前 Fargate 変更後：AppSync + Lambda RDS 常時起動の費用 Go・コンテナ・ECRの管理 AppSync 廃止 DynamoDB Lambda (Go) S3 Select React・Amplifyの画面を継続解析用のStep Functions・Batchも継続 1レコード1MB以内（S3 Select上限）結果整合性で十分（多少の遅延は許容）データ件数の急増はない 2021年の事例。S3 Selectは現在、新規利用不可。AppSync＝GraphQLのマネージドサービス 15 ©Fusic Co., Ltd.

Slide 16

Slide 16 text

型は移行の前後で引き継げる AWS DevDay 2021の移行より。API.graphqlの戻り値に型を指定し、従来の型（OpenAPI Generator製）をそのまま使った async function fetchBlogRequest(id: string) { const getBlogVal: GetBlogQueryVariables = { id, } let res = (await API.graphql( graphqlOperation(getBlog, getBlogVal) )) as GraphQLResult setBlog(res.data?.getBlog as Blog) } 16 ©Fusic Co., Ltd.

Slide 17

Slide 17 text

保守対象を減らし、画面の型は引き継いだ AWS DevDay 2021 のまとめ保守対象を減らす画面の型は維持する取得・登録処理の変更箇所は明確。従来と同じ型に合わせて置き換えた学び：サーバーレスはブロックで組む。合わなくなったブロックは替えられる 17 ©Fusic Co., Ltd.

Slide 18

Slide 18 text

4 2022–2023：元アプリとの境界を引く引く 18 ©Fusic Co., Ltd.

Slide 19

Slide 19 text

AWS DevDay 2022で、元アプリのRDSへ直接接続しないサブサイトを紹介した元アプリのRDSへ直接接続する場合（見送った案）元アプリ安定運用中サブサイト新たな検索アクセス RDS 負荷試験・スケール計画済み元アプリの運用者の再検証・調整を増やさない 19 ©Fusic Co., Ltd.

Slide 20

Slide 20 text

元アプリのRDSから、サブサイトの読み取りを切り離した元アプリアカウントレプリカ RDS サブサイトアカウントブラウザ CloudFront S3 / 静的配信 S3 Select Fargate JSON ⽣成 API Gateway Lambda S3 (JSON) を配置 JSON 2022年の事例。S3 Selectは現在、新規利用不可 20 ©Fusic Co., Ltd.

Slide 21

Slide 21 text

PHPからS3 SelectにSQLを送り、検索した 2022年の事例。S3 Selectは現在、新規利用不可 $result = $this->s3Client->selectObjectContent([ 'Bucket' => $this->getBucket(), 'Key' => $this->getKey(), 'ExpressionType' => 'SQL', 'Expression' => "SELECT {$this->getField()} FROM …", 'InputSerialization' => [ 'JSON' => ['Type' => 'Document'], ], 'OutputSerialization' => [ 'JSON' => ['RecordDelimiter' => ','], ], ]); このLambdaはPHPで書き、Bref（PHPをLambdaで動かすOSS）で実行した 21 ©Fusic Co., Ltd.

Slide 22

Slide 22 text

必要な更新頻度を確認し、30分間隔で合意した 30 分ごとの更新で合意 JSONを更新更新間隔 30分次の更新必要な更新頻度を顧客に確認し、定期的なデータ生成を採用した 22 ©Fusic Co., Ltd.

Slide 23

Slide 23 text

サブサイト側で、処理できるリクエスト数を測った 2022年の負荷試験：GET・100クライアント・20万リクエスト GET 約 600 POSTの測定結果（別条件） RPS 次に、同じGETの試験でキャッシュ追加の効果を確認約1,100 RPS データ量はGETの1/10 GETとは条件の異なる測定値 RPS＝毎秒のリクエスト数。別条件でも計測（500クライアント・2,000リクエスト、 1,000クライアント・20万リクエスト） 23 ©Fusic Co., Ltd.

Slide 24

Slide 24 text

効果が得られないキャッシュは、採用しなかった API Gatewayのキャッシュを比較（同じGETの試験）キャッシュなし約600 RPS キャッシュあり約200 RPS 0 採用を見送ったこの試験では処理量が低下。時間単位の課金と管理項目も増える学び：効果のない管理対象を、運用の中に増やさない CloudFrontのキャッシュは利用していた 24 ©Fusic Co., Ltd.

Slide 25

Slide 25 text

キャパシティ管理がほぼ不要になり、運用負担が減ったキャパシティ管理がほぼ不要になったアクセスの急増に備えて、毎回サーバーの台数やスペックを調整する必要がほぼなかった構築から約1年、私の記憶にある限り保守作業はなかった

Slide 26

Slide 26 text

5 2022–2025：チームの技術に合わせる合わせる 26 ©Fusic Co., Ltd.

Slide 27

Slide 27 text

1章のAPIは、言語を変えても保守者が増えなかった Python 最初の実装言語保守者 1 人 Go 保守を考えて変更＝型・後方互換性を評価保守者 1 人言語は変わったが、保守する担当者は増えなかった学び：1人で回せてしまうことが、次の課題になった 27 ©Fusic Co., Ltd.

Slide 28

Slide 28 text

勉強会を開いても、すぐには使われなかった勉強会直後数年後社内で紹介利用は広がらず自然に利用 Amplify・AppSync PHP・Brefの構成当時の社内はPHP・Ruby・AWSが中心。Amplify・AppSyncは、馴染みのない技術だった 28 ©Fusic Co., Ltd.

Slide 29

Slide 29 text

使い慣れたPHP・Rubyを前提にLambdaを使う Ruby 公式ランタイム PHP Bref Lambda Lambda ServerlessDays Tokyo 2024・AWS Community Day Hong Kong 2025で紹介した構成。 PHPには公式ランタイムがないため、Bref（コミュニティ製のPHPランタイム）を使う 29 ©Fusic Co., Ltd.

Slide 30

Slide 30 text

ServerlessDays Tokyo 2023でも、BrefでPHPをLambdaに載せた Serverless Frameworkの設定（serverless.yml）より。BrefでPHPをLambdaに載せる service: app-php-serverless provider: name: aws plugins: - ./vendor/bref/bref functions: api: handler: index.php runtime: php-82-fpm events: - httpApi: '*' 30 ©Fusic Co., Ltd.

Slide 31

Slide 31 text

Laravelの性能を測り、採用を続けた PHPは素の実装、Laravelはフレームワーク込み。EC2から同時接続10・2万リクエスト。処理量は3回目の値処理量（RPS）デプロイ時間（秒） PHP PHP Laravel 351.93 262.52 0 Laravel 30 52 0 パッケージ：PHP 260kB ／ Laravel 32MB Laravelの採用を継続性能差を確認し、使い慣れた開発方法を評価した 31 ©Fusic Co., Ltd.

Slide 32

Slide 32 text

若手のPHP開発者が、同じ構成を採用できた若手のPHP開発者 Laravel 普段の開発知識共通の構成＋ Laravel + Bref Lambda 別案件の本番環境を構築 32 ©Fusic Co., Ltd.

Slide 33

Slide 33 text

構築と運用を含め、チームに適した構成を選んだ「 AWS Lambdaとしてはベストではない。でも構築、運用まで含めたアプリケーションとしては、チームとしてベストだった」 ServerlessDays Tokyo 2023 33 ©Fusic Co., Ltd.

Slide 34

Slide 34 text

本番と開発で、同じLaravelのコードを使う本番 TiDB Serverless 互換 MySQL AWS Lambda Bref / Laravel 同じLaravelのコードで開発する⼿元の開発環境 / Docker Compose Laravel MySQL LocalStack TiDB Serverlessは現在、TiDB Cloud Starterという名称です 34 ©Fusic Co., Ltd.

Slide 35

Slide 35 text

私が開発に加わらなくても、案件が進むようになった「今までServerlessの開発を牽引していた自分自身が開発には一切加わらず進捗」 ServerlessDays Tokyo 2024 / AWS Community Day Hong Kong 2025 35 ©Fusic Co., Ltd.

Slide 36

Slide 36 text

Slide 37

Slide 37 text

開発が進んでも、基盤の運営は個人に集中していたアプリケーション開発開発チーム基盤の運営清家共同作業・導入支援私が開発に加わらなくても進行個人に集中したまま利用する案件が増えるときは、支援する側の作業も確認する 37 ©Fusic Co., Ltd.

Slide 38

Slide 38 text

担当者の交代を前提に、導入・定着・拡大を設計する定着導入拡大 Normalize Adopt テスト・デプロイ・監視をテンプレートで試す自動化 Scale 複数の製品へ広げる各段階で、設計判断を3点に整理して記録する前提見送った案見直す条件個人の構成をチームの基盤として整える取り組みは、Platform Engineeringと呼ばれる 38 ©Fusic Co., Ltd.

Slide 39

Slide 39 text

現在の構成で、設計判断を確認するドメインごとにAWSアカウントを分離共通テンプレートから、同型のサービスを展開レガシー基幹 S3 CSV SQS Lambda Aurora 取り込みドメインDB DLQ ⼿動で復旧ドメイン＝業務の領域。既存側はCSVを置くだけ。SQSが受け付けと処理を分離し、失敗したメッセージはDLQ（隔離用キュー）へ退避させ、手動復旧基幹にサーバーレスを選んだ理由：管理する実行基盤を最小化し、人が入れ替わっても運用し続けられるようにするため 39 ©Fusic Co., Ltd.

Slide 40

Slide 40 text

時刻の条件で更新の順序を守る。削除は守れない差分処理は実装済み・未使用。同時実行数1の制限に加え、 SQSの順序非保証に備え発生時刻で新旧を判定するで、発生時刻で上書き条件を付ける // keyColumns ON CONFLICT // orderColumn ( ) await tx.execute(sql` INSERT INTO ${table} (${cols}) VALUES (${values}) ON CONFLICT (${keyCols}) DO UPDATE SET ${setClause} WHERE excluded.${order} >= ${table}.${order} `) // delete ( DELETE) 側物理には同じ条件がない 40 ©Fusic Co., Ltd.

Slide 41

Slide 41 text

受信3回を上限とし、復旧は手動で行う設定の要点を抜粋。コメントは説明用推奨以上推奨倍 const MAX_RECEIVE_COUNT = 3 // AWS : 5 const VT_MULTIPLIER = 3 // AWS : 6 + window const visibilityTimeout = cdk.Duration.seconds( lambdaTimeout.toSeconds() * VT_MULTIPLIER ) new sqs.Queue(this, 'MainQueue', { visibilityTimeout, deadLetterQueue: { queue: this.deadLetterQueue, maxReceiveCount: MAX_RECEIVE_COUNT, }, }) visibilityTimeout＝処理中に隠す時間。maxReceiveCount＝DLQへ移す受信上限以上 41 ©Fusic Co., Ltd.

Slide 42

Slide 42 text

冪等キーが守るのは、応答のキャッシュだけ SQSの取り込みとは別の、API応答キャッシュの処理。冪等キー＝重複処理を防ぐ識別子。 TTL＝保存期限はミリ秒。秒に変換して加算 // put(): createdAt 24h const ttl = Math.floor(record.createdAt / 1000) + TTL_SECONDS await this.client.send(new PutCommand({ TableName: this.tableName, Item: this.toItem(record, ttl), ConditionExpression: 'attribute_not_exists(pk)', })) 削除は遅延しうるため論理的にも判定 // get(): TTL if (parsed.data.ttl <= nowSeconds) return null 42 ©Fusic Co., Ltd.

Slide 43

Slide 43 text

1,500万件超の初回投入は、Lambdaの外で行った 1,500万件超初回投入別の実行環境 Lambda 実行時間の上限は15分ではなく Lambdaの外で投入した次の担当者が確認：選定理由とLambda分割の検討 43 ©Fusic Co., Ltd.

Slide 44

Slide 44 text

原因を修正し、対象と処理順序を確認して復旧する担当者が確認 DLQ アラームで検知復旧は手動失敗原因の修正対象ファイル並行する取り込み固定のS3キー Lambda 最新の内容を再読込全件洗い替え全件洗い替えは手動で復旧。差分の運用は、キーの使い方と処理順序を導入前に定める 44 ©Fusic Co., Ltd.

Slide 45

Slide 45 text

coreからほかのパッケージへの依存を、CI（自動チェック）で検出する共通テンプレートの依存ルール設定より。業務ルールを置くcoreの、ほかのパッケージへの依存を禁止 { name: 'core-no-workspace-import', severity: 'error', from: { path: '^packages/core/src' }, to: { path: '^packages/(?!core/)' }, } 設計の規則は、文書とCIの両方に残す。レビューする人の記憶に頼らない 45 ©Fusic Co., Ltd.

Slide 46

Slide 46 text

前提と見直す条件があれば、次の担当者も判断できる初版前提約2か月後に改訂大量なのは初回だけ日次は少量見送った案日次処理へのCOPY導入見直す条件日次の性能不足が実測で判明前提が崩れた日次も 1,000万件規模 ECS Run Task + COPY による一括MERGEへ ADR＝設計判断を記録する文書 COPY＝PostgreSQLの一括取り込み命令 46 ©Fusic Co., Ltd.

Slide 47

Slide 47 text

Slide 48

Slide 48 text

判断するAIの登場で、サーバーレスの価値は上がる引き継ぐのは「判断」— その判断を、AIも行う時代になった判断専用AIが必要とするものサーバーレスが持っているものイベントを契機に行う判断 S3 PUT → SQS → Lambda のイベント駆動断続的に呼ばれる判断従量課金と自動スケール自動実行と人の境界（閾値）コードに残した規則と記録（CI・ADR）人のために整えた基盤は、そのままAIのプラットフォームになる「Jev」（TypeSafe AI・2026年9月発表）は、確信度つきの判断を返す判断専用AI。 CNCFもAIエージェントがプラットフォームの利用者になると述べている。「価値が上がる」は実際に動かして確かめた結果 48 ©Fusic Co., Ltd.

Slide 49

Slide 49 text

このJevのデモは、実際にサーバーレスで動いている構成静的画面＋判断APIのPOST 1本 S3＋CloudFront → API Gateway → Lambda 境界確信度の分岐をコードに明記 0.9以上＝自動実行 / 0.5以上＝人に確認未満＝拒否鍵 APIキーはサーバー側に閉じ込め外に出るのは静的画面だけ実際のCloudFrontで動作しています判断が走るのは押された時だけ — 待機コストなし大量の判断が起きても自動スケール 49 ©Fusic Co., Ltd.

Slide 50

Slide 50 text

10年の行動が「信じる」の中身信じるとは、盲信ではなく確かめ続けること頼り、確かめ、やめ、引き、合わせ、選び直し、記録して渡してきた "Everything will be Serverless" その言葉を盲信せず、10年確かめ続けました