Prometheusのストレージのドキュメントをさらっと読んでみて、retentionの設定もしてみる

これは、なにをしたくて書いたもの？

Prometheusのストレージまわりの、お勉強に、と。

Prometheusのデータ（TSDB）のSnapshotを取得して、リストアまで - CLOVER🍀

こちらの続きで、今度はストレージのドキュメントを読み、オプションについて見ていこうと思います。

対象とするPrometheusのバージョンは、2.9.2とします（ドキュメントは2.9）。

ちょっと調べてみると、過去の情報と現在のドキュメントの内容はそれなりに異なる箇所が多そうなので、その時点の
バージョンのドキュメントをちゃんと確認した方が良いと思います。

あくまで、現時点（2.9.2）での話として。

Prometheusのストレージ

Prometheusのストレージまわりのドキュメントは、こちらです。

Storage | Prometheus

見ていくと、ざっくりこんな感じのことが書かれています。

• Prometheusには、ローカルディスク上に持つ時系列データベースが含まれている
• オプションで、リモートのストレージシステムと統合することもできる

リモートとのストレージシステムと統合することについては、また機会を改めて見ていきましょう。

ここからは、ローカルストレージについて見ていきます。

ローカルストレージについて

Prometheusのローカルの時系列データベースは、データを独自のフォーマットでディスクに保存します。

ディスク上のレイアウトについてですが、以下のような要素で構成されるようです。

• 取得したデータは、2時間ごとのブロックにまとめられる
• 2時間ごとの各ブロックは、以下の内容を含む
  • その期間のすべてのデータを含む、チャンクディレクトリ（1つ以上のチャンクファイルを含む）
  • メタデータファイル
  • インデックスファイル（メトリクス名と、チャンクファイル内の時系列にラベルを付与したものがインデックスされる）
  • Tombstoneファイル
    • APIを使用して、時系列データを削除した場合にできるファイル
    • チャンクファイルからすぐにデータが削除されるわけではない

また、Prometheusは収集したデータをすぐに永続化するのではなく、まずメモリ上に保持されています。

Prometheusがクラッシュしたりして再起動した場合は、WAL（Write Ahead Log）を使うことでクラッシュから保護されています。

WALは、以下の特徴を持ちます。

• 「wal」ディレクトリに128MBごとに保存されている
• 「wal」ディレクトリに含まれるファイルは、まだ圧縮されていないRawデータが含まれている
  • このため、通常のブロックファイルよりかなり大きい
• Prometheusは最低3つのWALファイルを保持している
  • 高トラフィックなサーバーでは、少なくとも2時間分のRawデータを保存する必要があるため、3つを超えるWALファイルができることがある

で、ドキュメントに書かれているディレクトリ構造がこちら。ここまで登場した要素が書かれている感じですね。

./data/01BKGV7JBM69T2G1BGBGM6KB12
./data/01BKGV7JBM69T2G1BGBGM6KB12/meta.json
./data/01BKGTZQ1SYQJTR4PB43C8PD98
./data/01BKGTZQ1SYQJTR4PB43C8PD98/meta.json
./data/01BKGTZQ1SYQJTR4PB43C8PD98/index
./data/01BKGTZQ1SYQJTR4PB43C8PD98/chunks
./data/01BKGTZQ1SYQJTR4PB43C8PD98/chunks/000001
./data/01BKGTZQ1SYQJTR4PB43C8PD98/tombstones
./data/01BKGTZQ1HHWHV8FBJXW1Y3W0K
./data/01BKGTZQ1HHWHV8FBJXW1Y3W0K/meta.json
./data/01BKGV7JC0RY8A6MACW02A2PJD
./data/01BKGV7JC0RY8A6MACW02A2PJD/meta.json
./data/01BKGV7JC0RY8A6MACW02A2PJD/index
./data/01BKGV7JC0RY8A6MACW02A2PJD/chunks
./data/01BKGV7JC0RY8A6MACW02A2PJD/chunks/000001
./data/01BKGV7JC0RY8A6MACW02A2PJD/tombstones
./data/wal/00000000
./data/wal/00000001
./data/wal/00000002

より詳細な内容を知りたければ、TSDBのドキュメントへ。

tsdb/README.md at v0.7.1 · prometheus/tsdb · GitHub

ちなみに、起動直後のdataディレクトリの中身は、こんな感じです。

$ find data -type f
data/wal/00000000
data/lock

lockというファイルは出てきていませんでしたね。

$ ls -l data/lock 
-rw-r--r-- 1 xxxxx xxxxx 0 May  2 10:51 data/lock

0バイトのファイルです。

このファイルは、文字通り排他に使うファイルのようで、すでにPrometheusが起動した状態で、リッスンポートを
変えて起動したりしようとすると、ロックが取れずに起動に失敗します。

$ ./prometheus --web.listen-address="0.0.0.0:9091"

...

level=error ts=2019-05-02T10:53:06.753Z caller=main.go:717 err="opening storage failed: lock DB directory: resource temporarily unavailable"

https://github.com/prometheus/prometheus/blob/v2.9.2/vendor/github.com/prometheus/tsdb/db.go#L280-L283

