ここ1年、業務へのモチベーションが全く上がらず、それにつられて業務外での情報収集も怠っておりました。
環境も変わる兆しが見えてきたところで少しはモチベーション上げていかないとなぁ、ということで刺激を求めてJJUG CCC 2017 Springへ参加してきましたので感想などを。
スライド関連はまだ出そろっていないようなので、随時補完していきます。
#ccc_c4 Unified JVM Logging: Java 9 から変わる JVM ログ
Java 9にはJVMログ出力の新オプションである-Xlogオプションが追加されるという話です。
JVMログ、といっても個人的にはGCのログくらいしか扱ったことがないですが、 人に説明するにも難儀するあのGCログが読みやすくなるようなら良さそうですね。 過去記事でもGCログをパースしてメモリリークの検出する、みたいなことを書いてますが、 「とはいえGC設定変えるだけで書式変わるしパーサ書くのつらいんですが」みたいなことを言われても「仕方ない」の一言で済ませてましたし。
-Xlog[:[what][:[output][:[decorators][:output-options]]]]
- what:出力項目
- tag:ログ種別(カテゴリ)
- loglevel:debug,infoなど
- output:出力先
- decorator:ログ行頭に出力する情報(日付など)
- output-options:ローテーション設定など
どのタグを出力するか、という設定は論理式っぽいもので指定するのですが、 -Xlogは複数書けるので種類ごとにファイルを分けちゃった方がわかりやすいんじゃないかなと思った次第。
あと、jcmdでログ設定の変更や強制ログローテート可能、ログ内でpauseを含む行に記載されている秒数はいわゆるstop the world状態とのこと。
#ccc_g5 Introduction of Project Jigsaw
Java 9に組み込まれる(かどうか不明になってしまった)注目機能。 仕様検討自体はずいぶん前からあったわけですが、Java 9になっていよいよ組み込まれるということになっています。
Javaでは関連するクラスファイルをJARファイルにまとめることである機能毎のライブラリとして管理していますが、 JARファイルの連鎖的な依存関係、パッケージ内クラスのスコープの制約(どうしてもpublicにせざるを得ない問題)が運用上の課題です。
このソリューションとしてModuleという新概念が作られました。
- module-info.javaにrequires(依存パッケージ)とexports(公開するパッケージ)を記述
- jarコマンドでmodule化(suffixは.jar)
- Javaランタイムも機能グループ毎にモジュール化される
- jlinkコマンドで任意のモジュールのみを含めたオリジナルJREが作れるようになる
- 既存のスコープにも影響が出てくる。リフレクション系など
- 既存のJARファイルは一定ルールに乗っ取って自動的にmoduleのように扱われる
逆にmoduleをJARとして扱われた場合にはおそらくスコープ等は関係ないことになってしまいますね...
ところがこのJSR376 JigsawはJavaコミュニティの投票でNGとなってしまいました。 (Jigsawが含まれるJSR379 Java9がOKにもかかわらず、です)
ざざっと話を聞いた限りでは拙速感は否めず、NGを出されたのも理解できます。 (元々の問題の全てを解決できてない部分もあるような…)
あと、最新版では以前あったオプションや機能が変わったりオミットされていたりするようで、 数か月前以上の記事等はあまりアテにならない部分が色々出てきているようです。
そもそも今書いているこの内容すらウソの可能性もありますが…
#ccc_c6 劇的！データベース・ビフォーアフター 時代はディスクからインメモリーへ――
10年くらい前にOpen terracottaが話題になったなぁ、というのをふと思い出しました。 (あの頃は多くの人が「アレ面白そうだよね！」で終わっていた気がします)
RDBMSをディスる体でのプレゼンでしたが、インメモリデータグリッドの効果的な適用シーンの紹介という内容です。 NoSQLに置き換えても文脈がかわらない内容なので、NoSQLとの比較が欲しかったと個人的には感じました。 (この内容でもNoSQLより速そうだというのはわかるんですが)
- 複数VM間で同一Mapオブジェクトを共有するイメージ
- メモリが主、RDBMSがバックアップ(非同期で書き出す)
- データは複数台で冗長して保持、1つが落ちても自動的にPrimaryが移行・他にバックアップ作成
- キャッシュミスしたものはDBから取り出すことで大容量データに対応
- 高速処理が可能、スケールアウトが可能
- Spark+HDFSにおいてspark workが多いときのメモリ利用効率向上
- ダブったデータが集約される
- SQLライクなクエリはRDBより遅い
SparkとHDFSの間に挟めるというのは面白い活用だと思いました。 他のクラスタを組むJavaプロダクトへの活用もありそうですね。
成功事例を聞くと明日からコレ使うわｗｗｗみたいな感じになりがちですが 遍く全てのアプリがインメモリへマイグレートしていくことはなく、 現実的には効果的な部分に適宜適用していく形になるのでしょう。
細かいところですと、開発においてはVM立ち上げた直後のデータはどうしているのか、 プレゼン中では表面だけ説明したトランザクションの中間処理はどのように解決したのか、 この辺りが気になるところです。
