Spring Fest 2017 の資料

エンタープライズで利⽤する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 設定ファイル暗号化

1 はじめに

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

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

2 アプリ構成概要

O/RマッパーにDoma、ビルドツールはgradleを利⽤ 2 アプリ構成概要 Spring Boot Jetty MySQL Spring MVC Doma ThymeLerf Spring Security

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

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

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

3 共通処理

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

確認⽤のパスワードのチェックを例に説明します。例）確認⽤のパスワードのチェックの実装 3-1 バリデーション凡例 Spring標準拡張実装

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

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

Spring MVCではコントローラでModelに情報をセットし、画⾯に情報を表⽰します。サービスから取得した情報をModelにセットする場合、処理を1⾏1⾏書く必要があります。例）ModelにaddAttributeで画⾯表⽰項⽬を設定 3-2 オブジェクトマッピング課題項⽬が多い詳細画⾯のコード量を削減したい単純な画⾯への表⽰項⽬追加対応でコントローラを修正したくないアプローチ

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

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

4 データアクセス

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

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

例）エンティティクラス →基底クラスを継承 4-2 エンティティリスナー凡例 Spring標準拡張実装

例）エンティティリスナークラス →システム制御項⽬の更新処理を共通化する 4-2 エンティティリスナー凡例 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標準拡張実装

5 セキュリティ

⼤抵のアプリケーションでは権限制御が必要です。弊社基盤では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. トークン制御による⼆重送信の抑制 5-2 ⼆重送信防⽌課題⼆重送信防⽌制御を基盤として実装しておきたいアプローチ

▪フォームの再送信禁⽌更新完了時は、参照画⾯にリダイレクトさせます。例）更新時にリダイレクトして、ブラウザ再読込でフォーム再送信させない 5-2 ⼆重送信防⽌参照画⾯に戻す

▪フォームへのトークン埋め込み RequestDataValueProcessorを実装し、⼊⼒フォームに⼆重送信防⽌のトークンを埋め込みます。例）カスタムトークンをhiddenに設定 5-2 ⼆重送信防⽌凡例 Spring標準拡張実装

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

▪⼆重送信チェック実装実際のエラー制御はエンティティリスナーで実装する。 Insert実⾏前にトークン⽐較を⾏い⼀致しない場合、例外をスローする。例）エンティティリスナー実装 5-2 ⼆重送信防⽌凡例 Spring標準拡張実装

▪コントラーでのエラーハンドリング ControllerAdviceを実装し、例外をハンドリングする。例）ExceptionHandlerで例外ハンドリングし、エラー情報を設定した後、編集画⾯に戻す 5-2 ⼆重送信防⽌凡例 Spring標準拡張実装

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

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

6 静的コンテンツ

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ブラウザのキャッシュによる不具合を防⽌したい開発時も、対顧客やテストチーム等との無駄なやり取りを抑制したいアプローチ

7 チーム開発

弊社では、以下技術を採⽤し、ミドルウエア構築の⾃動化を実施しています。 – 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 運⽤

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の設定⽅法は割愛します。アプローチ

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

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

最後に

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

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

Spring Fest 2017 の資料

Spring Fest 2017 の資料

More Decks by Thirosue

Featured

Transcript