ツナ缶雑記

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

PCをRyzen 9 5900Xで組んだ話(マザーボードの選択編)

f:id:masatsuna:20210202150840p:plain

前回はチップセットにB550をなぜ選んだか、といったあたりまで書きました。 今回はB550チップセットを搭載する様々なマザーボードの中から、何をどのように選択したのか、書いていこうと思います。

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

tsuna-can.hateblo.jp

マザーボードの選択手順

マザーボードを選定しようとすると、その数の多さや仕様の分かりにくさ、差異がどこにあるのかわからない、などなど、いくつも壁が出てくると思います。 なので、まずは種類を大きく絞り込めるポイントから順に選んでいきましょう。

WiFi 接続の有無

まず考えておいたほうが良いのは、ネットワークへの接続方式を決めることでしょう。 WiFi でネットワークに接続するなら、 WiFi 機能を搭載したマザーボードを選択したほうが良いと思います。 私は有線 LAN 信者なので、 WiFi 接続の機能は不要でした。 逆に有線 LAN が強化されているモデルのほうが嬉しいこともあり、2.5Giga LAN ポートを搭載しているモデルから選ぶことにしました。

WiFi が搭載されているモデルだと、 Bluetooth も一緒にくっついてくるのが良いところです。 Bluetooth 接続したい機器があるなら、有線 LAN 接続するにしても、 WiFi 搭載モデルを選択したほうが良いと思います。

PC ケースのサイズを確認する

続いてフォームファクターも決めましょう。 フォームファクターはマザーボードのサイズを表すもので、 PC ケースを決めると自然と使えるものが決まります。

PC ケースの選定についてはこちらの記事で紹介ています。 PCをRyzen 9 5900Xで組んだ話(CPUとケースの選択編) - ツナ缶雑記

私の採用したFlactal Design Define 7は、どんなサイズのものでも搭載可能です。 逆に言えば、わざわざ小さいサイズのマザーボードを選択する理由はありません。 そんなことから、 ATX サイズのものから選択することにしました。

小さなサイズのマザーボードは、小さなケースに収めるために使うもの、というのが一般的な認識だと思います。 マザーボードのサイズが小さくなると、どうしても拡張性が少なくなります。 将来やりたいことが出てきたときに、拡張できない、という事態になりかねません。 なので、 ATX サイズのマザーボードが入るケースなら、 ATX を選んでおくのが無難です*1

ここまでの 2 つの要素が決まったら、価格.com を活用してマザーボードを絞り込みましょう。 ATX × WiFi ありのモデルであれば、 10 枚くらいまで絞り込めます。

PC ケースのフロントパネルを確認する

続いて「必要最低限の機能」を満たしているマザーボードをさらに絞り込んでいきます。 必要最低限の機能が何かと言えば、私は PC ケースのフロントパネルについている端子群だと思っています。

私の採用したFlactal Design Define 7 には、フロントパネルに以下のものが実装されていました。

  • USB 3.1 Gen 2 Type-C × 1
  • USB 3.0 × 2
  • USB 2.0 × 2
  • オーディオI/O(ヘッドホン、マイク)
  • 電源ボタン
  • リセットボタン
  • 電源LED

これらの端子が使えるマザーボードは何か、先ほど絞り込んだリストからさらに絞り込んでいきます。 電源ボタン、リセットボタン、電源LEDについては、どんなマザーボードにも付属している機能なので無視しましょう。 差異が出てくるのはUSBのポート類です。 今回のケースの場合、 USB 3.1 Gen 2 Type-C が肝になりました。 B550 マザーボードでは、フロントパネル用の USB 3.1 Gen 2 Type-C がないマザーボードがあるため、まずはそれらを除外してしまいます。

価格.com ではリア側の USB 端子については絞り込みができますが、フロントパネル用の端子については絞り込みできません。 ですので、絞り込んだマザーボードの製品仕様をひとつひとつ調べ上げて、使いたいフロントパネル用のポートが準備されているか調査します。

メーカーのページで、以下のような USB ポートの実装数を確認していきます。 例えば超定番の TUF GAMING B550-PLUS は、フロントパネル用の USB Type-C ポートがありません。

f:id:masatsuna:20210202011052p:plain
ASUS TUF GAMING B550-PLUS の USB ポート

MSI MPG B550 GAMING PLUS だと USB Type-C のポートがあることを確認できます。

f:id:masatsuna:20210202011738p:plain
MSI MPG B550 GAMING PLUS の USB ポート

BIOS Flushback の有無

今回地味に重要視したポイントが BIOS Flushback の有無です。 RyzenBIOS は安定しない、特に初期のころは起動すらしないケースがある、といろいろ脅しのような文言をたくさん見かけていたので、 PC が起動できなくても BIOS の更新ができる機能を入れておこうと思いました。 メーカーによっては上位機種しか BISO Flushback に対応していないことがあり、しっかりと確認しておいたほうが良いと思います。

M.2 SSD の搭載可能数

ATX サイズの B550 マザーボードの場合、 M.2 SSD が 2 本以上搭載できるモデルが多数です。 今回私は M.2 SSD を 2 つ搭載する予定でした。 そんなことから、 2 本の M.2 SSD を搭載でき、ヒートシンクが両方のポートに付属しているものを探しました。 自前でヒートシンクをつけてもよいのでしょうが、その分余計な出費になりますからね。

人によっては SATA ポートの数も確認

SSD、HDD、ディスクドライブなど、 SATA 接続の機器を大量に使う場合は、 SATA のポート数も確認しておきましょう。 私の場合は SSD が 2 つ、HDD が 1 つ、ディスクドライブが 1 つで、合計4ポート以上必要でした。 ほとんどのマザーボードは 4 つ以上の SATA 端子を備えているため問題なかったのですが、多少空きがあったほうが将来性もあります。 この辺は必要最小限で考えるか、将来性をとるか、個人の判断によるところが大きいと思います。

また中には M.2 SSD を 2 本搭載すると SATA ポートの一部が無効になる仕様のマザーボードもあります。 特に SATA 接続の機器をたくさん搭載したい場合は、マザーボードの仕様書に細かく書いてあるので、よく確認されるとよいと思います。

MSI MAG B550 TOMAHAWK を選択

最終的に私は MSI の MAG B550 TOMAHAWK を選択しました。


ここまで上げてきた様々な条件をクリアし、最も安価なマザーボードを選択しました。 価格が高くなると、電源周りの機能が充実してきて、オーバークロックしたときに安定する、といったメリットが出てきます。 しかし、通常利用の範囲なら、ぶっちゃけ電源周りはそんなに気にしなくても問題ありません。 そもそも MAG B550 TOMAHAWK は電源周りの機能が価格の割に充実しているのですが。。。

また価格の高いマザーボードにしたからと言って、 PC の処理性能が上がる、といったことは一切ありません。 ガンガンオーバークロックしたいなら意味はありますが、私はそんなことしないので。

PCIe は万能説

ここまであーだこーだ書いてきましたが、実は PCIe のポートがあれば大体のことが解決できるという話もあります。 例えば USB Type-C のポートなら以下のような製品を使えば、マザーボードにポートが直接なくても問題ありません。


PCIe がたくさんあるというのは、拡張性という意味で意味があることなんだよな、と思います。 とはいえ、最初からこういったものに頼らない構成にしたほうが良いとは思いますが。

今回はこの辺まで。 次回はCPUクーラーの選定について書こうかと思います。

*1:もちろん小さいサイズを選ぶのも自由ですし、拡張性は犠牲になりますが、それ以外の問題はありません。

PCをRyzen 9 5900Xで組んだ話(X570 or B550 or A520の選択編)

f:id:masatsuna:20210127011651p:plain

前回まででCPUとPCケース、グラフィックボードを選ぶところまで書きました。 今回からはマザーボードをどのようにして選んだかを書いていこうと思います。 マザーボードは本当にいろいろなことを考えて決めたので、何回かに分けて書こうかなーと思います。 手始めに、チップセットの選択のあたりから書いていきます。

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

tsuna-can.hateblo.jp

チップセットを選ぶ

マザーボードを選ぶにあたって、最初に決めなければならないのはチップセットです。 通常CPUを選ぶと、対応したチップセットというのが決まってくるので、その中からどれを選択するか、ということになります。

Ryzen 5000番台で使えるチップセットは、現状X570、B550、A520の3種類があります。 ざっくりいうとX570がハイエンド、B550がミドルクラス、A520がローエンドです。 何が違うかというと、X570は拡張性に優れていて、PCIeの実装数が多くなっています。 なので、PCIeの拡張カードをたくさん使う人はX570を選択することになると思います。 またX570は、PCIe 4.0に対応したスロットが多いという特徴もあります。 PCIe 4.0の機器をたくさん接続したい場合もX570を選択することになると思います。

A520はPCIe 4.0に対応していません。 なのでPCIe 4.0を使いたいなら除外することになります。 B550はそのちょうど中間に位置していて、拡張性はそこまで高くないけど、一般用途ならPCIe 4.0も必要十分な量がある、というものです。 X570と比較するとPCIe 4.0で接続できる機器の数が少なくなっています。

私の場合、グラフィックボードにPCIe 4.0接続が可能なものを選定したので、A520を選択する理由は価格以外にほぼない感じでした。 6年ぶりにPCを新しくすることもあって、無駄にケチらずX570かB550を選択することにしました。

X570 vs B550

結論から言うと、私はB550を選択しました。 B550を選択した理由はいくつかあります。

チップセットの冷却ファンの有無

X570チップセットは、チップセット自体の発熱が大きいようで、マザーボードチップセットを冷却するためのファンが搭載されたモデルが多数ありました。 最近はファンレスタイプのものも出てきているようですが、圧倒的に数は少ないです。 このファンなんですが、径が小さく、回るとそれなりに騒音を発生させるようです。 またメカ部分の存在は壊れやすさにもつながります。 長く使いたいというニーズに対して、B550のファンレス仕様が非常にうれしく感じました。

m.2スロットに何をどれだけつなぐか

X570のマザーボードの場合、PCIe 4.0に対応したm.2スロットが2本ついているものが多いです それに対してB550の物は、PCIe 4.0対応は1つしかなく、m.2スロットが複数ある場合は、その1つを除いてPCIe 3.0での接続になります。 すなわち、PCIe 4.0に対応したm.2を何本使うかによって、どちらを選択するかが決まってしまいます。

現状のPCIe 4.0対応のm.2 SSDは、かなりお高いです。 もちろん安いものもあるにはありますが、そういった製品は性能面でPCIe 3.0のものと大差ないレベルであり、わざわざPCIe 4.0対応品を購入する理由が乏しいと思います。

