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

Slide 1

Slide 1 text

モノリス改善史 ~運用改善とバージョンアップの軌跡~ レバテック開発部　金澤伸行

Slide 2

Slide 2 text

|　© Leverages inc. 2 ● 所属 ○ 2022年 9月レバテック開発部ビジネスサポートチーム  ○ 2023年 9月レバテック開発部レバテックSRE  ● 出身 ○ 千葉県千葉市  ● 趣味 ○ 温泉/サウナ  ○ 海外サッカー  ○ うまそうな個人店を巡ること  ● この頃 ○ マーベル作品にやっと手を付けた  ■ 公開順で見ています  ○ 引っ越しついでに家電を買い足したい  ■ ドラム式洗濯機、食洗機...etc  ■ おすすめの家電あったら教えてください  金澤伸行自己紹介

Slide 3

Slide 3 text

|　© Leverages inc. 3 長いシステムの歴史の中で育てられた ● 手動での複雑な運用作業 ● 把握しきれないインフラ構成 ● バージョンの古いレガシーなシステムこれらを改善するために ● 運用の機能化 ● IaC化 ● バージョンアップの実現 ● オブザーバビリティ/SLMへの挑戦を1年半で実現して学んだこと話したいこと

Slide 4

Slide 4 text

|　© Leverages inc. 4 遡ること1年半前エンジニア情報の統合依頼が来たぞ！！今日の分あと2件あるのに！！ 1時間かかる運用業務

Slide 5

Slide 5 text

|　© Leverages inc. 5 遡ること1年半前また新しいプロジェクトが始まるの！？まだHogeHogeプロジェクトも終わってないのに！！増えるプロジェクト

Slide 6

Slide 6 text

|　© Leverages inc. 6 遡ること1年半前運用多すぎて実装進まない関わるプロジェクトが多くてチームのことに時間を割けないメンテナンス？無理だねー優先度負けちゃうドメイン理解？インフラも管理したい？時間がある時ねできない理由は時間がない

Slide 7

Slide 7 text

|　© Leverages inc. 7 遡ること1年半前なにからやればいいんだもう何からしたらよいのかわからない

Slide 8

Slide 8 text

|　© Leverages inc. 8 遡ること1年半前誰も幸せじゃない・・・

Slide 9

Slide 9 text

|　© Leverages inc. 9 遡ること1年半前開発チーム ● 個人/チーム両面で成長に繋がらない運用業務 ● 依頼ありきの業務に終止してしまい受動的な働き方が主となってしまうシステムを使う人 ● システムのパフォーマンスが悪化しているが改善されない ○ 業務効率に影響 ● 要望した機能追加は実装されない ● 声すら上がらなくなる連携する他システムのチーム ● プロジェクトのスケジュールが調整ができない ● 待ちが発生する

Slide 10

Slide 10 text

|　© Leverages inc. 10 遡ること1年半前変わらなきゃ・・・

Slide 11

Slide 11 text

|　© Leverages inc. 11 遡ること1年半前複雑かつミスが許容されない運用業務を手動で対応 ● 非常に長いクエリテンプレートがたくさんあった ○ 例）エンジニア情報を統合するクエリテンプレート A/B/Cがある ■ どのクエリテンプレートを使うか確認するためのクエリテンプレート ■ データの統合先（残すデータ）を確認するためのクエリテンプレート ● 1件1時間以上かかる場合も ● 即対応を依頼されるケースもあり非常に負担となっていた計画を立てられない、やりたいことやるべきことが積まれていく ● プロジェクトのスケジュールは常に後ろ倒し ● 今日は作業できそう！ってときに限って差し込み対応 ● 割れ窓ややりたいことは増え続けて減らない

Slide 12

Slide 12 text

|　© Leverages inc. 12 これぞトイル（今思えば）トイルとは ● 手作業であること ● 繰り返されること ● 自動化出来ること ● 戦術的であること（問題が生じて対応すること） ● 長期的な価値を持たないこと何故トイルはだめなのか ● キャリアの停滞 ● 燃え尽き、不満 ● 生産性の低下間違いなくトイル

Slide 13

Slide 13 text

|　© Leverages inc. 13 遡ること1年半前今つらい思いをしてでも、時間を生み出すための取り組みをしよう

Slide 14

Slide 14 text

|　© Leverages inc. 14 運が良かったことチームメンバーが増えたタイミングだった ● メンバーが増えて新体制について話している中で運用機能化を進めることになった ● きっかけとしてちょうど良かった

Slide 15

Slide 15 text

