ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Notes/Domino >

LDD Today

Domino 6: サーバー・ヘルス・モニタリングを使う

by Carol Zimmet
レベル：すべて
対象：Domino R5、Domino 6
原文の掲載：2002年6月4日

LDD Today の原文（US）

インデックス

	Dominoサーバー・ヘルス・モニタリングとは？
	サーバー・ヘルス・モニタリングを開始する
	モニタリングの実行
	サーバー分析に基づく調査
	覚えておきたいキーポイント
	終わりに
	要望

Lotusphere 2002のOpening General Sessionで、Lotus General ManagerのAl Zollar氏は、サーバー・ヘルス・モニタリング（Server Health Monitoring）の重要性をアナウンスした。彼は、Tivoliの新製品であるServer Helath Management and Plannning Toolset（Server Health Monitoringを含む）はDominoの管理者の作業方法を根本から変更するであろうと語っている。このツールは、サーバーの可用性を高め、既存のリソースをより有効に活用し、Dominoサーバーのレスポンスを改善する。また、TCO（Total Cost of Ownership）を削減する効果もある。

このツールを一度使用すると、その利点を実感できるだろう。幸いなことに、サーバー・ヘルス・モニタリングは、Domino 6を待たなくても、R5環境に導入して使い始めることができる。そして、Domino 6環境へ移行する頃には、すでにこのツールに慣れ、サーバーはこのモニタリング「ネットワーク」にすぐにフィットするだろう。

この記事では、R5またはDomino 6環境でサーバー・ヘルス・モニタリング機能の利点を活用する方法を解説する。この記事は、初心者およびベテランのDomino管理者向けで、Dominoネットワーク管理の基本的な経験があることを想定して書かれている。

Dominoサーバー・ヘルス・モニタリングとは？

簡潔に言うと、Dominoサーバー・ヘルス・モニタリングは、サーバーを監視・分析し、綿密な注意を必要とする兆候が現れたときにそれを通知するツールである。よく使われる格言の「転ばぬ先の杖」という意味合いに近い。このツールは一度だけ診断するのではなく、モニタリングは常に行われる（24 x 7体制）。管理者はつきっきりにならなくてもよく、他の作業をしている間に、モニタリングと分析が並行して行われる。また、通常のチェックでも、レビューする時間がないときでも、管理者は計測が一定の監視下に置かれていることを確信できる。

サーバー・ヘルス・モニタリング機能は優先順位が高く、開発チームの一番の目標なので、Domino 6サーバーのサポートに加え、Domino R5サーバーもサポートされる。われわれの目標はカスタマーの設定をサポートし、各リリースごとにベストな結果を届けることである。

上に戻る

サーバー・ヘルス・モニタリングを開始する

現在の製品環境には、システム管理クライアントがあるはずである。このシステムには、Notes 6クライアントのプレリリース1以降が必要となる。サーバー・ヘルス・モニタリングを有効にするにはシステム管理クライアントソフトウェアだけが必要で、これはNotes 6の「すべてのクライアント」のインストールに含まれる。Notes 6のプレリリース2は、Lotus Developer Domainからダウンロードできる。必要でないものも理解する必要がある。

	モニタリングプロセスに参加するために、サーバー設定の変更は必要ない。これは、Dominoサーバーのアップグレードまたは変更がまったく必要ないことを意味する。
	他のTivoliソフトウェア製品をロードする必要はない。サーバー・ヘルス・モニタリング機能はシステム管理クライアントと統合され、製品がプレリリースの段階では、デフォルトで有効になっている。また、サーバー・ヘルス・モニタリングと他のTivoli製品を同じ環境で実行することができる。

