新着記事

メインの開発機として MacBookPro 2019 16インチ Intel CPU を使っています。

ちょっとでも負荷のかかる処理をさせると、すぐファンが最高速で回ってしまいます。会社での使用時は問題ありませんが、在宅で静かな部屋の中で使っている場合、なかなか不快です。

今回、そのファンの音をなんとか静かにしようと試行錯誤したのでその記録を書きます。

M1 Mac はとても静か

おすすめ度: ★★★

主題から逸れますが、Apple Silicon M1 Mac は、Intel の MacBookPro と比較してとっても静かです。

そもそも M1 Mac の MacBookPro ではない MacBook Air は、ファンレスなので無音です。

しかし、MacBook Air は、CPU に高負荷をかけ温度が上がると、CPUの処理能力に制限を設けて温度を下げるため、開発業務には不向きです。開発業務に使うのであれば、 MacBook Pro が良いでしょう。

M1 Mac の大きな欠点として、同時に1つの外部ディスプレイしか標準で使えないことがあります。

この制限があるため、機種変更をためらっている方もいると思います。私もそうでした。

ただし、DisplayLink のチップを搭載したディスプレイアダプタをつければ、複数ディスプレイ出力に対応できます。DisplayLink チップを使うにあたり、今度は CPUリソースの消費や描画遅延が気になりますが、気にするほどの負荷はまったくありません。私の使っている機種は Plugable というブランドのものですが、全く問題なく、非常に快適です。

https://www.amazon.co.jp/dp/B08F2TSR43/

M1 Mac は、開発環境も Intel Mac 同等のものが現在は使えます。特に Docker が早いと感じます。よっぽど古いミドルウェアを扱ってない限り、問題なく開発できますので、今後開発をされる方は M1 Mac がおすすめです。

ファン付きPCスタンドを使ってみる

おすすめ度: ★☆☆

Intel の MacBook Pro の話に戻します。まず、ファンの回転数を下げるために本体を冷却させようと、ファンつきのノートPCスタンドを買ってみました。

使ってみましたが、キーボードが打ちにくくなる割りに、大した効果は見込めませんでした。5℃くらい下がったかも…と感じなくもないですが、高負荷の処理をすると結局最高速にファンが回るため、たいして変わりがありません。買わなきゃよかったと思います。

ゴム足で傾けてみる

おすすめ度: ★★☆

エアフローが少し改善されるかと思い、Mac の奥側のデスクにゴム足を貼り付け、本体を傾けて隙間を作ってみました。

結果、冷却効果は変わりませんでしたが、本体角度の影響か騒音がまろやかになり、不快感が減りました。コストも低いので、おすすめです。

後ほど、100円ショップでも同様の意図のゴム足が売ってたので、比較的一般的な方法のようです。

コストが安い割に、心理的メリットが大きいので試されることをおすすめします。冷却効果はほとんどなさそうです。

TG Pro を使ってソフトウェアでファンコントロールをする

おすすめ度: ★★☆

TG Pro というアプリが販売されており、インストールすると、温度センサーの温度とファン回転数の関係を制御できます。

(2021-08-23 現在、半額セールで JPY 1155)

冷却されるわけではないのですが、CPU温度70℃近辺のファン回転数を抑えることで、少しの消音化ができます。

それと、各種温度センサーやファン回転数を把握したり、メニューバーにファン回転数が出るのは使っててなかなか楽しいです。買って良かったと思いますし、常用しています。

↑MacBook Pro は多くの温度センサーが搭載されており、それぞれの温度を確認できる。

↑メニューバーに温度とファン回転数が出せる。

ファン制御は、最悪ハードウェア故障などにつながるため、扱いは自己責任となります。アプリ内でも、制御機能を有効にする際に警告が出ますので、よく理解して使ってください。

試用で15日間使えますので、興味があれば使ってみると良いでしょう。

Intel Power Gadget で CPU 周波数と温度を監視する

おすすめ度: ★★☆

こちらも直接冷却につながりませんが、温度を監視するのに Intel Power Gadget が便利です。
Intel のサイトからダウンロードでき、無料で使えます。

https://software.intel.com/content/www/us/en/develop/articles/intel-power-gadget.html

