‹#› 「完璧を目指さない」 サーバーレス進化論 ServerlessDays Tokyo 2025 2025 年09 月20 日 志水 友輔 NRI ネットコム株式会社 〜CDK で育てる変化に強いアーキテクチャ〜 

そのアーキテクチャ、本当に完成ですか？ 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 志水 友輔 ( しみず ゆうすけ) NRI ネットコム株式会社 / Cloud Architect Web システムのPoC 、アーキテクトがおしごと AWS Ambassadors(2023-) AWS Community Builder （Serverless ）(2024-) 　AWS CDK/Strands Agents/ カメラ/ つけ麺 パイナップルのテーマソング沼ってる #serverlessjp Blog: 

1. 「まずはLambda で作っておこう」の現実 #serverlessjp Copyright （C ） NRI Netcom, Ltd. All rights reserved. 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. よくある開発の流れ 要件定義 → 「とりあえずLambda で設計」 → 構築 → 本格運用 #serverlessjp 最初は快適（SAM で簡単にデプロイ） メリット デメリット 15 分制限の壁 複雑化するYAML （構成変更時に記述量爆発） 構成変更の恐怖（型安全性なし、実行時エラー多発） 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. Lambda 15 分制限の壁 シナリオ：データ処理バッチ 初期：数分で完了 半年後：データ量増加で10 分 1 年後：15 分超過でタイムアウト この時、あなたならどうしますか？ #serverlessjp 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 構成変更の現実 選択肢と課題 1.Lambda 分割 → 複雑化、デバッグ困難 2.Fargate 移行 → 大幅な構成変更が必要 どちらも大変... 初期設計では15 分で十分だった データ量増加は予測困難 SAM のYAML 地獄で変更が困難 もっと変更しやすくできないか？ #serverlessjp 

本日のテーマ アーキテクチャは「育てるもの」 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 進化の鍵：構成変更の容易さ アーキテクチャの進化には柔軟性が重要 完璧な初期設計は存在しない 要件変化に柔軟に対応できる仕組みが重要 構成変更の容易さと将来の拡張性 #serverlessjp 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 進化的アーキテクチャとは ビジネス要件や技術の進歩といった絶え間ない変化に適応できるように設計された、 柔軟性の高いソフトウェアアーキテクチャ 1. 漸進的な変更 - 小さく段階的な変更を可能にする 2. 適応度関数 - アーキテクチャ特性の充足度を測る客観指標 3. 多重な次元 - 性能、セキュリティ、可用性など複数の観点を統合管理 CDK による進化的アーキテクチャの実現 → 実際の移行事例で確認してみましょう #serverlessjp 

