すべてのサービスを依存関係にすることなく、初心者にも使いやすいアプリスタックを構築する方法

初心者にも扱いやすいアプリスタックは、各サービスが目的を1つに絞り、自身のデータを管理し、無関係な家庭内の機能を停止させずに障害から切り離せる構成にすると、全体を把握しやすくなります。

危険なのはコンテナの数だけではありません。すべてのアプリが同じデータベース、認証レイヤー、リバースプロキシ、DNSサービス、ストレージパス、更新時間帯、管理者アカウントに依存すると、複雑さが生じます。したがって、最初のスタックでは共通基盤を小さくし、必須サービスの経路から任意の便利機能を切り離し、各アプリを利用可能にする前にどのコンポーネントを復旧させる必要があるのかを正確に記録しましょう。

アプリのカタログではなく、家庭で実現したいことから始める

ソフトウェアを選ぶ前に、サーバーで継続的にサポートすべき作業を列挙しましょう。最初のスタックでは、デバイスのバックアップ、ファイルの共有場所を1つ、メディアサービスまたはダッシュボードサービスのどちらか1つを用意するとよいでしょう。それぞれの作業について、利用者、データの所有者、許容できる停止時間、復旧手順を明確にします。こうした成果のいずれにも役立たないアプリは、後回しのリストに入れましょう。

TechTargetは、アプリケーションアーキテクチャを、ユーザーの要件を満たすためにアプリケーションがミドルウェア、データベース、その他のアプリケーションとどのように連携するかを示す構造図と定義しています。このユーザー要件とコンポーネントの対応図は、利用可能なアプリをすべて独立した機能として扱うよりも役に立ちます。

最初のスタックは、製品名ではなく3つのサービス契約として書き出しましょう。それぞれの契約について、どんなデータが入力され、どんな結果が出力されるのか、サービスが利用できないときに家庭で何ができるのかを定義します。これにより、後から構成要素を置き換えても、サーバー全体を再設計せずに済みます。

共通基盤はアプリケーション層より小さく保つ

共通のインフラストラクチャを設けるのは妥当です。複数のWebアプリが同じホスト、ストレージプール、監視方式、ローカルの命名規則を使うこともあります。問題が生じるのは、すべてのアプリが中央サービスに依存し、その障害によってアクセス、認証、名前解決、ストレージが一度にすべて使えなくなる場合です。

TechTargetの循環依存分析では、密接に結合したコンポーネントは個別に更新、テスト、デプロイするのが難しくなると説明しています。この依存関係の循環に関する警告は、構成がはるかに小規模なホームサーバーにも当てはまります。

今必要な最小限の共有基盤を使いましょう。リバースプロキシ、集中認証基盤、内部DNSサービスは、複数の安定したアプリにとって役立つから導入するのであり、図に箱を追加したほうが見栄えがよいから導入するのではありません。

すべてのサービスに明確なデータ所有者と永続パスを割り当てる

アプリがストレージを偶然見つけるような構成にしてはいけません。設定、データベース、家庭内のファイル、使い捨てのキャッシュをそれぞれどのパスに置くか決めましょう。複数のサービスで同じメディアライブラリを読み取ることはできますが、メタデータデータベースを両方で管理したり、ストレージプール全体にわたって書き込んだりしてはいけません。

Better Stackは、コンテナの永続データには、それを使うコンテナとは独立したライフサイクルが必要だと説明しています。この独立したデータライフサイクルのモデルは、データの所在を曖昧にせずにアプリを入れ替えるための基盤です。

/srv/appdata/service、/srv/data/service、/srv/cache/serviceのような、内容がわかりやすいホストパスを使いましょう。それぞれについて、所有者、書き込み権限、バックアップルール、復元方法を記録します。複数のアプリがインデックス化したり表示したりする場合でも、世帯で共有するデータの正本となる保存場所は一つに決めましょう。

Featured

ZimaCube 2 パーソナルクラウド ホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

問題発生時にも使えるアクセス経路を構築する

初心者は、まずローカルIPアドレスとポートを直接使い、そこにローカルDNS、HTTPS、リバースプロキシ、リモートアクセスを順に追加していくことがよくあります。各層によって使いやすさは向上しますが、同時に、アプリケーション自体は正常なのに利用できないように見える原因も増えます。

