入門EOL対応 - Speaker Deck

入門EOL対応

by ryuichi1208

Slide 1

Slide 1 text

1 ⼊⾨EOL対応 ~SREが鉄板の流れ全部⾒せます編~ 渡部⿓⼀ YAPC::Hiroshima 2024

Slide 2

Slide 2 text

2 アジェンダ 1. ⾃⼰紹介 2. イントロダクション 3. EOL対応の意義 4. EOL対応プロセスのステップ 5. EOL対応をモチベーション⾼く進める⽅法 6. ⼤変だった事例の紹介 7. まとめ

Slide 3

Slide 3 text

3 1. ⾃⼰紹介

Slide 4

Slide 4 text

技術部プラットフォームグループ 2021年中途入社 4 自己紹介渡部龍一 Watanabe Ryuichi ● ロール: SRE ● 仙台から来ました ● YAPC参加歴: 2回目(前回は障害対応の話) ● 好きなモジュール: ExtUtils::MakeMaker ● SNS: @ryuichi_1208

Slide 5

Slide 5 text

ペパボは、主に個⼈の表現活動を⽀援するためのさまざまなウェブサービスおよびスマートフォンアプリを提供しています。それぞれのサービスは、以下のようにセグメント分けされています。 5 ホスティング事業 EC支援事業ハンドメイド事業金融支援事業

Slide 6

Slide 6 text

6 1. インターネットでものを売りたい人を支援 2. 2005年にサービスの提供を開始 3. プライベートクラウド + AWS + GCP 4. 100以上のコンポーネントで構成されている

Slide 7

Slide 7 text

2. イントロダクション 7

Slide 8

Slide 8 text

8 用語整理 ● EOL = 「End Of Life」の略 ● 製品・ソフトウェアのライフサイクルの終了 ● EOL対応 = 保守サポートされているバージョンにアップデートや乗り換え発表のターゲット ● 今後EOL対応をやっていく予定の人 ● 日々EOL対応をやっている人

Slide 9

Slide 9 text

9 イントロダクション “ EOL対応歴”

Slide 10

Slide 10 text

イントロダクション 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対応歴

Slide 11

Slide 11 text

11 イントロダクション “ EOL対応ばかりやってない？”

Slide 12

Slide 12 text

12 イントロダクション

Slide 13

Slide 13 text

3. EOL対応の意義 13

Slide 14

Slide 14 text

14 イントロダクション “ なぜEOL対応をやるのか”

Slide 15

Slide 15 text

15 イントロダクション “ EOL対応をやらないリスク”

Slide 16

Slide 16 text

16 バグのリスクライセンス違反のリスクセキュリティリスク 16 意図せず⾃動でアップデートが実施されるリスクソフトウェアの⾮互換性のリスク

Slide 17

Slide 17 text

17 EOL対応をやらないリスク ● セキュリティリスク ○ 新たに発見される脆弱性に対して対策が行われない = サイバー攻撃の対象になる ● バグのリスク ○ バグがあっても修正されない ○ 障害対応中に発覚しても直していく必要があるので障害復旧までの時間が伸びる ● ソフトウェアの非互換性のリスク ○ 古いOSを使っていることが原因で最新バージョンのソフトウェアが使えない ■ 例) 便利なモニタリングツールが eBPFを用いて実装されてるケース ■ 場合によっては生産性の低下にも繋がったりします。

Slide 18

Slide 18 text

18 EOL対応をやらないリスク ● ライセンス違反のリスク ○ アップデートサポートを契約しているケースで EOL後も使い続けることで違反となってしまう ● 意図せず自動でアップデートが実施されるリスク ○ パブリッククラウドでEOLまでに対応しないとベンダー側が指定した時間に自動でアップデートされてしまうリスク ○ EOL後は有償サポートに自動切り替えするケースもある ■ RDS for MySQL 5.7は3/1以降は自動で有償サポートに切り替わる ○ 認識した上でアップデートを任せたり有償サポートを使う判断

Slide 19

Slide 19 text

19 EOL対応をやらないリスク ● セキュリティリスク ○ 新たに発見される脆弱性に対して対策が行われない = サイバー攻撃の対象になる ● バグのリスク ○ バグがあっても修正されない = バグを前提として仕様を決めていく必要が出てくる ○ 障害対応中に発覚しても直していくのは時間が必要 ● ソフトウェアの非互換性のリスク ○ 最新のOSでサポートされていないので動かせない = OSや依存関係があるソフトウェアが今後アップデートできなくなる ○ 組み合わせによる性能劣化などが発生したりする ● ライセンス違反のリスク

Slide 20

Slide 20 text

4. EOL対応プロセスのステップ 20

Slide 21

Slide 21 text

イントロダクション 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対応歴(再掲)

Slide 22

Slide 22 text

22 イントロダクション “ 同じようなことやってない？”

Slide 23

Slide 23 text

23 イントロダクション “ EOL対応フレームワーク”

Slide 24

Slide 24 text

