🔧
MIXI × ココナラのSRE改革大作戦 〜改善のその先へ〜 レポート
複数サービスを運営するうえで、信頼性と運用効率の両立はSREにとって永遠のテーマです。2025年4月30日に開催された「MIXI × ココナラのSRE改革大作戦 〜改善のその先へ〜」では、両社のSREチームがいかに改善を重ね、現場で得られた学びをどう活かしているかが赤裸々に共有されました。 本レポートでは、ココナラとミクシーそれぞれの事例、さらにはQ&Aの内容を通じて、SREが直面する課題とその打開策、そして「改善のその先」にある世界を探ります。
ココナラ (1) 〜 一番気が重いと言われたポストモーテム委員会の改革
登壇者：吉川 拓見 さん
ポストモーテムへの不満
ココナラでは、5年ほど前から「ポストモーテム委員会」を運用していましたが、一部のエンジニアから「もっとも気が重いミーティング」と言われてしまいます。
理由1： ドキュメントの精度が高く求められ、作成に大きな工数がかかる
理由2： 雰囲気が暗く、再発防止策を“叩かれる”ような会になってしまいがち
結果として、障害が起きたチームが「叩かれに行く場」となり、運用参加者も発言しづらい悪循環が発生していました。
改革のポイント
ドキュメントのフォーマット刷新
「再発防止策」→「アクションアイテム」に名称変更し、ポジティブに捉え直す
「学び」セクションを設け、うまくいった事や発見をポジティブに共有できる場とした
ミーティング進行の柔軟化
再発防止策は“叩き台”であり、実際のミーティングではブレスト形式に。
「仕方ない」や「よく見つけた」を認め合うことで、ネガティブイメージを払拭
効果と今後
空気が明らかに明るくなり、参加者の発言数が増加
ポストモーテムが「障害報告」でなく「学びの場」になり、自発的に意見が出るように
今後は、技術的対処が難しい課題（例：プロダクトサイドとの調整）にも踏み込み、さらに品質向上を図る予定
ココナラ (2) 〜 GraphQLを活用したリアーキテクチャに対応するSLI/Oの再設計
登壇者：Kou さん
既存の監視基盤とGraphQLのアンマッチ
ココナラでは、HTTPベースのAPIに対してリクエスト成功率をSLIとし、Prometheus + Grafanaで可視化していました。ところが新たにフロントエンド-バックエンド間でGraphQLを導入したところ、
全リクエストが同じエンドポイント（POST /graphql）になり、ステータスコードも200に固定
従来のHTTPメソッドやパスを前提とするSLI/Oでは区別がつかない
解決策
GraphQL層でレスポンスを解析し、GraphQLの“クエリ名”やエラー状況をログへ出力
既存のログ収集＆エクスポーターに、GraphQL対応を加えることで計測基盤を拡張
これにより「クエリごとの成功率／失敗率」が可視化され、複数マイクロサービスへ展開しやすい
今後の課題
GraphQLによりマイクロサービス化が進むと、サービス単位でSLI/Oを定義し直す必要がある
SREチームだけで全サービスを担うのは困難。マイクロサービスごとにSRE文化を浸透させるエネイブリングが重要に
そのためのチーム増強やエラーバジェットなどの運用を整備していきたい
MIXI (1) 〜 突然のメモリ使用率上昇へ対応！k8sカスタムコントローラー開発事例
登壇者：井上 翔太 さん
突然のメモリ使用率上昇
MIXIのあるプロダクトで、GraphQLの修正が原因でAPIサーバーのメモリ使用量が急上昇。HPAで水平方向にスケールさせても、メモリが膨張しオートスケールが激しく上下動を繰り返す状態に陥った。 急ぎ対処の必要があり、「クーバネイティス上でメモリ使用率がしきい値を超えたポッドを自動的に終了させる」カスタムコントローラーを自作することに。
k8sカスタムコントローラーの実装
参考にしたOSS : Zapier製の “preoom-killer-controller”
実現したい要件 : パーセンテージ指定のメモリ使用率でポッドをイビクトする
実装概要 : 5分ごとに対象ポッドを確認し、指定のメモリ使用率を超えていたら終了要請(イビクト)を送る
自作により、クバネイティスの内部処理理解が進み、またGo言語ファイル数百行程度で簡潔に書けたというメリットがあった。
MIXI (2) 〜 生成AIとSERで『今』できること
登壇者：本間 匡晃 さん
ブームへの向き合い方
生成系AIのアップデートは極めて早く、多種多様な新機能が日々登場
その一方で、「SREプラクティス×AI」の成功事例は少なく、不安も大きい
過去の技術ブーム（例：フロントエンドフレームワークの群雄割拠）と同様、「今リアルタイムでキャッチアップし続ける意義は大きい」と強調
現在の取り組みと可能性
社内に「AI議論用チャンネル」を用意し、話題を共有
ミーティングや勉強会で自由に発表し、ハンズオン的に試す枠を用意
短期的には、業務効率化のトイレ削減（例：CI/CDの自動レビュー、エラーメッセージ解析、運用ドキュメント作成支援）が有力
中長期的には、エラーバジェット運用やインシデント対応など、SRE本来の分野でも大きなインパクトが期待できる
Q&Aダイジェスト
セッション後のパネルディスカッションでは、参加者から多数の質問が寄せられました。その中から一部を紹介します。
Q1. 「ポストモーテムの場を自由にするには？」
吉川さん：
「学び」セクションで成功体験や“よく見つけた”を共有するようにした。ブレスト方式に切り替え、司会が一人ひとりに声をかけるなど工夫すると、次第に空気が明るくなり、発言も増えた。
Q2. 「レスポンスタイム監視はしてないの？」
Kouさん：
「ココナラではPrometheusとGrafanaでリクエストの成功率・レスポンスタイム両方をトラッキングしています。ステータスコード以外にも、パスごとの分布を把握し、遅いエンドポイントを潰すといった運用を進めている。」 本間さん： 「ミテネでも似た仕組みでアラートや朝の定例確認をしているが、アラート設定が難しく、いろいろ試行錯誤しています。」
Q3. 「SREとAI、やっぱり興味あるけど…」
本間さん：
「まだ事例が少ない。が、過去の技術ブーム同様、キャッチアップしていると大きな差がつく可能性は高い。“とりあえずトイレ削減”のような業務効率化から始めるとよいのでは。」
全体を踏まえた感想 〜 改善を超えたその先のSRE
本イベントを通じ、「単なる改善の集合体で終わらず、どう学習サイクルを回し、組織としての成長に結びつけるか」が大きなテーマであると感じました。 ポストモーテム1つとっても、単なる障害報告の場ではなく学びの場へと変容させることが、チームの空気を一変させるきっかけになる。そして技術的なSREプラクティス（SLI/SLOなど）をどう運用レベルに落とし込むかにおいても、マイクロサービス化やGraphQLなど新しい技術との橋渡しが不可欠です。 さらに今後、AIはSREのトイレ削減やインシデント対応を加速する可能性を秘めています。あまりにも速い技術進化に圧倒されがちですが、今できることを試し、リアルタイムでブームに乗りながら自分たちの文脈を蓄積していく姿勢こそ「改善のその先」に続く道筋ではないでしょうか。
多様な現場の事例からうかがえるのは、SREとは結局“人がどう学び合うか”を前面に据えた取り組みだということ。ネガティブな障害対応でも、ポジティブな学びに転じる心構えや仕組みづくりを行えば、やがて「改善」の先にある新たな価値を切り開けるはずです。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...