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

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

自己紹介 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.

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

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

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

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

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

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

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

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

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.

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

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

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

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.

型は移行の前後で引き継げる 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<GetBlogQuery> setBlog(res.data?.getBlog as Blog) } 16 ©Fusic Co., Ltd.

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

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

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

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

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.

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

サブサイト側で、処理できるリクエスト数を測った 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.

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

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

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

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

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

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

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.

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.

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

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

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

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

6 現在：判断を記録し、次の担当者へ引き継ぐ 36 ©Fusic Co., Ltd.

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

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

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

時刻の条件で更新の順序を守る。削除は守れない差分処理は実装済み・未使用。同時実行数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.

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

冪等キーが守るのは、応答のキャッシュだけ 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.

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

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

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

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

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

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

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

Everything will be SERVERLESS — 信じて運用した10年の経験値 ...

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

More Decks by shiro seike

Other Decks in Programming

Featured

Transcript