Networking)という機能が使えます。利用条件はあるものの、この機能を有効にするだけでネットワークが速くなるので有用なのですが、何がどれくらい速くなるのか気になったので計測してみました。この機能自体は2013年末に発表されたものなので、目新しくはないです。公式の説明やその辺の情報を調べても、イマイチ情報がわかりやすくまとまっていない部分があったので、設定についてもまとめ直してみました。デフォルトと拡張ネットワーキングの性能比較この機能のON/OFFによって、変化するのは通信のレイテンシであり、最大Bandwidthが変わるわけではありません。インスタンスタイプによってレイテンシの変化量が変わるわけでもありません。よる通信の平均時間となっています。一発目は通信経路の把握のために時間を要するため、それを計測値から削るために二度目の実行結果を採取しています。いうのは、拡張ネットワーキングを利用するために必要な、カーネルモジュールの名前です。以上の使用を推奨しているからです。これは、モジュールのソースコードを探しに行くと見つかるREADMEに書いているのですが、このバージョンでパフォーマンスの改善が行われたため、と思われます。それ以外のバージョンのChangeLogは、ほぼディストリビューション対応とBugfixでした。いう事情があり、以下4つとしました。比べてレイテンシが40%程度に抑えられており、優秀であることがわかります。片道分の効果があることがわかります。バージョン違いは、そこまで違いはみられませんが、負荷状況によって差がでるかもしれません。ままにしておく理由もなく、また、READMEを見る限りメジャーバージョンが変わるわりにリスクに関わる変化は少ないと思われるため、最新バージョンを採用してしまってよさげです。程度の誤差を確認しました。ブラックボックスなので推測ですが、単に起動した位置が少し近かったり遠かったりして、経由するスイッチの数が変わっただけだと思われます。以下に安定しているのは凄いことです。なるというのだから垂涎ものであります。実践での効果予測レイテンシが40%になるから、ユーザー体感が60%向上する、なんてわけはないんですが、じゃあどのくらいよくなるかというと......例えば、あるアプリケーションのいちリクエストの処理において、MySQLへクエリを100発行するとします。もの処理時間短縮ができるというわけです!!・・・これをみて、フーン(鼻ほじ)全体1~2秒のうちの20msでしょ~、とか感じちゃう人は、仕事に対する姿勢が勿体無いとしかいいようがありません。ものユーザーストレスを削減できるのだ!!!実際にはもっといろんな箇所で短縮されるし、PVも多いでしょうから、万秒どころか億秒兆秒以上ありますよワンチャン!!・・・みたいなノリで仕事してます。運用されているとしたら、指定のインスタンスタイプにすることで多分、同様の効果を得られると思われます。するかというと、もったいない感じなので、この辺はあまり意識しないで、ついでに恩恵を受けられているだろう程度に知っておけばよさげです。公式の説明ほぼほぼ全てがこの辺で説明されています。#拡張ネットワーキングが、様々なディストリビューションの説明があるために、必要な手順は揃っていても、説明が若干わかりづらくなってる気がしたので、CentOS7の場合の設定についてまとめ直します。ネットワークインターフェース名を永続的にするEC2の公式CentOS7イメージなどから、該当するインスタンスタイプでHVMインスタンスを起動した後、最初にやるべきことはネットワークインターフェース名を永続的にすることです。公式の説明だけではチンプンカンプンなので、この辺のページを読んでおいた方がよいです。手順はこんな感じです。/boot/grub2/grub.cfgこれが必要な理由は、次手順において拡張ネットワーキングを利用することを宣言して再起動すると、利用するネットワークデバイスが変更され、ネットワークインターフェース名が変わってしまうからです。いうヤツになり、IPアドレスが無効な状態になってSSHできなくなります。コマンドを打てるサーバーに移動します。stopped中のインスタンスに対して、拡張ネットワーキング利用の宣言をします。eth0再起動してから同様の確認をすると、モジュールが有効になっていることを確認できます。あたりでカーネルバージョンとパスが関連してしまうため、いつかカーネルのバージョンを上げた時に、知らぬうちに無効になってしまう、ということが考えられます。そのため、DKMSを利用することで、カーネルバージョンアップ+再起動した時点で、自動的に更新して追随してくれるようになります。DKMSを使わないというのもアリっちゃアリですが、このご時世、カーネルに致命傷が見つかることが稀によくあるので、基本的には必須、よっぽどの確信やら自信やらがあるならば、といったところでしょう。手順はこんな感じです。eth0運用についてイメージを保存するここからは、レシピを当てたり、手動設定したりがあるでしょうが、この時点でいったんAMIとしてイメージを保存しておきましょう。拡張ネットワーキングの属性は、イメージの中に保存されるので、次にそのイメージから起動すれば、ONの状態で始めることができます。RPMパッケージにすることは可能っちゃ可能なのですが、DKMSを必須とした場合、結局パッケージインストール時にDKMSでインストールを走らせるという、わけのわからないモノになってしまいます。その動作確認には再起動、もしくはネットワークインターフェースのDOWN/UPが必要なので、レシピ適応後の自動テストにおいて標準的なやり方を押し通すことは難しくなってしまいます。いった事情を鑑みて、こういったイメージやOSの根幹に関わる部分はパッケージ化せず、レシピのデフォルトイメージとして扱う前の手動設定として運用することがベターであると思われます。自動テストするか否か設定を手動にしてレシピと切り離してしまうと、もしかしたら運用ミスで設定の入れ忘れが発生するかもしれません。そのため、設定は作業手順に沿って行うけど、自動テストのレシピは書く、というくらいがよさそうです。あることを確認する、といったような感じで。なんとなく設定している雰囲気があったりで、情報の錯綜が感じられたため、今回まとめ直してみました。減少するような、心が洗われるグラフ変化に出会えるかもしれません。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。