現場至上主義SpringBoot2徹底活用#

スターター#

• 一連の依存関係をセットとしてそろえるためのモジュール

• 必要なライブラリを準備したり、それぞれのバージョンを選定したりする煩わしい作業から解放される

• たとえば、spring-boot-starter-webを１つ依存関係に追加するだけで、SpringMVCやTomcatなど、Webアプリケーションに必要なライブラリがセットになって追加される

• 以下はスターターの例

  • spring-boot-starter-web : SpringMVC Tomcatが依存関係に追加される
  • spring-boot-starter-jdbc : SpringJDBC Tomcat JDBC Pool が依存関係に追加される

• スターターリファレンスページ

• 自分でスターターを作成する際は、*-spring-boot-starterという命名規則が定められていることに注意

ビルドツール#

• Spring Bootの推奨ビルドツール

  • ApacheMaven
  • Gradle

• 本書ではGradle

  • メリット
    • スクリプトを記述するタイプのビルドツールのため、Antのようにタスクを自由に記述することができる
    • マルチプロジェクト構成の場合は、サブプロジェクトに対して一括設定して、必要に応じて個別に設定することができるため、記述量がMavenよりも少なくなる
    • Mavenの場合は、特殊な処理が必要になった時に独自プラグインを実装する必要があるのに対し、Gradleはスクリプトを書くだけで対応できる

• Maven

  • Mavenを利用する場合、spring-boot-starter-parentプロジェクトを親プロジェクトとして継承することで、プラグインのデフォルト設定、依存ライブラリのバージョンの定義、Javaコンパイラー準拠レベル、文字コードを引き継ぐことができる

• 親プロジェクト設定

1
<!-- Inherit defaults from Spring Boot -->
2
<parent>
3
  <groupId>org.springframework.boot</groupId>
4
  <artifactId>spring-boot-starter-parent</artifactId>
5
  <version>2.0.6.RELEASE</version>
6
</parent>

• Gradle

  • Spring Boot2.0.xはGradle4.0以降に対応している
  • GradleはMavenと違って、設定を引き継ぐための親プロジェクトが存在しないため、単に、スターターを依存関係として追加します
  • spring-boot-gradle-pluginというGradleプラグインが用意されており、実行可能なJarファイルを作成するためのタスクを利用できる

• ビルドスクリプトの処理内容

  1. spring-boot-gradle-plugin をビルドスクリプトの依存関係に追加する
  2. spring-boot-gradle-plugin と dependency-management プラグインを利用することを宣言
  3. Javaコンパイラー準拠レベルをデフォルトの1.8から11に変更
  4. 文字コードはUTF-8であることを指定する
  5. スターターをアプリケーションの依存関係に追加する
  6. テスト用のスターターをアプリケーションの依存関係に追加する

依存関係の管理#

• すべてのライブラリのバージョンを１つずつ指定するというような作業をする必要はない
• 依存関係に定義されているライブラリも一緒にバージョンアップする
• Spring Bootのバージョンを上げる場合は、Project Wikiに載っているリリースノートを確認すること

コンフィグレーションクラス#

• Spring BootはJavaベースのコンフィグレーションが好まれる

• 従来通りXMLファイルに記述できるが、推奨されるのは@Configurationアノテーションを付与したクラスによるコンフィグレーション

• MVCの設定のこと？再度確認する

オートコンフィグレーション#

• Spring Bootは設定を変更しなければ、あらかじめ敷かれたレールに沿って動作するようになっている

メインアプリケーションクラス#

• SpringBootのアプリケーションを起動するメソッドを呼び出すクラス

• Javaアプリケーションのエントリポイントとなるmainメソッドの中で、SpringApplicationクラスのrunメソッドを呼び出すと、組み込みのTomcatが立ち上がり、SpringIoCコンテナの初期化が行われる

• ※再読

設定ファイル#

• アプリケーションを起動すると、次の場所にあるapplication.properties設定ファイルを読み込む

  1. カレントディレクトリの/configサブディレクトリ
  2. カレントディレクトリ
  3. クラスパスの/configパッケージ
  4. クラスパスのルート

• 上から順番に優先度が高くなる

• プロファイルという単位で別々の設定を持たせることも可能

• 設定ファイルはyml形式でもOK

• application.ymlを配置することで使用可能

• 設定ファイルの値を参照するのも簡単

Colum 外部設定ファイルの種類#

• 環境変数

• システムプロパティ

• コマンドライン引数

• いろんな渡し方がある

• けど、アプリケーションプロパティしか使わないのではと思う

アプリケーションの起動#

• コマンドラインで起動 gradle bootRun
• InteliJ IDEAを使って起動する

Restart vs Reload#

• JVM hot-swapping をよりよいものにしたい場合

  • JRebel(有償)または、Spring Loaded(無償の内部で利用されている) の利用を検討する