CPUの動作周波数と温度、電力、そしてシステムがCPUに要求している周波数などがモニタリングできるので、発熱する原因の調査に有効です。後述する、クロックアップ禁止の動作確認にも使えます。

Turbo Boost Switcher Pro でクロックアップを禁止する

おすすめ度: ★★★

Intel Mac の CPU は、Turbo Boost というテクノロジによって、処理量によって動作クロックが随時変更されるようになっています。私の Mac は 定格2.3GHz 動作ですが、負荷の高い処理を行おうとすると 4GHz ほどの動作クロックになるようです。

とはいえ、この Turbo Boost はバッテリーを多く消費し、発熱も高くなるため、安定動作を求めて OFF にする場合も多いようで、実施を記録したブログも多く見つかります。

高速化の処理を無効化するため、処理低下が感じられそうに思いますが、他のブログでは、多くが体感的な処理速度はそれほど感じかったと書いています。

実際、私も Turbo Boost を無効化したところ、遅くなったという感じはまったくしませんので、発熱を抑えたい方は Turbo Boost の無効化をおすすめします。

Turbo Boost を無効化するのは、Turbo Boost Switcher Pro というアプリを購入して実行する必要があります。起動時に自動的に無効化するには Pro 版が必要で、買い切り10ドル弱です。

http://tbswitcher.rugarciap.com/

(サイトの見た目はけっこう怪しい感じ)

他の紹介記事

Turbo Boost Switcherのご紹介： Macの爆音爆熱問題はTurbo Boostをオフにして解決しよう

Turbo Boost Switcher で Turbo Boost を無効化した後に、Intel Power Gadget で CPU のグラフを見ると、システムが CPUのオーバークロックを要求してるのをガン無視してるのがわかります。

↑矢印の箇所で開発環境を起動。CPUのオーバークロック要求が出ているが、オーバークロックされない。

Mac をデスクの下に置く

おすすめ度: ★★★

気になるファン音を直接耳に入れないようにするため、試しに机の天板の下(キャビネットの上)に Mac を隠すように置いてみたら、ファン音がほとんど気にならずかなり快適になりました。非常におすすめです。もっと早く気づけばよかったです。

つまり、クラムシェルモードで使うということです。Mac のキーボード、トラックパッド、タッチバー、指紋認証などが使えなくなってしまうデメリットが大きいですが、ファンノイズがうるさいことに比べれば小さいデメリットです。机の上がすっきりする副次効果もあります。

クラムシェルモードといっても、完全に閉じてしまうとキーボードの隙間からの吸気ができなくなってしまうので、本体温度が上がってしまいます。

2016? 以前の MacBook は、磁石でディスプレイの開閉をセンシングしてたため、磁石をキーボード左側に置くことで、ディスプレイを閉めたと錯覚させることができました。

最近の MacBookは、開閉センサーが磁石ではなくディスプレイヒンジ部に入っている傾きセンサーになったので、磁石をmacの上に置くことでディスプレイをOFFにする擬似クラムシェルモードはできなくなりましたが、傾きセンサーには遊びがあるため、2cmぐらい開けても閉まってると認識されます。吸気のため、それぐらい開けておくと、温度上昇は普通に使っているのと同じぐらいに保てます。

• Django, Nest, Laravel, Rails などの サーバサイドアプリ(APIサーバ)
• Vue, React などの Webクライアント
• iOS, Android 用の モバイルアプリクライアント

これらを組み合わせてサービスを作ることはよくあり、TORICOでもそうです。

Webクライアントとモバイルアプリクライアントは役割として同じものになるので、同じような感覚で開発を始めることはよくあります。

しかし、アプリのファーストリリースが終了し、運用開発のフェイズとなった時、同じような感覚で機能追加を進めていこうとするとうまくいきません。モバイルアプリは、非常にリリース速度が遅いのです。

アップデート容易さの比較

サーバサイドアプリ、Webクライアント、モバイルアプリクライアントをそれぞれ並列で比較した時、それぞれの更新の容易さ、障害時のインパクトは以下のようになると考えます。

Webクライアントとモバイルアプリクライアントは、使用用途としては同じですが、アップデート時の性質はまったく逆です。

Webクライアントは、ブラウザでアクセスすれば常に最新版のプロダクトが使えます。これはほぼ必ず自動的に入手でき、古いバージョンがそのまま使われることはまずありません。