24 EOL対応プロセスのステップ ● 対象の洗い出し ● リスク評価と優先順位の決定 ● EOL対応戦略の決定(自前パッチ、リスク許容、アップデート) ● アップデート準備 ● アップデート内容の調査 ● アップデート方法の調査 ● スケジュールの作成 ● テスト ● アップデート手順書の作成 ● アップデート実施

Slide 25

Slide 25 text

25 EOL対応プロセスのステップ ● 対象の洗い出し ○ どのサービスのどのロールが対象なのかをリストアップしていく ■ IaCや構成図から対象を探していく ■ IT 資産管理ツール(Excel)での管理をやっていたことも ■ SBOM（Software Bill of Materials、ソフトウェア部品表）を用いた管理

Slide 26

Slide 26 text

26 EOL対応プロセスのステップ ● リスク評価と優先順位の決定 ○ 全てのOS/ミドルウェア/言語をアップデート対応するのはよほどシンプルなシステムか人的リソースが潤沢なプロジェクト以外は不可能 ○ 対応するための優先順位を決める必要がある ■ リスク評価をすることで優先順位を決めるための指標の一つとなる ● DREADモデルの脅威分析によるスコア ● ビジネス影響度 ● リスク軽減策の有無 ○ 上記で出した指標を元に優先順位を決定していく

Slide 27

Slide 27 text

27 EOL対応プロセスのステップ ● リスク評価の例 ○ DREADモデル ■ 危険性 (Damage)：脆弱性が悪用された場合の被害の範囲と深刻度を評価 ■ 再現性 (Reproducibility)：脆弱性を再現するために必要な技術的なスキルやリソースの評価 ■ 影響範囲 (Exploitability)：脆弱性が悪用された場合に、どの程度の範囲で影響を与える可能性があるかを評価 ■ 発見性 (Discoverability)：脆弱性が発見される可能性の評価 ■ 修正性 (Fixability)：脆弱性を修正するための技術的な難易度やコストを評価 ○ 5つの観点から10段階で評価する手法 ■ ペパボではアレンジして 3段階で評価してスコアを出している

Slide 28

Slide 28 text

28 EOL対応プロセスのステップ ● リスク評価の例 ○ ビジネス影響度 ■ 複数サービスを見ているチームだと並列に対応することはできない ■ サービスごとのビジネス規模を指標の一つとして考える ■ サービスのフェーズ: 積極的に機能開発をしているフェーズ、保守フェーズ

Slide 29

Slide 29 text

29 EOL対応プロセスのステップ ● リスク評価の例 ○ リスク軽減策の有無 ■ 公式や非公式で有償サポートがある ■ メンテナーレベルで精通してメンバーが社内にいるケース ■ セキュリティリスクが高い機能の一時的な停止 ■ 例: ユーザーのファイルアップロード

Slide 30

Slide 30 text

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 有償延長サポート有

Slide 31

Slide 31 text

31 EOL対応プロセスのステップ ● EOL対応戦略の決定 ○ 自前パッチ ■ セキュリティやバグフィックスを自分たちで行なっていく戦略 ■ 開発するには専門知識と時間が必要になるしメインストリームで使える機能が使えなくなったりするデメリットはあります ○ リスク保有 ■ リスクであることを認識した上で保有していく ■ EOLを迎える=使えなくなるわけではない ■ 優先順位が低いコンポーネントには有効

Slide 32

Slide 32 text

32 EOL対応プロセスのステップ ○ マイグレーション ■ あるOS、ミドルウェア、言語から別のものへ移行すること ● 例: MySQL -> PostgreSQL、CentOS -> Ubuntu ○ アップデート ■ OS、ミドルウェア、言語自体は変えずにバージョンを上げる ■ 今回はこちらをメインに紹介

Slide 33

Slide 33 text

33 EOL対応プロセスのステップ ● アップデート準備 ○ アップデート内容の調査 ■ 公式が出しているアップデート手順の確認 ■ アップデートによる変更内容の確認 ■ 他社テックブログの事例もあれば読み込みを行う ○ 影響範囲の調査 ■ アップデートによってシステムのどこに影響が出るかを調査 ■ 現在のシステムの要件を整理しアップデート後も満たすことが可能かを調べる ■ ステークホルダーの特定 ● システムの利用者、システム仕様に詳しい人、決裁権がある人

Slide 34

Slide 34 text

34 EOL対応プロセスのステップ ● アップデート準備 ○ アップデート方法の調査 ■ インプレース、B/G、カナリー ■ ユーザー影響度やロールバックのしやすさを元に判断 ○ スケジュールの作成 ■ テストやQAのスケジュールを決定していく ■ アップデート実施日の決定 ■ ダウンタイムの調整、メンテナンス告知なども決める

Slide 35

Slide 35 text

