新Log4jへの移行: Log4jプロジェクト管理グループとのQ&A

先日InfoQでお伝えしたように,Apache Software Foundationは,人気ロギングフレームワークのLog4jバージョン1のサポート終了(EOL/End of Life)を発表し,ユーザに対してバージョン2への移行を推奨した。

InfoQでは以下のApache Logging Services Teamメンバとコンタクトを取り,Log4jの新バージョン移行に関する詳細と,今後の予定について聞いた – Apache Logging PMCでLog4j 2イニシアティブのRalph Goers氏,Apache Logging PMCメンバのRemko Popma氏とGary Gregory氏,Apache Logging責任者のChristian Grobmeier氏。

InfoQ: Log4j2は公開されてちょうど1年になりますが,Maven Centralの統計によれば,バージョン1の方がバージョン2より多く利用されているようです。今回のEOLはユーザにとって,新バージョン移行の動機になるでしょうか?

Remko: 少なくとも,log4j 2の存在がもっと意識されるようにはなると思っています。特に問題がなければ,何かを変える気にはあまりならないというのは,十分に理解できますが,このEOLを機会として,少なくとも新しいプロジェクトではLog4j 2を使って欲しいですね。

Christian: EOLは単なるマークですが,今後Log4j 1リリースに対して多くの時間が投資されることはない,ということが誰の目にも明らかになったはずです。バージョン1リリースは非常に複雑ですし,今後新たなリリースが行われないので,セキュリティ上の問題を引き起こす可能性があります。 実際にはLog4j 1にもバグトラッカが用意されていて,誰でもまだ問題を報告できるようにはなっていますが,パッチが提供されない限り,それらをフィックスする予定はありません。セキュリティ上の理由だけでも,アップグレードについて検討するべきだと思います。

InfoQ: Log4jが新バージョンに書き直された大きな理由は,バージョン1にあった数多くのアーキテクチャ的な問題を解決するためだと思うのですが,単純なログ機能が必要なユーザもたくさんいると思います。新しい機能を必要としない,そういったユーザに対して,バージョン2への移行をどのように説得しますか?

Remko: “単純なログ機能が必要”というのは,“将来的なログ機能の必要性の分析や,選択肢を比較する時間がない”という意味であることも少なくありません。それはよく分かります。そういったユーザには,Log4j 2が最適だと思います。簡単に利用できて,動作も非常に高速です。将来的な機能拡張に対しても,機能的な深さと柔軟性を十分に備えています。

Ralph: 私たちはユーザに対してLog4j 2にアップグレードするように勧めていますが,彼らが希望する限り,Log4j 1に固執するのはもちろん自由です。但し,Log4j 1で見つかった問題を報告することは今後も可能ですが,自分自身でパッチを用意するか,あるいは誰か他の人がそうしてくれない限り,問題が解決されることはありません。その点は理解しておく必要があります。

Gary: 私たち(開発者)には自明なことですが,すべての人たち(ユーザ)にはそうでない点があります。それは私たちがみなボランティアであること,つまり,時間やリソースが限られているということです。ですから,限られたリソースを最も効率的に使う方法は何なのかを決める必要があります。Log4j 1の変更はとても難しいので,同じ労力をバージョン2に集中した方が,より多くの価値を得ることができるのです。

もうひとつは,EOLは言葉の上に過ぎないということです。誰か名乗り出てくれれば,リリースもあり得ます。ただし問題の中には,新しいアーキテクチャとバージョンでなければ,簡単には対処できないものもあります。

InfoQ: Log4jバージョン1の利用を止めることになれば,単にバージョン2にアップグレードするのではなく,別のロギングフレームワークへの移行を検討する開発者も多いと思うのですが,そのような心配はありませんか?

Remko: Log4j 2は他の選択肢に対して,十分な競争力があると自信を持っています。それを証明するために,特に注目してほしい特徴が,Log4j 2にはいくつかあります。

  • コミュニティのサポート: Log4j 2には活発なコミュニティがあって,質問への回答や機能の追加,バグ修正などが行われています。
  • パフォーマンスへの影響が極めて低い: Asynchronous Loggerによって,ログを完全にオフにした場合とほとんど同じレベルのパフォーマンスを提供します。
  • 安定性と信頼性: コンフィギュレーション修正時,自動的に再読み込みを実行します。再設定の実行中でもログイベントを失うことはありません。
  • カスタムログイベントやフィルタリング(コンテキストデータ,マーカ,正規表現,その他のログイベント構成要素に基づく),ルックアップといった,豊富な機能を備えています。
  • プラグインアーキテクチャ: カスタムコンポーネントを開発することで容易に拡張可能です。
  • APIサポート: 直接使用する以外に,SLF4J,Commons Logging,Log4j 1,java.util.logging経由で使用することも可能です。
  • 2.4リリースでJava 8のラムダ式をサポートする予定です。

InfoQ: Log4jバージョン1のEOLのタイミングは適切だったと思いますか?もしも変更するとしたら,もっと以前か,後か,あるいは今と同じですか?

Remko: 正しかったと思います。Log4j 2はすでに19回のリリースを重ねてきましたし,直近の6回はGA(General Availability)としてマークされています。GAリリースになって1年以上になるということが,十分に安定していることの証明になります。このことから,Log4j 2はLog4j 1の代替として安全であると考え,前バージョンの終了を宣言するにはよいタイミングだと思ったのです。

Ralph: 今回のEOLに関する発表は,Log4j 1のバグ修正を誰も行っていない,今後も行う予定がないという事実を報告したに過ぎません。その意味では,バージョン1はもうずっと前にEOLに達していたとも言えます。私たちに必要だったのは,Log4j 1を公式にリタイアさせる前に,Log4j 2を安定した,信頼できる代替品にすることだったのです。

InfoQ: ログの分野で 今後,大きな課題となりそうなものは何だと思われますか?Log4jに関してはどうでしょう?

Remko: 個人的には,Log4j 2のパフォーマンスを,特に同期ロギングのシナリオで改善していきたいと思っています。この領域では,まだ改善の余地がたくさんあると思うのです。大局的な課題としては,おそらくログ管理でしょう。コレクション,中央集約,長期保持,ログの解析や検索,報告といった分野です。このような問題に取り組んでいる製品もありますし,もし標準化が行われれば,Log4jもそのような作業を支援することができるとおもいます。

Apache Software Foundationでは,バージョン1からバージョン2へのアップグレードを望むユーザ向けのマイグレーションガイドや,バージョン2の採用を推奨するLog4j 2の機能概要などを用意している。