Seeing is believing

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

SpringのControllerから先で非同期化するパターン

やりたいこと

  • リクエストはHTTPで受け付けて、後ろ側の処理を並列実行
  • 結果は全結果を待ち合わせてHTTPレスポンスを返す
  • できれば、エラーが発生した場合は待ち合わせせずに早期にレスポンス返したい

Spring5 Recipesに記載されていたパターンは以下

qiita.com

  • java.util.CompletableFutureを使うパターン

  • 参考

qiita.com

  • SpringのListenableFutureを使うパターン

  • 参考

qiita.com

今後それぞれのメリットデメリットなどを整理していきたい

  • 色々情報公開されていて、とても助かります。ありがとうございます。

MyBatisでTypeHandlerを使ってDBカラム単位に暗号、復号

ちょっと調べたメモ

やりたいこと

  • 要件として、DBのカラム単位に暗号化してテーブルにInsert、Updateしたい
  • Selectする場合はオブジェクトにマッピングされた時点で複合されていてほしい
  • つまり、カラム単位の暗号化、復号化を透過的に行いたい  ⇨テーブルの中身には暗号化された状態で永続化しておきたい

前提

透過的なカラム単位の処理⇨TypeHandlerをつかったら良いのではないか?

  • TypeHandlerとは  - MyBatis自身もデフォルトで多数持っている、DBのカラム定義とJava側のフィールドの型定義のマッピングを行うもの

www.mybatis.org

  • よく使われるパターンとしては、Java側はEnum、テーブル側は文字列型とかのときに自作TypeHandlerとして使われる

qiita.com

  • Java8からのLocalDateTimeでも使われることがある

qiita.com

  • これを応用して、型としてはどちらも文字列型であるがDBに投入する際に暗号化、DBからSelectしてJavaオブジェクトにマッピングする際は複合化すればOKでは、と考えた

調べたら中国語ではあるがGithubに同じことをやろうとしているソースを発見。

github.com

結構いろいろやっているので、まずは以下のような単純な暗号化ロジックをつかって今後試してみたい。

www.suzushin7.jp

JSUG勉強会 2019その2 Spring BootベースのDDDサンプル徹底解説!に参加しました。

20190218JSUG勉強会 2019その2 Spring BootベースのDDDサンプル徹底解説!

Spring Bootベースのドメイン駆動設計のサンプルコード 徹底解説

  • いつもながら運営の皆さん、登壇者の皆さん、大変勉強になりました。ありがとうございました。

サマリ

  • 増田さん、irofさんによるDDDの設計、実装パターンのサンプル
  • 今はこれにチャレンジしているという話が多々あったので、日々改善を繰り返している。つまりこれ、という答えはない
  • 気づきは多い。現場の状況に応じて少しずつやり方変えていくべき。。

