各サービスを依存関係だらけにせず、初心者にも使いやすいアプリスタックを構築する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Build a Beginner-Friendly App Stack Without Turning Every Service Into a Dependency - Zima Store Online

初心者にも扱いやすいアプリ構成は、各サービスに1つの目的があり、データを自ら管理し、家庭内の無関係な機能を停止させずに障害に耐えられる場合、理解しやすい状態を保てます。

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

アプリのカタログではなく、家庭で得たい成果から始める

ソフトウェアを選ぶ前に、サーバーで継続的に対応する必要がある作業を一覧にします。最初の構成では、デバイスのバックアップ、共有ファイルの保存場所を1つ、任意のメディアサービスまたはダッシュボードサービスを1つ用意するとよいでしょう。各作業には、明確な利用者、データの管理者、許容できる停止時間、復旧手順が必要です。これらの成果のいずれにも貢献しないアプリは、後回しのリストに入れます。

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

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

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

一部の共有インフラは合理的です。複数のWebアプリで、同じホスト、ストレージプール、監視方法、ローカルの命名規則を使用してもよいでしょう。問題が始まるのは、すべてのアプリが中央サービスを必要とし、その障害によってアクセス、認証、名前解決、ストレージが一度にすべて失われる場合です。

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

共有コンポーネント	最初の用途として妥当	依存関係の境界
ホストOS	信頼できる複数のサービスを実行する	アプリの状態をシステムレイヤーの外部に保持する
ストレージプール	安定したデータセットを提供する	アプリの状態、ユーザーデータ、バックアップ先を分離する
リバースプロキシ	覚えやすいローカル名を提供する	ローカルから直接復旧できる経路を維持する
シングルサインオン	スタックが安定してから追加する	管理への唯一の経路にしない

現在必要な最小限の共有基盤を使用します。リバースプロキシ、中央認証レイヤー、内部DNSサービスは、図にボックスを追加すると完成度が高く見えるからではなく、複数の安定したアプリが恩恵を受けるために導入すべきです。

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

アプリケーションがストレージを偶然見つけるような状態にしてはいけません。設定を含むパス、データベースを含むパス、家庭内ファイルを含むパス、使い捨てのキャッシュを含むパスを明確に定義します。2つのサービスが同じメディアライブラリを読み取ることはあっても、メタデータデータベースを両方が所有したり、プール全体に広く書き込んだりしてはいけません。

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

次のように、読みやすいホストパスを使用します。 /srv/appdata/service, /srv/data/service、および /srv/cache/serviceそれぞれについて、所有者、書き込み権限、バックアップルール、復元方法を記録します。複数のアプリがインデックスを作成したり表示したりする場合でも、家庭内で共有するデータには、信頼できる唯一の保存場所を用意する必要があります。

Featured

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

ZimaCube2

障害時にも段階的に機能するアクセス経路を構築する

初心者はまず、ローカルIPアドレスとポートを直接使うところから始め、そこにローカルDNS、HTTPS、リバースプロキシ、リモートアクセスを追加していくことがよくあります。各レイヤーによって使いやすさは向上しますが、一方で、アプリケーション自体は正常に動作しているのに利用できないように見える箇所も増えます。

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

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

オプションの利便性サービスを必須経路の外に置く

ダッシュボード、検索インデックス、通知リレー、メディアアートワーク、集中認証は、利便性を高める一方で、基盤データを利用可能な状態に保つために必須とは限りません。これらをオプションの依存関係として扱い、利便性のためのレイヤーに障害が発生しても、完全な停止ではなく機能の低下にとどまるようにします。

TechTargetのレジリエンスガイドでは、バルクヘッドパターンを、ある部分の障害がシステム全体の障害へ連鎖しないよう、システムの各部分を分離する設計として説明しています。この障害分離の原則は、家庭内では次のようなシンプルなルールに置き換えられます。オプションのレイヤーが停止しても、重要なストレージ、バックアップ、管理経路は利用できなければなりません。

一度に1つのオプションサービスを停止して、環境全体をテストします。ダッシュボードが停止しても共有ファイルには引き続きアクセスできるべきです。リモートアクセスに障害が発生しても、ローカルでの管理は可能であるべきです。バックアップがメディアインデックスに依存したり、復元にバックアップ状況を報告する通知サービスが必要になったりしてはいけません。

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

1回のメンテナンス時間内に、すべてのアプリを同時に更新する必要はありません。サービス定義、永続データ、バージョン情報を十分に分離し、無関係なワークロードを変更せずに、1つのアプリだけを保護、変更、検証し、ロールバックできるようにします。

Backblazeは、復旧計画の強度は直近のテストの強度にすぎないとし、繰り返し実施できる限定範囲の復旧演習を推奨しています。このサービス単位の復旧訓練は、小規模なセルフホスト環境に適しています。

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

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

連鎖状態にならず成長できるスタータースタックを使う

長く使える最初のスタックには、通常、1つのシステムレイヤー、1つのストレージマップ、1つのバックアップ経路、そして少数のユーザー向けサービスがあれば十分です。2つ以上の安定したアプリが必要とするようになり、それがなくても復旧手順を理解できる状態を保てる場合に限り、共有インフラを追加しましょう。

ServeTheHomeのコンパクトサーバープロジェクトは、規模を際限なく拡大するのではなく、コンピュート、ストレージ、ネットワークの明確な組み合わせを中心に、小型の専用システムを設計する方法を示しています。この役割を限定したサーバーモデルは、すべてのインフラサービスを一度に導入するよりも、初心者にとって優れた参考になります。

3つの連携サービスを中心に最初のサーバーを構築するZimaSpaceのガイドは、初期スコープを適切に保つのに役立ちます。ZimaBoard 2 ミニホームサーバーは、ストレージを計画的に設計し、サービス数を限定した、アプリ中心のコンパクトなスタックに適しています。複数ドライブのストレージ、複数の家庭内ユーザー、長期保存、ストレージを中心とした復旧がすでに重要な要件なら、ZimaCube 2 AI NASのほうが明確な基盤になります。

サービスの追加、停止、更新、置き換えを行った際に、そのサービス自身のデータとアクセス経路だけが変わり、家庭用サーバー全体を一緒に移行する必要がない構成なら、初心者にも扱いやすいスタックです。