先に進みましょう。

最初の2時間のブロックは、最終的にはバックグラウンドでより長いブロックに圧縮されます。

ローカルストレージの制限

ローカルストレージの制限は、クラスタ化もされておらず、またレプリカも持たないことです。

なので、ディスクやノード障害対して、耐性がありません。スケーラブルでも耐久性もない、直近の短命な
スライディングウィンドウデータとして扱われるべきです。

耐久性の要件が厳しくなければ、ローカルストレージでも最大数年のデータを保存できるかもしれない、くらいのことが
書かれています…。

このあたりのことから、ローカルストレージのスケーラビリティと耐久性についての課題を解決するために、リモートの
ストレージシステムと統合する仕組みがある、ということみたいです。

Remote storage integrations

ローカルストレージに関するオプション

ストレージに関するドキュメントの以下の部分に、ストレージに関して指定できるオプションが書かれています。

Operational aspects

Prometheus自身のヘルプから、「storage」を含むオプションを表示してみると、

$ ./prometheus -h 2>&1 | grep storage
      --storage.tsdb.path="data/"  
                                 Base path for metrics storage.
      --storage.tsdb.retention=STORAGE.TSDB.RETENTION  
                                 storage. This flag has been deprecated, use
                                 "storage.tsdb.retention.time" instead
      --storage.tsdb.retention.time=STORAGE.TSDB.RETENTION.TIME  
                                 How long to retain samples in storage. When
                                 "storage.tsdb.retention". If neither this flag
                                 nor "storage.tsdb.retention" nor
                                 "storage.tsdb.retention.size" is set, the
      --storage.tsdb.retention.size=STORAGE.TSDB.RETENTION.SIZE  
      --storage.tsdb.no-lockfile  
      --storage.tsdb.allow-overlapping-blocks  
      --storage.remote.flush-deadline=<duration>  
      --storage.remote.read-sample-limit=5e7  
      --storage.remote.read-concurrent-limit=10  

「--storage.remote.〜」については、リモートストレージシステムとの統合に関するオプションなので、ここでは対象外。

その他のオプションについて、説明を見てみます。

      --storage.tsdb.path="data/"  
                                 Base path for metrics storage.
      --storage.tsdb.retention=STORAGE.TSDB.RETENTION  
                                 [DEPRECATED] How long to retain samples in storage. This flag has been deprecated, use "storage.tsdb.retention.time" instead
      --storage.tsdb.retention.time=STORAGE.TSDB.RETENTION.TIME  
                                 How long to retain samples in storage. When this flag is set it overrides "storage.tsdb.retention". If neither this flag nor
                                 "storage.tsdb.retention" nor "storage.tsdb.retention.size" is set, the retention time defaults to 15d.
      --storage.tsdb.retention.size=STORAGE.TSDB.RETENTION.SIZE  
                                 [EXPERIMENTAL] Maximum number of bytes that can be stored for blocks. Units supported: KB, MB, GB, TB, PB. This flag is experimental and can be
                                 changed in future releases.
      --storage.tsdb.no-lockfile  
                                 Do not create lockfile in data directory.
      --storage.tsdb.allow-overlapping-blocks  
                                 [EXPERIMENTAL] Allow overlapping blocks which in-turn enables vertical compaction and vertical query merge

すでにDeprecatedなオプションは無視します。

• --storage.tsdb.path … Prometheusがデータを保存する際のベースパス。デフォルトは、「data」
• --storage.tsdb.retention.time … 古いデータをいつ削除するかを指定する。デフォルトは、「15d」
• --storage.tsdb.retention.size … （実験的）ストレージブロックが最大で使用できるサイズを指定する
• --storage.tsdb.no-lockfile … dataディレクトリ内に、ロックファイルを作成しない
• --storage.tsdb.allow-overlapping-blocks … （実験的）オーバーラップするブロックを許可する。圧縮、クエリーの縦方向のマージが可能になる

「--storage.tsdb.retention.time」のデフォルト値は15日で、フォーマットにはy、w、d、h、m、s、msが利用できます。

prometheus/db.go at v2.9.2 · prometheus/prometheus · GitHub

https://github.com/prometheus/prometheus/blob/v2.9.2/vendor/github.com/prometheus/common/model/time.go#L192-L208

データの保持期間に関するリテンションポリシーは時間とサイズの2つがありますが、使われるのは最初に動作した方だとか。
※サイズはまだ実験的なので、スルーしましたが

「--storage.tsdb.allow-overlapping-blocks」については、まだ実験的な感じがするので、スルーします…。

Implement vertical query merging and compaction · Issue #90 · prometheus/tsdb · GitHub

なお、2時間ごとにブロックにまとめられる、というのは、このあたりから来ている気がします。

https://github.com/prometheus/prometheus/blob/v2.9.2/vendor/github.com/prometheus/tsdb/db.go#L51

ところでですね、PrometheusのWeb Consoleから「Status」→「Command-Line Flags」を見ると、もう少し指定できそうな
オプションが多いように見えるのですが…。

今回は、とりあえず深追いしない…。

ローカルストレージで必要とするディスク容量

