メインPCの構成を変更

昔に書いて放置していた記事を放流しておきます。
大体今年の春頃の話です。

プライベート兼個人事業関連用で使っているメインPCでもたつきを感じるようになったので、パーツを変更しました。

CPUクーラーのディスプレイに映っているのは、うちの杏ちゃんです。
マジで可愛すぎる。

構成変更前後のパーツ比較（最終構成）

構成変更は、途中でトラブルがあり計2回変更したので、先に最終的な構成を紹介します。

	変更前	変更後
CPU	Intel Core i7 9700K	Intel Core i9 12900K
マザボ	Asrock Z390 Steel Legends	MSI MAG Z690 TOMAHAWK WIFI DDR4
メモリ	Crucial Ballistix RGB 32GB	Corsair VENGEANCE RGB PRO 32GB
グラボ	Palit GeForce RTX 2080 SUPER GRP	変更なし
SSD	WD Black SN750 NVMe SSD 1TB	変更なし
電源	Thermaltake Toughpower Grand RGB 850W Gold	変更なし
PCケース	Fractal Design Define XL R2	Fractal Design Define 7 Compact Light Tempered Glass
CPUクーラー	Fractral Design Lumen S28 RGB	Corsair H150i ELITE LCD

ゲームも開発もかなり快適になったので大満足です。拡張機能もりもりのVSCodeの起動が、5秒から1秒になりましたからね。

構成変更の方針

構成変更するにあたってパーツ選びの方針を決めてから購入しました。

更新しなくてよいパーツは更新しない
光るパーツがあるならできるだけメーカーを統一する
Z系チップのマザボを使う（OCするので）
DDR5はコスパが悪いのでDDR4対応のマザボにする

これらを踏まえてパーツを購入して進めていきます。

パーツ変更（1回目）

さて、構成変更する理由は「もたつきを感じる」だったので、CPUを変更することを主軸にしてパーツを変更していきます。
闇の時代を超えた第12世代のCore i9 12900Kで構成を考えます。
また、今使っているPCケースが重すぎるのでもう少し軽いPCケースに変更します。

1回目の構成変更では以下のようになりました。

	パーツ	選定理由
CPU	Intel Core i9 12900K	ワッパはダメだけどコア数多い
マザボ	MSI MAG Z690 TOMAHAWK WIFI DDR4	Z690、光らなくて黒い、ドラゴンがいない
PCケース	Fractal Design Define 7 Compact Light Tempered Glass	Fractal Design信者、たまにはガラスパネル使ってみるか
CPUクーラー	Corsair H150i ELITE LCD	正規品のLGA1700互換性パーツが取れなかった、Corsair使ってみるか

開発機としても兼用しているPCなので、現状一部の命令セットがサポートされていないためRyzenはまだ避けています。
と書きつつも、Ryzenで困ることは開発でも現状はまずないので、コスパとかソケットの互換性などで自分の使いたいCPUを選んでいくと良いですね。
友人に勧めるのはRyzenが多いです。

この構成で動作検証をしていったのですが、特定のゲームやアプリケーションを起動すると、メモリ関連のエラーでブルスクが出るようになりました。
といわけで、メモリを購入することになります。

メモリ自体は元々のパーツで動かしている分には問題なかったので、相性問題かもしれません。

パーツ購入（2回目）

CPUクーラーをCorsairにしたので、同じコントローラで使えるようにメモリもCorsairにします。

	パーツ	選定理由
メモリ	Corsair VENGEANCE RGB PRO 32GB	CPUクーラーがCorsair、もうここまで来たら光らせるか

さて、この後に動作検証していって、ブルスクが一度も出ることもなく問題ないことが確認できました。

最終構成

最終的な構成は以下のようになりました。

	変更後
CPU	Intel Core i9 12900K
マザボ	MSI MAG Z690 TOMAHAWK WIFI DDR4
メモリ	Corsair VENGEANCE RGB PRO 32GB
グラボ	Palit GeForce RTX 2080 SUPER GRP
SSD	WD Black SN750 NVMe SSD 1TB
電源	Thermaltake Toughpower Grand RGB 850W Gold
PCケース	Fractal Design Define 7 Compact Light Tempered Glass
CPUクーラー	Corsair H150i ELITE LCD

おわりに

構成変更後は、ゲームをしながらの他の作業でも、もたつくこともなくなり非常に快適になりました。
消費電力が高いのがネックですが、そこはAMDとIntelとで切磋琢磨してより良いCPUが将来でることを祈ります。

【2022/11/16 追記】 AG03/06がちょいちょい切れる

