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使用率のパフォーマンスカウンター
f:id:nonbei:20180608173141j:plain


 プログラムやライブラリの比率が高い場合はプログラム、カーネルの比率が高い場合はカーネルも含めた調査が可能な解析ツールを用いて、ボトルネック箇所を特定するといった使い方をします。


ソ-ス:複数のアプリを円滑に動かせるのはOSのおかげ、優先順位と負荷分散を管理 - 新人SEのためのOS基礎:日経 xTECH Active

OS: メモリー管理機能の仕組み

 コンピュータの動作にCPUと並んで不可欠なのがメモリーです。プログラムを実行するには、プログラムがメモリー上にロードされている必要があります。また、計算対象のデータ、入出力するデータもメモリーに置かれます。

 メモリー上のどの領域に、いつ、どのデータを載せるのかによって、プログラムの処理の効率が変わります。これを制御するのが、OSが持つメモリー管理の機能です。メモリー管理は、タスク起動時のプログラムのロード、実行中のプログラムによる動的なメモリー確保だけでなく、ファイルやネットワークなどのキャッシュ、バッファの管理でも使用されます。

 コンピュータのメモリーには、位置を特定するアドレスがついています。このアドレスをそのまま使うと、複数のプログラムが同じアドレスを使ってしまわないように、どのプログラムがどのアドレスを使うか事前に決めなければならなくなります。しかしカーネルのメモリー管理機能があるので、その必要はありません。カーネルは物理的なアドレスと仮想的なアドレスの対応付けを管理することで、すべてのプログラムが他のプログラムを意識しないでメモリーを使えるようにします。

 カーネルは、メモリーの用途別にアクセス保護を設定することで、バグや悪意による不正なメモリーアクセスからプログラムやシステム全体を保護します。不正なメモリーアクセスがあると、カーネルはそのことを示すメッセージやイベントを発生させ、プログラムを強制的に終了させます。

 ライブラリや命令が格納されたメモリーは読み取り専用で、書き込みを試みると例外になります。また、カーネルのメモリーは、カーネルのコードを実行しているとき以外は、プログラムから読み書きできないように設定します。

 ストレージI/Oは、メモリーアクセスに比べると非常に遅い操作です。そこでカーネルは、メモリーをストレージのキャッシュとして使用します。一度読み込んだストレージの内容をメモリーに保持することにより、再度同じ箇所を読み込む場合、メモリーの内容をプログラムに返す、あるいは書き込み内容をメモリー中に保持します。そして適切なタイミング、あるいはプログラムから指示されたタイミングで書き込むことにより、全体的なI/O性能を向上させます。
f:id:nonbei:20180608172820j:plain
OSのメモリー管理機能によるキャッシュへの書き込みと読み込み


 キャッシュは、プログラムが読み書きするファイルだけでなく、ライブラリを含むプログラムの命令部分にも使われます。

使用中のキャッシュを回収
 メモリーをプログラムの命令とデータ、およびファイルI/Oのキャッシュとして際限なく使い続けると、いつかは空きメモリーがなくなります。そこで、OSは、空きメモリーを監視し、一定の基準に基づき、使用されていたメモリーを回収し、空きメモリーにします。メモリーとストレージの内容が同じキャッシュは、直ちに空きメモリーにしても、後に再度ストレージI/Oを行う必要があるにしても、システムの正常な状態を損ないません。

 また、更新されたキャッシュは、ストレージに更新内容を書き戻せば、回収できます。これに対し、プログラム中のデータ領域やヒープ領域(動的に割り当てたデータ領域)は、対応するストレージの内容がありません。このようなメモリーを回収する必要がある場合、OSは、スワップ領域あるいはスワップファイルにメモリーの内容を書き出して、対応するメモリーを回収します。

 メモリー監視ツールが報告する空きメモリーを見るとき、どのメモリーを空きメモリーと報告するかに注意が必要です。一般に空きメモリーとして表示されるのは何にも使われていないメモリーであり、回収可能なキャッシュは含まないことが多いからです。使用中のメモリーには回収可能なキャッシュが含まれるので、空きメモリーが少ないからといって、システムが危機的な状況にあるとは言えません。

 空きメモリーが少ないのを問題視し、強制的にキャッシュを回収させたり、キャッシュのサイズを制限すると、不必要なストレージI/Oでシステム全体の性能を低くださせるリスクもあります。メモリーの使われ方はさまざまであり、監視方法についても一つの正解を示すことはできません。ただしよく使われる指針としては、継続的なスワップの発生を深刻な問題の兆候として監視します。