Prometheusは、ひとつのサンプルあたり、1〜2バイトほどを使用するそうです。

なので、Prometheusが要求するサーバーのディスク容量は、以下の計算式で算出できます、と。

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample
必要なディスクサイズ = 保持期間（秒） × 秒あたりの取得サンプル数 * サンプルあたりのバイト数

1秒あたりに取得するサンプルを小さくするには、取得する時系列データの数を減らす（収集するターゲットを減らす、
ターゲットあたりの取得項目を減らす）か、取得間隔を長く設定するかのどちらかです。

ドキュメントによると、取得したデータは圧縮されるため、取得する項目数を減らす方が効果的だとか。

なお、ローカルストレージが破損した場合は、以下の対処になるとか。

• Prometheusをシャットダウンして、データディレクトリを削除する（これが最善らしい）
  • 当然、全データを失う
• 個々のブロックディレクトリを削除する
  • 削除したブロックに含まれる、2時間のデータは失う

どちらにせよ、Prometheusのローカルストレージは長期間のデータ保存を意図していないことがドキュメントでは強調されています。

データの保持期間を指定してみる

それでは、データの保持期間を短めにして、動作を確認してみましょう。

以下のような、データの取得間隔を短めにしたPrometheusの設定ファイルを用意し、起動。
prometheus.yml

global:
  scrape_interval:     1s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 1s # Evaluate rules every 15 seconds. The default is every 1 minute.

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

データの取得対象は、デフォルト（自分自身）のままです。

起動オプションとして、早めに消えることを確認したくて「--storage.tsdb.retention.time」を3分に設定しました。
あと、「--storage.tsdb.min-block-duration」を指定していますが、なんでこれを付けたかはまた後で…。

$ ./prometheus --storage.tsdb.retention.time 3m --storage.tsdb.min-block-duration 1m
level=info ts=2019-05-02T14:09:07.183Z caller=main.go:321 msg="Starting Prometheus" version="(version=2.9.2, branch=HEAD, revision=d3245f15022551c6fc8281766ea62db4d71e2747)"

Web Consoleで、起動オプションを認識していることを確認。

とりあえず、Web ConsoleでCPU使用時間（process_cpu_seconds_total）を表示。10分間の表示で見ています。

1分経過すると、こんなログが出力され

level=info ts=2019-05-02T14:10:44.219Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806153112 maxt=1556806200000 ulid=01D9WE45RQ73CF18Y6J2BPMN1Q duration=100.343317ms
level=info ts=2019-05-02T14:10:44.237Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.785374ms

ブロックができます。

$ find data -type f
data/wal/00000000
data/lock
data/01D9WE45RQ73CF18Y6J2BPMN1Q/meta.json
data/01D9WE45RQ73CF18Y6J2BPMN1Q/index
data/01D9WE45RQ73CF18Y6J2BPMN1Q/tombstones
data/01D9WE45RQ73CF18Y6J2BPMN1Q/chunks/000001

このログが4回出力されるまでは、ブロックディレクトリが追加されていきます。

level=info ts=2019-05-02T14:10:44.219Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806153112 maxt=1556806200000 ulid=01D9WE45RQ73CF18Y6J2BPMN1Q duration=100.343317ms
level=info ts=2019-05-02T14:10:44.237Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.785374ms
level=info ts=2019-05-02T14:11:30.196Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806200000 maxt=1556806260000 ulid=01D9WE5JP7Y6FFGZMKKS1KK2AD duration=77.507689ms
level=info ts=2019-05-02T14:11:30.217Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.549613ms
level=info ts=2019-05-02T14:12:30.229Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806260000 maxt=1556806320000 ulid=01D9WE7D97CMB7R8RS12G9E9YW duration=109.711593ms
level=info ts=2019-05-02T14:12:30.251Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.421509ms
level=info ts=2019-05-02T14:13:30.197Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806320000 maxt=1556806380000 ulid=01D9WE97W9WEKZCQ0957KVH2GX duration=75.948389ms
level=info ts=2019-05-02T14:13:30.215Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.492116ms

こんな感じに。

$ find data -type f
data/wal/00000000
data/01D9WE7D97CMB7R8RS12G9E9YW/meta.json
data/01D9WE7D97CMB7R8RS12G9E9YW/index
data/01D9WE7D97CMB7R8RS12G9E9YW/tombstones
data/01D9WE7D97CMB7R8RS12G9E9YW/chunks/000001
data/lock
data/01D9WE45RQ73CF18Y6J2BPMN1Q/meta.json
data/01D9WE45RQ73CF18Y6J2BPMN1Q/index
data/01D9WE45RQ73CF18Y6J2BPMN1Q/tombstones
data/01D9WE45RQ73CF18Y6J2BPMN1Q/chunks/000001
data/01D9WE5JP7Y6FFGZMKKS1KK2AD/meta.json
data/01D9WE5JP7Y6FFGZMKKS1KK2AD/index
data/01D9WE5JP7Y6FFGZMKKS1KK2AD/tombstones
data/01D9WE5JP7Y6FFGZMKKS1KK2AD/chunks/000001
data/01D9WE97W9WEKZCQ0957KVH2GX/meta.json
data/01D9WE97W9WEKZCQ0957KVH2GX/index
data/01D9WE97W9WEKZCQ0957KVH2GX/tombstones
data/01D9WE97W9WEKZCQ0957KVH2GX/chunks/000001

