ツナ缶雑記

ぐうたらSEのブログです。主にマイクロソフト系技術を中心に扱います。

Visual Studio サブスクリプションに付属する Azure サブスクリプションが勝手に無効にされた(と思った)話

f:id:masatsuna:20210419115058p:plain

本記事において、悪いのは私であってマイクロソフト社が悪いのではありません。 こんな使い方をしてしまった結果、マイクロソフト社まで問い合わせないと謎が解けなかったよ、という私のダメな記録として残しておきます。

何が起きたか

とある月に、私は Visual Studio サブスクリプションに付属している Azure クレジットを使い切ってしまい、月の途中で無効扱いになってしまいました。 Visual Studio サブスクリプションを契約すると、エディションに応じて Azure のクレジットが付与され、その枠内なら無償で使い放題になります。 この枠を突破してしまうと、 Azure サブスクリプションが無効状態になります。

この無効状態を解除するためには、 Azure サブスクリプションにクレジットカード情報を登録して、制限を解除し課金するように設定するか、 Azure サブスクリプションの月の変わり目まで、再度 Azure サブスクリプションが有効化されるのを待つか、の 2 択です。 私は課金したくなかったので、無効のまま Azure サブスクリプションが再度有効化されるのを待っていました。

待望の月の変わり目がやってきて、 Azure サブスクリプションが再度有効になりました。 もともと無効になってしまったのは、 Cosmos DB の検証をしていて、無償で割り当てられた Azure クレジットを使ってしまっていたからでした。 一刻も早くこの状態をもとに戻さないと、また月の途中で無効状態にされてしまう恐れがありました。

年度頭ということもあって、月の変わり目から 1 日、何も作業できずにいたのですが、翌日、再度 Azure サブスクリプションが無効になった、とのメールが。。。 さすがに 1 日で Azure クレジットを使い切るような設定はしていません。 そして Azure ポータルでトータルコストを見ても、無償枠までまだまだ余裕がある状態でした。

無償枠を上限突破してしまって、 Azure サブスクリプションが無効になるケースは何度も遭遇していますが、今回のパターンは初めてで、何が起こっているのか全く分かりませんでした。

Visual Studio サブスクリプションの状態を確認

とりえあず Visual Studio サブスクリプションんがおかしなことになっていないか確認しました。 過去に何度か社内の管理者がオペミスをして、勝手に私の Visual Studio サブスクリプションを削除されたことがありまして、真っ先に疑いました。

ところが登録状態は問題なく、以下のポータルにログインしても問題なく Visual Studio サブスクリプションは認識されています。

https://my.visualstudio.com/

これで Visual Studio サブスクリプションが犯人である説は消えました。

Azure ポータルから問い合わせてみる

課金関連の問い合わせは、 Azure ポータルから無償で行うことができます。 Azure ポータルの以下のメニューから、問い合わせを起票しました。

f:id:masatsuna:20210419111342p:plain

f:id:masatsuna:20210419111458p:plain

ところが、どうも会話がかみ合いません。 サポート窓口の人が言うには、 Azure DevOps が原因だ、と。 具体的に何が問題になっているかは教えてくれなかったのです。 確かに Azure DevOps は使っていますが、課金されるような使い方をしたつもりは一切ありませんでした。

真犯人は。。。

結論から言うとチームメンバーのオペミスが原因でした。 チームで利用している Azure DevOps 組織は、 Visual Studio サブスクリプションの特典で取得した私の Azure サブスクリプションに対して紐づけられていました。 その Azure DevOps 組織には、チーム内のメンバー数名を管理者として登録していました。 その人が、 Azure DevOps のユーザーを登録する際、 Basic レベルのメンバーを 6 名登録してしまい、私の Azure サブスクリプションに対して課金が発生した、というのが真相でした。

Azure DevOps の課金は、 Visual Studio サブスクリプションで与えられる無償の Azure クレジットを支払いに使うことができません。 そのため、 Azure サブスクリプションに対してリアルな課金が発生します。 しかし、 Azure サブスクリプションにクレジットカードが登録されていなかったためリアルな課金ができず、 Azure クレジットが余っているように見えるのに無効扱いにされてしまったのです。

その後、 Azure ポータルからこの月限定でクレジットカード決済できるように設定し、難を逃れました。 この月限定で課金、というのが設定できるのは非常にうれしいですね。

まとめ

私の視点で見ると、突如 Azure サブスクリプションが無効にされたように見えたため、とても混乱したお話でした。 しかも無効にされた理由が自分では全く把握できなかったんですよね。 Azure DevOps のユーザーの登録状況や、ビルドマシンの使用状況など、課金の発生するような使い方をされていないか、随時確認するようにしないとダメですね。 こんなアホなことやらかすのは私くらいでしょうが、ここに供養しておきます。

ある程度の規模の Azure DevOps を運用するなら、リアル課金できる Azure サブスクリプションに Azure DevOps の課金設定を変更しておかないと怖いですね。 手順は以下に記載がありますので参考までにどうぞ。

docs.microsoft.com

この件でマイクロソフトさんからいくつか聞いたので箇条書きで残しておきます。 ここに示すのは 2021 年 4 月に私が聞いた情報です。 将来変わるかもしれませんし、正しくないかもしれません。 あまり鵜吞みにしないようにしてください。

  • 上記の手順に従って Azure サブスクリプションの変更する場合、変更先の Azure サブスクリプションの Azure AD に、 Azure DevOps 上のユーザーを登録する必要があるが、課金先の Azure サブスクリプションの変更を行った後で、そのユーザーを Azure AD から削除しても問題なく課金はされる( Azure ポータル上 Azure DevOps のリソースが存在すれば、そこが課金対象のサブスクリプションになる)
  • 上記の手順をスキップして、マイクロソフト社に、 Azure DevOps の課金対象の Azure サブスクリプションを変更するよう依頼することはできない(必ず上記のオペレーションでユーザーに実施してもらう)
  • 上記の通り変更する場合も、 Azure DevOps の組織を Azure AD と接続する必要はない
  • Azure DevOps が課金できない状態だと、 Azure DevOps も読み取り専用状態にさせられる(と言われたが、実際にはされていなかったため真偽不明)

Azure Pipelines のビルド環境考察(MS Hosted Agent vs Self Hosted Agent)

f:id:masatsuna:20210318022823p:plain

ついに MS Hosted の利用制限が強化される

Azure DevOps のチームから以下の 2 件のブログポストがありました。

devblogs.microsoft.com

devblogs.microsoft.com

要約すれば以下の 2 点が言われています。

  • パブリックなプロジェクトの場合、 Azure Pipelines の MS Hosted Agent 無償利用枠を使いたいならメールせよ
  • プライベートなプロジェクトの場合、 Azure Pipelines の MS Hosted Agent 無償利用枠を原則自動付与するするが、自動付与されない場合はメールせよ

メールの送付先とか、メールに含める内容については元記事を参照してください。

なぜこんな制限が?

無償でできてしまうせいで、いろいろ悪いことを考える輩がいるようです。 雑に言えばタダでコンピューティングリソースを使えてしまうわけで、暗号解析とか仮想通貨のマイニングとか、そういった目的に無償のマシンを使われていると。 確かにこの半年くらい、 MS Hosted Agent のビルドマシンはキュー待ちがすごい増えた印象があって、こういうことだったんだなーと妙に腹落ちしました。

MS Hosted Agent をどう使うか

個人的には、 MS Hosted Agent を大規模開発では使わないようにしています。 たとえ規模が小さかったとしても、ビルド時間が手元で 40 秒以上かかるようなプロジェクトの場合は Self Hosted Agent にしています。 こういったプロジェクトの場合、単体テストの実行まで含めると、私の体感として 1 回のパイプライン実行に余裕で 5 分くらいかかってきます。 この待ち時間が微妙にストレスを与えるんですよね。

