Spring Fest 2017 「エンタープライズで利用するSpring Boot」#jsug #sf_h1

エンタープライズで利用するSpring Boot
株式会社ビッグツリーテクノロジー＆コンサルティング
SI事業部アーキテクチャG
廣末丈士

Copyright © 2017 Bigtree Technology&Consulting Ltd. All Rights Reserved. 2
自己紹介
• 名前
– 廣末丈士（ひろすえたけし）
• 仕事
– 官公庁のSIプロジェクトの開発リーダ
– 新技術検証、プロトタイプ開発
• 好きな技術・サービス
– AWS
– Docker
– Spring Boot(Java)
• GitHub
https://github.com/Thirosue
• Quita
https://qiita.com/takeshi_hirosue

対象者と前提
• 対象者
– 開発者（Springにこだわらない）
特に開発標準策定に関わるアーキテクトの方。今日話す内容で共感した箇所
を、自身のプロジェクトに持ち帰って取り入れてください。フィードバック
（mail／PR／Issue）大歓迎です！
– プロダクト管理者
今日話す内容で気になった箇所について、自身のプロダクトの現状をチェッ
クしてみてください。
• 前提
– 具体的な作り方（コード中心）にフォーカスします。
– 独自フレームワーク路線ではなく、Spring Bootの使い方を中心に話します。
– 図が少ないため、少し解りづらいかもしれません。。。

アジェンダ
1 始めに
2 アプリ構成概要
3 共通処理
3-1 バリデーション
3-2 オブジェクトマッピング
4 データアクセス
4-1 Doma
4-2 エンティティリスナー
4-3 排他制御
4-4 その他便利機能
5 セキュリティ
5-1 権限制御
5-2 二重送信防止
5-3 監査情報制御
6 静的コンテンツ
6-1 ライブラリ管理（WebJars）
6-2 キャッシュ制御
7 チーム開発
7-1 開発環境管理
(Docker/Flyway)
7-2 テスト管理(Spock)
8 運用
8-1 Spring Profiles
8-2 ロギング
8-3 アプリケーションの状態
8-4 JMX監視
8-5 設定ファイル暗号化

SpringBootは動くものをシンプルに作成・デプロイできる優れた仕
組みです。
しかし、開発者に実装を一任すると、プロダクトコードが望むものに
なっている可能性は低いです。
ここでは、弊社の直近のSpringBoot開発プロジェクトのソースコー
ドを参考に、開発実装基盤として設計・実装しておくべき点について、
実際のソースコードを交えてご説明します。
1 はじめに

本セッションで取り上げる主な課題
1 はじめに
設計開発運用
設計・実装における横断的関心事
（ロール制御、監査情報、ロギングetc）
開発環境管理
テスト管理
フロントライブラリ管理
開発を効率化するライブラリ選定
システム監視

O/RマッパーにDoma、ビルドツールはgradleを利用
Spring Boot
Jetty
MySQL
SpringMVC
Doma
ThymeLerf
SpringSecurity

Spring以外の主な登場プロダクト
名称内容
オブジェクトマッピングライブラリ。
WebJars クライアントライブラリ管理ライブラリ。
JQuery、BootStrap等をjarに同梱する。
DevOpsを支える軽量なコンテナ管理ソフトウエア。
DBマイグレーションツール。
テストフレームワーク。Groovyで記載できる。
統合監視ソフトウエア。

本セッションでサンプルとして示すソースコードの大半はGitHubよりクロー
ンすれば、すぐに動かせる状態となっています。
気になる箇所をIDE等でご確認ください。
事前準備
https://github.com/miyabayt/spring-boot-doma2-sample

字が小さすぎて見えない方
SlideShareに資料アップしています。
事前準備
https://www.slideshare.net/takeshi_hirsoue/

デフォルトでは、単項目チェックのアノテーションは存在しますが、相関チェックを行うアノテー
ションは提供されていません。
相関チェックについては、以下2点のいずれかで実装する方針が考えられます。
1. 自作アノテーション実装
2. Spring Vaildatorを利用
弊社では、実装のシンプルさを重視し、2の方針を採用しました。
課題
Bean Validatorで提供してない、相関チェックをシンプルに実装したい
アプローチ

確認用のパスワードのチェックを例に説明します。
例）確認用のパスワードのチェックの実装
凡例
Spring標準
拡張実装

Spring Vaildatorを拡張した基底クラスの実装例
→デフォルトでは、supportsを実装不要とし、アプリ開発者は利用するフォームクラスを指定し、
doValidateのみ実装する。
凡例
Spring標準
拡張実装

