©MIXI ©MIXI 限られた⼈数で MIXI のあらゆる 公式サイト群を保守‧運⽤する ノウハウとその体制 2023/10/31 開発本部CTO室SREグループ 多⽻⽥俊 MIXI SRE秋祭り 〜 MIXIのもうひとつのSRE 〜

22 ©MIXI ⾃⼰紹介 【名前】 多羽田 俊（たばた しゅん） 【所属】株式会社 MIXI 開発本部 CTO 室 SRE グループ 【来歴】 • 前職では主に Web アプリケーションのバックエンド開発を中心 に、フロントや iOS アプリの開発も経験 • 現在は主に会社の基盤システムの設計から開発・保守・運用や、 プロジェクトへの DevOps 支援などを行なっている • アプリの開発経験から、最近はアプリの CI/CD の導入支援など を行なっている -好きなこと- 猫（2匹飼ってます）、音楽、 作曲、お酒 - X (旧：Twitter) - @bbq_all_stars

33 ©MIXI ⽬次 ● 開発本部 CTO 室 SRE グループの紹介 ● みなさん公式サイトの開発‧運⽤ってどうしてます？ ● MIXI の公式サイトの要件 ● 〜公式サイト3 分クッキング〜 ● 何をやっているのか？ ● 保守‧運⽤フェーズでやっていること ● まとめ

©MIXI 開発本部 CTO 室 SRE グループの紹介

55 ©MIXI 開発本部 CTO 室 SRE グループの紹介 特定のプロダクト・ サービスに所属するエンジニア 横断的に複数のサービス・ プロジェクトに関わるエンジニア SRE

6 ©MIXI 開発本部 CTO 室 SRE グループの紹介 ミッション ● MIXI Group における注⼒事業‧サービスの価値向上 ● MIXI Group のエンジニアの開発⼒‧⽣産性の最⼤化 ⽅針 ● 注⼒事業への機動的な配置 ● 領域の拡⼤ ● 内製化進めていく ● エンジニアの教育‧育成を積極的にしていく 業務内容 ● 注⼒事業(プロダクト)の⽀援(サポート) ● エンジニアのいない領域への⽀援(サポート) ● 全社的な横軸での案件サポート

7 ©MIXI 開発本部 CTO 室 SRE グループの紹介 ミッション ● MIXI Group における注⼒事業‧サービスの価値向上 ● MIXI Group のエンジニアの開発⼒‧⽣産性の最⼤化 ⽅針 ● 注⼒事業への機動的な配置 ● 領域の拡⼤ ● 内製化進めていく ● エンジニアの教育‧育成を積極的にしていく 業務内容 ● 注⼒事業(プロダクト)の⽀援(サポート) ● エンジニアのいない領域への⽀援(サポート) ● 全社的な横軸での案件サポート 今日はこの辺の話

©MIXI みなさん公式サイトの開発‧運⽤って どうしてます？

99 ©MIXI みなさん公式サイトの開発‧運⽤ってどうしてます？ ビジネス側 ● 常にエンジニア‧デザイナーの⼿を借りずに更新できるようにしてほしい ● （場合によっては）アプリのお知らせページに埋め込みで表⽰させたい エンジニア側 ● サービスの開発に集中したいので、なるべくなら低リソースで運⽤したい

10 10 ©MIXI 例えば MIXI の公式サイトは以下のようなものがあります。 ● https://event-info.monster-strike.com/10th-anniversary-party/ ● https://cubic-stars.com/ ● https://rinkai-pj.com/ ● https://ghost-scramble.com/ ● https://mixi-anime.com/ ● https://ms-srr.com/ ● https://ms-grb.com/ ● etc… ところで、みなさん公式サイトの開発‧運⽤ってどうしてます？

©MIXI いっぱい

©MIXI これらをほぼ1⼈で構築‧運⽤しています

©MIXI MIXI の場合

14 14 ©MIXI ● 社内にはデザイン本部があって、デザイナーを抱えている ○ 基本的にはデザイナーさんが CMS の設計‧構築を⾏なっている ○ たまに外注もある ● 歴史的に Movable Type の CMS をよく使っている ○ 静的 HTML を吐いてくれるので、サービス終了後も残したいなど、取り回しがし やすい ○ 元々 Perl の会社ですし ○ AWS の AMI が Marketplace にある ● イベント開催時等、数千 rps 程度のトラフィックがよくくる ● サクッと作りたい MIXI の場合

15 15 ©MIXI ＿⼈⼈⼈⼈⼈⼈⼈⼈⼈⼈＿ ＞ サクッと作りたい ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣ MIXI の場合

©MIXI やります

©MIXI MIXI の公式サイトの要件

