SaltStack Config のインストールに必要なシステム アーキテクチャは、1) SaltStack Config のデプロイに使用しているインストール方法と 2) 環境のスループット（SaltStack Config を使用してシステムで実行する作業の量）という 2 つの主な要因によって決まります。
開始する前に
システム アーキテクチャに対するニーズを正確に評価するには、まず次の内容について確実に理解しておく必要があります。
- SaltStack Config で使用できる 2 つのインストール方法
- SaltStack Config SaltStack アーキテクチャの 4 つの基本コンポーネント（RaaS、Salt マスター、PostgreSQL、Redis）
インストール プロセスの一般的な概要を含む、これらの概念の概要については、SaltStack Config のインストールと構成を参照してください。インストール シナリオの選択のガイダンスについては、推奨のインストール シナリオも参照してください。
SaltStack Config は、オープンソースの自動化および構成管理エンジンの機能を利用しています。Salt で使用される主な用語（Salt マスターや Salt ミニオンなど）に慣れていない場合に詳細を確認するには、「Salt システム アーキテクチャ」を参照してください。
ミニオン アーキテクチャの決定
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 の現在の高可用性ソリューションでは手動フェイルオーバーのみがサポートされていることに注意してください。
