モノリス改善史~運用改善とバージョンアップの軌跡~

## 技術

SRE, Observability, Terraform, Ansible, 監視, SLI/SLO, イネイブリング

Transcript

1. モノリス改善史 ~運用改善とバージョンアップの軌跡~ レバテック開発部　金澤伸行
2. |　© Leverages inc. 2 • 所属 ◦ 2022年 9月 レバテック開発部 ビジネスサポートチーム
 ◦ 2023年 9月 レバテック開発部 レバテックSRE
 • 出身 ◦ 千葉県千葉市
 • 趣味 ◦ 温泉/サウナ
 ◦ 海外サッカー
 ◦ うまそうな個人店を巡ること
 • この頃 ◦ マーベル作品にやっと手を付けた
 ▪ 公開順で見ています
 ◦ 引っ越しついでに家電を買い足したい
 ▪ ドラム式洗濯機、食洗機...etc
 ▪ おすすめの家電あったら教えてください
 金澤 伸行 自己紹介
3. |　© Leverages inc. 3 長いシステムの歴史の中で育てられた • 手動での複雑な運用作業 • 把握しきれないインフラ構成 • バージョンの古いレガシーなシステム これらを改善するために • 運用の機能化 • IaC化 • バージョンアップの実現 • オブザーバビリティ/SLMへの挑戦 を1年半で実現して学んだこと 話したいこと
4. |　© Leverages inc. 4 遡ること1年半前 エンジニア情報の統合依頼が来たぞ！！ 今日の分あと2件あるのに！！ 1時間かかる運用業務
5. |　© Leverages inc. 5 遡ること1年半前 また新しいプロジェクトが始まるの！？ まだHogeHogeプロジェクトも終わってないのに！！ 増えるプロジェクト
6. |　© Leverages inc. 6 遡ること1年半前 運用多すぎて実装進まない 関わるプロジェクトが多くてチームのことに 時間を割けない メンテナンス？無理だねー優先度負けちゃう ドメイン理解？インフラも管理したい？ 時間がある時ね できない理由は時間がない
7. |　© Leverages inc. 7 遡ること1年半前 なにからやればいいんだ もう何からしたらよいのかわからない
8. |　© Leverages inc. 8 遡ること1年半前 誰も幸せじゃない・・・
9. |　© Leverages inc. 9 遡ること1年半前 開発チーム • 個人/チーム両面で成長に繋がらない運用業務 • 依頼ありきの業務に終止してしまい受動的な働き方が主となってしまう システムを使う人 • システムのパフォーマンスが悪化しているが改善されない ◦ 業務効率に影響 • 要望した機能追加は実装されない • 声すら上がらなくなる 連携する他システムのチーム • プロジェクトのスケジュールが調整ができない • 待ちが発生する
10. |　© Leverages inc. 10 遡ること1年半前 変わらなきゃ・・・
11. |　© Leverages inc. 11 遡ること1年半前 複雑かつミスが許容されない運用業務を手動で対応 • 非常に長いクエリテンプレートがたくさんあった ◦ 例）エンジニア情報を統合するクエリテンプレート A/B/Cがある ▪ どのクエリテンプレートを使うか確認するためのクエリテンプレート ▪ データの統合先（残すデータ）を確認するためのクエリテンプレート • 1件1時間以上かかる場合も • 即対応を依頼されるケースもあり非常に負担となっていた 計画を立てられない、やりたいことやるべきことが積まれていく • プロジェクトのスケジュールは常に後ろ倒し • 今日は作業できそう！ってときに限って差し込み対応 • 割れ窓ややりたいことは増え続けて減らない
12. |　© Leverages inc. 12 これぞトイル（今思えば） トイルとは • 手作業であること • 繰り返されること • 自動化出来ること • 戦術的であること（問題が生じて対応すること） • 長期的な価値を持たないこと 何故トイルはだめなのか • キャリアの停滞 • 燃え尽き、不満 • 生産性の低下 間違いなくトイル
13. |　© Leverages inc. 13 遡ること1年半前 今つらい思いをしてでも、 時間を生み出すための取り組みをしよう
14. |　© Leverages inc. 14 運が良かったこと チームメンバーが増えたタイミングだった • メンバーが増えて新体制について話している中で運用機能化を進めることになった • きっかけとしてちょうど良かった
15. |　© Leverages inc. 15 運用業務を機能化して、まず時間を作る 20%ルールの実践 • 1人20％だとまとまった作業ができないので 3〜4人ユニット内全体で最低 20%の時間を確保 • 基本一人は運用機能化専属とする とにかく未来の時間を作るために今の時間を使う • 細かな依頼や割れ窓など、手を止められないプロジェクト以外対応停止 • やらないという意思決定 • 課題感はチーム全員が持てていたので意思決定はスムーズだった
16. |　© Leverages inc. 16 1Q使って死ぬ気で取り組む うおおおおお！！ むずい！！ 複雑な運用を機能化するのは当たり前に辛い
17. |　© Leverages inc. 17 気をつけたこと 最初から完璧を求めない • 全ての運用の全てのパターンを網羅するのは現実的ではない • 発生頻度の高い基本的なパターンから機能化し、拡張性を持たせる 自動化を無理にしない • フェーズを分けてまずは自分たちの時間を作ることを優先 ◦ 依頼を受けてクエリで対応 ◦ 依頼を受けてシステムで実行（ ここを目指す） ◦ 依頼主に実行権限を移譲 ◦ 発生をトリガーに自動対応 ◦ 発生させない（ゴール）
18. |　© Leverages inc. 18
19. |　© Leverages inc. 19 とんでもなく効率UPした データの統合 • 1時間/1件→2分/1件 機能で対応しきれないデータ • 一部データの紐づけをクエリで修正して、統合機能で対応（後に機能追加） • 15分程度で完結 依頼者へ機能の提供 • 一部運用業務は開発チームで対応不要に
20. |　© Leverages inc. 20 とんでもなく効率UPした 15分で7件も消化した！ 時間が増えた！ 積み上がっていた運用依頼が なくなってきたそ！ シンプルに感動する。仕事が楽しくなる。
21. |　© Leverages inc. 21 最初からやればよかったのに？ そんな事言わないで！ やめる決断、変える決断はきっかけがないと難しい
22. |　© Leverages inc. 22 余裕が生まれる 運用 プロジェクト開発 障害対応 割れ窓/メンテナンス 運用 プロジェクト開発 障害対応 割れ窓/メンテナンス 余裕が生まれる
23. |　© Leverages inc. 23 改善を進める Jenkins導入 • サーバー内でcronで動いていたバッチを管理 • 頻繁にサーバーにアクセスして実行するコマンドを管理 ◦ ドキュメントとしての役割も果たす チューニングなどのパフォーマンス改善 • プロジェクトや運用とは異なる技術的な問題解決に時間を費やせるように アジャイル • 差し込みの運用対応が入ると計画が崩れる状態ではなかなか実践できなかった データ多すぎて一日で処理で きていないバッチがありました
24. |　© Leverages inc. 24 改善を進める プロジェクトに十分に人をアサインできるようになる • 差し込みで時間を取られる機会も減り専念できる環境を整えることができた • インボイス対応など規模の大きいものも他プロジェクトと平行して対応できた システムを利用する人たちにヒアリングをする時間を設ける • 実際の業務の中でどの様に使われているのかを知る • 開発側で吸い上げられていない課題を把握する
25. |　© Leverages inc. 25 改善する効果を実感する日々
26. |　© Leverages inc. 26 改善することに前向きになる
27. |　© Leverages inc. 27 残された大きな課題 インフラの整備 • システムの初期構築を行ったメンバーはチームに存在しない • EC2内部の各種設定ファイルやパッケージは一元管理されていない ◦ 万が一全てのインスタンスが使用できなくなったら迷宮入り • ドキュメントもない 自動テストの導入 • 動作確認は手動でチェックシートを用いて実施していた • レビュー戻りで修正したらまたゼロから動作確認・・・ バージョンアップ • AmazonLinux1/PHP7系/Laravel5系 • 長期間塩漬け状態 • 技術的な難易度が高く、工数の兼ね合いもあり時間を使えていない • バージョンを上げなくてもなんとかなってしまっている
28. 時間はある！今なら出来る！
29. |　© Leverages inc. 29 まずはインフラから 止まったら終わり。
30. |　© Leverages inc. 30 まずはインフラから IaC化しよか〜〜！ EmbeddedSREの活動の一環としてIaC化を進めることに
31. |　© Leverages inc. 31 今までだったら・・・ 人がいない！誰もアサインできません
32. |　© Leverages inc. 32 今は・・・ 大きいプロジェクトもあるけど、なんとかなり そう！
33. |　© Leverages inc. 33 IaC化 専任のポジションを作って対応する • 通常の開発業務と平行して行うには規模が大きすぎる • そのためチームから専任の人員 1名確保して短期間で IaC化を推し進める ◦ 運用のコストが減ったため、大きなプロジェクトが動いていたが人員の確保ができた ある程度整ったらチームメンバーに展開する • IaC化や構成図などを整備してインフラリソースの可視化をしたものをチームに展開 • チームで運用できるようメンバーをサポートする
34. |　© Leverages inc. 34 IaC化 インフラリソースの可視化 • 今までは社内で全てを把握している人がいないくらいにブラックボックス • そこから使用しているミドルウェアなどや AWSサービス等が一目瞭然になった 管理コストの削減 • 稼働するサーバーそれぞれで設定を変更していた • ソースコード上で変更して一括反映 • 不本意な環境差分を防げる • 変更や追加をチームで独立して行えるように
35. |　© Leverages inc. 35 テストの課題 今は全くテストコードはないんだ。 全くゼロからの実装は少ないから既 存の部分のテストを書かない意味あ るテストにならないんだ。
36. 時間はあっても過去の分までは・・・
37. |　© Leverages inc. 37 チームの外から助っ人を呼ぶ テストいれるよ〜〜！
38. |　© Leverages inc. 38 テストを導入する チームの外から専任の人を入れる • プロジェクトと並行して進めるには規模が大きい • テストに知見のある人を入れることで土台を固める • イネイブリングしながらテスト実装を浸透させる ドメインに関わる部分はチームメンバーでサポート • コードだけでは読み取れないことは協力しながら進める イネイブリング • 新規実装分についてはを実装時に追加できるよう展開する
39. Iac化/テスト導入後・・・
40. |　© Leverages inc. 40 状況を整理する 運用コストを削減 • 改善やプロジェクトに腰を据えて着手できるように • 大きな課題には専任者を割り当てて一気に対応 インフラ環境 • IaC化を進めて全体像が把握できる状態になった • 同じ環境をいつでも再現することが可能に テスト導入 • 主要機能に関しては網羅的にテストが書けている状態に
41. |　© Leverages inc. 41 ついにバージョンアップへ・・・ バージョンアップするよ〜〜！ 準備は整った
42. |　© Leverages inc. 42 バージョンアップ 変更内容 他にも・・・ • ApacheからNginxへ • OpcacheやJitの導入 • x86からARM（Graviton）へ 旧環境 新環境 PHP7系 PHP8系 Laravel5系 Laravel 10系 Node12系 Node20系 AmazonLinux1 AmazonLinux2023
43. |　© Leverages inc. 43 バージョンアップに専念できる環境
44. |　© Leverages inc. 44 インフラ環境、すぐ作れる
45. |　© Leverages inc. 45 ミドルウェアの設定まとまってる
46. |　© Leverages inc. 46 テストのおかげで不必要に動作確認しなくていい
47. |　© Leverages inc. 47 バージョンアップ IaC化しててよかった！ 自動テストありがたい！ 今までの改善の集大成
48. |　© Leverages inc. 48 バージョンアップ 大きな障害もなく約3ヶ月で5年の負債を返済！ 当たり前のように完了したけれど • IaC化されてなかったら・・・ • 運用業務がまだ残っていたら・・・ • テストがなかったら・・・ 改善の進めかたは間違っていなかったかなと思えた
49. |　© Leverages inc. 49 そして・・・
50. |　© Leverages inc. 50 現在 オブザーバビリティの導入 • バージョンアップする前は導入できず、メトリクスやログ収集までだった • システムパフォーマンスの可視化をしてより安定した運用を目指す SLMの促進 • SLI/SLOの設定を進めてユーザー目線でのシステムの状態を把握する チームでできていなかったことを当たり前に • テスト実装 • 定期メンテナンス • インフラリソースの管理 バージョン上げないとオブザー バビリティツールが動かない状 態でした。
51. 学び
52. |　© Leverages inc. 52 学び まずは時間を作る • 時間がないと何も始まらない • 特に意味を見いだせない作業に時間をかけていると生産性も落ちる その後見えるようにする • 見えないものは改善できない 大規模な改善は専任で一気に進めることも • チームの外から専門性の高い人をいれることも効果的 • やりっぱなしでなくイネイブリングをしてチームでできることを増やす 成果を感じられるのは時間がかかる • 実際に改善を進めているときは意味があるのか不安になる
53. 最後に・・・
54. |　© Leverages inc. 54 今までの話の内容 みんなやってるよ 当たり前のことだと思うかもしれません
55. |　© Leverages inc. 55 長い間放置されると当たり前の状態に戻すのにとてつもない労力がかかります
56. |　© Leverages inc. 56 私がいたチームでは、当たり前を実現するためにみんなで大変な思いをしました
57. |　© Leverages inc. 57 今までの話の内容 新しいシステムなら負債はなるべく作らないように 負債を解消するために頑張っている人がいたら、チーム問わず支え合い 良い環境にしていきましょう 頑張ろ