OS: ファイルシステム

 組み込みシステムでないコンピュータには、CPUとメモリーのほかに、プログラムやデータを格納するストレージがあります。OS上で動作するプログラムは、ストレージ上のデータにファイルシステムを通じてアクセスします。例外は、一部のDBMSファイルシステムを作成・修復するツールだけです。


 プログラムは、カーネルの他の機能と同様、APIによってファイルシステムにアクセスします。カーネルは、これらの操作とストレージ上のデータを対応付けます。加えて、入出力されるデータをキャッシュするためのメモリー管理、アクセス権管理のためのユーザー管理などのセキュリティ機能、ストレージI/Oのためのデバイスドライバとそれぞれ連携します。ファイルシステムがさまざまなストレージに対応できるように、ファイルシステムデバイスドライバの間には、標準化されたストレージデバイスドライバのインタフェースが存在します。
f:id:nonbei:20180608172027j:plain
OS上で動作するプログラムはファイルシステムを通じてストレージを利用する


 ファイルシステムAPIは、ファイルの作成、ファイルのオープン・クローズ、ファイルの読み書き、ディレクトリの一覧取得、ファイルの属性情報取得・設定などの操作を提供します。


 読み書きするファイルの内容は、メモリー管理で紹介したように、カーネルがメモリーにキャッシュとして保持します。また、先頭から順番にファイルを読み込むのは、非常によくあるファイルアクセスの方法なので、ファイルシステムは、このような順次アクセスを検知したとき、ファイルを先読みしてキャッシュに置きます。データベースの表領域のようなランダムアクセスの場合、先読みはムダになるので行いません。


 LinuxWindowsファイルシステムは、書き込みの性能を重視して、デフォルトで書き込みにキャッシュを使います。書き込みの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対応のドライバがあれば、準仮想化を使用していることが分かります。


 準仮想化ドライバは仮想化基盤により異なり、デバイス名が変わるなどの影響があります。また、準仮想化だと、物理デバイスの動作誤差を利用した乱数生成機能が、誤差データが収集できないため十分に動作しないことがあります。これが原因で、物理サーバー向けの設定のままだと、暗号化や署名作成の処理がいつまでも終了しないことがあります。


仮想化より省リソースのコンテナー

 コンテナーは、今後有望な仮想化技術です。GoogleNetflixといった世界的規模のシステムを支えるだけでなく、CI(継続的インテグレーション)/CD(継続的デリバリー)との相性のよさで注目されるDockerもコンテナーを作成・実行するシステムです。


 コンテナーでは、一つのOSの中を分割して、OSを専有しているように見せます。
f:id:nonbei:20180608171733j:plain
仮想マシンVM)やコンテナーの上でOSが動く


 カーネルは共通なので、コンテナー間で共通なリソースを共有することにより、VMにくらべて省リソースである一方、WindowsLinuxや、Linuxの異なるバージョンのように異なるカーネルを同居させられません。コンテナーのメリットとしてポータビリティーが謳われることがありますが、このポータビリティーは、OSが同一であることが前提です。WindowsのコンテナーをLinuxで動かす、あるいはその逆は、コンテナーがあってもなくても同じで、JVMや.NETのようなカーネルの違いを吸収する仕組みを挟む必要があります。


 省リソースであるコンテナーは、作成・起動も速いという特徴を活かして、大量の試験を実施しなければならないCIパイプラインの高速化に適用事例が多いです。