設定での考慮事項
システム管理クライアントをダウンロードした後は、設定オプションに注意する必要がある。サーバー・ヘルス・モニタリングを設定し、起動するには次の作業を行う。

	「Domino 6システム管理ヘルプ」のサーバー・ヘルス・モニタリングのセクションを読む。このドキュメントには、ツールの設定方法や使い方についての詳細な情報が含まれ、この記事での説明よりも多くの内容を得られる。「目次」ページの「サーバーパフォーマンス」?「Tivoli Advanced Monitoring Tool」または索引の「サーバー・ヘルス・モニタリング」を参照してほしい。（なお、この機能は名前の変更が予想されるので、それに応じて参照先も変わる。）
	モニタリングプロセスにおける管理者の役割の一部として、サーバーへのリモートコンソールアクセスが必要になる。この情報はDominoディレクトリのサーバー設定文書で指定されている。この情報はすでに設定され、使用するサーバーに対して有効になっていなければならない。サーバーモニタリングと同様に、サーバー・ヘルス・モニタリングを使用してサーバーをモニターするために、管理者にはサーバーへのアクセス権が必要となる。
	プラットフォーム統計（Platform Statistics）はサーバー・ヘルス・モニタリングの分析プロセスでキーとなるコンポーネントである。これは、CPU、メモリー、ディスクの使用状況に関する情報を提供する。プラットフォーム統計では、すべてのオプションを利用可能に設定することを特にお勧めする。（プラットフォーム統計は、Windows NTおよびSun SolarisではDomino R5.0.2以降、iSeries OS400ではDomino R 5.03以降が必要となる。Domino 6では、すべてのプラットフォームでプラットフォーム統計がサポートされる。）この推奨によって、ディスク分析をサポートするために、Windows NTプラットフォームでの設定の必要性が減少した。ディスクカウンタのモニタリングを有効にするには、Windows NTオペレーティングシステムの一部として出荷されているdiskperfというツールを起動しなければならない。収集用の他の計測はデフォルトで有効になっている。
	この記事では詳しくは触れないが、他の計測のセットも、有効にしておくとサーバー・ヘルス・モニタリングで使用できる。これらはQOS（Quality of Service）統計として知られている。これらの統計は、特定のサーバータスクのレスポンスタイプの計測に使用される。この統計セットの設定方法については、「Domino R5システム管理ヘルプ」を参照してほしい。サーバーのNOTES.INIファイルにあるDomino Server Taskパラメータも、モニタリングタスク用に"runjava ispy"を含むように変更する。

次に、Domino 6システム管理クライアントを使用して、以下の手順でサーバー・ヘルス・モニタリングを設定する。

1.	「ファイル」?「プリファレンス」?「システム管理」を選択し、「システム管理プリファレンス」ダイアログボックスで「モニタリング」タブをクリックし、「Generate server health statistics and reports」チェックボックスを選択する。これで、統計の収集、分析、推奨事項の生成が有効になる。このオプションはデフォルトでは選択されていないので、サーバー・ヘルス・モニタリングを使用するときは必ず選択しなければならない。
2.	.「Historical Charting」を有効にするために、「Statistics」タブをクリックし、「Generate statistic reports while monitoring or charting statistics」チェックボックスを選択する。サーバーの状態を時系列的に分析するために、このオプションの選択が必要となる。情報はクライアントのMonitoring Resultsデータベース（statrep*.nsf）にローカルに保存される。このオプションはデフォルトでは選択されない。
3.	「OK」をクリックして設定を完了する

サーバー・ヘルス・モニタリングを開始するには、Domino 6システム管理クライアントで、「サーバー」タブ、「モニタリング」タブの順にクリックし、右上にある「開始」ボタンをクリックする。これによって、サーバーモニタリングとサーバー・ヘルス・モニタリングが開始される。

Start button

「開始」ボタンをクリックすると、ボタンは「停止」に変わる。このボタンをクリックすると、モニタリングが停止する。

モニターするサーバーを選択する

サーバー・ヘルス・モニタリングは、R5の管理者にとってすでにおなじみのサーバーモニタリングインタフェースに統合されている。R5のサーバーモニタリングと同様に、サーバー・ヘルス・モニタリングを最初に起動したときに、サーバー設定文書に基づいて、モニターするサーバーがDominoディレクトリで検索される。（製品開発チームの環境には、R3から6までに至るまで、これまでにリリースされたサーバーが混在しているが、読者の環境に合わせるために、ここではDomino R5サーバーに的を絞ることにする。）

モニターしたいサーバーを選択できるのだろうか。もちろん、答えはイエス。システム管理クライアントの新機能を使用すると、モニターしたいサーバーのリストを保存済みの統計グループプロフィールに保存できる。既存のプロフィールを変更して新規のプロフィールを作成し（モニターしたいサーバーのリストが得られるまで、サーバーの削除と追加を繰り返す）、プロフィールを別の名前で保存する。たとえば、下図の例では「R5Servers」という名前が付けられている。

