「あなたのパソコンの時刻は合っていますか」。こう聞かれると、「NTP（Network Time Protocol）を使っているから大丈夫」と答える人が多いだろう。筆者もそう思っていた。だが、取材すると、時刻合わせの世界は想像以上に奥が深いことに驚いた。筆者が知らなかった話題を、いくつか紹介しよう。
そもそも正しい時刻って？
時刻を合わせる場合、その相手は当然正しい時間にしたいと思うだろう。だが、そもそも“正しい”時刻というのは存在しない。
NTPで配布しているのは、協定世界時（UTC）と呼ばれるもの。日本では情報通信研究機構（NICT）が決めた「UTC（NICT）」というものを使っている。実はこのUTC、各国ごとに独自の原子時計を持って決めている。このため、世界共通の時間というのは存在しないのだ。細かく比べると、国ごとに数～数十ナノ秒程度の誤差がある。
世界で共通に使う本当のUTCは、実はフランスにある国際度量衡局（BIPM）が決めている。だが、この本当のUTCは、世界各国に何百個とある原子時計それぞれで計測した結果を集めたうえで、安定した時計は高く、安定していない時計は低くといったように加重平均して決めている。こうした処理が必要なため、最終的な結果が出るまでに数週間の時間がかかる。つまり、後から「あのときの本当のUTCはこれ」ということが分かるだけで、その時点で本当のUTCは分からないのだ。
それぞれの国は、BIPMが決めたUTCと自分が決めたUTCを比較して、誤差が小さくなるように調整する。ちなみに、日本のUTCは「ほぼ±20ナノ秒の範囲でBIPMが決めているUTCと同期している」という。つまり、NICTがNTPを介して日本で配布しているUTCがそもそも10ナノ秒前後ずれている可能性が高いのだ。
マイクロ秒単位で時刻を合わせる技術も
とはいえ、ナノ秒単位の誤差は、NTPで時刻合わせする場合において大した問題ではない。インターネットを経由してTCP／IPを使いパケットをやり取りするため、NTPでの時刻合わせにはどうしてもミリ秒単位の誤差が生じてしまうからだ。ミリ秒が当たり前の世界で、6ケタも小さなナノ秒の誤差はほぼ無視していい存在だ。企業の情報システムではほとんど問題とならないNTPの誤差だが、最近になってより高精度を求めるニーズが増えている。
例えば、携帯電話の基地局がそうだ。最近のLTEや今後登場する5Gの通信ではTD-LTEという方式が広く使われる見込みだ。このTD-LTEの特徴は、これまでのFDD-LTEのように上りと下りで利用する周波数帯を分けるのではなく、同じ周波数帯で時間を区切って上りと下りに併用することだ。このため、隣接する基地局とタイミングをそろえて上りと下りを切り替えないと、電波の干渉などが発生して通信がうまくいかない可能性がある。ITU-Tは、UTCとの時刻誤差を1.5マイクロ秒以下と規定している。
こうした高精度の同期を実現するため、従来はGPS衛星などからの電波を活用して時刻同期することが多かった。だが、5Gでは屋内やマンホール型など、より狭いエリアをスポット的にカバーする基地局を増やす予定だ。こうした基地局すべてで衛星からの電波を受信させるのは現実的ではなく、通信回線を使って時刻を同期したいというニーズがあるのだ。
こうした高精度の時刻同期を、NTPに代わって実現するプロトコルとして注目されているのが「PTP（Precision Time Protocol）」だ。PTPの最大の特徴は、物理層のハードウエアレベルで時刻合わせの機能を実装すること。基本的にソフトウエアで実現するNTPは、TCP／IPのプロトコルスタックでの処理を含め遅延が発生しやすい。
これに対してPTP対応機器はタイムスタンプユニットという部品を搭載し、時刻情報を送受信する際にハードウエアでパケットにタイムスタンプを記録する。処理による遅延を最小限に抑え、さらに利用をLANなど遅延の少ないネットワーク環境に限定することでマイクロ秒以下の誤差という高精度を実現している。
テレビ放送ではデジタル化に伴い、時報や放送開始時の時計表示がなくなった。その一方で、番組制作において、より正確な時刻合わせが必要になっている。このため、高精度な時刻合わせのニーズは、素材をネット経由で送ることが増えてきた放送局でも必須となりつつある。これから高速ネットが普及するにつれ、精度の高い時刻合わせのニーズはさらに高まるだろう。
悪質サイト
URLやメールアドレスに使われるドメイン名の最後に付く文字列であるトップレベルドメイン。「tech.nikkeibp.co.jp」なら「.jp」が該当する。セキュリティ組織のThe Spamhaus Projectによると、.menや.clickといったトップレベルドメインを持つWebサイトの6割以上が危険な悪質サイトであるという。
急増するトップレベルドメイン
従来、トップレベルドメインには主に2種類あった。gTLD（Generic Top Level Domain）とccTLD（Country Code Top Level Domain）である。gTLDは、利用する企業や団体の形態や用途に合わせて利用できるTLD。2000年11月までは、.com、.net、.org、.edu、.gov、.mil、.intの7種類しかなかった。
2000年より前から存在するgTLD
（出所：日本ネットワークインフォメーションセンター）ccTLDは、国や地域ごとに付与されるTLD。日本なら.jp、中国なら.cn、英国なら.ukといった具合だ。200種類以上のccTLDが存在する。
ccTLDの例
（出所：日本ネットワークインフォメーションセンター）
そして2010年11月以降、第3のTLDが登場する。新gTLDである。新gTLDの最大の特徴は、企業や団体が任意のTLDを申請し取得できること。会社名や製品、サービス名、地域名（地方自治体名）をトップレベルドメインとしてWebサイトのURLやメールアドレスに利用できる。
この新gTLDの登場により、トップレベルドメインの数は爆発的に増え、現在では1500以上が登録されている。.menや.work、.loanといった見慣れないトップレベルドメインの多くは新gTLDだ。
悪質の度合いを算出
多数存在するトップレベルドメイン。それらのうち、悪質な使い方をされているのが特に多いドメインを、複数のセキュリティベンダーやセキュリティ組織がランク付けして公表している。ここでの悪質な使い方とは、ウイルスを配布するWebサイトやスパム（迷惑メール）の送信サーバーなどに使うことを指す。複数存在するランク付けの中で、信頼性が高いと思われるものの一つが、The Spamhaus Projectが公表するものである。The Spamhaus Projectは、スイスと英国に拠点を持つ非営利組織。1998年の設立以降、スパムの送信元やウイルスの配布元などに関する情報（ブラックリスト）を、ISP（インターネットサービスプロバイダー）や企業・組織に提供している。
The Spamhaus Projectが公開するランキングは、同組織が独自に算出した悪質指標（Badness Index）で順位付けされている。使われている全ドメインに対する悪質ドメインの割合に、悪質ドメインの数の対数を乗じている。これにより、悪質ドメインの割合が同じでも、悪質ドメインの数が多いトップレベルドメインのほうが、より悪質と判断される。
悪質指標（Badness Index）の計算式
（出所：The Spamhaus Project）The Spamhaus Projectによるランキングは毎日更新される。2018年6月上旬は、男性を表す新gTLDの.menが首位の座を守っていたが、6月中旬以降は.gqがトップに躍り出た。.gqは赤道ギニアのccTLDである。
悪質指標（Badness Index）ワースト10（2018年6月19日時点）
（出所：The Spamhaus Project）.cfは中央アフリカ、.gaはガボン、.mlはマリ、.tkはトケラウのccTLDである。.topはトップ、.workは仕事（ワーク）、.loanはローン、.clickはクリックを表す新gTLDだ。
「悪い」のは「安い」から
一見、共通点がないように思えるこれらのワースト10。実は、ある点で共通している。これらのトップレベルドメインは、無料あるいは低料金で利用できるのだ。
悪質ドメインは、悪行が発覚するとブラックリストに登録されて使えなくなる。このため攻撃者は、ドメインを多数用意して使い捨てる。その場合、攻撃者を困らせるのが、ドメイン名の登録や維持にかかる費用だ。通常は、レジストラと呼ばれるドメイン登録事業者に料金を払って、ドメイン名の登録と管理を依頼する。
そこで攻撃者は、無料あるいは低料金で使えるトップレベルドメインに目を付けた。.gq、.cf、.ga、.ml、.tkの5種類のトップレベルドメインは、Freenomというレジストラが無料で登録を受け付けている。
FreenomのWebサイト。日本語でも情報を提供している
（出所：Freenom）同社では、無料サービスと併せて有料サービスも提供している。無料サービスには制限を設けて、有料サービスに移行させることを狙っている。
例えば、無料サービスではドメイン名を所有できない。Freenomから貸してもらうという立場だ。また、無料サービスは有料サービスよりも利用規定が厳しく、規定に違反するとすぐに利用できなくなる。ドメイン名を所有したい、あるいは利用規定を緩くしてほしいという場合には、有料のサービスに移行する必要がある。ただ、最初からドメイン名を使い捨てるつもりの攻撃者にとっては、無料のサービスで十分だ。
新gTLDの.men、.top、.work、.loan、.clickが使われるのも同じ理由だと考えられる。The Spamhaus Projectの情報によると、攻撃者に悪用されることを承知のうえで、これらのトップレベルドメインを安価で大量に提供しているレジストラが存在するという。例えば、著名なセキュリティ研究者Brian Krebs氏は、.menや.loanといった新gTLDを年額66セントで提供しているレジストラがあるとする。
見慣れないトップレベルドメインには、変なものが潜んでいる可能性が高い。リンクなどをクリックしているうちに.gqや.cf、.men、.clickなどのWebサイトに誘導されたら、すぐに立ち去ったほうがよい。
「見慣れないトップレベルドメインには、変なものが潜んでいる可能性が高い。リンクなどをクリックしているうちに.gqや.cf、.men、.clickなどのWebサイトに誘導されたら、すぐに立ち去ったほうがよい。」を実行する。
関連：
・海賊版サイトをブロッキングするための5つの手法（その仕組みと限界および問題点） - INTERNET Watch
ロック画面ではCortanaをオフに
・WindowsのAIアシスタント「Cortana」を使って誰でもPCのロックを解除できてしまう - GIGAZINE
ロック画面ではCortanaをオフにするべきだ。
OSの役割
LinuxやWindowsに代表されるOS（Operating System）は、ハードウエアを利用したり、管理したりするためのソフトウエアです。各種のミドルウエアやアプリケーションといったOS以外のソフトウエアは、OSを介してコンピュータを利用します。つまり、OSの役割をひと言でいうと、ハードウエアなどのコンピュータリソースへのインタフェースを提供し、それらを管理することです。
OSが他のソフトウエアに提供するインタフェースを、API（Application Program Interface）といいます。REST APIのようなWebサービスのインタフェースを指すAPIと同じ用語です。どちらも、何らかのサービスをアプリケーションが利用するためのインタフェースだからです。
OSが管理するリソースは、CPU、メモリー、ストレージ、ネットワークカードなどのハードウエアです。また、OSがソフトウエアで実装しているユーザー、アクセス権、ファイルシステム、排他制御なども、OSが管理します。
ハードウエアの違いを吸収しAPIを提供OSは、CPUやネットワークカードなどのハードウエアの違いを吸収します。また、アプリケーションや人間にとって使いやすいインタフェースであるAPIを提供します。例えば、システム要件に応じて異なるスペックのハードウエアを導入してもシステムが動作するのは、OSがハードウエアの違いを吸収し、同一のAPIをシステムに提供しているからです。
また、ストレージ装置に格納されたデータを、人間が使いやすいファイル形式で扱えるのは、OSのAPIの働きによるものです。ストレージ装置では、磁気ディスク上ではデータは512バイト単位のブロックの羅列です。OSは、このブロック単位のデータを、ファイル名のついたファイルとして、任意の大きさのデータを読み書きできるようにしています。
OSのAPIは、プログラム作成とコンピュータの利用を容易にするだけでなく、それに従って作成されたアプリケーションの可搬性、移植性を保証します。特にエンタープライズシステムで広く使われているOSのAPIはこの点を明確に意識しているといえます。国際規格、業界規格、ベンダー公開仕様などにより、既存の仕様との互換性を長期間にわたって維持しています。
主なAPI仕様の例を表に示します。UnixやLinuxのAPIであるPOSIXは1988年の登場から既に30年が経っています。Windowsの標準APIであるWin32も1993年に登場し、現在に至るまで互換性を提供し続けています。
表●API仕様の例
APIに互換性があれば、異なるOS向けのプログラムを再コンパイルにより動作させることができます。そこで、ハードウエアやOSの保守期限切れなどにともなってサーバーを更新しなければならないような場合でも、大きな変更をすることなく、システムを延命できる可能性があります。旧システムのOSと移行先OSのAPIの互換性が高ければ高いほど、アプリケーションのプログラムの修正箇所を少なくでき、移行の難易度が低くなります。
もちろん、実際の移行検討では、OSだけでなくミドルウエアやパッケージの互換性の問題もあります。その場合、OSのAPIが完全互換だとしても、移行が容易とは限りません。
リソースを効率的に使う
OSのもう一つの大きな役割は、コンピュータのリソースを管理して、プログラムがリソースを効率的かつ安全に使えるようにすることです。
リソースが効率的に利用できていないと、データの読み書きがボトルネックになってCPUの停止している時間が長くなり、システムの処理に時間がかかってしまったりします。
リソースを効率的に利用するために、OSはさまざまな機能を備えています。例えば、入出力したデータをメモリーに保持して再利用するこキャッシュ機能、複数のI/Oを一度にまとめて行うバッファなどのソフトウエア技法を用います。これらにより、CPUの無駄な待ち時間を減らして処理を高速化できます。
こうした機能を活用する際には、プログラムがメモリーを使うつもりがなくても、OSがメモリーを消費することがあります。性能やデータ量の要件が厳しい場合、OSのリソース割当てやバッファに関するデフォルト設定を変更する必要があります。
リソースの安全な利用とは、リソースの使いすぎによるシステムの予期しない動作を防ぎ、アクセス権のないリソースにアクセスさせず、同時アクセスによるデータ破壊を防ぐことです。
OS: 構成要素ごとに機能を押さえる
OSは、WindowsやLinuxの標準インストール後のディスク使用量がギガバイト単位であることからも分かるように、巨大なソフトウエアです。したがって、OSを理解するためには、OSを構成要素に分けて見る必要があります。また、OSの構成を知ることは、パッチ適用判断などの実務にも役立ちます。パッチの対象がOSのどの部分で、その部分の役割が何かが分かれば、OSだからすべてのソフトウエアが影響を受けるという以上のきめの細かい影響調査を行えるようになります。
何がOSを構成するかは、OSにより異なります。エンドユーザーにとっては、OSのインストールメディアに入っている、あるいはOSのインストーラーがインストールするソフトウエアは、すべてOSでしょう。逆の極端な例を挙げると、Linuxの開発コミュニティはOSの中核部分であるカーネルだけを開発しています。しかし、カーネルだけではコンピュータを起動して人間が操作することもできないので、カーネルだけがOSだという人はいません。
確実にOSに入るのは、カーネル、標準ライブラリ、およびシェルです。
OSの構成要素カーネルは、名前通りOSの核となる部分です。カーネルはメモリーに常駐し、ハードウエアの操作およびOS専用のデータをアクセス可能なCPUの特権状態で実行します。そのため、カーネルをアップデートするには、システムの再起動が必要になります。
カーネルには、多様な機能を含んたモノリシック（一枚岩の意味）カーネルと、CPUの特権状態を要する必要最小限の機能だけからなるマイクロカーネルがあります。モノリシックカーネルは性能、マイクロカーネルは保守性に優れるので、この両者は、現在は歩み寄っています。例えば、Linuxはモノリシックカーネルですが、モジュールごとに必要に応じてメモリーにロードするようになりました。逆に、WindowsはWindows NTのマイクロカーネルから出発して、現在はカーネルの機能が大きくなっています。
カーネルのうち、ハードウエアを直接操作する部分はデバイスドライバといいます。デバイスドライバは、サードパーティーが提供することが多いため、カーネルとは別の要素として扱うOSが多いです。
標準ライブラリは、APIの実装です。プログラムは、標準ライブラリを呼び出すことにより、APIを実行します。標準ライブラリは、メモリー、ファイルなどのOSが管理するリソースを使用する場合、カーネルを呼び出します。
カーネルの作りの違いは、標準ライブラリの構成にも現れます。例えば、Linuxでは全面的にカーネルで実装されているプロセスやスレッドは、Windowsではライブラリとカーネルで実装されています。LinuxのglibcやWindowsのkernel64(32).dllのようにすべてのプログラムに使用されるライブラリはメモリーに常駐しています。更新にはシステムの再起動が必要ですが、そうでないライブラリはファイルを置き換えるだけで更新できます。
IEはOSか？
シェルは、プログラムの起動・停止、ファイルの作成・削除などを対話的に実行します。シェルは、また、ジョブのような一連の操作を自動的に実行するために、条件分岐やループなどのプログラム言語の機能を備えます。一般利用者、開発者、システム管理者の幅広い用途に応えるため、および以前のOSとの互換性のために、複数のシェルを提供するOSもあります。
GUIによる操作を基本とするシステムでは、シェルもGUIになります。これは、デスクトップ環境でおなじみの機能で、ファイルの一覧表示、ファイルの種別に応じたアプリケーションの起動、メニューからのアプリケーションや管理ツールの起動を行います。
かつてWebブラウザーのInternet Explorer（IE）がOSの一部かどうかという論争がありました。IEをGUIシェルと捉えればOSの一部となりますが、主機能をWebブラウザーと捉えると、OSの管理外のインターネット上にあるリソースにアクセスするプログラムなので、OSではないのではないかという反論が出てきたわけです。
また、OSには、基本的な運用・管理ツールを含めることが多いです。商用システムの運用で使用する運用・管理システムと異なり、そのOSが実行するコンピュータのリソースだけを対象として、OSの起動・終了、基本的なファイル操作、リソース統計取得などの機能を提供します。
ソ－ス：OSは巨大なソフトウエア、構成要素ごとに機能を押さえる - 新人SEのためのOS基礎：日経 xTECH Active
OS: 優先順位と負荷分散を管理
コンピュータ上では、複数のアプリケーションを同時に動作させることができます。これは、OS（Operating System）が備える「スケジューリング」機能が実現しています。スケジューリングは、CPUリソースの管理と割り当てをつかさどるカーネルの機能です。CPUリソースの割り当ての統計情報であるCPU使用率は、システム性能を示す代表的な指標の1つです。
スケジューリングは、OS上で動作するプログラムに、CPUコアを割り当てます。スケジューリング機能を担うOSのモジュールを「スケジューラー」と呼びます。CPUコアの割り当てがスケジューラーによってどのように動作するのかを詳しく見てみましょう。
プログラムが動作するとき、カーネルはプログラムをストレージから読み込んでメモリー上に配置します。こうしてコンピュータが実行可能な状態にしたものを「プロセス」と呼びます。そして、プロセスの中で実行する命令の流れを「スレッド」と呼びます。以下では、CPUのスレッドとの混同を防ぐために、プロセスとスレッドを合わせて「タスク」と表現します。
OSのスケジューリング機能は、CPUのどのコアでタスクを動かすかを判断します。また、CPUのコア数を上回るタスクが動作しようとするときは、どのタスクを優先的に実行するかを判断してコアに割り当てます。これらの判断は、タスクに指定された優先度、各タスクのCPU割り当て実績、各コアで割り当てを待つタスクの数などに基づきます。
優先順位と負荷分散を管理
タスクに指定された優先度は、複数のタスクが一つのコアを奪い合うとき、どのタスクを先に実行するか決めるのに用いられます。異常事態の検知など、遅れが問題となる処理は優先度を高く設定します。一方、バックグラウンドで実行するメンテナンス処理などは、優先度を低く設定します。CPU割り当て実績により、スケジューラーは、タスクにCPU時間を公平に割り当てます。スケジューラーはまた、複数コア間の負荷を分散し、実行するタスクがないコアを省電力モードに移行させます。
省電力モードはコスト削減に効果のある機能ですが、レスポンス性能に厳しい要求のあるシステムでは注意が必要です。特にレベルの高い省電力モードになったCPUは、実行状態に復帰するのに時間がかかります。そのため、例えばパケットの受信に対する反応が遅くなります。
安定動作の余力があるか判断
管理対象のシステムでCPUリソースの過不足を見るには、CPU使用率を見ます。CPU使用率の統計情報を作成するのは、CPUリソースの管理・配分を行うスケジューラーなので、ここで説明したスケジューリングの知識と合わせて、CPU使用率の見方を解説します。
稼働中のシステムのCPU使用率を確認することで、CPUにシステムが安定して動作するのに十分な余力があるかどうかが分かります。CPU使用率が100％に近ければ、CPUに余力がないのでなんらかの増強が必要であると判断できます。逆に、CPU使用率が常に0％に近い値を示している場合は、能力過剰な状態となっている可能性があります。
マルチスレッドに対応していない、あるいはスレッド数に上限のあるプログラムを動作させている場合、これだけでは不十分です。カーネルがマルチコアを扱えても、明示的に並列に起動されていないシングルスレッドのプログラムを複数のコアで並列に実行することはできません。
例えば、8コアのハードウエアでシングルスレッドのシステムが動作中で、ほかのどのプログラムもCPUを大量に使わないことが分かっているケースを考えてみましょう。この場合、CPU使用率が12.5％でも、このシステムが使っている一つのコアでCPU使用率が100％近く、残りはOSなどの処理である可能性があります。このシステムは、シングルスレッドなので他のコアを使うことができません。
したがって、これでシステムの処理時間が長い、あるいは反応が遅い場合、複数のシステムを同時に動作させるか、より速いCPUに変更する必要があります。
CPU使用率の内訳として、カーネルを実行していた時間とプログラムおよびライブラリを実行していた時間の割合も、該当するパフォーマンスカウンターを監視することによって、知ることができます。
CPU使用率のパフォーマンスカウンター
プログラムやライブラリの比率が高い場合はプログラム、カーネルの比率が高い場合はカーネルも含めた調査が可能な解析ツールを用いて、ボトルネック箇所を特定するといった使い方をします。
ソ－ス：複数のアプリを円滑に動かせるのはOSのおかげ、優先順位と負荷分散を管理 - 新人SEのためのOS基礎：日経 xTECH Active
OS: メモリー管理機能の仕組み
コンピュータの動作にCPUと並んで不可欠なのがメモリーです。プログラムを実行するには、プログラムがメモリー上にロードされている必要があります。また、計算対象のデータ、入出力するデータもメモリーに置かれます。
メモリー上のどの領域に、いつ、どのデータを載せるのかによって、プログラムの処理の効率が変わります。これを制御するのが、OSが持つメモリー管理の機能です。メモリー管理は、タスク起動時のプログラムのロード、実行中のプログラムによる動的なメモリー確保だけでなく、ファイルやネットワークなどのキャッシュ、バッファの管理でも使用されます。
コンピュータのメモリーには、位置を特定するアドレスがついています。このアドレスをそのまま使うと、複数のプログラムが同じアドレスを使ってしまわないように、どのプログラムがどのアドレスを使うか事前に決めなければならなくなります。しかしカーネルのメモリー管理機能があるので、その必要はありません。カーネルは物理的なアドレスと仮想的なアドレスの対応付けを管理することで、すべてのプログラムが他のプログラムを意識しないでメモリーを使えるようにします。
カーネルは、メモリーの用途別にアクセス保護を設定することで、バグや悪意による不正なメモリーアクセスからプログラムやシステム全体を保護します。不正なメモリーアクセスがあると、カーネルはそのことを示すメッセージやイベントを発生させ、プログラムを強制的に終了させます。
ライブラリや命令が格納されたメモリーは読み取り専用で、書き込みを試みると例外になります。また、カーネルのメモリーは、カーネルのコードを実行しているとき以外は、プログラムから読み書きできないように設定します。
ストレージI/Oは、メモリーアクセスに比べると非常に遅い操作です。そこでカーネルは、メモリーをストレージのキャッシュとして使用します。一度読み込んだストレージの内容をメモリーに保持することにより、再度同じ箇所を読み込む場合、メモリーの内容をプログラムに返す、あるいは書き込み内容をメモリー中に保持します。そして適切なタイミング、あるいはプログラムから指示されたタイミングで書き込むことにより、全体的なI/O性能を向上させます。
OSのメモリー管理機能によるキャッシュへの書き込みと読み込み
キャッシュは、プログラムが読み書きするファイルだけでなく、ライブラリを含むプログラムの命令部分にも使われます。
使用中のキャッシュを回収
メモリーをプログラムの命令とデータ、およびファイルI/Oのキャッシュとして際限なく使い続けると、いつかは空きメモリーがなくなります。そこで、OSは、空きメモリーを監視し、一定の基準に基づき、使用されていたメモリーを回収し、空きメモリーにします。メモリーとストレージの内容が同じキャッシュは、直ちに空きメモリーにしても、後に再度ストレージI/Oを行う必要があるにしても、システムの正常な状態を損ないません。
また、更新されたキャッシュは、ストレージに更新内容を書き戻せば、回収できます。これに対し、プログラム中のデータ領域やヒープ領域（動的に割り当てたデータ領域）は、対応するストレージの内容がありません。このようなメモリーを回収する必要がある場合、OSは、スワップ領域あるいはスワップファイルにメモリーの内容を書き出して、対応するメモリーを回収します。
メモリー監視ツールが報告する空きメモリーを見るとき、どのメモリーを空きメモリーと報告するかに注意が必要です。一般に空きメモリーとして表示されるのは何にも使われていないメモリーであり、回収可能なキャッシュは含まないことが多いからです。使用中のメモリーには回収可能なキャッシュが含まれるので、空きメモリーが少ないからといって、システムが危機的な状況にあるとは言えません。
空きメモリーが少ないのを問題視し、強制的にキャッシュを回収させたり、キャッシュのサイズを制限すると、不必要なストレージI/Oでシステム全体の性能を低くださせるリスクもあります。メモリーの使われ方はさまざまであり、監視方法についても一つの正解を示すことはできません。ただしよく使われる指針としては、継続的なスワップの発生を深刻な問題の兆候として監視します。
OS: ファイルシステム
組み込みシステムでないコンピュータには、CPUとメモリーのほかに、プログラムやデータを格納するストレージがあります。OS上で動作するプログラムは、ストレージ上のデータにファイルシステムを通じてアクセスします。例外は、一部のDBMSやファイルシステムを作成・修復するツールだけです。
プログラムは、カーネルの他の機能と同様、APIによってファイルシステムにアクセスします。カーネルは、これらの操作とストレージ上のデータを対応付けます。加えて、入出力されるデータをキャッシュするためのメモリー管理、アクセス権管理のためのユーザー管理などのセキュリティ機能、ストレージI/Oのためのデバイスドライバとそれぞれ連携します。ファイルシステムがさまざまなストレージに対応できるように、ファイルシステムとデバイスドライバの間には、標準化されたストレージデバイスドライバのインタフェースが存在します。
OS上で動作するプログラムはファイルシステムを通じてストレージを利用する
ファイルシステムのAPIは、ファイルの作成、ファイルのオープン・クローズ、ファイルの読み書き、ディレクトリの一覧取得、ファイルの属性情報取得・設定などの操作を提供します。
読み書きするファイルの内容は、メモリー管理で紹介したように、カーネルがメモリーにキャッシュとして保持します。また、先頭から順番にファイルを読み込むのは、非常によくあるファイルアクセスの方法なので、ファイルシステムは、このような順次アクセスを検知したとき、ファイルを先読みしてキャッシュに置きます。データベースの表領域のようなランダムアクセスの場合、先読みはムダになるので行いません。
LinuxやWindowsのファイルシステムは、書き込みの性能を重視して、デフォルトで書き込みにキャッシュを使います。書き込みのAPIが成功して完了しても、書き込んだデータはメモリー中のキャッシュにあるだけで、ストレージへの書き込みは完了していないことを意味します。このようなデータは、一定のタイミングでストレージに書き込まれます。API正常終了時に、ストレージへのデータ書き込みを保証したい場合、書き込みを保証するモードでファイルをオープンするか、キャッシュの書き戻しを指示するAPIを明示的に発行する必要があります。
書き込みサイズがI/O性能に影響
ストレージは一定のブロックサイズ単位でしか読み書きできませんが、ファイルシステムのAPIは1バイトなど任意の大きさのデータをファイルに読み書きできます。これは、プログラムの作成のしやすさの面ではよいのですが、I/O性能の面では注意を要します。
ファイルシステムがストレージに対して行うI/Oは、ストレージのI/Oの最低単位であるブロックサイズと、メモリー管理の単位であるページサイズの両方に都合のよいサイズで行います。PCやIAサーバーが採用するインテル系のCPUでは4096バイト単位です。したがって、例えば、1バイトだけの書き込みを行うと、このバイトを含む4096バイトのデータを読み込み、1バイトを更新し、更新された1バイトを含む4096バイトを書き込む必要があります。
このように非効率なストレージI/Oを行わないために、高レベルのファイルシステムAPIは、特に指定がない限り、ライブラリやプログラム中に確保したバッファを使って、4096バイトの倍数単位でファイルの読み書きを行います。
ストレージI/Oの統計情報から分かる入出力されたデータ量やI/O要求の回数を見るとき、カーネルによる先読みとキャッシュ、ライブラリによるバッファの影響を考慮する必要があります。プログラムが行ったファイル入出力の量や回数と、ディスクに対して行ったI/Oは、多くの場合一致しません。直近にアクセスされたファイルならキャッシュ、書き込みの場合バッファによりI/O回数が少なくなることがあります。
順次アクセスの場合、先読みで一時的にI/Oが多く見えることがあります。また、ファイルの新規作成時は、ストレージ上のデータ配置情報などファイルシステム自体が使うデータも更新する必要があるので、同一のファイルを上書きするときより多くのI/Oが行われます。
ソ－ス：プログラムやデータを読み書きする仕組み、OSのファイルシステム - 新人SEのためのOS基礎：日経 xTECH Active
OS: CPU能力を使い切る
仮想化とクラウドコンピューティングの普及により、物理マシンより仮想マシンを扱うことが多くなりました。そこで、仮想化環境上で動作するOSの特徴についても知っておく必要があります。
マルチコアCPUやマルチCPU構成が当然になったため、CPUの能力を使い切るには、プログラムをマルチスレッド対応させるか、多数同時に動作させる必要がでてきました。しかし、マルチスレッド対応も、同時動作の保証も、プログラム作成の難易度を一気に高めます。また、マルチスレッド対応しても、サーバーの全コアで並列動作させるほどの性能要件がないこともあります。
そこで、CPUを有効に使い切るための手段として、CPUを自由に仮想マシン（VM）に割り当てられる仮想化が普及しました。この数年注目を集めているコンテナーはVMとよく比較されますが、仮想化のレイヤーがハードウエアでないなどVMとは大きく異なります。両者の違いについて説明します。
仮想マシン（VM）方式の仮想化
まずは、仮想化の代表であるVM（仮想マシン）方式の仮想化と特徴です。VMはハードウエアを模擬した環境をOSに提供するので、複数の異なるOSを同時に動作させることができます。このうち一つのOSがダウンしても、他のOSの動作には影響がありません。一方、仮想マシンには、仮想化のオーバヘッドがあります。仮想化のオーバヘッドは、ストレージI/OとネットワークI/Oに顕著です。逆に、CPUの命令を実行し続けI/Oをほとんど行わない処理は、オーバヘッドの影響を受けづらいです。したがって、I/Oへの性能要求が高いシステムを仮想マシンで動作させる場合、I/O性能に関して入念な検討が必要です。I/Oに仮想化ソフトウエアが介在する以上避けられないのですが、極力減らすための工夫はあります。その代表が準仮想化です。準仮想化は、特別なデバイスドライバをゲストOSに入れ、仮想マシンがハードウエアを模擬することなく、直接I/O対象のデータを送受することで、仮想化のオーバヘッドを大幅に削減します。仮想マシンのデバイスドライバの一覧表示や、デバイス情報でドライバを確認してVM対応のドライバがあれば、準仮想化を使用していることが分かります。
準仮想化ドライバは仮想化基盤により異なり、デバイス名が変わるなどの影響があります。また、準仮想化だと、物理デバイスの動作誤差を利用した乱数生成機能が、誤差データが収集できないため十分に動作しないことがあります。これが原因で、物理サーバー向けの設定のままだと、暗号化や署名作成の処理がいつまでも終了しないことがあります。
仮想化より省リソースのコンテナー
コンテナーは、今後有望な仮想化技術です。GoogleやNetflixといった世界的規模のシステムを支えるだけでなく、CI（継続的インテグレーション）/CD（継続的デリバリー）との相性のよさで注目されるDockerもコンテナーを作成・実行するシステムです。
コンテナーでは、一つのOSの中を分割して、OSを専有しているように見せます。
仮想マシン（VM）やコンテナーの上でOSが動く
カーネルは共通なので、コンテナー間で共通なリソースを共有することにより、VMにくらべて省リソースである一方、WindowsとLinuxや、Linuxの異なるバージョンのように異なるカーネルを同居させられません。コンテナーのメリットとしてポータビリティーが謳われることがありますが、このポータビリティーは、OSが同一であることが前提です。WindowsのコンテナーをLinuxで動かす、あるいはその逆は、コンテナーがあってもなくても同じで、JVMや.NETのようなカーネルの違いを吸収する仕組みを挟む必要があります。
省リソースであるコンテナーは、作成・起動も速いという特徴を活かして、大量の試験を実施しなければならないCIパイプラインの高速化に適用事例が多いです。
ソ－ス：CPU能力を使い切る、仮想環境でOSが動く仕組みを図解 - 新人SEのためのOS基礎：日経 xTECH Active
ブロックチェーン懐疑論
ビジネスマンで、ITや新商品開発のような部門に属している人は、何年か前から「ブロックチェーン」という技術の話をよく聞くようになったと思います。これはビットコインの仕組みの中核にあたる技術なのですが、ビットコインを始めとする仮想通貨の発展には限界があると見越してか、「ビットコインよりもブロックチェーンのほうが凄い発明なのだ。仮想通貨は、その初期の応用の一つに過ぎない」として、ブロックチェーン関連プロジェクトへの投資を進めましょうという主張がよく聞こえてきます。
ブロックチェーンは「インターネット以来の大発明」であり、「全てを変えてしまう」ほどの破壊的な影響力を持つ技術なのだとまで言う人もいます。しかし最近、ブロックチェーンの将来性について懐疑的な専門家の記事をいくつか読みまして（リンクは下のほうにまとめて貼っておきます）、ブロックチェーンは確かに私も面白いアイディアだと思うものの、今のところ懐疑論のほうに説得力があるのではないかと感じました。
ブロックチェーンは、誰かと取引や契約やコミュニケーションをしたいと思っている人がたくさんいて、しかしお互いに信頼することができず、しかも個々の参加者を超越した「信頼できる第三者」や「特権的な仲介者」の役割を担う主体が存在しないという場合に、どうやって取引等を安全に行うかという問題を解決する仕組みです。特に、「やり取りの正しい記録」を残すにはどうすればいいかを考えたもので、ビットコインの場合は、電子署名と呼ばれるデータの改ざん防止技術の他に、全記録の公開・くじ引き・多数決などをうまく組み合わせて解決しているのですが、ビットコイン方式以外にも少し異なる方法がいくつか提案されています。
通常のビジネスには「信頼できる第三者」に支えられたものがたくさんあります。例えばメルカリでモノを売買する時、買う側からすれば「代金を先に払っても、望んだ商品が届かなかったらどうしよう」という心配があり、売る側からすれば「商品を先に送っても、代金が払われなかったらどうしよう」という心配があります。この問題は、メルカリという「信頼できる第三者」が間に入って仲介することで解決されていて、この構造は多くの取引に見られますよね。広義には、法律と司法機関というものも、揉め事が起きたときにどちらが正しいかの裁定を下す「第三者」として機能しています。その「第三者」が実は信頼できないかも知れない、あるいは存在しないという場合に、どうすれば取引が継続的に可能になるかを考えたのがブロックチェーンです。
ブロックチェーン自体は面白いアイディアではあるのですが、ある批判者は、それは本質的に「信頼と時間のトレードオフ」によって成り立っていて（これには異論もあるでしょうが）、処理に長時間を要する仕組みばかりになっており、とても不便であると言います。実際、ビットコインでは１回の決済に数十分かかりますし、ブロックチェーンを用いたSNSのようなアプリでも、投稿が反映されるのに数分かかるようです。処理時間は今後次第に改善していくにしても、処理手数料もかかるのが一般的で、この手数料はなくならないだろうとも指摘されています。
また別の批判者が言うには、「スマートコントラクト」などブロックチェーンの応用例として紹介される事例をよく見てみると、じつはブロックチェーンを使う必然性が特になく、単に「電子化」「自動化」されたことのメリットが大きいだけで、既存の技術でも目的は達せられるし、むしろその方が高性能で安定している場合がほとんどだとのことです。しかもさらによく見ると、開発の過程で工夫を重ねた結果として「信頼できる第三者」が直接・間接に導入されている場合もあり、だったら既存の仕組みでいいという話になります。
ブロックチェーンそのものが、新発明というよりは、既存の技術のツールボックスから「特定の状況でうまく機能するツールの組み合わせ」を見つけただけだという見解もあります。状況が少し異なれば要素技術の組み合わせも変わるのであり、その結果として例えば「信頼できる第三者」が再導入されたりするのであれば、それはもはや当初の意味でのブロックチェーンとは別物です。つまり、「ブロックチェーン」という革命的な技術領域があると考える必要がなく、単にデータ管理の新たな工夫事例が増えただけと言うべきなのかも知れないのです。
実際、日本の政府や金融機関が提案しているブロックチェーン活用の実証プロジェクトなどを見てみても、「プライベートチェーン」と言って、信頼できる企業や公的機関の管理下でのデータ処理方法の議論が多くなっています。その方向でブロックチェーン方式が効率的に機能するケースは何かしらあるように思いますが、それはすでに「信頼できる第三者を不要にする」というほどの革命感は無い話であって、単に処理速度・機密性・冗長性・否認防止・低コストなどを追求するという、日常的な努力の一部という印象を受けます。
懐疑論者の一人は、「たくさんのブロックチェーン信奉者と話してきたのだが、『何か解決したい問題があって、それを解決するベストな方法がブロックチェーンだと判明し、その結果として信奉者になった』という人は存在しなかった」とまで言っています。要するに今は、「ブロックチェーンは面白いアイディアだ」と魅力を感じた技術者と、「ビットコイン以後の投機ネタを見つけたい」と思っている投資家が、「何かいい応用先はないものか」と探し回っている状況なのでしょう。その段階で、革命だの何だのと騒ぐのは大げさですよね。
思想誌のメルマガで技術の論評をするのは場違いなのですが、なぜこんな妙な状況になっているのかを考えることには意味があると思います。これも批判者の一人が言っていることなのですが、ブロックチェーンの有望な応用先がなかなか見つからないのは、結局のところ「信頼できる第三者」や「特権的な仲介者」に頼ったシステムが、多くの場合にとても良く機能するという単純な事実のせいだということです。そのため、ブロックチェーンの応用先を探すつもりが、結局は「信頼」を活用するモデルに行き着いたりしているわけです。
企業・政府・司法機関・NPO・業界団体といった組織を、多くの人が信頼していて、その信頼関係が我々の社会生活や経済活動に大きな力をもたらしています。その力をどうしても利用したくない（たとえばマネーロンダリングのような）場合にはビットコインのようなものが有用でしょうが、そのような状況は限られています。「仮想通貨が全面普及すれば中央銀行が不要になる。通貨発行量に限界があるのでインフレも起きない」といった主張を見かけることもありますが、それは社会の進歩ではなく退歩ではないか、と考えることが重要だと思います。
［参考記事］
What I Learned After Attending 15 Blockchain Events
Ten years in, nobody has come up with a use for blockchain
Blockchain is not only crappy technology but a bad vision for the future
Clemens Vasters氏の一連のツイート
インターネットと言う巨大ネットワーク
個々に管理されたネットワークの集合体がインターネットであると考えることができる。
個々のネットワークがすべて同一のポリシーで管理されることは非現実的でありえない。様々なポリシーで管理されているネットワークで構成されたインターネットは優れた汎用性を持っていなければならない。それは簡単に言うと「なんでもありの管理されていないネットワーク」でなければならない。つまり、管理されていないネットワークであるからこそインターネットと言う巨大ネットワークが存在できている。個々のネットワークが、どのようなポリシーであれ（非常識なポリシーではないと仮定してのことだが）十分に管理されているならば、それらの集合体であるインターネットも十分ではないにしても管理されていると言えるであろう。しかし現実のインターネットは、およそ管理されているとは言いがたい。
なぜ？
それは個々のネットワークが管理されていないからだ。
小さなネットワークならば、パソコン同士をつなぐだけでネットワークができてしまう。技術の進歩で十分な知識がなくてもネットワークをつくることができてしまう。つまり管理されていないネットワークが到る所に誕生してしまうことになるのだ。そのようなネットワークが繋がぅてインターネットが構成されているから、全体としてみるとデタラメに見えてしまうのだ。この状態が良いか悪いかは別にして、デタラメなインターネットを正常に戻せるとしたら、それはインターネットの管理機構、管理方法を確立することではない。個々のネットワークの管理が十分にされるようにすることにあるだろう。
IPパケットはプロバイダ内をどのように転送されるのか
プロバイダの中にあるルーターは，IPパケットに書かれたあて先IPアドレスと経路情報を頼りに，IPパケットを転送していく。しかし，その具体的な動きはなかなかイメージしにくい。そこで，IPパケットがプロバイダのネットワークをどのように転送されるのか，もう少し詳しく見て理解を深めよう。
2種類のプロトコルを使い分けるPart4の本文で見たように，プロバイダ間ではBGPというルーティング・プロトコルを使って経路情報を交換する。一方，プロバイダの内部のルーター間で経路情報をやりとりするのに使われるのが，BGPとは別の「OSPF」と呼ぶルーティング・プロトコルである。
BGPで扱う経路情報は，「そのASに所属するネットワーク」という極めて単純な形式になっている。こうした工夫によって，プロバイダ間でやりとりされる膨大な経路情報をうまくさばける。BGPは，プロバイダ同士の経路情報のやりとりのほか，外部から得た経路情報を自分のAS内の主要ルーターに配る場面で利用される。IPパケットのあて先が他のプロバイダの場合，BGPで得た経路情報が役立つことになる。
一方のOSPFは，AS内のルーター同士の接続状況を示した詳細なマップ（トポロジ・マップ）を管理する役割を果たす。そのうえで，AS内でIPパケットを送る場合の具体的な経路を決める。OSPFには，回線の帯域などを考慮に入れた最適経路を選択できるというメリットがあるが，ルーターの台数や経路情報が増えるとマップの作成に時間がかかるデメリットもある。
外部からの経路はBGPを使って配布具体的な例で，IPパケットが転送されるしくみを追っていこう。
図B-1は，日本全体をカバーするプロバイダAのネットワーク構成例である。コア・ルーターを中心として，バックボーンを構成している。
おもに，ASの外部への経路情報はBGPで管理し，AS内のトポロジ管理にはOSPFを使う。なお，一般にはコア・ルーターやエリア境界ルーターは障害に備えて2台使うが，説明しやすくするために省略した。 [画像のクリックで拡大表示]
プロバイダAの管理する範囲は，AS100である。これは外部のASとBGPで経路情報を交換する単位となる。ASの内部の経路情報は，OSPFで管理する。その場合，いくつかのエリアに分割するのが一般的である。図では，バックボーン・エリア，西日本エリア，東日本エリアに分けている。
このネットワーク構成で，どのように経路情報が配布，管理されるのかを見る。
まずBGPによる経路情報の管理から。プロバイダAは，プロバイダBからBGPで経路情報を受け取る。多くの場合，各プロバイダは，異なるAS同士で経路情報をやりとりするための「ゲートウエイ・ルーター」あるいは「ボーダー・ルーター」と呼ぶ専用のルーターをNOCに置いている。
まずプロバイダAのゲートウエイ・ルーターは，プロバイダBから受け取った経路情報をバックボーン・エリアのほかのルーターに配布する。このときに使われるのもBGPである。一般的には，バックボーン・エリアにあるすべてのルーターはBGPで経路情報を交換する。
一方，OSPFは，AS内の全ルーターがサポートする。エリア内の各ルーターは，そのエリアの詳細マップを共有する。つまり，エリア内の経路はエリア内のすべてのルーターが知っていることになる。しかし，ほかのエリアについては，エリア境界ルーターに処理を任せる。
また，あらかじめエリア境界ルーターは，そのエリアのデフォルト・ゲートウエイであることをOSPFを使ってエリア内のルーターに広告しておく。すると，IPパケットのあて先がASの外の場合，エリア内のルーターはルーティング・テーブル（経路表）に対応する情報を持たないので，エリア境界ルーターにIPパケットを送るようになる。
BGPとOSPFの連係で転送先を決める
では，経路情報を使ってIPパケットが転送される様子を追ってみよう（図B-2）。
図B-2●BGPとOSPFを使ってIPパケットをルーティングする様子
図B-1と同じネットワークで，IPパケットがどのようにルーティングされるのかを示した。AS外のネットワークがあて先の場合，OSPFとBGPがうまく組み合わされることで，IPパケットが適切にルーティングされる。 [画像のクリックで拡大表示]まず，図B-2の（a）のように，西日本にいるユーザーのIPパケットのあて先が，ほかのプロバイダBにあるネットワーク（ここではX）の場合を見ていく。
まず，西日本エリア内のルーターは，デフォルト・ゲートウエイであるエリア境界ルーターにIPパケットを中継する（青の(1)）。
エリア境界ルーターは，BGPの経路表を見て，あて先が（X）のIPパケットはプロバイダBのゲートウエイ・ルーター（Y）に送ればよいことを知る。次に，OSPFの経路表を参照し，（Y）へIPパケットを送るためには，まず隣のルーター（a）に送ればよいことを理解する（青の(2)）。
同じように中継を繰り返して，IPパケットはプロバイダAのゲートウエイ・ルーターまで届く。後は対向するプロバイダBのゲートウエイ・ルーターに送るだけだ（青の(3)）。
今度は，図B-2の（b）のように，あて先がプロバイダAの内部にある場合のIPパケットの中継を見ていこう。
まず西日本の収容ルーターがユーザーからのIPパケットを受け入れる。収容ルーターを含む，西日本エリアのルーターは，最終目的地がある東日本エリアの詳細マップは持たない。しかし，そのエリアが西日本エリアの外にあり，そこにIPパケットを送るにはエリア境界ルーターに送ればよいということは知っている。そこで，西日本エリアのルーターは，IPパケットをエリア境界ルーターまで運ぶ（黄の(1)）。
IPパケットはバックボーン・エリアのルーターを中継され（黄の(2)），東日本のエリア境界ルーターまで届けられる。東日本エリアのルーターは，同じエリアにある最終目的地までの具体的な経路を知っているので，IPパケットは無事届く（黄の(3)）。
マスキングした情報が一定の操作により閲覧し得る状態となっておりました
日本の頭脳である財務省官僚が、またもや大失態をしでかした。
財務省は23日、約4000ページにのぼる森友学園との交渉記録や改ざん前の決裁文書をホームページで公開した。ところが、約3時間後の同日夕にすべて削除。24日未明にあらためて公表した。その理由は、資料の一部について「マスキングした情報が一定の操作により閲覧し得る状態となっておりました」からだという。
ソ－ス：森友4000枚文書黒塗り剥がすと、稲田元防衛相の夫や二階幹事長の名前 財務省痛恨のミス (1/2) 〈週刊朝日〉｜AERA dot. (アエラドット)
「こういったミスを避けるため、紙に印刷をしてからスキャンするなどの対策をするものなのですが……」、いやいやそのためにAcrobatとかに「非表示情報を消去」する機能がある。