ソ-ス:CPU能力を使い切る、仮想環境でOSが動く仕組みを図解 - 新人SEのためのOS基礎:日経 xTECH Active

ブロックチェーン懐疑論

 ビジネスマンで、ITや新商品開発のような部門に属している人は、何年か前から「ブロックチェーン」という技術の話をよく聞くようになったと思います。これはビットコインの仕組みの中核にあたる技術なのですが、ビットコインを始めとする仮想通貨の発展には限界があると見越してか、「ビットコインよりもブロックチェーンのほうが凄い発明なのだ。仮想通貨は、その初期の応用の一つに過ぎない」として、ブロックチェーン関連プロジェクトへの投資を進めましょうという主張がよく聞こえてきます。


 ブロックチェーンは「インターネット以来の大発明」であり、「全てを変えてしまう」ほどの破壊的な影響力を持つ技術なのだとまで言う人もいます。しかし最近、ブロックチェーンの将来性について懐疑的な専門家の記事をいくつか読みまして(リンクは下のほうにまとめて貼っておきます)、ブロックチェーンは確かに私も面白いアイディアだと思うものの、今のところ懐疑論のほうに説得力があるのではないかと感じました。


 ブロックチェーンは、誰かと取引や契約やコミュニケーションをしたいと思っている人がたくさんいて、しかしお互いに信頼することができず、しかも個々の参加者を超越した「信頼できる第三者」や「特権的な仲介者」の役割を担う主体が存在しないという場合に、どうやって取引等を安全に行うかという問題を解決する仕組みです。特に、「やり取りの正しい記録」を残すにはどうすればいいかを考えたもので、ビットコインの場合は、電子署名と呼ばれるデータの改ざん防止技術の他に、全記録の公開・くじ引き・多数決などをうまく組み合わせて解決しているのですが、ビットコイン方式以外にも少し異なる方法がいくつか提案されています。


 通常のビジネスには「信頼できる第三者」に支えられたものがたくさんあります。例えばメルカリでモノを売買する時、買う側からすれば「代金を先に払っても、望んだ商品が届かなかったらどうしよう」という心配があり、売る側からすれば「商品を先に送っても、代金が払われなかったらどうしよう」という心配があります。この問題は、メルカリという「信頼できる第三者」が間に入って仲介することで解決されていて、この構造は多くの取引に見られますよね。広義には、法律と司法機関というものも、揉め事が起きたときにどちらが正しいかの裁定を下す「第三者」として機能しています。その「第三者」が実は信頼できないかも知れない、あるいは存在しないという場合に、どうすれば取引が継続的に可能になるかを考えたのがブロックチェーンです。


 ブロックチェーン自体は面白いアイディアではあるのですが、ある批判者は、それは本質的に「信頼と時間のトレードオフ」によって成り立っていて(これには異論もあるでしょうが)、処理に長時間を要する仕組みばかりになっており、とても不便であると言います。実際、ビットコインでは1回の決済に数十分かかりますし、ブロックチェーンを用いた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氏の一連のツイート


ソ-ス:【川端祐一郎】ブロックチェーン懐疑論について | 表現者クライテリオン

インターネットと言う巨大ネットワーク

 個々に管理されたネットワークの集合体がインターネットであると考えることができる。
 個々のネットワークがすべて同一のポリシーで管理されることは非現実的でありえない。様々なポリシーで管理されているネットワークで構成されたインターネットは優れた汎用性を持っていなければならない。それは簡単に言うと「なんでもありの管理されていないネットワーク」でなければならない。つまり、管理されていないネットワークであるからこそインターネットと言う巨大ネットワークが存在できている。


 個々のネットワークが、どのようなポリシーであれ(非常識なポリシーではないと仮定してのことだが)十分に管理されているならば、それらの集合体であるインターネットも十分ではないにしても管理されていると言えるであろう。しかし現実のインターネットは、およそ管理されているとは言いがたい。


 なぜ?


 それは個々のネットワークが管理されていないからだ。
 小さなネットワークならば、パソコン同士をつなぐだけでネットワークができてしまう。技術の進歩で十分な知識がなくてもネットワークをつくることができてしまう。つまり管理されていないネットワークが到る所に誕生してしまうことになるのだ。そのようなネットワークが繋がぅてインターネットが構成されているから、全体としてみるとデタラメに見えてしまうのだ。


 この状態が良いか悪いかは別にして、デタラメなインターネットを正常に戻せるとしたら、それはインターネットの管理機構、管理方法を確立することではない。個々のネットワークの管理が十分にされるようにすることにあるだろう。