Saved statics group

最後に選択していたプロフィールが、次回にサーバーモニタリングを起動するときのデフォルトのプロフィールとして使用される。これらのグループプロフィールの指定は、必要性や条件（地域別、機能別、標準時別など）に基づいてサーバーのグループをモニタリングするのに役に立つ。最終結果として1つまたは複数のサーバーをセットしてグループ化し、実用的で、管理しやすく、スケーラビリティの高い管理手法が得られる。

上に戻る

モニタリングの実行

サーバーモニタリング画面の右上の「開始」ボタンをクリックすると、サーバーモニタリングとサーバー・ヘルス・モニタリングのプロセスが開始し、管理者の手が離れる。しばらくすると、生成された情報が画面上に表示される。

	R5サーバーモニタリングの情報が画面の中央に表示される。
	サーバー・ヘルス・モニタリング用の新しい列が左側に表示される。列のラベルは「Hea」でHealthを意味する。
	「Hea」列にはサーバーの健康状態を示す温度計のアイコンがある。緑色は、すべてが正常に動作していることを示す。黄色の場合は、「コンポーネントはストレスを受けているが、問題には至っていない。しかし、監視が必要である」ことを示している。赤色の温度計が現れたときは、サーバーの1つまたは複数の主要なコンポーネントに注意が必要であることを示す。この場合、コンポーネントが効率よく機能していないか、まったく機能していないことを示す。

この時点で、かなりの量の情報が蓄えられている。サーバー・ヘルス・モニタリングは詳細なタスク情報を収集する。この情報はサーバー・ヘルス・モニタリングの分析プロセスに送られ、温度計のアイコンに反映される。

サーバー・ヘルス・モニタリングは、プラットフォーム統計を介して提供された情報も取り入れる（プラットフォーム統計は、Windows NT、Sun Solaris、iSeries OS400プラットフォーム上のR5、およびすべてのプラットフォーム上のDomino 6でサポートされる）。R5でサポートされるプラットフォーム統計のコンポーネントには、CPU、メモリー、ディスクの分析が含まれる。Domino 6ではこれよりも多くのコンポーネントがサポートされる。このため、サーバー・ヘルス・モニタリングの内容はDominoのリリースに応じて調整されている。サーバー・ヘルス・モニタリングはこれらの計測値を分析し、正常、ストレス、問題の3つの範囲に分類する。そして、観察結果は総合的な値としてまとめられ、温度計として報告される。

サーバーパフォーマンスの主な計測値は簡単には得られないが、これも取り出されて検討される。ドミノの主な統計も、メールルーティング、サーバーの応答、バッファなどの機能面でチェックされる。観察された動作（効率よく実行されているか、あるいは実行にストレスがあるか）のどちらに値が当てはまるかによって、決定が行われる。

実際に何が行われているのか、ここで振り返ってみよう。

	サーバー・ヘルス・モニタリングはどの計測項目を選択し、評価するのかを認識している。また、このツールは、Dominoがサポートするプラットフォームにおいて、これらの値の有効な範囲も理解している。この点に取り組んだすべての記事、Redbook、プレゼンテーションを考慮するとわかるように、関連するほとんどの知識はサーバー・ヘルス・モニタリングのナレッジベースに組み込まれている。いわば、管理者の代わりに運用しているのであり、管理者はエキスパートになる必要はない。
	サーバー・ヘルス・モニタリングは、複数のモニタリング間隔にわたって分析を行う。これは、サーバー・ヘルス・モニタリングが、異なるコンポーネント領域（プラットフォーム統計セット、サーバーモニタリングセット、およびDominoセット）を一定の間隔（通常は1分）でチェックしていることを意味する。どのような評価を行う場合でも、複数のモニタリング間隔をレビューする。これは、コンピュータが最も得意とする分野である。サーバー・ヘルス・モニタリングは、スパイク条件（1回だけの計測値）については判断せず、複数の間隔にわたって持続または繰り返すパターンを観測して、評価を下す。
	サーバー・ヘルス・モニタリングタスクを実行し、情報のレポートを得るのに、管理者は「開始」ボタンの選択以外のことはしていない。

上に戻る

サーバー分析に基づく調査