ここで、5回目のコンパクションが起こると

level=info ts=2019-05-02T14:10:44.219Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806153112 maxt=1556806200000 ulid=01D9WE45RQ73CF18Y6J2BPMN1Q duration=100.343317ms
level=info ts=2019-05-02T14:10:44.237Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.785374ms
level=info ts=2019-05-02T14:11:30.196Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806200000 maxt=1556806260000 ulid=01D9WE5JP7Y6FFGZMKKS1KK2AD duration=77.507689ms
level=info ts=2019-05-02T14:11:30.217Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.549613ms
level=info ts=2019-05-02T14:12:30.229Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806260000 maxt=1556806320000 ulid=01D9WE7D97CMB7R8RS12G9E9YW duration=109.711593ms
level=info ts=2019-05-02T14:12:30.251Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.421509ms
level=info ts=2019-05-02T14:13:30.197Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806320000 maxt=1556806380000 ulid=01D9WE97W9WEKZCQ0957KVH2GX duration=75.948389ms
level=info ts=2019-05-02T14:13:30.215Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.492116ms
level=info ts=2019-05-02T14:14:30.248Z caller=compact.go:499 component=tsdb msg="write block" mint=1556806380000 maxt=1556806440000 ulid=01D9WEB2F4SWD5FDP5EBV7BD0E duration=132.373486ms
level=info ts=2019-05-02T14:14:30.270Z caller=head.go:540 component=tsdb msg="head GC completed" duration=1.201336ms

ブロックディレクトリが増えなくなります。「01D9WE45RQ73CF18Y6J2BPMN1Q」という名前のディレクトリがいなくなりました。

$ find data -type f
data/01D9WEB2F4SWD5FDP5EBV7BD0E/meta.json
data/01D9WEB2F4SWD5FDP5EBV7BD0E/index
data/01D9WEB2F4SWD5FDP5EBV7BD0E/tombstones
data/01D9WEB2F4SWD5FDP5EBV7BD0E/chunks/000001
data/wal/00000000
data/01D9WE7D97CMB7R8RS12G9E9YW/meta.json
data/01D9WE7D97CMB7R8RS12G9E9YW/index
data/01D9WE7D97CMB7R8RS12G9E9YW/tombstones
data/01D9WE7D97CMB7R8RS12G9E9YW/chunks/000001
data/lock
data/01D9WE5JP7Y6FFGZMKKS1KK2AD/meta.json
data/01D9WE5JP7Y6FFGZMKKS1KK2AD/index
data/01D9WE5JP7Y6FFGZMKKS1KK2AD/tombstones
data/01D9WE5JP7Y6FFGZMKKS1KK2AD/chunks/000001
data/01D9WE97W9WEKZCQ0957KVH2GX/meta.json
data/01D9WE97W9WEKZCQ0957KVH2GX/index
data/01D9WE97W9WEKZCQ0957KVH2GX/tombstones
data/01D9WE97W9WEKZCQ0957KVH2GX/chunks/000001

この結果、最初の時間のデータがなくなります。「01D9WE45RQ73CF18Y6J2BPMN1Q」というのは、最初に作られた
ディレクトリでした。

というわけで、「--storage.tsdb.retention.time」で指定した保持期間を越えたデータは削除されていることが確認できました。

ところで、今回、起動オプションに「--storage.tsdb.retention.time」だけではなくて「--storage.tsdb.min-block-duration」も
指定しました。

$ ./prometheus --storage.tsdb.retention.time 3m --storage.tsdb.min-block-duration 1m

「--storage.tsdb.min-block-duration」を指定したことで、ブロックの範囲が1分になっています。

最初、以下のように「--storage.tsdb.retention.time」を指定しただけだとデータがまったく消えず、「もしかしてWALにいる間の
データは対象に入らないのでは？」と思い、変更に至りました。

$ ./prometheus --storage.tsdb.retention.time 3m

つまり、長時間待つのが嫌で、極端に短い時間をretentionに設定したのが完全に裏目に出たようです。

実際、削除対象はブロック単位のようです。

https://github.com/prometheus/prometheus/blob/v2.9.2/vendor/github.com/prometheus/tsdb/db.go#L670

ブロックディレクトリ内のmeta.jsonを見ると、minTimeとmaxTimeで、どの時間の範囲のデータが含まれているか確認することが
できます。
data/01D9WEEQN5CH9F53GAFCN3G14E/meta.json

{
    "ulid": "01D9WEEQN5CH9F53GAFCN3G14E",
    "minTime": 1556806500000,
    "maxTime": 1556806560000,
    "stats": {
        "numSamples": 27120,
        "numSeries": 452,
        "numChunks": 452,
        "numBytes": 77220
    },
    "compaction": {
        "level": 1,
        "sources": [
            "01D9WEEQN5CH9F53GAFCN3G14E"
        ]
    },
    "version": 1
}