セッション中メモ

  • https://github.com/system-sekkei/isolating-the-domain
  • サンプルは設計、開発で1ヶ月ぐらい
  • 増田亨(有限会社システム設計)、irof(関西Javaエンジニアの会) さん
  • ソースコードはirofさんを始め、関西中心のコントリビュータの方々が書いている
  • DDDをコードで示すことがサンプルを作った目的
  • 質問が具体的になり、考え方の違いがはっきりしてきた
  • ソフトウェアの複雑性とはなんなのか?
    • ビジネスルールの複雑さに影響される
    • 計算をどうやって実現するか?-> 計算をモデリングする(データだけではない)
    • 型志向でプログラミング(Classにこだわる)
  • 詳細は3/22のDevLovePremiumで語る解説する予定
  • 計算(ビジネスルール)を実行するモジュール群とデータの入出力するモジュール群を分けることに拘る
  • 業務系のアプリはトランザクションスクリプトで実装されることが多い
    • ここにドメインモデルをモジュールとして組み合わせるのが良い
  • 開発(設計)の順番
  • POJO
    • BeanValidationは、有効な値の表明であり、自己署名化の一部
    • privete とか finalはこのサンプルでは書いてない。ルールはシンプルで読みやすいようにしている。(可読性 over Java)
    • No getter, no setter , no Lombok, JPA
  • プリミティブをなくす方向で整理したい。ただしパッケージ間の相互依存を無くすためにプリミティブで値のやりとりをしていたという背景もあり。ケースバイケース
  • StreamAPIを使いたいケースもあるが、業務としての表現が貧弱なケースもある。forのほうが読みやすい。
  • 増田さん個人的には、Haskellとかと比べるとStreamに違和感がある。。(Groovyとかでも比較対象として良いかも)
  • IntellJでforとStreamの相互変換はできるので、見比べながらバランスみて決めている
  • DBのDDLの内容とドメインのバリデーションの差異はどう考えたら良いか?マルチチェックすべき内容なので、それぞれで確認すべき
  • パッケージに閉じているのであれば、フィールド直接アクセスするもの良いのではないかと考え始めている
  • バリデーションが権限によって変わるというのは複雑さの一因となっている。Groupバリデーションを使うか、それぞれ分けてしまう
  • DTOはできれば使いたくないが、実際にはかなり大きいJSONを受け取って、ドメインをIFたくさん書いて組み立てるということは現実ありうる
  • オペレーションサービス 計算結果の記録と通知の指示 -> データソース層
  • Serviceクラスは単純1RepogitryへのCRUD。あまりビジネスロジックを描かない
  • coodinatorクラスは上記のserviceクラスを複合するサービス。IF文はこちらに持つ
  • どちらも@Service。パッケージを分ける
  • 増田さんはMyBatis一択派。irofさんはDomaにしたい。。。SQLを生で書くことを優先している。
  • テーブル設計は単独でよりよく見直されるようになるべき。データモデルへのマッピングについて橋渡ししているのがSQL。よってSQL書くのは大事。
  • データベースはイミュータブルデータモデル(川島さんが発表された内容を参照)
    • https://www.slideshare.net/kawasima/ss-40471672
    • 履歴+最新状態のレコード
    • 履歴:事実の記録ーInsertオンリー
    • 最新状態レコード:論理的には不要だが、Insert/Deleteで実現する
    • Update無くしが基本
    • スキーマ名、テーブル名、カラム名を日本語でやるチャレンジをしてみた
    • 外部APIを叩くときは、Transfer層(Outbound)、プレゼンテーション層(Inbound)で詰め替える。
    • DB,SQLでエラーが起きるのは基本はシステムエラーケースを想定。事前にドメインとしてチェックされているのがあるべき
    • トランザクションは意図的に組んでいない。今はやってない。履歴を事実として積み上げたい
  • JIGは自作ツール。以下が確認できて便利
    • 一覧表示での平仄確認
    • パッケージ間の相互依存の確認

今年学びたいこと

元日ということで、今年やりたいこと、学びたいとを、メモ。

ブログする頻度あげる

社内での発信にさらに力を入れる

マイクロサービス関連のアンテナ高める

WEBAPI関連も同様

リアクティブを正しく人に伝えられるように理解する

外部講演(登壇)を2回以上

フロントエンドも追う

アジャイルスクラム)の良さを真に理解、これまでのコンテキスト異なる人にも分かりやすく伝える

 

頑張ります。

JSUGイベントSpringOne Platform 2018報告会メモ

SpringOne Platform 2018報告会

SpringOne Platform全体所感

  • NTT 岩塚卓弥さん、NTTデータ 岩本純佳さん
  • 前身カンファレンス(Groovyとかといっしょの時代とか)からくらべて10年目
  • スポーサーとして日本からはNTTDataと富士通
  • セッション150個のうち、一番多かったのはケーススタディ
  • Springのセッションがそこまで多くなかったのは前年にSpring5のメジャーバージョンアップがあったから
  • JDK11使う人はSpring5.1を使う
  • 5.2は6月リリース予定
  • 5.1は去年発表のリリース予定から数ヶ月遅くなったので、5.2も遅くなる可能性あり
  • 関数型スタイルVSアノテーションスタイル
    • これからも両建て
    • 関数型スタイルも選択できる
      • パッケージスキャン不要
      • KotrinDSLで簡潔にかける
  • フレームワーク内のリフレクション使用の最適化
    • Spring5.1(Boot2.1)にするだけでヒープサイズ、起動時間が少なく短く起動できる
    • 関数型Bean定義で明示的に定義するとさらに早く起動できる
  • GraalVMによるnative imageへのコンパイル
    • GraalVMとはOracleOSS公開している多言語対応VM
  • Spring5.2
    • JDK12のサポート
    • GraalVMへの完全対応
    • Kotorin1.3の完全サポート
    • HibernateORMの5.3
  • DBS銀行の事例
    • 外注と内製の割合を逆転(8:2)
    • 技術の社内展開:技術者とのペアでの活動
    • 新規人材採用
      • 採用プロセスにオンライン技術テストやハッカソンを取り入れた(hack2hire)
  • https://codezine.jp/article/detail/11180

