徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例 - SRE NEXT 2024

2024年8月3,4日に開催された SRE NEXT 2024 での発表資料です。
「徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例」
https://sre-next.dev/2024/schedule/#sp007
本発表では、数十のウェブサイトを限られた人数で構築・運用するための徹底した自動化とトイルの撲滅手法を紹介します。

1. IaCのモジュール化とテンプレート化: terraformのテンプレート化により、大量のインフラを効率的に構築・管理する手法を解説します。
2. モノレポによるCI/CDの効率化: terraformコードをモノレポで一元管理し、CI/CDリソースを最適化した方法を紹介します。
3. 脆弱性の継続的な予防・検知・対応: アップデートツールやクラウドサービスを駆使して、脆弱性検知と自動アップデートを実現した手法を説明します。
4. モニタリングとアラート、障害対応: 少人数運用に必要十分なモニタリングとアラート設計、障害例とその対応について紹介します。
5. 信頼性を担保する組織体制: 少人数での運用を支えるルールや体制、組織との連携について解説します。

これら発表を通じて、少人数での運用の効率化と信頼性向上をどのように実現したかを共有します。

1. ©MIXI 徹底的な⾃動化とトイルの撲滅で 実現する効率的なSREの実践例 SRE NEXT 2024 IN TOKYO 2024/08/04 株式会社MIXI 開発本部CTO室SREグループ 多⽻⽥俊
2. 2 ©MIXI ⾃⼰紹介 【名前】 多羽田 俊（たばた しゅん） 【所属】株式会社 MIXI 開発本部 CTO 室 SRE グループ 【来歴】 • 前職では主に Web アプリケーションのバックエンド開発を 中心に、フロントや iOS アプリの開発も経験 • 現在は主に会社の基盤システムの設計から開発・保守・運用 や、プロジェクトへの DevOps 支援などを行なっている • アプリの開発経験から、最近はアプリの CI/CD の導入支援 などを行なっている -好きなこと- 猫（2匹飼ってます）、音楽、 作曲、お酒 - X (旧：Twitter) - @bbq_all_stars
3. 3 ©MIXI • MIXI の開発本部 CTO 室 SRE グループの紹介 • 今回お話するシステムの概要 • 少⼈数での運⽤の基本⽅針 • 具体的な⽅法 ◦ 1. IaCのモジュール化とテンプレート化 ◦ 2. モノレポによるCI/CDの効率化 ◦ 3. 脆弱性の継続的な予防‧検知‧対応 ◦ 4. モニタリングとアラート、障害対応 ◦ 5. 信頼性を担保する組織体制 • まとめ ⽬次
4. ©MIXI MIXI の開発本部 CTO 室 SRE グループの紹介
5. 5 ©MIXI MIXI の開発本部 CTO 室 SRE グループ 特定のプロダクト・ サービスに所属するエンジニア 横断的に複数のサービス・ プロジェクトに関わるエンジニア SRE
6. 6 ©MIXI • ミッション ◦ 注⼒事業サービスにて開発‧運⽤のため の設計開発保守を遂⾏と新技術の検証‧ 研究 ◦ MIXI GROUP 全体で開発⽣産性の向上‧ コスト最適化のための取り組みを進める ◦ ⼈材の育成‧リスキリングを進めて課題 を解決していけるようにする • 業務内容 ◦ 注⼒事業の⽀援 ◦ 他事業を伸ばすための⽀援 ◦ 全社的な横軸での案件サポート 開発本部 CTO 室 SRE グループの紹介 注力事業の支援 ・サービスを支える基盤の 　構築や運用 ・パフォーマンス向上 ・負荷対策の検討/実施 他事業の成長支援 ・クローズしたサイトの 　メンテナンス ・eスポーツの円滑化/ 　安定化支援 ・コーポレートサイトの 　構築運用支援 ・技術教育のコンテンツ/ 　講師など 全社的な横軸での案件サポート ・全社横断での支援 ・社内ITと協力して最適なIT投資をする ・MIXI 社全社のツールの導入・推進
7. ©MIXI 今回お話するシステムの概要
8. 8 ©MIXI • 開発本部CTO室SREグループが社内に提供している CMS のウェブサイト基盤 • さまざまな公式サイト、コーポレートサイトを運⽤している • 社内のプロジェクト側より相談を受けて、デザイン本部と協⼒して構築‧運⽤している • サイト構成は主に 3 パターン ◦ CloudFront + ALB + EC2 (CMS) ◦ CloudFront + CMS の SaaS版 ◦ CloudFront + S3 • サイトによっては数千 rps 程度の リクエストがある環境 今回お話するシステムの概要 e.g. 提供しているシステムの一例
9. ©MIXI 少⼈数での運⽤の基本⽅針
10. 10 ©MIXI • ⾃動化とトイルの削減 ◦ 運⽤に⼈数を割けない代わりに徹底的に⾃動化 ▪ CI/CD ▪ Terraform コードの⾃動⽣成 ◦ 責任判断が伴う箇所のみ⼿動 ▪ レビュー ▪ 実⾏のトリガー ◦ 各種マネージドサービスを活⽤ • 共通化‧標準化 ◦ コードの共通化、モジュール化 ◦ CI/CD の集約 • システムに対しての割り切り ◦ SLO は設けずにベストエフォートによる対応 ◦ プロダクトの SLO に関わるサイトを作る場合は、プロジェクト側に運⽤を依頼 ◦ ⾃部署だけの運⽤をやめる 少⼈数での運⽤の基本⽅針
11. ©MIXI 具体的な⽅法
12. 12 ©MIXI 今⽇は主に 5 つの軸で具体的な取り組みをお話しします • 共通化‧標準化 ◦ 1. IaCのモジュール化とテンプレート化 • ⾃動化とトイルの削減 ◦ 2. モノレポによるCI/CDの効率化 ◦ 3. 脆弱性の継続的な予防‧検知‧対応 ◦ 4. モニタリングとアラート、障害対応 • システムに対しての割り切り ◦ 5. 信頼性を担保する組織体制 具体的な⽅法
13. 13 ©MIXI Terraform Module の利⽤ • 様々な要件に対応できるように、module 化して Terraform コードの再利⽤性を⾼めている • 基本的に全てのウェブサイトを module を組み合わせるだけで 作成できるようにしている • 今は 30 個ぐらい • 最近 HCP Terraform Private Registry の管理に移⾏中 1. IaCのモジュール化とテンプレート化
14. 14 ©MIXI tf_generator で Terraform コードを⾃動⽣成 • Terraform コードを⽣成する内製のツール • Go のテンプレートツールである gomplate で 作られている • 必要なパラメータを与えると GitHub Actions で実⾏され Terraform コードの⽣成と PR の ⾃動作成を⾏う • 以下のようなシステムの Terraform コードの テンプレートがある ◦ CloudFront + ALB + EC2 (CMS) ◦ CloudFront + CMS の SaaS版 ◦ CloudFront + S3 1. IaCのモジュール化とテンプレート化 • 全てのシステムに以下の機能が付属 ◦ ALB、EC2 の CloudWatch Metrics 収集 ◦ EC2 の CloudWatch Logs ◦ Synthetics Canaries による外形監視 ◦ CloudWatch Alarm + AWS SNS + PagerDuty による通知 ◦ Chatbot + Lambda による内製の CloudFront のキャッシュ削除ツール ◦ AWS Systems Manager Maintenance Window による⽇時バックアップ ◦ AWS Systems Manager Patch Manager によるパッチの⾃動適⽤ ◦ Certificate Manager or 外部 SSL 証明書 の利⽤ ◦ ステージング環境の構築 ◦ etc…
15. 15 ©MIXI モノレポによる運⽤ • モノレポで運⽤することで効率的に CI/CD をまわすようにしてい る • CI/CD で⾏っている処理 ◦ terraform plan / apply ◦ terraform fmt ◦ terraform validate ◦ tfupdate（後述） ◦ Lambda の Go バイナリのビルド • 50 前後の Terraform Workspace を管理 • 当初はモノレポ運⽤でいくつか問題があったが、現在は解消（後 述） 2. モノレポによるCI/CDの効率化
16. 16 ©MIXI モノレポ運⽤で発⽣した問題 • workspace が増えるに従って terraform plan / apply を実⾏する CI の実⾏時間が増⼤ • GitHub Actions で job matrix を使⽤して、並列で runner を実⾏することで対応 • 100並列とかで回しても 5 分ぐらいで plan / apply が完了するようになる • ref. GitHub Actions の matrix で並列にファイルを⽣成しつつ、⽣成した複数のファイルを次の job に渡す⽅法 2. モノレポによるCI/CDの効率化
17. 17 ©MIXI モノレポ運⽤で発⽣した問題 • 最近 SRE 以外のリポジトリで Terraform Module を再利⽤しようとした時に問題が発⽣ • module の管理に HCP Terraform の Registry を使おうとしたが、これらは tag や branch でバー ジョン管理をする前提になっている • 複数の module をモノレポでバージョン管理をする場合は、個別の tag や branch を作らなけれ ばならず取り回しが悪い（ec2-1.2.3、cloudfront-1.2.3 のような形） ◦ ここに関してはモノレポを諦めて module ごとにリポジトリを分けることで対応 2. モノレポによるCI/CDの効率化
18. 18 ©MIXI • 現状対応しているのは以下の部分 ◦ クラウド ▪ AWS Health Notification という内製のツールで AWS Personal Health Dashboard を監 視 ▪ セキュリティ室によるクラウドの包括的な監視 ◦ OS、ミドルウェア、アプリケーション ▪ AWS Systems Manager Patch Manager で対応 ◦ Lambdaのコード ▪ GitHub dependabot ◦ Terraform のコード ▪ tfupdate ◦ システム全体 ▪ セキュリティ室による脆弱性のチェック • 必要に応じて、AWS Systems Manager Run Command を利⽤して複数マシンに対して同時にコ マンドを実⾏ • バックアップ処理は AWS Systems Manager Maintenance Window で実⾏ 3. 脆弱性の継続的な予防‧検知‧対応
19. 19 ©MIXI AWS Health Notification • AWS Personal Health Dashboard を監視する内製のツール • Health Dashboard に通知が届いたら GitHub issue を⾃動で作成 3. 脆弱性の継続的な予防‧検知‧対応
20. 20 ©MIXI AWS Systems Manager Patch Manager • AWS から提供されるOS、ミドルウェア、アプリケーションのパッチを⾃動適⽤するサービス • Patch Baseline で定義されたパッチ適⽤ルールに基づいて適⽤する ◦ 本システムでは以下のような Patch Baseline を設定している（Amazon Linux 系の場合） ▪ SEVERITY が Critical や Important => 1 ⽇後に適⽤ ▪ それ以外 => 7 ⽇後に適⽤ • AWS Sysmtems Manager Maintenance Window と組み合わせることで、定期的にパッチを当て ることが可能 ◦ 本システムでは 1 ⽇に 1 回実⾏ 3. 脆弱性の継続的な予防‧検知‧対応
21. 21 ©MIXI tfupdate • Terraform のバージョンの⾃動更新ツール ◦ https://github.com/minamijoyo/tfupdate • terraform 本体や provider のバージョンを⾃動でアップデートしてくれる • .terraform.lock.hcl のファイルも⾃動更新してくれる • 本システムでは以下のような GitHub Actions を作成して定期的に実⾏している ◦ 1 ⽇に 1 回実⾏ ◦ アップデート後のバージョンで以下をチェック ▪ terraform validate で問題がないか確認 ▪ terraform plan で差分が出ないか確認 ◦ 問題があれば、アップデートしたバージョンのコードで PR を作成 ◦ 問題がなければ、main ブランチに⾃動でマージ 3. 脆弱性の継続的な予防‧検知‧対応
22. 22 ©MIXI モニタリング‧アラート • モニタリングは CloudWatch を使⽤ • ALB 、 EC2 、Lambda の基本メトリクスを収集 • 以下の項⽬を監視 ◦ ALB ▪ healthy count ▪ 5xx count ▪ EC2 のレスポンス時間 ◦ EC2 ▪ CPU使⽤率 ▪ メモリ使⽤率 ▪ ディスク使⽤率 4. モニタリングとアラート、障害対応
23. 23 ©MIXI モニタリング‧アラート • CloudWatch Logs で EC2 のログを収集 ◦ EC2 構築時に CloudWatch Agent をインストールし、CloudWatch Logs に送信するように設 定 ◦ アプリケーションログ、NGINX ログ、システムログを保存 • Synthetics Canaries で外形監視 ◦ トップページへのアクセス可否 ◦ トップページのスクリーンショットの撮影と保存 ◦ スクリーンショットは 1 ヶ⽉間保存 • AWS SNS + PagerDuty で通知 • これらのプロビジョニングは、全て tf_generator を使⽤して⽣成された Terraform コードで⾏わ れる 4. モニタリングとアラート、障害対応
24. 24 ©MIXI 障害対応 • 基本的にはベストエフォートで対応 • 3 年ほどの運⽤では、障害は CMS の利⽤に伴うものが多かった ◦ CMS のバグを踏んでスタックしたりとか ◦ CMS の操作で重い処理を実⾏してしまったとか ◦ テンプレートの作成を間違えて無限ループが発⽣してしまったりとか • 公式サイトという特性上、 CloudFront のキャッシュを⻑時間効かせることが可能で、発⽣した障 害がユーザーに影響することはほぼなかった 4. モニタリングとアラート、障害対応
25. 25 ©MIXI • SRE グループでの最低稼働⼈数は 2 ⼈ + reviewer 数名 • 他にも複数の横軸組織と協⼒している ◦ プロジェクト側 ◦ デザイン本部 ▪ CMS の設定、構築、管理 ◦ セキュリティ室 ▪ AWS の全般的な監視やシステム外部からの継続的な監視 ▪ ref. パブリッククラウドのセキュリティ監視【MIXI TECH CONFERENCE 2023】 - Speaker Deck • プロジェクトごとに Slack のチャンネルを個別に作成してやり取り 5. 信頼性を担保する組織体制
26. ©MIXI まとめ
27. 27 ©MIXI • Terraform Module や tf_generator を使⽤することで、IaCのモジュール化とテンプレート化を⾏ い、効率的にシステムを構築、運⽤できるようにしています • モノレポで Terraform コードを管理し、 CI/CD パイプラインを並列で実⾏することで、⼤量の Terraform Workspace に対して処理を実⾏するようにしています • AWS Health Notification や AWS Systems Manager の各サービス、tfupdate 、dependabot など のツールを駆使することで、脆弱性の検知とアップデートを⾃動化します • ALB、EC2 の基本メトリクスやログの収集と、Synthetics Canaries を使⽤した外形監視、AWS SNS + PagerDuty を組み合わせた監視体制を構築することで、必要最⼩限のモニタリングとア ラート体制を構築しています • SRE グループだけではなく、プロジェクト側やデザイン本部、セキュリティ室と体制を組んでシ ステムを運⽤することで、少⼈数での効率的な運⽤を実現します まとめ
28. ©MIXI 宣伝
29. 29 ©MIXI MIXI GROUPの事業領域 エモーションと コミュニケーションで 「心もつながる」場と機会を 創造し続けます。 MIXI GROUPは、 ただ「つながればいい」という効率的な機能の提供ではなく、 歓喜や興奮、温かな思い、幸せ、居心地の良さの共有を通じて、 その先に、もっと深くて濃く豊かな、心のつながりを生み出すような、 サービスの開発・提供を目指しています。 現在、スポーツ・ライフスタイル・デジタルエンターテインメント の3つの領域で事業を展開しており、 それぞれの主な事業内容は右の通りです。 また、近年の投資活動の拡大と重要性を勘案し、 FY2023からはスタートアップやファンド出資等の投資活動を事業化しました。 スポーツ事業 プロスポーツチーム運営および 公営競技ビジネスの推進 ライフスタイル事業 インターネットを活用し、 人々の生活に密着したサービスの提供 デジタルエンターテインメント事業 スマホゲームを中心としたゲームの提供 3つの領域で “「心もつながる」 場と機会” を創造する事業を推進
30. ©MIXI We are hiring!! 採用情報 https://mixigroup-recruit.mixi.co.jp/ MIXI　採用 ＼ 様々なポジションで積極採用中 ／