こんなこともあって、私はPCIe 4.0対応のSSDを複数導入する考えはありませんでした。 システムドライブにはPCIe 4.0を持ってくるつもりでしたが、データドライブはそこまで早くなくてよいかなと。 X570は私にとってオーバースペックであるように思いました。

設計の新しさ

実はX570チップセットは、B550チップセットの約1年前にリリースされています。 そのため、それらのチップセットを搭載したマザーボードも、同様に1年ほどリリース時期に差があります。 1年の違いは、マザーボードの設計の新しさと、品質の向上につながったと言われています。

価格

X570はハイエンド、B550はミドルクラス、ということを書きましたが、それはそのまま価格にも反映されています。 X570を搭載するマザーボードのほうが、ざっくり5,000円~10,000円くらいお高くなっています。 マザーボードによる性能差はほとんどないと言われています。 すなわち、この価格差は拡張性や、PCIeのバージョンの差など、性能とは異なるところにあらわれます。 すなわち、この差を5,000円~10,000円余計に出して買うのかどうか、ということになります。

電源周りや冷却機構などは、実はX570とB550でそれほど大きな違いはないようです。 どちらのチップセットも、様々なグレードのマザーボードがリリースされています。 電源周りだけ強化したいのであれば、無理にX570を選ばずとも、B550の上位モデルを選べばよいと思います。

今回はこの辺まで。 次回は数々のB550搭載マザーボードから、どうやって製品選定を行ったのか、書こうと思います。

PCをRyzen 9 5900Xで組んだ話(グラフィックボードの選択編)

f:id:masatsuna:20210126003333p:plain

前回はCPUとPCケースを選ぶところまで書きました。 今回はグラフィックボードをどのようにして選んだか、といったあたりを書いていこうと思います。

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

tsuna-can.hateblo.jp

メーカーを選ぶ

Ryzen 5900Xは、CPU自体にグラフィックボードが付属していません。 そのため、グラフィックボードを別途用意しなければなりません。 現在世の中に出ているグラフィックボードは、主にAMDの開発しているRadeonNVIDIAの開発しているGeForceという大きく2つの種類があります。 これらのGPUを使って、各社が様々な冷却機構を実装したグラフィックボードを作り、世に送り出しています。 なので、まずはRadeonなのか、GeForceなのか、これを選択しなければなりません。

Ryzen 5900XはAMDが提供するCPUなので、同一メーカーのだすRadeonのほうが良いかなーと当初は思っていました。 しかも、Radeon 6000番台とRyzen 5000番台、500系チップセットをあわせて使ったときに、Smart Access Memoryなる高速化機構が使えるとか、いろいろアドバンテージがあるように見えていました。

ですが、最終的に選んだのはGeForceでした。 最大の理由は信頼性です。 Radeonに限らず、AMDって出始めのころの安定性、信頼性が悪い印象がありました。 自作PCならトラブルはつきものですが、無駄に時間を浪費するのはうれしくないです。 事実Radeon 6000番台のリリース後はドライバーの不具合とかいろいろささやかれていたりして、メインマシンとして使うのに不安がありました。

もうひとつの理由が入手性です。 Radeonを選ぶなら6000番台かなーと思っていたのですが、いざリリースされてみたら全く市場に出回っていません。 初回ロット以降ほとんど入荷情報を見かけませんでした。

というわけで、GeForceを選択することとなりました、

型番を選ぶ

GeForceを選んだとして、どの型番を選ぶか、実は最後の最後まで迷いました。 今回はRyzen 5900Xを使うということで、PCIe 4.0が使えます。 まずはPCIe 4.0が使えるもの、という前提で、型番を選んでみました。

GeForce系でPCIe 4.0に対応しているのは2020年後半にリリースされたRTX 3000番台の物たちです。 私が組み立てた2020年末の時点では、RTX 3090、3080、3070、3060Tiの4種類がリリースされていました。 これらの中から選ぶことにしました。

私は今までPCゲームをほとんどやってきていません。 今後は時間ができたらPCゲームも体験してみたいなー、次のファイナルファンタジーはPCでやってみようかなー、といった感じです。 なのでRTX 3060Tiで十分だし、値段が安ければRTX 3070でもいいか(年末めっちゃ頑張って働いたからご褒美!)と思っていました。

本当ならここで、同じRTX 3060Ti、RTX 3070の中でも、メーカーとかブーストクロックの違いとかで、製品を選ぶべきなんだと思います。 ですが、2020年末は入手性も悪化していて、そもそもほしいものが手に入る状況ではありませんでした。 そして、同じRTX 3060Ti同士なら、オーバークロックされていてもたいして変わらんだろ、という思いもありました。

そんな私は年末年始のセールでいい感じのが出ないかずーっと監視していました。 そうしたら、出てきましたよ。 パソコン工房さん。

店舗限定 新春初売り特価販売チラシ|パソコン工房店舗情報

年始の初売りセールでRTX 3060Ti(MSI RTX 3060Ti TWIN FAN OC)が税込みで5万円切ってました。 というわけで、こいつをメインターゲットに据えることにしました。

年始セールで買ったものは。。。

ということで、元旦からパソコン工房さんの通販ページに張り付いて、お目当てのものを購入すべく準備。

結果、こちらを購入しました。


はい、RTX 3070です。 簡単に言うと、争奪戦に敗れました。。。 その後ダメもとでRTX 3070をぽちったら、買えてしまったと。 税込み約66,000円。 RTX 3070にしてはそこそこ安いけど、メインターゲットと比較すると高い。 あきらめよう、これで快適にゲームできる(時間あれば)。 ということで自分を納得させたのでした。

その他の選ぶポイント

私は割と雑な感じで製品を選んでしまいましたが、これができた理由に、PCケースに大型のものを選択したことがあります。 小型のケースの場合、グラフィックボードが入らないことがあるので、ケースの説明書をよく読んで、入るサイズなのか確認しましょう。 特に高性能なグラフィックボードは想像以上にでかいです。 長さはもちろんのこと、高さも注意して確認しましょう*1

また厚みも注意しましょう。 小さいサイズのマザーボードを選ぶ場合、それにあわせてケースを小さくすると、グラフィックボードの厚みが収まりきらないことがあるようです。 RTX 3070以上の製品の場合、2スロットでは収まらないものが多いようです。

そして最後に、端子の種類を必ず確認しましょう。 最近のグラフィックボードは、Display Portが3つ、HDMIが1つ、という組み合わせが良く見られます。 自分の使いたい端子がついているか、不足していないかを確認しておくと良いと思います。

後日談

2021年1月末になって、急激にグラフィックボードとかの値上げが続いていますね。 私が買ったモデルは、一時75,000円くらいまで下がったものの、本日は80,000円近くの値段がついています。 そう考えると、年始に購入した値段は相当にお買い得だったようです。 いずれにせよ、この値段を即決できるレベルまで身を粉にして働いておいてよかった(いや良くない)。

次回に続く

*1:サイズ問題に直面することが非常に多いので、先にケースを選んでしまって、そこに入るグラフィックボードを探す、というアプローチも私はありだと思います。

PCをRyzen 9 5900Xで組んだ話(CPUとケースの選択編)

f:id:masatsuna:20210120023348p:plain

はじめに

2020~2021の年末年始で、PCを新しく構築しました。 構築にあたってどんなことを考えたのか、自分の記録のためにも残しておこうと思います。

考えたことを全部残すつもりで書くので、記事は適当なところで分割します。 今回は旧PCの紹介、問題点とかを書いて、CPU、PCケースを選定するあたりまで書きます。

旧PC

私が以前使用していたPCは、約6年前に構築したマシン(自作)でした。 構築した当初のスペックはこんな感じでした。

項目 構成
CPU Intel Core i7 4790K
メモリ DDR3 4GB × 2枚
記憶装置 80GB 2.5インチSSD × 1、512GB 2.5インチSSD × 1、2TB HDD × 1
マザーボード ASUS MAXIMUS VII HERO
グラフィックボード オンボード
CPUクーラー 前マシンから使いまわしの巨大なトップフロー型クーラー(もはや型番とか記憶にない)
電源 ENERMAX 450W セミプラグイン(型番忘れた)
DVDドライブ LG製のやっすいやつ
カードスロット 前マシンから使いまわしたやつ(マイクロSDのスロットは壊れていて使えなかった)
ケース 前マシンから使いまわしたやつ(メーカーすら不明、フロントにIEEE端子ついてたくらい昔のやつ)

構築して2年くらいして、さすがにメモリが足りなくなってきたので、家族のマシンから余ったDDR3 2GB × 2を増設。 そして一昨年、年末年始のセールでめちゃくちゃ安売りされていたCFDの1TB SSD(確か税抜き6,999円だった)を購入して増設。 CPUがそこそこ使える優秀な子だったので、そろそろ潮時かなーと思いながらもズルズルと使い続けてしまっていました。

いい加減買い替えようと思ったきかっけが、会社の先輩から、廃棄予定のPCで余ったDDR3 4GB × 2をもらったことでした。 このメモリ、先輩の子供が使っていたマシンだったそうで、エンジニアのマシンが子供のマシンより低スペックとか。。。 マジで笑えなくなってきたなーと思っていました。 そして最近は、お勉強という名の技術検証するときにHyper-Vを多用することが多く、メモリもCPUパワーも若干不足していて、難儀するケースが増えてきていました。

さらに決定的にダメになってきたのが、映像端子です。 このマザーボードオンボードの映像出力はHDMI、DVI-D、D-Subがそれぞれ1ポートずつありました。 HDMI端子は普通に使えていたんですが、DVI-D、D-Subの端子から映像出力できなくなってきてしまって、デュアルモニターがあるのに使えない、という悲しい事態に。。。 接点復活剤でたまーに映るようになったものの、めちゃくちゃ調子が悪くて、それ以上の改善ができませんでした。

うん、よくここまで使い切ったよ。

ということで、2020~2021の年末年始を利用して、新PCを構築することにしました。

新PC構築計画

CPU選定

パーツ選定とかは夏ごろから始めました。 ちょうどZen3のRyzenのうわさが出回り始めたころで、Zen3のスペックがすごそう、みたいな話がちらちら出てきていたころです。 正直Zen2までのRyzenは、ベンチマークはすごいけど、実際に使ってみたらそんなでもない、みたいな印象を持っていて、Ryzenへの信頼感はそれほど高くなかったんです。 なので、このころはIntelにするのかRyzenにするのか、すごく悩んでいました。