前の図を見ると、Franklin、Houston、およびTrafficの各サーバーに赤い温度計が表示されている。「ヘルスレポート」を調べることによって、これらのサーバーでどのようなトラブルが発生しているのかを探ってみよう。

サーバーモニタリングの画面で右クリックし、「Display Healyh Report」を選択する。

Health Report view

「Current Health Reports」ビューにDominoサーバーのリストが再び表示されるが、今度は深刻度でソートされている。一番上が赤色のサーバーで最もクリティカルな状態、次が黄色で注意が必要な状態、そして一番下が緑色で健康な状態の順になる。このビューでも、多くの情報がコンパクトなフォーマットで表示されている。もう少し詳しく見ていこう。

The server list details

いくつかのサーバーで右側に赤いアイコンが示されている。これは管理者への直接のメッセージで、設定されていないモニタリングコンポーネントがある（したがって、設定すれば分析が可能になる）ことを意味する。また、かなり右側にある「Comment」列には、黄色や赤の警告状態に対し、最初に考えられる原因が示される。複数のコンポーネントが問題となることがあるので、問題を示しているコンポーネントを判断し、これをコメントセクションに表示する。

この例では、コメントを見ると、複数のサーバーでメモリーが問題になっていることがわかる。たぶん、システムリソースがアップグレードの時期にきているか、サーバーのロードバランシングを再構成する必要がある。レポートを何回も見ていると、特定のサーバーで頻繁にトラブルが発生することに気づくことがある。このようなサーバーの「個性」を把握したり、繰り返し発生する問題を識別することは、サーバー・ヘルス・モニタリングの大きな特長である。管理者は、ホットなサーバーとそうでないサーバーを知ったり、問題を起こしたサーバーを突き止めることができる。

さらなる情報
管理者として注目するサーバーがわかっているとき、より詳細な情報はどのように入手するのだろうか。サーバー名の左横にある小さな三角形のアイコンをクリックすると、詳細な情報が表示される。

Expanded server health report

Domino 6では、10種類のコンポーネントがモニターされる。R5では、利用できない情報もあるので、このコンポーネント数は少なくなる。また、表示されているコンポーネントは、リストに含まれるものだけであることを理解しておくとよい。上記の例では、サンプルのどのサーバーでもHTTPコンポーネントがロードされていないので、HTTPコンポーネントはリストに存在しない。また、Mail Delivery Latencyがコンポーネントとしてリストに入っているが、これはメールルータがロードされていることを意味する。

上の情報をよく見ると、Aristaサーバーのメールルーティング動作とFranklinサーバーのメモリーの使用度を詳しく知りたくなる。どちらのコンポーネントもクリティカルな状態として示されているからだ。サーバーAliceは、Memory Utilizationだけに黄色の温度計が表示されている。このため、よりクリティカルなアイテムの後で処理すればよい。

コンポーネントの色が変わることがある点に注目したい。これは状況が進展したことを意味する。1つの計測値が他の値に影響を与えることがあるので、これは何が起こっているかを示す材料の一つになる。
問題を特定し、ソリューションを見つける。

分析にはいくつかのレベルがあり、レベルごとに別の「世界」が開ける。そこには、ソリューションに向けての推奨事項が含まれている。

サーバー・ヘルス・モニタリングは、システムの特性と仕様に基づいて、問題に対する推奨事項を生成する。サーバー用の「Overall Health Report」には、多くの情報がまとめられている。それぞれの情報には、十分な考察が加えられたさまざまな分析が用いられている。サーバーの「Overall Health Report」を見るには、「Current Report」ビューに表示されているサーバーをダブルクリックする。

さまざまなセクションを見ると、"one-stop shopping"（窓口の一元化）方式になっていることに気づく。つまり、必要で関連性の高い情報が提供されている。これが、推奨事項の作成に使用される情報で、アクションの次の方針を決める際にも使用される。

