3. 構成の基本¶

3.1. 端末には負荷を避けるために必要な量のキャッシュを貯められるように構成する¶

Windows が起動する際に必要とする読み込み量は、せいぜい 1～2 GB 程度です。 Office アプリケーションが起動する際に必要とする読み込み量は、アプリケーション 1 種類あたり 200 MB 程度です。このことから、OS を起動させ、各種のアプリケーションをつかって通常の利用方法を取る限りは、キャッシュのサイズは 20～30 GB 程度あれば足ります（端末の C ドライブのサイズやアプリケーションの種類数には、よほど特殊なケースを除けば影響を受けません）。

なお、端末側でウィルス対策ソフトによるフルスキャンや、ディスクのデフラグメントのような処理が実行されることがないように設定してください。これらの処理が実行されてしまうと、(本来キャッシュする必要がないはずの) ほとんど使われることのないデータまでがキャッシュされてしまい、端末のキャッシュ容量を無駄に消費してしまうことになります。そのため、運用中の端末においては、上記のような処理が実行されることがないように設定してください。

3.2. 端末の内蔵ドライブのサイズは必要最小限として、コストを下げる¶

同時並行的に使うディスクの種類数を検討し、端末内に何種類のキャッシュを貯めるかを検討します。そこから、端末内蔵ディスクに確保すべきキャッシュ容量を決定します。

3.3. キャッシュがまったくない状態は想定しない¶

「CO-Colors いか」のキャッシュは、端末を再起動しても残り続けます。ディスクを更新しても、キャッシュの大半は残ります（ディスクが更新された部分のキャッシュが消去されます）。

そのため、端末側には常にそれなりにキャッシュがあるものと想定して設計します。

メモ

キャッシュがまったくない状態になるのは、「全く新しいディスクを初めて使うとき」であり、これは導入後の初回起動時と、ディスクを新規に作成したときですので、めったにないケースとなります。

キャッシュが全くない状態で端末起動をしても、なんとか我慢できる程度の速度で起動します。

3.4. 通常運用時にボトルネックがないようにネットワークを構成する¶

「教室の端末を一斉起動する」「教室の端末で一斉に特定のアプリケーションを起動する」といった運用を想定する場合には、「各端末がサーバーから 200 MB の転送をする」ものとしつつ、その転送に許容される時間を加味しつつネットワークを設計します。

メモ

サーバーやネットワークの負荷で注意を要するのは、リクエストが短時間に集中するケースです。「ディスク更新直後に多数の端末を一斉起動する際」と「新規アプリケーション導入直後に、多数の端末でそのアプリケーションを一斉起動する際」には、端末側にはキャッシュがないため、各端末が同時にサーバーから読み込むことになります。経験的にこのいずれのトラフィックは端末 1 台あたり 100～200 MB です。

3.5. サーバーのディスクに負荷がかからないようにする¶

サーバーのディスクをどれほど高性能なものにしたとしても、多数の端末からのリクエストに順次応えられるような性能にはなりえません（端末 100 台からのディスクアクセスに期待通りに応えるには、端末のディスク性能の 100 倍の性能が必要になってしまいます）。そのため、サーバーのメモリをキャッシュとして活用することで、サーバーのディスクへのアクセスを抑えることが必須です。すなわち、端末が読み込み要求をするデータの総量に相当するメモリをサーバーが備えることが理想です。

端末側でキャッシュにミスヒットするのは、ディスクを更新した直後等ですが、そのデータ量は経験的に各端末で 2 GB 程度です。この 2 GB のリクエストはどの端末からでも同じ内容となるため、サーバーは 「2 GB×ディスクの種類数」の要求に応えられる ようなメモリーを備えるようにしてください。

3.6. サーバーのディスクが不足しないようにする¶

サーバーのディスク容量が不足すると、「どのディスクを消すのか、どれを保持するのか」等を検討するのに相当なコストがかかります。また、ディスク容量不足が理由で運用に制限がかかってしまうようでは問題と考えます。

そのため、サーバーのディスク容量はできるだけ潤沢に確保してください。一方、サーバーのディスクに対するアクセスはほとんど発生しないように設計することで、ディスクの性能はほとんど必要としません。例えば、「3.5" ドライブを選択して容量を確保しつつ、コストを抑える」「S-ATA、7200rpm といったドライブを選択することでコストを抑える」ことは大いに推奨されます。

また、ネットブートのサーバーが複数設置される場合には、それらのサーバー上に保持するディスクは同じ内容のバックアップとなります。そのため、ディスクの冗長性（RAID）を過度に要求する必要はありません。また、ディスクイメージを保持する領域については、バックアップを必須とする必要はありません。

3.7. できるだけ過去のディスクを保持し続けるようにする¶

ディスク配信のような古いツールを長く使っていらっしゃるお客様は「過去のものを残しても仕方ないので、3～5 世代ぐらいでいい」と考えられるケースもありますが、過去の更新履歴が多く残っていると次のような点で役に立ちます。

なにか問題が起きていることに気づいたときに、過去の履歴が残っていれば、どのような更新を行ったときに問題が生じたのかを簡単に判断できる。
「最近なんか動作が遅い」と感じたときに、いつでもすぐに過去の状態に戻して比較検討できる。
どのバージョンを消してもよいかを検討するのは、ただ単純に面倒、かつ、心理的負担が大きい。

そのため、ディスク容量には余裕を持った構成にしてください。