ソ-ス:Blog for CAT | 無題

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のネットワーク構成例である。コア・ルーターを中心として,バックボーンを構成している。

f:id:nonbei:20180531194649j:plain

おもに,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)。

f:id:nonbei:20180531194919j:plain

図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))。


ソ-ス:IPパケットはプロバイダ内をどのように転送されるのか | 日経 xTECH(クロステック)

マスキングした情報が一定の操作により閲覧し得る状態となっておりました

 日本の頭脳である財務省官僚が、またもや大失態をしでかした。


 財務省は23日、約4000ページにのぼる森友学園との交渉記録や改ざん前の決裁文書をホームページで公開した。ところが、約3時間後の同日夕にすべて削除。24日未明にあらためて公表した。その理由は、資料の一部について「マスキングした情報が一定の操作により閲覧し得る状態となっておりました」からだという。


ソ-ス:森友4000枚文書黒塗り剥がすと、稲田元防衛相の夫や二階幹事長の名前 財務省痛恨のミス  (1/2) 〈週刊朝日〉|AERA dot. (アエラドット)

f:id:nonbei:20180530103751p:plain

f:id:nonbei:20180530103810p:plain


「こういったミスを避けるため、紙に印刷をしてからスキャンするなどの対策をするものなのですが……」、いやいやそのためにAcrobatとかに「非表示情報を消去」する機能がある。

“Spectre” Variant 3a/4への対応

2018年5月25日号 “Spectre” Variant 3a/4への対応・Windows Server環境でのWSL:Ubuntu Weekly Topics|gihyo.jp … 技術評論社





関連:
Intel、2018年後半投入のCPUで「Meltdown」「Spectre」対策の新設計を導入:投機的実行に関する脆弱性に対処するマイクロコード提供も大きく前進 - @IT

ubuntu 18.04

win10 から Ubuntu 18.04 LTS(Long Term Support=LTS)版に換えた。


Ubuntu 18.04 LTSインストールガイド【スクリーンショットつき解説】 | Linux Fan

Ubuntu 18.04 LTSをインストールした直後に行う設定 & インストールするソフト

  • 初めてログインした際の一番最初の設定
  • 更新を確認する
  • ソフトウェアのダウンロード元を変更する
  • ファイアーウォールを有効にする
  • ディスプレイの電源が自動的にオフにならないようにする
  • 画面が自動的にロックされないようにする
  • コーデック等をまとめてインストールする
  • 時刻の表示を変更する
  • ウィンドウが自動的に最大化しないようにする
  • 『デスクトップ』『音楽』などの日本語フォルダー名を英語表記にする
  • 右クリックメニューから空のドキュメントを作成できるようにする
  • 時刻合わせの設定を変更する


Ubuntu 16.04 その69 - 段階的にパッケージのアップデートを提供するフェーズドアップデート - kledgeb
「apt」コマンドを利用すればすべてのアップデートが適用されますし、アップデートが提供される最初のユーザーになる可能性もありますが、余計なトラブルを避けるためにも「フェーズドアップデート」によるアップデートを利用したほうが良い。

第517回 Ubuntu 18.04 LTSの変更点:Ubuntu Weekly Recipe|gihyo.jp … 技術評論社

そろそろ Windows10 (CPU G530) と別れるときが来た