CorsairのCPUクーラーが悪いわけではないと思いますが、YamahaのAG03のドライバとCorsairのRGBコントローラ系のドライバとで干渉しているようで、今はCorsair側のドライバをアンインストールしています。

2022-11-16

コンテナ化することが正しいか？

年末年始がバタついていそうで、アドベントカレンダーを書く時間もなさそうなので怪文書を投稿します。
他にも活動している中で共有できそうな項目などがあれば、怪文書として投稿する日があるかもしれません。

私は、会社員としても茨谷企画としても、定期的に「このアプリをコンテナ化すべきか？」という相談は受けることが多いです。
この問いに関しての自分が今まで他者へしてきた回答や、自分なりの考えについて書いておきます。
これが正しいといったこともないですし、全く別の考えの人もいるとは思うので最終的には意思決定者がどう判断すべきかということを考える必要があります。

個人的にはコンテナを使った開発・運用が好きなので推奨したいところではあるんですけどね。

コンテナ化すべきか？

「コンテナ化すべきか？」という問いは、背景がそれぞれの組織や人によって全く持って異なります。

流行ってるからうちもコンテナ化したい
コンテナ化すると開発・運用が楽になるかもしれない
採用でコンテナ技術を利用していると有利に働くかもしれない

ここに書かれていないことも多くありますが、相談にのるケースとしてはこういった理由が挙げられます。
1つ目は、導入から運用までやり抜く覚悟があるならありかもしれませんが、それだけの理由であれば余りオススメしません。
2つ目は一旦飛ばして3つ目ですが、確かにそういった側面もありそうです。
開発しているアプリによりますが、Vagrantでの開発なんてもう嫌だという時があるかもしれません。

さて2つ目の「コンテナ化すると開発・運用が楽になるかもしれない」は、はたして本当でしょうか？

コンテナ化すると開発・運用が楽になるか？

ケースバイケースです。
楽にならないケースでは、どういった特徴があるのかを個人的にまとめておきたいと思います。

課題について把握できていない
技術を新規導入しても、運用できる正社員・もしくはフルタイムの人がいない
too muchな技術を利用する

必ずしもこれに該当しているからといって、楽にならないわけではないですが、大体はこういった傾向があるかなと母数が10数程度ではあるものそう判断しています。

では、楽にならない理由について書いておきます。

課題について把握できていない

課題を正しく把握できていない場合は、コンテナ化だけではなく他の技術採用についても失敗する可能性があります。
それこそtoo muchな技術であったり、そもそも本来解決したい課題を解決できていないということになりがちです。

ということで、コンテナ化云々よりかは現状の課題について見直すのが先に必要です。
必要であれば一緒に課題の洗い出しや壁打ちなどもやりますが、それでも本当に解決すべき課題を見つけるのは難しいです。
現在の課題についていえばある程度把握できるかと思いますが、今後その組織・個人のサービスの方向性や事業戦略を踏まえた上で、「将来のある時点までに〇〇が必要だ」といったことも加味した上で判断するのが望ましいので、かなり難しい判断が迫られます。

100%の確信は得られないにしても、それがコンテナを利用することで解決するのであれば今すぐにでもベットしましょう。
そうでないなら、コンテナに知見がある人や組織にお金をかけてでも相談してみてください。
自分が見ている視座では見えていないことも見えてくるかもしれません。

技術を新規導入しても、運用できる正社員・もしくはフルタイムの人がいない

コンテナ化するのであれば大体の場合、新規導入になるケースが多いと思います。

フルタイムである必要はないものの、何人かがコンテナについて運用・メンテできるような事業状況でなければ、そこにベットするのはリスクが高いように思います。
その状況がコンテナ化で覆せるのであればベットしても良いとは思いますが、そういったケースは本当にあるのかは分かりません。

too muchな技術を利用する

これは昔から様々な方々が言っていることですが、明らかにtoo muchな技術を採用するのは避けておいた方が良いです。
近い将来必要になるが今はtoo muchというケースは例外ですが、基本的には「必要になりそう」で導入するのは勧めません。

もし必要になりそうなのであれば、導入するのではなく変更しやすいアーキテクチャにしておくなどの工夫をしておくのが大事です。

too muchなケースは、「サービスが1つしかないのにk8s クラスタで構築する」といった場合になります。
サービスがというのはクライアントから見て1つではなく、社内で管理しているWebアプリケーションが1つという意味です。
少なくともk8sではtoo muchなので、Cloud RunやApp Runner、Heroku、Amazon ECSなどの方が適しているかもしれません。

有識者がもし近くにいれば相談してみて、どういった技術が最適そうかを壁打ちしてみるのも良いでしょう。

コンテナ化したい

