Javaプログラムを実行する際、パフォーマンスを大きく左右する要因の一つに「Stop-the-World」イベントがあります。これは、ガベージコレクション（GC）によって全てのアプリケーションスレッドが一時的に停止される瞬間を指します。アプリケーションが大規模であるほど、この一時停止時間が長引き、応答性の低下や遅延の原因となります。特にリアルタイム処理や高パフォーマンスが求められるシステムでは、このStop-the-Worldの影響は無視できません。本記事では、JavaのStop-the-Worldイベントを最小化し、パフォーマンスを向上させるためのGC最適化技術について、具体的な方法を紹介します。
Stop-the-Worldイベントとは
Stop-the-Worldイベントとは、Javaのガベージコレクション（GC）プロセス中に、全てのアプリケーションスレッドが停止される瞬間を指します。この停止は、Java仮想マシン（JVM）がメモリ管理の一環として、不要なオブジェクトを回収し、メモリを解放する際に発生します。名前の通り、すべての処理が一時的に停止するため、リアルタイム性を求められるアプリケーションや、レスポンスが重要なシステムにおいて大きな影響を及ぼします。
Stop-the-Worldの重要性
GCの際にアプリケーション全体を停止するのは、JVMがメモリの整合性を保つために必要な措置です。しかし、この停止時間が長くなると、ユーザーの体感速度が低下し、パフォーマンスのボトルネックとなる可能性があります。特に大規模なアプリケーションでは、Stop-the-Worldの発生が頻繁になるため、効果的な最適化が求められます。
GCの基本概念とStop-the-Worldの関係
ガベージコレクション（GC）は、Javaプログラムにおいて不要となったメモリを自動的に解放する仕組みです。JVMはプログラムがメモリを適切に利用できるようにするため、定期的にメモリをスキャンし、使用されていないオブジェクトを検出して削除します。このプロセスによってプログラムは不要なメモリ管理に煩わされることなく実行できますが、その一方で、メモリ回収中に発生する「Stop-the-World」イベントがパフォーマンスに悪影響を及ぼすことがあります。
GCの動作とStop-the-World
Javaには、様々なGCアルゴリズムが存在します。これらは主にメモリの世代（Young世代、Old世代）ごとに異なる方式でメモリを管理します。GCは、オブジェクトのライフサイクルに基づいてこれらの世代を対象にしますが、そのプロセス中にStop-the-Worldが発生します。特にOld世代でのメモリ回収は大量のメモリを処理するため、Stop-the-Worldが長引く可能性があります。
GCとアプリケーションの一時停止
GCの一部のアルゴリズムでは、メモリを効率的に回収するためにすべてのアプリケーションスレッドを一時停止し、メモリ管理作業に集中します。この一時停止が「Stop-the-World」と呼ばれ、アプリケーションの応答性やスループットに影響を与える要因となります。プログラムの規模やメモリ使用量が大きいほど、Stop-the-Worldの影響は顕著になります。そのため、Stop-the-Worldの回数と時間を最小化することがパフォーマンス改善の鍵となります。
Stop-the-Worldが発生する原因
Stop-the-Worldイベントが発生する主な原因は、ガベージコレクションの実行中に、JVMがメモリの整合性を確保するためにすべてのアプリケーションスレッドを停止する必要があるためです。特に、Javaプログラムが大量のオブジェクトを作成し、メモリ使用量が増加すると、GCが頻繁に発生し、それに伴いStop-the-Worldも頻繁に起こります。以下は、Stop-the-Worldを引き起こす主要な要因です。
ヒープメモリの不足
アプリケーションがメモリを多く消費し、ヒープメモリが不足すると、JVMはガベージコレクションを実行して不要なオブジェクトを回収します。特に、Old世代（長期間メモリに留まるオブジェクトを格納する領域）が満杯になると、Stop-the-Worldイベントが発生し、ヒープ全体をスキャンするための大規模なGCが行われます。
GCアルゴリズムの特性
使用するGCアルゴリズムによっては、Stop-the-Worldが頻繁に発生することがあります。例えば、従来のSerial GCやParallel GCは、すべてのスレッドを停止してメモリを回収するため、Stop-the-Worldイベントが長くなりがちです。一方で、G1 GCやZGCなどの新しいアルゴリズムは、この影響を最小化する設計になっていますが、それでも一定の停止は避けられません。
大規模なオブジェクトの生成と解放
大量のオブジェクトや大規模なオブジェクトが頻繁に生成され、すぐに解放されると、GCはこれらを素早く処理する必要があります。これにより、Stop-the-Worldイベントが引き起こされる頻度が増加し、パフォーマンスに悪影響を与える可能性があります。
コンカレントGCの失敗
コンカレントGCは、アプリケーションの実行中に並行してメモリを回収しますが、タイミングが合わずにGC処理が完了しない場合、JVMは強制的にすべてのスレッドを停止してガベージコレクションを完了させます。この場合もStop-the-Worldイベントが発生し、予期しない停止が生じることがあります。
GCチューニングの基礎
Javaアプリケーションにおけるパフォーマンス最適化の重要なポイントの一つは、ガベージコレクション（GC）のチューニングです。適切にGCをチューニングすることで、Stop-the-Worldイベントを最小化し、アプリケーションのレスポンスやスループットを向上させることができます。GCチューニングは、アプリケーションの特性に応じたメモリ管理とGCアルゴリズムの最適化を行うことで実現されます。
ヒープメモリの最適化
ヒープメモリのサイズは、GCチューニングの基本です。適切なヒープサイズを設定することで、GCが頻繁に発生することを防ぎ、Stop-the-Worldイベントの発生回数を減らすことができます。ヒープメモリが小さすぎると、頻繁なGCが必要になりますが、大きすぎるとGCの実行時間が長くなり、Stop-the-Worldの時間も増加します。
Young世代とOld世代のバランス
Javaヒープは、Young世代とOld世代に分割されています。Young世代は短命なオブジェクトを処理し、Old世代は長期間生存するオブジェクトを管理します。Young世代が大きすぎるとGCが頻繁に発生し、Old世代が大きすぎるとGCの一回あたりの時間が長くなります。これらのバランスを取ることが、Stop-the-Worldを減少させるために重要です。
GCアルゴリズムの選択
JVMには複数のGCアルゴリズムが用意されています。各アルゴリズムは、メモリ使用やStop-the-Worldの影響を最小限に抑えるための異なる特性を持っています。アプリケーションの特性に合ったGCアルゴリズムを選択することで、最適なパフォーマンスを引き出すことが可能です。
Serial GC
単純かつコンパクトなGCで、小規模なアプリケーションに向いていますが、Stop-the-Worldイベントが発生しやすいため、大規模なアプリケーションには不向きです。
Parallel GC
複数のスレッドで並列にGCを実行し、大規模なヒープメモリを持つアプリケーションに適しています。Stop-the-Worldの時間は短縮されますが、完全に回避することはできません。
GCログの活用
GCの動作状況を詳細に記録したGCログを解析することにより、チューニングの効果を確認できます。GCログを分析することで、どのタイミングでStop-the-Worldが発生しているのか、GCの時間や頻度を把握することができ、最適化の方向性を見つける手助けとなります。
G1 GCによるStop-the-World最適化
G1ガベージコレクター（G1 GC）は、Java 7以降で導入されたガベージコレクションアルゴリズムで、特に大規模なヒープメモリを持つアプリケーションにおけるStop-the-Worldイベントを最小化するよう設計されています。G1 GCは、ヒープを小さな領域に分割し、効率的にメモリを回収するため、従来のGCよりも一時停止時間を短縮することが可能です。
G1 GCの仕組み
G1 GCは、ヒープ全体を一度にスキャンするのではなく、ヒープを小さなリージョン（区画）に分割して管理します。これにより、GCが必要なリージョンだけを効率的にスキャンしてメモリを回収し、全体のGC時間を短縮します。また、G1 GCは並行してGCを実行するため、アプリケーションの動作中にもGCが進行し、Stop-the-Worldイベントの頻度を減らすことができます。
並行処理によるStop-the-Worldの回避
G1 GCは、並行GCと呼ばれるプロセスを使用して、アプリケーションスレッドを完全に停止させずにGCを進行させることができます。これにより、GCがバックグラウンドで動作し、アプリケーションのレスポンスを向上させることが可能です。ただし、メモリが逼迫するとStop-the-Worldが発生するため、適切なチューニングが重要です。
G1 GCの利点
G1 GCの最大の利点は、Stop-the-Worldイベントの発生を抑えるために「予測可能な一時停止時間」を提供することです。G1 GCは、あらかじめ設定された目標停止時間を守るように設計されており、これによりアプリケーションのパフォーマンスを予測しやすくなります。たとえば、停止時間を200ミリ秒に設定すれば、GCは可能な限りその時間内でメモリを回収しようとします。
G1 GCのチューニング
G1 GCを効果的にチューニングするためには、停止時間の目標値（-XX:MaxGCPauseMillis）を設定することが重要です。このパラメータにより、Stop-the-Worldイベントの時間を制御し、アプリケーションのパフォーマンス要件に合わせて最適化が可能です。また、ヒープサイズや世代分割の調整もG1 GCの効果を最大化するために考慮すべき要素です。
適用シナリオ
G1 GCは、大規模なヒープメモリや高い応答性が求められるアプリケーションに適しています。従来のGCアルゴリズムに比べてStop-the-Worldイベントの時間が短縮され、並行処理によってアプリケーションの動作を阻害することが少ないため、リアルタイム性が重要なWebサーバーや大規模データ処理システムに効果的です。
ZGCとShenandoah GCによるGC最適化
ZGCとShenandoah GCは、Javaの最新世代のガベージコレクションアルゴリズムであり、どちらもStop-the-Worldイベントの最小化に特化しています。これらのGCは、非常に短い一時停止時間を実現し、大規模なヒープメモリでも高いパフォーマンスを維持できるように設計されています。それぞれのアルゴリズムは異なるアプローチでStop-the-Worldイベントを削減しますが、どちらもアプリケーションの応答性やスループットを向上させる点で共通しています。
ZGCの特徴
ZGC（Z Garbage Collector）は、Java 11で導入されたガベージコレクションアルゴリズムで、非常に大規模なヒープ（数テラバイト規模）でも数ミリ秒単位の一時停止時間を維持できるように設計されています。ZGCは、ほぼすべてのガベージコレクション作業を並行して行い、アプリケーションスレッドの停止を最小限に抑えます。
ZGCの仕組み
ZGCは、ヒープメモリを同時に処理する「コンカレントマーキング」と「コンカレントリロケーション」という技術を用いて、アプリケーションスレッドと並行してメモリを回収します。これにより、Stop-the-Worldのイベントがほぼなくなり、大規模なヒープメモリを持つアプリケーションでも高い応答性を維持できます。また、ZGCはメモリの圧縮も行うため、メモリリークの防止や効率的なメモリ使用が可能です。
ZGCの適用シナリオ
ZGCは、極めて低い一時停止時間が求められるリアルタイムアプリケーションや、大規模なデータ処理システムで効果を発揮します。特に、数百GBや数TB規模のヒープメモリを扱う場合に、Stop-the-Worldの影響を最小限に抑えるための有効な選択肢となります。
Shenandoah GCの特徴
Shenandoah GCは、Java 12で正式に導入されたガベージコレクタで、ZGCと同様に一時停止時間を極限まで短縮することを目標としています。Shenandoah GCの最大の特徴は、「リージョン型GC」を採用している点で、メモリ全体ではなく特定の領域だけを対象に並行してGCを行うことで、アプリケーションの停止時間を短縮します。
Shenandoah GCの仕組み
Shenandoah GCは、並行してメモリを回収する際に、メモリの「リージョン」単位で作業を行います。これにより、ヒープ全体をスキャンする必要がなく、より効率的なメモリ回収が可能です。また、Shenandoah GCは、メモリのデフラグメンテーションも並行して行うため、メモリの断片化を防ぎ、Stop-the-Worldを大幅に短縮します。
Shenandoah GCの適用シナリオ
Shenandoah GCは、ZGCと同様に低レイテンシーが求められるアプリケーションに適していますが、特に中規模から大規模のヒープメモリを扱う場合に有効です。また、リアルタイム性が重要なアプリケーションや、応答時間を短縮したいWebサービスでも利用されています。
ZGCとShenandoahの比較
ZGCとShenandoah GCはどちらもStop-the-Worldイベントを極限まで削減する目的で設計されていますが、ZGCは非常に大規模なヒープメモリに特化しており、Shenandoah GCは中規模から大規模のヒープでより広範な用途に対応しています。アプリケーションのメモリ要件やパフォーマンス目標に応じて、これらのGCを選択することが重要です。
GCログ解析と監視ツール
Stop-the-Worldイベントの影響を最小化し、Javaアプリケーションのパフォーマンスを最適化するためには、ガベージコレクション（GC）の動作を正確に理解することが不可欠です。GCログは、JVMが実行するGCの詳細を記録しており、GCの頻度や停止時間、各フェーズの実行時間などを確認することができます。これらのログを解析し、適切なツールを使って監視することで、Stop-the-Worldイベントの原因や頻度を把握し、最適化の方向性を見つけることが可能です。
GCログの取得方法
Javaでは、GCログを有効にすることで、JVMが実行するすべてのGC活動を詳細に記録できます。これには、JVMの起動時に以下のようなオプションを指定します。
-XX:+PrintGCDetails -Xloggc:/path/to/gc.logこれにより、GCが発生するたびに、その詳細がログファイルに出力され、ヒープの使用状況や一時停止時間、GCごとの詳細なタイミングが記録されます。
GCログの解析
GCログを解析することで、Stop-the-Worldイベントが発生したタイミングやその原因を特定できます。ログには、GCの種類（Minor GC、Full GCなど）、ヒープメモリの使用状況、GC実行にかかった時間が含まれています。たとえば、次のようなログエントリは、あるGCの開始と終了を示しています。
[GC (Allocation Failure) [PSYoungGen: 5120K->1024K(6144K)] 8192K->4096K(16384K), 0.0123456 secs]このログエントリから、Young世代のGCが発生し、Stop-the-Worldイベントが0.0123456秒続いたことがわかります。こうした情報をもとに、Stop-the-Worldイベントを引き起こしている要因を特定し、最適化するポイントを見つけることができます。
監視ツールの活用
GCログを手動で解析するのは手間がかかるため、専用の監視ツールを使用すると効率的です。以下のツールを使用することで、GCの動作を可視化し、リアルタイムでアプリケーションのパフォーマンスを監視できます。
VisualVM
VisualVMは、Javaのアプリケーションの実行中にヒープの状態やGCの動作をリアルタイムで監視できるツールです。GCの実行タイミングやヒープの利用状況をグラフィカルに表示し、どのGCがどれくらいの時間停止を引き起こしているのかを把握するのに役立ちます。
GCViewer
GCViewerは、GCログを読み込み、GCのパフォーマンスや一時停止時間を可視化するツールです。これを使用することで、GCの詳細なパフォーマンス指標を一目で確認でき、長時間のGCやStop-the-Worldイベントが頻発する箇所を特定できます。
Prometheus + Grafana
PrometheusとGrafanaを組み合わせることで、GCログやJVMのパフォーマンスをリアルタイムでモニタリングできます。これにより、長期間にわたってGCの傾向を監視し、Stop-the-Worldイベントの発生状況やメモリ使用率の変化を追跡することができます。アラート設定を行うことで、GCに問題が生じた場合に即座に対応することも可能です。
監視と最適化のサイクル
GCログや監視ツールを活用することで、アプリケーションのGCパフォーマンスを定量的に把握し、Stop-the-Worldイベントの発生状況を監視できます。このデータをもとにチューニングを行い、最適化した結果を再び監視することで、継続的なパフォーマンス向上が可能です。
適切なヒープサイズの設定
ヒープサイズの適切な設定は、Stop-the-Worldイベントの発生頻度やGCの効率に直接影響します。ヒープサイズの調整を適切に行うことで、GCの頻度を減らし、アプリケーションのパフォーマンスを向上させることができます。ヒープサイズが小さすぎると、頻繁にGCが発生し、Stop-the-Worldイベントが増加します。一方、大きすぎるヒープはGC時間が長くなり、Stop-the-Worldイベントが発生した際により大きな影響を及ぼす可能性があります。
ヒープサイズの基本
Javaのヒープは、Young世代とOld世代に分かれており、これらのサイズを適切にバランスさせることが重要です。Young世代では短命なオブジェクトが主に処理され、Old世代では長期間にわたり生存するオブジェクトが管理されます。ヒープ全体のサイズを調整し、各世代のサイズを適切に割り当てることで、GCの効率を最適化できます。
Young世代の最適化
Young世代が小さすぎると、新しいオブジェクトがすぐにOld世代に移され、Old世代のGC（通常、Full GC）が頻繁に発生します。Young世代が大きすぎると、Young世代のGCが長くなるため、適度なバランスが必要です。通常、ヒープ全体の20～40%程度をYoung世代に割り当てると良い結果が得られます。
Old世代の最適化
Old世代は、長期間生存するオブジェクトを保持するため、Young世代から移動されるオブジェクトが多く蓄積されます。Old世代が小さいと、メモリがすぐに不足し、Full GCが頻繁に発生してStop-the-Worldイベントが引き起こされます。逆に、Old世代が大きすぎるとFull GCの時間が長くなり、停止時間が延びます。Old世代のサイズは、アプリケーションの動作やオブジェクトの生存パターンに合わせて慎重に設定する必要があります。
ヒープサイズの設定方法
JVMのヒープサイズは、-Xmsと-Xmxオプションで設定できます。-Xmsはヒープの初期サイズ、-Xmxはヒープの最大サイズを指定します。以下の例では、ヒープの初期サイズを2GB、最大サイズを4GBに設定しています。
-Xms2g -Xmx4g初期サイズと最大サイズの間に大きな差があると、JVMがヒープサイズを動的に調整する際にオーバーヘッドが発生する可能性があるため、これらの値はできるだけ近い値に設定するのが一般的です。
メモリ使用量とGCの関係
ヒープサイズを適切に設定することで、メモリ不足による頻繁なGCを防ぎ、Stop-the-Worldイベントの発生を抑えることができます。アプリケーションが必要とするメモリ量に対して十分なヒープを確保することで、GCの効率が向上し、アプリケーションのスループットやレスポンスが改善します。また、GCアルゴリズムに応じてヒープサイズの最適な設定は異なるため、使用するGCに合わせたヒープチューニングが必要です。
ヒープサイズのモニタリング
ヒープサイズが適切に設定されているかを確認するために、監視ツールやGCログを利用してメモリの使用状況をモニタリングします。ヒープメモリの消費パターンやGCの頻度、実行時間を定期的にチェックし、必要に応じてヒープサイズやGCの設定を調整することが、Stop-the-Worldイベントを最小化するための重要なステップです。
実践的なGC最適化のステップ
Stop-the-Worldイベントを最小化するためのガベージコレクション（GC）最適化は、Javaアプリケーションのパフォーマンス向上において重要な課題です。ここでは、具体的な最適化手順を段階的に紹介し、GCを効率的に管理してアプリケーションの応答性を向上させる方法を解説します。
ステップ1: アプリケーションのメモリ使用パターンの把握
最初のステップは、アプリケーションがどのようにメモリを消費しているかを理解することです。これには、アプリケーションの負荷テストを実行し、メモリ消費量、オブジェクトのライフサイクル、メモリリークの有無などを分析します。Java Flight Recorder（JFR）やVisualVMなどのツールを使用して、アプリケーションのメモリ使用パターンを可視化することで、メモリ消費の傾向を把握できます。
メモリリークの確認
メモリリークがあると、ヒープが過剰に消費され、頻繁にGCが発生する可能性があります。ヒープダンプを取得し、オブジェクトのライフサイクルを監視することで、リークが発生している箇所を特定します。
ステップ2: ヒープサイズとGCアルゴリズムの選択
アプリケーションのメモリ使用パターンを把握したら、適切なヒープサイズを設定します。-Xms（初期ヒープサイズ）と-Xmx（最大ヒープサイズ）の値をアプリケーションのメモリ要件に基づいて決定します。さらに、アプリケーションの特性に合わせて適切なGCアルゴリズムを選択します。
GCアルゴリズムの選択基準
- Serial GC: 小規模アプリケーションに最適だが、Stop-the-Worldが発生しやすい。
- Parallel GC: スループット重視のアプリケーションに向いているが、長い停止時間が発生する場合がある。
- G1 GC: Stop-the-Worldイベントを最小化しつつ、大規模なヒープを効率的に管理できる。
- ZGCやShenandoah GC: 低レイテンシーが求められるリアルタイムアプリケーションに最適。
ステップ3: 停止時間の目標設定
G1 GCやZGCでは、停止時間の目標を設定することができます。例えば、-XX:MaxGCPauseMillis=200のように設定すると、GCの停止時間が200ミリ秒以内に抑えられるように最適化されます。アプリケーションの要件に応じて、適切な停止時間を設定し、GCがその時間内で完了するようにチューニングします。
ステップ4: GCログの監視と解析
GCのチューニングが進んだら、GCログを詳細に監視し、最適化が有効かどうか確認します。-XX:+PrintGCDetailsや-XloggcオプションでGCログを有効にし、Stop-the-Worldイベントの発生頻度、時間、GCの種類（Minor GC、Full GC）を確認します。GCログからのフィードバックを基に、さらにチューニングを進めます。
GCログ解析のポイント
- 頻繁に発生するGC: Young世代が小さすぎる可能性があるため、Young世代のサイズを増加させる。
- 長時間のFull GC: Old世代のヒープが大きすぎる、またはヒープサイズが不適切な可能性がある。
ステップ5: アプリケーションのプロファイリングとヒープ調整
最適化の最終段階として、アプリケーションのプロファイリングを行い、ヒープサイズやGCアルゴリズムの最終調整を行います。VisualVMやEclipse MATなどのツールを使用して、ヒープダンプの分析やGCパフォーマンスの詳細な確認を行います。メモリ使用量が予想以上に増加している場合は、コードのメモリ効率を改善することも考慮します。
ステップ6: 運用中のパフォーマンス監視
最適化が完了した後も、アプリケーションの運用中に継続的なパフォーマンス監視が必要です。PrometheusやGrafanaなどの監視ツールを使用して、ヒープ使用率やGCの停止時間をリアルタイムで監視し、異常が発生した場合には迅速に対処できる体制を整えます。
アラート設定
監視ツールでアラートを設定し、Stop-the-Worldイベントが規定時間を超えた場合やGCの頻度が異常に増加した場合に通知を受け取れるようにします。これにより、運用中のトラブルを迅速に検出し、アプリケーションの健全性を維持できます。
最適化後のパフォーマンス監視
GCの最適化が完了した後も、アプリケーションのパフォーマンスを継続的に監視することが重要です。適切な監視を行うことで、Stop-the-Worldイベントの再発や予期しないパフォーマンス低下を早期に検出し、迅速に対応できるようになります。パフォーマンス監視ツールを使用することで、GCの挙動やヒープ使用率、レスポンス時間などをリアルタイムで確認し、最適化の成果が維持されているかを評価します。
リアルタイム監視ツールの活用
PrometheusやGrafana、VisualVMなどのツールは、GCパフォーマンスやメモリ使用量を継続的に監視するために有効です。これらのツールを活用し、Stop-the-Worldイベントの発生頻度やGCの遅延時間をリアルタイムで把握することが可能です。特に大規模なシステムでは、メモリ使用パターンが時間とともに変動するため、長期間にわたる監視が必要です。
メモリ使用のトレンド分析
運用中にメモリ使用量のトレンドを監視し、ヒープメモリの消費パターンに変化があれば、必要に応じてヒープサイズやGC設定を再調整します。GCの頻度や停止時間が増加していれば、アプリケーションのコードやメモリ管理方法に再度見直しが必要です。
アラートとパフォーマンスのフィードバック
監視ツールでアラートを設定し、特定の閾値を超えた場合に通知を受けるようにしておくと、Stop-the-Worldイベントの発生やGCの遅延が発生した際にすぐに対応できます。これにより、予期しないパフォーマンスの問題を迅速に解決し、システムの安定性を確保できます。
長期的なGCパフォーマンスの監視
長期的にGCの動作を監視することで、メモリ使用のパターンやGCの効果を定量的に評価し、必要に応じて最適化を再度行うことができます。システムのアップデートや新しいワークロードに対応する際にも、GCチューニングが適切に機能しているか確認することが重要です。
まとめ
本記事では、JavaのStop-the-Worldイベントを最小化するためのGC最適化技術について解説しました。Stop-the-Worldイベントの原因やGCアルゴリズムの選択、ヒープサイズの最適化、GCログ解析と監視ツールの活用など、実践的な最適化ステップを紹介しました。適切なチューニングと監視を行うことで、アプリケーションのパフォーマンスを維持し、GCによる一時停止時間を大幅に削減できます。GCの最適化は、継続的な監視と調整が鍵であり、安定したパフォーマンスを提供するためには欠かせない要素です。
コメント