で、Zen3発表。 各種ベンチマークが出回り、実際に使ってみても結構いいぞ、みたいな評価が見えてきて、今回のPCはRyzenで行ってみるかなーと心が傾き始めました。

Ryzenを選んだ理由は、ベンチマークや口コミだけではありませんでした。 先ほど書いた通り、私はHyper-Vを多用する関係上、コア数がたくさんあることをそれなりに重要視していました。 Core i7 4790Kは4コア8スレッドで、正直Hyper-Vで複数台マシンを立ち上げて、ガンガン使うには貧弱でした。 10世代のCoreシリーズだと、多くても10コア20スレッド。 11世代のCoreまで待つと、8コア16スレッドに縮小。。。 Ryzenなら5900Xで12コア24スレッド、5950Xなら16コア32スレッド、となるならRyzenでしょ、と。 Ryzenは昔から仮想化回りに若干の不安があることは知っていましたが、せっかく作るなら多少遊びたい気持ちもあって、Ryzenを選択しました。

10世代のCoreシリーズが爆熱仕様だったことも、Intelを回避した理由になりました。 自作PCのくせに、長期間同じマシンを使い続ける私は、簡易水冷ではなく空冷にしたい気持ちがありました。 正直メンテナンスもめんどくさいし、ジョババは嫌だし。 空冷最高!という考えですね。

5900X、5950Xどっちで行くかは、価格で決めました。 さすがに16コアはいらないだろうし、CPU単体で10万円を超えるのはどうなのよ、ということで、5900Xにしました。

ちなみに5900X、5950Xは、現在も品薄状態が続いています。 もしかしたリンク先の販売ページが転売ヤーとかかもしれないで、十分に注意して購入するようにしてください。



PCケース

私のデスクは、足元にPCケースを置くスペースが確保されているタイプのデスクです。 逆に言うと、このサイズに収まるPCケースしか置くことはできません。 あとはDVDドライブをつけるつもりがあったので、今となっては希少な5インチベイのあるものを探しました。 PCをピカピカさせる趣味は一切ないので、光らないファンが搭載されていて、クリアパネルではないものができればうれしいなーと思っていました。 あと最近はUSB-C接続のものが増えてきているので、フロントにUSB-Cの端子があるものを選定しました。

そんなこんなで条件を見て回った結果、結局Flactal DesignのDefine 7になりました。


本当はDefine 6のUSB-C端子を搭載したモデルのほうがサイズ的に余裕があってよかったのですが、すでに日本では手に入らない状態になっていまして、泣く泣くDefine 7にしました。 Define 6から若干サイズアップしたせいで、本当にギリギリ収まる(というか、若干はみ出ている)状態になってしまいました。 Flactal Designさん、あと数ミリでいいから小さくしてほしい。

今回はここまでです。 次回に続く。

VM や k8s 環境へのデプロイ前に人手の承認処理を挟み込む

f:id:masatsuna:20201212120109p:plain

本記事は Azure DevOps Advent Calendar 2020 - Qiita 14 日目の投稿です。

はじめに

Azure Pipelines で VMk8s 環境にアプリケーションを配置するには Environments という機能を活用します。 これについては既に以下の記事で解説しました。

tsuna-can.hateblo.jp

今回は、エンプラ系のしっかりとした開発プロセスでも、こういった機能を活用できるようにするリリース前承認の機能を解説します。

やりたいこと

開発/テスト環境、本番環境に対して、自動デプロイを行います。 開発/テスト環境には、特に承認の作業なくアプリケーションをデプロイできるようにします。 本番環境へのデプロイは、開発/テスト環境での動作を確認できた後に、人の承認があって、デプロイするようにします。

全体の動作イメージ

以下のような動作を実現できるようにしていきます。 なおこの前段には、アプリケーションをパッケージングし、アーティファクトとして Azure DevOps にアップロードしていることを前提にします。

f:id:masatsuna:20201108155311p:plain
全体の動作イメージ

① 開発/テスト環境のエージェントが、自分の環境にダウンロードするべきアーティファクトがないか、ポーリングします(エージェントが自動でやってくれます)

② ダウンロードするべきアーティファクトを検知すると、それを開発/テスト環境にダウンロードします

③ ダウンロードしたパッケージを自サーバー内に展開して配置し、開発/テスト環境を更新します

④ Azure DevOps から、本番環境に配置しても良いか、レビューを依頼するメールが事前に登録したレビュアーに届きます

⑤ レビュアーは開発環境上で動作確認を行い、リリース可能かどうかを判定します

⑥ レビュアーは Azure Pipelines 上でレビュー結果を記録します(OK か NG かの 2 択)

⑦ 本番環境のエージェントが、自分の環境にダウンロードするべきアーティファクトがないか、ポーリングします(レビューが通ったもののみが対象になります)

⑧ ダウンロードするべきアーティファクトを検知すると、それを本番環境にダウンロードします

⑨ ダウンロードしたパッケージを自サーバー内に展開して配置し、本番環境を更新します

Environment の作成と VM の登録

今回は開発/テスト環境をあらわす「Development」と、本番環境を表す「Production」の 2 つの Environment を作成します。

f:id:masatsuna:20201212091807p:plain
Environment は 2 つ作成

それぞれの Environment には、 VM を 1 台ずつ登録しています。

f:id:masatsuna:20201212092125p:plain
VM を各環境に登録

Environment の作成や VM の登録については以下の記事で詳細に解説していますのでそちらをご覧ください。

tsuna-can.hateblo.jp

アプリケーションの作成

今回は .NET 5 のアプリケーションを適当に作成して使用します。 ソリューション名、プロジェクト名、フォルダ構造などは以下をご覧ください。

f:id:masatsuna:20201212093009p:plain
ソリューション構成

パイプラインの作成

続いてパイプラインの YAML を作成していきます。 以下に作成した YAML を公開してあります。

AzurePipelinesYAMLSample/Build-Release-To-Environment.yml at master · tsuna-can-se/AzurePipelinesYAMLSample · GitHub

やることは非常にシンプルで、アプリケーションのパッケージングを行い、各 Environment に配置するだけです。 パッケージングと配置はそれぞれ別の Stage として作成しています。 配置の Stage は、それぞれ前段の Stage の処理が正常に完了しなければ動作しないように設定しています。

本番環境への配置前に承認処理を入れる

ここまでの状態でパイプラインを実行すると、アプリケーションのパッケージング、開発/テスト環境への配置、本番環境への配置が順次実行されます。

f:id:masatsuna:20201212110416p:plain

ここから、本番環境への配置前に人手の承認処理が行えるよう設定を行っていきます。

[Pipelines] → [Environments] メニューを選択して、承認処理を行いたい Environment を選択します。 今回は本番環境へのリリース前に承認処理を挟み込むので、 Production を選択します。 そして右上の三点リーダーを押下し、 [Approvals and checks] を選択します。

f:id:masatsuna:20201212103128p:plain

[Approvals and checks] の画面の右上にある [+] ボタンを押下します。

f:id:masatsuna:20201212103350p:plain
[Approvals and checks] 画面右上の [+] ボタンを押下

すると、この Environment にリリースするための条件を選択・設定することができます。 今回は人手の承認処理を行いたいので [Approvals] を選択します。

f:id:masatsuna:20201212103603p:plain
[Approvals] を選択

承認者を [Approvers] に設定します。 承認者は Azure DevOps に対して登録したユーザーを個別に指定することもできますし、チームやグループを指定することもできます。

f:id:masatsuna:20201212110018p:plain

以上で設定は完了です。

動作確認

再度作成しておいたパイプラインを実行してみましょう。 アプリケーションのパッケージング、開発/テスト環境へのリリースは、今まで同様、自動的に流れていきます。 しかし、本番環境へのリリースを行う前にパイプラインの実行が停止します。 そして、レビューを促すボタンが表示されます。

f:id:masatsuna:20201212110634p:plain

先ほど設定したレビュアーのもとには、承認依頼がメールで飛びます(ただしこのメールは英語です)。

f:id:masatsuna:20201212115455p:plain

レビュアーは、開発/テスト環境にリリースされているアプリケーションを確認したり、各種メトリクスを参照したりして、本番環境への配置が可能な品質かを確認します。 問題がなければ、 [Approve] ボタンを押下します。

f:id:masatsuna:20201212111640p:plain

すると、今まで止まっていた処理が流れ始めます。

f:id:masatsuna:20201212113701p:plain

これで、本番環境へのリリース前に、人手の承認処理を挟み込むことができました。

なお承認処理にはタイムアウト時間を設定することもできるので、無駄に Waiting 状態で放置され続ける心配も少なくなります。 タイムアウトした場合は、処理自体が Skip され、以下のように記録が残ります。

f:id:masatsuna:20201212115606p:plain

もっと使い込む

Environment にリリースするための条件確認には、今回紹介した人手の承認処理以外にも様々なものがあります。 その中から特に有用なものをご紹介します。

Git リポジトリのブランチ運用ルールが明確になっているような開発では、 [Branch control] を活用するのが良いと思います。 本番環境には [main] ブランチからビルドしたモジュールしか配置できない、といったルールを簡単に作成することができます。 誤ってテスト用のモジュールを本番環境に配置してしまった、というミスも防げます。 このチェック機能はほとんど害悪がないので、是非使っていただきたいです。

またエンタープライズ系のシステムですと、業務の行われていない夜間にリリースしたいケースもあると思います。 今までだと人が張り付いてリリースの行く末を見守っていたと思いますが、 [Business Hours] を使えばそういった問題が解決できるかもしれません(相当難しいと思いますが。。。)。

もっと柔軟にいろいろ確認したいのであれば、 [Invoke Azure Function] も有用です。 例えば開発環境に対する一通りの動作確認を Azure Function で作成しておき、その処理を実行するように構成できれば、人手による確認を、より軽量化できるはずです。

まとめ

今回は Environment へのリリースチェック機能を紹介しました。 今回は VM を用いた例を提示しましたが、 Environment は k8s にも対応していますので、幅広く活用できるのではないでしょうか。 より安全に、より手間をかけず、リリースできるための仕組みを作っていきたいですね。

プロジェクトのプロセステンプレートを変更する方法

f:id:masatsuna:20201006071154p:plain

はじめに

最近 Auzre DevOps ってプロセスを最初に決めると変えられないの困るよね、みたいな話をよく聞きます。 いつのスプリントで実装されたのか記憶から消えてしまったのですが、実は変更できるようになっています。

操作方法

組織のページに入り左下の [Organization settings] を押下します。 左側のメニューから [Boards] → [Process] メニューを選択します。

f:id:masatsuna:20201005171954p:plain
[Process] メニューを選択