MS Hosted Agent のマシンは Standard_DS2_v2 の VM 上に展開されています。 Standard_DS2_v2 は 2 Core 7 GB メモリのマシンなので、大多数の方がローカル開発で使用しているマシンよりだいぶ貧弱です。 そういった環境を他の Azure Pipelines のユーザーと共用します。 また悪意を持っているかは別として、長時間のワークロードを実行されるケースもあります。 結果として、キューに入ったままなかなかパイプラインが実行されなかったり、ビルドパイプラインの実行にローカルマシンでのビルドと比較して長時間要したり、ということが起こるわけです。

Self Hosted Agent を用意するタイミング

同時開発者数が 10 名を超えてきたあたりから、徐々に MS Hosted Agent を使うのがしんどくなっていくように経験上思います。 以下のような兆候が見られたら、 Self Hosted Agent の導入を検討すると良いと思います。

  • ビルドパイプラインの実行待ちが増えて、キューに滞留する
  • ビルド時間が大幅に長くなり、なかなかビルドパイプラインが終わらない

Azure Pipelines は、 MS Hosted Agent のほうができることが少ないので、 MS Hosted Agent から Self Hosted Agent への移行はほとんど問題なく実施できると思います。 Self Hosted Agent の環境構築が若干めんどくさいですけどね。

ただ、公開プロジェクトで、 MS Hosted Agent を並列実行できる環境だと、ほとんど Self Hosted Agent を使うことはないと思います。 この辺は本当に使い方によるかなーという印象です。 ビルドパイプラインの状態をよく見ながら検討するべきかと思います。

Azure VM Scale Set Agent

ほかの選択肢として Azure VM Scale Set を用いた Agent もあります。 私は仕事でもこれを使ったことはありません。 たぶん今後も使うことはほとんどないと思います。

最終的に最強なのは何か

個人的におすすめするのは、適当なデスクトップマシンを購入して、そいつを Self Hosted Agent として登録することです。 VM のほうが良ければそれでもいいのですが、先述の通り、現実的な値段で物理マシンと同等以上の性能を持つ VM を用意するのは無理です。 であるならば、適当な物理マシンを Self Hosted Agent として使ったほうが、安くて性能も出せます。

ビルドマシンはサーバーである必要もありません。 安い Windows 10 や Ubuntu のマシンで良いのです。 MS Hosted Agent に不満が出てきたら、 Self Hosted Agent をお試ししてみてください。 いろいろなものが劇的に改善されると思います*1

安く済ませたいならこういったミニ PC を Self Hosted Agent として構築するのがおすすめです。


特に Deskmini シリーズはデスクトップ用の CPU ( TDP 65w まで) が使えるのが良いところです。 非常に小さいですし、組み立ても簡単ですよ。

Deskmini に組み込める最強 CPU は Core i9 10900 です。


Core i5 10500 でも十分な性能を発揮してくれると思います。 正直この辺はお値段と相談です。


デスクトップ CPU にこだわりがないのであれば、完成品で販売しているタイプのミニ PC もよいと思います。 最近よく見かけるのはレノボのミニ PC です。


モバイル PC 用の CPU を積んでいるので、プロセッサーのパワーは Deskmini と比較すると劣ると思います。 しかし、貧弱な VM よりはよほどましです。

まとめ

今回は MS Hosted Agent と Self Hosted Agent の使い分けについて個人的に思うことを書いてみました。 Azure VM Scale Set Agent はいつ使う日が来るのだろうか。

*1:あまり使わなくなってしまった古いマシンを登録するのが一番良いと思います。エンタープライズの利用の場合、適当なデスクトップマシンをレンタルするのでも良いと思います。

Hyper-V で画面が表示されない場合の確認項目

f:id:masatsuna:20210314015924p:plain

私自身がはまってしまったので備忘録もかねて書いておきます。

現象

Hyper-V を有効にして、 Windows 10 20H2 の仮想マシンを作成しました。 OS のインストールも完了して、ログインアカウントはホスト OS でも使っている MS アカウントに設定。 そして PIN の設定もして、仮想マシンの起動もできました。 Windows Update を実行し、パッチをあてて再起動したら。。。

f:id:masatsuna:20210314012137p:plain

こんな感じでパスワードの入力画面が出てきません。 現在時刻の表示すら出ていません。 右下の電源アイコンとその左隣のボタンだけ操作できる、そんな感じになってしまいました。

原因

聡明な方はすでにお気づきかと思いますが、原因は PIN の設定をしてしまったことと、 Hyper-V を [拡張セッション] モードで起動してしまったことにあります。 この状態ではログインすらできないので、まずは [拡張セッション] モードを無効にします。

[拡張セッション] の設定は、 [表示] メニュー → [拡張セッション] のチェックを外すことでオフにできます。 この設定をオフにすれば、いつもの時計が表示されるようになります。

f:id:masatsuna:20210314012945p:plain

また通常通り PIN を入力してログインすることができます。

f:id:masatsuna:20210314013242p:plain

拡張セッションを使いたい場合

拡張セッションを使うと、ホスト OS のドライブにアクセスできるようになるので、非常に便利です。 拡張セッションを使いたいのであれば、ゲスト OS 側の設定で、 Windows Hello を無効にしましょう。 PIN を有効にすると Windows Hello が有効になります。 この状態だと拡張セッションが使えません。

ゲスト OS 側で [設定] を開きます。

f:id:masatsuna:20210314013903p:plain

[アカウント] を選択します。

f:id:masatsuna:20210314014030p:plain

[サインイン オプション] のメニューを選択します。 OS インストール時に PIN を設定してしまっている場合、 [Microsoft アカウントWindows Hello サインインを要求する] の項目が以下のようにオンになっていると思いますので、オフに設定します。

f:id:masatsuna:20210314014330p:plain

この状態で、再度 [表示] メニュー → [拡張セッション] のチェックをオンにしてください。 今度は MS アカウントのパスワードを入力するための画面が表示されるはずです。

f:id:masatsuna:20210314014819p:plain

今度は PIN ではなく、 MS アカウントのパスワードを入力してログインしましょう。

.NET Framework ベースのアプリケーションを .NET 5 ベースへと更新サポートするツール(upgrade-assistant)

f:id:masatsuna:20210303121532p:plain

つい先日、 .NET Framework ベースのアプリケーションを .NET 5 に移行するための便利ツールが登場しました。 .NET Blog でも紹介されていました。

devblogs.microsoft.com

今回はこいつを軽く触ってみた感想とか、できること、できないことを軽く整理してみようと思います。 なお今回紹介しているのは、 2020/03/03 時点の最新版に基づく情報です。 本日時点ではプレビュー扱いであるため、今後大幅に変更される可能性もありますので、注意してください。

環境

  • dotnet 5.0.103
  • try-convert 0.7.212201
  • upgrade-assistant 0.2.212405

.NET SDK のインストール

コマンドプロンプトを開いて以下のコマンドを実行します。

dotnet

インストールができていれば dotnet コマンドの使い方が出力されます。 コマンドが見つからない、といったエラーになった場合は、以下のページからインストーラを取得して、導入してください。 導入後は再起動しておいた方が良いです。

dotnet.microsoft.com

try-convert ツールのインストール

以下のコマンドを実行して、 try-convert ツールをインストールします。

dotnet tool install -g try-convert

インストールが正常に完了すると、以下のようなメッセージが出力されます。

次のコマンドを使用してツールを呼び出せます。try-convert
ツール 'try-convert' (バージョン '0.7.212201') が正常にインストールされました。

.NET Upgrade Assistant のインストール

以下のコマンドを実行して、 .NET Upgrade Assistant をインストールします。

dotnet tool install -g upgrade-assistant

インストールが正常に完了すると、以下のようなメッセージが出力されます。

次のコマンドを使用してツールを呼び出せます。upgrade-assistant
ツール 'upgrade-assistant' (バージョン '0.2.212405') が正常にインストールされました。

2020/03/03 現在、どちらのツールもプレビュー版扱いなので、メジャーバージョンは 0 になっていますね。

.NET Upgrade Assistant の実行

ソリューションファイルのあるディレクトリに移動して、以下のコマンドを実行します。

upgrade-assistant <*.sln のファイル名>

実行すると、ソリューションに含まれているプロジェクトの一覧が出力されます。 エントリーポイントに相当するプロジェクトの番号を入力して作業を開始します。