|　© Leverages inc. 15 運用業務を機能化して、まず時間を作る 20%ルールの実践 ● 1人20％だとまとまった作業ができないので 3〜4人ユニット内全体で最低 20%の時間を確保 ● 基本一人は運用機能化専属とするとにかく未来の時間を作るために今の時間を使う ● 細かな依頼や割れ窓など、手を止められないプロジェクト以外対応停止 ● やらないという意思決定 ● 課題感はチーム全員が持てていたので意思決定はスムーズだった

Slide 16

Slide 16 text

|　© Leverages inc. 16 1Q使って死ぬ気で取り組むうおおおおお！！むずい！！複雑な運用を機能化するのは当たり前に辛い

Slide 17

Slide 17 text

|　© Leverages inc. 17 気をつけたこと最初から完璧を求めない ● 全ての運用の全てのパターンを網羅するのは現実的ではない ● 発生頻度の高い基本的なパターンから機能化し、拡張性を持たせる自動化を無理にしない ● フェーズを分けてまずは自分たちの時間を作ることを優先 ○ 依頼を受けてクエリで対応 ○ 依頼を受けてシステムで実行（ここを目指す） ○ 依頼主に実行権限を移譲 ○ 発生をトリガーに自動対応 ○ 発生させない（ゴール）

Slide 18

Slide 18 text

|　© Leverages inc. 18

Slide 19

Slide 19 text

|　© Leverages inc. 19 とんでもなく効率UPしたデータの統合 ● 1時間/1件→2分/1件機能で対応しきれないデータ ● 一部データの紐づけをクエリで修正して、統合機能で対応（後に機能追加） ● 15分程度で完結依頼者へ機能の提供 ● 一部運用業務は開発チームで対応不要に

Slide 20

Slide 20 text

|　© Leverages inc. 20 とんでもなく効率UPした 15分で7件も消化した！時間が増えた！積み上がっていた運用依頼がなくなってきたそ！シンプルに感動する。仕事が楽しくなる。

Slide 21

Slide 21 text

|　© Leverages inc. 21 最初からやればよかったのに？そんな事言わないで！やめる決断、変える決断はきっかけがないと難しい

Slide 22

Slide 22 text

|　© Leverages inc. 22 余裕が生まれる運用プロジェクト開発障害対応割れ窓/メンテナンス運用プロジェクト開発障害対応割れ窓/メンテナンス余裕が生まれる

Slide 23

Slide 23 text

|　© Leverages inc. 23 改善を進める Jenkins導入 ● サーバー内でcronで動いていたバッチを管理 ● 頻繁にサーバーにアクセスして実行するコマンドを管理 ○ ドキュメントとしての役割も果たすチューニングなどのパフォーマンス改善 ● プロジェクトや運用とは異なる技術的な問題解決に時間を費やせるようにアジャイル ● 差し込みの運用対応が入ると計画が崩れる状態ではなかなか実践できなかったデータ多すぎて一日で処理できていないバッチがありました

Slide 24

Slide 24 text

|　© Leverages inc. 24 改善を進めるプロジェクトに十分に人をアサインできるようになる ● 差し込みで時間を取られる機会も減り専念できる環境を整えることができた ● インボイス対応など規模の大きいものも他プロジェクトと平行して対応できたシステムを利用する人たちにヒアリングをする時間を設ける ● 実際の業務の中でどの様に使われているのかを知る ● 開発側で吸い上げられていない課題を把握する

Slide 25

Slide 25 text

|　© Leverages inc. 25 改善する効果を実感する日々

Slide 26

Slide 26 text

|　© Leverages inc. 26 改善することに前向きになる

Slide 27

Slide 27 text

|　© Leverages inc. 27 残された大きな課題インフラの整備 ● システムの初期構築を行ったメンバーはチームに存在しない ● EC2内部の各種設定ファイルやパッケージは一元管理されていない ○ 万が一全てのインスタンスが使用できなくなったら迷宮入り ● ドキュメントもない自動テストの導入 ● 動作確認は手動でチェックシートを用いて実施していた ● レビュー戻りで修正したらまたゼロから動作確認・・・バージョンアップ ● AmazonLinux1/PHP7系/Laravel5系 ● 長期間塩漬け状態 ● 技術的な難易度が高く、工数の兼ね合いもあり時間を使えていない ● バージョンを上げなくてもなんとかなってしまっている

Slide 28

Slide 28 text

時間はある！今なら出来る！

Slide 29

Slide 29 text

|　© Leverages inc. 29 まずはインフラから止まったら終わり。

Slide 30

Slide 30 text

|　© Leverages inc. 30 まずはインフラから IaC化しよか〜〜！ EmbeddedSREの活動の一環としてIaC化を進めることに