35 EOL対応プロセスのステップ ● アップデート準備 ○ テスト ■ アップデートを実施した際に機能面で仕様を満たしているかを ■ 非機能面の確認も実施する。特にパフォーマンスが著しく劣化するケースもあるので前後で確認できるように性能テストを実施しておく ● パフォーマンスの指標は事前に決めておく、SLIがあればそちらを使用 ■ ありがちなのはアップデートしたらバックアップツールが動きませんやメトリクスが取れてませんケースがあるので正常に動作するかを確認する ■ アップデートしてうまく動かなかったを想定して切り戻し手順のテストも実施する

Slide 36

Slide 36 text

36 EOL対応プロセスのステップ ● アップデート準備 ○ 手順書の作成 ■ 自動化できる部分は事前にスクリプトを作っておく ■ 明確性や簡潔性を意識して書く ■ 対象読者の理解度を考慮

Slide 37

Slide 37 text

37 EOL対応プロセスのステップ ● アップデート実施 ○ ここまできたら手順をなぞるくらい ○ 手順自体も自動化が進んでいれば PRマージするだけで完了というケースも ○ 準備までで9割完了と行っても過言ではない (はず)

Slide 38

Slide 38 text

38 5. EOL対応をモチベーション⾼く進める⽅法

Slide 39

Slide 39 text

39 イントロダクション “ EOL対応楽しめてますか？”

Slide 40

Slide 40 text

40 Twitterのアンケート

Slide 41

Slide 41 text

41 EOL対応をモチベーション高く進める方法 ● 実際の理由を身近な人に聞いてみた結果 ○ 大変な割には地味で保守的な作業である ○ 新しいプロジェクトやイノベーションに比べて評価されにくい ○ EOL = ビジネス停止ではないので優先度が低くなりがちでリソースが足りない (予算、人員) ○ システムによっては調整する人が不明で技術的な大変さじゃなくコミュニケーションの大変さで疲弊してしまった

Slide 42

Slide 42 text

42 イントロダクション “ 楽しくやるには？”

Slide 43

Slide 43 text

43 イントロダクション “ ジョブクラフティング”

Slide 44

Slide 44 text

44 EOL対応をモチベーション高く進める方法 ● ジョブクラフティング ○ 仕事の中に自分をひと匙入れること ○ “やらされ感”のある仕事を“やりがいのあるもの”へと変容させる手法 ○ 仕事の意味や目的を再定義し、個人の強みや関心に合わせて仕事を自己調整

Slide 45

Slide 45 text

45 EOL対応をモチベーション高く進める方法 ● ジョブクラフティング ○ タスクのクラフティング ■ 具体的な業務の内容や方法を変えてみたり、工夫を加えること ○ 関係性のクラフティング ■ タスクを進める際の他者(上司、同僚、取引先)との関係性を増やしたり接点を増やしたり関係性を変えてみること ○ 認識のクラフティング ■ タスクの意味や目的の捉え方を変えてみようとすること

Slide 46

Slide 46 text

46 EOL対応をモチベーション高く進める方法 ● タスクのクラフティング ○ アップデートチェックツールや自動化スクリプトを自作して公開してみる ● 関係性のクラフティング ○ ステークホルダーとの関わりが少ないなら他チームの MTGに飛び入りで参加して何をやっているのかを把握したり接点を増やす ● 認識のクラフティング ○ CentOSのEOL対応をやるならば何が変わるかだけでなくなぜ変わるのかに着目してみたり、最新のLinux事情について学ぶ機会にする ○ その仕事が企業や部署のミッションに対してどう関連するのか考えてみる

Slide 47

Slide 47 text

47 EOL対応をモチベーション高く進める方法 ● モチベーション高く進めるには ○ ソフトウェアに関するアップデートを追っていく ■ 現在のバージョンでは実現できなかったことが最新バージョンを使うことで解消されることが多くある ● Terraform: import機能、テストができたり ● MySQL: バージョンアップによるパフォーマンス改善

Slide 48

Slide 48 text

48 6. ⼤変だった事例の紹介(時間あれば)

Slide 49

Slide 49 text

49 大変だった事例の紹介 ● CentOS 6からCentOS 8に乗り換えたら1年でEOL迎えることになった話 ● 一部の営業さんが使っているエンジニア0の謎のシステムのEOL対応をした話 ● セキュリティガバナンスが緩かった時代に作られたシステムのEOL対応をしようとしたら新設されたセキュリティチームからシステム自体がコンプライアンス違反でアップデートだけでは済まなかった話 ● OSアップデートしたら性能が1/5まで下がった話懇親会とかで聞いてもらったらいっぱい話します！！

Slide 50

Slide 50 text

50 7. まとめ

Slide 51

Slide 51 text

51 まとめ • EOL対応は準備が9割 • 地味な作業も主体的に捉え直すことで、やりがいのあるものに仕事を創り変えていく(ジョブクラフティング)ことでモチベーション⾼く取り組める • 最新は最⾼！！！！ • 来週メインDBのMySQL 8.0アップデートがあるので⾒守っててください

Slide 52

Slide 52 text

52 ご清聴ありがとうございました