ここからわかることは、「--storage.tsdb.min-block-duration」を設定することはそうないかもしれませんが、
「--storage.tsdb.retention.time」はブロックディレクトリで持つ範囲（デフォルト2時間）の倍数でなければ意味がない
ということですね。

覚えておきましょう。

いい確認になりました。

RESTEasy（JAX-RS）＋ArC（CDI）の利用に見る、Quarkusアプリケーションのビルド結果の中身

これは、なにをしたくて書いたもの？

Quarkusは、GraalVMを使ってアプリケーションをネイティブイメージにビルドできることを売りのひとつにしています。

ところで、GraalVMを使ってネイティブイメージを作ろうとするとけっこうな制限があって、アプリケーション側もそれなりに
対応する必要があります。

graal/LIMITATIONS.md at vm-1.0.0-rc16 · oracle/graal · GitHub

このあたり、Quarkusはどうしてるんだろうということで、小さなアプリケーションを使ってなにが起こっているのかを
少し追ってみることにしました。

環境

今回の環境は、こちらです。

Java、Apache Maven。

$ java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.18.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

$ mvn -version
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-05T04:00:29+09:00)
Maven home: $HOME/.sdkman/candidates/maven/current
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: ja_JP, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-48-generic", arch: "amd64", family: "unix"

GraalVM CE。

$ export GRAALVM_HOME=/usr/local/graalvm-ce
$ $GRAALVM_HOME/bin/native-image --version
GraalVM Version 1.0.0-rc16 CE

Quarkusは、0.14.0を使います。

お題

今回は簡単に、RESTEasy（JAX-RS）とArC（CDI）を使ったアプリケーションをビルドし、その時に生成される情報を
見てみたいと思います。

ArC

ArCは、Quarkusが実装しているCDIのサブセットです。

Cdi Reference

サポートしている機能と制限。

Supported Features

Limitations

@ConversationScoped、Decorator、Portable Extensions、BeanManagerの一部の機能、beans.xmlを無視する、Interceptorに
関する制限などがあります。

また、依存関係をインジェクションする際には、GraalVMのSubstrate VMをターゲットにしている関係上、privateメンバーではなく、
パッケージプライベートやコンストラクタインジェクションを利用するのがおすすめされています。

Private Members

でないと、リフレクションを使用するようにフォールバックしてしまうようです。

また、Portable Extensionsは使えませんが、代わりにビルド時の拡張ポイントがあり、こちらで多くの機能は代替できるようです。

Build Time Extension Points

あとで出てきますが、作成したプロジェクト内に含まれるArCの依存関係は、以下の2つです。

quarkus-arc

https://github.com/quarkusio/quarkus/tree/0.14.0/extensions/arc/runtime

arc

https://github.com/quarkusio/quarkus/tree/0.14.0/independent-projects/arc/runtime

とまあ、ArCの話はとりあえずこれくらいにして、先に進みましょう。

サンプルアプリケーションの作成

まずはアプリケーションの雛形を作ります。

$ mvn io.quarkus:quarkus-maven-plugin:0.14.0:create \
    -DprojectGroupId=org.littlewings.quarkus \
    -DprojectArtifactId=resteasy-arc

RESTEasy＋ArC（JAX-RS＋CDI）の最小構成のプロジェクトです。

この時のArCの依存関係を確認すると、以下のようになっています。

$ mvn dependency:tree | grep arc

...

[INFO] |  +- io.quarkus:quarkus-arc:jar:0.14.0:compile
[INFO] |  |  \- io.quarkus.arc:arc:jar:0.14.0:compile

「quarkus-arc」

https://github.com/quarkusio/quarkus/tree/0.14.0/extensions/arc/runtime

「arc」

https://github.com/quarkusio/quarkus/tree/0.14.0/independent-projects/arc/runtime

ここで、ArC本体が入っているIndependent Projectsというのは、最終的にQuarkusから独立可能なスタンドアロンなプロジェクトが
含まれているものです。現時点だと、ArCとBootstrapですが。

quarkus/independent-projects at 0.14.0 · quarkusio/quarkus · GitHub

簡単なCDI管理Beanと
src/main/java/org/littlewings/quarkus/resteasyasc/HelloService.java

package org.littlewings.quarkus.resteasyasc;

import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class HelloService {
    public String message() {
        return "Hello Quarkus!!";
    }
}

このCDI管理Beanを作成する、JAX-RSリソースクラスを作成します。JAX-RSリソースクラスは、CDI管理Beanのアノテーションを
付けない場合はSingletonになるようです。 src/main/java/org/littlewings/quarkus/resteasyasc/HelloResource.java

package org.littlewings.quarkus.resteasyasc;

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("hello")
public class HelloResource {
    @Inject
    HelloService helloService;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String message() {
        return helloService.message();
    }
}

パッケージングして起動。

$ mvn package
$ java -jar target/resteasy-arc-1.0-SNAPSHOT-runner.jar 
2019-04-30 00:44:53,592 INFO  [io.quarkus] (main) Quarkus 0.14.0 started in 0.712s. Listening on: http://[::]:8080
2019-04-30 00:44:53,613 INFO  [io.quarkus] (main) Installed features: [cdi, resteasy]