18 18 ©MIXI ● CMS は Movable Type ● デザイナーさんがすぐに使える状態にする ● 数千 rps に耐えられるように ● 監視‧アラートはしたい ● バックアップも欲しい ● なるべく短時間で作りたい ● コストも抑えたい ● セキュリティもしっかり MIXI の公式サイトの要件

©MIXI 〜公式サイト 3 分クッキング〜

20 20 ©MIXI ⽤意するもの ● AWS ● Terraform ● tf_generator ● GitHub Actions 〜公式サイト 3 分クッキング〜 ⼿順 ● tf_generator で Terraform コードを⽣成 します ● GitHub Actions で terraform apply ● おいしくできました

©MIXI 何をやっているのか？

22 22 ©MIXI ● tf_generator による Terraform コード⽣成 ○ AWS のリソースの作成 ○ cloud-init の設定ファイルの⽣成 ○ Slack workflow の設定ファイルを⽣成 ● GitHub Actions で terraform apply 何をやっているのか？

23 23 ©MIXI ● tf_generator による Terraform コード⽣成 ○ AWS のリソースの作成 ○ EC2 プロビジョニング⽤の cloud-init の設定ファイルの⽣成 ○ キャッシュ削除ツールの Slack workflow の設定ファイルを⽣成 ● GitHub Actions で terraform apply 何をやっているのか？

24 24 ©MIXI ● 内製の Terraform コード⽣成システム ● GitHub Actions にパラメータを yaml で⾷わせると、⾃動で Terraform コードを⽣成 して PR を作成してくれる ○ 設定するパラメータは以下のようなもの ■ ⽣成する Terraform のテンプレートの種類 ■ プロジェクト名 ■ 環境名 ■ ドメイン ■ Route53 を利⽤するかどうか ■ PagerDuty のエンドポイント ■ etc… 何をやっているのか？： AWS のリソースの作成

25 25 ©MIXI 以下のようなリソースを⽣成します。 ● CloudFront ● ALB ● EC2 ● セキュリティグループ ● VPC ● 各種 IAM ● Elastic IP ● WAF ● ACM ● Route53 ● CDN キャッシュ削除⽤の Lambda ● バックアップ⽤の Systems Manager Maintenance Windows ● Chatbot 何をやっているのか？： AWS のリソースの作成 ● CloudWatchメトリクス ○ EC2 ○ ALB ● CloudWatch Synthetics Canary（外形監視） ● CloudWatch Alarm ○ EC2 のアラート ○ ALB のアラート ○ Lambda の成功可否アラート ○ AWS Systems Manager Maintenance Windows の成功可否アラート ● SNS ● PagerDuty の設定 ● etc…

26 26 ©MIXI 何をやっているのか？： AWS のリソースの作成

27 27 ©MIXI 以下のような想定で作っています。 ● 基本は CloudFront で CDN キャッシュを効かせる想定 ○ 記事の更新時は Slack 経由で CloudFront のキャッシュを削除する ● EC2 のセキュリティグループに SSH の⽳を開けない ○ サーバーへの接続は Session Manager 経由でアクセス ● AWS Systems Manager Maintenance Windows で DB の dump やファイルのバックアップを⾏う ● ソフトウェアの更新などがあれば、必要に応じて AWS Systems Manager Run Command を実⾏ して複数のインスタンスに対してまとめてコマンドを実⾏する ● NGINX や Movable Type のログはすべて CloudWatch Logs に⼊れる ● CloudWatch Synthetics Canaries を使⽤してウェブサイトの外形監視を⾏う ● CloudWatch のアラームは PagerDuty に投げる 何をやっているのか？： AWS のリソースの作成

28 28 ©MIXI EC2 のプロビジョニング⽤に cloud-init の設定ファイ ルを⽣成しています。 やっていることは以下の通りです。 ● SFTP ⽤のユーザーを作成 ● Movable Type の初期設定 ● NGINX の初期設定 ● Movable Type のディレクトリパーミッションの 設定 ● swap の設定 ⽣成した設定ファイルは Terraform で EC2 の user data に流し込んで EC2 の初期設定をしています。 何をやっているのか？： cloud-init の設定ファイルの⽣成

29 29 ©MIXI ● 運⽤者向けにCDN キャッシュ削除ツールというのを⽤意しています ● ChatOps で Slack から CloudFront のキャッシュを削除できるようになっています ● Slack から AWS Chatbot を介して Lambda を実⾏し、Lambda で CloudFront の invalidation を実⾏します 何をやっているのか？： Slack workflow の設定ファイルを⽣成

©MIXI これで Terraform コードを⽣成できました

©MIXI 次にこれを terraform apply します

32 32 ©MIXI ● tf_generator による Terraform コード⽣成 ○ AWS のリソースの作成 ○ cloud-init の設定ファイルの⽣成 ○ Slack workflow の設定ファイルを⽣成 ● GitHub Actions で terraform apply 何をやっているのか？（再掲）