今までの話を踏まえて、それでもコンテナ化するべき、したいというのであればコンテナ化をするためにどういった作業が必要なのかを把握する必要があります。
新規立ち上げと既存サービスのコンテナ化は全く異なる勘所があるので注意が必要です。

どちらにも共通しているのは、

モニタリングに必要なAgentなどのサイドカーが想定している環境で動作するのか？

という点です。
これは技術検討の段階で必ずチェックしておきます。

新規サービスでコンテナ化したい

新規サービスでコンテナ化するのは、比較的容易です。
社内で決まっている技術があれば、それを利用するのが望ましい場合が多いので、それに従ってください。
社内で初めてコンテナを導入する場合は、公式が載せているチュートリアルや、様々な方や組織が投稿している構成を参考に立ち上げます。

docs.aws.amazon.com

後は何とかリリースに間に合わせましょう。
全く知見がない状態でリリースに間に合わないと最初から分かっている場合は、スケジュールをずらすか別の技術に切り替えるのも1つの手段としてはアリです。

既存サービスをコンテナ化したい

非常に難易度が高いです。
以前、私が現時点で所属しているスタディストで書いた記事がありますが、約1年半かかっています。

規模としては、大規模ではないものの2013年頃から開発し続けられているサービスというのもあって、下準備や入念なテストや移行期間を設けて1年半という歳月がかかりました。

この既存サービスのコンテナ化でやったことを振り返ると、以下のステップが挙げられます。 ※1

やること・やらないことの整理
関係者への周知と教育
他部署を含めたリリースフローの把握と見直し
アプリケーションコードを12Factor Appになぞらえて携帯性を高める
開発、CI/CDからコンテナ化する
ステージング環境やテスト環境のコンテナ切り替え
本番のコンテナ切り替え

ここに書かれていない項目もあるかとは思いますが、個人的には大体これらに集約されると思っています。
この中で何が時間が難しいのか？といえば、携帯性を高めると本番の切り替え、そして関係者への周知と教育です。

長くなるので端的に書きますが、「携帯性を高めた」と思っていてもコードの全てを把握できているわけではないので、必ずどこかで落とし穴にはまります。
精査しながら進めるのも良いですが、早い段階から単体テストやE2Eテストなどを利用して、トライアンドエラーを繰り返しながら進めるのが個人的にはオススメします。

「本番の切り替え」は、携帯性を高めるにも関連していますが、並行期間の有無、本番環境特有の環境差分でハマりやすいです。
並行期間がある場合は、旧環境とコンテナ環境とで処理可能なリクエストが変わらないかどうかといった観点が出ます。
サービスを停止して切り替えなどはオススメできませんし、いきなり全てコンテナへリクエストを飛ばすのもオススメできないので、並行期間はあった方が良いです。
本番環境特有の環境差分は、コンテナに限らずハマります。
絶対にはまるので、早い段階から自分のみ、自組織のみでもいいので検証できるようにしておきましょう。
ほぼほぼ何かあります。

関係者への周知と教育は、時間がかかりますし相手にとっても非常に負担になります。
サービス開発者からしたらサービス開発に必要な技術も勉強しながら、コンテナについても学ばなければならなくなります。
心理的負荷もかなりあるかと思います。
であれば、サービス開発者にはまず理解しなくても開発・運用できる環境を提供するというのをゴールとして設定すべきです。
こうすることでできるだけ認知不可を下げるように勤めます。
構成図を含め、図示した移行前後の差分などを可視化しておくのも良いでしょう。
プロダクトマネージャーには、事前に移行スケジュールやプロダクトロードマップを踏まえながら、それぞれのスケジュール・ロードマップを調整することが大事です。
いきなり「〇〇月××日にはリリースしないでください」となると、お互い困ることになります。
早めに調整しておくことで、CSや営業に周知も早く行うことができます。
これはサービスやアプリの利用者にも早く情報が届くということに他なりません。
こういったことを定期的に根気強く続けていくことが必要です。

さいごに

ここまで読んでくれた人は、怪文書を全て読んだ方か、ここまでスクロールして飛ばしてきた人かと思います。
どちらにせよ、ここまで見てくれてありがとうございます。

今だと古い資料かもしれませんが、CNCFが公開しているCloud Native Trail Mapという素晴らしい資料があります。

github.com

こういった資料や12Factor Appをベースにしながら、コンテナ化をする必要があればしていきましょう。