Microsoftがバージョン1803(April 2018 Update)のWindows 10/Server向けに、IntelプロセッサーのSpectre Variant 2 脆弱性を修正するマイクロコードアップデートを提供開始した。(KB4100347)

Microsoft Updateカタログした。
f:id:nonbei:20180520225614p:plain


しかし、いつまでWindows10で使えるのだろう?
インテル® プロセッサーの Microsoft Windows® 10 の対応状況について
SandyBridgeがない。Windows10サポート外なのか。


CPUがG530という古いもので、Windows を使い続けるのは無理と判断した。

デ-タをバックアップしよう。



関連:
【後藤弘茂のWeekly海外ニュース】なぜSandy Bridgeはそんなにパフォーマンスが高いのか - PC Watch

EFAIL:電子メールの暗号化に脆弱性

 欧州の研究者らによって「EFAIL」と名付けられたこの脆弱性は、PGPなどの電子メール暗号化規格を破るものではないが、電子メールクライアントがHTMLコードを読み取る方法に関連する脆弱性を利用する。


 この攻撃は、最近のメッセージだけでなく、アーカイブ済みの暗号化された電子メールにも適用できる。


 研究者らは、PGPメッセージの解読を防ぐために、電子メールクライアントのHTMLレンダリングを無効にすることを推奨している。電子フロンティア財団(EFF)は、PGP電子メールプラグインの使用を一時的にやめて、電子メールをベースとしない「Signal」などのプラットフォームを暗号化メッセージに使用することを推奨している。


ソ-ス:暗号化された電子メールが読み取られるおそれ--「EFAIL」脆弱性が明らかに - ZDNet Japan


関連:
EFAIL

News | Surveillance Self-Defense

EFAIL - Qiita

Mozilla、Thunderbirdの暗号メールの脆弱性と対策について説明 - グノシー

おそらくSEな人の備忘録 Thunderbird の HTMLメール無効化設定

10GBASE-Tのケーブル

CAT5、CAT5eケーブルは10GBASE-Tに非対応


 10GBASE-Tのケーブルに関しては、CAT5/CAT5eの利用を断念し、CAT6/6a/6e/7のみのサポートとしたのが大きなポイントである。当初、10GBASE-Tでは既存の1000BASE-Tとの互換性を考えてCAT5ケーブルの利用を可能にしようとしていた。CAT5、正式には「ANSI/TIA/EIA-568-A」に加えて「TSB-95」で明確化されたCategory 5ケーブルであるが、「UTP(Unshielded Twisted Pair:シールドされていない撚り対線)」方式で、通せる信号周波数の上限は100MHzとされている。


 冒頭で説明した通り、1000BASE-Tでは信号周波数が125MHzなので、厳密に言えばオーバースペックでの運用になっている。このこともあり、短距離(数mのオーダー)だと問題はないが、1000BASE-Tの最大到達距離である100mまでで利用しようとすると、CAT5では性能的に怪しくなる。これもあって、CAT5eあるいはCAT6の利用が推奨されている。ただ、10GBASE-Tでは、信号周波数が200MHzとさらに高くなることもあって、CAT5では1m未満でも性能的に怪しいという話になり、わりと早い時期にCAT5の利用が断念された。


 このCAT5の改良版がenhanced Category 5(CAT5e)である。こちらも信号周波数は100MHzまでだが、内部の配線を太くして伝達特性を改良したもので、1000BASE-Tでは100mまで利用可能となっている。しかし、こちらを使っても10GBASE-Tではやはり性能的に厳しいことがシミュレーションで早期に判明し、やはりサポートから落ちている。


 さて、その代わりにサポートされたのが、Categoly 6(CAT6)である。CAT6では内部の4対の配線が偏らないように十字型のスペーサーが内蔵されている。撚り対線も変更され、250MHzまでの信号周波数に対応している。10GBASE-TではこのCAT6を利用した場合、最大37m(後述するエイリアンクロストークがなければ55m)までの通信が可能とされた。


 このCAT6の改良版が、Enhanced Category 6(CAT6e)である。実はこれ、TIAANSIでは策定されていないケーブルメーカーの独自規格である。違いは、4対の撚り対線に加えて、スペーサー全体を薄いアルミのシールドで覆う形になっていること。建前上はシールドなので、UTPではなくSTP(Shielded Twisted Pair)に分類されることになるはずなのだが、実際はこれがUTPとして扱われるのは、このアルミのシールドがアースされていないためだ。現実問題としては、シールドの性能が不十分である。これもあり、10GBASE-T的にはCAT6ケーブルと同じ扱いである。