-----------------------------------------------------------------------------------------
- Microsoft .NET Upgrade Assistant v0.2.212405+8e7b4314944e5328780f06f20721a4d6ef9783bb -
-----------------------------------------------------------------------------------------

[09:45:11 INF] MSBuild registered from C:\Program Files\dotnet\sdk\5.0.103\
[09:45:11 INF] Registered 1 extensions:
        Default extension
[09:45:13 INF] Initializing upgrade step Select an entrypoint

Upgrade Steps

1. [Next step] Select an entrypoint
2. Select project to upgrade

Choose a command:
   1. Apply next step (Select an entrypoint)
   2. Skip next step (Select an entrypoint)
   3. See more step details
   4. Configure logging
   5. Exit
> 1
[09:46:58 INF] Applying upgrade step Select an entrypoint
Please select the project you run. We will then analyze the dependencies and identify the recommended order to upgrade projects.
   1. CoreProject
   2. WebProject
   3. WpfProject
> 3
[09:49:06 INF] Upgrade step Select an entrypoint applied successfully
Please press enter to continue...

以降このような形で、出力される選択肢の中から番号を選択して、変換作業を行っていくことになります。 今のところ、以下のような処理が実行できるようです。

1. Back up project
2. Convert project file to SDK style
3. Update TFM
4. Update NuGet packages
5. Add template files
6. Upgrade app config files
    a. Convert Application Settings
    b. Disable unsupported configuration sections
    c. Convert system.web.webPages.razor/pages/namespaces
7. Update C# source
    a. Apply fix for UA0001: ASP.NET Core projects should not reference ASP.NET namespaces
    b. Apply fix for UA0002: HtmlString types should be replaced with Microsoft.AspNetCore.Html.HtmlString
    c. Apply fix for UA0003: ActionResult types should come from the Microsoft.AspNetCore.Mvc namespace
    d. Apply fix for UA0004: Filter types should be used from the Microsoft.AspNetCore.Mvc.Filters namespace
    e. Apply fix for UA0005: Do not use HttpContext.Current
    f. Apply fix for UA0006: HttpContext.DebuggerEnabled should be replaced with System.Diagnostics.Debugger.IsAttached
    g. Apply fix for UA0007: HtmlHelper should be replaced with IHtmlHelper
    h. Apply fix for UA0008: UrlHelper should be replaced with IUrlHelper
    i. Apply fix for UA0009: HelperResult should be replaced with Microsoft.AspNetCore.Mvc.Razor.HelperResult
    j. Apply fix for UA0010: [AllowHtmlAttrubute] should be removed

変換作業が完了したら、アプリケーションコードを手で直して、実行できるように修正していきます。 変換作業が完了しただけの状態だと、コンパイルすら通らない状態になります。 コードの手修正はほぼ必須となります。

できること、できないことがある

このツールを実行すると、ターゲットフレームワーク .NET 5 に設定してくれます。 NuGet パッケージの更新作業もある程度やってくれます。 Program.cs や Startup.cs を生成してくれます。 また Web.config に設定してあった AppSettings の内容を appsettings.json に移してくれます。 他にもいくつか、定型的な変換作業を実施してくれます。 逆に言うと、それ以外のことはできません。 アプリケーションコードがコンパイルできる状態まで更新してくれるわけではありません。 そういう意味で、過度な期待は禁物です。 決して魔法のツールではありません。

このツールは、 .NET Framework のアプリケーションを .NET 5 に持っていくために必要な、最低限の作業をやってくれる印象です。 使いこなすためには、以下のような知識が個人的には必要と思いました。

  • .NET Framework アプリケーションの仕組み
  • もともとのアプリケーションの構造
  • .NET 5 アプリケーションの基本的な仕組み

要するに、わかっている人が使うなら超便利なんですが、わかっていない人が使うとわけわからん、となるように思います。

ASP.NET MVCWPFWindows フォームに対応

公式ドキュメントでは、.NET Framework ベースの ASP.NET MVCWPFWindows フォームアプリケーションを、 .NET 5 ベースに変換できると説明されています。 きっとできることはこれからどんどん増えていくと思います。 今後のアップデートとGAに期待しましょう。

xUnitで単体テストの並列実行をオフにする

f:id:masatsuna:20210303024437p:plain

xUnit を使って C#単体テストを作り、全テストをまとめて実行すると、一部の単体テストが並列実行される様子がわかります。 もう少し正確に言うと、 1 つのテストクラス内のテストは直列実行されますが、異なるテストクラスに配置されているテストは並列実行されます。 このあたりの挙動についてまとめてみようと思います。

環境

テストコレクション

冒頭に述べた挙動は、 xUnit の持つテストコレクションという概念で説明ができます。 テストコレクションは、動画サイトにおける再生リストのようなもので、同一のテストコレクションの中に含まれているテストは、直列実行されるようになっています。 しかし、テストコレクションが異なれば、お互いにテストは並列に実行されるようになっています。

1 つのテストクラス内に含まれるテストメソッドは、すべて同じテストコレクションに含まれます。 特に何も指定しなければ、テストクラス単位でテストコレクションが作成されます。

コードレベルで見ると、以下のように 1 つのテストクラス内にあるテストメソッドは、テストコレクションが同一になるため、順次実行されます。

public class TestClass1
{
    // Test1, Test2 は順次実行(順不同)

    [Fact]
    public void Test1()
    {
        // Do something...
    }

    [Fact]
    public void Test2()
    {
        // Do something...
    }
}

それに対して、以下のようにテストクラスを分割すると、各テストメソッドはテストコレクションが別になるため、並列実行されます。

// Test1, Test2 は並列実行

public class TestClass1
{
    [Fact]
    public void Test1()
    {
        // Do something...
    }
}

public class TestClass2
{
    [Fact]
    public void Test2()
    {
        // Do something...
    }
}

テストを直列実行できるようにする

テストを直列実行するためには、いくつかの方法があります。

テストコレクションをまとめる方法

テストコレクションが 1 つであれば、テストメソッドは直列実行されるようになります。 テストクラスに対して CollectionAttribute を付与することで、テストコレクションを明示的に指定することができます。 CollectionAttribute の引数にテストコレクションの名前を与えることができます。 テストクラスに対して同名のテストコレクションであることをマークすることで、テストコレクションを 1 つにまとめることができます。

[Collection("テストコレクションHoge")]
public class TestClass1
{
    [Fact]
    public void Test1()
    {
        // Do something...
    }
}

[Collection("テストコレクションHoge")]
public class TestClass2
{
    [Fact]
    public void Test2()
    {
        // Do something...
    }
}

このようにテストコレクションをまとめておけば、テストは直列実行されます。

テストクラス単位にテストコレクションが作られないようにする方法

テストクラス単位にテストコレクションが作られてしまう既定の動作を変更することができます。

using Xunit;
[assembly: CollectionBehavior(CollectionBehavior.CollectionPerAssembly)]

このようなコードを追加することで、テストコレクションの単位がアセンブリ単位になります。 こうすることでテストが直列実行されるようになります。

テスト実行のスレッド数を制御する方法

テストが並列実行されるのは、テストランナーが複数のスレッドを起動しているからにすぎません。 なのでスレッドの数を制限することでも、テストが直列実行できます。

using Xunit;
[assembly: CollectionBehavior(MaxParallelThreads = 1)]

この例ではスレッドを 1 つに制限しているので、テストコレクションの単位とは関係なく、テストは直列実行されます。

並列処理を無効に設定する方法

そもそもテストの並列実行機能をオフに設定することもできます。

using Xunit;
[assembly: CollectionBehavior(DisableTestParallelization = true)]

まとめ

xUnit のテスト並列実行についてまとめました。 特にデータベースに依存するようなテストを xUnit で書いていると、こういった問題にぶち当たるかと思います*1。 安易に並列実行をオフにすることは推奨しませんが、いざというケースでは使えるのではないでしょうか。

参考資料

xunit.net

*1:そんなテストコードを xUnit で書くな、という話はもちろんありますけどね。

Windows 10 Enterprise LTSC のサポート期間が 5 年になる

