11/24(金)に行われた「Spring Fest 2017」というイベントに参加してきたので、 自分が聴講したセッションのアバウトな内容と、自分の所感まとめます。
springfest2017.springframework.jp
セッション内容もある程度記載しているので、ちょっと長文です。
What's New In Spring
内容
最初はSpringFramework全体と、その中でのSpringBoot、SpringCloudの位置づけの話。 SpringはMVC、Security、Dataなど、システムで必要な機能をすべて賄えるほどの大量のプロジェクトがありますが、それを一括管理して省力で利用できるようにするのがSpringBoot(この説明はわかりやすかった)。
セッションの中心は、Spring 5.0 から新しく入るReactorAPI(WebFlux)の説明、デモ。
主にMono
「今までのブロッキング・同期のコードをほとんど書き換えず、dependenciesとちょっとした変更でReactiveにできる」というのが一押しポイントだったよう。
あと、SpringBoot 2.0、そこに対応するSpring Cloud finchleyは2018年2月ごろになる模様。
所感
SpringBootの役割を再認識できたことは、ためになりました。 RxJava、Angular、AngularMaterialを触っているおかげで、Mono/Fluxの理解がそれなりにはできたかと思います。
Introduction to Spring WebFlux
内容
www.slideshare.net
WebFluxを、デモアプリケーションも含め実装レベルで深く掘り下げた内容。
所感
コンテンツ量も多く、スピードも速かったですが、 これもストリームの事前知識があったおかげで、十分メモを取りながら理解できました。
特に勉強になったのは、次の2点です。
「WebFluxを使うときは、必ず最後まで”ノンブロッキング”で処理を書かなければ意味がない」ということ。 スレッドが1つなので、完全にリクエスト処理が止まる。
JDBCは完全にブロッキングなので、現時点ではWebFluxと組み合わせることはできない、ということ。 Javaで今後非同期APIを検討中とのことなので、それの先行きを見守るしかない(スライド P.129)
Wagby R8 と Spring の関係
内容
Wagbyという名前は初めて聞きましたが、ノンプログラミングで業務システム開発ができるプラットフォームのようです。
製品紹介は一切なく、内部で使用しているSpring Frameworkのノウハウをひたらすらお話いただきました。 とても潔くてステキ!
新バージョンのWagby8からは次の3つを新たに取り入れるとのこと。
- Boot
- Session
- Security
ぞれぞれ次の通り。
- Boot
マイクロサービスを目指すために導入。
エンプラアプリケーションでは、特定の機能をある一時期だけ大量に使用する、というケースがあるが、このときVMのリソース定義を最大値に会わるわけにはいかず、平均値にしたところで高付加時に対応できない。マイクロサービスにすることで、アプリケーション分割=リソース定義分割をしたい。 あとはよく聞く、部分変更のために全アプリダウンを発生させないようにするため。
また、パッケージとしての将来性のため、時代に合わせた対応をしたいとのこと。
- Session
これまでは単一セッションであったため、1ブラウザにつき1タブしか開かないでください、とお客様にお願いしていたとのこと。 これをマルチセッションにするために導入。
具体的な対応を説明いただきましたが・・・一応抽選のランチセッションだったんで、ここに書いてもいいんだろうか? お弁当だけ抽選だからいいのかな?
簡単に、マルチセッションの仕組みは、Gmailに倣ったとのこと。
セッション情報をRedisに保存するために、運用プロセスとしてRedisの管理が増えたが、これはシステムを「前進」させるために必要なこととして、お客様に説明するとのこと。
- Security
セキュリティ周りが独自実装であったが、認証方法や暗号方式などついていくコストが大変なのでSpringに乗っかる方向に。 おかげで、LDAP認証とDB認証の組み合わせや、BCryptの導入などができるようになった。
エンプラ系システムだと、やっぱり枯れた技術のほうが求められがちだが、新しい技術をエンプラ系システムに適用していき、未来に繋げたいとのこと。
所感
最新技術の勉強会で貴重なエンプラ立場話。 弁当ほしさに聴講しましたが、SIerとしては聞き逃せない話でした。
エンプラ系システムを使って実現される業務を未来に残すためには、やはり新しい技術にアジャストしていくことを絶やさず、それをちゃんとお客様に説明して理解してもらうことが大切です。 開発側の都合に聞こえるかもしれませんが、数年、数十年単位で見て、双方の幸せにつながると思います。
・・・油断するとエンプラシステムに対する熱い(キモい)想いが溢れそうなので、いったんここまで。
Spring Data REST を利用したAPIの設計と、作り直しまでの道のり
内容
www.slideshare.net
オチはP.45から。 Spring Data JPAを試しに使って、使いどころを実感したという話。
所感
2つ後のカサレアル多田さんの話と合わせて、Spring Data JPAの尖ったパワーをよく理解して、よく検討することが必要なことがわかりました。 あと、今回の話では、方針を決定するための「勇気」も必要なことを感じました。
脆弱性の探し方 ~発見と対応のノウハウ In NTTDATA~
内容
TERASOLUNAの中の人が、TERASOLUNAにおける脆弱性にどう立ち向かっているかという話。
2014年にStruts1の大きな脆弱性が発見されてから、脆弱性にいち早く対応するために、脆弱性を「探す」ということに重点をおいて活動している。 大きく、
※脆弱性というのは、基本的には
- 設計の不備
- プログラムの不具合
であるため、効果があるとのこと。
脆弱性に関するノウハウ。
- ”なに”を脆弱性とみるか:
プログラムに脆弱性があったとき、依存ライブラリがあったとする。依存ライブラリに脆弱があるときは、依存先が悪いと判断できる。しかし、依存先が「○○で回避できる」と公表していると、それに対応していない依存元プログラムが悪いことになる。それも考慮して実装を検証する。
- "いつ"脆弱性が作りこまれるか:
依存ライブラリなどがアップデートされた場合は特に注意。脆弱性の3分の1は機能追加・アップデート時に作りこまれる。
- "どこ"に脆弱性がうまれるか:
ライブラリ呼び出しなどのモジュール間。 Spring MVCとSpring Securityの間では、URLをベースに設定が作りこまれるため、Secruity側でURLパターンの漏れがあれば、脆弱性になる。
- "どのように"脆弱性を探すか:
ほかのOSSで発見された脆弱性を、Springなどでも横展開調査している。
といった活動により、NTTDATAで、高い割合での脆弱性報告の実績がある。
また、脆弱性を「報告」する際には、悪用されたり、事前察知⇒攻撃、とならないように、 IPAが公開している 早期警戒パートナーシップ などを参照し、 しっかりと警戒しながら報告・対応を行うことが必要。
所感
エンドユーザに近いエンジニアとして、セキュリティに対しては正しい知識が必要です。 また、こういった話を聞いてて多くの人が「セキュリティ広すぎてわからん。一人じゃできない。」と思われると思います。
その通り、「セキュリティは一人ではできない」ということは、セキュリティ関係のコミュニティは共通認識です。
多くのエンジニアがセキュリティに関心を持ち、その知識・ノウハウを共有していくことが大切だと思います。
なので、上記内容記載も長文になりましたが、極力浅く広く記載しました。スライド公開されてたらうれしいんだけどなぁ。まだ見つけてない。
Pivotal認定講師が教える!Spring Data JPAによるデータアクセス徹底入門
内容
www.slideshare.net
Spring Data JPAに関する詳細な解説と、様々な注意点。 まず必要なことは、スライドにもありますが次の通り。
多田さん「次の3つの条件を、すべて、ANDで満たせないと、Spring Data JPAを使うことはおすすめしません!」
所感
2つ前の、楽天の高橋さんのセッションでもありましたが、やはりSpring Data JPAは曲者な模様。
Pivotal認定講師の言葉を信じましょう。
そして、認定講師のセミナーを受けましょう! (宣伝したのでインセンティ
Spring と TDD
内容
最初に断っておくと、JUnit含めあまりテストを書いたことがないため、内容はよく理解できてません。。。
TDD(テスト駆動開発)は、テストを最初に書く⇒次に実装を少しずつ書きながらテストを少しずつクリアしていく、という手法。 実装がない状態からテストを書き始めるので、
- いかにテストコードを早く書くか
- いかに最小限のクラス実装で通過できるテストスケルトンを用意できるか
が大事になる。
これを、SpringBootでは、依存先にspring-boot-starter-test
を追加するだけで、いろいろ用意してくれている。
アノテーションだけ、レイヤごとのスライステストなど、いろんなテストができる。
MVC、Secrutiyのテストに
@WebMvcTest @WithMockUser
したり、e2eのテストには
@Autowired
WebDriver
したり。
RestClientのテストには、
@RestClientTest
を書くと、MockRestServiceServerという相手先APIのかわりができる。
@DataJpaTest
を書くと、EntityManagerのテストモックが利用できる。
Boot2.0からは、ConfigurationのBean設定をテストする ApplicationContextRunner
という機能も増える。
所感
相手先業務システムを開発する際は、テストコードを書く機会というのは本当に少ないです(現に私は一度もないです)。 個人プロジェクトなどで積極的にテストを書いていきたいですね。
また、情シスなど維持管理になると、今後はでは自動テストは避けて通れないため、そういう意味でも、早いうちに練習をしておきたいですね。
Spring Boot と Spring Cloud で始めるマイクロサービス
内容
まず、マイクロサービスは、特にアメリカで、
ビジネスの仮設⇒システムを少し修正⇒すぐためしてフィードバック⇒仮説・・・
というビジネスイテレートを早く回すために発生したもの。
なので、すべての会社のシステムに適しているかというとそういうわけではなく、全てのアプリケーションがマイクロサービスになる必要はない。 ガートナーだって「企業の8割9割はマイクロサービスを始めて、すぐやめるだろう」と言っている。
そもそも、理想的なマイクロサービスを実現するためには、次のような要素が必要。
- 分散システムの知識
- DevOps
- 可用性、耐久性
- ドメイン駆動設計の知識(アプリケーション単位などを決めるためには必要)
- チーム・組織(アプリケーション毎に責任を持つ)
特にチーム・組織作りは、エンプラ系で、エンドユーザとの間にSIerなど挟んだとき、 その仲介がマイクロサービスやそれに合わせた組織作りの知識がない場合がある。
だが、マイクロサービスを学ぶことで、開発者として知識・視野が広がることは確かであるため、学ぶことは開発者として身になる。
その学びのスタートラインとして、Spring Boot + Spring Cloudの組み合わせは、シンプルでちょうどよい。
※Spring Bootの解説がありましたが、この記事では割愛します。
マイクロサービスを構成するとき、
- どうやってマイクロサービスをさがすか?
- サービスがスケールアウトしたら?
- サービスの一部がダウンしたら?(monolithicなら副系切り替えなどするが・・・)
といった課題がある。これらを解消するために、サービスディスカバリなどのデザインパターンがある。それを実現するのがSpring Cloud。
例えばサービスディスカバリには、Netflix OSSのEureka(谷本さんは”ユーレカ”って読んでたかな?)を使用している。
SpringBoot+SpringCloudのシンプルな構成でマイクロサービスを学んで、 技術的視野を広げよう。
所感
マイクロサービスを学ぶと、自然と可用性やレスポンスなどを意識するようになるので、単一のアプリケーションプログラムだけを学んでいるよりも広い視野になることは、確かだと思います。 いわばエンプラ系でシステム全体の構成を考えるイメージに近いです。
どのノードにどのアプリケーションを置くか、ということも考えるようになるため、物理距離やリージョンなど、インフラレベルの現実の制約を意識する機会も増えます。 ただひたすら与えられた業務画面プログラムだけを組むだけでは見えなかった、誰も教えてくれなかった、必要な現実に目が向くようになってきますので、書籍を読むだけでも勉強することをお勧めします。
少なくとも、自分はそうでした。
全体的な所感
エンプラ系のSEなのでその目線で。
総じて、様々なアーキテクチャ・技術を "適材適所" で用いることが大切です。いわゆる無銀弾です。
マイクロサービスの採用/不採用、アプリケーション間連携でのWebFluxの採用/不採用、Spring Data JPAの採用/不採用・・・
Springは本当にシステムに必要な機能をすべて賄うだけのいろいろ機能を提供しています。 実際にそれを使用する私たちSEに必要なのは、適した組み合わせ で取捨選択し、 それを 適した使い方 で価値のあるシステムに加工・組立することです。
再発明もはなはだしい感想ですが、現にそのことを改めて実感した一日でした。
おまけ
最後に、懇親会中のLTの内容を覚えてる限り書きます。
1
DocurainというサービスをSpring Boot+Kotlinで作った際のノウハウのお話。
内容は・・・うっ頭が・・・(記憶がない
2
JUnit5を使ったという話。 kazuki43zooさんの記事がわかりやすいという話。
JUnit4との互換性には注意しましょうという話。
そして・・・うっ頭が・・・
3
Java2年目の女の子が、がんばってJava SE 8 Silverをとった話。
自分の勉強は当然として、社内勉強会を実施して社員間で教えあうことで、合格できたという話。
会社名は・・・うっ頭が・・・
4
JavaログにUUIDを出力するMavenライブラリを作りましたという話。
うっ頭が・・・(早い
5
さいぼうずのひとがJDBCTemplateをラッピングしたライブラリを作りましたという話。
MyBatisでもいいけど、クエリを別ファイルに書きたくないから、 @Query("SELECT ...")
ってできるようにしました、という話。
うっあt
6
このひとかな?
転職したら使用するSpringが3まで若返ったという話。 JSPがいやだったので、わざわざJARをダウンロードしてThymeleafをいれたけど(Mavenもなかった) だれもThymeleaf読めなくてコードレビューしてもらえなかった話。
うっ頭が・・・(悲しい話のため
7
アニメカバレッジ90%だというこの人。
とても真面目でとても素晴らしい内容の話を聞きました。
それは・・・うっ頭が・・・
8
建築とマイクロサービスは似てるかも、という問いの話。 マイクロサービスのような建築は、40年前からあった。 中銀カプセルタワービル という、同じ形の部屋カプセルを組み合わせた建物。 でもこれはマイクロサービスの悪い例だった。
これまでカプセルが一度も入れ替わってない、なぜかというとカプセルを上から外していかないといけない。つまり、依存性が強すぎる。 配管は奥まって修理困難。 耐震強度の問題で建て替えが必要になってきているが、住んでる人や、芸術価値を感じてる芸術家が反対してなかなかできない。
やっぱりシステムはスモールスタートがいいね。 また、システムをつくるときは芸術重視、効率重視、など目的をもったほうがいい。
内容は以上です。
参加者はどのくらいいたのかな?
次回も参加したいです。
そのときはSpringのステッカーとかほしいな。
あと、東京はやはりいろいろあってうらやましい。
可能性の獣…! #こざけ pic.twitter.com/YUPw5jkXSW
— Koji Saiki (@saikou9901) 2017年11月25日