コントローラの実装
→作成したバリデータをインジェクションする
→作成したバリデータをWebDataBinderに追加する
凡例
Spring標準
拡張実装

Spring MVCではコントローラでModelに情報をセットし、画面に情報を表示します。
サービスから取得した情報をModelにセットする場合、処理を1行1行書く必要があります。
例）ModelにaddAttributeで画面表示項目を設定
課題
項目が多い詳細画面のコード量を削減したい
単純な画面への表示項目追加対応でコントローラを修正したくない
アプローチ

ModelMapper （org.modelmapper:modelmapper）
Bean間で属性のコピーを行えるマッピングライブラリ
→類似ライブラリは、commons.BeanUtilsやDozer等
→シンプルさと制約等が特にないことからModelMapperを採用
凡例
Spring標準
拡張実装

プロジェクト個別要件は、JavaConfigで調整
例）EntityのPKはコピーしないように調整、外部キーをcastする。

O/Rマッパーの選択は、好みが別れ選定が難しいですが、弊社基盤ではDoma2を選定しました。
選定理由は、
– XML不要でシンプルにSQLテンプレートファイルを利用できるため
– 2Way-SQLであり、SQLテンプレートに記載したSQLをSQL実行ツールでそのまま実行できる
ため
です。
※アノテーション1つで便利な機能も利用できるところもポイント高い
4-1 Doma
課題
XMLはできるだけ利用したくない
SQLを外部ファイルで管理したい
アプローチ

SQLテンプレートの利用は、以下で対応できます。
1. インターフェースの作成
2. メソッドに対応したSQLファイル作成
例）インターフェースの実装例 CodeエンティティをOptionalでselect
4-1 Doma

SQLテンプレートファイルの作成
→ src/main/resources/META-INF/(FQCN)/(class name)/(method name).sqlで配置
→コンパイル時にインターフェースの実装クラスが自動生成される
4-1 Doma

エンティティ基底クラスを作成し、更新イベントをエンティティリスナーでハンドリングする。
例）エンティティ基底クラスの作成
→共通処理をハンドリングするためエンティティリスナーを指定
課題
システム制御項目の更新処理を一箇所にまとめたい
アプローチ
凡例
Spring標準
拡張実装

例）エンティティクラス
→基底クラスを継承
凡例
Spring標準
拡張実装

例）エンティティリスナークラス
→システム制御項目の更新処理を共通化する
凡例
Spring標準
拡張実装

Domaでは@Versionアノテーションを利用するとデフォルトで楽観的排他制御が可能です。
具体的には、以下のフローで楽観的排他制御を実装します。
1. 画面制御で改定番号を含めてSELECTする
2. SessionAttributeを利用し、更新セッションで改定番号を保持しておく
3. 更新時に更新セッションで保持していた改定番号をエンティティに設定する
4. 更新件数が0件の場合は、楽観的排他エラーとなる。
1) 画面制御で改定番号を含めてSELECT
4-3 排他制御

2) SessionAttributeを使用し、更新セッションで改定番号を保持しておく
→改定番号を保持した、基底Formクラスを用意しておき各画面フォームは継承する
→各画面フォームを更新セッションで保持
4-3 排他制御
凡例
Spring標準
拡張実装

3,4) 更新セッションで保持しておいた改定番号をエンティティにセットして、更新処理を実行
→改定番号を更新条件に含めて更新処理を実行、例外時は楽観排他例外がスローされる
4-3 排他制御
3)
4)

Domaでは以下の様な便利機能があります。
1. EntityにNullがセットされた項目は更新対象にしない
2. 指定されたプロパティは更新対象外とする
例）Null項目を更新対象外にできる属性：excludeNullを指定し、論理削除フラグのみ更新する
例）指定されたプロパティは更新対象外にできる属性：excludeを指定し、コード値のみ更新する
4-4 その他便利機能
凡例
Spring標準
拡張実装

大抵のアプリケーションでは権限制御が必要です。
弊社基盤ではSpEL（ Spring Expression Language ）を用い権限テーブルを設計することで、
きめ細かい権限制御を実現しています。
例) 権限テーブルのDML
→SpELを用いて、直感的な権限定義を実現
→RDBのみで管理できるメンテナンス性を重視し、Spring Securityのメソッドレベルの権限制御
は不採用とした
→コントローラへのアノテーション実装を採用すると、アプリケーション拡張に比例し、メンテナ
ンスコストは増大する
5-1 権限制御
課題
権限管理を一箇所にまとめたい
更新権限、参照権限を各々管理できるようにしたい
アプローチ