f:id:nonbei:20180507024250p:plain

CAT6Aは500MHz、CAT7はGG45/TERAコネクタ採用で600MHzに対応

 このCAT6eをさらに拡張したのが、Augmented CAT6(CAT6A)である。4対の撚り対線+スペーサーをアルミのシールドで覆う構造はCAT6eと同じだが、撚り対線が変更されて500MHzまでの信号周波数に対応した。また外皮が不等断面形状になり、特に複数のCAT6Aケーブルを並べた際のケーブル間の信号干渉(これをエイリアンクロストークと呼ぶ)を減らす効果がある。ただ、このCAT6Aも、外側のアルミシールドは実際にはアースされていないためシールド効果が不十分で、一定の条件下では10GBASE-Tで利用できない可能性が指摘された。これもあって、後にはCAT6Aのケーブルを利用したSTPも登場している。


 さて、これらに続いて登場した本命が、Category 7(CAT7)である。このあたりから、もはやUnshieldのままでは高速化は不可能と判断され、完全に配線をシールド化したSTPに切り替わった。CAT7の場合、4つの撚り対線はそれぞれ個別にシールドされ、さらに全体を網線シールドで覆う構造になっている。
f:id:nonbei:20180507024216p:plain

 図で確認すれば、要するにどんどんケーブルが太く、高価になる方向に進化していったわけだ。もっとも、それでも10GBASE-CX4のように4対×2の同軸ケーブルを使うよりは安価、という見通しだった。しかし、実際に価格が下がったのはつい最近のことである。


 眼で見た違いは(ケーブルの太さとか折り曲げにくさを除くと)コネクタ部にある。CAT6Aまでは伝統的に「RJ45」というコネクタが利用されてきた。これはプラスチック製で、内部に8つの端子が用意されているだけのものである。これに対し、CAT7では「GG45」ないし「TERA」コネクタが用いられる。


 GG45は、コネクタ構造そのものはRJ45と後方互換性があるが、コネクタ全体をメタルシールドで覆う形になっている。これにより、コネクタのシールド部を通してケーブルのシールドがグランドに接続されることになり、シールド性能が大幅に向上した。


 一方のTERAは、ヨーロッパでよく利用されているもの。Siemonという会社が開発したもので、そのまま標準化された。撚り対線の信号周波数の対応が600MHzまでに向上しており、これを利用することで、10GBASE-Tで100mまでの通信が可能になる。余談だが、このGG45あるいはTERAコネクタとCAT6Aケーブルを組み合わせたのが、CAT6AのSTPということになる。

f:id:nonbei:20180507024717p:plain


CAT7Aは1000MHzながら25/40GBASE-T非対応、2000MHzのCAT8で対応へ

 ついでに余談を一つ。最近はAugmented Category 7A(CAT7A)およびCategory 8(CAT8)ケーブルも普及を始めている。これらはいずれも、25/40GBASE-Tという、10GBASE-Tの次の規格向けのものである。CAT7Aは、1000MHzの信号周波数を目標に制定されたものの、これでは25GBASE-Tでも十分ではないということで、結局10GBASE-Tのみのサポートになっている。一方CAT8は、当初1600MHz以上として策定が始まり、最終的には2000MHzになったものだ。25GBASE-Tおよび40GBASE-Tは、このCAT8ケーブルで最大30mまでの距離で利用可能とされる。


 さて、CAT7A/8の仕様上の構造そのものは、CAT7のままなのだが、2016年1月に開催されたCES(Consumer Electronics Show)において、WireWorld Technologyが斬新なCAT8ケーブルを発表した。もっとも同社は、オーディオ向けケーブルを手がけている会社なので、本当にこれを25GBASE-Tや40GBASE-Tで使えるのかどうかは不明(同社もオーディオ向けの話しかしていない)だし、そもそもTIAの定めた標準規格「ANSI/TIA-568-C.2-1 specifications for Category 8 cabling systems」に合致したケーブル特性を実現できているのかどうかも謎である。このあたりがクリアになるまでは、とりあえずこれはオーディオ用ケーブルとして使うのが無難な気がする。


 というわけで長くなったが、変調方式・エラー訂正・ケーブルと、すべての面で大幅な拡張というか新技術を導入するという前提の下で、やっと10GBASE-Tの標準化が完了したわけである。



