構築作業が終わり、確認コマンドでも想定どおりの値になっている。
「これで設定完了です」
そう報告したあと、OSを再起動したら設定が戻っていた。
クラウド環境でインスタンスを再作成したら、同じ設定が入っていなかった。
インフラ構築では、こういうことが起きます。
特に危ないのは、作業直後には正しく見えるケースです。
コマンドを実行した。
設定値も変わった。
疎通もできた。
だから大丈夫だと思っていた。
しかし、再起動後、AMI化後、インスタンス再作成後、DHCP更新後に設定が戻る。
本番運用でこれが起きると、単なる作業ミスでは済まなくなります。
今回は、MTU設定を題材にします。
MTUとは、ネットワークで一度に送れるパケットサイズの上限です。
通常のWebシステムでは、普段あまり意識しないかもしれません。
しかし、クラウド環境、VPN、Direct Connect、閉域接続、ジャンボフレーム、オンプレからクラウドへの移行などが絡むと、MTUは設計・構築・試験で確認すべき項目になります。
今回のトラブルは、次のようなものでした。
RHEL7の環境では、NetworkManager を使ってMTUを設定していた。
ところが、Amazon Linux 2の環境では、同じように設定しようとしても、RHEL7と同じ前提では作業できなかった。
つまり、RHELで使っていた設定手順を、そのままAmazon Linux 2に横展開できなかったのです。
何が起きたのか
ある環境で、ネットワークインターフェースのMTU値をカスタマイズする必要がありました。
RHEL7の環境では、次のように nmcli を使って設定していました。
nmcli c modify "My favorite connection" ethernet.mtu 1600
nmcli は、NetworkManagerを操作するためのコマンドです。
NetworkManagerが管理している接続設定に対して、MTU値などを変更できます。
この場合、設定内容は結果的に以下のようなファイルにも反映されます。
/etc/sysconfig/network-scripts/ifcfg-XXXX
そのため、RHEL7で構築経験がある人からすると、
「MTUを変えるなら、nmcli で設定すればよい」
という感覚になりがちです。
しかし、今回のAmazon Linux 2環境では、同じ前提が成り立ちませんでした。
RHEL7と同じように NetworkManager.service を前提にした構成ではなく、nmcli 前提の手順をそのまま使うことができなかったのです。
問題は「MTUの設定方法を知らなかったこと」ではない
ここで大事なのは、
「Amazon Linux 2では、このファイルを編集しましょう」
という単純な話ではありません。
本質的な問題は、OSが変わったにもかかわらず、ネットワーク設定の管理方式が同じだと思い込んだことです。
Linuxといっても、すべてが同じではありません。
RHEL、CentOS、Amazon Linux、Ubuntu、Oracle Linuxなど、ディストリビューションが違えば、設定ファイルの場所、サービス管理の考え方、ネットワーク設定の反映方法、標準で有効になっているサービスが変わることがあります。
さらに、同じRHEL系に見えても、バージョンやクラウドイメージの作りによって、デフォルト構成が違うこともあります。
つまり、
「前の案件で動いた」
「RHELではこうだった」
「Linuxだから同じだろう」
という判断は、インフラ構築では危険です。
なぜこういうことが起きるのか
オンプレミス環境のLinuxと、クラウド環境のLinuxでは、サーバの作られ方が違います。
オンプレミスでは、OSをインストールし、ネットワーク設定を作り込み、固定的なサーバとして長期間運用することが多くあります。
一方、クラウド環境では、AMIなどのイメージからインスタンスを起動し、起動時にIPアドレス、ホスト名、鍵情報、ネットワーク関連の初期設定などが自動的に構成されることがあります。
Amazon Linux 2のようなクラウド向けのOSイメージでは、オンプレミスのRHEL環境と同じ管理サービス構成になっているとは限りません。
そのため、NetworkManagerだけでなく、network service、DHCP、cloud-init、AMI作成時の状態など、複数の仕組みが関係する場合があります。
今回の環境では、RHEL7で使っていたNetworkManager前提の設定手順を、そのまま使える構成ではありませんでした。
見るべきポイントは、
「どのOSか」
だけではありません。
より正確には、
「そのOSイメージでは、ネットワーク設定を何が管理しているのか」
です。
ここを確認せずに手順を横展開すると、設定が反映されない、再起動後に戻る、別インスタンスでは挙動が違う、というトラブルにつながります。
なお、Amazon Linux 2023では、さらに事情が変わります。
AWS公式ドキュメントでは、AL2023では `systemd-networkd` がネットワークインターフェースを管理し、AL2で使われていた `dhclient` から変更されていると説明されています。
つまり、Amazon Linux 2で確認した手順も、Amazon Linux 2023にそのまま横展開できるとは限りません。
RHEL7ではNetworkManager、Amazon Linux 2では別の見方が必要だった
今回の差分を簡単に整理すると、以下のようになります。
RHEL7では、NetworkManagerがネットワーク設定の中心になっている環境があります。
その場合、nmcli で接続プロファイルを変更することが自然な方法になります。
一方で、Amazon Linux 2では、環境によってはNetworkManagerを前提にできません。
そのため、インターフェース設定ファイルやDHCPクライアント設定、起動時にネットワーク設定へ関わる仕組みを確認する必要があります。
たとえば、インターフェース側では以下のような設定ファイルを確認します。
/etc/sysconfig/network-scripts/ifcfg-eth0
MTU値を指定する場合、環境に応じて次のような設定を追加・変更します。
MTU=1600
さらに、DHCPでネットワーク設定を取得している場合は、DHCPクライアント側の設定も確認対象になります。
/etc/dhcp/dhclient.conf
ここで出てくるコマンドやファイルパスを、すべて丸暗記する必要はありません。
大事なのは、個別のコマンドを覚えることではなく、
「誰がネットワーク設定を管理しているのか」
「どこに書けば再起動後も残るのか」
「何に上書きされる可能性があるのか」
という構造を押さえることです。
この図で見てほしいのは、設定値の違いではありません。
同じMTU設定でも、RHEL7ではNetworkManager経由、Amazon Linux 2では設定ファイルやDHCP関連の確認が中心になる、という設定経路の違いです。
一番怖いのは、設定できたように見えてしまうこと
この手のトラブルで怖いのは、最初から完全に失敗してくれるとは限らないことです。
コマンドが存在しない。
サービスが存在しない。
設定ファイルが見つからない。
ここまで分かりやすく失敗してくれれば、まだよいです。
問題は、設定したつもりになっているケースです。
たとえば、次のようなコマンドで確認したとします。
ip link show eth0
その時点では、MTUが変わっているように見える。
しかし、ネットワークサービスを再起動すると戻る。
OSを再起動すると戻る。
AMIから再作成すると戻る。
DHCP更新後に戻る。
別のインスタンスでは挙動が違う。
この場合、作業者の感覚としては、
「設定したのに戻った」
「なぜか環境によって違う」
「手順通りにやったのに再現しない」
となります。
しかし、原因はシンプルです。
その設定が、永続化される場所に入っていなかった。
または、
永続化したつもりの設定が、別の仕組みに上書きされていた。
作業直後に設定値が変わることと、運用中もその設定が維持されることは、別の話です。
設定確認は「今」だけで終わらせない
MTU設定後に ip link show eth0 で確認することは必要です。
しかし、それは「今そうなっている」ことを見ているだけです。
インフラ構築では、設定直後だけでなく、network再起動後、OS再起動後、AMI化・再作成後、DHCP更新後まで確認します。
設定直後にMTUが変わっているか
network再起動後も維持されるか
OS再起動後も維持されるか
AMI化・再作成後も維持されるか
DHCP更新後に戻らないか
この図で伝えたいのは、「今変わっているか」だけでなく、戻らないかまで見る必要がある、ということです。
このトラブルを防ぐための確認観点
1. ネットワーク設定の管理方式を確認する
対象OSでネットワーク設定を何が管理しているかを最初に確認します。
systemctl status NetworkManager
systemctl status network
ls -l /etc/sysconfig/network-scripts/
cat /etc/sysconfig/network-scripts/ifcfg-eth0
見るべきなのは、コマンドが使えるかどうかだけではありません。
そのサービスがOS起動時に使われているか。
対象インターフェースを管理しているか。
設定ファイルの内容と実際の状態が合っているか。
ここまで確認します。
2. 一時設定と永続設定を分ける
MTUは、一時的に変更するだけなら次のようなコマンドでも変更できます。
ip link set dev eth0 mtu 1600
しかし、これは基本的に一時的な変更です。
OS再起動後に維持されるかは別問題です。
一時設定で確認するのか。
永続設定として設計するのか。
ここを混同すると、構築時は動いていたのに、本番運用で戻るということが起きます。
3. DHCPやcloud-initによる上書きを確認する
クラウド環境では、OSが起動した後に、DHCPやcloud-initなどがネットワーク設定に関わることがあります。
そのため、設定ファイルに値を書いただけでは不十分な場合があります。
確認すべきことは、たとえば次のような点です。
DHCPで取得した設定によりMTUが上書きされないか
dhclient.conf で明示的な設定が必要か
cloud-initが起動時にネットワーク設定を生成・変更していないか
AMI化した後、別インスタンスで同じ設定が再現されるか
さらに対策として、手作業で変更した内容を、AMI作成手順、構築手順、構成管理、または自動構築の仕組みに反映しておく必要があります。
詳細設計と構築手順では「設定値」だけでなく「反映と確認」まで書く
詳細設計書に、
MTUを1600に設定する
とだけ書いてあったとします。
設定値だけでは、構築する側は判断できません。
少なくとも次の情報が必要です。
対象OS：
Amazon Linux 2
対象インターフェース：
eth0
設定値：
MTU=1600
設定箇所：
/etc/sysconfig/network-scripts/ifcfg-eth0
DHCP設定：
/etc/dhcp/dhclient.conf の更新要否を確認
反映方法：
networkサービス再起動、またはOS再起動
確認方法：
ip link show eth0
ping疎通
必要に応じてパケットサイズ指定で疎通確認
永続化確認：
OS再起動後もMTU値が維持されること
AMI化・再作成後もMTU値が維持されること
DHCP更新後にMTU値が戻らないこと
これくらい書いて、ようやく構築・試験できる設計になります。
構築手順書に落とす場合も同じです。
手順書には、設定コマンドだけでなく、変更前確認、変更後確認、再起動後確認、必要に応じてAMI化・再作成後の確認まで含める必要があります。
たとえば、作業の流れとしては次のようになります。
1. 現在のMTU値を確認する
2. 対象インターフェースを確認する
3. ネットワーク設定の管理方式を確認する
4. 設定ファイルやDHCP設定を修正する
5. network再起動またはOS再起動で反映する
6. MTU値を確認する
7. OS再起動後に再確認する
8. 必要に応じてAMI化・再作成後に再確認する
試験項目では「今の設定値」だけを見ない
ip link show eth0 だけでは「今の状態」しか分かりません。
実務では次の観点まで確認します。
特にクラウド環境では、AMI化・再作成後の確認が重要です。
Auto Scalingや障害復旧で新しいインスタンスが起動したときに設定が戻るなら、構築時に確認できていても運用には耐えません。
レビューでは設定値ではなく、設定が残る仕組みを見る
MTU設定の設計書や手順書をレビューするなら、次のような観点で見ます。
対象OS・バージョン・対象インターフェースが明記されているか
設定箇所と反映方法が明記されているか
NetworkManager前提か、network service前提かが明記されているか
DHCP・cloud-initの影響を確認しているか
OS再起動後の確認があるか
AMI化・再作成後の確認があるか
「MTU=1600と書いてあるからOK」では、このトラブルは防げません。
設定値ではなく、設定が残る仕組みまで見ることがレビューのポイントです。
まとめ
今回のトラブルは、RHEL7とAmazon Linux 2でMTU設定方法が違っていた、という事例です。
ただし、学ぶべきことは「Amazon Linux 2ではこのファイルを編集する」という単純な話ではありません。
重要なのは、以下です。
OSが変われば、設定の管理方式も変わる
コマンドではなく、管理している仕組みを見る
設定直後だけでなく、再起動後・再作成後も確認する
詳細設計では、設定値だけでなく設定箇所・反映方法・確認方法まで書く
クラウド環境では、AMI化・再作成後も同じ設定になるかを見る
コマンドを知っていること以上に、その設定がどの仕組みに管理され、再起動後も維持されるのかを確認できること。
この視点が、インフラ構築の品質を分けます。
関連記事
今回の記事で扱った「設定値だけでなく、設定箇所・反映方法・確認方法・永続化確認まで設計に落とす」という考え方は、以下の記事でも整理しています。
【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程
シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。
コメント