開発と運用を楽にするSpring Boot on AWSテクニック集
Masatoshi Tadaさん
https://docswell.com/s/MasatoshiTada/537VVD-spring-boot-on-aws
テスト
- ローカルでのテスト
- 何も考えずに起動して動くのが理想
- でも壁がある
- DockerCompose
- ミドルウェアのセットアップが入ったものを
- spring-boot-docker-compose
- 起動時に勝手にdocker composeしてくれる
- テストの時も勝手に起動して停止してくれる
- DBの接続情報などをapplication.ymlに持たなくて良くなる
- モックとプロファイルでの切り替え
@Profile("local")とか@Profile("production")とか- ローカルは固定値返すなどのモックで
- 本番は外部のサービスへ
- application.ymlのspring.profiles.activeにlocalを指定する
- 環境変数のSPRING_PROFILES_ACTIVEでも
- Local StackでAWSサービスを再現
- コンテナイメージが提供されている
- AWSのセットアップのBeanをProfileで切り替えてLocalStackに向けるように
デプロイ
- Amazon ECS
- AWS Lambda
耐障害性
- 自システム
- マルチAZ
- 負荷分散の問題
- SpringSessionの注意点
- ストレージへのアクセスが入るのでその分レイテンシに影響がある
- https://www.docswell.com/s/MasatoshiTada/K1XE12-spring-session
- 連携先システム
その他
- 構造化ログ
- ログはJSONにする
- Microsoft Entra ID連携
- ALBにEntraIDを設定
- Spring Securityで設定
- @SpringBootTest
- テストは全てこれを使う
@WebMvcTestとか@JdbcTestなどもある- AutoConfigurationの範囲を縮めてる
- 効果は小さい割にハマると面倒なので使わなくていい
- SpringBoot4.0
- 2025/11/20リリース
- 変更点がたくさんある
- マイグレーションガイドを見るといい
- ライブラリ名がリネームされてるもの
starter-webがstarter-webmvcstarter-testが細分化されたり
- RestTemplateが非推奨化
- まだだけどいずれ使えなくなる
- RestClientに移行する
- Jacksonが2から3へ
- パッケージ名とグループIDが変わる
- ただしjakson-annotationsのみ変更されない
nullの10億ドルの過ちから未来へ：Spring Boot 4とJSpecifyが描くnull安全設計
- 尾形さん(ウェルスナビ株式会社)
藤原さん(ウェルスナビ株式会社)
https://docswell.com/s/WN_Tech-PR/ZM6PPE-2025-11-15-125730SpringBootのアップデートをしていて
- 古いバージョンを使っているアプリが多くアップグレード対応
- SpringBoot4でJSペシfy準拠のnull安全アノテーションが導入されることを発見
- Javaとnull
- 1995年にJavaが登場
- その時からnullが導入されていた
- 何も参照していない状態
- Javaのnullの課題
- 型システムでnullを判別できない
- つまり静的解析で判定できない
- null許容化明示されないので設計書やコメントで補足しないといけない
- この変数はnull入れて良いの？という議論が起きてしまう
- 型システムでnullを判別できない
- null安全アノテーションの乱立
- Java標準のnull安全アノテーション
- JSR-305
- 統一的なアノテーション
- 議論が停滞し休止し採用されず
- Optional
- Java8から使える
- nullの有無を型で明示的に表現できる
- 値の存在確認が強制させる
- Kotlinの台頭
- null安全な言語
- Helpful NullPointerException
- java14から
- 何がヌルポになったか分かりやすくなった
- 具体的に何がnullで落ちたのか
- JSpecify
- NullAway
間も無くリリース Spring Boot 4！
- SpringFramework7が11/14にリリース
- SpringBoot4が11/20リリース
- OSSサポートは13ヶ月
- 毎年マイナーバージョンを上げていくとちょうどいい
- Spring Boot 4.0
- Spring Framework 7.0
- Spring Security 7.0
- Spring Batch 6.0
- Spring Data 2025.1
- Spring Integration 7.0
- Spring gRPCは1.1でSpring Boot 4.1に含まれる予定
- Spring gRPC 1.0はSpring Boot 4に対応
Spring Boot4.0の変更点
- モジュール化
- 今までAutoconfigurationがモノリスで1つのjarだった
- 機能が増えるにつれてサイズも増大
- 保守性も悪くなった
- 利用側でも必要ない機能が入ってしまったり時間がかかったり
- 各技術ごとにjarが分割された
- それに伴ってパッケージ名が変わった
- アップグレード
- Spring Initializrで改めて必要なモジュール選んで生成したものをコピーして持っていくといい
- 何が必要なのかの選別が大変だから
- 暗黙的に有効になっていたやつをもらさないように注意
- ライブラリが内部的に使ってたとかもあるので
- 過渡期用の全部入りセットもある
- spring-boot-starter-classic
- サードパーティがAutoConfiguration使ってたらライブラリ側が対応してくれるのを待たないといけない
- Spring Initializrで改めて必要なモジュール選んで生成したものをコピーして持っていくといい
- 今までAutoconfigurationがモノリスで1つのjarだった
- Jackson3
- 2から3に上がる
- パッケージ名が変わる
- ObjectMapperを使っていたとこがJsonMapperなどそれぞれ用意されるようになった
- 例外がチェック例外から非チェック例外になって扱いやすくなった
- 2は非推奨だけど使うことはできる
- サードパーティが暗黙的に使ってることもあるので注意
- dependency treeを見てチェック
Spring Framework 7.0の変更点
- レジリエンス機能
- リトライサポート
- Spring Retryがコアに入った
- Java Configクラスに@EnableResilientMethodsつけておくと有効化される
- @Retryableでリトライの定義
- @ConcurrencyLimitで同時実行数の制限ができる
- リトライサポート
- APIバージョニング
- headerでバージョン入れてもらって振り分けるようなケース
- 従来は自前で振り分けてた
- 設定とGetMappingなどに書いたversionでいい感じにできる
- Interface HTTP Client
- インターフェースベースのHTTPクライアント
- 従来は同じような設定をコピペで毎回書かないといけなかった
- 同じような設定をグループとしてまとめられるようになった
- RestTestClient
- WebClientに対応するWebTestClientのRestClient版
- JSONのアサートできたり
- どこまで組み込んだ状態で使うかバリエーションがある
- JmsClient
- JdmcTemplateに対するJdbcClientのJmsTemplate版
- FluentなAPIで扱えるようになる
- priorityとかtimetolieveを設定したいとかなると良さが見えてくる
- BeanRegistration
- プログラマティックにDIコンテナにBeanを登録する方法
- ifとかforを使ってということ
- 今までは1個ずつやってかないといけなかった
- プログラマティックにDIコンテナにBeanを登録する方法
- JSpecify
AI駆動開発の最前線：GitHub Copilot Agent Mode と Coding Agent で実現する高速マイクロサービス開発
てらだよしおさん
- AI駆動開発に適応できないといけない時代
- マイクロサービスなECアプリをを数日で動くものまでできる
- モノリスよりもマイクロサービスの方が相性がいい
- AIコーディング
- 同じ指示でも結果が違う
- Vibeコーディングは運任せ
- やらせるにしても仕様をしっかり書いて単位を小さく
- 設計仕様を作らせる
- 実装計画をたてさせる
- GitHub Copilot Agent Mode
- VSCode上でプロンプト渡して動かすやつ
- GitHub Coding Agent
- AIとの向き合い方
- AIは嘘を付くしごまかすし壊してしまう
- 常に検証/テスト/レビューを実施する
アーキテクチャと考える迷子にならない開発者テスト
irofさん
- テストは難しい
- テストエンジニアと呼ばれる専門家がいるくらい一大トピック
- 片手間でできるようなものではない
- 開発者とテスト
- 誰もがテストと向き合ってる
- スペシャリストになるのは難しくても知識を取り入れる必要がある
- 開発者テスト
- 今回の話のスコープ
- 作ったものが思ったとおりに動くか自分でやるテスト
- アーキテクチャは難しい
- アーキテクトと呼ばれる専門家がいるくらい一大トピック
- 片手間でできるようなものではない
- アーキテクチャという言葉の曖昧さ
- 抽象的な概念
- 構造をモデルで表したとしても単一に定まらない
- 複数同時に存在することもある
- 切り口によっていろいろ
- アプリケーションアーキテクチャ
- 今回の話のスコープ
- アプリケーションを構造で捉える
- テストする範囲と道具
- 自分の作ったコードで存在し得る欠陥を考える
- その欠陥がないことを確認するテストを書く
- アーキテクチャに持たせている意味が成立していることを見ていく
- 意味があれば各レイヤーで何をテストするべきかが分かりやすくなる