右側に現在組織内で利用できるプロセステンプレートの一覧が表示されます。 何もしていなければ、 [Basic] [Agile] [Scrum] [CMMI] が表示されているはずです。 この中から、プロセステンプレートを変更したいプロジェクトに設定されている現在のプロセステンプレートを選択します。

f:id:masatsuna:20201005172113p:plain
変更したいプロジェクトのプロセスを選択

上部のタブから [Projects] を選択します。 選択したプロセステンプレートの適用されているプロジェクトの一覧が表示されます。 この中から、プロセステンプレートを変更したいプロジェクトを探し、右側の三点リーダーをクリックして [Change process] を押下します。

f:id:masatsuna:20201005172635p:plain
[Change process] を選択

右側に変更先のプロセステンプレートを選択するドロップダウンが表示されます。 変更先のプロセステンプレートを選択します。

f:id:masatsuna:20201005172909p:plain
変更先のプロセステンプレートを選択

プロセステンプレートを選択すると、以下のような警告文が出てきます。 内容についてはちゃんと確認しておきましょう。 なおこの例では [Basic] から [Agile] に変更しています。

f:id:masatsuna:20201005173155p:plain
警告が出る

確認したら、下部にある [Save] ボタンを押下します。

プロセステンプレートの変更が完了すると、以下のようなメッセージが表示されます。

f:id:masatsuna:20201005173326p:plain
手動での変更手順

プロセステンプレートによって、ステータスの名前が違ったり、 Work Item のタイプが異なったりするので、その辺を手動で修正しなければなりません。 この辺はすべて自動で変換できるわけではないので、ご利用は計画的に、といったところでしょうか。

まとめ

今回はプロジェクトのプロセステンプレートを変更する方法について解説しました。 実際にやろうとすると、手作業となる部分がかなり多く、結構大変な作業になることは間違いありません。 特にたくさんの Work Item を登録してしまった後で、プロセステンプレートを変更するのはそれなりに労力を要します。 どのプロセステンプレートがご自身の開発にマッチするのかよく検討したうえで、使い込んでいくべきかと思います。

Azure DevOps でチームやグループ宛のメンションをしてもメール配信されないときに確認すること

f:id:masatsuna:20200927003353p:plain

Azure DevOps では、いろいろなところでメンションを行うことができます。 「@<ユーザー名>」や「@<チーム名>」のように入力することで、メンバーに対してメール送信を行うことができます。

非常に便利な機能なのですが、チーム宛てやグループ宛てにメンションをしようとしたとき、以下のようなメールがメンションした人に送られてくることがあります。

f:id:masatsuna:20200928103339p:plain

<チーム名 or グループ名> cannot be mentioned in <メンションした場所>.

The identity is not configured to receive notifications.

今回はこのような状態になってしまったときに、どのように設定を変更すればよいか、手順を解説します。

チーム宛てメンションの配信設定

チーム宛てにメンションを送った際、チームメンバーに対して個別にメール配信する設定は以下から行います。

まず設定したいチームの所属するプロジェクトのページに入り、左下の [Project settings] メニューを選択します。

f:id:masatsuna:20200918005105p:plain

[General] → [Teams] メニューを選択します。

f:id:masatsuna:20200918005303p:plain

右側ペインから、配信の設定を行いたいチームを選択します。

f:id:masatsuna:20200918005452p:plain

チーム名の下にある [Notifications] のリンクを押下します。

f:id:masatsuna:20200918005743p:plain

[Delivery settings] のメニューを選択します。

f:id:masatsuna:20200918005901p:plain

[Deliver to individual members] にチェックを入れ、 [Save] ボタンを押下します。

f:id:masatsuna:20200918010011p:plain

グループ宛て・チーム宛てメンションの配信設定

グループ宛てにメンションを送った際、グループのメンバーに対して個別にメール配信する設定は以下から行います。 同様の手順で、チーム宛ての配信設定を行うこともできます。

Azure DevOps の組織のトップ画面の左下にある [Organization Settings] を選択します。 続いて [General] → [Global notifications] メニューを選択します。

f:id:masatsuna:20200918010414p:plain

[Subscribers] タブを選択し、ドロップダウンに設定対象のグループ名を入力します。 対象のグループをドロップダウンの中から選択しておきましょう。

f:id:masatsuna:20200918010721p:plain

画面上部の右側に表示される [Delivery settings] のメニューを選択します。

f:id:masatsuna:20200927001532p:plain

[Deliver to individual members] にチェックを入れ、 [Save] ボタンを押下します。

f:id:masatsuna:20200927001650p:plain

この手順では、グループに対する設定方法を解説しましたが、同様の手順でチームに対する設定を行うこともできます。

参考情報

公式ドキュメントでは、以下に解説があります。 docs.microsoft.com

Chromium 版 Edge 用の Test & Feedback 拡張機能を試す

f:id:masatsuna:20200915154117p:plain

Chromium 版 Edge で使える Test & Feedback の拡張機能がリリースされていましたので紹介します。

Test & Feedback 拡張機能とは

Web アプリケーションの手動テストを実施する際、不具合などの報告を Azure DevOps にログインすることなく、ブラウザーから直接行うことのできる拡張機能です。 わざわざ Azure DevOps にログインして Work Item を起票することなく、簡単に報告を上げることができるのが、この拡張機能のウリといえます。 またブラウザー上でのテスターの操作記録を自動的に取得してくれるため、不具合の再現性を高めることもできます。

元々は ChromeFirefox 向けのブラウザー拡張機能として提供されていましたが、 Chromium 版 Edge での動作もできるようになっています。 各ブラウザー用の拡張機能のリンクは以下から参照できます。

marketplace.visualstudio.com

インストール

以下のページから Chromiun 版 Edge 用のブラウザー拡張機能をインストールすることができます。 microsoftedge.microsoft.com

接続

Azure DevOps の組織に接続します。 ブラウザー上右上に出てくる以下のアイコンをクリックします。

f:id:masatsuna:20200915001359p:plain
アイコン

[Connected] を選択して、接続先の Azure DevOps 組織の URL を入力します。

f:id:masatsuna:20200915004907p:plain
Azure DevOps の組織に接続

接続先のチームを選択します。

f:id:masatsuna:20200915010842p:plain
接続先のチームを選択

これで Azure DevOps のチームへの接続が完了しました*1

操作の記録と Work Item の作成

インストールした機能を使用して、Azure Boards に新たな Work Item を追加してみましょう。 今回は画面キャプチャーを取得して、そこにコメントを追記し、新たなタスクを登録する、というシナリオを追ってみたいと思います。

まず左側の三角ボタンを押下して、セッションを開始します。

f:id:masatsuna:20200915004412p:plain
記録の開始

カメラにファイルのアイコンから、 [Browser] を選択します。

f:id:masatsuna:20200915011034p:plain
ブラウザーの画面キャプチャーを開始

以下のようにブラウザー内のキャプチャーを取得したり、そこに対して直接コメントを記載したりすることができます。

f:id:masatsuna:20200915003029p:plain
フィードバックを書く

このように問題を発見したら、「!」マークのついているファイルアイコンから、直接 Work Item を起票することができます。

f:id:masatsuna:20200915003455p:plain
Work Item を直接起票できる

今回はタスクを作ってみます。 作成するタスクのタイトルを入力して、保存してみましょう。

f:id:masatsuna:20200915003703p:plain
タスクのタイトルを入力して保存

正常に保存が完了すると、以下のように Azure Boards にタスクが追加されます。

f:id:masatsuna:20200915003843p:plain
Azure Boards にタスクが追加される

先ほどキャプチャーした画像は、タスクの詳細を開くと張り付けられていて、確認することができます。

f:id:masatsuna:20200915004029p:plain
タスクの詳細に、キャプチャ画像が張り付く

まとめ

今回は Azure DevOps から新たに提供された Chromium 版 Edge の拡張機能である Test & Feedback の機能を紹介しました。 以前から存在していた ChromeFirefox 用の Test & Feedback 拡張機能と、できることは全く同じでした。

この機能は、主に探索的テストを行う場面で役立つのかなーという印象です。 テスト中に発見した不具合を逐一報告できる機能となっているため、このような使い方と相性がよさそうです。 また操作手順を定めたテストにおいても、操作記録を自動的に取得してくれるため、正しいオペレーションが行われたか、あとから検証することができます。 こういったツールを活用することで、手動の打鍵テストを効率化できるかもしれませんね。

*1:今回は同一ブラウザーセッション内で、接続先の Azure DevOps にログインした状態で実行しています。

Azure Pipelines の PowerShell タスクから警告/エラーログを出す方法

f:id:masatsuna:20200911011224p:plain Azure Pipelines で PowerShell を組んでいると、パイプラインの実行エラーや警告をログ出力したくなるケースがよくあります。 ただログを出力したいだけであれば、 Write-Host コマンドレットを使って標準出力に文字列を出力しても問題ありません。 しかし、以下のようにパイプラインの実行結果のトップ画面である Summary ページに、エラーや警告の情報を出力できたらより良い状態になります。

f:id:masatsuna:20200911001947p:plain
Summary 画面の通知

今回はこのような出力 Azure Pipelines から行う方法について解説します。

環境

今回は PowerShell タスク(v2)を用います。

PowerShell タスクから警告/エラーの情報を出す

前述のような出力を行うためには、 Azure Pipelines の実行エンジンに対して、 PowerShell スクリプトから警告やエラーの情報を伝えてあげなければなりません。 Azure Pipelines の PowerShell タスクを使う場合、 Write-Host コマンドレットに特別な文字列を設定することで、この動作を実現できます。

trigger: none

pool:
  vmImage: 'windows-latest'

steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host "##vso[task.LogIssue type=warning;]警告ログです"
      Write-Host "##vso[task.LogIssue type=error;]エラーログです"
    pwsh: true

Summary 画面には、エラーと警告、 2 つのログをサマリー表示してくれます。 上述の PowerShell スクリプトの 1 行目、 2 行目が、それぞれのログを出力している箇所です。 標準出力に対して ##vso[task.LogIssue type=xxxx;]ログ本文 の形式で文字列を流し込むことで、エラーや警告の情報を Summary 画面に出力できるようになります。

今回は PowerShell を用いていますが、 Bash や CMD を使う場合は、同様の文字列を echo コマンドで標準出力に出力することで、同じようなことが実現できます。

タスクを失敗させる

上記のパイプラインを実行すると、以下のような画面になります。

f:id:masatsuna:20200911003843p:plain
エラーがあるのにビルド成功?

