読者です 読者をやめる 読者になる 読者になる

Logic Delight

明日のワシは忘れてしまうから、コードにはコメントを書くのです。

Spring in Summer ~ 夏なのにSpring に行ってきたメモ

最近出席したカンファレンスの中では、特に得る物がない残念な1日でしたが、折角メモ取ったので挙げておきます。知人に再開したのもあって、予定外にディナーパーティーまで参加してしまった。

http://www.springframework.jp/summer
https://jsug.doorkeeper.jp/events/27682

公式ハッシュタグ:#jsug_sis

日時:2015年 8月 28日 (金) 10:00 〜 18:30 (開場 9:00)

場所:〒100-6640
東京都千代田区丸の内1-9-2
グラントウキョウサウスタワー 23〜41階

Room 1 (41F 200名)
Room 2 (41F 100名)
Room 3 (23F 50名)

10:00 - 10:30 R1-1.オープニングセッション

 長谷川裕一 (日本Springユーザ会 会長)

10:30 - 11:30 R1-2.マイクロサービスアーキテクチャの設計

鈴木 雄介 (日本Javaユーザーグループ 会長)

http://www.slideshare.net/yusuke/jug2015

MSA(Micro Service Architechture)

  • MSAの2つの側面
    • 技術面:分散配置と統合
      • サービスをサービスで構成する
        • 静的要素の組み合わせから動的要素の組み合わせへ
      • メッセージによる統合
      • サービスをマネージする
        • 稼働監視、依存性管理、
    • 文化面:持続性と分権
      • サービス全体を持続的に動作させる
        • ソフトウェア開発からITサービス運営へ
      • ドメイン固有の技術と運営
        • ドメインごとの自主性を認め、標準化を否定する
      • ドメイン個別のライフサイクル
  • MSAの背景
    • ウェブサービスのレガシー化
      • いまやエンタープライズよりも巨大で複雑
      • サービスの各要素特性や変化速度が大きく異なるため、標準化が出来ない
    • サービス共有の一般化
      • サービスレベルがコードで管理できる
        • SDx流れ。様々な仮想化技術
        • サービス=非機能要件的なもの。性能や可用性など
        • コードが機能だけではなく、サービスを管理できる
      • 動作構成パターンの共有化
        • OSSは静的な構成の共有化を実現し、APIは動的な構成の共有化を実現した
  • MSAとは
    • 新しい理想論ではなく現実解
  • MSAを理解する
    • 技術論よりは技術管理論
      • いかに技術をマネジメントするかという方法論
    • 粒度ではなく関係性に注目を
  • システム統治としてのMSA
  • MSAの適用
    • MSAは銀の弾丸ではない
      • SOAは必ずしも悪ではない
    • とはいえ、関係性を重視するアプローチは重要
  • MSAと開発プロセス
  • MSAのデザイン
    • 前提:企業システムにおける適用
    • ドメインの発見
      • ドメイン=変化の境界線
        • 変化の境界線を見つける
          • モジュール化は変化の境界線によって起きる
        • 変化の要因を品質特性から理解する
        • 変化の濃淡に線を引く
    • プラットフォームの利用
      • プラットフォーム=共有の動的資産
        • 複数ドメインを許容するための基盤
        • 今後はプライベートPaaSやハイブリッドPaaSの登場が予想される
    • ドメインとプラットフォーム
      • バランスをいかに取るか
        • 独立させすぎると無駄が増える
        • 共有し過ぎると対応できない
  • MSAの実例
    • 企業システムで言えばECサイト
      • 既存の社会的責任が維持されてしまう
      • 多様な利害関係者/ルール/システム
      • レガシー連携と最新トレンドへの追随
      • 複雑系と柔軟性の課題が多い
    • ECサイトドメイン設計
        • 特性
          • 流入→商品検索→購買
            • それぞれでの複雑性や利用者数の違い
            • 買わせるための属性と売るための属性の違い
        • 個人情報やカード番号
        • 基幹(請求/在庫など)との連携
          • データの整合性と鮮度のコントロール
    • ECサイトの構成
  • Springについて
    • Spring Bootだけじゃない
      • あらゆる粒度で関係性の管理が行える
        • Framework:アプリ内の関係性管理
        • Integration:アプリ間の関係性管理
      • Springは何かを規定しないからこそ、アーキテクトにとって魅力的であり続ける
        • プラットフォームとしてのオープンさが魅力
  • 「MSAにする」のではなく「MSAになる」のが健全
    • MSAはITサービスを持続するためのアーキテクチャデザインコンセプト
    • 個別の技術に惑わされることなく「適切さ」を維持することを重視すべき

