いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は2025.04.03（木）に開催した春のSREまつり〜大規模サービス "あるある" との戦い事例〜へ参加しましたのでアウトプットとしてイベントレポートを執筆しました。

初見の方でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。

誤字脱字、わかりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しているため誤字脱字があるかもしれません。

イベントページ

エウレカ様ページ

みてね様ページ

目次

イベント概要
大規模サービスにおけるカスケード障害について
『家族アルバムみてね』を支えるS3ライフサイクル戦略
ペアーズにおけるData Catalog導入の取り組み
データベースで見る『家族アルバムみてね』の変遷
トークセッション
まとめ

イベント概要

本イベントでは、大規模サービスを支えるSREのリアルな知見を共有するべく、エウレカ（ペアーズ）とMIXI（みてね）から計4名のSREがそれぞれの現場での課題と解決策を紹介します。
各トークでは、障害対応・データ管理・ストレージ最適化といったSREにとって "あるある" な戦い事例を、実際の取り組みをもとにお話します。さらに、登壇者全員によるパネルディスカッション＆Q&Aを通じて、それぞれを深堀りしていく予定です。
SREなら知っておきたい実践的な知見が詰まった内容になるかと思いますので、是非、ご参加ください。

大規模サービスにおけるカスケード障害について

登壇資料

参考サイト

自己紹介
- エウレカ所属のエンジニアの方
カスケード障害とは
- ポジティブフィードバックの結果として時間とともに拡大する障害
- ざっくり言えば、小さな種火が大炎上につながるイメージ
- 発生する条件としていくつかある
  - 高い相互依存性を持つサービス：依存関係があると連鎖する
  - リソース上限に近い：ひっ迫すると障害が発生する
  - マイクロサービス化していない：冗長化されていないため障害につながる
カスケード障害のパターン
- 依存先サービスの障害・不具合など
  - （個人的考察）DNSサーバ障害がイメージしやすいですね
- 意図しないフェールオーバー
  - トラフィック増加により意図しないタイミングでフェールオーバーが発生する
カスケード障害への対策
- 設計による対策
  - サーキットブレーカーパターン：障害が発生したところは切り離す
  - リトライ戦略なども対策の一つになる
    - （個人的考察）このあたりの話はシステム設計でもものすごく重視しますね
- 実運用時の対策
  - トラフィックシェービング：ひっ迫した帯域を削減する
    - （個人的考察）QoSを利用するイメージかしら
ベアーズのカスケード障害
- Elasticache for Redisの接続が問題だった
  - 読み取りは全ノード、書き込みはプライマリノードに実施
- ポップアップ側のアルゴリズムに問題があった
  - 大量の配信対象が特定のシャードに保存されていた
    - （個人的考察）Redis周りだとあるある話ですね
  - 結果として、シャードへのひっ迫が発生した
  - クライアントコネクション数の上限に到達しリトライが複数発生した
カスケード障害への対策
- リストではなくユーザー単位でキーを作成
- 設計段階でのDesign Docレビューを強化していった
- ちょっとした考慮不足が命取りになってしまう
  - データサイズが大きくなることで影響範囲が大きくなる
まとめ
- 小さな不具合が全体障害へつながる障害はカスケード障害
- 複数のコンポーネントが組み合わされたモノリスシステムでも起きる
- クラウドリソースのバースト可能はベストエフォート
  - （個人的考察）ベストエフォートに関してはおっしゃる通りですね

『家族アルバムみてね』を支えるS3ライフサイクル戦略

登壇資料

参考サイト

自己紹介
- MIXI所属のエンジニアの方
- 家族写真みてねプロダクトの開発担当の方
家族写真みてねとは
- 家族写真をアプリで管理するアプリ
- プリント商材・サブスクリプションなどで収益を得ている
- 直近ではGPSサービス**も
サービスに関する課題
- データ保存でS3を利用しているがデータが溜まってしまう
  - その結果として、コストが大幅にかかってしまうためコスト最適化が必要
課題に対する対策
- データ保護：S3バージョニング
  - ユーザの大切な写真・動画の削除はNG
  - バージョニングを設定することでデータ削除を防止できるが残り続ける
  - S3ライフサイクルを有効化して一定期間で旧データを削除する
- ストレージクラスの選定
  - 場面に応じたストレージクラスを選択する
  - 動画データのアクセスパターンを分析する
    - アップロード直後はアクセス頻度が高い：
      - S3標準
    - 一定期間経過するとアクセス頻度は下がるがリアルタイム性は少なくなる
      - Glacier Instance Retreval
        
        引き出しコストは高くなるが保管コストは安い
- 動画の場合
  - アプリ上での動画再生はHLSを用いている
  - UI/UXを考えた保存期間を考える必要がある
    - 保存期間が長い場合：ストレージコスト増加
    - 保存期間が短い場合：再生成で利用するインスタンスコスト増加
  - 利用状況をもとに最適な保存期間を決定した

ペアーズにおけるData Catalog導入の取り組み

登壇資料

参考サイト

自己紹介
- 2022年にエウレカに入社したSREエンジニアの方
- 趣味は麻雀の方
DataCatalogとは
- データ利用者が必要なデータを探し出せるサービス
  - データエンジニア以外でも開発者も利用する
導入に伴う課題
- データカバナンスに関する課題があった
  - データ管理をスプレッドシートで行っているため俗人化している
  - 各カラムの定義があいまいでどのようなデータが含まれているか不明
- データ管理としてDataCatalogを利用した
  - いきなり大規模で利用するわけではなくスモールスタートで
