運動中の水分補給について…からの~…システムチューニングの話

運動中の水分補給について…からの~…システムチューニングの話

運動で健康な体を作ろうとしている人は多いと思います。運動中の水分補給は非常に重要ですが、誤った給水方法では効果がありません。同様にコンピュータシステムの性能を健全に保つための効果的なシステムチューニングの方法があります。

野球少年だった私

私はかつて少年野球をやっていました。当時は、「巨人の星」などの根性物のスポーツアニメが世の中を席巻していました(何年前のことでしょうか? 笑)。

そこで練習といえば、根性、根性、・・・もひとつ根性・・・の世界。

特に練習中は「水分を取るとバテる」という理由で、水は一切飲ませてもらえませんでした。今となっては科学的根拠の全く無いものでしたが。特に夏休みは朝から晩まで練習。飲水ができるのは昼食時のみ。あとは練習後に近所の人達が差し入れてくれるジュースがたまにある程度でした。

それでも練習中、どうしても水が飲みたくなった時は、走塁時にヘッドスライディングをして、「顔洗ってきまーす!」といって顔を洗うふりをしてこっそり水を飲んだりしていました。今考えれば、こんな理不尽な環境でよく生きていたものだと不思議に思ったのですが、当時はこれが「常識」だったんです。

最近の運動中における水分補給事情

今では運動中の給水事情も全く変わってしまいました。以前の「常識」は「非常識」となってしまうほどです。

人間の体の約60%は水分で構成されており、体重の約1%の水分が失われると喉が渇くなどの不快感を覚え、約4~5%失うと発熱や吐き気、頭痛などの体調不良を感じるようになるそうです※。そのため厚生労働省では、熱中症の予防も含め、積極的に水分を取るよう働きかけています。

これを当時の少年野球の監督が聞いたらどんな反応を示していたでしょうか?でもこれが今の「常識」なんです。おそらく昔はそれを「根性」で我慢していたんでしょうね。現在の私は野球ではなく少年サッカーのコーチをしています。日本サッカー協会のコーチライセンスと日本体育協会の指導員の資格を保有しています。資格取得時に受講したメディカルの講義において、講師のドクターから怪我の応急処置方法などに加え、水分補給についてのレクチャーも受けました。指導要項や試合開催要領では水分補給の重要性が説かれ、実際の試合においては飲水のための時間を確保するよう周知されています。

ところで運動時に効果的な水分を補給するタイミングは喉が渇く前だそうです。喉が渇いたと感じた時点では遅いそうです。運動中であれば、20分に1回。1回の摂取量はコップ1杯(約200cc)で、それ以上飲んでも体には吸収されず、尿として出てしまうそうです。その時、体内のミネラル等も一緒に排出されてしまうので、水分の取りすぎは逆に体に良くないそうです。

ちなみにそのドクターが推奨していた飲料は、ポ○リス○ットです。但しそのままだと糖分が多すぎるので、2倍に薄めて塩を一つまみ入れるのが良いとのことでした。また、運動していない状態での水分補給は、水で十分だということです。

※ 参考※
厚生労働省「健康のため水を飲もう」推進運動
厚生労働省「ポスター『のどが渇いた』『先生、水を飲ませてください』」

システムチューニングの勘所も時代とともに・・・

話は突然飛躍しますが、コンピュータシステムの性能を健全に保つのも、喉が渇く前の水分補給と同様、事前の対処が重要です。性能劣化が起こる要因としては、ユーザアクセス数の変化などによる「外部要因」と長年使用されていたことによるストレージのフラグメント発生などの「内部要因」に分類できます。

これらの変化を定常的に監視しておき、パフォーマンスの低下が発生した時に慌てないよう、平常時と異なる数値や現象が見られた(閾値を超えた)場合はどう対処するのかを予め決めておきます。そのためには運用監視ツールが大活躍する訳ですが、ベンダー製品ではWebSAMやSystemwalker、JP1などがよく使われています。最近ではOSSのNagiosやHinemos、ZABBIXが人気ありますね。

監視の結果、外部要因による性能劣化と判断される場合、単純に処理能力が不足しているので、サーバのパワーアップが必要です。CPUのクロックアップやコア追加、ストレージのキャパシティ増強などパーツをより高性能なものにリプレースする方式をスケールアップといいます。

この方式だと既存のソフトウェアのリソースはそのままで運用できるというメリットがあります。ただし、ホットスワップ対応機器以外では基本的にパーツ交換のためにサーバの電源断が伴いますので機器停止中は代替機での運用などサービスを止めない工夫が必要となります。

また、分散環境に対応したシステムであればスケールアウトという方式でサーバの増強ができます。これは、既存のサーバと同等のスペックのマシンを並列に結合して「サーバ群」または「クラスタ」としてトータルで処理性能の向上を図るというものです。この方式は、既存サーバの停止を伴わなくてもハードウェアの増強ができるというメリットがあります。しかしサーバ台数が増えることによる管理工数の増大やソフトウェアライセンスの増額という運用コストが増えるというデメリットがあります。

内部要因の場合は話が多少複雑になりますが、ハウスキーピングやデータ領域の再構成などのストレージ周りのメンテナンスやアプリケーションロジックの変更など、システムの内部処理に関する対応が必要です。

また、喉が渇いたからといって一度に何リットルの水を飲んでも効果は無いのと同様、システムのパフォーマンスが出ないといってむやみにCPUやメモリなどのパーツ追加や交換を行っても効果は期待通りには表れません。日頃のシステム状態の監視によりどの部分に異常が発生しているかなど注意を払い、適材適所の対処が必要です。いずれにしても、問題が発生する想定での事前準備がトラブル解決の早道になります。

最近のシステムチューニングにおけるトレンド

さらにシステムチューニングの「常識」もテクノロジーの進化に伴い変わってきています。チューニングの最終的なゴールは、システムのパフォーマンスを最大にすることです。先ほど述べたスケールアウトも、最近注目されるようになったシステムのパフォーマンスを最大にするための方式です。

また、性能を考慮したデータベースのストレージ設計を例に取ると、以前はデータ自体を格納する領域とインデクスを格納する領域を分けて負荷分散を図っていましたが、最近はRAIDコントローラやハードディスクの性能が向上したため、データとインデクスは同じ領域へ収めて運用する方式(S.A.M.E:Stripe And Mirror Everything)がメジャーになってきています。これに加えて、ハードディスクのような機械的な操作の必要のないSSDをストレージに採用し、更に高速なデータアクセスを実現するシステムも登場しています。

さいごに

時代と共に「常識」は変化していくものです。この先も常識は変化していくでしょう。でもその変化に対応できることが「進化」だと思います。

記事は、予告なく変更または削除される場合があります。
記載された情報は、執筆・公開された時点のものであり、予告なく変更されている場合があります。
また、社名、製品名、サービス名などは、各社の商標または登録商標の場合があります。

この記事を読んだ人がよく読む記事