見てもらうとわかる通り、エラーや警告は通知されているものの、ビルドパイプラインの実行は正常に終了している状態になります。 この動作からも明らかですが、エラーや警告の情報を出力しただけでは、 PowerShell タスク、パイプライン全体の実行結果をエラーに設定することはできません。

PowerShell タスクを明示的に失敗に設定したい場合は、以下のように PowerShell タスク実装します。

trigger: none

pool:
  vmImage: 'windows-latest'

steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host "##vso[task.LogIssue type=warning;]警告ログです"
      Write-Host "##vso[task.LogIssue type=error;]エラーログです"
      Write-Host "##vso[task.complete result=Failed;]タスクを失敗に設定します"
      return
    pwsh: true

PowerShell スクリプトの 3 行目で、この PowerShell タスクを失敗に設定しています。 これにより、 PowerShell タスクが失敗するようになり、パイプライン自体も失敗となります。

しかし、この処理を PowerShell の世界で見ると、単純に標準出力に文字列を出力しているだけです。 PowerShellスクリプトを了させる効果は、この 1 文にありません。 そのため、タスクをエラーに設定した直後に、 return などスクリプトを強制的に終了させるコマンドを使ってください。 この例ではあってもなくても関係ありませんが、特定の条件に当てはまる場合のみエラーとするなど、処理が複雑化してくると、意図しない処理が実行されてしまう危険があります。 これら 2 つをセットで使うよう、意識付けしておくとよいと思います。

f:id:masatsuna:20200911004828p:plain
ビルドパイプラインも失敗扱いになる

タスクの失敗を通知するコマンドと return コマンドの組み合わせを実装するのがめんどくさい場合は、 exit 1 と実装することでも、同じような結果を得ることができます。 ただし、 exit 1 を利用した場合、ビルドの Summary ページに、 exit 1 が呼び出されたことを示すエラーも表示されるようになります。 これが気にくわない場合は、上記のような実装をすることをおすすめします。

まとめ

今回は PowerShell タスクを用いて、 Azure Pipelines の実行サマリー画面に、エラーや警告の情報を出力する方法について解説しました。 また明示的にタスクを失敗にする方法についても解説しました。 ぜひ活用してみてください。

なお今回は、ログ関連の機能を中心に、標準出力の変則的な使い方を解説しました。 このような特殊な標準出力の使い方は、他にもいくつかあります。 以下にまとまっていますので、参考にされてください。

docs.microsoft.com

Surface Laptop 3 を冷却台で冷やしてみよう 後編

f:id:masatsuna:20200823020400p:plain

前編では、ノート PC 冷却台の効果が本当にあるのかを検証しました。 中編では、実際に事務作業を行う中で、ノート PC 冷却台の効果がどの程度あるのかを検証しました。

後編となる今回は、 Surface Laptop 3 に最大の負荷をかけたとき、ノート PC 冷却台がどの程度効果を発揮するのか、検証してみようと思います。


検証の目的

前編、中編と、どちらかというと PC に対して低負荷の状態で、ノート PC 冷却台の効果を検証してきました。 主な PC の使い方だけ考えれば、こういった検証だけでも十分かもしれません。 しかし、私はこの PC を使ってソースコードのビルドや自動テストを日々実行しています。 こういった利用シーンでは、それなりの時間 CPU が高負荷の状態になります。 大きなソースコードになってくると、数分間にわたって CPU 使用率が 100 %に張り付くといったこともあります。

このような作業を PC にやらせるとき、だいたい PC の前でボケーっと待っているわけです。 そもそも CPU をやたらと食われてしまうので、他の作業をするのにもなかなかしんどいですし、他の作業をやるのには時間が短すぎます。 休憩時間としていた方が精神的にも落ち着くし、次どうしようかと考える時間に使ったりしています。 とはいえ、この待ち時間が非常にうざったいのも事実です。 できる限りこの時間は短くあってほしいのがシステムエンジニアという生き物なんじゃないでしょうか。

CPU が高クロックの状態で長時間稼働できれば、ソースコードのビルドや自動テストが短時間で終了できます。 今回はこういったシーンを想定して、ノート PC 冷却台の効果がどの程度発揮できるのかを検証していきたいと思います。

ノート PC 冷却台について

後編でも、前編、中編で使用したのと同じサンワサプライ製のノート PC 冷却台(TK-CLN16U2N)を使用します。 詳細は前編の記事を参照してください。


検証内容

今回は CPU に対して最大負荷をかけたときの CPU クロック、 CPU 温度を計測していきます。 CPU に負荷をかけるツールとして Cinebench R20 を使用します。 Cinebench R20 のマルチコアのスコアを計測するモードを実行し、前述のデータを取得します。

測定は、以下の 2 条件で実施しました。

  • 直置き(ノート PC 冷却台を使わず、 Surface Laptop 3 を机の上に直接置く)
  • ファン最大(ノート PC 冷却台に置き、冷却台のファンを最大回転で回す)

中編までの検証で、ノート PC 冷却台の効果は実証されていますので、今回はこの 2 条件に絞って検証します。 各条件での計測実行前に 10 分間のクールダウン時間を設けて、まずは CPU 温度が安定した状態を作ります。 その後、それぞれの条件下で、 Cinebench R20 を 1 回ずつ実行します。 その時の、 CPU クロックと CPU 温度を計測します。

検証時の室温は 28.8 ℃でした。 エアコンは稼働していますが、直接風が ノート PC に当たることはありません。

CPU クロック、 CPU 温度の測定には Open Hardware Monitor を使用しました。 各条件で実行したときの CPU クロック、 CPU 温度をそれぞれグラフ化して、比較します。 また Cinebench R20 を完走するまでの時間も、併せて計測します。 なお今回は Cinebench R20 のスコアについては触れません。

検証結果

CPU クロック

まずは CPU クロックの状態を確認していきます。 以下のグラフを見てください。

f:id:masatsuna:20200825235320p:plain

縦軸がクロック数、横軸が経過時間を示しています。 Cinebench R20 の実行を開始した時間を 0 秒地点としています。

この結果を見てもわかる通り、ファン最大場合は、 Cinebench R20 の実行が終わるまで、約 2.1 GHz をキープできています。 それに対して直置きした場合おおよそ 50 秒を過ぎたあたりからクロック数が徐々に低下していき、最終的には約 1.6 GHz までクロック数が落ちてしまっています。

CPU 温度

続いて CPU 温度の状態も確認します。 以下のグラフを見てください。

f:id:masatsuna:20200825235717p:plain

縦軸が CPU 温度、横軸が経過時間を示しています。 Cinebench R20 の実行を開始した時間を 0 秒地点としています。

まず注目すべきポイントは、実行を開始した直後の温度上昇です。 直置きしたときは、ファン最大の時に比べて、 CPU 温度が急激に上昇している様子が見て取れます。 CPU 温度が 90 ℃ に達するタイミングを見ると、直置きの時は 16 秒後ですが、ファン最大の時は 23 秒まで持ちこたえています。 また最大温度も直置き時は 94 ℃ を記録していましたが、ファン最大時は 92 ℃ と、 2 ℃ 低い値となりました。

おおよそ 54 秒経過したあたりで、直置きした場合はクロック数が下がり始めます。 これにつられるようにして、 CPU 温度も徐々に低下していく様子が見て取れます。 この検証結果から見ると、 CPU クロックの低下は CPU 温度だけを見ているのではないように思います。

Cinebench R20 の実行時間

前述の通り、直置きした場合は CPU クロックの低下が確認されました。 結果として、 Cinebench R20 の実行時間にも大きな影響を与えました。 前述の各グラフは、 Cinebench R20 の実行が完了するタイミングまでのデータを掲載しています。 ファン最大の場合の方が、横軸が短くなっているのは、ファン最大の時の方が、 Cinebench R20 を完走する時間が短かったからです。

Cinebench R20 を完走するまでの時間は以下の通りです。

条件 Cinebench R20 完走までの時間
直置き 249秒
ファン最大 227秒

単純に引き算すると、ファン最大の場合は直置きの場合と比較して、約 22 秒速く処理を終えることができました。 クロック数の低下が、実行時間に対して大きな影響を与えている様子がわかります。

まとめ

Surface Laptop 3 に対して最大負荷をかけた場合、ノート PC 冷却台の効果がどの程度あるかを検証してきました。 結果として、ノート PC 冷却台をファン最大の状態で使用すると、 CPU クロック数を長時間ハイレベルな状態でキープできることがわかりました。 またその結果、 ノート PC 冷却台の上に置くだけで、処理速度を向上できることもわかりました。

さいごに

全 3 回にわたって、 Surface Laptop 3 をノート PC 冷却台で冷やすことができるのか、その効果がどの程度あるのかを検証してきました。 正直検証してみるまで、ノート PC 冷却台については眉唾ものだと思っていました。 検証してダメだったら捨てるかーくらいの気持ちでいたのですが、かなり効果的であるという結果が出て、驚いています。 ノート PC 冷却台、大事に使っていくことを急に決意しました。

なお今回の検証は、各記事で紹介した条件で実行しています。 PC の種類やノート PC 冷却台の種類、室温など、様々な条件によって結果が大きく異なる可能性もあります。 あくまで参考程度にご覧いただければと思います。

Surface Laptop 3 を冷却台で冷やしてみよう 中編

f:id:masatsuna:20200823013129p:plain

前編では CPU の負荷テストツールである CpuStres を使って、 Surface Laptop 3(Core i7、16GB RAM、256GB SSD)に負荷を与え、本当にノート PC 冷却台の効果があるのかどうかを検証しました。 その結果、 CPU の温度上昇を抑える効果がある程度認められることを確認しました。

tsuna-can.hateblo.jp


中編となる今回は、一般的な事務作業を行ってみたときの発熱状態を確認し、ノート PC 冷却台がどの程度効果を発揮するか確認してみようと思います。

なぜ前編の結果だけではダメなのか

前編で確認したのは、 CPU に一定の負荷をかけてノート PC 冷却台の効果があるのかどうか、を確認しました。 しかし、実際に PC を使うことを考えてみると、現実の使い方に即した負荷になっているとは言えません。 前編で行ったような、 PC に定常的な負荷を一定時間かけ続ける使い方をすることは、ほとんどないと思います。

そこで今回は、 Surface Laptop 3 を通常の事務作業の中で使ってみて、 CPU 使用率や CPU 温度を計測してみることとします。 それを通して、 Surface Laptop 3 の実際の発熱具合や、ノート PC 冷却台の実際の効果を検証してみます。

ノート PC 冷却台について

中編でも、前編で使用したのと同じサンワサプライ製のノート PC 冷却台(TK-CLN16U2N)を使用します。 詳細は前編の記事を参照してください。