確認。

$ curl localhost:8080/hello
Hello Quarkus!!

これで、用意はOKです。

ビルド時に作成されたファイルを見る

ここで、targetディレクトリの中を見てみましょう。「target/lib」はアプリケーションの依存ライブラリなので、除外します。

$ find target -type f | grep -v 'target/lib'
target/maven-status/maven-compiler-plugin/testCompile/default-testCompile/inputFiles.lst
target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst
target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst
target/resteasy-arc-1.0-SNAPSHOT.jar
target/resteasy-arc-1.0-SNAPSHOT-runner.jar
target/classes/META-INF/application-info.properties
target/classes/META-INF/resources/index.html
target/classes/application.properties
target/classes/native-image.properties
target/classes/org/littlewings/quarkus/resteasyasc/HelloResource.class
target/classes/org/littlewings/quarkus/resteasyasc/HelloService.class
target/maven-archiver/pom.properties
target/wiring-classes/META-INF/build-config.properties
target/wiring-classes/META-INF/services/io.quarkus.arc.ComponentsProvider
target/wiring-classes/META-INF/quarkus-default-config.properties
target/wiring-classes/io/quarkus/arc/runtime/LifecycleEventRunner_Bean.class
target/wiring-classes/io/quarkus/arc/setup/Default_ComponentsProvider.class
target/wiring-classes/io/quarkus/arc/ActivateRequestContextInterceptor_Bean.class
target/wiring-classes/io/quarkus/arc/runtimebean/RuntimeBeanProducers.class
target/wiring-classes/io/quarkus/deployment/steps/UndertowBuildStep$boot10.class
target/wiring-classes/io/quarkus/deployment/steps/LoggingResourceProcessor$setupLoggingRuntimeInit4.class
target/wiring-classes/io/quarkus/deployment/steps/LifecycleEventsBuildStep$startupEvent11.class
target/wiring-classes/io/quarkus/deployment/steps/RuntimeBeanProcessor$build2.class
target/wiring-classes/io/quarkus/deployment/steps/ResteasyScanningProcessor$setupInjection8.class
target/wiring-classes/io/quarkus/deployment/steps/LoggingResourceProcessor$setupLoggingStaticInit1.class
target/wiring-classes/io/quarkus/deployment/steps/UndertowArcIntegrationBuildStep$integrateRequestContext6.class
target/wiring-classes/io/quarkus/deployment/steps/ArcAnnotationProcessor$build5.class
target/wiring-classes/io/quarkus/deployment/steps/ConfigBuildStep$validateConfigProperties7.class
target/wiring-classes/io/quarkus/deployment/steps/UndertowBuildStep$build9.class
target/wiring-classes/io/quarkus/deployment/steps/ThreadPoolSetup$createExecutor3.class
target/wiring-classes/io/quarkus/runner/ApplicationImpl1.class
target/wiring-classes/io/quarkus/runner/AutoFeature.class
target/wiring-classes/io/quarkus/runner/GeneratedMain.class
target/wiring-classes/io/quarkus/runtime/generated/RunTimeConfig.class
target/wiring-classes/io/quarkus/runtime/generated/RunTimeDefaultConfigSource.class
target/wiring-classes/io/quarkus/runtime/generated/RunTimeConfigRoot.class
target/wiring-classes/io/quarkus/runtime/generated/BuildTimeConfigRoot.class
target/wiring-classes/io/quarkus/runtime/generated/BuildTimeConfig.class
target/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloResource_Bean.class
target/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloService_Bean.class
target/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloService_Bean$$function$$1.class
target/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloService_ClientProxy.class
target/wiring-classes/javax/enterprise/context/control/ActivateRequestContext_Shared_AnnotationLiteral.class

「target/wiring-classes」というディレクトリに、いろいろ作成されています。

1度削除して、通常のビルド時とネイティブアプリケーションとしてのビルド時で作成されるファイルを比較してみましょう。

$ mvn clean

$ mvn package
$ mv target target-java

$ mvn -Pnative package
$ mv target target-native

差分を見てみると、特にネイティブイメージにしたからといってファイルが増えたりすることはなさそうです。
※wiring-classes/io/quarkus/deployment/steps配下は、生成する度に名前が変わるようなので、その差は無視します

