はじめに
TeslaMateは、Teslaの走行履歴や充電履歴、消費電力などを継続的に記録できる非常に優れたプラットフォームです。
私自身もOCI上でTeslaMateを運用していますが、ある時ふと「もし今この環境が失われたらどうなるだろう」と考えるようになりました。
TeslaMateに蓄積されたデータは、一度消失するとほとんどの場合再取得できません。
特に、
・走行履歴
・充電履歴
・消費電力情報
・位置情報履歴
・長期間の車両運用データ
といった情報は、TeslaMateを利用する大きな価値そのものです。
そこで今回は、現在運用しているTeslaMate環境に対して、低コストかつ継続的に運用可能なバックアップおよびDR（災害復旧）設計を検討してみました。
現在の構成
現在の構成は以下の通りです。
OCI
├ TeslaMate
├ PostgreSQL
├ Grafana
└ SeaweedFS
TeslaMateが収集したデータはPostgreSQLに保存されています。
Grafanaによる可視化環境も重要ですが、本当に保護すべき資産はPostgreSQLデータベースに集約されています。
そのため、今回の設計ではPostgreSQLを中心に保護していきます。
バックアップに求める要件
今回の設計では、次の要件を設定しました。
確実に復旧できること
バックアップは取得することが目的ではありません。
実際に必要になった際、確実に復元できて初めて価値があります。
運用コストを抑えること
個人環境であるため、企業向けのレプリケーション構成や複雑なバックアップ製品には依存しない方針としました。
OCI Free Tierを意識すること
通信量やストレージ消費が大きくならない設計を目指します。
将来的な拡張性を持たせること
将来の監視基盤や通知システムとの連携も視野に入れています。
バックアップ方式の選定
今回はPostgreSQLの論理バックアップを採用する予定です。
バックアップの流れは次のようになります。
PostgreSQL
↓
データベースダンプ取得
↓
圧縮
↓
SeaweedFSへ保存
物理バックアップやWALアーカイブも検討しましたが、TeslaMateの規模を考えると運用負荷とのバランスが良いとは言えませんでした。
そのため今回は、
「シンプルで復旧しやすいこと」
を最優先に考えています。
世代管理設計
Dailyバックアップ
毎日取得します。
保持期間は14日を予定しています。
主な目的は、
・設定ミス
・誤削除
・直近の障害対応
です。
Weeklyバックアップ
毎週取得します。
保持期間は12世代を予定しています。
数週間前から問題が発生していた場合でも、復旧ポイントを確保できるようにするためです。
Monthlyバックアップ
毎月取得します。
保持期間は無期限を予定しています。
長期間の履歴保全と、最終的な保険として位置付けています。
SeaweedFSを採用する理由
バックアップ保存先としてSeaweedFSを利用します。
理由は以下の通りです。
・すでに運用中の環境を活用できる
・S3互換APIを利用できる
・特定クラウドサービスへの依存を減らせる
・将来的な拡張が容易
現在はOCI上で運用していますが、将来的には以下のような構成も考えています。
OCI
↓
SeaweedFS
↓
自宅Piクラスタ
↓
別拠点
このようにバックアップの保管場所を分散できれば、さらに耐障害性を高めることができます。
DR環境の設計
バックアップだけでは十分ではありません。
重要なのは、
「そのバックアップから本当に復旧できること」
です。
そこで専用のDR検証環境を用意することにしました。
構成は以下を想定しています。
Pi5
└ Proxmox
└ TeslaMate-DR VM
├ Ubuntu
├ Docker
├ PostgreSQL
└ TeslaMate
想定スペックは次の通りです。
・vCPU：2
・RAM：4GB
・Disk：32GB
通常時は停止状態とし、検証時のみ起動します。
リストアテスト方針
四半期ごとに復旧訓練を実施する予定です。
実施時期は、
・1月
・4月
・7月
・10月
を想定しています。
検証内容は次の通りです。
SeaweedFSからバックアップ取得
↓
検証用VMへ投入
↓
PostgreSQL復元
↓
TeslaMate起動
↓
データ確認
確認項目としては、
・TeslaMateへログインできること
・車両情報が表示されること
・走行履歴が表示されること
・充電履歴が表示されること
・エラーが発生していないこと
を予定しています。
バックアップの次に必要なもの
今回の検討では、
・バックアップ取得
・世代管理
・復旧手順
までを対象としました。
しかし実運用では、それだけでは十分とは言えません。
例えば、
・バックアップ成功
・バックアップ失敗
・バックアップ容量不足
・世代管理異常
・リストアテスト結果
といった運用イベントも継続的に把握する必要があります。
つまり、
「データを守る仕組み」
に加え、
「状態を把握する仕組み」
も必要になります。
将来的な構想
現時点では、まずバックアップとDR環境の構築を優先しています。
一方で将来的には、
TeslaMate
↓
バックアップ基盤
↓
運用イベント
↓
通知・連携基盤
という形で、運用イベントを統合的に管理できる仕組みについても検討していきたいと考えています。
現在所有しているCode27についても、このような運用監視・通知基盤との連携可能性を含めて今後検証していく予定です。
ただし現段階では、Code27との具体的な連携方法はまだ確立していません。
そのため、本記事ではまず「確実にバックアップできること」と「確実に復旧できること」を優先事項としています。
まとめ
TeslaMateに蓄積されるデータは、一度失われると取り戻すことが難しい重要な資産です。
そこで今回、
・Daily 14世代
・Weekly 12世代
・Monthly 無期限
・SeaweedFS保管
・Pi5 DR環境
・四半期ごとのリストアテスト
という構成を検討しました。
重要なのはバックアップファイルを持つことではありません。
必要になったときに、確実に復元できることです。
まずはこの設計をベースにバックアップ基盤を構築し、その後は運用監視やCode27を活用した連携についても検討していきたいと思います。
コメント