比較して、モバイルアプリクライアントは、アップデート作成時にプラットフォーマー( Apple, Google ) の審査をまず通さなければならず、審査を通すのに数日が必要です。アップデートを提供したとしても、利用者の設定によっては自動アップデートはされないため、古いバージョンを使い続けられることもありあす。

更新難度を下げるためのテクニック

モバイルアプリのコードを動的にアップデートする方法が存在します。ゲームで多く使われています。

他に、古いアプリバージョンでAPIアクセスした時にアップデートを促してサービスを受け付けないなどの対応も考えられます。ただしどちらも基本的にプラットフォームの規約違反なので、通常は選択できません。

更新難度が高い理由

例えば、APIのエンドポイントURLをリファクタリングにより更新したい場合、Webアプリの場合はクライアントも同時に更新してリリースすれば、大抵は問題ありません。

しかしモバイルアプリのクライアントを扱っている場合、旧バージョンのユーザーを考慮して、古い仕様のAPI エンドポイントもしばらく(年単位で)残しておく必要があります。この非生産的なサービス保守は、モバイルアプリ運用をする上での大きな負荷となります。

そのため、モバイルアプリクライアントでサービス運営をする場合、なるべくクライアントで計算(判断)をさせない設計とした方が素早いサービス改修が行えます。

アップデート頻度を下げる

例えば日付時刻をモバイルアプリクライアントで表示する場合。

DBに日時型で入っている情報を、どこかで文字列にフォーマットする必要がありますが、私は文字列へのフォーマットは大抵サーバサイドで行い、文字列でモバイルアプリに送るようにしています。また、何かのリスト表示時の並び替えなども、可能であればすべてサーバサイドで行い、なるべくモバイルアプリクライアントでの計算は減らします。

そうしないと、何かの調整時…例えば、日付時刻を表示する箇所に「未定」と表示したいケースとなった時、わざわざ新たなアプリをビルドしてプラットフォーマーの審査を通過させ、新旧両バージョンのクライアントが同時に存在することを考慮してAPIの改修も行わなくてはならないという、目指す成果に対して非常に時間と手間のかかる運用開発をしなければいけません。

さらに、そのアプリに問題があり、「未定」と表示しなければならない箇所でアプリがクラッシュしてしまうビルドをリリースしてしまうと最悪です。ある一定の利用者は、不具合のあるバージョンを更新することなく、使い続け、障害が発生し続けます。それがプラットフォーマーの目に止まった場合、最悪でアプリの配信停止までありえます。

この困難さは、Web畑の開発者からの理解は難しいかもしれません。私の感覚では、モバイルアプリをリリースし運用開発を行っていくのは、コード量が同じだとするとWebクライアントの5倍大変です。5倍時間がかかるとも言えます。目標が同じなのに、4倍の回り道が追加で強いられる感覚です。

Webクライアントの運用開発

逆に、Vue や React などの Web クライアントの場合、更新が簡単な上に何か不具合があっても致命的な問題には発展しづらいため、クライアントサイドでもサーバサイドでもできるような処理は、なるべくクライアントサイドに寄せていったほうが素早いリリースが行えます。

クライアントサイドの改修ミスが、不正な支払いにつながったりセキュリティホールになることはほとんどありません(これはモバイルアプリでも言えることですが)。逆に、サーバサイド改修では、ちょっとした修正ミスがセキュリティホールにつながったりコアサービスの停止になることは少なくありません。そのため、Webクライアントのほうがサーバサイド改修より気軽に新規リリースができます。

気軽に改修できる分、どちらでも行えるような処理はWebクライアント側になるべく寄せることで、リリース頻度を高め、早く顧客体験を上げることができ、サーバの負荷軽減にもつながります。

まとめ

Webクライアントとモバイルアプリクライアントは、行う仕事としては同じようなものですが、

• Webクライアントは更新が容易で不具合発生時のインパクトも少ないため、よりリッチに設計していったほうが良い。
• モバイルアプリクライアントは、更新に時間がかかり、更新も強制させることはできないため、よりシンに設計し、サーバ側で表示内容などをコントロールしたほうが良い。

と、逆の運用開発方針で進めていったほうが、プロジェクトをうまく進捗できると考えています。