$ diff -rq target-java target-native
ファイル target-java/classes/META-INF/application-info.properties と target-native/classes/META-INF/application-info.properties は異なります
ファイル target-java/classes/native-image.properties と target-native/classes/native-image.properties は異なります
ファイル target-java/maven-archiver/pom.properties と target-native/maven-archiver/pom.properties は異なります
target-native のみに存在: reports
target-native のみに存在: resteasy-arc-1.0-SNAPSHOT-runner
ファイル target-java/resteasy-arc-1.0-SNAPSHOT-runner.jar と target-native/resteasy-arc-1.0-SNAPSHOT-runner.jar は異なります
ファイル target-java/resteasy-arc-1.0-SNAPSHOT.jar と target-native/resteasy-arc-1.0-SNAPSHOT.jar は異なります
ファイル target-java/wiring-classes/META-INF/build-config.properties と target-native/wiring-classes/META-INF/build-config.properties は異なります
ファイル target-java/wiring-classes/META-INF/quarkus-default-config.properties と target-native/wiring-classes/META-INF/quarkus-default-config.properties は異なります
ファイル target-java/wiring-classes/io/quarkus/arc/ActivateRequestContextInterceptor_Bean.class と target-native/wiring-classes/io/quarkus/arc/ActivateRequestContextInterceptor_Bean.class は異なります
ファイル target-java/wiring-classes/io/quarkus/arc/runtime/LifecycleEventRunner_Bean.class と target-native/wiring-classes/io/quarkus/arc/runtime/LifecycleEventRunner_Bean.class は異なります
ファイル target-java/wiring-classes/io/quarkus/arc/setup/Default_ComponentsProvider.class と target-native/wiring-classes/io/quarkus/arc/setup/Default_ComponentsProvider.class は異なります
ファイル target-java/wiring-classes/io/quarkus/deployment/steps/ArcAnnotationProcessor$build5.class と target-native/wiring-classes/io/quarkus/deployment/steps/ArcAnnotationProcessor$build5.class は異なります
target-java/wiring-classes/io/quarkus/deployment/steps のみに存在: ConfigBuildStep$validateConfigProperties6.class
target-native/wiring-classes/io/quarkus/deployment/steps のみに存在: ConfigBuildStep$validateConfigProperties8.class
target-native/wiring-classes/io/quarkus/deployment/steps のみに存在: LoggingResourceProcessor$setupLoggingRuntimeInit3.class
target-java/wiring-classes/io/quarkus/deployment/steps のみに存在: LoggingResourceProcessor$setupLoggingRuntimeInit4.class
target-native/wiring-classes/io/quarkus/deployment/steps のみに存在: LoggingResourceProcessor$setupLoggingStaticInit1.class
target-java/wiring-classes/io/quarkus/deployment/steps のみに存在: LoggingResourceProcessor$setupLoggingStaticInit2.class
target-native/wiring-classes/io/quarkus/deployment/steps のみに存在: ResteasyScanningProcessor$setupInjection6.class
target-java/wiring-classes/io/quarkus/deployment/steps のみに存在: ResteasyScanningProcessor$setupInjection8.class
target-java/wiring-classes/io/quarkus/deployment/steps のみに存在: RuntimeBeanProcessor$build1.class
target-native/wiring-classes/io/quarkus/deployment/steps のみに存在: RuntimeBeanProcessor$build2.class
target-java/wiring-classes/io/quarkus/deployment/steps のみに存在: ThreadPoolSetup$createExecutor3.class
target-native/wiring-classes/io/quarkus/deployment/steps のみに存在: ThreadPoolSetup$createExecutor4.class
ファイル target-java/wiring-classes/io/quarkus/deployment/steps/UndertowArcIntegrationBuildStep$integrateRequestContext7.class と target-native/wiring-classes/io/quarkus/deployment/steps/UndertowArcIntegrationBuildStep$integrateRequestContext7.class は異なります
ファイル target-java/wiring-classes/io/quarkus/deployment/steps/UndertowBuildStep$boot10.class と target-native/wiring-classes/io/quarkus/deployment/steps/UndertowBuildStep$boot10.class は異なります
ファイル target-java/wiring-classes/io/quarkus/deployment/steps/UndertowBuildStep$build9.class と target-native/wiring-classes/io/quarkus/deployment/steps/UndertowBuildStep$build9.class は異なります
ファイル target-java/wiring-classes/io/quarkus/runner/ApplicationImpl1.class と target-native/wiring-classes/io/quarkus/runner/ApplicationImpl1.class は異なります
ファイル target-java/wiring-classes/io/quarkus/runner/AutoFeature.class と target-native/wiring-classes/io/quarkus/runner/AutoFeature.class は異なります
ファイル target-java/wiring-classes/io/quarkus/runtime/generated/BuildTimeConfig.class と target-native/wiring-classes/io/quarkus/runtime/generated/BuildTimeConfig.class は異なります
ファイル target-java/wiring-classes/io/quarkus/runtime/generated/RunTimeConfig.class と target-native/wiring-classes/io/quarkus/runtime/generated/RunTimeConfig.class は異なります
ファイル target-java/wiring-classes/io/quarkus/runtime/generated/RunTimeConfigRoot.class と target-native/wiring-classes/io/quarkus/runtime/generated/RunTimeConfigRoot.class は異なります
ファイル target-java/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloService_ClientProxy.class と target-native/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloService_ClientProxy.class は異なります

まず、パッと気になるのは自分が作成したクラスに対して、生成されているクラス。

target/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloResource_Bean.class
target/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloService_Bean.class
target/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloService_Bean$$function$$1.class
target/wiring-classes/org/littlewings/quarkus/resteasyasc/HelloService_ClientProxy.class

IDEなどで見てみると、ArCが提供するInjectableBeanインターフェースを実装したクラスが生成され、さらにクライアントプロキシも
作成されています。

JAX-RSリソースクラスに対応するクラスも、InjectableBeanとして作成されています。

