第15章: ベストプラクティスと実践的なケーススタディ
15.1 本章の目的と範囲
本章では、AlmaLinux9の特長であるバイナリ互換性とコミュニティ主導の開発体制を活かし、実際の業務運用におけるベストプラクティスと具体的なケーススタディを示します。AlmaLinux OSはコミュニティ主導のエンタープライズLinuxディストリビューションで、RHELとバイナリ互換を保つ長期安定版プラットフォームです。
この章の目的は以下の通りです：
- 事前に習得した AlmaLinux9 の基礎（
dnfによるパッケージ管理、SELinuxによるOSレベルのセキュリティ設定など）を踏まえ、実運用での最適化手法を学ぶ - セキュリティ設定、バックアップ/DR、運用自動化、仮想化・コンテナ技術の統合による可用性・信頼性向上を図る
- 小規模からエンタープライズ環境まで、規模や要件に応じたケーススタディを通じて具体的な設計・構成例を理解する
- オンプレミスおよびクラウド（ハイブリッド）運用での最適構成と考慮点を把握する
- 業務要件に基づいた RPO/RTO 設定や定期テストの重要性を知り、継続的に検証可能な運用フローを確立する
なお、本章の範囲は以下のとおりです：
- 対象範囲：AlmaLinux9 を利用する企業・組織のサーバー運用全般
- 前提条件：AlmaLinux9 のインストール完了、基本的なシェル操作と
dnf、SELinux設定の基礎知識があること - 非対象範囲：独自カーネルパッチの作成や特殊デバイスドライバー開発、開発者向けアプリケーション開発環境の詳細解説
💡 補足：本章で扱うベストプラクティスは、公式ドキュメント（AlmaLinux 公式Wiki、RHEL 9 ドキュメント）を参照しつつ、現場での適用実績に基づいています。
15.2 全体設計のベストプラクティス
15.2.1 サーバー役割分割とネットワーク構成
業務システムを冗長化・分散化するために、Web、DB、メールなど用途ごとにサーバー役割を明確に分割します。これにより、一部システム障害時の影響範囲を局所化し、可用性と保守性を向上させます。また、DMZ（公開サービス）と内部ネットワークを物理または論理的に分離し、firewalldでゾーンベースのアクセス制御を厳格に設定します。
💡 補足：小規模環境では物理サーバーが不足する場合もあるため、仮想マシンやコンテナを用いた役割分割も有効です。
# 実行ユーザー: root
# 目的: NIC をボンディングしてネットワークの冗長化とスループット向上を実現
# 前提条件: eth1, eth2 が存在し、NetworkManager が有効
# 期待結果: bond0 が作成され、eth1/eth2 がスレーブとして動作する
nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup # bond0 インターフェイスを作成
nmcli connection add type ethernet con-name bond0-port1 ifname eth1 master bond0 # eth1 を bond0 スレーブに設定
nmcli connection add type ethernet con-name bond0-port2 ifname eth2 master bond0 # eth2 を bond0 スレーブに設定
nmcli connection up bond0 # bond0 接続を有効化
# 実行ユーザー: root
# 目的: bond0 インターフェイスを内部ネットワーク用の firewalld ゾーンに割り当てる
# 前提条件: bond0 が作成済み、firewalld サービスが稼働中
# 期待結果: bond0 が internal ゾーンに登録され、SSH/HTTP が許可される
firewall-cmd --permanent --zone=internal --add-interface=bond0 # bond0 を internal ゾーンに追加
firewall-cmd --permanent --zone=internal --add-service=ssh # SSH サービスを許可
firewall-cmd --permanent --zone=internal --add-service=http # HTTP サービスを許可
firewall-cmd --reload # 設定を反映
15.2.2 オンプレ＋クラウドのハイブリッド運用
センシティブなデータはオンプレミスで保持し、可用性やスケーラビリティが求められる Web/AP 層はクラウドで展開するハイブリッド構成を採用します。オンプレミスとクラウド間は IPsec/VPN や専用線（AWS Direct Connect、Azure ExpressRoute）で安全に接続し、インフラはコード（AWS CLI、Terraform）で管理します。IPSec や WireGuard による暗号化トンネルも推奨されます。
# 実行ユーザー: root
# 目的: AWS CLI をインストールしてハイブリッド環境の管理を可能にする
# 前提条件: dnf リポジトリが有効、インターネット接続が利用可能
# 期待結果: aws コマンドが利用可能になり、VPC ピアリングなどを操作できる
dnf install -y awscli # AWS CLI をインストール
aws --version # インストール状況を確認
❗ 注意：VPN 設定は双方のネットワークポリシーに準拠して行い、事前にルートテーブルとセキュリティグループを設計してください。
# 実行ユーザー: root
# 目的: strongSwan を用いてオンプレ⇔AWS 間に IPsec VPN トンネルを構築
# 前提条件: AWS 側に Customer Gateway と Virtual Private Gateway が準備済み
# 期待結果: IPsec トンネルが自動起動し、両拠点間で暗号化通信が実現する
dnf install -y strongswan # strongSwan をインストール
cat > /etc/strongswan/ipsec.conf << 'EOF' # VPN 設定を /etc/strongswan/ipsec.conf に書き込む
config setup
charondebug="ike 1, knl 1, cfg 0"
conn aws
keyexchange=ikev2
ike=aes256-sha256-modp2048
esp=aes256-sha256
left=%defaultroute
leftsubnet=10.0.0.0/16
leftid=@onprem.example.com
right=203.0.113.12
rightsubnet=172.31.0.0/16
rightid=@vgw-12345678.amazonaws.com
auto=start
EOF # ipsec.conf 設定終了
cat > /etc/strongswan/ipsec.secrets << 'EOF' # PSK を /etc/strongswan/ipsec.secrets に書き込む
@onprem.example.com : PSK "YourPreSharedKey"
EOF # ipsec.secrets 設定終了
systemctl enable strongswan --now # strongSwan サービスを有効化・起動
15.3 多層防御によるセキュリティ設定（セキュリティ設定）
15.3.1 ネットワークレベル
ネットワークレベルでは、firewalldによるゾーンベースのファイアウォール設定に加え、IPセットを活用したブラックリスト運用、IDS/IPS（Suricata）による異常通信検知を組み合わせて、防御の第一線を強化します。
- ファイアウォール（firewalld）：ゾーンやサービス単位で通信を制限し、不要なポートを閉塞
- IPセット：大量のIPアドレスを高速にマッチングし、動的にブラックリスト管理
- IDS/IPS（Suricata）：リアルタイムでパケットを解析し、シグネチャや挙動ベースで不正通信を検知・遮断
# 実行ユーザー: root
# 目的: firewalld と Suricata を使ったネットワーク多層防御を実装
# 期待結果: ゾーンとIPセットで不要通信を遮断し、IDS/IPSで不正通信を検知・防御
# EPELリポジトリを有効化
dnf install -y epel-release # EPELリポジトリをインストール
# firewalldのインストールと有効化
dnf install -y firewalld # firewalldパッケージをインストール
systemctl enable --now firewalld # firewalldを起動・自動起動設定
# DMZ用ゾーンdmzを作成し、HTTP/HTTPSを許可
firewall-cmd --permanent --new-zone=dmz # dmzゾーンを新規作成
firewall-cmd --permanent --zone=dmz --add-service=http # HTTPサービスを許可
firewall-cmd --permanent --zone=dmz --add-service=https # HTTPSサービスを許可
firewall-cmd --permanent --zone=dmz --add-interface=eth1 # eth1をdmzゾーンに登録
# IPセットbadipsを作成し、ブラックリストを追加
firewall-cmd --permanent --new-ipset=badips --type=hash:ip # IPセットを作成
firewall-cmd --permanent --ipset=badips --add-entry=203.0.113.0/24 # 悪意あるIP範囲を追加
firewall-cmd --permanent --zone=public --add-rich-rule='rule source ipset="badips" drop' # publicゾーンで遮断
# 設定反映
firewall-cmd --reload # 変更を反映
# Suricataのインストールと設定
dnf install -y suricata # Suricataをインストール
systemctl enable --now suricata # Suricataを起動・自動起動設定
suricata-update # 最新ルールセットをダウンロード
15.3.2 OSレベル（SELinux設定）
SELinuxはMandatory Access Control（MAC）を実装し、プロセスやユーザーによるファイル・リソースアクセスを細かく制御します。デフォルトのTargetedポリシーをEnforcingモードで運用し、必要に応じてBooleansやカスタムポリシーモジュールを活用します。
- Enforcingモード：リアルタイムで違反アクセスを遮断
- Booleans：サービスごとにアクセス許可を動的に切り替え
- ポリシーモジュール：auditログからカスタム許可を追加し、必要最小限のアクセスを実現
また、OpenSCAPを用いてSCAP Security Guideに準拠したベースラインチェックを実施し、システム設定のコンプライアンスを自動評価します。
# 実行ユーザー: root
# 目的: SELinuxの強制モード運用とカスタムポリシー適用、OpenSCAPによる定期評価
# 期待結果: SELinuxがenforcingで動作し、必要許可のみが与えられる
# SELinuxポリシーの確認
rpm -q selinux-policy-targeted # Targetedポリシーがインストール済みか確認
sestatus # 現在のSELinuxモードを表示
# Enforcingモードへの切替
setenforce 1 # 一時的にEnforcingモードに変更
sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config # 永続的にEnforcingに設定
# ファイルコンテキストの正規化
restorecon -Rv /var/www/html # Webディレクトリのラベルをデフォルトに戻す
# カスタムポリシーモジュールの生成と適用
ausearch -c 'httpd' --raw | audit2allow -M httpd_custom # httpd用の許可ルールを生成
semodule -i httpd_custom.pp # カスタムモジュールをインストール
# OpenSCAPによるベースラインチェック
dnf install -y openscap-scanner scap-security-guide # スキャナとガイドをインストール
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard --results /tmp/ssg-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml # CISベンチマークで評価
15.3.3 アプリケーションレベル
アプリケーションレベルでは、WAF（ModSecurity）によるWebアプリ保護、Fail2Banによるブルートフォース対策、SSH設定強化を組み合わせて多層防御を実現します。
- WAF（ModSecurity）：リクエストをシグネチャやルールセットでスキャンし、不正なアクセスを遮断
- Fail2Ban：ログ監視により繰り返し認証失敗したIPを自動でブロック
- SSH設定強化：ルートログイン禁止や公開鍵認証のみ許可
# 実行ユーザー: root
# 目的: ModSecurityとFail2Banによるアプリケーション層の防御強化
# 期待結果: WAFが有効化され、ブルートフォース攻撃を自動遮断
# ModSecurityのインストールと有効化
dnf install -y mod_security mod_security_crs # WAFと標準ルールを導入
systemctl restart httpd # Apacheを再起動してモジュールをロード
httpd -M | grep security2_module # security2_moduleがロードされたか確認
# Fail2BanインストールとSSH監視設定
dnf install -y epel-release # EPELリポジトリを有効化
dnf install -y fail2ban # Fail2Banをインストール
systemctl enable --now fail2ban # サービスを起動・自動起動設定
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # 設定ファイルをコピー
sed -i '/^\[sshd\]/,/^$/s/enabled = false/enabled = true/' /etc/fail2ban/jail.local # SSHセクションを有効化
systemctl restart fail2ban # 設定変更を反映
# SSH設定強化（例）
sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config # ルートログイン禁止
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config # パスワード認証禁止
systemctl reload sshd # SSH設定を再読み込み
💡 補足：セキュリティシグネチャやルールセットは定期的にアップデートし、最新の脅威に備えてください。
15.4 バックアップとDRの統合運用
15.4.1 バックアップポリシー
データ保護の基本として「3-2-1ルール」を採用します：3コピー、2種のストレージメディア、1つはオフサイト保管。バックアップの種類はフルバックアップ、差分バックアップ、増分バックアップを組み合わせ、ストレージ消費量と復旧速度のバランスを最適化します。さらに、ファイルレベル、ファイルシステムレベル、ブロックデバイスレベルの各バックアップ手法を用途に応じて使い分けます。
- フルバックアップ：システム全体をアーカイブ（例：tar）
- 差分バックアップ：前回フルバックアップ以降に変更されたファイルを対象
- 増分バックアップ：前回バックアップ以降に変更されたファイルを対象
- LVMスナップショット：稼働中のファイルシステムを一貫性ある状態で取得
- データベースバックアップ：mysqldump や Percona XtraBackup などで論理／物理バックアップ
💡 補足：用途や業務要件に応じて、バックアップスケジュールと保持期間を定義し、定期的にリストアテストを実施してください。
#!/usr/bin/env bash # スクリプトインタプリタを指定
# 実行ユーザー: root # root権限で実行
# 目的: LVMスナップショットを活用した一貫性のあるフルバックアップを取得
# 前提条件: ボリュームグループvg01、論理ボリュームlv_dataが存在
# 期待結果: /backup にバックアップファイルが生成される
TIMESTAMP=$(date +%F_%H%M%S) # YYYY-MM-DD_HHMMSS形式のタイムスタンプ取得
SNAP_NAME=lv_data_snap_${TIMESTAMP} # スナップショット名を定義
SNAP_DEV=/dev/vg01/${SNAP_NAME} # スナップショットデバイスパスを定義
lvcreate --size 1G --name ${SNAP_NAME} --snapshot /dev/vg01/lv_data # lv_dataの1GBスナップショット作成
mkdir -p /mnt/backup_${TIMESTAMP} # マウント用ディレクトリを作成
mount ${SNAP_DEV} /mnt/backup_${TIMESTAMP} # スナップショットをマウント
tar czf /backup/data_full_${TIMESTAMP}.tar.gz -C /mnt/backup_${TIMESTAMP} . # gzip圧縮でアーカイブ
umount /mnt/backup_${TIMESTAMP} # マウント解除
lvremove -f ${SNAP_DEV} # スナップショット削除
rmdir /mnt/backup_${TIMESTAMP} # マウントディレクトリ削除
# cron設定例：毎日深夜2時にバックアップスクリプトを実行
echo "0 2 * * * /usr/local/bin/lvm_backup.sh" >> /etc/crontab # crontabへジョブ登録
15.4.2 DR（Disaster Recovery）計画
DR計画では、RPO（目標復旧時点）とRTO（目標復旧時間）を定義し、オフサイトへのレプリケーションとリカバリ手順を確立します。Bare‐metalリカバリにはRelax-and-Recover（ReaR）を用い、システム全体のイメージと起動可能ISOを生成します。
- RPO/RTO設定：例 RPO=6h、RTO=1h と定義
- レプリケーション：ブロックレベル（DRBD）またはオブジェクト（AWS S3/Glacier）
- DRテスト：定期的なリストア検証およびISOブートテスト
# 実行ユーザー: root # root権限で実行
# 目的: Relax-and-Recover を導入し、ブート可能DRイメージを生成
# 前提条件: EPELリポジトリ有効、インターネット接続
# 期待結果: /etc/rear/output にISOイメージとバックアップ成果物を出力
dnf install -y epel-release rear # EPELからReaRをインストール
rear -d mkbackup # システムバックアップを作成（成果物は/etc/rear/output）
rear -d mkrescue # ブート可能ISOを生成（/etc/rear/outputに配置）
❗ 注意：DR手順はテストを欠かさず実施し、手順書を常に最新に保つことが重要です。
💡 補足：DR環境構築にはDRBDを利用した同期レプリケーションも有効です（LINBIT社製DRBDを参照）。
15.5 運用自動化と監視体制（dnf 自動更新例）
15.5.1 自動化
システム運用において、パッケージの適時更新はセキュリティと安定性の要です。dnf-automaticを用いると、セキュリティアップデートや全アップデートを自動でダウンロード・適用し、メール通知まで行えます。ここでは、AlmaLinux 9 公式ドキュメントに準拠した設定手順を示します。
#!/usr/bin/env bash # スクリプトインタプリタを指定
# 実行ユーザー: root # root 権限で実行
# 目的: dnf-automatic を設定し、毎日深夜にセキュリティアップデートを自動適用・通知する
# 前提条件: AlmaLinux 9 がインストール済み、メール送信環境（postfix 等）が設定済み
# 期待結果: セキュリティ更新のみ自動適用され、更新結果が root@localhost 宛にメール送信される
dnf install -y dnf-automatic # dnf-automatic パッケージをインストール
cp /etc/dnf/automatic.conf /etc/dnf/automatic.conf.bak # 設定ファイルをバックアップ
sed -i 's/^apply_updates = .*/apply_updates = yes/' /etc/dnf/automatic.conf # 自動適用を有効化
sed -i 's/^upgrade_type = .*/upgrade_type = security/' /etc/dnf/automatic.conf # セキュリティ更新のみに限定
sed -i 's/^emit_via = .*/emit_via = email/' /etc/dnf/automatic.conf # 通知方式をメールに設定
sed -i 's/^email_to = .*/email_to = root@localhost/' /etc/dnf/automatic.conf # 通知先メールアドレスを設定
systemctl enable --now dnf-automatic.timer # タイマーを有効化＆起動
# 動作確認（オプション）
systemctl list-timers --all | grep dnf-automatic.timer # タイマーが登録されているか確認
journalctl -u dnf-automatic --since "1 hour ago" # 実行ログを最新1時間分確認
💡 補足：Ansible で複数サーバーに一括展開する場合は、
community.general.dnf_autoupdate モジュールを利用すると設定管理が容易になります。
15.5.2 監視
自動更新だけでは障害検知やリソース異常が見逃される恐れがあります。Prometheus と Grafana を組み合わせ、Node Exporter で OS・ハードウェア指標を収集し、アラートルールで異常を通知する多層監視体制を構築します。
#!/usr/bin/env bash # スクリプトインタプリタを指定
# 実行ユーザー: root # root 権限で実行
# 目的: Prometheus Node Exporter をインストールし、systemd で常時実行させる
# 前提条件: AlmaLinux 9 がインストール済み、ネットワーク接続が利用可能
# 期待結果: ポート 9100 でメトリクスが公開され、Prometheus が取得可能になる
# 1. prometheus ユーザーとディレクトリ作成
useradd --no-create-home --shell /sbin/nologin prometheus # prometheus 用のシステムユーザー作成
mkdir -p /etc/node_exporter /var/lib/node_exporter # 設定・データ用ディレクトリ作成
# 2. バイナリのダウンロードと配置
VERSION=$(curl -s https://api.github.com/repos/prometheus/node_exporter/releases/latest | grep -Po '(?<="tag_name": ")[^"]*') # 最新バージョン取得
cd /tmp # 作業ディレクトリ移動
curl -LO https://github.com/prometheus/node_exporter/releases/download/${VERSION}/node_exporter-${VERSION}.linux-amd64.tar.gz # バイナリを取得
tar xzf node_exporter-${VERSION}.linux-amd64.tar.gz # アーカイブを展開
cp node_exporter-${VERSION}.linux-amd64/node_exporter /usr/local/bin/ # 実行ファイルを配置
cp -r node_exporter-${VERSION}.linux-amd64/consoles /etc/node_exporter/ # コンソールファイル配置
cp -r node_exporter-${VERSION}.linux-amd64/console_libraries /etc/node_exporter/ # ライブラリ配置
# 3. systemd サービス定義
cat << 'EOF' > /etc/systemd/system/node_exporter.service # サービスファイル作成開始
[Unit]
Description=Prometheus Node Exporter for system metrics
Wants=network-online.target # ネットワーク到達を待つ
After=network-online.target
[Service]
User=prometheus # prometheus ユーザーで実行
Group=prometheus # prometheus グループで実行
Type=simple
ExecStart=/usr/local/bin/node_exporter # バイナリ実行
[Install]
WantedBy=multi-user.target # マルチユーザーモードで自動起動
EOF # サービスファイル作成終了
# 4. サービスの有効化・起動
systemctl daemon-reload # systemd 定義を再読み込み
systemctl enable --now node_exporter.service # サービスを有効化・起動
# 5. Prometheus サーバー設定例（/etc/prometheus/prometheus.yml）
cat << 'EOF' > /etc/prometheus/prometheus.yml # Prometheus 設定ファイル作成開始
global:
scrape_interval: 15s # 15秒毎に全ジョブを取得
scrape_configs:
- job_name: 'node_exporter' # Node Exporter 用ジョブ
static_configs:
- targets: ['localhost:9100'] # 監視対象をローカル node_exporter に設定
EOF # 設定ファイル作成終了
# 6. Grafana インストール・起動
dnf install -y https://packages.grafana.com/oss/rpm/grafana-release-1.0-1.noarch.rpm # Grafana リポジトリ追加
dnf install -y grafana # Grafana をインストール
systemctl enable --now grafana-server # Grafana サービスを有効化・起動
❗ 注意：Node Exporter や Grafana の Web UI はデフォルトで認証なしのため、必ずファイアウォールやリバースプロキシでアクセス制限を行ってください。
💡 補足：Alertmanager を併用すると、メールや Slack への通知設定を一元管理でき、SIEM 連携も容易になります。
15.6 ケーススタディ
15.6.1 小規模Webサービス
単一サーバー構成での小規模Webサービスは、コストと管理の手軽さを両立しつつ、適切なセキュリティ対策とバックアップを実装することが重要です。以下では、LAMPスタックの構築から基本的なセキュリティ強化、バックアップ自動化までを詳細に解説します。
#!/usr/bin/env bash # スクリプトインタプリタを指定
# 実行ユーザー: root # root権限でスクリプトを実行
# 目的: LAMPスタックを構築し、小規模Webサービスをセットアップ
# 前提条件: AlmaLinux9がインストール済み、インターネット接続あり
# 期待結果: Apache, MariaDB, PHPがインストールされ、サービスが起動・自動起動設定される
dnf install -y httpd mariadb-server php php-mysqlnd # ApacheとMariaDB、PHPモジュールをインストール :contentReference[oaicite:1]{index=1}
systemctl enable --now httpd # Apacheを起動＆自動起動設定
systemctl enable --now mariadb # MariaDBを起動＆自動起動設定
# MariaDB初期セキュリティ設定（対話式）
mysql_secure_installation << 'EOF' # セキュリティ設定を自動実行
y # ルートパスワード設定有効化
SecurePass123! # 新しいルートパスワードを設定
SecurePass123! # パスワード確認
y # 匿名ユーザー削除
y # リモートルートログイン拒否
y # テストDB削除
y # 権限リロード
EOF
firewall-cmd --permanent --add-service=http # HTTPをファイアウォールで許可
firewall-cmd --permanent --add-service=https # HTTPSを許可
firewall-cmd --reload # 設定を反映
restorecon -Rv /var/www/html # SELinuxコンテキストを正規化 :contentReference[oaicite:2]{index=2}
# Fail2Banを導入してSSH・HTTPのブルートフォースを防御
dnf install -y epel-release fail2ban # EPELリポジトリとFail2Banをインストール :contentReference[oaicite:3]{index=3}
systemctl enable --now fail2ban # Fail2Banを起動＆自動起動設定
また、データベースの定期バックアップとリモート保管を自動化するスクリプト例を以下に示します。これにより、万一の障害時にも迅速に復旧可能な体制を整えます。
#!/usr/bin/env bash # スクリプトインタプリタを指定
# 実行ユーザー: root # root権限で実行
# 目的: MySQL全データベースをダンプし、リモートサーバーに保管
# 前提条件: /backup ディレクトリ作成済み、SSH鍵認証が設定済み
# 期待結果: backup.example.com にダンプファイルが転送される
TIMESTAMP=$(date +%F_%H%M%S) # タイムスタンプを取得
DUMP_FILE="/backup/db_${TIMESTAMP}.sql" # ダンプファイル名を定義
mysqldump --user=root --password='SecurePass123!' --all-databases > ${DUMP_FILE} # 全DBをダンプ
rsync -avz ${DUMP_FILE} backup.example.com:/remote/backup/ # リモートサーバーへ転送
15.6.2 エンタープライズ環境
大規模サービスでは、可用性・スケーラビリティ・耐障害性を確保するため、ロードバランサー、コンテナ化、データベースクラスタ、共有ストレージを統合した多層構成を採用します。
# 実行ユーザー: root # root権限で実行
# 目的: HAProxyとKeepalivedで冗長ロードバランサーを構築
# 前提条件: ネットワーク構成およびVIP(192.168.0.100)を決定済み
# 期待結果: VIPがアクティブノード間でフェイルオーバーする
dnf install -y haproxy keepalived # HAProxyとKeepalivedをインストール :contentReference[oaicite:6]{index=6}
cat << 'EOF' > /etc/haproxy/haproxy.cfg # HAProxy設定を作成
global
maxconn 2000 # 最大同時接続数を指定
log /dev/log local0 # ログ出力先を設定
defaults
mode http # HTTPモードで動作
timeout connect 5s # 接続タイムアウト設定
timeout client 50s # クライアントタイムアウト設定
timeout server 50s # サーバータイムアウト設定
frontend http_front
bind *:80 # ポート80をバインド
default_backend http_back # バックエンド指定
backend http_back
balance roundrobin # ラウンドロビン方式
server web1 10.0.0.11:80 check # web1を登録
server web2 10.0.0.12:80 check # web2を登録
EOF
cat << 'EOF' > /etc/keepalived/keepalived.conf # Keepalived設定を作成
vrrp_script chk_haproxy {
script "pidof haproxy" # HAProxyプロセス監視
interval 2 # 監視間隔(秒)
weight 2 # 重み設定
}
vrrp_instance VI_1 {
state MASTER # 初期状態をMASTERに設定
interface eth0 # 監視インターフェース
virtual_router_id 51 # VRID設定
priority 100 # プライオリティ
authentication {
auth_type PASS # 認証方式をPASSに設定
auth_pass securepass # 認証パスワード
}
virtual_ipaddress {
192.168.0.100 # VIPを指定
}
track_script {
chk_haproxy # 監視スクリプトを適用
}
}
EOF
systemctl enable --now haproxy keepalived # サービスを起動＆自動起動設定
# コンテナ基盤構築: Podmanインストール
dnf install -y podman # Podmanをインストール :contentReference[oaicite:7]{index=7}
podman --version # インストール確認
# DBクラスタ: MariaDB Galera
dnf install -y mariadb-server-galera # Galera対応MariaDBをインストール :contentReference[oaicite:8]{index=8}
cat << 'EOF' > /etc/my.cnf.d/galera.cnf # Galera設定を作成
[mysqld]
wsrep_on=ON # Galeraを有効化
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so # wsrepプロバイダ指定
wsrep_cluster_address="gcomm://10.0.0.11,10.0.0.12,10.0.0.13" # クラスタノード指定
wsrep_node_address="10.0.0.11" # 現在ノードのアドレス
wsrep_cluster_name="galera_cluster" # クラスタ名設定
wsrep_sst_method=rsync # SST方式設定
EOF
galera_new_cluster # 新規クラスタをブートストラップ
systemctl enable --now mariadb.service # MariaDBを起動＆自動起動設定
# 共有ストレージ: GlusterFS
dnf install -y glusterfs-server # GlusterFSをインストール :contentReference[oaicite:9]{index=9}
systemctl enable --now glusterd # Glusterdを起動＆自動起動設定
15.6.3 コンテナと仮想化の併用
仮想マシン上でさらにコンテナを実行することで二重隔離と柔軟性を実現します。KVMによるハイパーバイザー環境にPodmanを組み合わせることで、テスト・本番の環境分離やリソース管理を効率化します。
# 実行ユーザー: root # root権限で実行
# 目的: KVMホストをセットアップし、VM上でPodmanコンテナを運用
# 前提条件: BIOSで仮想化有効、インターネット接続あり
# 期待結果: KVMホストが起動し、VM内でPodmanコンテナを立ち上げ可能
# KVM関連パッケージのインストール
dnf install -y qemu-kvm libvirt virt-install virt-manager # KVMと管理ツールをインストール :contentReference[oaicite:11]{index=11}
systemctl enable --now libvirtd # libvirtdデーモンを起動＆自動起動設定
# 仮想マシン作成例: vm1を作成
virt-install --name vm1 \ # VM名を指定
--memory 2048 \ # メモリ2GBを割当
--vcpus 2 \ # CPUコア数を2に設定
--disk size=20 \ # ディスクサイズ20GBを指定
--os-variant rhel9 \ # OSバリアントをRHEL9に設定
--network network=default,model=virtio \ # ネットワーク設定
--graphics none \ # コンソールはテキストモード
--location 'http://mirror.almalinux.org/almalinux/9/BaseOS/x86_64/os/' \
# インストールソースを指定
--extra-args 'console=ttyS0,115200n8 serial' # コンソール設定
# ゲストVMに対してPodmanをインストール
virsh start vm1 # VMを起動
virsh console vm1 # VMコンソールに接続
# （ゲスト内）
dnf install -y podman # ゲストVMにPodmanをインストール
podman run --detach --name nginx -p 8080:80 nginx # Nginxコンテナをデタッチモードで起動
💡 補足：リソース割り当てには cgroups/v2 を活用し、CPU・メモリ使用量を制限することで安定稼働を実現します。例えば、
podman run --memory=512m --cpus=1 のように指定できます。15.7 学習のまとめ
本章では、AlmaLinux 9を活用したインフラ設計からセキュリティ、多層防御、バックアップ／DR、運用自動化、監視、そして実際のケーススタディまでを一気通貫で学びました。以下のポイントを押さえることで、安全性と可用性を両立した運用基盤を構築し、継続的に改善／検証できる体制が整います。
- サーバー役割分割とネットワーク構成
用途ごとにサーバーを分離し、DMZと内部ネットワークをfirewalldでゾーニング。障害時の影響範囲を局所化し、可用性と保守性を高める。 - ハイブリッド運用
オンプレミスにコアサービスを、クラウドにスケーラブルなWeb/API層を配置。IPsec/VPNやAWS Direct Connectで安全に接続し、インフラはIaC（Terraform/AWS CLI）で管理。 - 多層防御セキュリティ
firewalldのゾーン、IPセットによるブラックリスト、IDS/IPS（Suricata）、SELinux enforcing、ModSecurity＋Fail2Banを組み合わせ、多段階で攻撃を防ぐ。 - バックアップとDR
3-2-1ルール＋LVMスナップショット／Percona XtraBackupで整合性あるバックアップを取得し、Relax-and-Recoverでブート可能ISOを作成。RPO/RTOを明確化し、定期的にテストを実施。 - 運用自動化
dnf-automaticやAnsible、cronでパッケージ更新や設定適用を自動化。変更履歴をGitで管理し、人為的ミスを削減。 - 監視体制
Prometheus＋Grafana＋AlertmanagerでOS／アプリ指標を収集・可視化し、異常時はメールやSlackで即時通知。ELK Stackでログを一元管理し、SIEM連携も可能に。 - ケーススタディの応用
小規模Webサービスからエンタープライズ環境、コンテナ＋仮想化の二重隔離まで、要件に応じた最適構成パターンを理解し、実践的に設計・運用できる。 - 継続的な検証と改善
定期的なリストア／DRテスト、ポリシー・ルールセットのアップデート、手順書・ドキュメントの最新化を徹底し、運用基盤を常に最適化。