ホームラボガイドでは、DNS、ルーティング、リバースプロキシ、アプリケーション、データベースまたはストレージの依存先を通るリクエスト経路を図解します。この階層化されたリクエスト経路のモデルを使うと、初心者でもアクセスの問題とアプリケーションの問題を切り分けやすくなります。

重要なサービスにはそれぞれ安定したローカル名を付け、復旧用に直接アクセスできるアドレスも記録しておきます。家の中からサーバーを管理する際に、リモートアクセスを必須にしてはいけません。ルーター、DNSリゾルバー、認証システムがすべて、同じ実験的なサービスチェーンに依存しないようにします。

利便性を高める任意のサービスを必須の経路から分離する

ダッシュボード、検索インデックス、通知リレー、メディアのアートワーク、集中認証は、データそのものへのアクセスを維持するために必須ではありませんが、利便性を高めます。これらを任意の依存関係として明示すれば、便利なレイヤーの障害による機能低下にとどまり、全面的な停止を防げます。

TechTargetの耐障害性ガイドでは、バルクヘッドパターンを、システムの一部を隔離して、1つの障害が連鎖し全体の障害に至るのを防ぐ手法として説明しています。この障害隔離の原則を家庭で実践するためのルールは簡単です。必須のストレージ、バックアップ、管理の経路は、任意のレイヤーが停止しても使える状態を保つ必要があります。

任意のサービスを一度に1つずつ停止し、スタックをテストします。ダッシュボードが停止しても共有ファイルには引き続きアクセスできるようにします。リモートアクセスが機能しなくても、ローカルで管理できるようにします。バックアップはメディアインデックスに依存せず、復元の際にバックアップ状況を通知するサービスが不要であることを確認します。

サービスを独立した復旧単位として更新・バックアップする

1回のメンテナンス時間に、すべてのアプリをまとめて更新する必要はありません。サービス定義、永続データ、バージョン情報をそれぞれ分け、他のワークロードに影響を与えずに、1つのアプリを保護、変更、検証、ロールバックできるようにします。

Backblazeは、復旧計画の強さは最新のテスト次第だと主張し、繰り返し実施できる限定的な復旧演習を推奨しています。このサービスごとの復旧訓練は、小規模なセルフホスト環境に適しています。

更新前に設定をエクスポートし、該当するデータベースやアプリの状態を保護して、現在のバージョンを記録します。更新後は通常のユーザーアカウントでアプリを検証し、スケジュールされたジョブも確認します。更新に複数サービス間の調整が必要なら、障害発生時に初めて気づくことのないよう、その依存関係を明記しておきましょう。

サービス一覧のそばに、簡単な依存関係台帳を用意しましょう。各アプリについて、本当に必要なホスト、ストレージパス、データベース、ローカル名、認証方式、バックアップ先を記録します。任意の連携は別に記載します。コンポーネントを置き換えるときは、それに依存する行だけを更新し、該当する復旧確認を行います。こうすれば、便利な共通ツールが、後から追加するすべてのサービスにとって文書化されていない基盤になるのを防げます。

連鎖的な依存関係を生まずに拡張できるスタータースタックを使う

長く使える最初のスタックは、通常、システムレイヤーが1つ、ストレージ構成が1つ、バックアップ経路が1つ、そしてユーザー向けサービスが少数で成り立ちます。安定して稼働する2つ以上のアプリが必要とし、その機能なしでも復旧手順を把握できる場合に限り、共通インフラを追加しましょう。

ServeTheHomeのコンパクトサーバープロジェクトは、範囲の定まらないプラットフォームへと拡張するのではなく、用途を明確に定めた演算、ストレージ、ネットワークの構成を軸に、小型の専用システムを設計する方法を示しています。この役割を限定したサーバーモデルは、最初からあらゆるインフラサービスをインストールするよりも、初心者にとって参考になります。

ZimaSpaceの連携する3つのサービスを軸に初めてのサーバーを構築するガイドを参考にすると、最初に扱う範囲を絞れます。ZimaBoard 2 ミニホームサーバーは、ストレージを計画的に用意し、サービス数を限定した、アプリ中心のコンパクトなスタックに適しています。複数ドライブのストレージ、複数の家庭内ユーザー、長期保存、ストレージ優先の復旧がすでに重要な要件であれば、ZimaCube 2 AI NASがより明確な基盤となります。

サービスの追加、停止、更新、置き換えを行っても、家庭内サーバー全体をそれに合わせて変更する必要がなく、各サービスのデータとアクセス経路だけが変わる構成なら、初心者にも扱いやすいスタックになります。