株式会社日立製作所 ソフトウェア事業部 ネットワークソフト設計部 主任技師
ミッションクリティカルシステムにおける安定稼働と可用性をいかに確保するかは、今やシステム開発者にとって必須かつ最大の要件となってきている。とくに近年この問題は、インターネットの拡がりによって、Webシステムにおいて顕著となってきている。
日立製作所 ソフトウェア事業部 第2ネットワークソフト設計部 主任技師の中島恵氏は、「WebシステムはアプリケーションサーバおよびJavaによる開発生産性の向上によって、容易な構築が可能になった。しかし一方で業務量のピーク時における性能上のトラブルも跡を絶たない。Webシステムの安定性・堅牢性を高めるためには、システムの性能劣化につながる要因、すなわち『CPUネック』『メモリネック』『バックエンドシステムによるネック』の3つを克服しなければならない。中でも重要なのはメモリサイジングや実行データ流量の適切かつ正確な見積もりだ。そこで今回のセッションでは、メモリサイジングのための有効な手法と、当社Cosminexus（コズミネクサス）を活用した取り組み例について説明したい」と切り出した。
中島氏によれば、メモリサイズのトラブルでもっとも多い例が、システムのエンドユーザ数の増加に伴ってトランザクションの増加が起こり、GCが頻発した結果、レスポンス遅延＝システムのスローダウンが発生するといったパターンである。この現象を予防しようにも、従来は「Javaの世界では見積もりは困難。実際に負荷テストを行ってみないとわからない」といった、事実上あきらめに近い状態だった。これに対して同氏は、「性能単価を測定していけば、GC発生の頻度による業務への影響度を客観的に見積もることができる」と主張。「高い精度のメモリサイジングを行うには、JavaVMのメモリ管理の仕組み=GCを理解することが重要。これによって、効率的なメモリサイズの見積もりを行うことができるようになる」と語る。
よく知られているように、GCとはJavaVMが管理するメモリ領域中の使用済みメモリ領域を破棄し、空き領域を作る機能である。GCにはNew領域のみを対象にした「CopyGC」と、全領域を対象に、使用済みのインスタンスをすべて削除する「FullGC」の2種類があり、後者の処理中は、大量のメモリアクセス処理を業務プログラムの実行を一時停止して行うため、パフォーマンスに影響を及ぼす可能性が高い。中島氏は「システムのスローダウンの大きな原因はFullGCであり、この頻度をコントロールする上で、メモリ管理は重要なポイントとなる。特に月末の処理ピーク時などでは処理量に対してメモリヒープが不足して、システムのスローダウンや最悪の場合は停止などを招いている例が少なくない」と指摘する。
ここでのメモリ管理とは、Javaヒープサイズの見積もり手法をどのようにするかであり、サイジングの要件としては、ピーク時であってもFullGCを起こさないメモリサイズをいかに算出するかが求められる。
「Javaヒープを構成する領域の中で『New』領域は生存期間の短いデータ処理に割り当てられる。一方の『Old』領域にはログインからログアウトまで生き続けるセッション情報が保存されるため、この部分がだんだん膨らんでいって、一杯になるとFullGCが発生する（図１）。何個のセッション情報が蓄積するとOld領域が一杯になるのかを計算することが、メモリサイジングの基本的な考え方となる」と中島氏。
メモリの算出に必要な情報としては、「セッション情報サイズ」「1秒当たりのログイン数」「最大同時ログイン数」がある。これらを元にセッション情報の蓄積に起因するFullGC発生間隔を算出し、次に業務プログラム使用領域サイズを算出、最後に最大同時ログイン数がどれくらいあるかを勘案する。具体的な算式としては、下記のようになる。
FullGCの発生間隔
・ Oldの業務プログラム使用領域サイズ：Old
・ 1秒あたりの想定ログイン数: Login
・ セッション情報サイズ：M
＜FullGCの発生間隔 = Old／(Login×M)＞
「また、正確な見積もりを行う上で、『最大同時ログイン数』の考慮は重要だ。ログインのピーク時にFullGCが発生すると、使用中のセッションは削除されずに残ってしまうからだ。この結果、通常であればFullGCが120分おきに発生する見積もりであっても、削除されずに残った処理の分、Old領域の残量が少なくなってしまい、120分よりも短い間隔で再度FullGCが発生することになる。これを防ぐためには、あらかじめ最大同時ログイン数分の領域サイズを多めに確保しておく必要がある。ここまで配慮することで、正確なFullGCの発生間隔と、その確保に必要なOld領域サイズの見積もりが可能になる」と中島氏。
ここまででOld領域のサイズを算出・確定できた。次に必要なのはメモリ全体のサイズ、すなわちJavaヒープのトータルサイズを求める作業だ。Javaヒープの内訳は領域ごとの比率があらかじめ決まっているため、必要なOld領域サイズが確定できれば、そのサイズから逆算してNew領域など他の領域サイズを算定することが可能だ。
以上のような一連のヒープサイズの見積もりを、日立製作所の「Cosminexus」を用いて簡単かつ正確に行うことができると中島氏は語る。
「Cosminexusが提供している『パフォーマンス見積もりシート』に、セッション情報サイズやFullGCの許容間隔などの必要事項を入力すると、サイジングした数値が即時に表示される。これによって見積もり精度を向上させ、運用に入ってからのトラブルの芽を摘むことができる。また、Cosminexusには予期せぬFullGC多発の検知機能が備わっており、Javaヒープサイズの遷移をCosminexusが蓄積・解析することでFullGCの多発を検知し、回避のアクションを自動的に取ってくれるのだ。たとえばFullGCの多発を予測すると、自動的にリクエストの入り口を絞って、システムのスローダウンを未然に防ぐといった対応が可能だ」と中島氏。
また、FullGCの予兆を検知したときに、Cosminexusでは自律的にサーバを再起動して、問題を回避することもできる。この際、負荷分散機による振分け定義変更が実行され、再起動中は別のサーバにセッション情報を引継ぐため、ユーザは業務の再起動処理を意識することなく継続することができるというメリットがある。
最後に中島氏は、Cosminexusが提供するJavaVMのヒーププロファイル機能を用いてメモリリークの原因を特定し、メモリリークによる不具合を迅速に解決できると説明（図2）。「リークしているクラスだけではなく、さらにその周辺クラスの参照関係までを、JavaVMのGC処理を利用したプロファイル機能で解析できる。このように、Cosminexusはテスト環境では予見できなかったメモリリークによる不具合を、正確に調査する方法を確立している」と説明して、セッションを締めくくった。
株式会社 日立製作所
HMCC（日立オープンミドルウェア問い合わせセンター）
TEL 0120-55-0504
URL http://www.hitachi.co.jp/soft/hmcc/
情報提供サイト
URL http://www.cosminexus.com/