f:id:masatsuna:20210225144332p:plain

Windows 10 Enterprise LTSC のサポート期間が10年から5年に短縮されるという話が出ています。 Windows as a Service という概念が出て、Windows 10 から大幅にサポートライフサイクルの考え方が変わりました。 そんな中、 Windows 10 Entperprise LTSCは、唯一残っていたクラシックなサポートの方式でしたね。 それもついに終わりを迎えるということで、非常に感慨深いです。

blogs.windows.com

実態とは。。。

記事内には以下のような記載があります。

お客様をサポートする中で、LTSC バージョンをインストールしているインフォメーション ワーカー用のデスクトップは、10 年ものライフサイクルは必要ないことがわかりました。テクノロジの変化が激しい現在、10 年も前の製品に最新のエクスペリエンスを期待するのは現実的ではありません。

Windows 10 のサポートライフサイクル短期化によって、 LTSC を希望するお客様の話を結構聞いた記憶があります。 時は流れて、ようやく Windows 10 の更新スピードに、みんなついてこれるようになった、ということなのでしょうか。 実態はよくわかりませんが、日本の環境にもこの話がそのまま当てはまるのか、興味がわくポイントです。

ライフサイクルの短期化

製品ライフサイクルの短期化によって、多分ベンダー側の負担していた保守コストは大幅に減るものと思います。 複数のバージョンを並行して保守していくこと、しかもすごく古いものを保守し続けるのは、手間ばかりかかって全然見合わないのだろうという想像はつきます。 企業努力では片づけられないだろう現場の苦労も想像できてしまいます。 みんなで新しいものを一緒に使おうぜ、という思想は、マクロな視点では生産性を向上させるのだろうと思います。

自分たちの現場を短期化という目線で見たとき、果たしてそんなことができているのか/今後できるのか、漫然とした不安を覚えてしまったのもまた事実です。 いまだに大規模な開発プロジェクトなら年単位で作業することもあります。 .NET 6 とかも LTS 版が 3 年サポートとか言われていて、大規模な開発プロジェクトってどうしてあげればいいのか。。。 ずっと .NET Framework を使い続けるわけにもいかないし。 OSもミドルウェアもどんどん開発・リリースのスピードが上がっているのに、アプリケーションがそれに追従できないというジレンマを感じる方って多いのではないでしょうか。

これからのシステム開発

これからの IT 業界(特にシステムインテグレーションの業界)は、本気でこの問題に取り組んでいかないとまずいことになるだろうと思います。 業界構造や契約のしがらみ、システムの肥大化など、とにかくいろいろなものがスピードを阻害しているんですよね。 それによって前にも後ろにも進めなくなってしまうシステムがどんどん出てくるだろうと思います。

体力のある会社なら、一気にヒト・モノ・カネを投入して、力業で何とかする、ということも可能かもしれません。 しかし、そうではない会社も多くあると思うのです。 そういう会社こそ、今後どうしていくのか、知恵を絞って乗り越えなくてはならないんですが、そうもいかない現実ってありますよね。

まとめでもないまとめ

ただただ現実を憂うだけのポストになってしまいました。 Windows 10 Enterprise LTSC のサポート期間短縮を受けて、特に日本のシステムインテグレーション業界における現状が、本当に怖いなーと思った話でした。

Ryzen CPU で Hyper-V を使う方法

f:id:masatsuna:20210215005450p:plain

Windows 環境で手軽に仮想マシンを使うのであれば、 Hyper-V を使うのが便利だと思います。 Windows に標準で搭載されているのが最大の利点ではないでしょうか。 検証作業とかで、ホストマシンの設定を汚したくないケースに結構活用できます。

今回は Ryzen CPU で Hyper-V を使うための手順を解説します。 Intel CPU の場合と設定する BIOS の項目が異なりますので注意しましょう。

環境

Hyper-V を有効にするためには、 Windows 10 Pro が必要です。 Home エディションでは有効にできないので注意しましょう。

なお BIOS は日本語に設定してあります。 英語版と微妙に違うところがあるかもしれませんが、適宜読み替えてください。

Windows の機能の有効化または無効化

Hyper-V を有効にするためには、 Windows 上で機能を有効に設定する必要があります。 [Windows の機能の有効化または無効化] を検索して実行しましょう。 そして [Hyper-V] の項目にチェックを入れれば有効化できます。

しかし、特に何も設定をせずに Hype-V を有効にしようとすると、 [Hyper-V] > [Hyper-V プラットフォーム] > [Hyper-V Hypervisor] のあたりに以下のようなメッセージが出ていることに気づきます。 f:id:masatsuna:20210214235605p:plain

このようなメッセージが出た場合は、 BIOS で設定を変更します。

BISO 設定を変更する

Hyper-V を有効にするには、 [SVM*1 Mode] を BIOS 上で有効にしなければなりません。 BIOS への入り方はマザーボードの種類によって異なります。 多くの場合は電源投入直後、 Windows の起動前に [Del] キー、 [F1] キー、 [F2] キーあたりを連打することで入れます。 B550 TOMAHAWK の場合(というか、たぶん MSIマザーボードの場合)は [Del] キー連打で入れます。 メーカー製のものはもっと凝った作りになっているケースもあるので、説明書をよく読みましょう。

BIOS に入ることができたら、 [SVM Mode] を有効にします。 MSIBIOS の場合は、以下の手順で有効にできます。

まずモードを [Advanced] に設定します。 [F7] キーを押下すると、 [EZ Mode] と [Advanced] を往来できます。

[OC] メニューを選択し、 [Advanced CPU Configuration] を選択します。 f:id:masatsuna:20210215002007j:plain

[SVM Mode] を選択します。 f:id:masatsuna:20210215002010j:plain

設定値を [無効(Disabled)] から [有効(Enabled)] に変更します。 f:id:masatsuna:20210215002015j:plain

設定が変更できたら [F10] を押下して設定を保存し、再起動しましょう。


再度 Windows の機能の有効化または無効化

設定が正しく実行できていると、 [Windows の機能の有効化または無効化] で Hyper-V の有効化ができるようになっています。 f:id:masatsuna:20210215002401p:plain

[Hyper-V] の項目にチェックを入れると、配下のすべての項目が有効化されます。 そのまま [OK] ボタンを押下して、機能を有効化しましょう。

少々待つと、以下のように再起動を促すダイアログが出ます。 f:id:masatsuna:20210215002815p:plain

再起動後に Hyper-V が利用できるようになります。

*1:Secure Virtual Machine

MSI マザーボードの BIOS を日本語化する

f:id:masatsuna:20210216013017p:plain

MSIBIOS は、日本語表記に対応しています。 メニューの項目は英語のままですが、各項目の説明文や、ちょっとしたところが日本語表記に書き換わります。 設定手順を示しておきます。

環境

  • Ryzen 9 5900X
  • B550 TOMAHAWK

BIOS に入る

まずは BIOS 画面に入ります。 BIOS への入り方はマザーボードの種類によって異なります。 多くの場合は電源投入直後、 Windows の起動前に [Del] キー、 [F1] キー、 [F2] キーあたりを連打することで入れます。 B550 TOMAHAWK の場合(というか、たぶん MSIマザーボードの場合)は [Del] キー連打で入れます。 メーカー製のものはもっと凝った作りになっているケースもあるので、説明書をよく読みましょう。


言語の設定を変更する

BIOS 画面右上の部分に注目してください。 [En] となっている個所をクリックします。

f:id:masatsuna:20210216011538p:plain

すると使用可能な言語の一覧が表示されるので、[日本語] を選択します。

f:id:masatsuna:20210216011614p:plain

うまく設定が終われば、右上の言語の設定箇所が [日] になります。 また左上の曜日表記が日本語に変化している様子も見られます。

f:id:masatsuna:20210216011655p:plain

正常に設定が変更できたら [F10] を押下して保存し、再起動しましょう。

Visual Studio と開発者コマンドプロンプトを統合する(Visual Studio Terminal)

f:id:masatsuna:20210216003932p:plain