検証内容

私が仕事をする環境では、最低限アンチウィルスソフトウェア、 Teams 、ブラウザーVPN 接続用のソフトウェア、 Outlook を起動しています。 今回の検証は通常の利用シーンでの CPU 温度を計測するのが目的ですので、前編のように、これらのソフトウェアを終了することなく、起動した状態で検証を行いました。 また今回は事務作業を実施中の CPU 温度を確認するため、これらのソフトウェアとは別に、 PowerPoint の資料を 1 つ、 Excel ブックを 1 つ起動し、主に PowerPoint の資料を作成するシーンを測定対象としました。 資料作成ですので、当然ながら途中でブラウザーを使用して検索を行ったりもします。 また今回は、 Surface Dock 2 を用いて電力を供給しながら、外部の 4K モニターを接続したデュアルモニター環境で計測しています。

温度測定は、前編と同様、以下の 4 条件で実施しました。

  • 直置き(ノート PC 冷却台を使わず、 Surface Laptop 3 を机の上に直接置く)
  • 台に置いただけ(ノート PC 冷却台に置くだけ、冷却台のファンは回さない)
  • ファン最小(ノート PC 冷却台に置き、冷却台のファンを最小回転で回す)
  • ファン最大(ノート PC 冷却台に置き、冷却台のファンを最大回転で回す)

それぞれの条件下で、前述のような事務作業を 30 分間行います。 そのうち最後の 8~10 分間で、 CPU 使用率と CPU 温度を計測しました。 検証時の室温は 28.5 ℃でした。 エアコンは稼働していますが、直接風が ノート PC に当たることはありません。

CPU 温度の測定には Hardware Monitor を使用しました。 今回は、 CPU にかける負荷が一定ではないため、正確な CPU 温度を出すことにあまり意味はありません。 全体的な傾向をつかむ方が重要ですので、結果はグラフとして確認することとします。 平均値もグラフ上で「それっぽい値」を感覚で示すこととします。*1

検証結果

上述の検証を各 1 回ずつ行いました。 計測した時間の中から、 CPU 使用率、 CPU 温度の平均をグラフから「なんとなく」求めた結果、以下のようになりました。

条件 CPU 最小使用率 CPU 最大使用率 CPU 平均使用率 CPU 最低温度 CPU 最大温度 CPU 平均温度
直置き 1% 61% 9.5% 51℃ 72℃ 56℃
台に置いただけ 1% 50% 9.5% 49℃ 70℃ 54℃
ファン最小 0% 63% 9% 48℃ 68℃ 51.5℃
ファン最大 0% 30% 8% 46℃ 62℃ 49℃

結果を見てもわかる通り、 ノート PC 冷却台の効果はかなりにある ことがわかりました。

検証結果の分析

さて、今回は CPU 負荷を一定にすることができない検証ですので、結果として記載した表も、あくまで参考レベルとしか言えません。 特に CPU 最大使用率については、瞬間的に使用率が上がっているだけのケースも多く、外れ値と考えて差し支えない状況であると言えます。 感覚的にノート PC 冷却台の効果を見ていただくためにも、生のグラフを見ていただければと思います。 かなり効果を実感できる結果になっていると思います。

f:id:masatsuna:20200821010021p:plain
直置き時の CPU 使用率遷移

f:id:masatsuna:20200821010159p:plain
直置き時の CPU 温度遷移

f:id:masatsuna:20200821010454p:plain
台に置いただけの時の CPU 使用率遷移

f:id:masatsuna:20200821010720p:plain
台に置いただけの時の CPU 温度遷移

f:id:masatsuna:20200821011031p:plain
ファン最小時の CPU 使用率遷移

f:id:masatsuna:20200821011220p:plain
ファン最小時の CPU 温度遷移

f:id:masatsuna:20200821011415p:plain
ファン最大時の CPU 使用率遷移

f:id:masatsuna:20200821011547p:plain
ファン最大時の CPU 温度遷移

前編で検証した CPU 使用率を一定にする時よりも、全体的に温度が上昇していると言えます。 前回は CPU にだけ負荷をかけるようにしていましたが、今回は一般的な事務作業を行っている関係上、内臓グラフィックやメインメモリ、 SSD にもある程度の負荷がかかっています。 これにより、 PC 内部の温度が全体的に上昇し、 CPU の冷却が追い付かなくなっているものと推察します。

なお今回は SSD の温度も取得しようとしたのですが、 Hardware Monitor のエラーでファンを回転させているときの情報が収集できませんでした。 直置き、台に置いただけのとき、 SSD の温度はどちらも 44 ℃ でした。 Surface Laptop 3 の SSD は、キーボード側の左手を置いたあたりに配置してあります。 ぼやっと左手に温かみを感じましたが、背面のように低温やけどしそうなほどには熱くなりませんでした。 ファン回転時も体感温度に差はなく、ノート PC 冷却台の冷却効果は背面に限られるように感じました。

背面温度

CPU 温度が他のパーツの温度上昇の影響を受けるということは、逆に言えば筐体の温度を低下させることで、 CPU 温度を下げる効果が期待できるとも言えます。 前編の検証結果でも示した通り、背面の温度がノート PC 冷却台の有無、ファンの回転有無によって体感的に差が出ていました。 この本体背面への冷却効果が、事務作業を行う場面では、 CPU 温度の低下に大きく効果を表していた考えることができそうです。

まとめ

今回は一般的な事務作業を Surface Laptop 3 で実施しながら、 4 つの条件下で CPU 温度を計測しました。 計測結果から、ノート PC 冷却台の効果は非常に高いということがわかりました。

後編では、 Surface Laptop 3 に最大負荷をかけ、その時の PC の挙動や、 CPU 温度の計測を行おうと思います。 ソースコードのビルド作業などを行うと、 CPU に対してそれなりの時間、大きな負荷がかかる状況というのは割とよくあります。 そういったときにどういった差が出てくるのかを確認していきたいと思います。

*1:学生時代に統計学の先生が、グラフから感覚で求めた平均って割とあってるんだよね、って話していたことを悪用します。笑

Surface Laptop 3 を冷却台で冷やしてみよう 前編

f:id:masatsuna:20200820012633p:plain

最近 Surface Laptop 3 の13.5インチモデル(Core i7、16GB RAM、256GB SSD)を手に入れました。 Visual Studio とか SSMS とか、重たいアプリケーションを入れて実行しても、かなり軽快に動作していまして、大満足しています。


しかし、動作が早いってことはそれなりに発熱もするわけです。 セキュリティ対策のアプリケーションや、 Teams 、 Outlookブラウザーといったいつも起動しているアプリケーションを動かしているだけで、本体(特に裏側のディスプレイサイド)が低温やけどするんじゃないか、程度に熱を持っています。 世の中の Surface Laptop 3 の評価を見ていると、廃熱の仕組みが優れているとか、かなり称賛されているのですが、実際に使ってみると心配になる程度に熱くなります。 長く使っていきたいので、できる限り PC 本体の発熱を抑えることはできないか、チャレンジしてみることにしました。

単純に発熱を抑えるのなら、 CPU がブン回らないように制御する、といった対応ができるかと思います。 しかし、スペック重視で選んだ機器なので、できる限りそういった制限はしたくありません。 ということで、この発熱をノート PC 冷却台で冷やしてみよう、そしてその結果を見てみよう、というのが今回の記事の趣旨となります。

前編では CPU 負荷ツールを用いて、ノート PC 冷却台の効果がどの程度あるのか、検証した結果をお伝えします。 中編では、実際に事務作業を行いながら、ノート PC 冷却台の効果がどの程度あったかお伝えしていきます。 後編では、 Surface Laptop 3 に最大負荷をかけたときの挙動についてお伝えします。

ノート PC 冷却台について

今回はサンワサプライから出ている TK-CLN16U2N というノート PC 冷却台を用意して、その効果を検証してみました。 このノート PC 冷却台は、前後に移動可能なファンが 2 つついています。 またファンの動作スピードを側面スイッチで変更することができます。

なお今回用意したノート PC 冷却台は、既に販売終了となっており、サンワサプライから直接購入することはできません。 Amazon などで少々在庫が残っているようですが、入手性が極めて悪いこと、ご了承ください。

direct.sanwa.co.jp


13インチクラスのノート PC 冷却台は、それほど多くありません。 こういった製品は「大は小を兼ねる」のですが、あまりにも大きいものでは机の上で邪魔なんですよね。 もうちょっとこのサイズの製品が選べればよいのですが。。。

ちなみにこちらの製品、Surface Laptop 3 13.5 インチモデルのサイズにぴったりです。 ちょうどよいサイズ感を求めている方は頑張って探してみてください。

検証内容

Microsoft の Sysinternals から出ている CpuStres v2.0 というソフトウェアを使って CPU に対して負荷をかけ、その時の CPU パッケージ温度を計測します。 CPU 温度の測定には Open Hardware Monitor を使用しました。

温度測定は、以下の 4 条件で実施しました。

  • 直置き(ノート PC 冷却台を使わず、 Surface Laptop 3 を机の上に直接置く)
  • 台に置いただけ(ノート PC 冷却台に置くだけ、冷却台のファンは回さない)
  • ファン最小(ノート PC 冷却台に置き、冷却台のファンを最小回転で回す)
  • ファン最大(ノート PC 冷却台に置き、冷却台のファンを最大回転で回す)

CpuStres は、論理コア 1 つに対して 1 つのスレッドを起動し、それぞれ 25% の負荷をかける設定としました。 今回テストする Surface Laptop 3 は Core i7 モデル(4C/8T)なので、 8 スレッド起動するよう設定しています。 またある程度温度が安定した状態で測定を行いたかったため、 CpuStres を先述の条件で約 3 分間起動し、温度が安定してから 2 分間、 CPU 使用率と CPU 温度を計測しています。 データは 1 秒につき 1 回取得するように設定しています。

検証時の室温は 28.5 ℃でした。 エアコンは稼働していますが、直接風が ノート PC に当たることはありません。

なお今回 CPU 使用率を 25% 程度になるよう設定した理由は、以下の 2 点です。

  • 実際に PC を使っているときの一般的な負荷に合わせるため
  • これ以上負荷をかけてしまうとサーマルスロットリングが発生してしまい、 CPU 温度が安定しないため

検証結果

上述の検証を各 1 回ずつ行いました。 計測した 2 分間の CPU 使用率、 CPU 温度の平均は以下の通りとなりました。