Slide 31

Slide 31 text

|　© Leverages inc. 31 今までだったら・・・人がいない！誰もアサインできません

Slide 32

Slide 32 text

|　© Leverages inc. 32 今は・・・大きいプロジェクトもあるけど、なんとかなりそう！

Slide 33

Slide 33 text

|　© Leverages inc. 33 IaC化専任のポジションを作って対応する ● 通常の開発業務と平行して行うには規模が大きすぎる ● そのためチームから専任の人員 1名確保して短期間で IaC化を推し進める ○ 運用のコストが減ったため、大きなプロジェクトが動いていたが人員の確保ができたある程度整ったらチームメンバーに展開する ● IaC化や構成図などを整備してインフラリソースの可視化をしたものをチームに展開 ● チームで運用できるようメンバーをサポートする

Slide 34

Slide 34 text

|　© Leverages inc. 34 IaC化インフラリソースの可視化 ● 今までは社内で全てを把握している人がいないくらいにブラックボックス ● そこから使用しているミドルウェアなどや AWSサービス等が一目瞭然になった管理コストの削減 ● 稼働するサーバーそれぞれで設定を変更していた ● ソースコード上で変更して一括反映 ● 不本意な環境差分を防げる ● 変更や追加をチームで独立して行えるように

Slide 35

Slide 35 text

|　© Leverages inc. 35 テストの課題今は全くテストコードはないんだ。全くゼロからの実装は少ないから既存の部分のテストを書かない意味あるテストにならないんだ。

Slide 36

Slide 36 text

時間はあっても過去の分までは・・・

Slide 37

Slide 37 text

|　© Leverages inc. 37 チームの外から助っ人を呼ぶテストいれるよ〜〜！

Slide 38

Slide 38 text

|　© Leverages inc. 38 テストを導入するチームの外から専任の人を入れる ● プロジェクトと並行して進めるには規模が大きい ● テストに知見のある人を入れることで土台を固める ● イネイブリングしながらテスト実装を浸透させるドメインに関わる部分はチームメンバーでサポート ● コードだけでは読み取れないことは協力しながら進めるイネイブリング ● 新規実装分についてはを実装時に追加できるよう展開する

Slide 39

Slide 39 text

Iac化/テスト導入後・・・

Slide 40

Slide 40 text

|　© Leverages inc. 40 状況を整理する運用コストを削減 ● 改善やプロジェクトに腰を据えて着手できるように ● 大きな課題には専任者を割り当てて一気に対応インフラ環境 ● IaC化を進めて全体像が把握できる状態になった ● 同じ環境をいつでも再現することが可能にテスト導入 ● 主要機能に関しては網羅的にテストが書けている状態に

Slide 41

Slide 41 text

Slide 42

Slide 42 text

|　© Leverages inc. 42 バージョンアップ変更内容他にも・・・ ● ApacheからNginxへ ● OpcacheやJitの導入 ● x86からARM（Graviton）へ旧環境新環境 PHP7系 PHP8系 Laravel5系 Laravel 10系 Node12系 Node20系 AmazonLinux1 AmazonLinux2023

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

|　© Leverages inc. 48 バージョンアップ大きな障害もなく約3ヶ月で5年の負債を返済！当たり前のように完了したけれど ● IaC化されてなかったら・・・ ● 運用業務がまだ残っていたら・・・ ● テストがなかったら・・・改善の進めかたは間違っていなかったかなと思えた

Slide 49

Slide 49 text

Slide 50

Slide 50 text

|　© Leverages inc. 50 現在オブザーバビリティの導入 ● バージョンアップする前は導入できず、メトリクスやログ収集までだった ● システムパフォーマンスの可視化をしてより安定した運用を目指す SLMの促進 ● SLI/SLOの設定を進めてユーザー目線でのシステムの状態を把握するチームでできていなかったことを当たり前に ● テスト実装 ● 定期メンテナンス ● インフラリソースの管理バージョン上げないとオブザーバビリティツールが動かない状態でした。

Slide 51

Slide 51 text

学び

Slide 52

Slide 52 text

|　© Leverages inc. 52 学びまずは時間を作る ● 時間がないと何も始まらない ● 特に意味を見いだせない作業に時間をかけていると生産性も落ちるその後見えるようにする ● 見えないものは改善できない大規模な改善は専任で一気に進めることも ● チームの外から専門性の高い人をいれることも効果的 ● やりっぱなしでなくイネイブリングをしてチームでできることを増やす成果を感じられるのは時間がかかる ● 実際に改善を進めているときは意味があるのか不安になる

Slide 53

Slide 53 text

最後に・・・