入門EOL対応

入門EOL対応 ~SREが鉄板の流れ全部見せます編~

https://fortee.jp/yapc-hiroshima-2024/proposal/8b778ed2-df11-4bee-a4b7-81e2b85b51c4

ソフトウェアは進化する一方で、全てのバージョンをサポートし保守し続けるのはリソースを効果的に割り当てる観点から現実的ではありません。
セキュリティリスクや管理コストを考慮し、サポート終了期間を設けるEOLを用いた運用が一般的に採用されています。
サービスを運営する中で、EOLに対して時間に余裕を持って対応できればよいですが機能開発が優先されることでリソース不足となってしまうなどでソフトウェアのEOL対応に対して後手に回ってしまうという課題がありました。
このセッションでは、GMOペパボのSREがソフトウェアのEOL対応をベースとした、ソフトウェアをただアップデートするだけじゃない工夫した事例等についてお話します。

話すこと
* EOL対応の意義とメリット、対応プロセスのステップ
* EOL対応をモチベーション高くやる方法
* (時間があったら)過去にEOLで辛かった事例と乗り越えた話(Perlネタ)

Transcript

1. 1 ⼊⾨EOL対応 ~SREが鉄板の流れ全部⾒せます編~ 渡部 ⿓⼀ YAPC::Hiroshima 2024
2. 2 アジェンダ 1. ⾃⼰紹介 2. イントロダクション 3. EOL対応の意義 4. EOL対応プロセスのステップ 5. EOL対応をモチベーション⾼く進める⽅法 6. ⼤変だった事例の紹介 7. まとめ
3. 3 1. ⾃⼰紹介
4. 技術部プラットフォームグループ 2021年 中途入社 4 自己紹介 渡部 龍一 Watanabe Ryuichi • ロール: SRE • 仙台から来ました • YAPC参加歴: 2回目(前回は障害対応の話) • 好きなモジュール: ExtUtils::MakeMaker • SNS: @ryuichi_1208
5. ペパボは、主に個⼈の表現活動を⽀援するためのさまざまなウェブサービスおよびスマートフォンアプ リを提供しています。それぞれのサービスは、以下のようにセグメント分けされています。 5 ホスティング 事業 EC支援 事業 ハンドメイド 事業 金融支援 事業
6. 6 1. インターネットでものを売りたい人を支援 2. 2005年にサービスの提供を開始 3. プライベートクラウド + AWS + GCP 4. 100以上のコンポーネントで構成されている
7. 2. イントロダクション 7
8. 8 用語整理 • EOL = 「End Of Life」の略 • 製品・ソフトウェアのライフサイクルの終了 • EOL対応 = 保守サポートされているバージョンにアップデートや乗り換え 発表のターゲット • 今後EOL対応をやっていく予定の人 • 日々EOL対応をやっている人
9. 9 イントロダクション “ EOL対応歴”
10. イントロダクション 10 • 2017年 CentOS 5、Solaris • 2018年 GlusterFS(分散FS)、Spring、memcached • 2019年 CentOS 6、Python2、Perl 5.8.8、k8s、Solr • 2024年 CentOS 7、MySQL 5.7、Terraform 私のEOL対応歴
11. 11 イントロダクション “ EOL対応ばかりやってない？”
12. 12 イントロダクション
13. 3. EOL対応の意義 13
14. 14 イントロダクション “ なぜEOL対応をやるのか”
15. 15 イントロダクション “ EOL対応をやらないリスク”
16. 16 バグのリスク ライセンス違反の リスク セキュリティリスク 16 意図せず⾃動でアッ プデートが実施され るリスク ソフトウェアの ⾮互換性のリスク
17. 17 EOL対応をやらないリスク • セキュリティリスク ◦ 新たに発見される脆弱性に対して対策が行われない = サイバー攻撃の対象になる • バグのリスク ◦ バグがあっても修正されない ◦ 障害対応中に発覚しても直していく必要があるので障害復旧までの時間が伸びる • ソフトウェアの非互換性のリスク ◦ 古いOSを使っていることが原因で最新バージョンのソフトウェアが使えない ▪ 例) 便利なモニタリングツールが eBPFを用いて実装されてるケース ▪ 場合によっては生産性の低下にも繋がったりします。
18. 18 EOL対応をやらないリスク • ライセンス違反のリスク ◦ アップデートサポートを契約しているケースで EOL後も使い続けることで違反となってしまう • 意図せず自動でアップデートが実施されるリスク ◦ パブリッククラウドでEOLまでに対応しないとベンダー側が指定した時間に自動でアップ デートされてしまうリスク ◦ EOL後は有償サポートに自動切り替えするケースもある ▪ RDS for MySQL 5.7は3/1以降は自動で有償サポートに切り替わる ◦ 認識した上でアップデートを任せたり有償サポートを使う判断
19. 19 EOL対応をやらないリスク • セキュリティリスク ◦ 新たに発見される脆弱性に対して対策が行われない = サイバー攻撃の対象になる • バグのリスク ◦ バグがあっても修正されない = バグを前提として仕様を決めていく必要が出てくる ◦ 障害対応中に発覚しても直していくのは時間が必要 • ソフトウェアの非互換性のリスク ◦ 最新のOSでサポートされていないので動かせない = OSや依存関係があるソフトウェアが 今後アップデートできなくなる ◦ 組み合わせによる性能劣化などが発生したりする • ライセンス違反のリスク
20. 4. EOL対応プロセスのステップ 20
21. イントロダクション 21 • 2017年 CentOS 5、Solaris • 2018年 GlusterFS(分散FS)、Spring、memcached • 2019年 CentOS 6、Python2、Perl 5.8.8、k8s、Solr • 2023年 CentOS 7、MySQL 5.7、Terraform 私のEOL対応歴(再掲)
22. 22 イントロダクション “ 同じようなことやってない？”
23. 23 イントロダクション “ EOL対応フレームワーク”
24. 24 EOL対応プロセスのステップ • 対象の洗い出し • リスク評価と優先順位の決定 • EOL対応戦略の決定(自前パッチ、リスク許容、アップデート) • アップデート準備 • アップデート内容の調査 • アップデート方法の調査 • スケジュールの作成 • テスト • アップデート手順書の作成 • アップデート実施
25. 25 EOL対応プロセスのステップ • 対象の洗い出し ◦ どのサービスのどのロールが対象なのかをリストアップしていく ▪ IaCや構成図から対象を探していく ▪ IT 資産管理ツール(Excel)での管理をやっていたことも ▪ SBOM（Software Bill of Materials、ソフトウェア部品表）を用いた管理
26. 26 EOL対応プロセスのステップ • リスク評価と優先順位の決定 ◦ 全てのOS/ミドルウェア/言語をアップデート対応するのはよほどシンプルなシステム か人的リソースが潤沢なプロジェクト以外は不可能 ◦ 対応するための優先順位を決める必要がある ▪ リスク評価をすることで優先順位を決めるための指標の一つとなる • DREADモデルの脅威分析によるスコア • ビジネス影響度 • リスク軽減策の有無 ◦ 上記で出した指標を元に優先順位を決定していく
27. 27 EOL対応プロセスのステップ • リスク評価の例 ◦ DREADモデル ▪ 危険性 (Damage)：脆弱性が悪用された場合の被害の範囲と深刻度を評価 ▪ 再現性 (Reproducibility)：脆弱性を再現するために必要な技術的なスキルやリソー スの評価 ▪ 影響範囲 (Exploitability)：脆弱性が悪用された場合に、どの程度の範囲で影響を与 える可能性があるかを評価 ▪ 発見性 (Discoverability)：脆弱性が発見される可能性の評価 ▪ 修正性 (Fixability)：脆弱性を修正するための技術的な難易度やコストを評価 ◦ 5つの観点から10段階で評価する手法 ▪ ペパボではアレンジして 3段階で評価してスコアを出している
28. 28 EOL対応プロセスのステップ • リスク評価の例 ◦ ビジネス影響度 ▪ 複数サービスを見ているチームだと並列に対応することはできない ▪ サービスごとのビジネス規模を指標の一つとして考える ▪ サービスのフェーズ: 積極的に機能開発をしているフェーズ、保守フェーズ
29. 29 EOL対応プロセスのステップ • リスク評価の例 ◦ リスク軽減策の有無 ▪ 公式や非公式で有償サポートがある ▪ メンテナーレベルで精通してメンバーが社内にいるケース ▪ セキュリティリスクが高い機能の一時的な停止 ▪ 例: ユーザーのファイルアップロード
30. 30 EOL対応プロセスのステップ • 具体的な例 項目 種類 EOL時期 DREAD ビジネス影響度 軽減策 CentOS7(web app) OS 2024-06-31 12 5 有償延長サポート有 CentOS7(DB) OS 2024-06-31 11 4 有償延長サポート有 MySQL 5.7(VM) ミドルウェア 2023-10-31 10 3 なし MySQL 5.7(RDS) ミドルウェア 2024-02-28 10 4 有償延長サポート有
31. 31 EOL対応プロセスのステップ • EOL対応戦略の決定 ◦ 自前パッチ ▪ セキュリティやバグフィックスを自分たちで行なっていく戦略 ▪ 開発するには専門知識と時間が必要になるしメインストリームで使える機能 が使えなくなったりするデメリットはあります ◦ リスク保有 ▪ リスクであることを認識した上で保有していく ▪ EOLを迎える=使えなくなるわけではない ▪ 優先順位が低いコンポーネントには有効
32. 32 EOL対応プロセスのステップ ◦ マイグレーション ▪ あるOS、ミドルウェア、言語から別のものへ移行すること • 例: MySQL -> PostgreSQL、CentOS -> Ubuntu ◦ アップデート ▪ OS、ミドルウェア、言語自体は変えずにバージョンを上げる ▪ 今回はこちらをメインに紹介
33. 33 EOL対応プロセスのステップ • アップデート準備 ◦ アップデート内容の調査 ▪ 公式が出しているアップデート手順の確認 ▪ アップデートによる変更内容の確認 ▪ 他社テックブログの事例もあれば読み込みを行う ◦ 影響範囲の調査 ▪ アップデートによってシステムのどこに影響が出るかを調査 ▪ 現在のシステムの要件を整理しアップデート後も満たすことが可能かを調べる ▪ ステークホルダーの特定 • システムの利用者、システム仕様に詳しい人、決裁権がある人
34. 34 EOL対応プロセスのステップ • アップデート準備 ◦ アップデート方法の調査 ▪ インプレース、B/G、カナリー ▪ ユーザー影響度やロールバックのしやすさを元に判断 ◦ スケジュールの作成 ▪ テストやQAのスケジュールを決定していく ▪ アップデート実施日の決定 ▪ ダウンタイムの調整、メンテナンス告知なども決める
35. 35 EOL対応プロセスのステップ • アップデート準備 ◦ テスト ▪ アップデートを実施した際に機能面で仕様を満たしているかを ▪ 非機能面の確認も実施する。特にパフォーマンスが著しく劣化するケースもある ので前後で確認できるように性能テストを実施しておく • パフォーマンスの指標は事前に決めておく、SLIがあればそちらを使用 ▪ ありがちなのはアップデートしたらバックアップツールが動きませんやメトリクス が取れてませんケースがあるので正常に動作するかを確認する ▪ アップデートしてうまく動かなかったを想定して切り戻し手順のテストも実施す る
36. 36 EOL対応プロセスのステップ • アップデート準備 ◦ 手順書の作成 ▪ 自動化できる部分は事前にスクリプトを作っておく ▪ 明確性や簡潔性を意識して書く ▪ 対象読者の理解度を考慮
37. 37 EOL対応プロセスのステップ • アップデート実施 ◦ ここまできたら手順をなぞるくらい ◦ 手順自体も自動化が進んでいれば PRマージするだけで完了というケースも ◦ 準備までで9割完了と行っても過言ではない (はず)
38. 38 5. EOL対応をモチベーション⾼く進める⽅法
39. 39 イントロダクション “ EOL対応楽しめてますか？”
40. 40 Twitterのアンケート
41. 41 EOL対応をモチベーション高く進める方法 • 実際の理由を身近な人に聞いてみた結果 ◦ 大変な割には地味で保守的な作業である ◦ 新しいプロジェクトやイノベーションに比べて評価されにくい ◦ EOL = ビジネス停止ではないので優先度が低くなりがちでリソースが足りない (予 算、人員) ◦ システムによっては調整する人が不明で技術的な大変さじゃなくコミュニケーション の大変さで疲弊してしまった
42. 42 イントロダクション “ 楽しくやるには？”
43. 43 イントロダクション “ ジョブクラフティング”
44. 44 EOL対応をモチベーション高く進める方法 • ジョブクラフティング ◦ 仕事の中に自分をひと匙入れること ◦ “やらされ感”のある仕事を“やりがいのあるもの”へと変容させる手法 ◦ 仕事の意味や目的を再定義し、個人の強みや関心に合わせて仕事を自己調整
45. 45 EOL対応をモチベーション高く進める方法 • ジョブクラフティング ◦ タスクのクラフティング ▪ 具体的な業務の内容や方法を変えてみたり、工夫を加えること ◦ 関係性のクラフティング ▪ タスクを進める際の他者(上司、同僚、取引先)との関係性を増やしたり接点を増 やしたり関係性を変えてみること ◦ 認識のクラフティング ▪ タスクの意味や目的の捉え方を変えてみようとすること
46. 46 EOL対応をモチベーション高く進める方法 • タスクのクラフティング ◦ アップデートチェックツールや自動化スクリプトを自作して公開してみる • 関係性のクラフティング ◦ ステークホルダーとの関わりが少ないなら他チームの MTGに飛び入りで参加して何 をやっているのかを把握したり接点を増やす • 認識のクラフティング ◦ CentOSのEOL対応をやるならば何が変わるかだけでなくなぜ変わるのかに着目し てみたり、最新のLinux事情について学ぶ機会にする ◦ その仕事が企業や部署のミッションに対してどう関連するのか考えてみる
47. 47 EOL対応をモチベーション高く進める方法 • モチベーション高く進めるには ◦ ソフトウェアに関するアップデートを追っていく ▪ 現在のバージョンでは実現できなかったことが最新バージョンを使うことで解消さ れることが多くある • Terraform: import機能、テストができたり • MySQL: バージョンアップによるパフォーマンス改善
48. 48 6. ⼤変だった事例の紹介(時間あれば)
49. 49 大変だった事例の紹介 • CentOS 6からCentOS 8に乗り換えたら1年でEOL迎えることになった話 • 一部の営業さんが使っているエンジニア0の謎のシステムのEOL対応をした話 • セキュリティガバナンスが緩かった時代に作られたシステムのEOL対応をしようとしたら新設さ れたセキュリティチームからシステム自体がコンプライアンス違反でアップデートだけでは済まな かった話 • OSアップデートしたら性能が1/5まで下がった話 懇親会とかで聞いてもらったらいっぱい話します！！
50. 50 7. まとめ
51. 51 まとめ • EOL対応は準備が9割 • 地味な作業も主体的に捉え直すことで、やりがいのあるものに仕事を創り 変えていく(ジョブクラフティング)ことでモチベーション⾼く取り組める • 最新は最⾼！！！！ • 来週メインDBのMySQL 8.0アップデートがあるので⾒守っててください
52. 52 ご清聴ありがとうございました