このレポートでは、次の点に注目したい。

	「Configuration Issue」セクションには、前に進むのに必要なアクションのリストが表示されている。この例だと、「Logical Disk Performance Counters」を有効にすることである。このアクションを実行すると、サーバー・ヘルス・モニタリングが他のシステムコンポーネントをモニターできるようになる。このケースでは、ディスクアクティビティをモニターしていないことが問題の原因である。特に、トラフィックの量や、共有および配布する情報量が増えている場合に、このモニタリングは重要になる。
	上位レベルのレポートでは、このサーバーが実行に必要な十分なメモリーを確保するのが難しいことが報告されている。その詳細はこのレポートにあり、サーバーに割り当てられたメモリーの合計容量と、実際に使用可能であったメモリーの容量が示される。
	前の推奨事項ではメモリー不足の環境についての説明があり、このシステムの利用可能なメモリーがその範囲内（7.6MBのメモリーが利用可能）であることが示された。この数値は、持続された状態を表していることに注意が必要だ。これは、1回だけの計測ではなく、複数のモニタリング間隔で計測された結果である。
	推奨された戦略には、短期的なものと長期的なものがある。推奨事項には特別な優先順位はない。一般的に、各推奨事項ごとに特定の条件がチェックされ、分析の順番に表示される。いくつかの推奨事項は、環境や設定に大きな影響を与えることがあり、また、それぞれの使用プロフィールとデザインは一意である。これらの条件が一致したとき（または、一致しないとき）、推奨事項が表示される。前にも説明したように、それぞれの推奨事項が生成される前に、固有の設定や仕様について考慮される。
	短期的な推奨事項も、環境に合わせて調整される。このサーバーのメモリーが少ないと報告されたとき、次の質問は「どれだけの量に調整すればよいか」であろう。この情報もここで提供され、設定をどれぐらい調整するか、または増加させるかの目安が示される。
	長期的な推奨事項には、より多くのプロセスが含まれる傾向がある。すべては実行可能で、その方法も記載されている。情報を分析する時間のスケジュールを決め、推奨の実行方法を決めるとよいだろう。

この時点で振り返ってみよう。短時間のうちに、最小限の努力でかなりのレベルまで進んだ。自分自身でモニタリングしなくても、最適な結果を得られることがわかった。また、より注意が必要な点についても、正確に報告される。これにより、Domino Performance Team が推奨するテクニックに基づいて、問題となる状況へのアプローチ方法が得られるであろう。

人々はサーバー・ヘルス・モニタリングを実際の作業でどのように使用するのだろうか。他のDomino管理者から寄せられたシナリオを考えてみた。彼女はシステム管理コンソールの席に座っているので、いつでもサーバーモニタリングの画面を見ることができる。このため、問題が発生したときは、すぐに対応できる。また、彼女は毎朝サーバーモニタリングの画面をチェックする。これによって、今日一日、起こりそうなことや、注意が必要なことをあらかじめ予測しておくことができる。

上に戻る

覚えておきたいキーポイント

