AWSインフラ運用の地味だけど大変な話

Transcript

1. 現場エンジニアが語る IJDS AWS Tech Session AWS インフラ運用の“地味だけど大変”な話 〜Lambda ランタイム更新と RDS Blue/Green デプロイの実録 〜 2026年 09月 16日 日本アイ・ビー・エムデジタルサービス株式会社 AWS Platform本部 辻川 弘規
2. 自己紹介 インフラからアプリまで、幅広く担当しています。 辻川 弘規 (つじかわ ひろき) 所属 IJDS AWS Platform 本部 仕事内容 インフラ構築（CDK）、アプリ開発（コンテナ系 /Lambda）、PJ マネジメント 保有資格 2025 - AWS Ambassadors 2024 - Japan AWS Top Engineers G 検定 / 生成 AI パスポート 趣味 読書 / 映画鑑賞 / 競馬鑑賞 © 2026 IBM Corporation 2
3. 構築は、華やか。 でも、システムの人生は、稼働してからが長い。 リリースはゴールではなく、スタート。適切に・安全に保ち続ける日々が始まる。 © 2026 IBM Corporation 3
4. Agenda 1. 案件概要/背景 2. Lambda EOL対応（ランタイム更新 & Transform Custom） 3. RDS バージョンアップ対応（Blue/Green デプロイの一苦労） 4. まとめ © 2026 IBM Corporation 4
5. 数年前に作ったとあるシステム B to B 及び B to C 向けの複数システム。今も稼働中です。 © 2026 IBM Corporation 5
6. 数年前に作ったとあるシステム B to B 及び B to C 向けの複数システム。今も稼働中です。 ポイント： APIやバッチで利用するLambda が複数システムに散在。EOL 対応は“膨大な数”になる。 © 2026 IBM Corporation 6
7. 作って終わり、ではない 適切な状態を保ち、セキュリティ的にも安全に稼働させ続ける。それが保守運用。 安全に保つ 止めない 新しさを保つ 脆弱性・ EOL への対応。 放置はセキュリティリスクに直結。 B to C なので、ユーザーは常にいる。 ダウンタイムは最小限に。 ランタイムやエンジンが古びると、 やがて更新もできなくなる。 © 2026 IBM Corporation 7
8. 今回のミッションは、二つ。 放置すると、どうなる？ Mission 1 Mission 2 Lambda の EOL 対応 RDS のバージョンアップ ランタイムの更新 エンジンの更新 放置すると 放置すると セキュリティ更新が止まり、いずれ新規作成・更新ができなく サポートが切れ、セキュリティ・性能・機能面で取り残される。 なる。 © 2026 IBM Corporation 8
9. 今回のミッションは、二つ。 放置すると、どうなる？ Mission 1 Mission 2 Lambda の EOL 対応 RDS のバージョンアップ ランタイムの更新 エンジンの更新 放置すると 放置すると セキュリティ更新が止まり、いずれ新規作成・更新ができなく サポートが切れ、セキュリティ・性能・機能面で取り残される。 なる。 © 2026 IBM Corporation 9
10. なぜランタイム更新が必要か Lambda ランタイムには EOL がある。放置はできない。 放置するとどうなるか セキュリティ更新が止まる 脆弱性が見つかっても、ランタイム側の修正が届かなくなる。 いずれデプロイできなくなる 今回の対象ランタイム Python 3.9 → 3.13 約 100 個 EOL のランタイムでは新規作成・更新ができなくなる。 Python 約 80 （ 3PJ × 3 環境） + Node 系 20 © 2026 IBM Corporation 10
11. 膨大な数に、 AWS Transform Custom 手作業では現実的でない。変換を自動化する。 AWS Transform Customとは AWS Transform Custom は、技術的負債を大規模に解消するエージェンティック AI サービスです。最大の特徴は、共通パターンだけでなく組織固有の技術的負債 パターンも学習して自動変換できることです。 1. 実行時間を 80% 以上短縮 - 手動で行っていた反復的な変換タスクを自動化 2. 継続的学習 - コードサンプル、ドキュメントなどから学習精度が向上 3. any-to-any 変換 - 言語・フレームワーク・ランタイム間の任意の変換が可能 4. 自動化の専門知識が不要 - 自然言語で変換を定義可能 © 2026 IBM Corporation 11
12. 膨大な数に、 AWS Transform Custom 手作業では現実的でない。変換を自動化する。 二つの変換から、カスタム変換を選んだ AWS マネージド変換 カスタム変換（採用） 標準的なバージョンアップをお任せで実行。 共通レイヤーのパッケージバージョンなど、より細かい指示を渡したかった。 手軽だが、細かい指定はしにくい。 Transform がコードを分析し、変換定義を作って自動適用 新しい型表記へ置換 非推奨記法の刷新 typing.List → list など、組込み型へ。 datetime.utcnow() など 3.13 で非推奨の記法を修正。 © 2026 IBM Corporation 12
13. 知らないコードは、 Kiro に説明させる 構築担当でなくても、理解を底上げできる。 直面した壁 対象のうち一つは、自分が構築担当ではないシステム。 中身を知らないコードをいきなり更新するのは怖い。 まず「何がどう動いているか」を理解する必要があった。 Kiro で理解を底上げ コード構造を解説させる どこがどう呼ばれ、何をしているかを把握。 ドキュメントと照らし合わせ AI の説明と既存資料を突き合わせて裏取り。 AI は作業の代わりではなく 人が判断に集中するための支え © 2026 IBM Corporation 13
14. CI/CD ごと対応する CodeBuild のランタイムも、 CDK の変更で。 CI/CD を内包しているので、ビルドする CodeBuild 側も合わせて更新。すべて CDK の変更で対応。 変更前 変更後 runtime-versions: runtime-versions: python: 3.9 python: 3.13 docker: 18 （古い記述） docker の記述は削除 CodeBuild イメージ CodeBuild イメージ （旧い Ubuntu イメージ） aws/codebuild/standard:8.0 へ © 2026 IBM Corporation 14
15. Lambda EOL対応のまとめ 良かった点 注意点 膨大な数を一括でさばけた AWS Transform Customによって カスタム変換がコードを分析し、変換を自動化。 依存パッケージは細かく指定 共通レイヤーのバージョン固定が必要だった。 担当外のコードも理解できた Kiro の解説とドキュメント照合で底上げ。 CI/CD 側の対応も忘れない CodeBuild のランタイム・イメージも同時に更新。 既存CI/CDのおかげでスムーズ更新 ダウンタイム0でLambdaのバージョンアップ完了。 © 2026 IBM Corporation 15
16. 今回のミッションは、二つ。 放置すると、どうなる？ Mission 1 Mission 2 Lambda の EOL 対応 RDS のバージョンアップ ランタイムの更新 エンジンの更新 放置すると 放置すると セキュリティ更新が止まり、いずれ新規作成・更新ができなく サポートが切れ、セキュリティ・性能・機能面で取り残される。 なる。 © 2026 IBM Corporation 16
17. RDSのバージョンアップをスムーズに 本番環境を止めずにバージョンアップ対応の実施を。そのために B/Gで切り替えたい。 放置できない理由 RDS Blue/Green デプロイを選んだ理由 2026/5/31 に特定のマイナーバージョンの標準サポー トが終了。 本番を止めずに切り替えたい 停止は切り替えの瞬間だけ。 放置すればメンテナンス期間に自動アップグレードされる。 いつ・どう変わるかをこちらで選べなくなる。 8.0.42 → 8.4.9 へ、計画的に上げる。 © 2026 IBM Corporation 新環境を安心して検証 Green は Blue から常にデータ同期される。 問題があれば戻せる 旧環境は一定時間残るので切戻し可能。（ただし注意事項あり） 17
18. なぜ RDS Blue/Green デプロイを選んだか RDS Blue/Green デプロイとは データベースの変更をより安全、簡単、高速に行うための機能です。本番環境の クローンを作成し、変更をテストしてから データロスゼロで切り替えます。 特徴 1. 通常 1 分未満の切り替え - 短時間・予測可能なダウンタイム 2. 常にデータ同期 - Green環境作成後も常にデータ同期 データ同期 3. データロスゼロ - 切り替え中は書き込みをブロックし、完全同期後に切り替え 主なユースケース - メジャー/マイナーバージョンアップグレード -スキーマ変更（論理レプリケーションを壊さないもの） © 2026 IBM Corporation 18
19. パラメータグループは Kiro と整理 変更と整理を、相談しながら進めた。 バージョンが上がるとデフォルト値が変わる。現行と新を全部突き合わせ、どう扱うかを三つに分類した。 戻す 維持する 自動に任せる 8.4 で変わったが、アプリに影響するも の。 8.4 の値の方が適切だと確認できたもの。 インスタンスサイズに応じて自動で決 まるもの。 time_zone / 文字セット / スロークエリ監視 binlog_format=ROW / ssl_fips_mode=ON など。 innodb_dedicated_server=ON でバッファプー 安全・性能面で 8.4 のままで良い。 ル等を自動調整。無理に固定しない。 必須 8 パラメータ ポイント：必須 8 パラメータはすべて Dynamic 。パラメータグループの即時適用でリブート不要。 © 2026 IBM Corporation 19
20. 想定外だったこと ダウンタイムは短い。でも 2 段階更新が待っていた。 バージョンアップしたGreen環境の作成ができない —— 作成→変更の 2 ステップ （カスタムのパラメータグループを適用させたい場合に限り） 1 Green を新規作成 現行と同じ 8.0.42 ・デフォルト構成で 作る 2 Green を変更 8.4.9 に上げ、カスタムパラメータを適 用 この間も、 Green は Blue からずっとデータを同期し続けてくれる。 切り替えのダウンタイムを実測 接続コマンドを 1 秒間隔で叩く検証ツール（これも Kiro に作成させた）で、実際の停止時間を計測した。 実測したダウンタイム 15 秒 ほど。この瞬間だけの停止。 © 2026 IBM Corporation 20
21. RDS バージョンアップ対応のまとめ 1 パラメータグループは事前に突き合わせ with Kiro Green には必ずカスタムパラメータグループを明示指定する。 2 バージョンアップは 2 ステップで変更 作成→変更の順で進む。（カスタムのパラメータグループを適用させたい場合） 3 ロールバックには注意 切り替え後、旧 Blue にはデータが同期されない（読み取り専用で残るだけ）。切戻し時はその間の更新が失われる。 4 最後にレグレッション試験 切り替え後に主要機能が壊れていないかを必ず確かめる。 © 2026 IBM Corporation 21
22. まとめ © 2026 IBM Corporation 22
23. 想定外を、想定内に変える 計画表と手順書。検証環境で確立してから本番へ。 検証環境で手順を確立してから、本番へ 開発 ステージング 本番 手順を組み立てる 本番同様でリハーサル 確立した手順で実行 “想定外”を“想定内”に変えたのは、この二つ デプロイ計画表 手順書 いつ・何を・どの順でやるかを事前に可視化。 検証環境で確立した手順を、そのまま本番へ。 © 2026 IBM Corporation 23
24. 大きなトラブルなく、成功 メンテナンス時間を最小限に。 地道で怖い作業を、安心・安全にやり切った 1 メンテナンス時間を最小限 B/G で切り替えの瞬間だけ。ダウンタイムは実測 15 秒ほど。 2 大きなトラブルなく成功 事前の検証と手順確立で、本番を安定して切り替え。 3 AI で安心・安全に 膨大で神経を使う作業を、 AI の支えで進められた。 © 2026 IBM Corporation 24
25. 地味で怖い守りこそ、 AI で“怖くない”に変えられる。 守りの作業を、踏み込める作業に。 作って終わり、ではない。 怖い守りの運用こそ、 AI と事前検証・手順書で、“想定外”を“想定内”に。 守りの作業を、怖い作業から、安心して踏み込める作業へ。 © 2026 IBM Corporation 25