Visual Studio 2019 の 16.3 Preview 3 リリースで発表されていた Visual Studio Terminal がいつの間にか GA されていたので紹介します。

Visual Studio Terminal とは何か

Visual Studio Code だと、 IDE の中にコマンドをたたくためのウィンドウが統合されていて、 IDE を 1 つ立ち上げれば、原則他の物を使う必要はない状態を作ることができていました。 しかし、こういった機能は Visual Studio には用意されておらず、別途コマンドプロンプトPowerShell など、 Visual Studio から一度離れて操作しなければなりませんでした。 今の開発ツールは、コマンドラインを用いて操作するものがそれなりに多いので、わざわざ別のツールを立ち上げて操作するのは若干めんどくさい状況にあったと思います。

これを解決するための提案が 2019 年にありました。

https://developercommunity.visualstudio.com/idea/516314/integrated-terminal-in-visual-studio-2019-similar.html

そこから 1 年ほどたって、ようやく GA までやってきた、というのが Visual Studio Terminal です。 スレッドを見る限り、 16.6 で GA されたようです。 ですが、 Visual Studio のリリースノートを見ても何の記載もなく、気づくのが相当遅れてしまいました。

起動してみる

Visual Studio Terminal は、以下の通り [表示] メニュー > [ターミナル] を選択することで起動できます。

f:id:masatsuna:20210215235414p:plain

起動すると、 Visual Studio 内のウィンドウとして、開発者コマンドプロンプトか、開発者用 PowerShell が起動します。

f:id:masatsuna:20210216002332p:plain
開発者コマンドプロンプト

f:id:masatsuna:20210216002448p:plain
開発者用 PowerShell

これで Visual Studio から離れることなく、コマンドライン操作を実行することができるようになります。

超便利

Visual Studio Code と同じレベルで使えるので、 Visual Studio Code で慣れている人は使ってみると良いと思います。 また Visual Studio Terminal は、 Visual Studio に付属する開発者用のコマンドプロンプトPowerShell が起動する点が良いポイントです。 .NET 系の PATH の通っていないツールも、開発者コマンドプロンプトPowerShell ならパス指定なしで実行できます。

これらのツールを起動するためには、わざわざ深いパスにある専用ツールを起動しなければなりませんでした。 しかし Visual Studio Terminal を使えば、これらのツールを IDE から離れずに、ダイレクトに起動することができます。 ウィンドウを消さなければ、次回起動時も自動的に立ち上がってくれます。 個人的に結構お気に入りな機能になっています。

Entity Framework Core でデータベースから DbContext を生成する方法

f:id:masatsuna:20210212012626p:plain

Entity Framework Core を使うと、既存のデータベースから DbContext やテーブルに対応するクラス群を自動生成することができます。 ただし Entity Framework 6 までのように、 GUI による操作方法は提供されておらず、すべてコマンドラインから実行する必要があります。

前提条件

  • .NET Core 3.1
  • SQL Server Local DB
  • Entity Framework Core 5.0.3

事前準備

まずは適当にプロジェクトを作成して、以下 2 つの NuGet パッケージをインストールしましょう。

今回は SQL Server Local DB を使うので、 SQL Server 用の EF Core パッケージをインストールします。 また DB から DbContext を生成するために、 Microsoft.EntityFrameworkCore.Design のパッケージも追加します。

パッケージの追加が完了したら、一度ビルドしておきます。

DbContext とテーブルに対応するクラス群の生成

続いて dotnet ef コマンドを使って、 DbContext とテーブルに対応したクラスを生成します。 コマンドプロンプトを立ち上げて、作成したプロジェクトのルートディレクトリ(*.csproj ファイルがあるディレクトリ)に移動します。 続いて以下のようなコマンドを実行します。

dotnet ef dbcontext scaffold "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=<データベース名>;Integrated Security=True;" Microsoft.EntityFrameworkCore.SqlServer --context <DbContextクラスの名前> --output-dir <DbContextとかの出力先ディレクトリ>

このようにコマンドを実行すると、 --output-dir のオプションに指定したディレクトリに、 DbContext と、テーブルデータを保持するためのクラスが生成されます。 DB への接続文字列などは、環境にあわせて修正してください。

特定のテーブルのみ生成したい場合は、 --table オプションを使用すると対象テーブルを指定することができます。

dotnet ef dbcontext scaffold ~省略~ --table <テーブル名> --table <テーブル名>

dotnet ef コマンドが使えない人

以下のコマンドをたたいて、 Entity Framework Core 用の CLI ツールをインストールしましょう。

dotnet tool install --global dotnet-ef

インストール後に再起動しないと使えないこともあります。 詳細は以下のページに解説があります。

docs.microsoft.com

Entity Framework Core ツールをコマンドラインから更新する方法

f:id:masatsuna:20210212012004p:plain

Entity Framework Core を使っていると以下のようなメッセージによく出くわします。

The Entity Framework tools version '5.0.2' is older than that of the runtime '5.0.3'. Update the tools for the latest features and bug fixes.

こんなメッセージが出たら、 Entity Framework Core のツールをアップデートしましょう。 アップデートはコマンドラインから実行することができます。 グローバルにインストールしている場合、コマンドは以下の通りです。

dotnet tool update --global dotnet-ef

正常に実行できると、以下のようなメッセージが出ます。

ツール 'dotnet-ef' がバージョン '5.0.2' からバージョン '5.0.3' に正常に更新されました。

たまにしかやらないコマンドってすぐ忘れますよね。

PCをRyzen 9 5900Xで組んだ話(電源の選択編)

f:id:masatsuna:20210212011236p:plain

今回で自作 PC のパーツ選定シリーズ最終回となります。 最後に電源ユニットの選択についてさらっと触れていきます。

前回の記事はこちらからどうぞ。

tsuna-can.hateblo.jp

消費電力を見積もる

電源を決めるうえで、最初に行わなければならないのは PC 全体の消費電力を見積もることだと思います。 ここまででパーツ構成が決まっているので、以下のようなツールを用いて、消費電力を見積もりましょう。

PC電源容量計算【2021年最新版】 | BTOパソコンミニ館

電源容量計算(電源電卓)電源の選び方|ドスパラ通販【公式】

そうすると、自分の PC の消費電力の推定値を計算することができます。 私の場合、合計使用量は最大で 450 W 程度であることがわかりました。

電源容量を見積もる

上記のサイトでは、電源容量の推奨値まで勝手に出してくれるのですが、これらのサイトはちょっと大きな値を出しすぎているように思います。 電源容量は、消費電力の 2 倍と計算するのが割と一般的かと思います。 私の場合は 900W ということになります、 しかし、それではさすがに多すぎます。 常時 100% の負荷を PC にかけ続けるわけではありません。 あまりにも大きな容量の電源を選んでしまうと、一番変換効率の良いゾーンを長く使うことができなくなってしまいます。 であるならば、最大の負荷がかかるような使い方をしたときは、変換効率の悪いゾーンで落ちない程度に働いていただいて、普段使いするときになるべくよい変換効率を得られるようにする、というのが基本戦略になります。

もう少しパーツ個別の消費電力に着目すると、いろいろわかることがあると思います。 例えば今回利用する Ryzen 9 5900X ですが、 TDP は 105 W と言いながら、ブーストがかかると 140 W くらいまで消費電力が上がるようです。 GPU についても同様に調べると、 RTX 3070 の最大消費電力は 220 W 程度、 OC している場合は 250 W 程度、となるようです。 最大負荷状態で動かしたとしても、 500 W まで消費することはなさそう、ということがわかります。 多少余裕を持ったとしても、 750 W あれば十分足りると考えました。 また 750 W にしておけば、あまり負荷のかかっていない状況でも、効率のよいゾーンで使ってくれそうです。

それなりに高性能な GPU を搭載しているのであれば、 PC 内で最も電力を食うのは GPU です。 GPU を選ぶ際、どの程度の電源が必要か、という情報が公開されているものもあります。 上記の見積もりをしたうえで、 GPU の仕様書も確認してみると、その確からしさを補強できると思います。

電源のサイズを決める