Spring Cloud Stream および2.1での新機能

  • Jia Xiaozhouさん
  • メッセージドリブンマイクロサービスのためのフレームワーク
  • Spring Integration + Spring Boot => Spring Cloud Stream
  • コンセプトはBinderレイヤを設けることによってアプリとミドルを疎結合(RabbitMQやKafkaなどをアプリからメッセージキューの種類を意識せずに使える)
  • 2.1ではSpring Cloud Functionとの連携
  • FunctionをBean登録、プロパティ指定するとイベント契機で呼べる
  • Function Compositoin:アプリに閉じたワークフローの定義ができる
    • Spring Cloud Data Flowとの連携も現地で話されていた
  • Source -> メッセージの源
  • Sink -> メッセージが流される場所(受け取る側)
  • Processor -> Source兼Sink
  • Functionの引数でメッセージを受けとって、戻り値がメッセージ送信になる
  • ActuatorエンドポイントからBinderを停止したり出来る

High Performance Batch Processing

  • アスクル 寺山さん
  • Spring Batchの情報が古いので参加
  • 半年前からBatch使っている
  • SpringBatchはStepという概念で管理
  • stepの途中で失敗したら失敗したところからリラン可能
  • stepはtasklet(読み込み、加工、書き込みに別れる)とchunk(それ以外)にわかれる

Reactor NettyネタとKafkaネタ

  • Yahoo! JAPAN 水落さん
  • PCFを利用
  • reactor-netty最新は0.8
  • Nettyネットワークプログラミング向けのフレームワーク(HTTP以外のTCPUDPも選べる)
  • スループット、複雑な非同期処理が求められるミドルウェア等の実装に向いている
  • non-bloking IO
  • WebFluxのデフォルトバックエンド
  • Springからみるとメタフレームワークと言える
  • Reactor NettyはReactor利用時のネットワーク通信全般に用いる
  • イベントループ前提
  • wiretapメソッドを入れておくと通信ダンプがログに出る
  • KafkaはStreaming Platform
    • Producer/Consumer
      • Kafkaにデータを送受信する基本的な機能
      • Producer/Consumer APIにより実装する
    • Connectors
      • Kafkaとデータ連携するアプリケーション
      • データソース、シンクごとに実装が公開されている(MySQL,Elasticserch)
    • Sreaming Engine
      • トピック間同士でリアルタイムにデータを変換、統合するようなアプリケーション
      • Streams APIにより実装する
      • 後述のKafka Streamsライブラリより手軽実装できる
  • KafkaStrems
    • Kafkaを用いたストリーミング処理を書くためのライブラリ
  • Spring for Apache Kafka
    • KafkaTemplete
    • @KafkaListener

R2DBCネタとRSocketネタ

  • Pivotal 槙俊明さん
  • SpringOne 2018 Ben Haleで検索して出てくる動画を参照
  • リアクティブプログラミング
  • Springの人たちが言うにはback pressureが大事
    • Reactive Streamのrequest(n)が大事
    • Subsctiverがボリュームかわりに流れてくるデータ量を調整できる(back pressure)
  • WebClientはリアクティブでなくても使えるので、おすすめ。シンプルに書ける
  • JDBCがノンブロッキングなので、別のものをAPIを作ったもの
  • OracleのADBAによい影響を与えたいという思いでSpringチームが開発している
  • Driver SPI(サービスプロバイダインターフェース)
  • JDBCっぽくかけるが、MonoやFluxで戻り値をもらえる
  • トランザクショナルなインサートも実現。スレッドローカルは使わない(JDBCだとつかっている)
  • SPIではなく、r2dbc-clientでハイレベルなAPIが提供されている。テンプレートパターン的な。
  • spring-data-r2dbcというとなりの存在のプロジェウトも。リポジトリインターフェースの作成だけで実現できる。リポジトリパターン。
  • WebFluxを使えばReactiveになるわけではない。書き方に注意。currectAllとかすると待ってしまうので、リアクティブではない
  • リアクティブアプリケーション間のback pressureを制御できあかった課題に対してのプロトコルがRsocket。L7のプロトコル(HTTPと同じレイヤ)
  • NetflixでrScoketを使っていた人がFacebookにいって活用していた人がキーノートに
  • Netflixでは今はあまりrSocketを使わずにgRPCを使っている
  • プロトコル定義なので、プログラム言語非依存(今はJS、Java、Kotlin、C++)
  • TCP直接使えないようなプラウザ上ではWebSocketを使ってその上でRSocketを使う。プロトコルなので下は意識しない。
  • マイクロサービス的な構成になった場合にRsocketを使うとback pressureを伝播できる。Istioと競合?
  • battle-flux-ui.apps.pcfone.io
  • Rsocketでクライアントからback pressureを設定できるデモ