条件 CPU平均使用率 CPU温度平均
直置き 28.5% 51.3℃
台に乗せただけ 28.4% 50.2℃
ファン最小 28.3% 47.9℃
ファン最大 28.6% 48.4℃

冷却台に乗せるだけで約 1 ℃、ファンを回転させるとさらに約 2 ℃の CPU 温度低下を確認できました。

検証結果の分析

各条件下での CPU 使用率、 CPU 温度をグラフ化すると、以下のようになりました。

f:id:masatsuna:20200820005143p:plain

f:id:masatsuna:20200820005157p:plain

f:id:masatsuna:20200820005210p:plain

f:id:masatsuna:20200820005220p:plain

これらは、 1 秒おきに計測した CPU 使用率、 CPU 温度のデータを、 10 秒間の移動平均としてグラフ化したものです。 左の軸が CPU 使用率、右の軸が CPU 温度を表しています。 今回は測定回数が 1 回だったこともあり、あまり精度のよい測定ができているとは言えません。 特に「直置き」の場合、 CPU 使用率が安定しなかったことから、CPU 温度が若干上振れした可能性があります。 また「ファン最大」の場合も、 CPU 温度が一時的に不自然に上昇しており、平均値を押し上げる要因になりました。

しかし、これらの測定誤差を鑑みても、直置きしたときより冷却台においてファンを回すと約 3 ℃、 CPU 温度を下げることに成功したと言えそうです。

背面温度

残念ながらサーモグラフィーがないため、触ったときの感覚をそのままお伝えするにとどめます。

まず「直置き」の場合と「台に置いただけ」の場合は、低温やけどをしそうな温度であると感じました。 どちらの場合も体感温度にほとんど差はありませんでした。

「ファン最小」の場合、明らかに温度が下がっていることを感じました。 感覚としては、「温かい」くらいのレベルまで温度が下がっていました。

「ファン最大」の場合、さらにそれより温度が下がり、触っても「ほんのり温かい」程度まで温度が下がっていました。 明らかに「ファン最小」より温度が低くなっていることを感じました。

まとめ

これらのことから、今回用意したノート PC 冷却台は、ある程度ノート PC の冷却効果がある、と言えそうです。 ファンを回すことで、よりその効果が高まることがわかりました。 特に触ったときの背面温度は CPU 温度として表れている値以上に温度差を感じました。

ご参考

今回の検証で利用したソフトウェアのダウンロード先を張っておきます。

CpuStres

docs.microsoft.com

Open Hardware Monitor

openhardwaremonitor.org

Azure Reposのメインブランチ名がmasterからmainに変わる話

f:id:masatsuna:20200804095448p:plain

日本でも話題になっていた黒人差別に端を発した差別撤廃に関する運動が、 Azure Repos にも変化をもたらすようです。 この運動については以下のような記事がたくさん出ていますので、ここでは触れません。

www.itmedia.co.jp

何が変わるのか

Git で構築した Azure Repos は、当初何も設定しなければ、 master という名前の既定のブランチが 1 つ作成される仕様になっていました。 以下のように後から既定のブランチを変更することもできましたが、多くの方は既定のブランチを変更せずに使っているのではないかと思います。

docs.microsoft.com

この既定のブランチ名が、今後「main」に変更されるようです。 時期についての詳細は述べられていませんが、2020年の夏に行われるとの情報があります。 今後も「master」を既定のブランチ名として使いたい場合や、何か別の名前を既定のブランチ名としたい場合は、 Azure Repos の設定から、既定の名前を設定できるようになるようです。

docs.microsoft.com

この修正は Sprint 173 に含まれており、 2020/08/03 から配信が開始されています。 1か月以内には使えるようになると思われます。

日本語で考えてみる

正直私は、 master / slave という言葉の意味を真剣に考えたことなんてありませんでした。 ただの英単語としてしかとらえていなかったし、アルファベットの文字の羅列としか認識できなかったのかもしれません。 そしてマスターとカタカナで書くと、バーとか居酒屋の店主のようなイメージがあって、そんなに悪いイメージがなかったのです。

しかし、最近は、英語を母国語とする人たちには、これって結構強烈な単語なのかもしれない、と思い直しています。 実際に辞書で調べてみると、結構強烈な日本語に変換されます。

単語 意味
master 主人、雇い主、家長、支配者、主君、(動物・奴隷の)所有主
slave 奴隷、奴隷のように(あくせく)働く者

※出典:https://ejje.weblio.jp/

仮にブランチ名がこういった日本語だったとしたら、と考えると。。。 皆さんはどうお考えでしょうか。

リポジトリの新旧を暗に表す

世の中がこのように大きく動いているので、 master ブランチを使い続けているリポジトリは、古臭さを感じるようになるかもしれません。 「まだ SVN 使ってるの?」と同じ文脈で。

Azure Pipelines のビルド結果画面にコードカバレッジの結果を表示する(.NET Core)

f:id:masatsuna:20200727014541p:plain

モヤるポイント

Azure Pipelines を使って .NET Core のアプリケーションの単体テストを実行するとき、以下のような YAML を書いて単体テストを実行していたと思います。

- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    projects: '$(Build.SourcesDirectory)\**\Test.*.csproj'
    arguments: --collect "Code coverage"

こんなタスクを組み込んであげると、 Azure Pipelines の実行結果画面で、単体テストの実行結果を参照できます。

f:id:masatsuna:20200726234522p:plain
単体テストの実行結果

[Tests] タブを開くと、以下のような形でテストの実行結果をさらに詳しく参照することもできます。

f:id:masatsuna:20200726234702p:plain
[Tests] タブ

しかし、 [Code Coverage] タブを開くと、そこにはコードカバレッジの情報は表示されません。 何やらファイルダウンロードを行うためのリンクが表示されます。 このファイルをダウンロードして、ローカルの Visual Studio Enterprise で開くと、コードカバレッジの情報が参照できるのですが。。。 Visual Studio Enterprise を持っていないとこのファイルを開けなかったり、オペレーションがめちゃくちゃ煩雑だったり、とまったくうれしくない使用感です。

f:id:masatsuna:20200726234806p:plain
[Code Coverage] タブ

やりたいこと

今回は前述した [Code Coverage] タブを開いたら、そこにコードカバレッジの詳細情報を表示できるようにしていきたいと思います。 なお今回使用するサンプルは、以下の GitHub リポジトリに公開してありますので、ご自由に参照してください。

github.com

Azure DevOps のセットアップ

まずは Azure DevOps のマーケットプレースに行って、以下の拡張機能をインストールしましょう。

marketplace.visualstudio.com

YAML の作成

続いてビルドパイプラインを作成します。

各種設定

まずは設定部分です。

trigger: none

variables:
  System.Debug: True
  BuildConfiguration: 'Debug'
  TargetSolution: '$(Build.SourcesDirectory)\TestCoverageReportSample_Core\TestCoverageReportSample.sln'
  TestProjects: '$(Build.SourcesDirectory)\TestCoverageReportSample_Core\test\**\Test.*.csproj'

pool:
  vmImage: 'windows-latest'

今回は手動でビルドパイプラインを実行するだけなので、トリガーは none に設定しておきます。 またビルドマシンも最新版の MS-Hosted な Windows マシンを使用します。

変数はビルドの Configuration とソリューションのパス、テストプロジェクトのパスを設定しています。 Configuration は今回 Debug を使用していますが、特に理由はありません。 このリポジトリは複数ソリューションが含まれるリポジトリですので、ソリューションやテストプロジェクトのパスはそれ反映した形で定義しています。

System.Debug 変数は、ビルドパイプライン内の各タスクの出力するデバッグログを出力するための設定です。 デバッグログが不要なら、この設定は必要ありません。

アプリケーションのビルド

- task: DotNetCoreCLI@2
  displayName: 'NuGet パッケージの復元'
  inputs:
    command: 'restore'
    projects: '$(TargetSolution)'
    feedsToUse: 'select'
- task: DotNetCoreCLI@2
  displayName: 'アプリケーションのビルド'
  inputs:
    command: 'build'
    projects: '$(TargetSolution)'
    arguments: '--configuration $(BuildConfiguration)'  

今回のアプリケーションは .NET Standard 2.0 準拠のクラスライブラリプロジェクトと、そのライブラリの単体テストプロジェクト(.NET Core 3.1)で構成してあります。 なので VSBuild ではなく、 dotnet CLI を用いて実行しています。 最初のタスクで NuGet パッケージの復元を行い、続いてソリューション全体のビルドを実行しています。

アプリケーションのテスト

- task: DotNetCoreCLI@2
  displayName: '単体テストの実行'
  inputs:
    command: 'test'
    projects: '$(TestProjects)'
    arguments: '--configuration $(BuildConfiguration) --collect "XPlat Code coverage" -- RunConfiguration.DisableAppDomain=true'  

アプリケーションのテストも dotnet CLI を用いています。

この時ポイントとなるのが --collect "XPlat Code coverage" の部分です。 これはコードカバレッジを Coverlet で実行するための設定です。 Visual Studio 2019 で .NET Core 3.1 の [MSTest テスト プロジェクト(.NET Core)] を作成すると、既定で以下の NuGet パッケージが含まれてきます。

www.nuget.org

この --collect "XPlat Code coverage" の設定を行うことで、 Coverlet を用いてコードカバレッジの計測が行われるようになります。 計測結果は [coverage.cobertura.xml] という名前の XML ファイルとして出力されます。 出力場所は $(Agent.TempDirectory)ディレクトリ配下にランダム名前のディレクトリが置かれ、その中に配置されます。 出力されるファイルのパスは、 System.Debug 変数を true に設定しておくことで参照できます。

単体テストで使用できるオプションについては、以下を参照してください。

docs.microsoft.com

コードカバレッジレポートの作成と発行

- task: reportgenerator@4
  displayName: 'コードカバレッジレポートの作成'
  inputs:
    reports: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'
    targetdir: '$(System.DefaultWorkingDirectory)\TestResults\Coverage\Reports'
    reporttypes: 'Cobertura'
- task: PublishCodeCoverageResults@1
  displayName: 'コードカバレッジレポートの発行'
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(System.DefaultWorkingDirectory)\TestResults\Coverage\Reports\Cobertura.xml'

最後に、マーケットプレースからインストールした Report Generator を使って、コードカバレッジレポートの作成を行います。 アプリケーションのテストを行うタスクで出力した [coverage.cobertura.xml] を入力として、 [Cobertura] 形式のカバレッジレポートを作成します。 コードカバレッジのレポート作成を [Cobertura] 形式で実行すると、 targetdir に設定したディレクトリに、 [Cobertura.xml] が出力されます。 このファイルを PublishCodeCoverageResults のタスクを用いて発行します。