電源も物理的なサイズに差があります。 購入した PC ケースの仕様をよく読み、適したサイズの電源にまずは絞り込みます。 私は Fractal Design の Define 7 を購入しましたので、 ATX サイズの電源を使用することにしました。

ATX サイズの電源は品ぞろえの幅が最も広いという特徴があります。 ケースが許すのであれば ATX から選ぶことをお勧めします。

電源の SATA ポート、 PCIe ポートの数を確認する

特に電源容量の小さなモデルでは、使用可能な SATA や PCIe の電源ポート数が少なく設定されているため、自分の使いたい機器がすべて接続できるか確認しましょう。

プラグイン対応か否か

安い電源の場合、電源から各種ケーブルが直接はえているものが多いです。 こういった形状の場合、不要なケーブルが PC ケース内で邪魔になるという問題が起きます。 ケース内をすっきりさせたいならプラグイン対応のものをえらぶと良いと思います。

逆にプラグイン対応の電源の場合、差込口の接触が悪くなりがちです。 どちらにも一長一短ありますので、好きなほうを選べばよいとおもいます。

80PLUS 認証の確認

ここまで絞り込んでくると、それなりに商品数を絞り込むことができると思います。 あとは電源の性能を表す認証と価格のバランスを見て、実際に使用する製品を決めればよいと思います。 認証については、大体の場合製品の価格と比例して決まります。 予算と相談しながら決めてしまって問題ないと思います。

なお私はいつも 80Plus Gold の認証を得ているものから選択しています。 80Plus Silver 以下のモデルは確かに安いのですが、数がそれほど多くありません。 逆に 80Plus Platinum 以上のモデルになると、価格が急上昇してしまい、コスパの悪さが目立ちます。 最近の電源の多くが 80Plus Gold を取得していることからも、このあたりがメインストリームとして見られていると思います。

選択肢

私の今回の用途にあう電源として、いくつかよさそうなものを見繕いました。



電源に関しては、あまり冒険したくない思いがありました。 過去に使ったことがあって、各種レビューでの評判も悪くない有名どころを使うつもりで、上記 2 つを対象に考えていました。 そして PC ショップに行ったら、偶然 RM750x が特価で出ていたので、そちらを採用することにしました。

全体のまとめ

ここまで長々と、今回の PC を構築するにあたって、どうやってパーツを選んでいったのか、といったあたりを書いてきました。 最終的に私の構築した PC はこんな構成になりました。

項目 構成
CPU AMD Ryzen 9 5900X
メモリ Corsair Vengeance DDR4 3200MHz 32GB × 2枚
記憶装置(メイン) Samsung 980 PRO 1TB PCIe Gen 4.0
記憶装置(データ領域1) Seagate FireCuda 510 1TB PCIe Gen 3.0
記憶装置(データ領域2) ※ CFD 販売 SATA 2.5インチ SSD 900GB
記憶装置(データ領域3) ※ Crucial CT500MX200 SATA 2.5インチ SSD 500GB
記憶装置(データ領域4) ※ 東芝 MD04ACA200 SATA 3.5インチ HDD 2TB
マザーボード MSI B550 TOMAHAWK
グラフィックボード ASUS DUAL-RTX3070-O8G
CPUクーラー Nocture NH-D15
電源 Corsair RM750x
DVDドライブ ※ LG 製(型番不明)
ケース Fractal Design Define 7

※:前マシンから流用したもの

ここ最近の残業代を突っ込んだ結果、相当に満足いく構成で組み上げることができたと思います。 これからたくさん使いこんでいきたいと思います。

また後日、ベンチマーク結果についても書いていこうと思います。 パーツ選定の話は今回で終了です。

PCをRyzen 9 5900Xで組んだ話(SSDの選択編)

f:id:masatsuna:20210210003353p:plain

前回はメモリの選定について書きました。 今回は SSD について書いていこうと思います。

前回の記事はこちらからどうぞ。

tsuna-can.hateblo.jp

SSD の種類

現在発売されている SSD には、その接続方式として NVMe 接続と、 SATA 接続の 2 種類があります。 マザーボードとの接続方法も、 M.2 スロットに接続する方法と、 SATA のポートに接続する方法の 2 種類があります。 M.2 スロットに接続する場合は、 NVMe 接続と SATA 接続どちらかで接続することになりますが、 SATA のポートに接続する場合は SATA 接続しか使えません。 また M.2 スロットは、必ず NVMe 接続、 SATA 接続、どちらもできるかというとそういうわけでもなく、マザーボードの仕様によってどういう接続方式が使えるかが決まっています*1

さらにややこしいのは、 M.2 スロットに NVMe 接続で接続する場合、 PCIe 3.0 なのか、 PCIe 4.0 なのか、でも差があります。 PCIe 4.0 のほうが新しい規格で、速度も PCIe 3.0 の 2 倍くらい高速です。 どういった SSD が接続できるかはマザーボードの仕様をよく確認しておきましょう。

私の購入した B550 TOMAHAWK は、 M.2 スロットが 2 本装備してあります。 そのうち 1 本は NVMe 接続 PCIe 4.0 / SATA 接続の両対応、もうひとつは NVMe 接続 PCIe 3.0 のみ対応です。 今回のマシンは、 M.2 スロットをフル活用していくつもりでしたので、あまりケチらず十分なスペックのものを選ぶことにしていました。

SSD にも互換リストがある

マザーボードメーカーが公開しているのか調べたことはありませんが、少なくとも MSI はストレージの互換性リストを公開していました。 心配性な私は、メモリと同じようにこの互換性リストの中から製品選定をすることにしました。 互換性リストは以下のページから参照できます。

https://jp.msi.com/Motherboard/support/MAG-B550-TOMAHAWK

メインストレージ(システムドライブ用)の選定

メインストレージに使う SSD は、できる限り高速なものを選んでおいた方が、 OS の起動速度、各種アプリケーションの起動速度を大きく向上してくれます。 そういったこともあり、メインストレージには NVMe 接続 PCIe 4.0 の M.2 スロットを使うことにしました。 速度重視なので、 PCIe 4.0 対応の SSD から選定することにしました。

容量は今使っている PC のストレージ使用量から、 1 TB に決めました。 512 GB でも間に合いそうだったんですが、 SSD なので容量は余裕を持っておいた方が良いかなーという雑な決め方です。 この条件で互換性リストを検索してみると、 8 件まで絞り込むことができました。 あとはメモリの時と同様、型番を価格.comで検索して、日本で入手できそうなものを探します。

最終的に選んだのは超ド定番のこちらの一品でした。


価格はそれなりにしますが、性能に全振りするとやはりこれになるかな、という感想です。

仮想マシンのイメージを保存するストレージの選定

続いて決めたのは仮想マシンのイメージを保存するストレージです。 今までは SATA 接続の 2.5 インチ SSD に格納していたのですが、複数台の仮想マシンを立ち上げるとディスク I/O が明らかにボトルネックになっている様子が見えていました。 そんなこともあり、今回はもうひとつの M.2 スロットを活用してやろうと思いました。

仮想マシンイメージを保存するため、ディスクアクセスの速度がそれなりに欲しいのと、耐久性が高いことが必須の要件となりました。 PCIe 3.0 接続の SSDMSI の互換性リストから抽出し、それらのディスクアクセス速度や、 TBW をもとに絞り込みました。

正直 TBW の値は「参考値」扱いだと思います。 公式に TBW の値を公開していないものは怪しいかもしれません。 しかし、 TBW の値は計測方法がそろっていないと比較できない値なので、 TBW の値だけを見て優劣を決められるようなものではないのかな、と思います。

最終的に選定したストレージはこちらです。


正直どこのものでもよかったのですが、高耐久であることをアピールしていることと、 PCIe 3.0 の性能をしっかり出せていることが選定ポイントになりました。 また B550 TOMAHAWK には、 PCIe 3.0 の M.2 スロットにもヒートシンクが付属しています。 そのため、ヒートシンクの付属しないモデルを選択しました。 あと今まで SeagateSSD を使ったことがなかったので、どんなものか試してみたかった、という好奇心も選定に影響を与えたことは否めません。

