地方こそサーバーレス — 10年続けた、顔が見えるチームで確かな基盤を / Serverless Matters Most in Regional Areas — 10 Years of Building Reliable Foundations with Close-Knit Teams

JAWS FESTA 2026 in AKITA
https://jawsfesta2026.jaws-ug.jp

Transcript

1. OSEKKAI × TECHNOLOGY 地方こそサーバーレス 〜10年続けた、顔が見えるチームで確かな基盤を〜 JAWS FESTA 2026 in AKITA 2026.11.07 Fusic Co., Ltd. 清家 史郎 (@seike460)
2. 自己紹介 OSEKKAI × TECHNOLOG Y 清家 史郎 (@seike460) SHIRO SEIKE 技術コミュニティ統括室長 / シニアエバンジェリスト ・AWS Ambassador ・AWS Community Builder (Serverless) ・2025・2026 Japan AWS Top Engineers — コミュニティ ・JAWS-UG 福岡 Co-Organizer ・JAWS DAYS 2026 実行委員長 2 ©Fusic Co., Ltd.
3. 何を任せて、何を自分で決めるか。 構築は AI に、実行はサーバーレスに任せる。 その分、一つ一つの仕事に人が関わる部分は減る。 それでも、要件を決めて判断するのは人だ。 地方こそサーバーレス。 なぜそう言えるのかを、僕が作ってきたシステムで話します。 3 ©Fusic Co., Ltd.
4. 多くのアプリはほとんどの時間動いていない。 81% 平均 1 分に 1 回以下しか呼ばれないアプリ 安くなる 45% 平均 1 時間に 1 回以下 たまにしか動かない処理 安くならない 休まず動く処理。VM やコンテナが安い 僕の 1 本目も最初はこの 81% に入っていた。 4 ©Fusic Co., Ltd.
5. Lambda は使った分だけ払えばいい。 AWS がまとめて動かすと 自分でサーバーを持つと A社 B社 C社 → 1 つの microVM に、他社の関数は入らない。 microVM が主なセキュリティの境界になる。 灰色は払っているのに使っていない分。まとめると、ほとんど消える。 この仕組みがあるから、AWS は使った分だけの料金にできる。 5 ©Fusic Co., Ltd.
6. 管理を任せたので、73 倍になっても 1 人で保守できた。 2016 年 2022 年 月のリクエスト 保守する人 21,172 件 1人 1,543,602 件（約 73 倍） 1人 2016 年に決めたのは、サーバーの運用を任せること。 6 ©Fusic Co., Ltd.
7. チームの PHP を捨てずに、サーバーだけ手放した。 いつもの Laravel PHP 60,357 行 2024-07 → Bref PHP を Lambda で動かす → AWS Lambda 17 本 27 か月続けて、毎月チームが変更を入れている 2026-09 手放したのはサーバーの管理だけで、 チームの技術は変えていない。 7 ©Fusic Co., Ltd.
8. 15,163,073 地域のお店に並ぶ商品の、店ごとの全件データ。 最初の移行だけでこの件数になる。 8 ©Fusic Co., Ltd.
9. 信 じてい るからこそ 、 使 い続け 失敗か ら学んで きました データが多い。順番が守れない。処理が二度走る。 9 ©Fusic Co., Ltd.
10. 要件：マスター全件 15,163,073 件を一括で反映する 重い取り込みは Fargate へ、軽い取り込みは Lambda へ 重い ｜ マスター全件。最初の移行は 15,163,073 件 Amazon S3 全件データ → EventBridge 保存を検知 → ECS Fargate COPY と MERGE → Amazon Aurora 一括で反映 軽い ｜ 小さなファイルの取り込み Amazon S3 CSV を保存 → Amazon SQS 標準キュー → AWS Lambda 同時実行 1 → Amazon Aurora 業務データへ反映 Lambda には 15 分とメモリの上限がある。大量のデータ処理は苦手だと論文も指摘する。 だから重い処理は分けた。 10 ©Fusic Co., Ltd.
11. 要件：新しいデータを古いデータで消さない。取込は低頻度で、速さは要らない 同時に 2 つ走ると、古い内容を読んだ実行が新しいデータを消す。 実行 A と B が同時に走ると A が読む 古い内容 → B が読む 新しい内容 → B が書く 新しい内容 → A が書く 古い内容 → 新しいデータが 消える → B が書く 新しい内容 → 新しいデータが 残る 同時実行を 1 にすると（A が終わってから B が動く） A が読む 古い内容 → A が書く 古い内容 → B が読む 新しい内容 s3-sqs-ingest-construct.ts 並列度 で直列化する 取込は低頻度で並列性能は不要)。 // 1 ( reservedConcurrentExecutions: 1, どの実行もその時点の最新を読んで丸ごと入れ替えるので、届く順番には頼らない。 11 ©Fusic Co., Ltd.
12. 要件：同じ依頼は一度だけ通す（基幹とは別の社内 HTTP API） 二度目の依頼は入口で止める。 1 回目の依頼 キー K → 入口の条件式 K の記録がない → 記録して通す 同じ依頼の 2 回目 キー K → 入口の条件式 K の記録がある → 409 で断る DynamoIdempotencyStore.ts 先勝ち。二度目は通さない // ConditionExpression: "attribute_not_exists(pk) OR #ttl <= :now", attribute_not_exists(pk) #ttl <= :now まだ記録がない 24 時間の期限切れ。TTL の削除を待たずに自分で判定する 12 ©Fusic Co., Ltd.
13. 要件：知らないうちにデータが欠けない。消したデータが戻らない サーバーではなく、判断の記録を引き継ぐ。 （要約） docs/adr/data-0005.md 取り込みの再試行と障害の扱い 背景 通知は 2 回以上届くことがある。 何度やっても失敗するデータもある。 却下 失敗した行を飛ばす → 気づかずにデータが欠ける。 自動で再投入する → 順番が崩れて、 消したデータが戻りうる。 決定 3 回受け取っても終わらなければ、 ファイルごと DLQ へ送る。 戻すのも、その順番を決めるのも人。 data-0005 担当が変わっても、決めた理由は残る。ADR は 22 本ある。 13 ©Fusic Co., Ltd.
14. 特売の日のアクセスも自動でさばけている。 アクセスが急に増えるとき 売上のピーク時間帯 特売の日 新店のオープン → AWS Lambda 意識しなくても、 自動でスケールする 地域のスーパーのポイントシステム。 お客さんと一緒に作り、お客さんが自分たちで運用できるようにした。 14 ©Fusic Co., Ltd.
15. サーバーは持たない。判断は、持つ。 「何分ごとの更新なら、困りませんか」 「30 分で」 要件を決めたのはお客さん。設計を決めたのは僕。 サーバーレスの制約で難しい要件も、お客さんと話せば解決できる。 地方はドメインを集めて伝えるのが得意だ。 人が減っても、AI とサーバーレスが助ける。 地方に合ったサーバーレスの形を、顔が見えるお客さんと作り上げていく。 15 ©Fusic Co., Ltd.
16. なぜ地方こそサーバーレスなのか。 地方で起きていること 人が減り、使う量の先が読めない 2024 年に人口が増えたのは東京都と埼玉県だけ システムを支える人も減る 情シスが 1 人の会社は、全国で 4 社に 1 社 要件を決める人と、顔が見える距離で話せる 「30 分で」と決めたのはお客さん サーバーレスと AI なら → 使った分だけ払う。 使う量が減れば、支払いも減る → 運用は AWS に、 構築は AI に任せる → 人は要件と判断に 時間を使える だから地方こそサーバーレス。 16 ©Fusic Co., Ltd.
17. 地方だからこそ サーバーレスで価値を届けよう。 17 ©Fusic Co., Ltd.
18. Thank You 地方こそサーバーレス @seike460 ©Fusic Co., Ltd.