手当たり次第に書くんだ

飽きっぽいのは本能

2024 年の自宅システムのテーマ

私自身が約20年の経験を持つエンジニアであり、それとほぼ同じ期間、自宅では自作のシステムを運用しています。

このシステムは Linux ベースで設計しており、初期は Samba でファイルサーバーを利用する程度でしたが、LDAP による認証情報の統合、Web サーバー(Apache/Nginx)、メールサーバーの導入(Postfix/Dovecot)、Xen/KVM での仮想化、そしてクラウドとの VPN 接続(固定 IP を得るため)、Ansibleでの自動化など、年に一回くらいはアップデートしてきました。特に仮想化はシステムの集約において素晴らしい効果がありましたし、Ansible は複雑なシステムを個人で構築するための最高のツールでした。

2022 – 2023 年は主にデュアルスタック化(IPv4/IPv6)を行いました。デュアルスタック化は手間がかかる一方で、現状では IPv4 で事足りるため、大した効果がないかもしれません。もちろん一部の環境ではネットワーク速度の向上が見込めるかもしれませんが、少なくとも私の環境ではそのような顕著な効果はありません。でも、IPv6 のナレッジを蓄えるには実践がベストであり、私の環境では BGP, OSPF/OSPFv3 も使用しています。また、Docker を利用した一部サービスのコンテナ化も行いました。コンテナも目から鱗の技術でした。確かに仮想化では大きすぎる最小単位を更に小さくしてくれたからです。

そして 2024 年のテーマは以下の通りです。

Kubernetes :

元々 Kubernetes は検証してきており、ある程度の挙動は知っていますが、この機に Kubernetes をメインでサービスを展開できる環境を整えます。もちろん、デュアルスタック環境を前提として Calico を使用して外部に BGP で接続する構成をとります。これで柔軟なネットワーク構成をとることができます。このアプローチはアプリサイドから Kubernetes を始めたエンジニアだと難しいかもしれません。 また、Helm を使用して複雑なマニフェストをパッケージ化します。ArgoCD も良いのですが、個人環境だとあっても使うだろうか?というのがあったので導入は見送っています。

Kubernetes の BGP 化について補足すると、通常、Kubernetes のネットワークモデルは NAT が中心ですが、NAT は既存ネットワーク環境にある程度影響を与えずに実装できる一方、ネットワーク全体の見通しが悪くなるデメリットもあります。このため、NAT を回避できる環境ではできるだけ NAT を使わない構成を考えた方が健全だと思っています(これはシステム管理者の目線によります)。

もう一つ、Pod のストレージアクセス用追加ネットワークに Multus を使用します。macvlan を使用することで、CNI を経由せずに直接ストレージにアクセスできるため、MTU の考慮なども含め、効率的にネットワークを利用できるようになる見込みです。

NextCloud:

Mac だと SMB マウントがいちいち面倒なので NextCloud を構築して Samba のフロントエンドにします。NextCloud は OSS で使用できるクラウドストレージのデファクトスタンダードと言って良いでしょう。実際、かなり快適に使えていますし、iPhone からもシームレスに使えます。難点は正しく環境を構築するのが難しい点です。NextCloud は、よくあるシステムの通り、Web サーバー、データベース、PHP (php-fpm) を使用します。また、Redis に代表されるインラインメモリデータベースも必要です。Web サーバーに関しても通常の構築では不足で、少しハードルが高めの rewrite 設定が必要なっています。コンテナや Snap でも提供されていますが、使ってみたところ中途半端な感じなので、現状では自力でミドルウェアから構築するのがおすすめです。

SSO:

これまでも LDAP を使用した認証情報の一元管理として、Samba や Posftix/Dovecot の認証を統合してきましたが、今回はクラウドっぽいシステムが増えるので、その LDAP をバックエンドにして Keycloak を導入、 SAML/ OAuth を使えるようにします。

PowerDNS/ phpIPAM:

PowerDNS/phpIPAM を連携し、IP アドレス管理の Web 化と同時に DNS のレコード管理を自動化します。実際かなり便利です。とにかくIP管理をExcelで行うことに強い抵抗感がずっとありましたが、IPAMを使用することで、かなり高度な管理を行えるようになります。ちなみに大企業(システム会社や通信キャリアでも)でも IP 管理を Excel で行なっているところが多いですが、IPAM にした方が良いですよ。

セキュリティ:

そろそろ RSA を卒業して ed25519 にします。SSH はそれで問題ないです。OpenVPN もサイト間 VPN、リモートアクセスともに全く問題なかったです。でも Web サーバーやブラウザなどはまだまだ完全ではないようですので注意が必要です。また、ed25519 にすると鍵が短くなって扱いやすくもなります。あと、迷惑メールが増えてきたので、メールサーバーで DKIM/DMARC を導入して対策できないかなと模索しています。

AI:

自宅システムに AI を導入しようとしており、KVM ホストに GPU も組み込みました。この GPU は KVM からパススルーして Kubernetes ノードにアタッチし、それを AI コンテナから利用します。どんな AI アプリを作るかは未知数ですが、とりあえず投資情報をまとめてくれる AI がいいなとほんのり思っています。

その他:

基本的にシステム管理の設計情報としてに Excel などのオフィスソフトやテキストファイルは排除したいです。GROWI、Git などで最新っぽく作ります。

多分断念すること:

KVM のブリッジに OVS-DPDK を導入して DPDK に対応させ、vHost-user-client で仮想マシンを接続しようと思いましたが、Ubuntu の場合では色々とセキュリティの問題があり多分諦めます。おそらく root で KVM を動かせば動きそうな気がしますが。

DPDK に関して補足すると、簡単にいうとカーネルの介入を必要とせずに通信が可能となり、つまり余計な仲介がない分、高速化するということです。一方、高速化できてもどこかでは頭打ちするのですが、例えば、仮想化における DPDK ではハイパーバイザー自身の CPU 利用率を下げつことに繋がり、ネットワークが頭打ちであっても全体的なメリットがあると思います。

最後に:

私のエンジニアとしての持論は「想像力を膨らませ、システム全体とその目的を捉え、意識しろ」です。もちろん、新米エンジニアなどは目の前のことに精一杯でこうはいかないでしょう。でもいつか気づく日が来ます。なぜこのシステムを作る必要があり、なぜ面倒な資料を作り、分かりきった検証を行い、ユーザーに文句言われながらエンジニアをするのか。それはエンジニアとして良いシステムを作ること、もしくはそれに関わることが社会貢献だからです。なので、楽しく、面白く、責任感を持ち、自負心を持ち、エンジニアリング活動をしていきましょう。

2024 年の自宅システムのテーマ

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

トップへ戻る