architecture-review

アーキテクチャ評価フレームワーク

現在の技術スタック

現在の技術スタックについては、references/technology-decisions.mdを参照してください。

評価基準

技術の追加案やアーキテクチャの変更案を評価する際は、以下の基準に照らして採点してください。

1. 原則との整合性

各中核原則を採点してください（強い／弱い／中立）：

• 家庭でもエンタープライズ品質：本番環境で通用するパターンを反映していますか？
• すべてをコードで管理：gitですべてを表現できますか？
• 自動化が鍵：手作業による負担を減らしますか、それとも増やしますか？
• 学習を第一に：価値あるエンタープライズスキルを学べますか？
• DRYとコードの再利用：既存のパターンを活用しますか、それとも重複を生みますか？

2. スタックとの適合性

• 既存のツールと役割が重複していますか？（例：DragonflyがあるのにRedisを追加する）
• GitOpsワークフローに統合できますか？（Fluxでデプロイ可能であることが必須です）
• ベアメタルで動作しますか？（クラウド専用サービスは不可です）
• マルチクラスター構成をサポートしますか？（dev → integration → live）

3. 運用コスト

• どのように監視しますか？（kube-prometheus-stackとの統合が必須です）
• どのようにバックアップしますか？（復旧手順が必要です）
• アップグレードにどう対応しますか？（宣言的であること。できればRenovate経由で行います）
• 障害の影響範囲はどの程度ですか？（クラスター全体より分離されているほうが望ましいです）

4. 複雑性の予算

• 学習価値によって複雑性が正当化されますか？
• 同じ課題を、既存のよりシンプルなツールで解決できますか？
• 12か月間の保守負担はどの程度ですか？

5. 代替案の分析

• 既存のスタックコンポーネントで解決できませんか？（必ず最初に確認してください）
• エコシステムにおける主要な代替案を2～3個挙げてください。
• 本番環境で運用されているホームラボでは、ほかにどのようなツールが使われていますか？（kubesearchで調査）

6. 障害モード

• このコンポーネントが利用できない場合、どうなりますか？
• ネットワークポリシーとどのように連携しますか？（デフォルトは拒否）
• 復旧手順はどうなっていますか？（ランブックへの記載が必須です）
• 自己修復できますか？（自己修復を強く推奨します）

見直すべきアンチパターン

アンチパターン	問題点	適切な対応
監視せずに「とりあえずコンテナを実行する」	障害を把握できず、アラートもありません	ServiceMonitor + PrometheusRuleが必須です
既存のツールで十分なのに新しいツールを追加する	スタックが肥大化し、保守負担が増えます	まず既存のスタックを評価してください
「今は」可観測性を後回しにする	技術的負債となり、いつまでも解消されません	監視は初日から必要であり、後回しにしてはいけません
クラウド専用サービス	ベンダーロックインが発生し、ベアメタルで動作しません	セルフホスト可能な代替案を優先してください
高可用性の方針がない単一インスタンス	単一障害点になります	最低限、復旧手順を文書化してください