Seeing is believing

いちエンジニアの日々の興味のあるところ、イベント参加記録、学びの共有を取止めなく※このblogは個人の見解であり所属する組織の見解ではありません

JSUG勉強会 2018年その5 Spring IO 報告会 に参加しました

JSUG勉強会 2018年その5 Spring IO 報告会

jsug.doorkeeper.jp

全体所管

  • Reactiveあまり触っていない分、キャッチアップする必要あり。進化が早い!
  • APIについては、ケースバイケース。見極め力が必要
  • Spring Cloud Gateway, Spring Cloud Pipelineについては触ってみる価値あり。やりたい!

  • 会場:Pivotal @六本木ヒルズ20F

Reactor, Reactive Data Access, REST beyond the obvious

Flight of the Flux: A look at Reactor execution model

  • 元ネタスライド
  • サーバサイドのReactiveの話 。イベント=通信
  • データが発生するごとにどのようにデータを処理していくかの工程をReadableにわける
  • マルチスレッド、ノンブロッキング、並行処理、並列処理
  • functional interface
  • Reactorを支える技術要素
  • Nothing happens until you subscribe
  • Assembly time:subscribeするまではpipeline(工程、ステップ)が書かれているだけ
  • Execute time:タイミングが異なる
  • Debugモードにする魔法;Hooks.onOperatorDebug();
  • Debugモードその2:checkpoint()メソッドをつかう
  • Hot publisher:流れている途中からもみれる
  • micro fusion : 異なるオペレータを1つのキューにまとめる

Under the Hood of Reactive Data Access

  • 元ネタスライド
  • ReactiveDriverはデータがどこまで取得できているのかを把握できるので、データを全て待たなくても良い
  • SpringDataでReactiveでDBアクセスできるものは限られている
    • Mongo,Radis,cassandra,Couchbase
  • ReactiveでないDBとの違いは、Threadの構造、タイムアウトのハンドリング、ConnectTimeout、ReadTimeではなく、CommandTimeout(自分で完了シグナルを送るタイムアウト

REST beyond the obvious

Spring REST Docs RAML, Spring Cloud Contract

  • 岩塚 卓弥(NTT SIC)さん
  • Restful API開発にはツールがたくさん
  • 用途により異なる
    • Public API
      • 誰がどう使うのかわからない
      • API変更時に利用者側の合意は不要(できない)
    • Internal API
      • 使う人、使用方法がわかっている
      • 変更時に同意が必要
      • 内部の開発者が使えればよい
  • メンテナンスされたドキュメントは重要 vs ドキュメントのメンテナンスは面倒
  • Public API
  • API仕様からのソースを生成
  • ソースコードからの生成:Springfox:ソースコードだけでは情報が足りてないので補完が必要
    • 実装方法に依存。ソースコードが読みづらくなる。実装内容と保管情報法の乖離のチェックが必要
  • Spring REST Docs:APIのテストコードからドキュメントの一部を生成
    • API実装側の実装方法に依存しない
    • テストされた正確なものが出力。デフォルトはAsciiDocs
    • Spring REST Docs RAML Integrationがよいのでは?
    • RAML形式の出力を出す3rdパーティ性ライブラリ
      • そのRAMLからJsonSchemaやリクエストのJsonの例なども出してくれる
      • raml2htmlするとちょっとリッチな画面に
      • API Rest Console:リクエスタコードの例、実際にAPIを叩いて確認できる
  • InternalAPI用
  • お互いにAPI呼び合っている際にテストをどうするのか?
  • Consumer-driven Contracts(CdC)
    • 各利用者はAPIのレスポンスすべてを使いたいとは限らない
      • 利用者の必要な部分だけの取り決め=Consumer Contract
    • Contract:Groovy DSLまたはYAMLで記述
    • Polyglot対応もされている:Contract がYAMLになっている&テストランナーはDockerで起動できるので環境を汚さない

Spring Cloud Gateway, Spring Cloud Pipeline

  • 堅田 淳也(NTT SIC)さん

Spring Cloud Gateway

  • APIゲートウェイAPIのリバースプロキシとして振る舞い、横断的関心事を処理
  • Spring5,Spring boot2系で動作
  • シンプルだが十分なAPIルーティングを動作
  • リアクティブ対応
    • 従来のZuul1系と大きく異なる。2系はSpringCloudでのサポートはなし
  • 最新バージョンは2.0.0
  • デモ
    • Stage1:モノリシックなアプリを段階的にマイクロサービス化していく
      • Helloサービス、Fortuneサービス、UI(index.html)
    • Stage2:Stand up gateway
      • 依存性追加、JavaConfigでルーティング先の設定
    • Stage3:Move UI to separate app( path rewrite)
    • Stage4:Add service discoverydiscovery
    • Stage5:Move hello service.URIの形式が変わった場合の古い人への吸収をAPIゲートウェイ実装側で実施可能というデモ
    • Stage6:Add circut breaker to old fortune service with fallback:Hystrixのサービスブレーカを実現
    • Stage7:Fortuneサービスの切り出し
    • Stage8:流量制御を適応する。
      • Spring Cloud Gatewayに機能あり。Redisが必要。
      • 例:秒間最大1アクセスに制限

Spring Cloud Pipeline

  • デプロイメントパイプライン
    • パイプラインを1から作るのは大変
  • Spring Cloud Pipelines :デプロイメントパイプラインのベストプラクティスを提供
  • Concourse,Jenkinsに対応
  • 最新バージョンは1.0.0M3
  • ライブラリではない。中身はほぼBashスクリプト
  • 4つの環境ごとにジョブが作られる
    • Build:ビルド、単体テスト、成果物の保存、API互換性チェック(Spring Cloud Contractを利用)
      • MavenかGradleに対応していれば活用可能
    • Test:テスト環境へのAPをデプロイ、スモークテスト、APをロールバックロールバックしたAPのスモークテスト(後者2つは戻しの可否確認)
    • Stage:ステージング環境へのデプロイ、E2Eテストの実施
    • Prod:新しいAPを本番環境へのデプロイ、新しいAPへの切り替え、ロールバック(これだけ手動)