次にアプリケーションの権限制御について説明します。
権限制御用のインターセプターを実装し、コントローラのメソッド単位の権限制御を実施しました。
例）権限制御を行うインターセプター
5-1 権限制御
凡例
Spring標準
拡張実装

例）SpELを評価するユーティリティ実装
→SpringSecurityで保持している認可情報とコントローラのメソッド名をSpELで評価
→コードテーブルの編集権限「^Code.(new|edit)Code$」保持しているユーザは、CodeControllerの
newCode及びeditCodeの実行を許可する
5-1 権限制御

ECサイト等のアプリケーションを実装する際、必ず二重送信防止制御の実装が必要になってきます。
二重送信防止制御は、クライアントサイドでの対応も必要ですが、サーバサイドでも実装しておく
必要があります。
弊社基盤では、以下実装で二重送信の抑制を行っています。
1. フォームの再送信の禁止（Post-Redirect-Getパターン）
2. トークン制御による二重送信の抑制
課題
二重送信防止制御を基盤として実装しておきたい
アプローチ

■フォームの再送信禁止
更新完了時は、参照画面にリダイレクトさせます。
例）更新時にリダイレクトして、ブラウザ再読込でフォーム再送信させない
参照画面
に戻す

■フォームへのトークン埋め込み
RequestDataValueProcessorを実装し、入力フォームに二重送信防止のトークンを埋め込みます。
例）カスタムトークンをhiddenに設定
凡例
Spring標準
拡張実装

■二重送信防止トークン制御
インターセプターを実装し、以下を制御します。
1. コントローラ動作前に二重送信防止トークンをセット
2. コントローラ動作後にトークンが一致した場合、トークンを再発行する
→ 結果、二重送信時（次回リクエスト時）はトークンが一致しない
例）二重送信防止のインタセプター実装
2)
1)
凡例
Spring標準
拡張実装

■二重送信チェック実装
実際のエラー制御はエンティティリスナーで実装する。
Insert実行前にトークン比較を行い一致しない場合、例外をスローする。
例）エンティティリスナー実装
凡例
Spring標準
拡張実装

■コントラーでのエラーハンドリング
ControllerAdviceを実装し、例外をハンドリングする。
例）ExceptionHandlerで例外ハンドリングし、エラー情報を設定した後、編集画面に戻す
凡例
Spring標準
拡張実装

Domaを利用しているため、Spring Data JPAの監査情報制御を利用できないため、自前で実装し
ます。
例）監査情報保持クラス
→スレッドローカルかつstaticアクセス可能な監査情報保持クラスを用意
課題
監査情報制御を一箇所にまとめたい
アプローチ

インターセプターを実装し、監査情報を設定すると、様々な箇所で利用できます。
例）インターセプタ実装例：アクセス毎に監査情報を初期化する
例）利用例：システム制御項目更新時に利用
凡例
Spring標準
拡張実装

Spring Boot+Thymeleafを利用し、サーバサイドレンダリング中心のアプリケーション
を作成予定でも、フロントライブラリの管理はやっておきたいです。WebJarsを利用す
れば、クライアントライブラリの依存関係もgradle/mavenで一元管理できます。
例）gradleでjqueryやbootstrapのバージョン管理
例）JavaConfig設定例：WebJarsをResourceHandlerに登録する
6-1 ライブラリ管理(WebJars)
課題
フロントライブラリも一元管理し、不要なプラグインの利用に起因する問題を抑制したい
アプローチ
前提
弊社のエンジニア構成はサーバサイドエンジニア中心のため、社内標準ではSpring Boot＋
Thymeleaf構成を採用しています
凡例
Spring標準
拡張実装

例）Thymeleafテンプレートにはバージョン指定不要
→フロントライブラリはlayout.htmlで一元管理する
例）実際に出力されたHTML
→バージョンが自動付与される
6-1 ライブラリ管理(WebJars)

静的コンテンツファイルの更新時に必ず発生するキャッシュ問題。
SpringBootでは容易にキャッシュ制御ができるため、
万が一自身のプロジェクトに設定されていない場合は、必ず以下設定を入れてください。
例) application.yml
上記の設定だけで、静的ファイルの内容からMD5ハッシュが付与された形でリンクが作成される。
↓
6-2 キャッシュ制御
課題
本番リリース時にWebブラウザのキャッシュによる不具合を防止したい
開発時も、対顧客やテストチーム等との無駄なやり取りを抑制したい
アプローチ