• もう一つの方法として、Dynamic Code Evolution VM(DCEVM) HotSwapAgentを使ったJVM hot-swapping がある

  • JDKにパッチをあててクラスの再定義機能を強化してくれる
  • Spring Loadedでは対応していないクラス追加に対してもhot-swappingが働く

• DCEVM + HotSwapAgentの導入方法

  • jarファイルをインストール http://dcevm.github.io/
  • java -jar DCEVM-*-installer.jar 実行

• Intelij IDEA プラグイン設定

  • HotSwapAgent をインストール
  • Settingより設定する

マルチプロジェクト#

• 本書で用いるサンプルプロジェクトは複数のモジュールで構成されるマルチプロジェクト
• メリット
  • ビルドスクリプトを共通化することができるので記述量が減る
  • ローカル・リモートリポジトリにアーティファクトをアップロードしなくてもソースコードの変更が反映される
  • それぞれのプロジェクトを関連付けてタスクを実行できる

アプリケーション・アーキテクチャ#

• プレゼンテーション層
  • プレゼンテーション層は、入力された値を受け取って、値をチェックしたり、値の変換を行ったりする層
  • WebモジュールのFormクラス、FormValidatorクラスが該当
• アプリケーション層
  • プレゼンテーション層から受け取った値をドメイン層に渡す層で、WebモジュールのControllerが該当する
  • ビジネスロジックは含まれないが、画面遷移先を制御したり、セッションを用いて、次画面に値を渡したりといった処理を行う
• ドメイン層
  • ドメインオブジェクトを持ち、ビジネスロジックを処理するメインの層で、ドメインモジュールのServiceクラスが該当する
  • ドメインオブジェクトはすべての層から利用されるが、逆にドメイン層はほかの層に依存してはならない点に注意する！
• インフラストラクチャ層
  • インフラストラクチャ層では、ドメイン層から渡されたデータを永続化する層
  • ドメインモジュールのRepositoryクラスが該当する
  • アプリケーション層の影響を受けないように、汎用的な部品としてつくるようにすること！

サンプルプロジェクトのビルドスクリプト#

1. Spring Bootのバージョンを拡張プロパティにセット
2. テストコードはSpockフレームワークを利用するため、Groovyを扱えるようにする
3. すべてのサブプロジェクトにおいて spring-boot-gradle-plugin を利用できるようにする
4. すべてのサブプロジェクトにおいて dependency-management プラグインを利用できるようにする
5. Javaコンパイラー準拠レベルを１１に変更する
6. src/main/resources をクラスパスに追加して、開発中の変更がすぐに反映されるようにする
7. リソースファイルの出力先をソースファイルの出力先に変更する
8. コンパイルの前に、リソースファイルの出力を行うようにする
9. Domaの依存関係にあるバージョン違いの Spring Boot を除外する
10. Spring Session モジュールを使ってセッション情報をデータベースに格納する
11. Gradleのプロジェクトプロパティを bootRun の引数に渡せるようにする

1
// メインアプリケーションクラスを持たないモジュールの場合（build.gradle）
2
bootJar {
3
  enabled = false
4
}

Lombokを利用する#

• ボイラープレートコードの削減のため
• アプリケーションの実行時には不要なので、スコープはcompileOnlyに設定
• 型valが使用できる
  • MEMO: これを使うと長い型を３文字でかけるよっていうことらしい

メッセージの設定#

• Bean Validator はメッセージを外部ファイルで管理するためのMessageSourceを内包している

• デフォルトでは文字コードがUTF-8 になっていないので、エラーメッセージを表示する際に文字化けてしまう

• application.yml

1
# 共通の設定を定義する
2
spring:
3
  messages:
4
    # メッセージ定義ファイルのパスを含めて設定する
5
    basename: messages,ValidationMessages
6
    cache-duration: -1
7
    encoding: UTF-8 # P40. デフォルトのままだと文字化けするため指定

Colum メッセージを定義するファイルを分割する#

• application.ymlのbasenameにカンマ区切りで複数指定可能
  • ValidationMessage:バリデーションのエラーメッセージを定義する
  • PropertyNames:エラー項目の項目名を入力フォームごとに定義する
  • messages:バリデーションとは関係ないシステムメッセージなどを定義する

バリデーションの種類#

• バリデーションの種類

  • クライアントサイド
  • サーバーサイド

• 本書はサーバーサイドのバリデーションについて説明

• 単項目チェック：Bean Validation APIで提供されるアノテーションを利用できる

• 相関項目チェック：org.springframework.validation.Validatorインターフェースの実装クラスを作成するか、自作のアノテーションを実装する

単項目チェック#

• javax.validation.constraintsパッケージに定義されている

• spring-boot-starter-validationスターターは Bean Validationの実装ライブラリーとして、Hibernate Validatorを依存関係に追加しているので、Hibernateで定義されたアノテーションも使うことができる

• 参考URL

  • https://beanvalidation.org/2.0/