これらの中で、実際のインスタンスをnewしたり、関連するクラスをInjectableReferenceProvider（後述）から取得して
依存関係を組み上げるような処理が含まれています。

今度は、Quarkusのパッケージで生成されたものを見ていきましょう。

最初に、アプリケーションのエントリポイントとなるJARファイルのMANIFEST.MFに含まれる、mainクラスの宣言を
見てみます。

$ unzip -p target/resteasy-arc-1.0-SNAPSHOT-runner.jar META-INF/MANIFEST.MF

Main-Class: io.quarkus.runner.GeneratedMain

このクラス、生成されたクラスの中に含まれています。

target/wiring-classes/io/quarkus/runner/GeneratedMain.class

中身を見ると、以下のクラスを呼び出してアプリケーションのセットアップを行っているようです。

target/wiring-classes/io/quarkus/runner/ApplicationImpl1.class

少し、目線を変えて、先ほどの自分が作成したクラスに対するBeanやクライアントプロキシの生成部分を見てみましょう。

以下のパッケージで行っているようです。

https://github.com/quarkusio/quarkus/tree/0.14.0/independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor

Beanやクライアントプロキシを生成しているのは、以下のクラス。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/BeanGenerator.java

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/ClientProxyGenerator.java

宣言されている定数値（suffix）を見ると、コンパイル時に生成されたもの（「Bean」、「ClientProxy」）と同じものを
見ることができるでしょう。

他にもGeneratorはたくさんあるので、気になる方は上記のパッケージを…。

次に、DI関連のところを少し見てみましょう。

InjectableReferenceProviderというのが、与えられたコンテキストに応じたインスタンスを取得できるインターフェースになります。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/InjectableReferenceProvider.java

その実装として、InstanceProvider、BeanManagerProviderなど、種々のProviderがあります。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/InstanceProvider.java

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/BeanManagerProvider.java

インジェクション可能なInjectableBean、InstanceHandleなどがあり、

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/InjectableBean.java

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/InstanceHandle.java

これらのBeanを扱うのがArcContainer（とその実装）になります。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/ArcContainer.java

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/ArcContainerImpl.java

CDI#currentなどで使う、CDIのProviderなどやBeanManagerの実装もあります。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/ArcCDIProvider.java

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/BeanManagerImpl.java

このあたりが、ArCのCDIの実体のようです。

で、CDI管理Beanをどうやって登録するかというところを少し見てみましょう。

CDI管理Beanは、ビルド時に生成されるComponentsProviderより取得します。

target/wiring-classes/io/quarkus/arc/setup/Default_ComponentsProvider.class

このクラスは、BeanProcessorおよびComponentsProviderGeneratorにより作成されます。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/BeanProcessor.java#L217

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/ComponentsProviderGenerator.java#L63

BeanProcessorが受け取る内容を見ると、それはもうたくさんの種類のクラスについての情報を受け取るようで…。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/BeanProcessor.java#L84-L92

そして、Beanやクライアントプロキシなどの生成が行われます、と。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/BeanProcessor.java#L159-L165

生成されたComponentsProviderは、必要なBeanをComponentsとして登録するような処理を実装しています。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/Components.java

この情報を使って、ArcContainerの実装はどのようなBeanがあるかを把握するようになっています。

https://github.com/quarkusio/quarkus/blob/0.14.0/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/ArcContainerImpl.java#L94-L116

なお、ComponentsProviderはService Providerの仕組みでロードされます。

$ unzip -p target/resteasy-arc-1.0-SNAPSHOT-runner.jar META-INF/services/io.quarkus.arc.ComponentsProvider
io.quarkus.arc.setup.Default_ComponentsProvider

あ、ArCとは少し離れるようですが、作成したJAX-RSリソースクラスは「resteasy.scanned.resources」として埋め込まれます。

target/wiring-classes/io/quarkus/deployment/steps/UndertowBuildStep$build9.class

というわけで、リフレクションを回避しつつ、必要な処理を行うクラスを生成して動かすことで、CDIなどの仕組みを
実現しているみたいですね。

Substrate VMの機能を使ったコードは？

となると、Substrate VMの機能を使ったコードは現れないのか？というと、そんなことはありません。

Substrate VMの、@AutomaticFeatureアノテーションが付与されたクラスが生成されます。

target/wiring-classes/io/quarkus/runner/AutoFeature.class

この中では、RuntimeReflectionを使い、リフレクションの情報を登録する処理が生成されます。

JAX-RSリソースクラスのクラス自体やメソッドの情報は、ここで登録するようです。

このクラスを生成するのは、以下のクラスのようです。

https://github.com/quarkusio/quarkus/blob/0.14.0/core/deployment/src/main/java/io/quarkus/deployment/steps/SubstrateAutoFeatureStep.java#L51

まとめ

あんまりまとめがないですが、RESTEasy＋ArCの簡単なアプリケーションのビルド時の情報から、中身を少し見てみました。

基本的に、ビルド時のコード生成を行ってGraalVM（Substrate VM）の制限を回避するような感じで作られているようですね。

このあたりはバージョンが進むといろいろ変わるような気はしますが、現時点の参考情報として。
追ってみて、けっこう面白かったです。