SaltStack Config のインストールに必要なシステム アーキテクチャは、1) SaltStack Config のデプロイに使用しているインストール方法と 2) 環境のスループット（SaltStack Config を使用してシステムで実行する作業の量）という 2 つの主な要因によって決まります。
開始する前に
システム アーキテクチャに対するニーズを正確に評価するには、まず次の内容について確実に理解しておく必要があります。
- SaltStack Config で使用できる 2 つのインストール方法
- SaltStack Config SaltStack アーキテクチャの 4 つの基本コンポーネント（RaaS、Salt マスター、PostgreSQL、Redis）
インストール プロセスの一般的な概要を含む、これらの概念の概要については、SaltStack Config のインストールと構成を参照してください。インストール シナリオの選択のガイダンスについては、推奨のインストール シナリオも参照してください。
ミニオン アーキテクチャの決定
SaltStack Config のコンテキストでは、ミニオンは通常、1 つ以上の Salt マスターを介して SaltStack Config に接続して管理する本番環境内のノードを意味します。
Salt は、ミニオンで実行されている可能性のあるオペレーティング システムと連携するように設計されています。Salt は、標準的なオペレーティング システム（Linux、Windows、MacOS）に加えて、Arista、Juniper、AIX、Solaris などのさまざまなネットワーク デバイスに固有のオペレーティング システム用の専用ミニオン ソフトウェア（一般に「ネイティブ ミニオン」と呼ばれる）を提供します。
次の表に、Salt ミニオン サービスの最小メモリ要件をオペレーティング システム別に示します。
| オペレーティング システム | メモリの最小要件 |
|---|---|
| AIX ミニオン | 512 MB の RAM |
| MacOS ミニオン | 4 GB の RAM |
| Linux ミニオン | 512 MB の RAM |
| Windows ミニオン | 4 GB の RAM |
| プロキシ ミニオンを含むその他のネットワーク デバイス | 制御されたデバイスあたり 40 MB の RAM |
インストール シナリオの決定
インストール シナリオの選択のガイダンスについては、推奨のインストール シナリオを参照してください。お使いのシステムに最適なインストール方法が不明な場合は、標準インストールをお勧めします。ノード数が 1,000 台を超える本番環境のシステムでは、Lifecycle Manager インストール方法は推奨されません。
Lifecycle Manager インストールを選択する場合、必要なノードは 1 台のみで、次のシステム アーキテクチャが必要になります。
| ハードウェア | 最大で 1,000 台のノード（ミニオン） |
|---|---|
| [コア] | 16 個の CPU コア |
| [RAM] | 32 GB の RAM |
| [ディスク容量] | 260 GB 以上の空き容量 |
以降、このガイドでは、標準インストール シナリオにおけるアーキテクチャのニーズについて説明します。
管理される Salt ミニオン数の予測
インストール前にシステムのスループットを測定することは困難ですが、SaltStack Config によって管理されるシステム内のミニオン（ノード）の数に基づいてニーズを予測することはできます。このガイドの最後のセクションでは、システム スループットを判断するための追加の測定について説明します。
SaltStack Config によって管理される Salt ミニオンの数が増えると、それに合わせてシステム アーキテクチャを拡張する必要が生じる場合があります。
必要な Salt マスターの数の予測
次の表に、システム内の管理対象 Salt ミニオン（ノード）の数に基づいて必要になる可能性のある Salt マスターの推奨数を示します。
| ミニオン | Salt マスター (16 CPU/16 GB) |
|---|---|
| 5,000 | 1 |
| 10,000 | 2 |
| 15,000 | 3 |
| 20,000 | 4 |
| 25,000 | 5 |
| 30,000 | 6 |
| 35,000 | 7 |
| 40,000 | 8 |
| 45,000 | 9 |
| 50,000 | 10 |
| 55,000 | 11 |
| 60,000 | 12 |
| 65,000 | 13 |
| 70,000 | 14 |
| 75,000 | 15 |
| 80,000 | 16 |
| 85,000 | 17 |
| 90,000 | 18 |
| 95,000 | 19 |
| 100,000 | 20 |
このドキュメントでは、SaltStack Config オンプレミス アーキテクチャについて説明します。SaltStack Config クラウドは現在、Salt マスターを 1 つのみ実行できます。つまり、ミニオン数は 20,000 未満に制限されています。
必要な RaaS ノードの数の予測
次の表に、システム内の管理対象 Salt ミニオン（ノード）の数に基づいて必要になる可能性のある RaaS ノードの推奨数を示します。
| ミニオン | 16 CPU/16 GB の RaaS ノード | 32 CPU/32 GB の RaaS ノード |
|---|---|---|
| 5,000 | 1 | |
| 10,000 | 1 | |
| 15,000 | 1 | |
| 20,000 | 1 | |
| 25,000 | 2 | |
| 30,000 | 2 | |
| 35,000 | 2 | |
| 40,000 | 2 | |
| 45,000 | 1 | 1 |
| 50,000 | 1 | 1 |
| 55,000 | 1 | 1 |
| 60,000 | 1 | 1 |
| 65,000 | 2 | |
| 70,000 | 2 | |
| 75,000 | 2 | |
| 80,000 | 2 | |
| 85,000 | 1 | 2 |
| 90,000 | 1 | 2 |
| 95,000 | 1 | 2 |
| 100,000 | 1 | 2 |
必要な PostgreSQL ノードの数の予測
次の 2 つの表は、システム内の管理対象 Salt ミニオン（ノード）の数に基づいて必要になる可能性のある PostgreSQL データベース ノードの推奨数を示します。
| ミニオン | 8 CPU/8 GB の PostgreSQL ノード | 16 CPU/16 GB の PostgreSQL ノード | 24 CPU/24 GB の PostgreSQL ノード | 32 CPU/32 GB の PostgreSQL ノード |
|---|---|---|---|---|
| 5,000 | 1 | |||
| 10,000 | 1 | |||
| 15,000 | 1 | |||
| 20,000 | 1 | |||
| 25,000 | 1 | |||
| 30,000 | 1 | |||
| 35,000 | 1 | |||
| 40,000 | 1 | |||
| 45,000 | 1 | |||
| 50,000 | 1 | |||
| 55,000 | 1 | |||
| 60,000 | 1 |
| ミニオン | 48 CPU/48 GB の PostgreSQL ノード | 56 CPU/56 GB の PostgreSQL ノード | 64 CPU/64 GB の PostgreSQL ノード |
|---|---|---|---|
| 65,000 | 1 | ||
| 70,000 | 1 | ||
| 75,000 | 1 | ||
| 80,000 | 1 | ||
| 85,000 | 1 | ||
| 90,000 | 1 | ||
| 95,000 | 1 | ||
| 100,000 | 1 |
必要な Redis ノードの数の予測
次の 2 つの表は、システム内の管理対象 Salt ミニオン（ノード）の数に基づいて必要になる可能性のある Redis データベース ノードの推奨数を示します。
| ミニオン | 4 CPU/4 GB の Redis ノード | 8 CPU/8 GB の Redis ノード | 12 CPU/12 GB の Redis ノード |
|---|---|---|---|
| 5,000 | 1 | ||
| 10,000 | 1 | ||
| 15,000 | 1 | ||
| 20,000 | 1 | ||
| 25,000 | 1 | ||
| 30,000 | 1 | ||
| 35,000 | 1 | ||
| 40,000 | 1 | ||
| 45,000 | 1 | ||
| 50,000 | 1 | ||
| 55,000 | 1 | ||
| 60,000 | 1 |
| ミニオン | 16 CPU/16 GB の Redis ノード | 20 CPU/20 GB の Redis ノード |
|---|---|---|
| 65,000 | 1 | |
| 70,000 | 1 | |
| 75,000 | 1 | |
| 80,000 | 1 | |
| 85,000 | 1 | |
| 90,000 | 1 | |
| 95,000 | 1 | |
| 100,000 | 1 |
スループットに基づくインストール後のアーキテクチャの最適化
SaltStack Config のインストールが完了した後に、システム監視メトリックを使用して、システムのスループットとアーキテクチャに関するニーズを効率的に特定することができます。
監視対象を特定する場合は、次の要因を考慮してください。
- [イベント システム上のトラフィック量] - イベント システム（「イベント バス」とも呼ばれる）は、Salt マスターと Salt ミニオンの両方によるプロセス間通信に使用されます。イベント バスが非常にビジーな状態の場合は、メモリ割り当てを増やすことを検討してください。
- [1 時間あたりのジョブの戻り値] - SaltStack Config では、SaltStack Config によって実行される各コマンド、タスク、および操作を表すために「ジョブ」という用語を使用しています。各ジョブは、レポート作成とデータ収集のために出力を SaltStack Config に送信します。指定した 1 時間内にシステムによって生成されたジョブの戻り値が、アーキテクチャのニーズに影響する可能性があります。
- [ピラー データの量] - ピラー データは Salt マスターに保存する必要があるデータです。ピラーは主にシークレットや、アカウント認証情報、暗号化キー、パスワードなどその他の秘密データを格納するために使用されます。また、構成データなど、状態ファイルに直接配置することが望ましくない非シークレット データを格納する場合にも役立ちます。Salt マスターに保存され、後で必要に応じてミニオンからアクセスされるデータの量は、メモリとデータ ストレージに関するニーズに影響する可能性があります。
- [カスタム グレインの量] - 特定のジョブまたはコマンドのターゲットにミニオンを設定するには、Salt でグレインを使用します。グレインとは、各ミニオンの基本的なデータと特性を意味します。Salt には、事前に構築された多数のグレインが付属しています。たとえば、オペレーティング システム、ドメイン名、IP アドレス、カーネル、メモリ、およびその他の多くのシステム プロパティによってミニオンをターゲットにすることができます。カスタム Grain データを作成し、システム内で一意のターゲットに設定する特性に基づいてミニオンのグループを別のグループと区別することもできます。作成するカスタム グレインの数が、アーキテクチャに関するニーズに影響する可能性があります。
- [ビーコンとリアクタの数] - ビーコン システムは、Salt ミニオン上のさまざまなシステム プロセスをリッスンできる監視ツールです。ビーコンはリアクタをトリガし、リアクタは変更の実装や問題のトラブルシューティングに役立ちます。たとえば、サービスの応答がタイム アウトになったときにリアクタ システムがサービスを再起動することができます。ビーコンをリアクタと組み合わせることで、インフラストラクチャやアプリケーションの問題に対して、事前に記述された自動応答を作成できます。リアクタを使用すると、事前に記述された修正状態を使用した自動応答によって Salt を拡張できます。定期的にアクティブ化されるビーコンとリアクタがシステムにある場合、システム アーキテクチャに関するニーズが高まる可能性があります。
- [ディスク サイズに関するニーズ] - 管理対象のミニオンの数や、ストレージに保持する必要がある各年のデータに基づいて、ディスク サイズを拡張する必要が生じる場合があります。たとえば、スループットが高いシステムによる、7 ～ 8 年間のデータ保持を必要とする規制の厳しい業界での運用では、ディスク サイズとストレージ容量の拡張が必要になる可能性があります。
- [地理的な場所とコンポーネント間の距離] - Salt マスターと SaltStack Config (RaaS) が実行されているサーバとの間に 65 ミリ秒以上の遅延が発生している場合は、問題が発生する可能性があります。Salt では、Salt ミニオンと Salt マスターの間の遅延による影響は小さく抑えられています。これらのコンポーネントを配置する場合は、必要に応じて、マスターを RaaS の近くに、ミニオンを RaaS から遠くに配置することを推奨します。
- [ビジネス クリティカルな運用] - 使用環境における SaltStack Config のビジネスクリティカル度を評価する場合は、SaltStack Config の停止がビジネスに与える影響について確認します。1 時間以上ダウンした場合、深刻な影響があるかどうかも確認します。影響がある場合は、高可用性に関するニーズを SaltStack Config システム アーキテクチャの設計に取り入れることが必要になる場合があります。
これらの要因に基づいて、リソースを段階的に拡張し、システムのパフォーマンスへの影響を監視することを検討します。たとえば、4 個の CPU を搭載した 4 GB の RAM を増設してメモリ割り当てを増やします。
次の図に、高可用性 SaltStack Config アーキテクチャの設計例を示します。
この図に示すように、多くの高可用性システムが複数の Salt マスターに接続されています。高可用性システムでは、PostgreSQL データベースと Redis データベースに冗長性を組み込むことによって、データベース間のフェイルオーバーを可能にしています。PostgreSQL および Redis の現在の高可用性ソリューションでは手動フェイルオーバーのみがサポートされていることに注意してください。
