「家族アルバム みてね」を支える SREのこれまでとこれから

ゆるSRE勉強会 #1 でお話させていただいた、みてねSREの伊東（@_nihi）の登壇資料です。
https://yuru-sre.connpass.com/event/292063/

Transcript

1. 「家族アルバム みてね」を支える SREのこれまでとこれから ゆるSRE勉強会 #1
2. MIXI, Inc. 自己紹介
 株式会社MIXI Vantageスタジオ 
 みてねプロダクト開発部 基盤開発グループ SREチーム 
 伊東 宏起
 
 https://hekki.info

3. MIXI, Inc. 家族アルバム みてねの紹介 写真プリント フォトブック スマホで撮影した子どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスで す。

4. MIXI, Inc. 家族アルバム みてねの紹介 利用者数1,800万人を突破（2023年5月時点） ※ iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計 7言語・175の国と地域でサービスを提供
5. MIXI, Inc. 本日お話する内容
 - みてねでのSREチームの立ち上げ 
 - 立ち上げ移行のこれまでの振り返り 
 - これからの展望
 - まとめ

6. MIXI, Inc. みてねでのSREチームの立ち上げ
 - サービス開始は2015年4月 
 - 当時インフラを専任で担当するメンバーはおらず、インフラ上の問題は開発者が都度対応
 - 次第にユーザー体験や開発者体験に悪影響が出始める 
 - そこでサービス開始から約3年後の2018年2月、SRE組織を立ち上げることになる 

7. MIXI, Inc. みてねでのSREチームの立ち上げ
 - サービス初期からの開発メンバー・別の部署のSREチーム・別の部署のアプリ開発者の3名でスタート 
 - 当初のSRE組織を立ち上げた目標 
 - ユーザーがより良いサービス体験を得られるようにする
 - 開発者が開発に集中し、ユーザーへの価値提供を最速・最大化するための下支えをする

8. MIXI, Inc. みてねSREチームのこれまで（チーム規模 3〜4名）
 - ユーザーと開発者の体験向上 
 - メディアのアップロード・ダウンロードの高速化
 - Terraformを導入し、IaCの考え方を取り入れる
 - ログ分析基盤の構築
 - インフラコストの削減 
 - S3のストレージクラスやライフサイクルルールの最適化
 - セキュリティ向上
 - AWSアカウントの分離やGuardDutyの活用
 - OS/ミドルウェア/フレームワーク等のアップデート
 - Grafanaの導入
 - オブザーバビリティの改善と同時に、平常時の様子が分かるようになった

9. MIXI, Inc. - 開発者が新機能開発に集中できるように、それ以外の課題をSREが巻き取るというポリシーで運用 
 - インフラコストの削減には継続してチャレンジ 
 - ユーザーへの動画配信にHLS(HTTP Live Streaming)を活用
 - 詳細は「みてねの動画再生にHLSを導入した話」をご覧ください
 - AWS OpsWorksからAmazon EKSへの移行 
 - 前述したTerraformの導入やAWSアカウントの分割もこの前準備
 - 詳細は「4年間のEKS移行の取り組みを振り返って」をご覧ください
 - オンコール当番制度の導入 
 - 夜間や休日など業務時間外もサービスの品質を低下させないために、オンコール当番制度を導入
 - 制度設計を丁寧にしないと破綻するので要注意
 - 詳細は「『家族アルバム みてね』を支えるオンコールエンジニア制度」をご覧ください
 みてねSREチームのこれまで（チーム規模 4〜5名）

10. MIXI, Inc. - サービスの拡大と共に組織も大きくなり、組織のスケーラビリティという課題に直面 
 - 「新規開発以外の課題をSREが巻き取る」というポリシーに限界が見え始める
 - そこで開発者自身で問題の発見・解決ができる環境をSREが提供するポリシーに変化
 - 海外ユーザーの体験向上 
 - サービスの海外展開に注力し始めた一方、それまでインフラは全て日本国内に構築
 - 海外ユーザーにも快適にサービスを利用していただくために、インフラをマルチリージョン化
 - 詳細は「みてね マルチリージョン」で検索
 - オブザーバビリティ改善 
 - 「開発者自身で問題の発見・解決ができる環境」を目標とした取り組み
 - Grafana Lokiを使ったリアルタイムなログ検索基盤の構築
 - APM(Application Performance Monitoring)の普及やトレーニング
 みてねSREチームのこれまで（チーム規模 5〜6名）

11. MIXI, Inc. - まだまだ課題は山積み 
 - SLI/SLOの運用
 - ユーザー数の増加に伴いアプリケーション開発の難易度も格段にアップ
 - 開発スピードの低下や、リリース後に問題が顕在化するといった課題が発生
 - さらなるオブザーバビリティ改善、大規模なデータ・アクセスを開発環境上で再現するといった、複数の施策で 対策予定
 - DBの負荷増大
 - コンテンツの大量生成・大量配信など、特定期間にDBへのクエリが集中
 - スケールアップにも限度があるので、マルチDBやシャーディングなど負荷分散にチャレンジ
 - 開発チームがスケールしても破綻しないSRE組織作り
 - 引き続き開発チームが自走できるための支援に注力
 これからの展望

12. MIXI, Inc. - サービスの規模・フェーズや目標に合わせてSREチームも柔軟に目標を変化させてきました 
 - はじめから完璧なSRE組織を作って運用するのではなく、スモールスタートで取り組むことが大切 
 - SREチーム発足から5年以上経過した今でも、完璧にGoogleが提唱するSREのプラクティスを実践できているとはいえ ません
 - SREのプラクティスを組織全体に浸透させていくことが大切 
 - 究極的にはSREチームが必要となくなる（＝開発チームが自走してSREのプラクティスを実践できるようになる）ことを 目指す
 - これからSREに挑戦する方々の参考になれば幸いです！ 
 まとめ

13. MIXI, Inc.