弊社では、以下技術を採用し、ミドルウエア構築の自動化を実施しています。
– Docker（ミドルウエア構築の自動化）
– Flyway（DBマイグレーション）
Dockerは、dockerコマンドを利用する方針でも良いのですが、Gradle Docker pluginを利用
し、静的ライブラリの管理同様、gradleで一元管理できるようにしました。
例）Dockerプラグインを利用したtask定義
→docker build、docker run等のdocker操作コマンドをタスク定義
→開発者はDockerを意識せず個人の開発環境を利用可能
7-1 開発環境管理(Docker/Flyway)
課題
実行環境による差異をなくしたい
新規参画者の環境構築コストを最小化したい
アプローチ

Dockerでのミドルウエア設定同様、DB定義もバージョン管理し、最新の断面が再現できる状況が好
ましいです。
弊社基盤では、Flywayを利用し、DBマイグレーションによりDB構築を自動化しています。
例）application-development.yml
→Flywayを有効化
例）マイグレーションファイルの配置
7-1 開発環境管理(Docker/Flyway)

テストコードには、仕様・処理の明確化が求められます。
チーム開発で明確な方針がない場合、テストコードの仕様理解や変更時のメンテナンスに工数が割
かれ、開発スピードが落ちてしまいます。
弊社では、以下観点より、Spockを採用しました。
– ブロック記法による記述の統一
– DSLを使った簡潔で分かりやすい記述
Before) After)
→when(テスト対象となる動作を記述)、then(whenの実行結果として、期待される条件を記述)等
のブロック記法で仕様をより明確に
→設計者によるテスト仕様レビューの敷居が下がる
7-2 テスト管理(Spock)
課題
テスト仕様の明確化、テスト仕様レビュー工数の最小化
アプローチ

8-1 Spring Profiles
データベースの接続設定やログレベルの設定等、開発環境と本番稼動時に切り替えたい設定が多々あ
ります。本番リリース時に本番設定用のファイルを上書きしてビルドする方法を採用してい方も多い
と思います。Spring Bootでは、設定ファイルの切り替えという課題に対し、Profilesという仕組み
が用意されています。
例）開発環境（application-development.yml）と本番環境（application-production.yml）の設定
ファイルを用意
例）application.ymlの設定例以下の例は開発環境をデフォルトとしている
課題
各環境ごとの設定を管理したい
各環境へのビルド方法を均一化したい
アプローチ

8-1 Spring Profiles
Springでは、起動時に有効なプロファイルを指定して、アプリケーションを起動することができます。
例）本番環境の起動コマンド JVMのシステムプロパティ -Dspring.profiles.active=production で起動
時のプロファイルを指定
→本番リリースするjarファイルはテスト済のファイルをそのまま持っていくことができる。※再ビルド不
要
■設定ファイル（application.yml）のパラメータの上書きについて
Spring Bootでは、設定ファイルの個別設定も起動時に上書きしてアプリケーションを起動できます。
上書きする方法は、以下の方法などがあります。
1. JVMのシステムプロパティ（上記例の指定方法）
2. コマンドライン引数（--spring.profile.active=production）
3. OSの環境変数（SPRING_PROFILES_ACTIVE=production）
例）コマンドライン引数を用いて、TymeleafのログレベルをDEBUGで起動する
例）OS環境変数を利用してアプリケーションポートを指定し、同一アプリケーションを複数起動する
java -jar -Dspring.profiles.active=production application.jar
java -jar –logging.level.org.tymeleaf=DEBUG application.jar
export SERVER_PORT=18081
java -jar application.jar #18081portで起動
export SERVER_PORT=28081
java -jar application.jar #28081portで起動

8-2 ロギング
課題
SI開発では、機能開発やデザイン調整が優先され、非機能要件の整理が後回しになることがあります。
ログ設定が適切でないことで、障害原因が特定できなくなることもあります。
SpringBootではデフォルトでロギングが有効となっており、デフォルトではlogbackが採用されます。
しかし、デフォルトではコンソール出力だけであるため、本番環境リリース時はログ出力設定は必須
となっています。
最低限の設定であれば、application.ymlで各コンポーネントのログレベル指定やログファイル出力
の可能です。
例）rootロガーをINFO、jdbcのログレベルをDEBUGにし、./log/app.logにログ出力
しかし、本番稼働を見据えると、以下の要望が発生する事が多いです。
– ディスク使用量調整のためのログローテーション
– 障害監視のための、アプリケーションエラー情報のみ別ファイルへの出力
上記課題に対し、
弊社では、Logback設定ファイルのlogback-spring.xmlを配置し、カスタマイズ設定する方針を採
用しました。
アプローチ

