投稿者: T.yuki

Javaの利用とサポート期間の振り返り

Javaは以前は無償で使えていたのですが、今は商用利用は有償となっておりサポート期間もバージョンによって違います。Java(Oracle JDK)を使ってみようと思い、今更ながらまとめてみました。

2014年3月　Java8がリリース
Java8までが無償利用が出来て、且つ、バグフィックスやセキュリティパッチの提供も（無償で）受けられたJavaです。6→7→8とメジャーバージョンアップが行われてきましたがバージョンアップの間隔は3〜4年となっていて特に決まっていませんでした。また、次のバージョンが出たからといって前のバージョンのパッチ提供がすぐになくなるということはなかったと思います。今は、商用利用でのJava8のパッチの提供は終了しています（2019年1月に終了）。個人利用の場合は2020年12月までパッチ提供があります。

= = 追記 = =
Java8の個人利用ですが無期限に変更されたようです。パッチ提供をやめる場合は18か月前には通知するようです。2020年5月13日付けの Oracle Java SE Supportロードマップ の抜粋です。

2017年9月　Java9がリリース
Java9からはバージョンアップは半年ごとになりました。パッチのサポートも半年間のみです。Java9を使い始めて半年後にはJava10が出るのでそちらに移行すれば良いわけですが、商用利用している場合はそう簡単に載せ換えられるものでもありません。半年後にパッチのサポートがないからと言ってJava9が使えなくなるというわけではないのですが、商用利用の場合は不安があります。その場合はお金を払うことで（つまり、有償で）Oracleからパッチを提供してもらうことはできます。

2018年9月　Java11がリリース
Java11からは商用でJavaを利用する場合は有償となりました。Oracleとライセンス契約が必要です。非商用（開発環境での利用）もしくは個人利用であれば無償です。またJava11では有償としたためか半年のサポートではなく5年間の長期サポート(LTS:Long Time Support)となっています。Java11以降もJavaのバージョンは半年ごとにあがっていきますが、Java11のようなLTS版は3年ごとに出るようです。次のLTS版はJava17です。non-LTS版も有償ですがサポート期間は半年間です。
個人の場合は無償で利用はできますがOracleからのサポートはなさそうです。

= = 2022年5月追記 = =
2021年9月　Java17がリリース
この記事を執筆した時点ではLTS版は3年ごとのリリースだったのですが、現在では2年ごとのリリースになるようです。ですのでJava17の次のLTS版はJava21になります。ただ、Javaのロードマップの注釈に「LTSの指定と日付は変更される場合があります」のコメントもありました。

2018/09　Java11　LTS
2019/03　Java12　non-LTS
2019/09　Java13　non-LTS
2020/03　Java14　non-LTS
2020/09　Java15　non-LTS
2021/03　Java16　non-LTS
2021/09　Java17　LTS
2022/03　Java18　non-LTS
2022/09　Java19　non-LTS
2023/03　Java20　non-LTS
2023/09　Java21　LTS
2024/03　Java22　non-LTS
2024/09　Java23　non-LTS

Java11以降、商用でJava(Oracle JDK)を利用する場合はタダではなくなったということです。ですが、OpenJDKというものを使えば商用でも無償でJavaが利用できます。OpenJDKは、OpenJDKコミュニティが作成したソースコードをOracle社がビルドしたものなのでOracle JDKとほぼ同じと考えてよいでしょう。ただOpenJDKも半年ごとにバージョンアップが行われていて、パッチも半年間のみの提供です。半年ごとに次のバージョンのOpenJDKに載せ換える手間があります。

ちなみにOracle社の製品（ウェブアプリケーションサーバーのweblogic）を使用している場合は製品のライセンス契約の中にJavaの利用が含まれるようなのでそれを使ってもよいかもしれません。Oracle社の方でweblogicのバージョンとJavaのバージョンとの整合性を確認してくれるようです。

以下はOracle社が行うJavaのサポート期間です（2020年4月現在）。

Premier Support、Extended Support、Sustaining Support の3つがあります。Oracleの「ファースト・ステップ・ガイド 第8版」によると「通常、ソフトウェア製品は出荷開始後の5年間をPremier Support期間とし、包括的なメンテナンスとソフトウェア・アップグレードを提供します。Premier Support期間終了後は、特定のプログラム・リリースについては、追加料金設定により、Premier Supportに準ずるサービス・レベルを維持するExtended Support期間が通常3年間提供されます。Extended Supportが設定されないリリースおよびExtended Support期間の終了後はSustaining Support期間となります。」とあります。

ちなみに、Java8のPremier Support期間が2022年3月までとなっているのが疑問だったのだけれど（Java8の商用利用でのサポートは2019年1月に終了したはず）、、これは本来は無償で使えたJava8を有償でOracle社と契約することでサポートしてもらえるということなのかな？と思いました。

Nginxでのリクエストとレスポンスのバッファサイズのチューニング

Nginxで運用しているWEBサーバーに画像ファイルをアップロード（フォームからのPOSTを）した際、「413 Request Entity Too Large」と表示されてアップロードができませんでした。

これはどうやらnginxがデフォルトで受信できるリクエストサイズが小さいためにエラーとなっているようです（デフォルトでは1メガバイトのようです）。この画面が表示されたときのnginxのerror.logには「client intended to send too large body」と出力されていました。受信できるリクエストサイズを拡張するにはclient_max_body_sizeディレクティブに適切な値を設定する必要があるとのこと。画像ファイルのアップロードにはPHPを使用しており、php.iniの中のupload_max_filesizeで最大2メガバイトと指定しているので、client_max_body_sizeには2メガバイト以上を指定することにしました。

