初心に帰ってサーバー運用ルールを見直した話

CCoE実践者コミュニティ #7 初心に帰って サーバー運用ルールを見直した話 2025年07月17日 chocopurin

Self-Introduction 名前：chocopurin ● 職業：とある企業の一般社員 ● 主なお仕事：インフラ時々セキュリティ ● ○ ○ ○ ● ITインフラ構築/維持管理 セキュア開発周りの整備 AWS見習い 直近の出没歴 OWASP Kansai, CCoE実践者コミュニティ関西, tktkセキュリティ勉強会 NCA Annual Conference, 総関西サイバーセキュリティLT大会 Micro Hardening, nakanoshima.dev, レトロゲーム勉強会 [寄稿]ハードニングファン！！2023 2

本講演内容は事実をもとにした フィクションです 3

提供サービスのインフラの変遷 4

こんなメールに見覚えありませんか？ 5

Amazon EC2インスタンスのリタイア ● From ○ ● Subject ○ ● Amazon Web Services Amazon EC2 Maintenance: Instance scheduled for retirement [AWS Account ID: xxxxxxxxxxxx] Body Hello, One or more of your Amazon EC2 instances associated with your AWS account (AWS Account ID: xxxxxxxxxxxx) are scheduled for maintenance that requires your instances to be retired on 2025-07-04. The following instances in the ap-northeast-1 region will be stopped after 2025-07-04 00:05:00 UTC. The affected instances are listed below: i-[該当EC2インスタンスのID] ※代理店経由など契約形態によっては表示形式が違うかもしれません 6

Amazon EC2インスタンスのリタイア ● From ○ ● Subject ○ ● Amazon Web Services Amazon EC2 メンテナンス：インスタンスの廃止予定 [AWS Account ID: xxxxxxxxxxxx] Body こんにちは、 お客様のAWSアカウント（AWSアカウントID: xxxxxxxxxxxx）に関連付けられているAmazon EC2インスタンス の1つ以上について、メンテナンスのため2025-07-04にインスタンスが廃止される予定です。ap-northeast-1 リージョンにある以下のインスタンスは、2025-07-04 00:05:00 UTC以降に停止されます。 影響を受けるインスタンスは以下の通りです。 i-[該当EC2インスタンスのID] ※代理店経由など契約形態によっては表示形式が違うかもしれません 7

Amazon EC2インスタンスのリタイア ● EC2インスタンスが稼働しているハードウェアが廃止されるので、 期限内に別のハードウェアに移ってね（猶予は概ね2週間） ○ ○ ● 該当EC2インスタンスを停止したうえで再び開始すると、 自動的に新しいハードウェアに移行されるよ オペレーションは「再起動」ではなく「停止→開始」でやってね 期限を過ぎると、AWS側で勝手に停止しちゃうからね 【出典】 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/ UserGuide/instance-retirement.html 8

• https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instance-retirement.html

事例：EC2で構築したDB群のリタイア対応 Elastic Load Balancing Amazon EC2 DB1(R) DB3(R/W) DB2(R) DB4(R/W) Network Load • 構築から5年以上経過しており、 各インスタンスに対して、 リタイア日が一斉に設定された • 各インスタンス間で微妙に密結合 な形で構築されており、作業対象 1台切り離すだけでもハードルが 非常に高い Balancer リタイア対応はできたものの、 別途遂行中の案件作業を止める レベルの工数を要することに… 9

EC2インスタンスリタイア対応の課題 ● 回避不可 ○ 文化の違い ● ● ○ ● 自社管理機器：基本的に自由 クラウドサービス：責任共有モデル どこかのハードウェアで動作しており、その機器はいつか寿命を迎える 煩雑な対応作業 ○ ○ ○ 影響調査 手順作成 停止調整（約款はあるけど…）etc 用途によっては 1インスタンスの 停止だけでも一苦労 10

• https://aws.amazon.com/jp/compliance/shared-responsibility-model/

稼働中のEC2インスタンス群を眺めてみた ● 複雑な構築背景 ○ ○ Web, バッチ, ログ集計など様々な用途で利用 ガバナンス未整備時代のツケ ● ● ● ● ファジーな運用ルール ○ ○ ● 試行錯誤でオンプレからEC2に移行したことによるひずみ 構築優先＆ルールは後回し（そして、忘れ去られた…） 気づいたら構築から5年以上経過しているものも 暫定版という名の本稼働プログラム いつの間にか24時間365日稼働が前提になっている ビジネス変化に伴い増加する新インスタンス （リタイア対応増加のリスク） 11

クラウド文化に合わせた 運用ルールの再整備が急務 12

初心に帰る（運用ルールの再整備） ● 要件定義の時点で運用ルールを明確にする 【例】 ○ 定期再起動 ● ● ○ ○ ● 頻度 時間帯 やることは基本的にオンプレと変わらないが、 常にクラウド文化を念頭に置く パッチの自動適用 システムライフサイクル 運用ルールを先に定義しておけば、後工程で負荷軽減に つながる（いわゆるシフトレフトが効いてくる） ○ ○ 停止調整タスクの定型化 設計・実装による対策 etc 13

まとめ ● クラウド化が進んでも、サーバー自体なくなることはない ● EC2インスタンスリタイア対応を通じて、オンプレ自社管理 機器とクラウドサーバーの違いに伴う負債が顕著になった ● オンプレ/クラウドが混在した環境の運用には、各文化の理解が 必須（ただし、運用に対する基本的な知識は変わりないため、 臆する必要はない） 14