“Don’t”Stop the World――Full GCへの対策:Java Review(3/3 ページ)
Full GCの発生は、ミッションクリティカルなWebシステムでは許容できない問題である。発生の抑止方法について順を追って検討してみよう。
冗長システム構成と運用で対策する
Full GCが発生して利用者への応答が一時的に停止しても問題はない、という業務システムは存在する。しかしそのような状態が許されないミッションクリティカルシステムの場合、業務システム全体で工夫することでFull GC対策を行う。
その方式は、システムを冗長構成とした上でFull GC発生の契機となるJavaヒープのOld領域の使用率を運用ツールなどで監視する、というものだ。Old領域の使用率を監視し、ある“しきい値”を越えた契機をとらえて、負荷分散機によりリクエスト数を絞り込んだり、Javaプロセス自体を再起動したりする。システムの構成や運用方式が複雑にはなるが、ほかのノードへ業務を引き継ぐことで、Full GC発生による利用者への影響を最小限にとどめられる。要はハードウェアリソースを増やし、問題が発生する前にシステムを停止して、リフレッシュする方法である。
Full GCが発生しないWebアプリケーションサーバを利用する
ここまでは、GCアルゴリズムの変更やシステム全体での対策を述べてきた。次にFull GCの対策として、Webアプリケーションサーバを利用することで対策できる方法を紹介する。
繰り返しになるが、Full GCはJavaヒープのOld領域が枯渇することで発生する。Full GCの主な発生原因は、一般的なWebシステムではOld領域でのセッション情報の蓄積による。トランザクション処理のような短時間の処理とは異なり、セッション情報は複数のリクエストにまたがって保持されるため、長時間利用されるオブジェクトと認識されOld領域に移行しやすい。そしてOld領域に移動したセッション情報が主原因となり、Full GCが発生してしまう。
日立のCosminexusではこの点に着目して、GCアルゴリズムの変更のように停止時間を短縮するのではなく、「Full GCを発生させない」機能を実現している。これが「Full GCレス機能」である。Full GCレス機能では、新しいメモリ管理方式を採用している。それはJavaヒープ領域のほかに、独自のメモリ域(明示管理ヒープ領域)を持つ方式だ。
Full GCレス機能を使用すると、長時間利用されるオブジェクトは明示管理ヒープ領域に格納されるため、Full GCの発生を抑止できる。そのためのハードウェアや業務アプリケーションの変更を必要としないのがポイントである(図2)。
またFull GCレス機能の「良い点」として、マシン台数を最適化できることが挙げられる。Full GC発生による利用者への影響を最小限にとどめるために、わざわざシステムを冗長構成にする必要はない。最適化したシステム構成で、利用者に影響を与えず「Don't」 Stop the Worldを実現できる。
関連記事
- JavaVMのメモリ管理をマスターする
Webシステムの安定動作には、メモリ使用量の適切な見積もりが不可欠。だがJavaVMでメモリがどのように管理されるかを理解しているだろうか? メモリに関する問題が発生すると、知識や技術資料の不足によって問題が長期化しがち。JavaVMでどのようにメモリが管理されているかを理解し、正確なメモリサイジングやメモリ関係のトラブルの早期解決へとつなげよう。 - ITアーキテクトに求められる「Javaの互換性やサポート」という視点
Javaにおける開発環境の進歩と同時に、ブラックボックス化とそれにともなう課題も発生している。開発現場での課題解決を図る連載第1回では、互換性とサポート期限に焦点を当てる。
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.