11:30 - 12:30 R1-3.大規模エンタープライズにおける、最新のフロントエンド・アーキテクチャへの挑戦

近藤 健 (株式会社野村総合研究所

ObjectWorks+という内製F/Wについて、
JavaEEに加えて、SpringMVC+AngularJSを2014から追加した、という話。

  • 背景と課題
    • モバイル化が一巡し、再びUI要件の上昇フェーズに入っている
    • Flexで開発されたアプリケーションのHTML5化の検討が始まっている
      • 2016年、IE11以外はサポートされなくなる →そういえばそうだ
    • 海外では金融系やBtoBシステムでもUXへの投資が始まっている
    • 大規模エンプラの制約
      • アプリ開発方式は変えられない
      • 組織の役割分担は変えられない
        • NRIの組織は、アプリと基盤で分かれているため、AOPで成果物を分けている
      • ミドルウェアは変えられない
        • ObjectWorks+として開発している(JavaEEベース)
    • JavaScript開発が当たり前に→JSFの弱点が顕在化
      • JSFはサーバサイドJavaでUIをコントロールするモデル
      • JSFの画面をJavaScriptで変更すると予期せぬ動作をする
  • サーバサイドアーキテクチャの最新化
    • 大規模エンプラの制約への対応
      • ま、フツーの話
    • SpringMVCに足りない機能の追加
      • 独自の例外ハンドリング
  • クライアントサイドアーキテクチャの最新化
    • クライアントサイドMVC導入
      • jQueryよりもAngularJSベースの標準化により、オフショア開発への切り出しがし易い
      • クライアントサイドMVCにより、クライアントサイドだけでモックアップの構築が可能、捨てずに使える
    • 導入リスクを下げるための試み
      • JavaScriptの欠点を補うためTypeScriptを採用する
        • データに型を持たせて、固く開発できる
      • AngularJS&TypeScriptにより、SpringMVCのアナロジーで説明し、学習コストを下げる

NRI社のフレームワークは、組織構造に縛られ、自社のビジネス構造に縛られ、自由度・柔軟性が少なくて窮屈そうに感じた。それでも競争力を維持しているというのは、それは「技術力」によるものではないんだろうと思慮。

12:30 - 13:30 昼休み

13:30 - 14:30 R1-5.キーノート The Macro of Microservices

Josh Long (Pivotal) 同時通訳あり

  • Agile Manifest
  • Dev Ops
  • Value Chain Map
    • Platform
  • writing cloud-native software
  • NETFLIX
    • Product team using microservices
      • Prod Mgr
      • UX
      • Dev
      • QA
      • DB Admin
    • Platform team (Producing API)
      • Sys Admin
      • Net Admin
      • SAN Admin
  • microservices enable bounded contexts
    • Martin faulers Blog...

14:30 - 15:30 R1-6.Spring DIと大規模プロジェクト、春は来るのか本当に?

三宅 泰裕(株式会社ワークスアプリケーションズ)

HUE(High Usability Enterprise)プロジェクトの中でのお話

  • プロジェクトの規模感
    • 初期:10人規模
    • 中期:50人規模
    • 後期:500人規模、グローバル混成部隊(今ココ)
  • 構成の変遷
    • 初期:Springでできるだけ構成
    • 現状:
      • RDBMS:Cassandra, Elasticsearch ...
      • Batch:SparkStream + SparkBatch
      • Cache:bugが見つかる...修正後、再度利用
      • Front:SPA, karma + jasmine ...
      • 結果:MVC / Cache / Test / Context
  • プロジェクトへの要求
  • @Autowired使いたいよね
    • @ComponentScanとセットで
    • でも、時間の経過とともに
      • AP起動時間が遅くなっていく
        • 瞬間的にスケールしたい!!
      • プロジェクト間の依存関係が
        • BeanCreationException...
      • 依存性の注入って言うけど
        • で、結局、何が読み込まれているの?
  • 先に結論!
  • Modularityを担保したい
    • ポリシー
      • 全部一個にしない
      • 開発者は必要な依存(Maven)を選ぶ
  • ComponentScan使いたい
    • @Autowiredが救世主?
  • 最低限の規約遵守
    • interfaceベースでのScan
    • テストしやすいように
  • 表面的に噴出した問題
    • 依存関係が謎、解決できない
      • 推移的依存解決
    • 起動時間が遅い
    • plug-in的に扱うものは?
    • 以下、詳細
    • 依存関係が謎、解決できない
      • 犯人は、実はComponentScan
        • 推移的依存関係の解決を行ってしまう
        • 見えない依存が勝手にできる
    • 起動時間が遅い
      • ComponentScan(対象PKG以下のフルスキャン)
      • Bean生成時の問題
        • コンストラクタでDB読み込み...してた
          • 起動時に寄せればいいってもんじゃない!
  • 人が増える=jarが増える
    • どんどん遅くなる
      • Eclipseだともっと遅い
      • 開発者のストレス → 遅いことに慣れてしまう
      • 小さく作れなくなる
  • 人が増える=知識も薄まる
    • 無駄を無駄と思わず、当たり前に感じる人が増える
  • plug-in的に扱うものは?
    • 依存が本当に分からないものもある
  • ソリューション
    • フレームワーク開発者
      • 速度を重視
        • Scanしない → @Component にあたるものは自前で管理
    • 業務開発者
      • 効率を重視
        • Scanする → DAO / Controller / Service
    • Scanしない
      • アノテーションベースDIからJavaベースDIへ
        • @Configurationを有効活用
        • @Beanも有効活用
        • applicationContext.xmlは使わない
      • メリット
        • 依存の整理が楽
        • テストも一元化
        • Grep天国との決別
    • ちゃんと@Importも使う
  • こうすると、実は問題が...
    • N回読み込まれる問題
      • @GuardedConfiguration(自作)
        • 2重登録の防止
  • 実装とインターフェイスの分離をConfigにも適用
  • テストも楽ちんに
    • @ContextConfigurationでもConfigクラスを読める
    • 嬉しいのは、ユニットテストのしやすさ

15:30 - 16:30 R1-7.The Bootiful Application

Josh Long (Pivotal) 同時通訳あり

github.com/joshlong/bootiful-microservices
twitter @starbuxman

start.spring.io/

make jar not war.

  • using spring-boot-starter-actuator / spring-boot-starter-remote-shell
    • actuator(下記のURLが自動で作られる)
      • /metrics
        • システム情報が照会できる
      • /trace
        • 直近100リクエストとレスポンスが見える
      • /env
        • JVMパラメータが参照できる
      • /info
        • プロダクトのバージョンなどの情報を埋め込んでおける
      • /mappings
        • アプリケーションのリクエストマッピングが一覧で見える
      • /beans
        • Beanオブジェクトのdependenciesが一覧で見える
      • /health
        • アプリケーションの状態(UPとかDOWN)が照会できる

16:30 - 17:30 R1-8. 【前半】 Spring Framework/Boot/Data徹底活用〜Sprnig Data Redis編〜【後半】 Spring適用のアンチパターンとベストプラクティス(仮)

Spring Data Redis
  • JedisのローレベルAPIを使うのではなく利用しやすいTemplateを提供している
  • RedisCaheManagerを利用することでspring-contextのCache機構と連携可
    • キャッシュとして戻り値を保持したいメソッドにCachableアノテーションを定義
    • Redisに存在しない場合のみ、メソッドの中身が呼び出される
    • 下のコードはSQL実行結果をキャッシュとしてRedisに乗せる例
  • spring-boot-starter-redis / autoconfigration を依存関係に加えるだけ
  • Redisの構成
    • Sentinel (Master Slave 投票でMasterを決定)
    • Load Balancer
  • JedisはRedis Clusterに対応しているが、Spring Data Redisが未対応
    • なので、現実的には、Sentinel or LB が選択肢
    • Read/Write先を区別したい場合は、Connectionまわりはカスタマイズが必要
Spring適用のアンチパターンとベストプラクティス

http://www.slideshare.net/Yoichi-KIKUCHI/jsug2015-summer-spring

  • オレオレフレームワークを作りまくった時代を振り返って
  • やっぱり素直にSpringに沿った作りにすべきだよねーという話
    • 何も得るものなし

17:30 - 18:30 R3-9.Spring Bootをフル活用した継続的デリバリーの実践

辻 昌佳 (株式会社 マネーパートナーズソリューションズ)

[対談:日本Springユーザ会 会長 長谷川裕一]

  • MPSシステムのサーバーサイドは全てSpringを採用
  • ドメインごとに5チーム(2〜10数名)
    • ポータル開発
    • 取引基幹系
    • 取引ツール
    • 社内
    • 共通開発
  • 課題
    • 小〜中規模プロダクトを多数抱えている
    • いかにして効率よくリリース、保守し続けていくか?
      • チーム専属の開発者アサインは非効率
      • アーキが異なると学習オーバーヘッドが大きい
      • 独自の構成があると担当が限られてしまい問題解決が遅れる
  • Springフレームワークを基盤とした共通開発手法を確立
  • 結果
    • チーム間で開発者を共有できるように
    • 保守、運用が容易にできるようになった
    • 統一感を持った見積りができるようになった
      • 見積りのブレが少なく
      • 見積りのチェックがしやすい
      • テンプレート化した見積りツールで簡単に見積もれる
  • フレームワーク
  • Springベースのフレームワークツールセットを活用して継続的デリバリを実現
  • 自動生成デモ(動画の再生と説明)
    • gitリポジトリから自動生成セットを取得し
    • ケルトンプロジェクトの初期化
    • ビルド・プロセスの起動
    • SwaggerからサーバのAPIを確認 ☆これは便利かも☆
    • 組み込みH2データベース上のデータを確認
    • プロセスの終了
  • デプロイ〜リリースデモ(動画の再生と説明)
    • 仮想マシン(Vagrant)にデプロイ
    • 仮想マシン上にリリース
    • プロセスの起動
    • SwaggerからサーバのAPIを確認
    • 組み込みH2データベース上のデータを確認
    • プロセスの終了
      • コマンドから、spring-boot内のActuatorを使って停止させている
  • これから
    • Springのライブラリ群の取り込み
      • SpringSecurity-OAuth
      • Cassandra
    • フレームワークを活用した共同開発
    • マイクロサービス開発への対応
  • MPSのこれから
    • ECや物流など他業種への展開
    • サービスの継続性を損なわない、システムの移行開発
    • 当社のノウハウを展開して、開発の効率化をサポート
  • JSUG会長の長谷川さんと対談
  • UI側はデフォルト実装は用意しているものの、技術の移り変わりが激しいので強制はしていない
  • 反面、WebAPIの構築は真剣にやる

19:00 - 20:30 41F 食堂: ディナーパーティー(無料)を開催。LT大会(飛び込み可)