• Formオブジェクトに@NotEmptyなどのアノテーション付与

• Controllerの@PostMapping("/new")を付与したメソッドの引数に@Validatedを付与し、Formオブジェクトを第一引数に指定

• チェック結果が、第二引数のBindingResultに入るので結果をチェックする

Column PRGパターンについて#

• PRGパターンでは、Post-Redirect-Getメソッドを組み合わせて、以下の流れで登録処理を行う実装パターン

1. 保存ボタンを押したとき、POSTメソッドを使い、サーバーにリクエストする（P）
2. 入力値をDBに保存するといった一連の処理を行い、詳細画面にリダイレクトする（R）
3. GETメソッドで詳細画面が表示される（G）

• サンプルプロジェクトはほぼすべての機能において、PRGパターンを適用している
• メリット
  • ブラウザの戻るボタンを押しても、フォーム再送信のダイアログを表示しないようにすることができる

相関項目チェック#

PDFファイルのダウンロード#

帳票出力の代表的なライブラリとして、JasperReportsがある JasperReportsは、.jrxmlという拡張子のXMLファイルで帳票のレイアウトをテンプレートとして定義して帳票を出する際に対象データを引数に渡すことで帳票を出力します。 テンプレートファイルはJasperSoftStudioというEclipseベースの帳票デザインツールを使って作成

SpringMVCには、JasperReportsをサポートするViewクラスが提供されていたが、SpringFramework5から機能が除外されている

そのため、JasperReportsライブラリを直接使ってPDF出力するPDFViewクラスを実装して、引数にデータを渡すだけでPDF出力ができるようにします。

CSVファイルのダウンロード#

CSVファイルのダウンロードは、jackson-dataformat-csvを利用するとシンプルに実装することができる

• CsvViewクラス
• Entityクラス
• Controllerクラス

Excelファイルのダウンロード#

Excelファイルのダウンロードの場合は、org.springframework.web.servlet.view.document.AbstractXlsxViewを利用 AbstractXlsxViewはApachePOIに依存しているのでバージョンまで指定して依存関係を記述します PDFファイルの場合と同様で、ファイル名に日本語文字が含まれると文字化けが生じてしまうので、子クラスを作成して対応

ファイルサイズの設定#

• １ファイルのサイズ上限は１MBで、１リクエストで受け付ける上限は１０MBになっている

1
spring:
2
  servlet:
3
    multipart:
4
      max-file-size: -1 # デフォルトは1MB　-1だと無制限
5
      max-request-size: 20MB # デフォルトは10MB

ファイルの取扱#

ファイルのデータベースへの格納#

• TODO: 後で画像保存する処理実装する

エンティティ基底クラス#

エンティティ基底クラスを用意し、共通的に使うフィールドを定義することができる

@Entityアノテーションにリスナーを指定すると、更新・登録・削除のタイミングで共通的な処理を実行することができる

• TODO: 共通項目実装

楽観的排他制御#

データ不整合を保険的に防ぐ方法 複数人が同じデータを編集してしまった場合に、先に保存したほうの編集内容が後から保存した内容で上書きされてしまうといったことを防ぐことができる

Domaを使って楽観的排他制御を行うには以下の条件を満たす必要がある

• エンティティのフィールドに@Versionアノテーションが付与されている

• Daoインターフェースに付与したアノテーションのignoreVersionをtrueにしていない

• テーブルに数値型の改定番号カラムが定義されている

• 流れ

  1. Formオブジェクト二改定番号のフィールドを定義する
  2. コントローラに@SessionAttributeアノテーションを付与する。
  3. 編集画面の初期表示処理で改定番号を含めてデータを取得して、Formオブジェクトに詰め替える
  4. 更新処理で、更新対象データを取得して、そのデータをFormオブジェクトの値で上書きする
  5. Daoの更新処理を呼び出す（ここで排他制御がかかる
  6. 不要になったFormオブジェクトをセッションからクリアする

• TODO: 楽観的排他制御について深堀り、実装→悲観的排他制御だけでアプリとしては回せそう

• Column セッション情報の格納先について

  • 楽観的排他制御の説明の中でSessionAttributeを使ってFormオブジェクトをセッション情報に保存する方法を紹介しました。サンプルプロジェクトでは、SpringSessionモジュールを依存関係に追加しているので、SpringBootによるオートコンフィグレーションが行われます。SpringSessionには、以下の格納先に対するオートコンフィグレーションが用意されています。
    • JDBC
    • Redis
    • Hazelcast
    • MongoDB
  • セッション情報の格納先を変更したい場合は、設定ファイルにリスト3.11を記述することで変更することができます。
    • redisにする場合：spring.session.store-type=redis

• TODO: セッションの格納先はREDISにする

悲観的排他制御#

データベースの行ロック機能を使った排他制御で、在庫数のような頻繁に同時更新がかかるようなデータの整合性を担保する方法として利用される