実行結果

ビルドパイプラインを実行すると、以下のようなビルド結果が [Summary] タブに表示されます。

f:id:masatsuna:20200727011921p:plain
ビルド結果(Summary)

ビルド結果(Summary)の画面は、今までとほとんど変わりありません。 ただし、 Build Artifacts として、カバレッジレポートの情報がアップロードされている点と、コードカバレッジ率に少々変化があります*1

f:id:masatsuna:20200727012207p:plain
Build Artifacts の中身

Build Artifacts の方には、アップロードしたコードカバレッジの情報と、そこから生成した HTML のレポートが含まれています。

次に [Code Coverage] のタブを開いてみます。

f:id:masatsuna:20200727012412p:plain
ビルド結果(Code Coverage)

ここには、先ほど Build Artifacts としてアップロードされたコードカバレッジの詳細情報が表示されます。 また表示されているクラスのリンクを押下すると、さらに詳細なカバレッジレポートを参照できます。

f:id:masatsuna:20200727012729p:plain
クラス別のカバレッジ

まとめ

今回は Azure Pipelines のビルド結果画面で、単体テストのコードカバレッジを表示する方法について解説しました。 Visual Studio Enterprise を持っていない場合でも、この方法ならコードカバレッジのデータを参照することができますので、活用してみてください。

*1:これはカバレッジの計算方法に若干の違いがあることが理由のようですが、ちゃんと調べていません

マネージド ID を使って App Service から SQL Database にアクセスする 後編

f:id:masatsuna:20200720021902p:plain

はじめに

前回に引き続き、システム割り当てマネージド ID 、ユーザー割り当てマネージド ID を用いて App Service に配置した Web Application から SQL Database にアクセスする方法を解説していきます。 今回は後編として、マネージド ID を使って App Service から SQL Database にアクセスできるよう、 Azure リソースの設定を行っていきます。

内容
前編 マネージド ID とは一体何かを概念的に解説し、それが Azure Portal 上でそれらがどのように見えるのか、具体的に解説します。
中編 ASP.NET の Web アプリケーションで システム割り当てマネージド ID 、ユーザー割り当てマネージド ID を取り扱う方法について解説します。
後編(本記事) Azure 上にアプリケーションを配置して、 App Service 上の Web アプリケーションから SQL Database にアクセスするまでの手順を解説します。

SQL Database の作成と設定

管理者用の Azure Active Directory ユーザーの作成

まずは SQL Database の管理者用として使用する Azure Active Directory のユーザーを作成します。 [Azure Active Directory] → [ユーザー] メニューを開き、 [すべてのユーザー] → [新しいユーザー] を選択します。

f:id:masatsuna:20200719235656p:plain
新しいユーザーの作成

今回は以下のような名前のユーザーを作成しておきました。

f:id:masatsuna:20200720000034p:plain
ユーザーの作成完了後

SQL Databaseの作成

次に SQL Database を作成します。 今回はサンプルなので、一番お安い SKU で作成しておきます。 ネットワーク設定は、前編で作成した App Service と、作業を行うローカルマシンから接続できるようにしておいてください。

Active Directory 管理者の設定

SQL Database は、ただ作成しただけだと Azure Active Directory を使ったログインが行えません。 これをできるようにするには、 SQL Database に対して、 Active Directory に存在するユーザーに対して管理者権限を割り当てる必要があります。 この作業は Azure Portal 上から実行できます。

まず先ほど作成した SQL Server のメニューから [Active Directory 管理者] のメニューを選択します。 [管理者の設定] ボタンを押下して、先ほど作成した Azure Active Directory 上のユーザーを選択します。 設定が完了したら、忘れずに [保存] ボタンを押下します。

f:id:masatsuna:20200720004340p:plain
Active Directory 管理者の選択

これで Azure Active Directory 上のユーザーを用いて SQL Database にアクセスできるようになりました。

データベースの初期化

続いて先ほど作成した Azure Active Directory のユーザーを使用して、 SQL Database に接続してみます。 今回はローカルマシン上にインストールした SQL Server Management Studio を使用します。

接続先の設定は以下のように行います。 ポイントは [認証] に [Azure Active Directory - MFA で汎用] を選択することです。 Azure Active Directory の方で MFA を有効にしていない場合も、これを選択します。

f:id:masatsuna:20200720004847p:plain
接続情報の設定

正常に接続できると、 SQL Server Management Studio の [オブジェクト エクスプローラー] は、以下のような表示になります。

f:id:masatsuna:20200720005247p:plain
接続完了後

ここでアプリケーションの使用するテーブルを作成しておきましょう。

マネージド ID をユーザーとして追加する

続いて、前編で作成した App Service のシステム割り当てマネージド ID と、ユーザー割り当てマネージド ID を、 SQL Database のユーザーとして追加します。 Azure Active Directory 上で、システム割り当てマネージド ID は App Service のリソース名である [app-demo0709] として登録されています。 またユーザー割り当てマネージド ID は、作成したリソースの名前である [uami-app-demo0709-01] 、 [uami-app-demo0709-02] として登録されています。 これらのユーザーを、 SQL Database でも利用できるように、以下の CREATE USER 文を実行します。

CREATE USER [app-demo0709] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [app-demo0709];
ALTER ROLE db_datawriter ADD MEMBER [app-demo0709];
GO

CREATE USER [uami-app-demo0709-01] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [uami-app-demo0709-01];
ALTER ROLE db_datawriter ADD MEMBER [uami-app-demo0709-01];
GO

CREATE USER [uami-app-demo0709-02] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [uami-app-demo0709-02];
ALTER ROLE db_datawriter ADD MEMBER [uami-app-demo0709-02];
GO

これでシステム割り当てマネージド ID 、ユーザー割り当てマネージド ID を使って SQL Database にアクセスする準備ができました。

App Service の設定

App Service に対して、マネージド ID を使って SQL Database にアクセスするための設定を行っていきます。 システム割り当てマネージド ID を使用する場合と、ユーザー割り当てマネージド ID を使用する場合で、設定方法が若干異なりますので、個別に解説します。

システム割り当てマネージド ID を使う場合

データベース接続文字列の設定をAzure Portal の App Service の [構成] から行います。 今回のアプリケーションは BooksDbContext という名前のデータベース接続文字列を使っているので、この値を Azure Portal で上書き設定します。

App Service の [構成] メニューを開き、 [アプリケーション設定] タブの下部にある [接続文字列] に、データベース接続文字列を定義します。 データベース接続文字列は、以下のようなフォーマットで作成します。 接続先のデータベース名を忘れずに入力するようにしましょう。

server=tcp:<server-name>.database.windows.net;database=<db-name>;UID=AnyString;Authentication=Active Directory Interactive

今回は以下のような設定となります。

f:id:masatsuna:20200720011606p:plain
データベース接続文字列の設定

設定を保存して再度アプリケーションにアクセスすると、データベースアクセスが正常に行われたことが確認できます。*1

f:id:masatsuna:20200720012116p:plain
実行結果

ユーザー割り当てマネージド ID を使う場合

ユーザー割り当てマネージド ID を使用する場合、どのユーザー割り当てマネージド ID をアプリケーションが使用するか設定を行う必要があります。 この設定方法には AppAuthentication の接続文字列を使用する方法と、データベース接続文字列に直接記述する方法があります。

AppAuthentication の接続文字列を使う方法

AppAuthentication の接続文字列を使う場合、接続文字列の設定はシステム割り当てマネージド ID の設定方法と変わりありません。 環境変数AzureServicesAuthConnectionString という名前のキーを定義して、そこにユーザー割り当てマネージド ID のクライアント ID を設定します。 App Service の場合、 Azure Portal の App Service の [構成] 画面から、 [アプリケーション設定] を追加することで、環境変数の代わりとすることができます。

ユーザー割り当てマネージド ID を使いたい場合、 AppAuthentication の接続文字列*2は以下のようなフォーマットとなります。 AppIdの部分に、ユーザー割り当てマネージド ID のクライアント ID 設定します、

RunAs=App;AppId={ClientId of user-assigned identity}

この例では、 uami-app-demo0709-01 のユーザー割り当てマネージド ID (クライアント ID が b1a7836c ... で始まるやつ)を使用するよう構成しています。 ユーザー割り当てマネージド ID のクライアント ID については、前編を参照してください。*3

f:id:masatsuna:20200720013234p:plain
AppAuthentication の接続文字列設定

設定を保存して再度アプリケーションにアクセスすると、データベースアクセスが正常に行われたことが確認できます。*4 実行結果は前述のものと同様なので割愛します。

データベース接続文字列を使う方法

データベース接続文字列を使う場合、前述した AppAuthentication の接続文字列は一切使用しません。 すでに前述の作業を行ってしまったいる場合は、 AzureServicesAuthConnectionString のアプリケーション設定を削除してから、以下の作業を行ってください。

データベース接続文字列に対してユーザー割り当てマネージド ID を組み込む場合、既に設定しているデータベース接続文字列を一部修正します。 設定済みのデータベース接続文字列には、 UID という名前の項目が入っていると思います。 この設定値は AnyString となっていますが、この値にユーザー割り当てマネージド ID のクライアント ID を設定します。

この例では uami-app-demo0709-02 のユーザー割り当てマネージド ID (クライアント ID が ab5a4564 ... で始まるやつ)を使用するよう構成しています。 ユーザー割り当てマネージド ID のクライアント ID については、前編を参照してください。

f:id:masatsuna:20200720014623p:plain
データベース接続文字列にユーザー割り当てマネージド ID のクライアント ID を設定する

設定を保存して再度アプリケーションにアクセスすると、データベースアクセスが正常に行われたことが確認できます。*5 実行結果は前述のものと同様なので割愛します。

まとめ

全 3 回にわたって、 App Service から SQL Database に対してマネージド ID を使用してアクセスする方法を解説してきました。 概念ややり方さえわかってしまえば、マネージド ID (特にユーザー割り当てマネージド ID )は非常に便利に活用できるものです。 徐々にマネージド ID に対応したサービスも増えてきていますので、今後はもっと使う場面も増えてくるかもしれませんね。

*1:設定を保存してから実際に反映されるまで若干タイムラグがあります。

*2:AppAuthentication の接続文字列については、以下を参照してください。 docs.microsoft.com

*3:[エンタープライズアプリケーション] の一覧画面では、 [クライアント ID ] は [アプリケーション ID ] と表記されています。

*4:設定を保存してから実際に反映されるまで若干タイムラグがあります。

*5:設定を保存してから実際に反映されるまで若干タイムラグがあります。