2. 実践的進化パターン #serverlessjp Copyright （C ） NRI Netcom, Ltd. All rights reserved. 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 実践的進化パターン 3 つの移行パターンで見るCDK の優位性 パターン1 ：Lambda → Fargate 移行 パターン2 ：EventBridge+Lambda → Step Functions 移行 パターン3 ：DynamoDB → Aurora 移行 #serverlessjp AWS Lambda AWS Fargate Amazon EventBridge AWS Step Functions Amazon DynamoDB Amazon Aurora 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. パターン1 ：Lambda → Fargate 移行 課題 15 分実行時間制限 データ処理時間の予測困難 スケーラビリティの限界 解決アプローチ コンテナ化による時間制限解除 ECS Fargate での自動スケーリング 既存Lambda との段階的置き換え #serverlessjp 15min Lambda Fargate 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. CDK 実装：Lambda → Fargate #serverlessjp 移行のポイント 実行時間制限の解除（15 分 → 制限なし） より大きなメモリ・CPU リソース割り当て 既存のLambda 関数ロジックをそのままコンテナ化可能 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 比較検証：実際に作成したサンプル 算出方法 各サンプルのインフラ定義 ファイルの総行数を集計 SAM はtemplate.yaml, CDK は*_stack.py コメント・空行含む 同一要件で実装したものを 比較 #serverlessjp CDK SAM Lambda EventBridge Scheduler Fargate EventBridge Scheduler S3 S3 VPC 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 移行時のコード量変化 Lambda → Fargate 移行での記述量比較 #serverlessjp SAM CDK 0 100 200 300 400 Lambda->Fargate 行数 59 367 73 152 x6.3 x2.1 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 移行時のコード量変化 Lambda → Fargate 移行での記述量比較 #serverlessjp SAM CDK 0 100 200 300 400 Lambda->Fargate 行数 59 367 73 152 x6.3 x2.1 CDK の優位性が明確に SAM: 6.3 倍の複雑化 CDK: 2.1 倍の複雑化 CDK は移行時の複雑度を1/3 に抑制 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. パターン2 ：EventBridge+Lambda → Step Functions 課題 トレーサビリティ不足 分散イベント処理の複雑化 障害時の影響範囲特定困難 解決アプローチ 一気通貫ワークフローへの統合 実行状況の可視化 エラーハンドリングの集約 #serverlessjp Lambda Lambda EventBridge DataSync Step Functions 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 移行のポイント Step Functions 移行での改善点 分散イベント処理の統合 複数ルール → 単一ワークフロー 実行履歴の一元管理で状況把握が一目瞭然 エラーハンドリングの集約化 障害調査時間の大幅短縮 迅速な顧客対応が可能 #serverlessjp 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. CDK 移行時の具体的メリット CDK でStep Functions 移行が楽になった理由 既存のgrant() メソッドがそのまま使える 型安全性によりコンパイル時にエラー検出 CDK で並列処理やワークフロー分岐の構造を定義 retry_on_service_exceptions で自動リトライ設定 複数のLambda 関数の連携を1 つのファイルで管理 #serverlessjp Lambda Step Functions S3 grant() S3 grant() 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. パターン3 ：DynamoDB → Aurora 移行 課題 複雑なクエリ要件の増大 NoSQL の限界 分析要件の高度化 解決アプローチ DynamoDB からAurora への切り替え SQL による柔軟なクエリ実行 CloudWatch Synthetics による監視強化 #serverlessjp Aurora DynamoDB 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. DB 移行のための性能監視 #serverlessjp API Gateway Lambda DynamoDB API Gateway Lambda Aurora CloudWatch Synthetics CloudWatch Synthetics OK OK 進化的アーキテクチャの観点 性能監視による適応度関数 DB 移行時の性能劣化を自動検知 CDK により簡単に記述可能 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. セキュリティ要件の移行 #serverlessjp DynamoDB Lambda Aurora IAM ベース VPC ベース 進化的アーキテクチャの観点 cdk diff により変更点を確認しながら進める漸進的な変更が可能 1 行の変更でIAM ベースからVPC ベースのセキュリティへ変更 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. CDK 移行時の具体的メリット 適応度関数の実装が容易 synthetics.Canary() で継続的な監視をコード化 移行過程でアーキテクチャ特性（性能・可用性）を保護 漸進的な変更の実現 cdk diff で変更点を確認しながら段階的に移行 1 行の変更でIAM ベースからVPC ベースのセキュリティへ変更 #serverlessjp 

3. 進化的アーキテクチャの実現 #serverlessjp Copyright （C ） NRI Netcom, Ltd. All rights reserved. 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. SAM vs CDK 観点 SAM CDK 構成変更時の記述量 爆発的増加 管理可能 変更影響の可視化 困難 cdk diff で確認可能 権限・接続管理 複雑なYAML grant/connections で直感的 段階的移行 困難 既存リソース保持しながら可能 進化的アーキテクチャ 困難 実現可能 長期的な開発・保守性でCDK が優位 #serverlessjp 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. 進化的アーキテクチャの実現 CDK による適応度関数の実装 CloudWatch Synthetics による継続的な監視のコード化 段階的移行による既存リソース保持と新リソース追加 多重な次元の統合管理による性能・セキュリティ・可用性の統合評価 実践的移行パターン 1.Lambda → Fargate ：実行時間制限の突破 2.EventBridge → Step Functions ：トレーサビリティの向上 3.DynamoDB → Aurora ：複雑クエリ要件への対応 #serverlessjp 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. まとめ CDK の価値 構成変更時の記述量を大幅削減（SAM の1/3 の複雑度） cdk diff による変更影響の事前確認 grant/connections による直感的な権限・接続管理 アーキテクチャは「育てるもの」 完璧な初期設計は存在しない サーバレスだからこそ要件変化に柔軟に対応できる 段階的な改善アプローチで進化させる #serverlessjp 

CDK でアーキテクチャを大切に育てていこう 

Copyright （C ） NRI Netcom, Ltd. All rights reserved. #serverlessjp