Domaでは、悲観的排他制御を行うための仕組みも用意されていて、ページング処理の説明と同じ用に検索オプションを使う

悲観的排他制御を行うときに注意すべきなのは、検索結果が０件になるような条件で検索すると、行ロックではなくテーブルロックがかかる点です！！！ 処理時間が長い処理でテーブルロックがかかってしまうと、処理の滞留が発生してしまい、システム全体が不安定な状態二なることもあるので注意する

更新機能による実現#

• @Update(excludeNull = true) // Nullの項目は更新対象にしない

エンティティリスナーによる共通処理#

• リスナーの中のpreUpdateメソッドの中で、メソッド名が論理削除のメソッド名と一致するかを確認する

論理削除レコードの除外#

• 論理削除を行うことをアプリケーション内で統一している場合は、データ取得のSQLに、論理削除フラグによる削除データの除外が行われる用にする必要がある

• Column 参考文献

  • BLOG.IK.AM https://blog.ik.am/
    • 初めてのSpringBoot著者
  • SlideShare Toshiaki Maki https://www.slideshare.net/makingx

認証情報の取得#

• UserDetailsServiceをimplementsして実装する方法
• TODO: 権限周りが実装できていないので見ておく

ログイン機能#

ログイン機能のコントローラを実装します。 デフォルトでも組み込みのログイン画面を表示することが可能ですが、ほとんどの場合において画面を変更する必要があるので、Thymeleafテンプレートを使ってログイン画面を表示する用に実装し、それ以降の処理はSpringSecurityと連携するようにします。

• TODO: タイムアウト処理やログイン成功処理など実装の必要があればサンプルを基に実装する
  • /authorize　にfowardできなくて、formオブジェクト経由のエラーチェックが実装できなかった

ログイン記録の永続化#

• TODO: 自動ログイン機能は必要になれば実装しておきたい
  • 合わせて不要なレコードを削除する機能も実装する必要がある

権限管理データをロード#

権限とメソッドの紐付け#

認可制御のインターセプター#

• TODO: 権限管理はあとで見直す

事前評価の実装例#

• 表示する言語を翻訳する例が紹介されている
• FormBeanの値と、実際に表示したい値が異なる場合に有用だと思う
• <p th:text="${@myapp.translator.Translator@translateToEnglish(textVar)}">some text here ...</p>

テンプレートの部品化#

• includeとreplaceの話

テンプレートの共通化#

レイアウトという機能でテンプレートの共通化をサポートします HTMLのレイアウトやJavaScriptおよびCSSのインクルードを一元管理できる 本機能を用いてテンプレートの共通化を採用することでソースコードの保守性や品質も向上するため、積極的に導入すべき機能

1
  compile('nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect:2.3.0') {
2
    exclude group: "org.codehaus.groovy", module: "groovy"
3
  }

1
@Configuration
2
public class WebConfig extends WebMvcConfigurer {
3
  @Bean
4
  public LayoutDialect layoutDialect() {
5
    return new LayoutDialect();
6
  }
7
}

• レイアウト機能を利用するために、xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"を指定する

• layout:fragment="任意の文字列"で各ページで差し替えるエリアを指定する

• MEMO: Spring徹底入門でも紹介されていたが、画面の全体像がわかりづらくなりやすいためincludeを用いることにする

エスケープなしのテキスト#

• 通常、クロスサイトスクリプティング対策のためSpringはタグ文字列をエスケープして表示している

• 場合によってはエスケープしないで、文字列を表示したいケースがある

• <p th:utext="#{home.welcom}">Welcom to our grocery store!</p>

• このutextを利用する場合は、XSSの脆弱性を含まない用に注意が必要

日付操作拡張#

Thymeleafでは、Date/TimeAPIをデフォルトでサポートしていないため拡張ライブラリーを使用する必要がある

1
  // https://mvnrepository.com/artifact/org.thymeleaf.extras/thymeleaf-extras-java8time
2
  compile group: 'org.thymeleaf.extras', name: 'thymeleaf-extras-java8time', version: '3.0.4.RELEASE'

1
<input class="form-control" type="text" name="holidayDate"
2
 th:value="${(value != null) ? #temporals.format(value, 'yyyy/MM/dd') : '' }" />

※その他にもThymeleafは各種の拡張機能をサポートしている

静的コンテンツの配置場所#

SpringBootでは、SpringMVCのオートコンフィグレーションに以下の設定がされており、デフォルトでは次の４点のパスに静的コンテンツを配置できる

• /resources/
• /static/
• /public/
• /META-INF/resources/

キャシュ制御#

キャッシュする時間は、application.(properties|yml) や ResourceHandlerRegistryのオーバーラードで調整

1
spring:
2
  resources:
3
#    cache-period: 86400 # 1日間キャッシュさせる
4
    chain:
5
      strategy:
6
        content:
7
          enabled: true # 静的コンテンツのキャッシュ無効設定 MD5ハッシュが計算される バージョン管理戦略と呼ばれるらしい
8
          paths: /**

• TODO: バージョン管理戦略を実施した場合のキャッシュの挙動を確認しておく

アクセス制御#

Faviconなどの画像ファイルやクライアントライブラリは未認証、認証にかかわらずアクセスできる必要がある SpringBootでは、SpringSecurityのオートコンフィグレーションにリストの設定がされており、デフォルトで次の５点のパスはpublicアクセス可能

しかし、SEOに必要なrobots.txtやsitemap.xmlは含まれないため、これらのファイルをPublicアクセス可能とするには、JavaConfigで設定を上書きする必要がある

• デフォルトで許可されている５点

  • /css/
  • /js/
  • /images/
  • /webjars/
  • favicon.ico

• TODO: SEO対策に必要な知識を習得しておく必要がある

1
  private static final String[] STATIC_RESOURCES = {
2
      "/favicon.ico", "/css/**", "/js/**", "/img/**", "/lib/**", "/font/**"
3
  };
4
  @Override
5
  public void configure(WebSecurity web) {
6
    // セキュリティ対策が不要なリソースがある場合、SpringSecurityの処理を適用しないようにする
7
    //    web.ignoring().antMatchers("/resources/static/**");
8
    web.ignoring().antMatchers(STATIC_RESOURCES);
9
  }

クライアントライブラリの構成管理#

サーバサイドエンジニア中心のチーム構成だとフロントライブラリの管理が抜けてしまうことがよくある

本項では、WebJarsを用いてクライントライブラリを管理する方法を紹介

• Dependenciesの追加方法を説明

1
  // https://mvnrepository.com/artifact/org.webjars/webjars-locator-core
2
  compile group: 'org.webjars', name: 'webjars-locator-core', version: '0.45'

API仕様#

リソース実装#

コントローラ実装#

エラーハンドリング実装#

@RestControllerAdviceアノテーションを指定して作成

RestTemplate#

SpringではRestTemplateというRESTクライアントを提供している RestTemplateを用いると、Javaオブジェクトとレスポンスボディの変換も容易に実現できる

ユーザー一覧取得APIへの連携#

ユーザー作成APIへの連携#

Swaggerとは#

OpenAPI仕様に基づくAPI開発ツールのフレームワークであり、APIのライフサイクル全体に渡って、設計から文書の管理、テストおよびデプロイまでを可能にします。

• 大きな利点は以下の４つ

  • OpenAPI準拠
  • YAMLを用いた宣言的な記法
  • コード自動生成
  • エコシステムの充実（SwaggerHub）

• OpenAPI準拠

  • マイクロソフト、Googleなどの大手の企業を含むOpenAPIInitiativeがLinuxFoundationの協力のもとで結成され、APIの記述のために採用したのがSwagger
  • API管理のデファクトスタンダードと呼ばれるほど普及している

• YAMLを用いた宣言的な記法

  • SwaggerはAPI定義をYAML(JSON)により宣言的に記載できます。
  • また、定義したYAMLからSwaggerUIというツールを用いると、HTMLベースの定義書やモックを作成できます。
  • SwaggerUIを利用し、APIを公開すると、クライアント側は動く仕様としてAPIを参照できるため、API連詠によるコミュニケーションコストを低下させることができます。

• コード自動生成

  • Swaggerには、Swagger CodegenというSwaggerUIで公開されたAPI仕様を基にコードを自動生成するツールがある

TODO: Dockerを用いてSwaggerCodegenを用いたスタブサーバーの起動例　確認しておく

• エコシステムの充実(SwaggerHub)
  • SwaggerCodegenを用いてスタブサーバーを起動し、開発チームで共有する方針も悪くないですが、ホスト環境の管理やAPI仕様の変更の都度、コードの再生成および再起動が必要になります。
  • Swaggerはエコシステムも充実しており、SwaggerHubというAPI管理のプラットフォームがあります。
  • SwaggerHubはSwaggerを使ったモックサーバーやテスト環境などAPI管理に関するサービスをまとめて提供しているため、APIの管理工数を下げることが可能です。
  • SwaggerHubはAPIドキュメントの編集/表示、モックサーバーの立ち上げ、SwaggerCodegenの機能などをブラウザベースで提供しています。

TODO: SwaggerHubは一回使ってみる必要あり！！！ →お金かかるから断念… チーム開発に有用かも？

Springでの利用(SpringFox)#

SwaggerでのAPI管理がデファクトスタンダードになっていること、Swaggerを利用することのメリットを説明しました。 本項では、SwaggerをSpringで利用する方法を説明します。

Springでは、SpringFoxを用いるとAPIドキュメントの自動生成が可能 SpringFoxはSwaggerUIの提供もサポートしているため、APIを用いたチーム開発を円滑にすすめることができる 次の手順に従い、SpringFoxの利用方法を説明

• 依存関係の設定
• 共通設定カスタマイズ
• 個別エンドポイントのカスタマイズ
• 静的ドキュメント生成

1. 依存関係の設定

1
// https://mvnrepository.com/artifact/io.springfox/springfox-swagger2
2
compile group: 'io.springfox', name: 'springfox-swagger2', version: '2.9.2'
3
// https://mvnrepository.com/artifact/io.springfox/springfox-swagger-ui
4
compile group: 'io.springfox', name: 'springfox-swagger-ui', version: '2.9.2'

2. 共通設定カスタマイズ(JavaConfig)

1
@Configuration
2
@Import({ ThymeleafConfig.class, // Thymeleafを使用することを明示
3
    GoogleAutoConfiguration.class })
4
@EnableSwagger2
5
public class AppConfig implements WebMvcConfigurer {

APIControllerのみグルーピングする方法を紹介

3. 個別エンドポイントのカスタマイズ

アノテーションでAPIごとの説明を追加できる

4. 静的ドキュメント生成

SwaggerUIを動的に生成する方法は、API連携開発の効率を上げてくれるため、開発フェーズでは導入しておくと効果的

しかし本番サービス稼働後に上述の手順を有効化しておくと、SwaggerUIの外部公開制御が必要になります

本項では、別のアプローチとして、SwaggerのAPI定義から静的ドキュメントを生成する方法を紹介

• 依存関係の設定

• テストクラスの追加

• HTML変換

• 依存関係の設定

  • SwaggerからAsciiDocへの変換をサポートしているSwagger2Markupというライブラリがある
  • Swagger2MarkupをSpring向けにカスタマイズした、springfox-staticdocsを依存関係に追加する

• テストクラスの追加

  • テストコードを作成し、CIサイクルに含めておくと、静的なドキュメントのAsciiDocが自動生成される

• HTML変換

  • HTMLへの変換はasciidoctorを利用する

TODO: HTMLへ変換するCI構築する

Spring REST Docs#

Springでのドキュメント生成の自動化には、Spring REST Docsを採用する方法もある

• 利点

  • テストをパスしないドキュメントは作成されないため、「動く仕様書」として信頼できる。
  • asciidoctorを用いた簡潔な記法

• 手順

  • 依存関係の設定
  • 雛形生成
  • テストコード生成

Docker#

「私のローカル環境では再現しません」をなくそう 秘伝のたれ的な作業が影響して、このような環境差異によるトラブルが発生しがち

コンテナ技術のDockerを用いて、環境構築手順をコード化してGithubなどにコミットし、環境の使い捨てができる状態にしておくことで、上述のようなトラブルを抑制できる

• メリット

  • インフラ構築手順のコード化（Dockerfile）
  • 環境依存性による問題の排除
  • 廃棄容易姓

• Column クラウドベースの統合開発環境（AWS Cloud9）

  • ここ数年、ブラウザのみでコードを記述、実行、デバッグできる統合開発環境の利用が活発化している
  • ブラウザベースの統合開発環境の有名なサービスとして、AWS Cloud9がある
  • AWS Cloud9を利用すると、開発には非力なマシン（ipadなど）でも、いつでもどこでも開発が可能

• インフラ構築手順のコード化（Dockerfile）

  • 開発に関わる全ての文書は構成管理の対象とすることが望ましい
  • チーム開発では、アプリケーションプログラムは必然的に構成管理の対象となりますが、設計文書やインフラ構築手順は構成管理の対象外になってしまうことがある
  • インフラ構築手順のコード（Dockerfile）をSCMにコミットすることで、利用しているディストリビューション、設定ファイルの状態がコードで明確化されるため、インフラに関わるトラブルを抑制できる

• 環境依存性による問題の排除

• 廃棄容易姓

• Column Tweleve-Factor App

  • コンテナ開発が活発になってきているのと同時に、クラウドアプリケーション開発のベストプラクティスの１つとして、The Twelve-Factor Appが取り上げ垂れることが多くなってきています。
  • The Twelve-Factor Appは、Herokuのプラットフォーム開発での治験をプラクティスに落とし込んだもので、コードベース、依存関係、プロセス、並行性、廃棄容易姓、開発/本番一致などの１２の要素から構成されます。
  • アプリケーションをThe Twelve-Factor Appに適用させることができれば、コンテナベースの開発に適用していることになるため、オンプレミス、クラウドなどの実行環境に関わらずアプリケーションをデプロイできます。

TODO: The Twelve-Factor Appについて深堀り

• Windows10proではHyper-Vを有効化することでDockerを利用できます。
• ここでは、Windows10 Pro以外でDockerを利用する方法を紹介します
• VagrantとVirtualBoxでDocker環境を構築

TODO: VagrantとDockerのコマンドについて説明しているので再度理解した上で読んで見る SpringBootで利用するための設定についても記載があるので組み込んでおく

Flywayの利用#

• SpringBootで利用するための設定
  • 依存下院系の設定
  • プロパティ設定
  • マイグレーションファイルの準備

Spock#

言語仕様に、RSpecやScalaなどのよい点を取り入れており、大きく次の３点の利点がある

• 可読性
• データ駆動テスト
• Power Assertions

TODO: SpringでのSpockの利用方法を紹介 GroovyやScalaなどをキャッチアップする必要がありそう

Sphinx#

• Sphinxはドキュメントを簡単に作ることができるようにするツール

• セットアップ

  • Pythonを利用しているため、Pythonの実行環境が必要
  • Dockerを用いた方法を紹介

TODO: 後ほど実施

• Sphinxの特徴
  • テキスト(MarkDown)形式
  • CIとの相性がよい
  • 様々な出力形式をサポート

ソースジェネレータプラグインの導入#

• 次の手順で導入
  • GradlePluginの実装
  • GradlePluginの利用

TODO: 余裕があればソースコード生成の自動化を組めたら

• メンバー全員に自動生成の仕組みが浸透していない状態で導入すると、ごちゃごちゃするのであまりおすすめできないらしい

Spring Profiles#

開発/本番環境の柔軟な切り替え

環境ごとの設定管理#

ファイルを分ける方法を記載→理解しているので飛ばす

実行可能Jar#

以下を加えることでビルド時に依存下院系のあるライブラリを梱包したJarを容易に作成できる

1
bootJar {
2
  launchScript()
3
}

アプリケーションサーバーの設定及びリリース#

• systemdを用いたアプリケーションサーバーの設定

TODO:　jarファイルの生成とDocker組み合わせまでできたらやってみる

SpringBootActuator#

SpringBootには、Actuatorという安定運用に寄与する強力な機能があるActuatorを有効にすると、HTTPやJMX経由でアプリケーションの状態を確認でき、自前でヘルスチェックのエンドポイントを実装する必要はなくなる

• SpringBootActuatorを有効化する

1
  // https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-actuator
2
  compile group: 'org.springframework.boot', name: 'spring-boot-starter-actuator', version: '2.3.0.RELEASE'

上記の設定だけで、デフォルトではシャットダウンを除く全てのエンドポイントが有効になります

主要なエンドポイント#

• Beans

  • アプリケーションに登録されたBeanの一覧を取得します。Curlでのリクエスト例を紹介

• Environment

  • アプリケーションで利用している環境変数の一覧を取得

• Health

  • アプリケーションのヘルスチェック。AutoConfigurationの状態をもとにデータベース接続やDiskFullのチェックを実施します

• HeapDump

  • ヒープダンプファイルをHTTPエンドポイントから取得できる

• Mappings

  • アプリケーションのエンドポイントとリクエストパスのマッピング情報を出力します。SpringFoxなどを導入しなくてもアプリケーションのエンドポイントの詳細な情報が取得できる

• Metrics

  • アプリケーションの現在の状態を出力

• Thread Dump

  • スレッドダンプを取得します

• Prometheus

  • インフラサービス監視ツールのPrometheusへ連携するメトリクスを出力するエンドポイント
  • 2018/10現在、Prometheusエンドポイントを有効にするためには、ライブラリを追加する必要があるらしい

• Column Prometheusとは

  • サーバーやインフラなどのメトリクスを取得できるOSSの統合監視ソリューション
  • Prometheusはインストールや設定が容易で、かつ十分な機能を持ち管理しやすいという特徴を持ちます。
  • Go言語で開発されており、バイナリと設定ファイルを用意するだけで利用できる他、Zabbixなどと異なり、データを格納するデータベースを別途用意する必要もありません。
  • また、DockerやKubernetesといったコンテナ/クラスター管理ツールとの連携機能もあり、容易に監視対象を設定できるため、マイクロサービス開発を推進している企業での導入が増加

エルスチェックのカスタマイズ#

Actuatorのデフォルトのヘルスチェックも強力ですが、ヘルスチェックをカスタマイズすることも可能

システム独自のチェックをすることができる

HealthIndicatorインターフェースを実装するBeanを登録することで実現できる

SpringBootActuatorのセキュリティ制御#

アプリケーションの機密情報を取得できるため、システム管理者以外からのアクセスは遮断する必要がある

Spring Boot 2系では、/info, /health以外のエンドポイントはデフォルトで認可ありとなります。 認可なしにしつつ、Listenポートの変更及び接続元IPを制限する設定は以下

Prometheus#

• メリット
  • 導入の敷居の低さ
  • クラウドネイティブ時代に適した設計
  • オープンソース

なお、本番環境のトータルの運用コストを見据える場合は、有償の監視サービスのMackerelやDatadogも検討対象にしてみる

Prometheusの導入#

• インストール方法は次の３つ

  • バイナリのダウンロード
  • Docker
  • ソースビルド

• PrometheusのDownloadページよりターゲットOSのファイルをダウンロードし、展開するだけでインストールは完了

Prometheusのサービスディスカバリー#

Prometheusにはサービスディスカバリ機能が備わっており、サービスの拡張に自動で追従します。 例えば、AWS EC2を利用している場合、サーバーの増減に自動で追従します

Springアプリケーションとの連携#

• SpringActuatorとPrometheusは連携できる
• 設定する方法を記載

メトリクスの可視化#

単体でもメトリクスの可視化はできるが、Grafanaと連携すればより強力にビジュアライズできる

• ダウンロード
  • バイナリのダウンロード
  • パッケージマネージャインストール

アラート通知#

Prometheusは複数のコンポーネントで構成されており、アラート通知もオプション構成となっている

• AlertManagerのインストール

  • アラート通知を実現するためには、Prometheus本体のPush通知を処理するAlertManagerのインストールが必要
  • バイナリファイルをダウンロードして展開する

• Slack通知設定

  • 本書では、Slack通知の設定方法を説明
  • AlertManagerはメール、HipChatなどの連携をデフォルトでサポートしています

TODO:　このあたりは見返して設定していきたい

nginxトレース#

静的コンテンツ配信の最適化やプロキシ用途でnginxを導入することは多く行われる

nginxは以下の用に設定すると、リクエストIDがCookieに付与される

1
userid           on;
2
userid_name      uid;
3
userid_domain    example.com;
4
userid_path      /;
5
userid_expires   365d;

nginxとのトレースIDの統合#

前項では、ミドルウェア（nginx）でリクエスト追跡IDを発行する方法を紹介 リクエスト追跡を切れ目なく実現するために、nginxとリクエスト追跡IDの統合の方法を紹介

リクエスト追跡機能は横断的関心事（cross-cutting concerns）のため、SpringAOPで実装する方針が望ましいと言えます

• RequestTrackingInterceptor.javaに実装した内容のことを説明していた

• Column ログ集約ソリューション

  • 複数台構成のアプリケーションをステートレスにと持つことを望ましい構成とすると、各アプリケーションサーバーにSSH接続してログを確認する方法では運用が大変
  • 上述の課題に対応するためには、ログ集約の仕組みを導入する方法がよい
  • ログ集約のソリューションとしては、商用のSplunk、DatadogやOSSのFluentd、Logs、AzureではLogAnalyticsなどの仕組みがある。アプリケーションを複数台で運用する際はこれらのソリューションの導入も検討してみて

TODO: OSSのFluentdは使ってみたい

Spring Cloud Sleuth#

FrontentとBackendで同じIDを出力して処理を追うことができますよっていう説明 RestTemplateを使用する必要があるみたい

ここでレイテンシが図られる様子 Zipkinで可視化できるみたい

ローリングデプロイ#

ローリングデプロイ作業フロー#

• Step1. アプリサーバー#1へのデプロイ
  • プロキシサーバーからアプリサーバー#1へのリクエスト振り分けを停止
  • アプリサーバー#1のアプリケーションをデプロイ

ローリングデプロイ作業手順#

TODO: nginxの設定ファイルの変更方法も記載しているので後で参考にして設定しておきたい

コンテナイメージの作成#

TODO: Kubernetesを使ったコンテナ管理…後でDockerを一通り使い倒した後確認する

システムが必要とする要件#

• 要件
  • 可用性：稼働率は99.9%以上を目標とすること
  • 拡張性：スループットの増加に対して、サービスが低下しない性能を維持するための資源の追加が容易に行えること
  • 完全性：データの操作にはACIDを保証し、データの堅牢性を実現すること

システム要件の検討#

• 可用性

  • システム構築ではSLAが明記されることが普通
  • サービス品質がSLAの保証値を著しく下回った場合には、ペナルティが発生することもあります。
  • SLAに可用性99.9%と記載されている場合、数値として年間にして９時間弱、月間にして４４分弱以内の停止しか許さないシステム構成を検討する必要がある

• 拡張性

  • システム構築では、サービス特性によりシステムへの負荷がばらついたり、突発的な高負荷が発生したりすることがあります。
  • 可能な限りシステムリソースのスケールアウト及びスケールインできるように設計することが望ましいと言えます。

• 完全性

  • システム構築では、システムじの状態をRDBなどのデータストアに保管することが普通
  • システムで保管した情報資産が正当な権利を持たない人により変更されていないことを確実にしておくよう設計する必要があります。また、データの消失を防ぐための対策も実施していく必要があります

• コスト

  • Capter8で解説したように、運用コストはシステム開発全体の3/4以上のコストを締めます。
    • システムリソースの運用コスト（ハードウェアコストやライセンスコストなど）
    • システム運用のコスト（人件費など）

構成要素一覧#

可用性#

拡張性#

コスト#