この設定で画像のアップロードはできるようになったものの、error.logには「a client request body is buffered to a temporary file」のワーニングが表示されていました。気持ちが悪いので、このワーニングも対処することにします。調べてみるとclient_body_buffer_sizeディレクティブに適切な値を設定することで解消するらしい。client_body_buffer_sizeのデフォルト値は64ビットOSの場合は16キロバイトが一般的でリクエストサイズがこれを超えた場合にワーニングを出力するとのことです。このサイズを超えたリクエストはバッファに収まらないので一時ファイルに出力したことをワーニングとして示しているようです。デフォルト値ではあまりにも小さいので思い切ってアップロード可能な画像サイズまで引き上げました。一時ファイルを出力することはディスクI/Oが発生して処理時間が長くなってしまいますので。

なお、この一時ファイルはディスク上のファイルではなくメモリ上のファイル(tmpfsという)も指定可能なようです。tmpfsを使用すればディスクI/Oは発生しないので良いように思えるのですが、リクエストサイズがtmpfsの容量を溢れてしまうとスワップ領域に一時ファイルが書き出されてしまうということでtmpfsの使用はやめました。ちなみに一時ファイルの出力先の指定はclient_body_temp_pathディレクティブで指定できるとのことです。tmpfsはディスク容量を確認する際に使用するdfコマンドで確認できます。

ちなみに先ほど書いた「a client request body is buffered to a temporary file」のワーニングですが、初期設定のnginxでWordPressを運用していると必ず出てしまうようですね。。

これで画像ファイルのアップロード時のエラーおよびワーニングは出なくなりました。なので、いったんこれで様子見をしようと思います。

まとめ。リクエストのバッファリングに関する設定は以下をチューニングする。

client_max_body_size
受信できる最大リクエストサイズ。デフォルトでは 1M 。

client_body_buffer_size
メモリ上のバッファに読み込む最大リクエストサイズ。デフォルトでは 8k or 16k（使用するOSにより変わる）。このサイズを超えるリクエストだった場合はclient_body_temp_pathに指定された一時ファイルにリクエストを書き出す（ディスクI/Oが発生する）。

client_body_temp_path
バッファの代わりとして使用する一時ファイルの出力先。

[広告]

ここからはリクエスト時のバッファサイズについて調べているうちにわかったことを覚え書きとして残しておきます。nginxではリクエストだけではなくレスポンスのバッファについても設定ができるようになっています。レスポンス時のバッファって何のこと？と最初は思ったのですが、PHPやCGIを処理するFastCGIサーバーからのレスポンスのバッファリングのことだと理解しました。

nginxではPHPやCGIを処理する際、fastcgi_passディレクティブでFastCGIサーバーのIPアドレスとポートを指定します。

FastCGIを使っている場合のレスポンスのバッファリングに関する設定は以下のようなものがあります。

fastcgi_buffering
バッファリングを有効にするかどうかの設定。デフォルトでは有効となっている。

fastcgi_buffer_size
一番最初のレスポンスをバッファリングする際のサイズを指定する。デフォルトでは 4k or 8k（使用するOSにより変わる）。

fastcgi_buffers
fastcgi_buffer_sizeにレスポンスが収まりきらなかった場合、fastcgi_buffersを使用する。fastcgi_buffersはパラメータを2つ持ち、1つ目のパラメータは領域の個数、2つ目のパラメータは1領域分のサイズを指定する。デフォルトでは 8　4k or 8k。4kもしくは8k（使用するOSにより変わる）の領域を最大8個使用するという意味。

fastcgi_busy_buffers_size
FastCGIサーバーからのレスポンスを受信しているときの最大バッファサイズ。デフォルトでは 8k or 16k（使用するOSにより変わる）。fastcgi_buffersと同じにするか、2倍程度にするのが一般的らしい。

fastcgi_max_temp_file_size
FastCGIサーバーからのレスポンスがバッファから溢れたときに書き出される一時ファイルの最大サイズ。

デフォルトだとfastcgi_buffer_size、fastcgi_buffersがかなり小さくメモリ上のバッファが足りなくなった場合は一時ファイルに書き出すとのこと。その際、「an upstream response is buffered to a temporary file」のメッセージがerror.logに出力されるらしい。ところがFastCGIサーバーからのレスポンスがどう考えてもfastcgi_buffer_size、fastcgi_buffersのバッファサイズを超えていると思われるのだけれど、このメッセージがerror.logに出力されていない。画像ファイルをレスポンスにしているからかなりのサイズだと思うのだけれど。これについて思い当たるのは以下の2点ということに考えが至りました。

  • 上の絵ではnginxとFastCGIサーバーは別々のサーバーとしていますが、実際の僕の環境はnginxとFastCGIサーバーはUnixソケットを通じて同一のサーバーでデータ連携をしている。これがバッファリング時のエラーを回避させているのか？
  • 上の絵ではnginxはWEBサーバーであってリバースプロキシの役割は持たせていない。nginxをリバースプロキシとして運用する場合はproxy_passディレクティブを設定してプロキシ先を指定するが、そのような構成ではない。レスポンス時のバッファリングのエラーはプロキシとして運用したときの場合のものか？

ちなみに2点目にあるリバースプロキシとしてnginxを運用する場合は以下のディレクティブでバッファリングに関する設定を行います。FastCGIのときの意味合いとほぼ同じだと思っているのですが。。

proxy_buffering
proxy_buffer_size
proxy_buffers
proxy_busy_buffers_size
proxy_max_temp_file_size

「an upstream response is buffered to a temporary file」が発生しない理由はよくわからないのですが、とりあえず上手くいっているようなのでFastCGIのレスポンスのバッファリングの設定はデフォルトのままとしています。

最後にFastCGI系とプロキシ系のレスポンス時のバッファリングに関するディレクティブの説明（nginxの公式サイト）を載せておきます。

・FastCGI系
・プロキシ系