Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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… ところで、みなさん公式サイトの開発‧運⽤ってどうしてます?

Slide 11

Slide 11 text

©MIXI いっぱい

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

©MIXI MIXI の場合

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

15 15 ©MIXI _⼈⼈⼈⼈⼈⼈⼈⼈⼈⼈_ > サクッと作りたい <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄ MIXI の場合

Slide 16

Slide 16 text

©MIXI やります

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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…

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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 のリソースの作成

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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 アラート対応

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

©MIXI これで1⼈で(?) 運⽤することができるようになりました

Slide 45

Slide 45 text

©MIXI まとめ

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

©MIXI