20181120Eclipse 最新事情セミナー に参加してきました

20181120Eclipse 最新事情セミナー

  • Mike Milinkovich 氏(13年ぶりの来日)
  • Eclipseは2001年にIBMによってローンチされた
  • Eclipse Foundationは2004にできた
  • Eclipseとして注目しているのは4つ
    • Cloud Native Java
      • Eclipse Glassfish5.2でJakartaEE8に対応。2019年予定。
      • Jakarta EE9から、コミュニティ駆動に。対応するGlassfishの対応版は未定5.X。来年末ぐらいを目標としている。
      • Eclipse Glassfish5.1 12/14にリリース予定。Java EE8ベース。
      • MicroProfileも継続している
    • Eclipse IoT
    • Tool
      • Eclipse Che
      • 3年ぐらい前からやっている活動
      • コンテナ化されたワークスペース for クラウドネィティブ開発
      • 開発におけるチャレンジ
        • コンフィグとセットアップに1週間に24%も時間、コストがかかっている(新チーム参画の場合)
        • 開発ツールの開発にも41%もコストがかかっている
        • 顧客からみると生産性がないため、その時間は全く嬉しくない
      • デスクトップで仕事をするとセキュリティの問題がある
      • Cheの考えは、ブラウザIDE+Project Files + Runtime
      • easy to share + easy to Manage + Secure.クラウド側で集中管理
      • ワークスペースはこれまでと考え方が異なる
      • クライアント側はいろいろな選択肢がある。EclipseやVSC、IntellJとかもクライアントとして使える
      • チーム内のコラボレーションにも使える。設定の共有、集中管理も楽。
      • ワークスペース、サンプルの共有や、Pre-commit feedbackなど。
      • Gracpical Modeling ツール
      • System and Software Engineering : Capella
        • Siriusを使って作られている
        • アルカディアという開発手法で使える
        • 大規模開発向き
  • Eclipseの純粋なスタッフは30名ぐらい。あとはコミュニティで運営されている。
  • Cheの背後にはRedhatがいて、OpenShiftでもCheが使われている
  • Eclipseプラグインアーキテクチャは取っていない?
  • 次のTHEIAというプロジェクトがあり、フロントエンド向けに機能拡張していく予定。TypeScriptで実装されている。ブラウザIDEや、スタンドアロンでも使える(Electronアプリ)次のバージョンではクライアント側をこちらにしてくことが決まっている。
  • 過去にあったOrion多言語対応は優秀だった。この機能は今後THEIAにマージされていく予定。
  • 直前には中国にいってきて、JakartaEE,Cloud Java、Cheに関心があった。Cheについては、開発者増、セキュリティの観点。Citrilxだと大変だった。移行を考えているとの声もあった。

20180911 Cloud Native Meetup Tokyo #4

20180911 Cloud Native Meetup Tokyo #4

所感

  • いろいろ追いつけていないところが多く、キャッチアップが必要

istioとEnvoy

  • Istio
    • オープンサービスをマネージドプラットフォーム
    • それぞれのK8S上のサービスをproxyをサイドカーでチェックしてやりとりする
  • Istio 1.0の機能
    • mTLSの実装:mutual TLS
    • パーミッシブモードの場合、通信の最初の数十バイトを見て、TLSか、mTLSかを判断してどちらでもやりとりできるようにする
    • gRPCでMixerのデフォルトアダプターでサポートされた
  • envoy
    • 高いパフォーマンスでL4/L7を理解できるネットワークプロキシ
    • ロードバランス
    • L7(アプリレベル)でログが履ける
    • 1.7.1リリース
    • 1.8が9月末にリリース予定
    • 1.7 の新機能 
      • RBACのフィルター
      • ルートURL単位のHTTPフィルター
      • 別フィルターを複数設定できるように
    • xDS APIがある
      • LDS - Listener Discovery Service
      • RDS - Route Discovery Service
      • CDS - Cluster Discovery Service
      • EDS - Endpoint Discovery Service
      • SDS - Secret Discovery Service
      • HDS ー Health Discovery Service
        • HDSは、Envoy ProxyEndpointがnmでヘルスチェックしないように、分担する
      • ADS - Aggregated Discovery Service
      • UDS - Unix Domain Socke
    1. Envoyで実装された新機能はどの程度遅れてIstioに入るのか?
    1. Envoy自体はMasterがRCとしてReleaseまで早いので利用できるようになるまでは早い。Istioのほうで抽象化して利用可能になるまでに若干時間がかかるかもしれない。

Open Policy Agent is 何?