技術選定
- Atlanを利用した
  - SaaSツールのため自社でのインフラ管理不要
  - 各種言語のSDKを提供している
  - 豊富なデータソースコネクションを有している
- 各利用用途ごとにデータソースを分けているため連携している
実装してみた課題感
- DynamoDBテーブルのデータをカタログ化できなかった
  - dbtモデル化（=YAML変換）させることでいい感じでカタログ化に成功
活用事例
- DLPデータをDataCatalogでの管理に成功
  - データ分類のチェック体制を強化することができた
- 開発視点でもメリットがあった
  - 社内チャットボットとの連携ができるようになった
    - 結果として非エンジニアロールでもデータ管理をうまくできるようになった
今後の展望
- MySQLのクエリレビューでも利用できる可能性
- DataCatalogを活用してデータガバナンスを向上させられる

データベースで見る『家族アルバムみてね』の変遷

登壇資料

参考サイト

自己紹介
- 2022年にMIXIへ入社されたSREエンジニアの方
- 家族アルバムみてねに携わっている方
データベースにおけるAWSマネージドサービス活用
- データベース活用は基本しんどい
- 2500万人利用しているがサービスとしては成長途中
- クラウド・インフラ視点でもSREの人的・時間リソースの制約が
  - 解決策としてマネージドなデータベースサービスの利用
- みてね開発途中ではAuroraは登場していなかった（2014年登場のため）
  - Auroraリリース後、データベースを移行した
- その後、セッション上限の壁を破るためにRDS Proxyを導入
- 2022年にはマルチリージョン化を実装
  - ユーザに近いリージョンのレプリカからデータを読み取る
- マルチリージョン導入直後は読み取りのみレプリカを対応したが
  - 将来性を考えてGlobal Tablesを導入した
マネージドサービスによるメリット
- 新しい機能をいち早く試すことができる
  - 結果としてコスト最適化につながる
発生したトラブル
- DB負荷が発生したことによりサービス接続性が悪化した
  - 休日ピークタイムに近づくにつれてReaderインスタンスのCPU使用率が高騰
  - Readerインスタンスが再起動、Writerインスタンスになだれ込む
- 対策として、Readerインスタンスを複数台構成にした
- スロークエリ改善も行っていった
現在抱えている課題
- サイズ（レコード数）が大きすぎてマイグレーションできない
- 将来的にはAuroraの性能・スケール限界が発生する

トークセッション

大規模サービスの信頼性をどのように定義し計測しているか
- エウレカさん
  - SLA・SLOについて関係各所とコミュニケーションを図りながら決めている
  - 開発者側でもSLO対象のエンドポイント修正を行っている
    - 結果を週次のパフォーマンス会で報告して改善している
  - 大規模サービスの場合、実測と異なる場合もあるので注意したほうがいい
- みてねさん
  - 正直なところSLA・SLOをうまく設計できていない
  - 一部開発チームでは写真アップロード成功率をSLAとして決めている場合も
  - 毎日Grafanaのダッシュボードを観察しながら対策を検討している
サービスの成長に伴い開発チームがスケールしたことで発生した問題
- みてねさん
  - リリース時のCIが遅くなってしまった
    - 実質無限にEC2をスケールできるようなCIに変えていった
  - PRにタグをつけて特定環境へマージする仕様に変更
    - （個人的考察）開発者体験は大切ですよね
  - リリースフローとしてはローカル⇒DEV環境⇒Master環境⇒デプロイ
    - ステージング環境はQAチームによるチェック・大規模修正の場合利用
    - （個人的考察）やはりブランチ戦略は考えないといけないですよね
  - 開発環境に関してはK8Sで行っている
    - （個人的考察）やはり開発環境をK8S＋GitHubで管理がベターですよね
    - （個人的考察）コード署名まわりも気になりますね
- エウレカさん
  - 開発環境のコンフリクトが発生する可能性
    - 各々が変更した内容がステージング環境へ反映されてしまう
    - 結果として想定した挙動にならないことが発生する
  - 環境を分離することで一時的に解決したが、コンフリクトは発生している
さらなるサービス成長に伴い、予想される技術的課題
- エウレカさん
  - レコード制約問題、ボリューム問題は将来的に起きる可能性があると思う
  - データ基盤についても今後問題なっていく可能性がある
  - シェアード開発に関しても考える必要がある
- みてねさん
  - 国外対応を行おうとするとマルチリージョン対応が必要
    - リーダーインスタンスに関して増強する必要がある
  - サービス品質に関しても向上させる必要がある
コストを定期的に意識・管理・削減する仕組み
- みてねさん
  - 小さなコスト削減ポイントを見つけたらコスト削減を行っている
- エウレカさん
  - 週1回コスト確認会を行っている
  - ダッシュボードを見る習慣を行っている
  - プロダクトリリースチェックリストは設けているがうまくいかない
    - 開発者にコスト意識を持ってもらうように仕向けている
サービスならではの負荷特性
- エウレカさん
  - 突発的な動画配信増加によるスパイクが発生する
    - 自動的にスケーリングできるようにしている
  - お正月などの長期休み明けは普段よりアクセス増が増える
- みてねさん
  - 雨の日などはアクセスが増加している

まとめ

SREに関する知見獲得を目的に本イベントへ参加しましたが、SREエンジニアとしてどのように課題に対して取り組んでいく必要があるのかをキャッチアップできました。
（サービスによって負荷に関する特性の違いがあるんだなぁと再認識しました）

そのうえで、今回参加したイベントを通じて私なりにデータベース運用のインプット↔アウトプットを行っていきたいと考えています。

最後まで、記事をお読みいただきありがとうございます！！