8-2 ロギング
Springで利用するlogbackは、Springと連動して、以下拡張設定が可能です。
– Spring Profiles連動
– Property連動
例）springProfileタグを利用し、Spring Profilesと連動する
例）springProPertyタグを利用し、application.ymlのプロパティ値をlogbackと連動する
凡例
Spring標準
拡張実装

8-3 アプリケーション状態
課題
障害等の想定外の挙動が発生した場合、アプリケーションの状態の確認が必要となります。
ログ確認で原因が特定できない場合、追加調査が必要となります。
Spring Bootでは、Spring Boot Actuatorを用いると様々な情報がHTTPアクセスで取得できます。
利用方法は、依存関係に「spring-boot-actuator」を追加するだけです。
例）gradleの設定例
追加されるエンドポイントの主要なものを紹介します。
endpoint 概要
/autoconfig AutoConfigureで有効になっているもの、無効になっているものを表示
/beans DIコンテナに管理されているBeanの一覧を表示
/env 環境変数、システムプロパティ一覧を表示
/dump スレッドダンプを表示する
/health ヘルスチェック
/metrics メトリクスを表示する
アプローチ

8-3 アプリケーションステータス
続いて、一般ユーザからこれらの内部情報をアクセスできなくなるよう設定する必要があります。
例）application.ymlの設定例
例）Endpoint（/metrics）の例メモリ、ヒープ、スレッド等のメトリクスが取得できる

8-4 JMX監視
課題
開発では機能開発やデザイン調整が優先され、非機能要件の整理が後回しになることがあります。
アプリケーション監視設定が適切でないと、サービス稼働後の運用対応が後手に回ってしまいます。
Spring Bootでは、JMX(Java Management Extensions)を有効にする事で、メモリ使用量、GC
の状況、セッション数等のアプリケーションの稼働状況を知る事ができます。
例）application.ymlの設定例
JMXを有効にしただけでは、アプリケーションの継続的なモニタリングはできないため、監視ツー
ルと連携して、アプリケーションのメトリクスを継続してモニタリングできる状況が望ましいです。
弊社では、監視ツールのZabbixと連携し、上記を実現していますが、ここでは、Zabbixの設定方
法は割愛します。
アプローチ

課題
通常の受託開発では、ソースコードの納品が必要になります。
納品した設定ファイルにデータベースの接続情報が平文で記載されているのはセキュリティ上
好ましくないです。
ここでは設定ファイルの暗号化の手順を紹介します。
まず、暗号化ライブラリを追加します。
例）gradleの設定例：依存関係に「jasypt-spring-boot-starter」を追加
続いて、JavaConfigで暗号化を有効にし、暗号化対象の設定ファイルを追加します。
→@EnableEncryptablePropertiesを指定し、暗号化を有効にする
→@EncryptablePropertySourceに暗号化対象ファイル（application.yml）を
列挙する
アプローチ
凡例
Spring標準
拡張実装

Jasypt.jarをダウンロードし、パスワードを暗号化します。
→ダウンロードしたjarを用い、javaコマンドでDBパスワードの「passw0rd」を、「master」
（鍵）で暗号化
最後に、設定ファイルに暗号化されたパスワードを指定します。
例）application.yml設定例
→defaultでは、ENC(暗号化されたパスワード)を指定する
鍵パスワード
暗号化されたパスワード

開発基盤を整備する時間を十分に用意することで、全体的な開発工
数は間違いなく下がるはずです。
本日紹介したサンプルで気に入った箇所はプロジェクトに取り入れ
て、より楽に開発しましょう！
最後に
https://github.com/miyabayt/spring-boot-doma2-sample
本日利用したソースコードは以下
フィードバックください。
architecture@bigtreetc.com

ご静聴ありがとうございました！

Spring Fest 2017 「エンタープライズで利用するSpring Boot」#jsug #sf_h1

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Spring Fest 2017 「エンタープライズで利用するSpring Boot」#jsug #sf_h1

Ähnlich wie Spring Fest 2017 「エンタープライズで利用するSpring Boot」#jsug #sf_h1 (20)

Spring Fest 2017 「エンタープライズで利用するSpring Boot」#jsug #sf_h1