as the Wind Blows ...

パソコン、プログラミング、車、写真、etc...

自宅サーバー買い替え (1) - 構成

自宅サーバーを新規にパーツ集めて作り直しました！

 

ここ最近GeForce 1660 TiのNVEncを使ったHWエンコードで過去のTSデータの整理を行っていたのだが、同時にサーバーがハングアップするようになってしまっていた。ESXi上のVMがハングするのではなく、ESXi ホストが突然ハングアップする。ホストのログを色々調べてみたのですが、ある瞬間に突然ハングするようで手掛かりなし。

ただハングするのは必ずCPU負荷が100%に近い状態で何か操作するときに頻発する。最初は新しく追加したGPUのせいかと思ったのですが、取り外して高負荷をかけてもハングするのでGPUは関係なかった。今まで気が付かなかったのは、エンコードなんてしてなかったので負荷をかけなかったから気が付かなかったらしい。メモリ不良を疑いMem Testを回すもエラーなし。試しにメモリスピードを1600MHzから1066MHzに下げるとハング発生の頻度が下がることは分かった。メモリ関連の不良の可能性は高いが、新品メモリ使ってもハングするため、メモリモジュールが原因ではなさそう・・。

 

CPUなのか、ボードなのか、はたまた電源が原因なのかさっぱりわからない。

正確には、約7年間24時間つけっぱなしのマシンなので、故障に心当たりが多すぎて原因がさっぱりわからない（笑）

 

一つ一つ部品を交換してチェックするのもばかばかしいくらい古いパソコンなので、せっかくなのでサーバーを新規に自作することにしました。

 

本当は10nmのAlder Lakeまで待ちたかったのですが、そこまで持ちそうにないので諦めました。Commet Lakeで我慢します。

 

今使っているのは第４世代のHaswellで、Commet Lakeは第10世代です。私の個人的な基準で、今使っているCPUの性能が倍になったら買い替えるを目安にしてきました。HaswellからCommet Lakeではsingle core性能で見ると2倍までいかないですが、コア数が倍以上なので2倍以上の性能は余裕でしょう。

 

今使っているパソコンの不満をうまく解決する方向で部品を選んでいきたいと思います。

 

不満１：サーバーの性能よりもノートPCの性能のほうが高くなりつつある（サーバーの意味ない）

不満２：メモリ24GBでは足りない。VMでメモリ容量を制限しないといけない。

不満３：HWエンコードで速度は上がったが、GeForce 1660 Ti高後負荷時にうるさい

不満４：PCケースが小さく、内部のエアフローが悪いため熱がこもり、GPUがさらに厚くなる悪循環。ケースが小さすぎて、部品交換時は総取り外しなのでメンテナンス性が悪い

 

 

上記不満から、下記のパーツを選定しています。

 

CPU : Core i9-10900 (無印) TDP 65W 10C 20T

メモリ：DDR4 64GB 2933MHz

マザーボード：ASUS TAF GAMING B460M-PLUS (Micro ATM)

電源：Corsair HX750i (80Plus Platinum)

PCケース：Thermaltek Core V21

CPUクーラー：Corsair H100i Platinum