またコンテナ化するのがゴールではありません。
あくまで課題を解決するための手段であり、スタート地点でしかないことに注意してください。
もし相談にのってほしいなど興味がある場合は、[茨谷企画の簡易的なページ](https://zuki.dev/work/）があるので、そちらをご覧の上、ご連絡ください。

それでは良いコンテナライフを。

※1 それぞれの話について語ると、どれに関しても長くなってしまうので割愛しますが、もし知りたい人がいたらお声がけください。

2022-11-15

jpドメインの管理はGoogle Domains以外がいいかも

茨谷企画という屋号で活動しているので、それに合うjpドメインを大分前に取得しています。
その時にGoogle Domains以外にした話です。

TL; DR

Google Domainsで取得した場合、whoisに登録者情報が全て公開される
Google Domainsでjpドメインはwhoisの代行が 不可能
個人の住所を設定していると、本名から住所まで全て公開される
whois代行してくれるバリュードメインにjpドメインだけ移管してる

jpドメインのwhois代行ができない

Google Domainsでは、jpドメインのwhois代行ができません。
そのため、jpドメイン取得時に設定した氏名、住所が公開されることになります。

これだと個人事業主で事務所を別に持っていない場合は、気持ちとしては嫌ですし防犯の観点でも避けるべきです。

jpドメインは登録情報を公開しなきゃいけない？

昨今の事情もあり、必ずしもそうであるべきではないようです。

jprs.jp

理由があれば非公開の申請は受け付けていると書かれています。

whois代行をやっているサービス

いくつか代行が可能なサービスはあるようですが、今回は使ったことがないバリュードメインを利用することにしました。

www.value-domain.com

大体の操作がマニュアル化されているので問題なく操作できましたし、最低限利用する分には問題ないかもしれません。
まだ本格運用はしていないのでこれから問題が出てくる可能性はあります。

他のサービスでも代行ができるのはいくつかあるので、自分にあったものを探すとよさそうです。

## さいごに

この記事を書いたということは、一度公開状態になったということです。
他の人がこういう失敗をしないように祈ります。

2022-11-14

GitHub Actionsで並列処理を作っていてヒヤッとした話

具体的な並列処理に関しては、会社ブログなどで公開するとは思いますが、GitHub Actionsで並列処理を作っていてヒヤッとした話を書いておきます。

TL; DR

1Workflowの合計時間ではなく、1Jobごとの時間でBillable timeを算出
10sec程度で終わるJobを100並列にすると、Workflowの合計時間が20分程度だとしてもBillable timeは100分になる
Jobを変に並列化するとすぐに無料枠が消費される
Action実行後すぐにBillable timeを見ても0なので、必ず時間をおいて確認する

GitHub Actionsの課金について

About billing for GitHub Actions に詳細が書いてありますが、大まかにまとめると、以下のような特徴になります。

Public repositoryであれば基本無料（一部例外あり）
Internal, Private Repositoryは無料枠の範囲内で利用可能（従量課金で増枠可）
従量課金の単位は分
実行時間にOS別の乗数がかけられた値がBillable time
実行時間が0秒以外の場合、単位が分になるように切り上げ（12秒なら1分）

となります。
また、Billable timeはWorkflowの1実行の合計（Jobの合計値）ではなく、JobごとにBillable timeが算出されます。

この仕様を甘くみていて、少しだけヒヤッとしました。

200並列で実行する

ある処理をmatrixを使って200並列で実行しようとしていました。

200並列ではないですが、以下がWorkflowのイメージとしては近いです。

jobs:
  prepare:
    runs-on: ubuntu-latest
    outputs:
      matrix: ${{ steps.set-matrix.outputs.matrix }}
    steps:
      - uses: actions/checkout@v3
      - id: set-matrix
        run: |
          echo "matrix={\"number\": [$(seq -f '"%g"' -s ',' 1 200)]}" >> $GITHUB_OUTPUT

  echo:
    runs-on: ubuntu-latest
    needs: prepare
    strategy:
      matrix: ${{ fromJSON(needs.prepare.outputs.matrix) }}
    steps:
      - uses: actions/checkout@v3
      - run: sleep 10; echo ${{ matrix.number }}

これを書いていた時には、prepareとcheckの合計時間を元にBillable timeが算出されると思っていたのですが、
先に書いたようにJobごとにBillable timeが算出されるため、
checkが10秒で終わるとしてBillable timeは100分になります。

つまりはGitHubの無料アカウントで利用可能な2,000分の1/20である100分を使うことになります。
Teamでも3,000分なのでかなり痛いことがよく分かるかと思います。

以下は、200並列した方に関しては個人ブログに貼るのは憚れるので、個人のPrivateレポにある実行ログの一部を張っておきます。 ' 200並列ではないもの、12秒程度のJobでBillable timeが1分になっていることが分かります。

これが200並列ということは分かりますね？

Billable timeが0になる？

実行後すぐに見ても、Billable timeが0になる場合があります。
以下は、サンプルではったWorkflowを実際に動かしたものなんですが、Billable timeが0でした。

これは、Billable timeがかかっていないわけではなく、まだ計算されていないだけです。
しばらく時間をおくと以下のようになります。

並列処理を組む時は、並列数によってはこの辺を注意しながら組むと良いですね。

さいごに

ヒヤッとしたといっていた通り、GitHub Enterpriseを使っていたのもあり大きな問題にはなりませんでしたが、
それでもかなり消費した枠は大きいものだったので反省しています。

GitHub Actionsで並列処理を組む場合は、最小単位が分でJobごとに算出されることを考慮して設計するのが重要です。

Self-hosted runnnerで実行するようにしておけば、こういった問題は起きないはずなので、
他にも似たようなことを気づかずにやらない人が出ないことを祈ります。

2022-11-11

RubyでRTX1300へSSH接続して設定ファイルを表示する

RubyからRTX1300へSSH接続して設定ファイルを表示するための備忘録です。

本来はnet-sshのみで実装する予定だったんですが、RTX1300のSSHサーバがRFC4254のSec 6.5にあるexecを実装していないようで、
open_channelを使って書く必要がありました。
既に似たようなことをやっているnet-ssh-telnetで軽い動作確認をした時のコードになります。

正直に言ってSSHして設定ファイルを表示するだけなら、expectコマンドを使ってシェルで書いた方が早いです。

コード

net-sshとnet-ssh-telnetを使っています。
パスワード認証のサンプルなので公開鍵はnet-sshのコードを見ながら変更してください。

require 'net/ssh'
require 'net/ssh/telnet'

# 環境に応じて書き換える
host = '192.168.100.1'
user = 'hoge'
pass = 'fuga'

ssh_options = {
  host_name: host,
  user: user,
  password: pass,
}
ssh = Net::SSH.start(nil, nil, ssh_options)

telnet = Net::SSH::Telnet.new(
  'Session' => ssh,
  'Prompt' => /^>\s+$/,
)

# エンコードを指定
# 設定する値はドキュメントを見てバージョンにあった値を設定
# http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/setup/console_character.html
telnet.cmd('console character en.ascii')

# show configなどで一定行が表示される場合にページングされるのを防ぐ
# これを実行しないとnet-ssh-telnetが待機状態になったままになる
telnet.cmd('console lines infinity')

# show configの実行結果を表示する
# net-ssh-telnetだと、最後に`> `が表示されてしまうので注意
puts telnet.cmd('show config')

特筆することはないのですが、以下2つの設定を実行するようにしておくと、
止まったまま全然動かないなと思うこともも少なくなるはずです。

# エンコードを指定
# 設定する値はドキュメントを見てバージョンにあった値を設定
# http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/setup/console_character.html
telnet.cmd('console character en.ascii')

# show configなどで一定行が表示される場合にページングされるのを防ぐ
# これを実行しないとnet-ssh-telnetが待機状態になったままになる
telnet.cmd('console lines infinity')

また、何故エラーが出ているのかが分からない場合は、ssh_optionsにverboseを追加するとデバッグ情報がみれます。

ssh_options = {
  host_name: host,
  user: user,
  password: pass,
  verbose: :debug,
}

2022-11-10

自宅でv6プラス固定IPサービスを使っている話を会社でしてきた

会社で自宅のネット環境について話したので、こちらでもリンクだけ貼っておきます。

docs.google.com

端的に言えば、「v6プラス」固定IPサービス」を自宅では利用して、v6プラスで問題になりやすいNAT周りを回避しているっていう話をしてきました。

5分程度の話なので詳しい話は大分端折っています。書いてあることは間違ってることはあるかもしれませんので、その時はコメントください。

もっとv6プラスについて詳細に知りたい人は、JPNE公式の解説本があるので読んでみてください。

www.jpne.co.jp

2022-11-01

macOSの1Password起動時に「You’ve used a newer version of 1Password on this device.」が出る

エラーのスクショを撮るの忘れていたんですが、macOSで1Password起動時にYou’ve used a newer version of 1Password on this device.というエラーが出る場合があります。

1password.community

ここを見るとベータ版を利用していた後に、安定版をインストールすると発生するようです。

対応としては、sqliteのデータベースファイルを移動もしくは削除すればOKです。

mv ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/Library/Application\ Support/1Password/Data/1password.sqlite ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/Library/Application\ Support/1Password/Data/1password-old.sqlite

データ残っていることで問題が起きていたとは思っていなかったですね。