ソ-ス:【10GBASE-T、ついに普及?】CAT5/CAT5eの利用を断念 CAT6/6A/6e/7のみサポート【期待のネット新技術】 - INTERNET Watch




関連:

Variable Fontって

「Rockridge- Layout-Variable Fontのデフォルト有効化はFirefox 62に延期された」でVariable Fontの存在を知った。

f:id:nonbei:20180504083303p:plain

The Typekit Blog | バリアブルフォント – 柔軟なデザインを可能にする新しい種類のフォント

Variable Fontについて - console.blog(self);

無限にフォントが作れる!?フォントの概念を大きく変える「Variable Font」とは|ferret [フェレット]

Variable Fontを試してみました

トロン: 国産OSが世界標準になるか

トロン著作権を譲渡


 電気・通信の分野で世界最大の標準規格策定団体である米国電気電子学会(IEEE)が、トロンフォーラム(会長は坂村博士)にトロンの著作権譲渡を求めてきたのは、トロンがデファクト・スタンダードであることを認めたからだ。坂村博士は昨年8月、IEEE標準化委員会のコンスタンチノ・カラカリオス事務局長と会談し、組み込み用トロンの最新版である「マイクロTカーネル2・0」の著作権を譲渡する(両者が著作権を共有する)契約書にサインした。


 「『ミスター坂村、あなたはよく頑張った。これからは私たちがトロンを発展させてあげよう』と言われた。どうしようかと思ったけど、譲っちゃうことにしました。もちろん無償ですよ」。調印の2か月後、坂村博士は、譲渡の理由を尋ねた筆者にそう答えた。


国電気電子学会が認定へ


 IEEEは電気・電子関連の幅広い技術分野で約900件もの標準規格を定めている。その規格が世界標準になっているおかげで、世界中で同じ工業製品を使うことができるのだ。例えば、どこの国を訪れても自分のスマホが無線LAN(WiFi)につながるのは、世界中がIEEEの定めた無線LAN規格を使っているからだ。情報処理系OSとしてパソコン以外では圧倒的なシェアを占めるポジックスも、IEEEが標準規格として認定したOSである。


 「われわれが標準化(標準規格として認定)すれば、トロンはよりグローバルに受け入れられるようになるだろう。トロンの未来は明るい」。標準化作業部会のスティーブン・デュークス議長は、昨年12月に東京・六本木で開かれたシンポジウムでそう語った。


 作業部会での標準化作業が終了し、標準化委員会で認められれば、トロンは晴れてIEEEの標準規格となる。事実上の世界標準から、公式の世界標準となるのだ。早ければ年内に認定される見込みだ。


 世界標準になれば、トロンを多く採用している日本の工業製品には追い風になることだろう。


 組み込み用のトロンは情報処理系OSよりも構造がシンプルなので、例えば発展途上国の技術者であっても、先進国の大手メーカーの協力を仰がなくても、独自に製品開発に利用できる。IEEEは、標準化によって、途上国でもトロンの利用が広がるだろうと予想している。



ソ-ス:トロン―国産OSが世界標準になる : 特集 : 読売新聞(YOMIURI ONLINE)