ストレージ：SATA SSD +HDD(前のPCから流用）

ケースファン：Noctua NF-A9-PWM

 

性能面ではTDP65Wはキープしつつ、性能を限界まで上げるためi9を選択。

メモリ容量は32GBx2枚で容量を確保

PCケースは今よりも一回り大きいキューブ型を選択。

ケースに合わせMicro ATMのマザボ購入。うちで実績があるTUFシリーズを採用

電源は静音性と効率を重視。

CPUクーラーは使ってみたかったという理由で水冷クーラーを選択。

92mmのNoctua製ファンはGPU冷却用。GeForce 1660 Tiのファンは薄型で3000rpm Maxで正直うるさい。保証外になるが、分解してファンを取り外しヒートシンクむき出し状態で正面から風を当てる実験をしたところ、この方式のほうが冷えることが分かった。PCIスロットを3スロット使ってしまうが、音の対策という意味ではよいと思われるので試してみる。

動画エンコード環境改善 (4) - GeForce 1660 Ti 再起動後のコード43エラー対策

 

vonvon.hatenablog.com

 ここで書いたようになぜかGeForce 1660 TiをESXiにパススルー後、ESXiホスト初回起動時は正常に認識するが、VMをシャットダウンや再起動するとデバイスマネージャーでコード43のエラーで初期化に失敗している状況。

ググったところ、全く同じ症状の人がVmwareのコミュニティに書き込んでいた。

https://communities.vmware.com/thread/607001

 

正常に使えているというレビューも別のサイトにあったが、ESXiのバージョンが分からなかった。ESXiを6.5から6.7にアップデートしたら動かなくなったという事で、6.5に戻すか、7.0を試してみればよいのかもしれないがバージョンダウンは簡単にはできないし、7.0も今すぐにアップグレードするのは不安。。

 

上記コミュニティーの書き込みに回避方法が書いてあったので、まずはそれを試す。内容はシンプルで、再起動やシャットダウン前にデバイスマネージャーでGPUと関連デバイスを無効に設定するだけ。起動後には手動で有効にすれば、正常に認識する。

実際試したところ、確かに正常に初期化されてGPUエンコードできる！

その他の検証するの面倒なので、取り急ぎこの回避策を使おう。ブルースクリーンとかハングアップしたらダメそうだけど。。

 

毎回手動で有効/無効切り替えるのは面倒なのでバッチ化しました。

ググるとWindows Driver Kit (WDK)の中にあるdevcon.exeを使う方法が簡単みたい。

WDKをインストールし、devcon.exeを抜き出し下記のバッチファイルを作ります。

 

## デバイス有効

devcon enable "PCI\VEN_10DE&DEV_2182&SUBSYS_8D901462&REV_A1"
devcon enable "HDAUDIO\FUNC_01&VEN_10DE&DEV_0099&SUBSYS_14628D90&REV_1001"
devcon enable "USB\VID_0955&PID_9000"
devcon enable "PCI\VEN_10DE&DEV_1AEC&SUBSYS_8D901462&REV_A1"
devcon enable "PCI\VEN_10DE&DEV_1AED&SUBSYS_8D901462&REV_A1"

 

## デバイス無効

devcon disable "PCI\VEN_10DE&DEV_2182&SUBSYS_8D901462&REV_A1"
devcon disable "HDAUDIO\FUNC_01&VEN_10DE&DEV_0099&SUBSYS_14628D90&REV_1001"
devcon disable "USB\VID_0955&PID_9000"
devcon disable "PCI\VEN_10DE&DEV_1AEC&SUBSYS_8D901462&REV_A1"
devcon disable "PCI\VEN_10DE&DEV_1AED&SUBSYS_8D901462&REV_A1"

 

devconは devcon enable/disable "<Hardware ID>"の構文で使います。

disable/enable変更するデバイスのHardware IDはデバマネで確認しましょう。

 

バッチファイル作成後は、ローカルグループポリシーの編集→コンピューターの構成→Windowsの設定→スクリプト→スタートアップ or シャットダウンでバッチファイルを登録します。そうすれば起動時やシャットダウン時に自動でバッチファイルが実行されます。

 

 

 

動画エンコード環境改善 (3) - 画質比較

GeForce 1660 Tiでハードウェアエンコードしてみたので、速度と画質の評価をしてみたいと思います。詳細な比較は他サイトでいろいろ行われているため、ここではあくまで自分用メモとして残していますが、基本的には結論は他で評価されている内容と方向性は同じでした。

 

評価の指標はSSIM(ALL)の値と動画から静止画切り出し後に目で見て比較を実施しています。使う動画のソースによりSSIMの値は大きく変わるため、２パターンで検証してみました。

 

パターン１：ソース = 2019/12/31放送 CDTV年越しライブ オープニング3分間切り出し

 

こちらはオープニングで乃木坂46が歌っているシーンの切り出しとなります。ほぼ３分間にわたり、シーン切り替え、チルド、パン等、画面全体に動きがあるソースです。今までは、このような歌番組等を保存しておきたい場合、私はエンコードはせずそのままTSを必要な範囲切り出して保管していました。エンコードの素材としては、私的には適当ではない素材ですが、意地悪なソースの例として試しています。結果が下記となります。

Enc Engine bit rate Enc Time (sec) fps SSIM(ALL)
x264 SW 7 Mbps 1245 5.34 0.955274
x264 SW 3.5 Mbps 1095 6.26 0.935873
QSV h264 7 Mbps 86 65 0.950438
QSV h264 3.5 Mbps 90 61 0.928495
NVEnc h265 7 Mbps 23 253 0.959321
NVEnc h265 3.5 Mbps 21 251 0.940422

 

x264 SWエンコードはvery slow設定で行っていますが、同じビットレートでSSIMを比較するとh264とh265ではハードウェアエンコードのほうがSSIM値で見ると、画質はよいという評価になりました。一方で、特に動きが激しい部分の静止画を切り出すと明らかに破綻している箇所が見受けられます。動画を普通に再生していても、なんかブロックノイズで乱れているなとぱっと見くらべてわかる箇所が多いです。HWエンコードの場合、静止画で比較してしまうとディテールがつぶれる傾向にあるのはよくわかりますが、その点はぶっちゃけ静止画比較しないとわからないです。

圧倒的なのはエンコード速度ですよね。うちのCPUがもともとしょぼいというのはもちろんありますが、画質をある程度犠牲にしたとしても、このエンコード速度は評価すべきなので何とか使いこなしたいです。

 

続いてパターン２、私がよくエンコードしている素材での検証です。

 

パターン２：ソース＝おしゃれイズム

PVのように頻繁に画面に動きがある素材ではなく、トーク中心の番組を想定したソースです。その結果が下記になります。

 

Enc Engine bit rate SSIM(ALL) memo
x264 SW 7 Mbps 0.989521 VBR 2pass
NVEnc x265 7 Mbps 0.992152 --vbrhq 0 --vbr-quality 20
NVEnc x265 5 Mbps 0.991126 --vbrhq 0 --vbr-quality 22

 

私の場合、少し高画質でエンコードしたいケースでは7Mbps、ドラマなど、特にこだわりない場合は3.5Mbpsでこれまでエンコードしていました。--vbr-quality 22はパターン2のソースでこのサイズになる値を探して決めています。--vbrhq 0 --vbr-quality 20はパターン3のハケンの品格第一話を3.5Mbpsになるように見つけた設定でパターン２をエンコードした結果です。どちらも多少、やはりディテールはつぶれる傾向にありますが、SSIMは0.99を超えています。動きが激しい部分を切り出して見つけてこないと、7Mbpsと5Mbpsの違いは私の眼にはよくわかりませんでした。トーク系の番組であれば、私のケースでは-vbr-quality 20で十分かもしれません。ソースにも依存すると思うので、もう少しいろいろな素材で検証が必要な気がします。

 

最後にパターン３、頻繁にエンコードしている実写ドラマ系です。

パターン3：ソース＝ハケンの品格 第一話

 

Enc Engine bit rate SSIM(ALL) memo
x264 SW 3.5 Mbps 0.990103 VBR 2pass
NVEnc x265 3.5 Mbps 0.993178 --vbrhq 0 --vbr-quality 22
NVEnc x265 2.6 Mbps 0.992752 --vbrhq 0 --vbr-quality 24

 

たまにスマホから見返してみるような使い方しかしていないから、--vbr-quality 24で十分な気がする。

動画エンコード環境改善 (2) - GeForce 1660 Ti パススルー

さっそく週末にGeForce 1660 Tiが届いたので、PCに取り付けてみました。ボードの長さが178mmと短いバージョンを購入しているのですが、使っているPCケースが小型キューブということもあり、でかい・・・。

事前に長さと厚さはチェックして問題ないことを確認済みでしたが、高さ方向は遮るものないから油断していました。PCIeスロットのブラケットの上にケースファンがあるのですが、そこに3mmくらい干渉している。もともとケースファンを取り外さないと接続できない構造になっているの十分入るのですが、ボードとぶつかるせいでケースファンのねじが閉まらない・・。仕方がいないのでファンの四隅のねじ止めはあきらめ、1か所だけとめて斜めに付けました。風は通っているのでとりあえずは大丈夫でしょう。だけど次PC新しくするときは少し大きいケースにしよう。。

 

さて、問題のGeForce 1660 TiのESXiでのパススルーです。

GeForce系GPUのパススルーのノウハウはあちこちに記載があるので省略します。結論から言えば、とりあえず制限付きですが問題なく動いています。

パススルーの時のポイントは下記ですね。

  • BIOSはUEFIを選択しておく
  • Integrated GPU(Intel製ならHD Graphics)はBIOSでdisableしておく
  • VMの詳細オプションでhypervisor.cpuid.v0=FALSEを追加する

うちのサーバーはESXi 6.7 u3で動作していますが、ESXi起動直後にGPUパススルー設定したVMを起動した場合は全く問題なく動作します。ただ、VMを再起動したりシャットダウンすると、VM起動後にGPUがデバイスマネージャーでコード43のエラーで動作しません。ちょっと調べたら同じ現象になっている情報がvmwareのサポートページにありました。


https://communities.vmware.com/thread/607001


この方はESXi 6.5では問題なかったが、ESXi 6.7にアップデート後にこの症状になってリセットの挙動の違いが原因ではないかと疑っているようです。この状態になった場合、ESXiを一度再起動し、その後VMを起動すれば問題ないためリセットの挙動の違いが原因というのは可能性が高いと思いますね。別途検証/対策は考えるとして、とりあえずHWエンコードの動作確認に進みます。VM起動しっぱなしにすれば取り急ぎは問題ないしね（笑

 

さて必要なファイルをインストール後にAmatsukazeでNVEncでエンコードしてみます。動作確認と速度チェックなので今回はパラメータとか特に気にせず、ほぼデフォルト設定で行きます。フィルタのチェックはインタレース解除のみ、固定品質モードでエンコードします。結果、x264の場合約300fps、x265の場合も同様に約300fps。SWエンコードの場合と比較して60倍！スゴイ！

CPU使用率は100%に近い。。デコード処理が追いついていないかも。GPUはまだ余裕ありそうですね。デコードもGPUでさせたほうがスピードは上がりそうですね。事前にネットで調べた限りではx265とx264は速度に２倍くらい差があるということでしたが、うちの環境ではどちらも同じですね。GPUが早くなっているのか、CPU性能がボトルネックになってい速度が出ていないのかまだよくわかっていません。

とりあえず、ちゃんと動くことは確認できたため次から画質の妥協点を探っていきたいと思います。

 

動画エンコード環境改善 (1)

何もせずに放置中のこのブログですが、ちょっとメモしておこうと思った出来事があったので書き留めておきます。

 

私の自宅には自作サーバーが稼働していますが、普段はキーボードやマウスはもちろんモニタも接続されていません。そのため、普段はノートパソコンを使用しています。しかし約９割の作業はサーバー上で稼働するVMにリモートデスクトップ接続して使っています。ノートパソコンでの作業はせいぜい動画をチェックするときくらいですね。

 

このようにしている理由は仕事柄どうしても海外出張が多く、多い時では１か月くらい自宅から離れるということが年に数回あったりするためです。その場合、プライベートのノートPCを出張先に持ち込むのも面倒なので、自分のパソコンではない環境からも普段の自宅環境に接続できるように工夫しています。

 

自宅サーバー上にはVMが常時５～８つくらい稼働しています。Linux VMが２つ（Linux Serverと各VMのバックアップ、リストア用サーバー）とWindows VMが３つ（普段使いPC、録画PC、テスト用PC）＋作業中のテスト環境VMが０～３つ程度。

 

今回の環境改善はこの中の録画PCについてとなります。

この録画PCではパススルーされたPT3が動作しており、必要な番組をTS形式で録画しています。録画した番組は高画質で保存しておきたいものはそのままTS形式で保管、その他は定期的にH264のmp4形式にエンコードしています。

 

一時期はAvisynth でフィルタを組み合わせてエンコードしていたのですが、あまりエンコードに割ける時間が無くなってきたこともあり、しばらく前から超絶便利なAmatsukazeに移行しています。しかし自宅サーバーのメインCPUはいまだにi7-4770sの第４世代Haswell CPU。。。できるだけ高画質にエンコードすべく低速でエンコードしているため、1時間ドラマを１本エンコードするのに8時間程度かかることもざらにあります。そのため、いつのまにか自宅で動画エンコードするのをあきらめている自分がいました。

 

一方で別のネットワークから完全に切り離されている場所に私が自由に使える普段は特に何も使っていないガチのXeonサーバーがあります。CPUはXeon Gold 6240 x 2、メモリ512GBという家庭用PCとはかけ離れたスペックです。このサーバー上で自宅と同じ設定でエンコードしてみると、並列処理できることもあり、1時間ドラマ１本あたりの処理時間は約20分！そのためあまり大きな声では言えませんが、番組を3か月分ほど撮りためたら、定期的にそこに持ち込み一晩エンコードさせてもらうと朝には全部終わっているという使い方をさせてもらっていました（頻繁には使わないという条件でもちろん許可は取っています）

 

しかしこの状況を一変させたのがコロナです・・

そもそも私の海外出張もなくなっているのですが、このXeonサーバーへのアクセスも原則リモートワークの方針により制限がかかるようになりました。そうなると録画したエンコード待ちTSが溜まっていく一方です。

 

これはなんとかせねば。

自宅サーバーを新しく作り直す選択肢も考えましたが、職業柄AMDのCPUを使うという選択肢はあり得ません。一方で、今更インテル14nmのCPUを購入してこの先数年にわたり使い続ける想像もできませんでした。先日インテルからアナウンスありましたが、7nmのCPU開発には遅れが出ています。初の10nmのデスクトップ向けCPU、Alder Lake-Sは順当にいって来年末に発売になるでしょう。となると今買うべきCPUがありません・・。

 

となると選択肢はハードウェアエンコードに頼るしかありません。

ハードウェアエンコードの選択肢はインテルCPUのQSVかNVIDIA GPUのNVEncの2択かと思います。今使っているi7-4770sはIntel HD Graphics 4600がのっており、QSV H264には対応していますが、H265には非対応です。

ESXiでIntel HD Graphics 4600をパススルーし、VM上でQSV H264をテストしてみましたが最低限のフィルタ処理を入れて60fpsが限界でした。iGPUにはまだ余裕があるためボトルネックはCPUのデコード処理です。フィルタ処理を外すと80fpsまで上がるので、このあたりがi7-4770sのQSVの限界かなと予想します。

この状態でも今までの処理性能が平均で4fps、改善後80fpsのため20倍の改善なのですが見た目での比較でも、SSIMでの比較でも画質は多少ですが悪くなる傾向にありますので、速度は許容範囲ですが、画質には不満があります。

 

そのため今まで消費電力と騒音を理由に選択肢から無くしていたNVIDIA GPUによるハードウェアエンコードの実力を試してみることにしました。そこで自宅サーバーの小型キューブケースにギリギリ入るサイズのMSI GeForce GTX 1660 Ti AERO ITX 6G OCをポチって見ました。明日届く予定です。

 

期待する結果は下記ですが、さてどうなるか検証してみたいと思います。

  1. GPUファンの騒音はVMの電源を切っているときはほとんど気にならない。
  2. GPUエンコード中のファン騒音は仕方が無いと割り切るが、夜寝ているときにしかエンコードしないので、騒音は許容できる範囲内に収まる。
  3. 消費電力は、改善前のSWエンコード時よりは改善後のハードウェアエンコードのほうがトータル電力は少なくなるはず。
  4. エンコードにかかる時間は現状よりも大幅に短縮できるはず。
  5. ソフトウェアエンコードからハードウェアエンコードに変更することで、画質の劣化は想定されるが、H264からH265に変更することでビットレートあたりの画質向上により、許容範囲内に収まる。

 

 

Amazon Hub ロッカーを使ってみたが、役に立たなくて困った話

最近AmazonがAmazon Hub ロッカーなるサービスを始めたのはご存知でしょうか？


マンション等にある宅配ボックスのようなもので、コンビニの近くとか商業ビルの中とかにアマゾンがロッカーを設置して、アマゾンで購入した商品をロッカーに配送して24時間受け取れるようにするサービスですね。


サービス自体はアメリカでは以前からありましたが、それが日本にもやっと展開されたということになります。


私の職場の近くにもロッカーが設置されていることを最近知ったため、ちょっと使ってみようと思い、配送先をロッカーに設定し注文してみました。


ロッカーに配送されるまでの時間は通常と変わらず、メールで配送予定日がいつものように送られてきますが、困ったのはここからです。


本日配達と連絡あったはずですが、配達完了の連絡が来ません。配達状況を確認してみるとロッカーの空きがなく配達できませんでした…

同じことが3日間続きます…

ここでアマゾンのカスタマーセンターに電話してみましたが、配送先を変更することはできないと言われます。


このまま数日間ロッカーへの再配達を繰り返し、それでも空きが発生しなかった場合には注文は自動的にキャンセルされ返金処理が行われますので、再度配送場所を変えるなりして再注文ください、だそうです。


ご迷惑おかけしますということで300円のクーポン券をくれました…

千奈美に注文した商品は1万円ちょっとです。


カスタマーセンターに電話したことで少しは優先度上がるかと期待しましたが、結局その後もロッカーに空きが出ることなく注文はキャンセルされましたww


ロッカーで受け取れるようになるのは非常に便利だと思いますが、使えなければ意味が無いと思いますね。大勢の人が使う以上、空きが無くなるのはある程度仕方がないと思いますが、ロッカーに空きがなかったら配送先を変えることができるようにする柔軟性は必要と感じた初めてのAmazon Hubロッカー体験でした。


まだまだ日本では始まったばかりのサービスです。急ぎに注文には使わないほうが良いかもですw

14年間契約し続けていたAUを解約しました

先日ついに長年使っていたAUを解約してしまいました。大学に入学してから今まで一度の浮気もなく使い続けてはや14年、ですがついにメリットよりもデメリットのほうが多くなってしまったので諦めて解約しました。

携帯は今までiPhone5の時からiPhoneを使っており、今はiPhone7でちょうど来月で丸2年になります。先週新型iPhoneの発表があり、XS/XRがリリースされましたね。本来であれば機種変更を考える時期なのですが、今回はなかなか心惹かれるものがありません。iPhone XRは論外にでかいし、XSの5.8インチもちょっと大きすぎなんですよね。私は携帯で動画そんなに見ないし、画面大きくされてもねぇ。ノッチもかっこ悪いし、指紋認証なくなったし。。

当初はXSに妥協して機種変更しようと思って料金プラン調べたんですが、やっぱり高いよね。携帯本体がじゃなくて、AUに払う通信料が。今私は月々のデータ通信量が6GB前後で、AUのLTEプランを使い、合計で9500円払っています。この内、本体の分割支払いは約2500円です。つまりそれ以外の部分が7000円。同じ条件でiPhone XSにAUで機種変更する月額料金は約10500円、ただし1年間限定の割引1500円含む。1年後には月12000円です。このうち本体の分割支払い額は約3000円。つまり通信費部分は9000円。本体が高いのはAUが悪いわけではないから仕方がないけど、通信費の部分も値上がりしてますよね。通信費の部分で本体側の割引額を確保しようという戦略なんだろうけど、納得が行かない部分が多々あります。私がAUを今までAUを使っていたのは実質支払額が少ないお得な金額でiPhoneの機種変更ができたからと今までずっと使っていたEメールアドレスを残しておきたかったからでした。iPhoneも別に安く使えるわけでもなく、今やキャリアメールなんてほとんど使っていないし、、、なんでAU使っているんだっけという状態になりました（笑）

そこで改めて格安SIMとAUに残った場合を比較してみました。

まずAUに残ってiPhone XSに機種変更した場合、1年間は月10500円、2年目から月12000円とすると、2年間で合計27万円です。

続いて格安SIM、例えばIIJｍioの音声プラン付き６GBプラン＋10分電話かけ放題オプションだと月3300円、XS本体が122000円、アップルケア24600円、合計で22万5800円。格安SIM側のキャンペーン等も考慮すると差額は2年間で5万円。これをやすいと見るか高いと見るかは人それぞれと思います。通信速度とサービス内容を考えても月2000円今までよりも多く払うのはちょっと納得できないかなぁというのが私の今の思いです。

こんなシミュレーションしてみた私ですが、結局iPhone XSは購入せず、S無しのフルモデルチェンジした新型iPhoneを1年待とうという結論に至りました（笑）。 ところでAUの場合多くの人が携帯を24回分割で購入していると思います。勘違いしている人が多いのですが、AUの場合24回分割の支払いが終わったら25ヶ月目に料金が分割代金分安くなるということはありません。機種変更しない場合は、24ヶ月目とほぼ同額の金額を25ヶ月目移行に支払うことになります。これってひどいですよね。私がAUを解約した一番の理由はこれです（笑）機種変更無しに1年待つ場合でも料金が安くならないので、それは損するからものは試しに格安SIMに変えてみようというのがモチベーションですね。格安SIMなら戻るのは比較的簡単なので、1年後お得なプランが出てきていたらAUに戻ることも考えるので、よろしくお願いしますAUさん。