33 33 ©MIXI ● GitHub Actions で⾃動で terraform plan / apply をしています ● 多い時に 60 workspace ぐらいを matrix を利⽤して並列で実⾏します ○ ref. https://zenn.dev/mixi/articles/3e9bd4afa34097 ● 他にも、terraform fmt を実⾏するものや、Terraform の lock ファイルを⽣成するも のもあるので、全部の公式サイトを更新しようとすると 80 ぐらい GitHub Actions が 回ります ● 遅くとも5分ぐらいで終わります 何をやっているのか？：GitHub Actions で terraform apply

©MIXI というわけでリリースできました 

©MIXI 保守‧運⽤フェーズでやっていること

36 36 ©MIXI ● セキュリティ室による脆弱性診断 ● Dependabot による脆弱性通知 ● secretlint によるシークレット情報の監 視 ● tfupdate による Terraform のアップ デート ● aws_health_notification による AWS か らのお知らせ通知 ● PagerDuty アラート対応 ● AWS Systems Manager Run Command を使⽤したアップデート ● AWS による更新対応 保守‧運⽤フェーズでやっていること

37 37 ©MIXI 開発本部セキュリティ室により、常時ウェブサイトに問 題がないかどうかチェックをしてもらっています。 ● 公式サイトの脆弱性チェック ● クラウドの設定の監視 詳細は MIXI TECH CONFERENCE の発表内容を参照 https://www.youtube.com/watch?v=wWfaHaqkcec 保守‧運⽤フェーズでやっていること：セキュリティ室による脆弱性監視

38 38 ©MIXI 保守‧運⽤フェーズでやっていること：Dependabot による脆弱性通知 ● GitHub による脆弱性検知システム ● ⾃動でアプリケーションのライブラリの脆弱性をチェックしてくれる ● CDN キャッシュ削除ツールや、tf_generator は Go で書かれているため、それの脆弱 性を確認するために導⼊している

39 39 ©MIXI 保守‧運⽤フェーズでやっていること：secretlint によるシークレット情報の監視 ● Node.js 製のシークレット情報監視ツール ● https://github.com/secretlint/secretlint ● git の commit hook や、 push をトリガーにした GitHub Actions に設定することで、 リポジトリに意図せぬシークレット情報が混⼊していないか監視する

40 40 ©MIXI 保守‧運⽤フェーズでやっていること：tfupdate による Terraform のアップデート ● Terraform の⾃動バージョンアップデートツール ● https://github.com/minamijoyo/tfupdate ● 毎⽇ 10:00 に GitHub Actions で⾃動実⾏している ○ Terraform のバージョンが更新されていたらPR を⾃動で作成

41 41 ©MIXI ● 内製の AWS 通知システム ● AWS の Personal Health Dashboard に通知がきたら、⾃動で GitHub に issue を作っ てくれる 保守‧運⽤フェーズでやっていること：aws_health_notification によるお知らせ

42 42 ©MIXI ● CloudWatch Alarm を PagerDuty に⾶ばして、問題を検知できるようにしています ● 主に以下の設定をしています ○ CloudWatch Integration の設定 ○ AWS Systems Manager Maintenance Windows のアラートは Custom Event Transformer を 使⽤ ■ AWS Systems Manager Maintenance Windows のアラートは CloudWatch を経由しな いので、CloudWatch の integration が使えない 保守‧運⽤フェーズでやっていること：PagerDuty アラート対応

43 43 ©MIXI ● AWS Systems Manager Run Command は、Systems Manager を導⼊した任意のインスタンスに 対して⾃動でコマンドを実⾏するもの ● これにより、全てのインスタンスに対してソフトウェアを最新にアップデートしたり、設定を変 更したりしています ● Session Manager で動くので、SSH の⽳を開けなくても使えます 保守‧運⽤フェーズでやっていること：Run Command を使⽤したアップデート

©MIXI これで1⼈で（？） 運⽤することができるようになりました

©MIXI まとめ

46 46 ©MIXI まとめ ● 内製ツールの tf_generator で Terraform コードを⽣成してサイトを構築しています ● GitHub Actionsで⾃動で並列に terraform apply しているので、ウェブサイトが⼤量 にあっても問題ありません ● リリース後は、セキュリティ室による診断や、Dependabot 、secretlint を使⽤してセ キュリティ対策を⾏なっています ● また、tfupdate による Terraform コードを⾃動でメンテしています ● 内製ツールの aws_health_notification や PagerDuty によりサーバーの問題を常に把 握できるようにしています ● 必要に応じて、AWS Systems Manager Run Command を使⽤してまとめて複数の サーバーに対してコマンドを実⾏しています

©MIXI