以下に示すキーポイントは、開発および他のIBMチーム内でのDomino Performance Team独自の導入シナリオと、パブリックフォーラム（Lotusphere、DevCon、Admin 2001、Tivoliに関するイベント）から受け取った質問やフィードバックに基づいて得られた結果である。

	サーバー・ヘルス・モニタリングはすべてのプラットフォームでR5サーバーをモニターする。モニタリングプロセスは、主要な計測値を分析し、必要に応じて推奨事項を生成する。リリースされているプラットフォームでプラットフォーム統計がサポートされていない場合でも、サーバー・ヘルス・モニタリングはDomino統計を収集・分析し、処理を行う。これらの情報からも、役に立つ貴重な情報が得られる。
	サーバー・ヘルス・モニタリングはサーバー上のシステムリソースに影響しないサーバー・ヘルス・モニタリングは、Domino 6システム管理クライアントから起動され、分析を行う。このため、サーバーのパフォーマンスには影響を与えない。
	Dominoサーバーには新しいソフトウェアはロードされない R5環境でも、サーバー・ヘルス・モニタリングを有効にするのに、Domino 6システム管理クライアントだけが必要。サーバー上では、新しいソフトウェアはロードされず、有効にしなければならない新しいコンポーネントもない。
	サーバー・ヘルス・モニタリングはTivoli製のコンポーネントや製品には依存しないサーバー・ヘルス・モニタリングはDomino 6システム管理クライアントに統合されていて、Tivoli製のコンポーネントをまったく必要としない（Tivoli Frameworkも含む）。他のTivoliソフトウェアがユーザーの環境にインストールされていても、使用されることはない。サーバー・ヘルス・モニタリングは個々のDominoサーバーだけに注目するのに対し、Tivoliソフトウェアは全体の環境を対象とし、複数のサーバーを包括する。
	サーバーモニタリングとサーバー・ヘルス・モニタリングはグループ内のDominoサーバーだけをモニターする企業の規模が非常に大きいときは、企業全体の環境をモニターする必要はない。管理者が1つのシステム管理クライアントを使用してモニタリングに成功するのは50?75台のサーバーまでという数字が得られている。これに基づいて、モニターするサーバーのグループを構成するとよいだろう。ユーザーインタフェースの観点からは、管理者が1つのシステム管理クライアントを使用して見ることができるのは、サーバーモニタリングの1?3画面までという結果となった。
	サーバー・ヘルス・モニタリングによって、クリティカルなシステム分析に対する管理者のプレッシャーが軽減されるサーバーのモニタリングと分析以外の作業へ注力したい管理者にとって、サーバー・ヘルス・モニタリングは大きな救いとなるであろう。オペレーティングシステムのさまざまな統計（CPU、メモリー、ディスクI/Oを含む）やDomino 6でのネットワーク統計の詳細を理解しなければならないプレッシャーが軽減される。また、Domino統計とオプションは定期的にレビューされ、サーバー・ヘルス・モニタリングのインタフェースを介して、値がどのように設定されているのかが示される。管理者は、分析作業が確実に行われていることを確信できる。
	サーバー・ヘルス・モニタリングによって、管理者はモニターすべき注意点を把握できる詳細な「Current Reports」ビューをはじめとするサーバー・ヘルス・モニタリングのインタフェースによって、モニターすべきキーポイント、考慮が必要な有効範囲、現在の値などを知ることができる。サーバー・ヘルス・モニタリングは、必要な作業をガイドするチュートリアルであるかのように機能する。
	この記事で説明したほとんどを(すべてではない）Domino 6に適用できる今からR5環境でサーバー・ヘルス・モニタリングを使い始めることは、将来への投資となるだろう。Domino 6にアップグレードしたときに、リリースに組み込まれる統計とコンポーネントが増えるので、インタフェースがその分だけ多彩になるのを実感できる。
	サーバー・ヘルス・モニタリングは、Tivoliから提供されるIBM Tivoli Analyzer for Lotus Domino と呼ばれる新機能の一部であるこの機能のセットはDomino 6システム管理クライアントに統合され、ベータおよびプレリリースプログラムを介して利用できる。公式なリリースが発表された後は、サーバー・ヘルス・モニタリングのユーザーインタフェースコンポーネントを有効にするために、Tivoli製のCDを購入する必要がある。

上に戻る

終わりに

最後に、ここで説明したビジョンやソリューションがユーザーの環境で活かされることを希望する。サーバー・ヘルス・モニタリングはすぐにでも試すことができ、そのメリットを享受できることはすばらしいニュースだと思う。また、この記事で紹介しきれかったことも数多くある。サーバー・ヘルス・モニタリングは、「Real-Time Charting」や「Historical Charting」などの分析とともに使用すると、その効果が高まるであろう。しかし、その点については、別の機会で説明することにしよう。

上に戻る

要望

ここで、読者の方にお願いがある。私たちは、Dominoサーバー・ヘルス・モニタリングのナレッジマネジメント（分析や推奨事項など）をできるだけ正確に、そして完全なものにしたいと思っている。このツールを使用し、このツールで検出できない問題に遭遇したときは、ぜひそれを知らせてほしい。同様に、成功したケースや使い方の別のシナリオがあるときは、それも知らせてほしい。なお、ご連絡の際は、サーバーの最新の健康状態が保存されているdommon.nsfのコピーと、統計情報が含まれているシステム管理クライアントのstatrep.nsfのコピーを添えていただけると役に立つ。なお、システム管理クライアントのNOTES.INIファイルでREDZONE_SAVE_AFTER_EVAL=1を設定すると、効果的な追加分析情報がdommon.nsfに保存されるようになる。送り先はczimmet@notesdev.ibm.comで、メールの件名に「I'm a Sever Health Monitor user」とご記入ください。

謝辞
ユーザーアシスタントのスペシャリストLynda Urgotisに対し特別に謝意を表したい。この記事も含め、彼女の奉仕、サポート、熱意によって執筆プロジェクトが成り立っている。彼女が参加したプロジェクトは、すべて成功している。

上に戻る