今回はここまでです。 次回は電源の選定についてまとめて、このシリーズを締めたいと思います。

*1:とはいえ、これから新しくパーツをそろえるのであれば、 M.2 スロットに SATA 接続するケースはほとんどないと思いますが。

PCをRyzen 9 5900Xで組んだ話(メモリの選択編)

f:id:masatsuna:20210209005304p:plain 前回まででマザーボードと CPU クーラーが決まりました。 今回はそれらに引きずられて決まるメモリについて書こうと思います。

前回の記事はこちらからどうぞ。

tsuna-can.hateblo.jp

容量を決める

メモリの選定にあたって、まず決めなければならないのは容量です。 昨今のブラウザーや各種チャットツールなど、普段使いするアプリケーションも、昔と比べてメモリをバカ食いする仕様のものが増えてきているように思います。 Windows も 64 bit が基本になっていますし、メモリバカ食いの時代はこれからも続くんだろうな、と思います。 なので、大した使い方をしていないのに、メモリが結構ひっ迫しているケースを最近よく見るように思います。

私が少し前まで会社で使っていた PC は、メモリ 8 GB のマシンでした。 Office とかブラウザーとかウィルス対策ソフトとか、常時使うアプリケーションをザーッと起動するだけで、半分くらいメモリを奪われていました。 そこに Visual Studio とか立ち上げようものなら、メモリ使用率 90% 超えが当たり前で、動作ももっさり、という状況でした。 いろいろなところに掛け合って、メモリ 16 GB のマシンをゲットしてから、メモリ不足に陥る問題は解消されました。 それでも常時 10 GB 以上使っているのが普通な感じです。 こんな状況だったので、最低でもメモリは 16 GB 以上必要だろう、と思っていました。

私は自宅のマシンで Hyper-V を多用します。 多い時だと 3 台の仮想マシンを使って、いろいろ勉強したり検証したりしています。 そうなると、ホストマシンが動作するように 16 GB、 3 台の仮想マシンそれぞれに 16 GB 割り当てる、と考えると、合計 64 GB あればよさそうだ、となりました。 Hyper-V には動的メモリ割り当てというメモリ節約のための機能があるにはあるのですが、最低容量を小さくすると処理遅延がひどくて使い物になりません*1。 そうであるなら、初めから 64 GB 用意しておけばいいじゃないか、と思ったわけです。

ほしい容量がわかったら、念のためマザーボードや CPU の仕様も確認しておきましょう。 私の選択した B550 TOMAHAWK ですが、仕様書を確認すると、最大メモリ搭載量は 128 GB となっています。 また Ryzen 9 5900X には最大メモリ容量の仕様について記載がないため、マザーボードの仕様に従うものと思います。 Intel 製 CPU の場合、 CPU にも最大メモリ容量が定められているので、自分の載せたい量が載るか、確認しておきましょう。


動画編集や画像編集のように、メモリを大量消費するアプリケーションを使う場合は、 1 台 16 GB では足りないと思います。 この辺は自分のマシンの使い方を観察して、適した容量を見積もりましょう。 PC パーツはほとんどのケースで「大は小を兼ねる」ので、予算に余裕があるなら多めに積んでおくことを個人的にお勧めします。

メモリの枚数を決める

私の選択した B550 TOMAHAWK には、メモリスロットが 4 スロット搭載されています。 64 GB のメモリを搭載するとして、メモリの載せ方には以下の 2 つの選択肢があります。

  • 16 GB のメモリを 4 本
  • 32 GB のメモリを 2 本

Ryzen CPU で組むのであれば、メモリの本数は 2 本を基本線にした方が良いと思います。 Ryzen CPU はメモリの本数を増やすと、メモリの動作クロックを下げなければなりません。 もちろんオーバークロックさせて動かすこともできるでしょうが、安定性は 2 本のほうが上になります。 逆に 1 本にしてしまうと、それはそれで性能低下を招くので、原則 2 本で考えておけばよいと思います。

メモリの動作クロックを考える

ここまでで 32 GB × 2 本という構成が決まりました。 次に決めるのは、このメモリの動作クロックです。 Ryzen CPU の場合、メモリの動作クロックを高めることで、それなりの性能向上が見込めます。 であるならば、製品保証の範囲内で、できる限り高速なものを選択したい、と考えました。

Ryzen Zen3 CPUの場合、メモリを 2 枚さしたときは DDR4-3200 で動作します。 これを超えた場合はオーバークロック扱いになります。 私は原則オーバークロックせずに使いたかったので、 DDR4-3200 をターゲットとすることにしました。

マザーボードのメモリ対応表を確認する

あとは好きなメモリを選べばよいのですが、安心安全なメモリを選びたいなら、マザーボードメーカーの出している対応メモリリストを確認してみましょう。 B550 TOMAHAWK の場合は、 MSI のサポートページに対応メモリの一覧が掲載されています。

2020/02/06 現在の確認方法を書いておきます。 まずは以下のページに行きましょう。

https://jp.msi.com/Motherboard/support/MAG-B550-TOMAHAWK

左側のメニューで [互換性] を選択します。

f:id:masatsuna:20210206105133p:plain

上部のメニューから [Memory By RX-5xxx] を選択します*2

f:id:masatsuna:20210206105230p:plain

すると、マザーボードの対応しているメモリの一覧が表示されます。

f:id:masatsuna:20210206105443p:plain

このメモリリストの中から、先ほど決めた要件にあうメモリを探しましょう。 とんでもない量が掲載されているので、 Excel とかを使ってうまいことフィルタリングすることをお勧めします。

さて、私の場合は 32 GB × 2、 DDR4-3200 が要件ですので、これにあうものを実際に探してみます。 [Size] の列には 1 枚あたりのメモリ容量が載っているので、ここが [32GB] となっているものに絞り込みます。

続いてクロックでも絞り込みます。 [SPD Speed] の列にはメモリをさしたとき、デフォルトで適用されるクロックが書いてあります。 どうせ後で設定変更するので、この値の大小はあまり気にしなくてよいと思います。 絞り込みが必要なのは [RAM Speed] と [Supported Speeed] です。 今回は DDR4-3200 で動かしたいので、ここに書かれているクロックが 3200 MHz 以上になっているものを抽出します。 2020/02/06 現在、ここまでやると 32 個まで絞り込めました。

ここからは機械的にできない作業になってしまいます。 今回は 2 枚組、合計 64 GB のメモリが欲しいので、型番を眺めて明らかに違いそうなものを除外します。 例えば Hyper-X のメモリは、以下のようなものが見つかります。

  • HX432C16FB3/32
  • HX432C16FB3K2/64
  • HX432C16FB3K4/128

末尾の数字に注目すると、それぞれ上から順に 1 枚組、 2 枚組、 4 枚組であることがわかります。 他のメーカーでも、型番にメモリの総容量を含めているものが結構あるので、自分の欲しい枚数のものだけに型番からある程度絞り込んでしまいましょう。 型番からは想像できないものは、無理に絞り込まなくてよいと思います。 2020/02/06 現在、この作業を行うと 17 個まで絞り込めました。

CPU クーラー、 PC ケースからメモリの最大高を計算する

近年のメモリは、ヒートシンクがついていたり、 RGB でピカピカしたり、いろいろと付属物がくっついているものがあると思います。 こういったメモリは高さが結構あります。 大きめの CPU クーラーを使う場合は、メモリの上空に CPU クーラーのファン部分が張り出してきます。 そうなると、大型のメモリでは CPU クーラーのファンと干渉してしまうことがあります。

今回私が導入する Nocture の NH-D15 の場合、公式サイトにメモリのサイズに関する記載があります。

noctua.at

上記のページ内を参照すると、 CPU クーラーの高さ 165 mm に収めたいのであれば、メモリの高さは 32 mm 以内に収めなければなりません。 もちろんこれより高さのあるメモリを使うこともできますが、その分ファンを上方向にずらして取り付けなければなりません。 そうすると、 CPU ファンの高さが仕様書よりも高くなってしまいます。

