Deep Security 11のサポートは終了しています。バージョンセレクタ（上記）を使用して、より新しいバージョンのヘルプセンターを表示します。
本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。
本ヘルプセンターの一部の記事には外部リンクが含まれています。リンク切れなどお気づきの点がございましたら、トレンドマイクロサポート窓口までご連絡ください。
PostgreSQLの推奨設定
すべての種類のデータベースに適用される要件については、
-
Deep Security Manager用のPostgreSQLデータベースを準備するには、データベースユーザアカウントを作成し、権限を付与します。
CREATE DATABASE "<database-name>";
CREATE ROLE "<dsm-username>" WITH PASSWORD '<password>' LOGIN;
GRANT ALL ON DATABASE "<database-name>" TO "<dsm-username>";
GRANT CONNECT ON DATABASE "<database-name>" TO "<dsm-username>";
Deep Security Managerに複数のテナントがある場合は、それらのテナントに新しいデータベースと役割を作成する権限も付与します。
ALTER ROLE <dsm-username> CREATEDB CREATEROLE;
- Deep Security ManagerとPostgreSQLの間の接続で信頼できないネットワークが使用されている場合は、TLSを使用してセキュリティを強化することを検討してください。Deep Security Managerとデータベース間の通信の暗号化を参照してください。
-
データベースログのローテーションとパフォーマンス設定を行います。
ベストプラクティスについては、 ログ設定, ロック管理, 最大接続数, 自動バキューム設定などを参照してください。
手順は、ディストリビューションや管理対象のホスティングによって異なります。
-
自己ホスト型データベースの場合:初期設定は、PostgreSQL Core Distributionの汎用値となります。特に大規模環境では、初期設定がデータセンターやカスタマイズされたクラウドインストールに適していないこともあります。
設定を変更するには、次の手順に従います。
- プレーンテキストエディタでpostgresql.confファイルを開きます。
- パラメータを編集します。
- ファイルを保存します。
- PostgreSQLサービスを再起動します。
- Amazon RDSの場合:初期設定は、インスタンスのサイズによって異なります。多くの場合、autovacuuming、 max_connections 、 effective_cache_sizeを微調整するだけです。設定を変更するには、 データベースパラメータグループ を使用し、データベースインスタンスを再起動します。
- Amazon Auroraの場合:初期設定は、インスタンスのサイズによって異なります。多くの場合、autovacuuming、 max_connections 、 effective_cache_sizeを微調整するだけです。設定を変更するには、 データベースパラメータグループ を使用し、データベースインスタンスを再起動します。
パフォーマンスを微調整する場合は、Amazon CloudWatchなどのサービスを使用してデータベースIOPSを監視し、設定を確認してください。
-
追加の支援が必要な場合は、PostgreSQLからプロフェッショナルサポートが提供されています。
PostgreSQLの設定を調整する
ログ設定
初期設定では、PostgreSQLログファイルはローテーションされないため、ログファイルに大量のディスク容量が使用される可能性があります。Deep SecurityでPostgreSQLを使用する場合、postgresql.confファイルで次の4つのパラメータを使用してログローテーションを設定することをお勧めします。
- log_filename
- log_rotation_age
- log_rotation_size
- log_truncate_on_rotation
log_rotation_ageとlog_rotation_sizeは、新しいログファイルがいつ作成されるかを制御します。たとえば、log_rotation_ageを1440に設定すると、新しいログファイルが1440分 (1日) ごとに作成され、log_rotation_sizeを10000に設定すると、前のログファイルが10000KBに達したときに新しいログファイルが作成されます。
log_filenameは、すべてのログファイルに与えられた名前を制御します。名前に時間と日付の形式の変換を使用できます。完全なリストについては、https://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.htmlを参照してください。
log_truncate_on_rotationを「on」に設定すると、新しく作成されたログファイルと同じ名前のログファイルが上書きされます。
要件に適したログローテーションを実行するために使用できるパラメータの組み合わせがいくつかあります。以下に例を示します。
- log_filename = 'postgresql-%a.log' (各ログファイルの名前に、曜日の最初の3文字が含まれます)
- log_rotation_age = 1440 (新しいログファイルが毎日作成されます)
- log_rotation_size = 0(設定が無効になり、制限を超えるたびに日次ログファイルが上書きされなくなります)
- log_truncate_on_rotation = on (ログファイルの上書きが有効になります)
ロック管理
初期設定では、 postgresql.conf ファイルの deadlock_timeout 設定は1秒に設定されています。つまり、クエリがロックを1秒以上待機するたびに、PostgreSQLはデッドロック状態のチェックを開始し、ログ設定がそのように設定されているとエラーをログに記録します（初期設定では).です）。これにより、読み込み時間中にクエリが1秒を超えて待機することが正常である大規模なシステムでは、パフォーマンスが低下する可能性があります。大規模なシステムでは、deadlock_timeout設定の値を大きくすることを検討してください。PostgreSQLのドキュメントには、この推奨事項が含まれています。: "理想的には、標準のトランザクション時間を超える設定が必要です。 [...]".
最大接続数
postgresql.confファイルのmax_connections設定では、データベースに対するオープン接続の最大数を指定します。初期設定値は100です。この値を500に増やすことをお勧めします。
共有バッファ
postgresql.confファイルのshared_buffers設定では、PostgreSQLがデータのキャッシュに使用できるメモリ容量を指定します。1GBのRAMを備えたシステムには、共有バッファ用にメモリの値の1/4が必要です。つまり、共有バッファを256MBに設定する必要があります (初期設定は32MBです)。
ワークメモリとメンテナンスワークメモリ
postgresql.confファイルのwork_mem設定では、一時ディスクファイルに書き込む前に、内部ソート操作とハッシュテーブルで使用できるメモリ容量を指定します。初期設定値は1MBですが、複雑なクエリを実行する場合は増やす必要があります。maintenance_work_mem設定では、ALTER TABLEなどのメンテナンス操作に使用される最大メモリ容量を決定します。
有効キャッシュサイズ
postgresql.confファイルのeffective_cache_size設定は、クエリによりキャッシュの効果を推定するために使用されます。この設定はクエリ計画中のコスト見積もりにのみ影響し、メモリ消費量は増加しません。この設定を大きくすることを検討してください。
チェックポイント
通常、チェックポイントはデータファイルへの書き込みの主なソースとなります。最も速いパフォーマンスを実現するには、大半のチェックポイントを「requested」 (使用可能なすべてのWALセグメントを入力することによるトリガ、または明示的なCHECKPOINTコマンドによるトリガ) ではなく、「timed」 (checkpoint_timeoutによるトリガ) にする必要があります。チェックポイントの作成頻度は減らすことを強くお勧めします。
| パラメータ名 | 推奨値 |
|---|---|
| checkpoint_timeout | 15min |
| checkpoint_completion_target | 0.9 |
| max_wal_size | 16GB |
ログ先行書き込み (WAL)
データベース複製を使用する場合は、wal_level = replicaを使用することを検討してください。
自動バキューム設定
PostgreSQLには、「バキューム」と呼ばれる定期的なメンテナンスが必要です。通常、autovacuum_max_workersの初期設定値を変更する必要はありません。
entitys および attribute2s 表で、頻繁な書き込みによって多くの行が頻繁に変更される場合（短時間のクラウドインスタンス), を使用する大規模な配置では、ディスク領域の使用を最小限に抑えてパフォーマンスを維持するために、自動バッファの実行頻度を増やす必要があります）。パラメータはデータベース全体と特定のテーブルの両方に設定する必要があります。
| データベースレベルのパラメータ名 | 推奨値 |
|---|---|
| autovacuum_work_mem |
1GB |
| テーブルレベルのパラメータ名 | 推奨値 |
|---|---|
| autovacuum_vacuum_cost_delay |
10 |
| autovacuum_vacuum_scale_factor |
0.01 |
| autovacuum_analyze_scale_factor |
0.005 |
データベースレベルの設定を変更するには、設定ファイルまたはデータベースパラメータグループを編集し、データベースサーバを再起動する必要があります。データベースが実行されている間、コマンドはその設定を変更できません。
テーブルレベルの設定を変更するには、設定ファイルまたはデータベースパラメータグループを編集するか、次のコマンドを入力します。
ALTER TABLE public.entitys SET（autovacuum_enabled = true、autovacuum_vacuum_cost_delay = 10、autovacuum_vacuum_scale_factor = 0.01、autovacuum_analyze_scale_factor = 0.005);
ALTER TABLE public.attribute2s SET（autovacuum_enabled = true、autovacuum_vacuum_cost_delay = 10、autovacuum_vacuum_scale_factor = 0.01、autovacuum_analyze_scale_factor = 0.005);
高可用性
高可用性 (HA) は初期設定では設定されておらず、テスト環境では有効になっていませんが、データベースの不具合が発生した場合やサーバにアクセスできなくなった場合にビジネスを継続できるように、強く推奨します。HAの有効化と設定の方法については、PostgreSQLのドキュメントを参照してください。
バックアップと復元
バックアップと復元は初期設定では設定されていませんが、本番環境では不可欠です。
pg_dumpやpg_basebackupのような基本的なツールは、エンタープライズ環境でのバックアップには適していません。バックアップと復元には、Barman (https://www.pgbarman.org/index.html) など、その他のツールの使用を検討してください。
Linuxの推奨設定
Transparent Huge Pages (Linux)
Transparent Huge Pages (THP) は、メモリ容量の大きいマシンでより大きなメモリページを使用することにより、Translation Lookaside Buffer (TLB) 検索のオーバーヘッドを削減するLinuxのメモリ管理システムです。THPはLinuxでは初期設定で有効になっていますが、データベースを実行しているコンピュータには推奨されていません。PostgreSQLがLinuxコンピュータにインストールされている場合は無効にする必要があります。詳細については、OSベンダのドキュメントを参照してください。
強化されたホストベース認証 (Linux)
初期設定では、Linuxにはデータベース用の制限付きホストベース認証 (HBA) がありません。データベースアプライアンスのHBA設定を強化すると、外部ホストからの不正アクセスを防ぐために役立ちます。HBA設定は、IPアドレス範囲にアクセスを制限し、その範囲内のホストのみがアクセスできるようにします。HBA設定はテスト環境では使用されていないため、お勧めしません。