PC ケースに記載のある CPU クーラーの最大の高さから、搭載可能なメモリの高さをまずは求めましょう。 FlactalDesign Define 7 は、 CPUクーラーの高さ 185 mm まで搭載可能となっています。 多少余裕をもって 180 mm までに収めて、メモリと CPU ファンの間にも 3 mm 程度の余裕を持たせようとすると、メモリの最大高はこのようになります。

32 mm + ( 180 mm - 165 mm - 3 mm) = 44 mm

国内流通品の確認とメモリの高さの確認

次に確認するのは日本国内で入手できるかどうかです。 これは型番で価格.com を検索すれば、入手可能かどうかある程度判断できます。 PC パーツを扱っているショップはほとんど価格.com と連携しているので、ここで型番を検索して出てこなければ、日本で入手できないと判断してしまってよいと思います。

入手できそうなものについては、メモリの高さを確認しておきましょう。 今回はパソコンショップ Ark の通販サイトが一番調査に役立ちました。 公式サイトに記載のないメモリの高さの情報が載っているので本当にありがたいです。

www.ark-pc.co.jp

リストアップしたものの中から、高さが 44 mm 以内のもので絞り込みます。 2021/02/06 現在、 3 件まで絞り込みができました。

製品選定

適合するものの中から、価格とスペックを見比べて製品を決めていきましょう。 最終候補に残ったのは以下の 3 点でした。



kakaku.com

キングストンのメモリは Amazon では完売しているようです。

私の場合、メモリは DDR4-3200 をターゲットにしていたので、 3600 MHz 動作のメモリは過剰スペックでした。 当然選別品でしょうから、同型の Corsair のモデルより 8,000 円近く高かったです。

Corsair とキングストンのメモリでは、性能差はほとんどないのに、キングストンのメモリのほうが約 7,000 円高かったです。 そんなこともあり、最終的には超定番の「CMK64GX4M2C3200C16」を採用することとしました。

今回はここまでです。 次回は SSD の選定について書きたいと思います。

*1:たぶん一時的に大容量のメモリを割り当てる用途だと思います。メモリサイズを極端に小さく保つためのものではない印象です。

*2:たぶん「RX-5xxx」は「Ryzen 5###X」という意味なんだと思う。

PCをRyzen 9 5900Xで組んだ話(CPUクーラーの選択編)

f:id:masatsuna:20210202161919p:plain

前回までで CPU 、 PC ケース、マザーボードなど、 PC の主要な部品を選定した話を書きました。 今回は CPU クーラー選定について書こうと思います。

前回の記事はこちらからどうぞ。

tsuna-can.hateblo.jp

CPU クーラーの種類

CPU クーラーにはいくつかの種類があります。 一般的な用途の PC で使われているものに限定すると、以下のような種類があります。

  • 空冷
    • トップフロー型
    • サイドフロー型
  • 水冷
    • 簡易水冷
    • 本格水冷(本記事では一切触れません)

それぞれがどういったものなのか、という話はここではあまり触れません。 こういった種類の中から、自分に適したものを選定する必要があります。

公式サイトお墨付きの製品を探す

AMDRyzen デスクトップ CPU でおすすめの空冷/簡易水冷の CPU クーラーリストを公開しています。 ここに掲載されているものから選定すれば、大外れすることはないと思います。

www.amd.com

私もこのリストを非常に参考にしました。

PC ケースとの相性を考える

CPU クーラー選定にあたって、必ず確認しておきたいのが PC ケースとの相性問題です。 空冷クーラーの場合、ハイパフォーマンスで発熱の大きな CPU を対象とした製品は、大型になっていることが普通です。 またハイパフォーマンスな空冷クーラーはサイドフロー型のものしかなく、特に高さ方向に対して PC ケースと干渉しやすくなります。 簡易水冷クーラーの場合、ラジエーターのサイズが問題となります。 一部の粗悪な品を除いて、ラジエーターサイズが大きくなればなるほど冷却性能が上がります。 発熱を抑えたいならできる限り大きなラジエーターのついた簡易水冷クーラーを選択したくなります。 しかしながら、 PC ケースに入らないか、入ったとしても無理やり押し込めるような形になることもあるので注意が必要です。

PC ケースにどのようなクーラーが入るかは、 PC ケースの説明書か、製品紹介ページにたいていの場合記載があります。 例えば Fractal Design の Era ITX という小型 PC ケースの場合、以下のような記載が公式サイトにありました。

f:id:masatsuna:20210202155142p:plain

このような情報と、 CPU クーラーの仕様を見比べて、どれが良いかを検討します。

空冷 vs 簡易水冷

個人的に簡易水冷のことをあまり信頼していません。 耐用年数も 3 年程度が目安となるようなので、私のように長々同じマシンを使い続けるような人にはあまり向きません。

何より怖いのは水漏れです。 水漏れしてしまうと、周辺の部品を巻き込んでしまうことも考えられるので、ちょっとした肝試しになってしまいます。 そんなこともあり、空冷クーラーのみで考えました。

空冷クーラーの選定

Ryzen 9 5900X は、その前世代の Ryzen 9 3900X と同程度の発熱であると言われていました。 そういった情報から、 Ryzen 9 3900X を十分に冷却できる空冷 CPU クーラーを探しました。 いろいろ検索してみると、使い方にもよりますが、空冷 CPU クーラーで十分に冷やしきることができる、というレビューをよく見かけました。 各種レビューで使用されているクーラーもそこまで大型のものでなくとも問題ないようです。

ですが、私はめちゃくちゃ心配性なのです。 PC ケースとの相性を考えると、どんなに大きな空冷 CPU クーラーであっても、問題なく取り付けできることが分かっています。 そうであるなら、空冷最強の CPU クーラーをつけてやろうではないかということで、以下の 2 つに絞り込みました。



2021 年現在、空冷 CPU クーラー最強の座を競い合う 2 台です。 冷却性能の面だけで言えば、両者の間にそれほど大きな差はないと言えそうでした。 様々なレビュー結果を見る限り、若干 ASSASSIN iii のほうが強そう、といったところです。

しかしながら、私は最終的に Nocture の NH-D15 を選択しました。 選定の理由は静音性です。 クーラーのぶん回る音はあまり好きではありません。 冷却性能に大きな差がないなら静かな方を選ぼう、となったわけです。

CPU クーラーには対応する最大 TDP が書いてあることもある

例えば ASSASSIN iii は、公式サイトを見ると最大 TDP 280W まで対応、と書かれています。 Ryzen 9 5900X の TDP は 105W ですが、ブーストがかかったときはおおよそ 210W くらいまで上昇するという検証結果が某サイトには載っていました。 そう考えると、 ASSASSIN iii の 280W という数字は十分に余裕があると言えそうです。

このように、 CPU の消費する電力から、 CPU クーラーを選択するという方法もあることだけ書いておこうと思います。 すべての CPU クーラーにこういった表示があるわけではないので、あくまで参考程度にされると良いと思います。

CPU グリスを選ぶ

ついでに CPU グリスの選定の話も書いておきます。

私の CPU グリス選定ポイントは、高耐久かつ高性能であることです。 ほかにも塗りやすさとか、人によっていろいろな評価軸があると思います。 ですが私は PC のメンテナンスに時間をかけたくないのです。 ホコリ掃除くらいで日々のメンテナンスは済ませたい、 CPU グリスの塗り直しはできる限りしたくない(スッポン怖いし)。

そんなことをテーマにいろいろ検索していたら、以下の製品が見つかりました。


たぶんあんまり人気がないです。。。 でも私のような「ものぐさ」タイプにはぴったりのコンセプトを持ったグリスでした。

塗りやすさですが、レビューにあるほど塗りにくさは感じませんでした。 確かにちょっと固い感じはしましたし、あまり伸びもよくなかったです。 ですが、 CPU 周辺をマスキングテープで養生して、そこそこ強度のあるクレジットカードみたいな大型のプラスチックカードでのばすと、結構きれいに塗れました。 CPU グリスに付属してくるヘラみたいな小さなやつより、期限切れのクレジットカードとかを使って伸ばした方がよいと思います。

というわけで今回はここまで。 次回はメモリの選定について書こうと思います。