🏗️
深堀り！現場のSRE 〜いろんなアーキテクチャ編〜 イベントレポート
Site Reliability Engineering (SRE)——その言葉が示す領域は、あまりにも広く、そして深い。サービスの数だけアーキテクチャがあり、組織の数だけ文化がある。教科書通りの「正解」など、どこにも存在しない。では、現場のSREたちは、自らが向き合うシステムとビジネスの固有の課題に対し、どのような「最適解」を導き出しているのでしょうか。
2025年7月23日、Repro、SODA、そしてMIXI（家族アルバム みてね）という、全く異なるドメインで戦う3社のSREが集結し、自社のアーキテクチャの裏側を語るイベントが開催されました。
BtoCのマーケティングプラットフォーム、CtoCのファッションマーケットプレイス、そして世界2500万人が利用する家族向け写真共有サービス。それぞれの現場で磨き上げられた「秘伝のタレ」から見えてきたのは、SREが単なるインフラ運用に留まらない、ビジネスと組織に深く根差した、創造的な営みであるという事実でした。
『Railsの限界を超えろ！「家族アルバム みてね」の画像・動画の 大規模アップロードを支えるアーキテクチャ』
株式会社MIXI（家族アルバム みてね） / ojima_h氏
最初のセッションは、サービス開始から10年、全世界で2500万人が利用する「みてね」が、その膨大な画像・動画データをいかにして捌いてきたかという、壮大なアーキテクチャ変遷の物語でした。SREの小島氏が語ったのは、サービスの成長と共に訪れる課題と、その時々のトレードオフの中で下されてきた意思決定のリアルです。
第一の壁：海外展開と、Railsからの解放
リリース当初、みてねのアーキテクチャは非常にシンプルでした。クライアントからアップロードされたメディアファイルを、一度Railsサーバーで受け止め、S3に保存する。しかし、2017年の海外展開を機に、この構成は限界を迎えます。海外から日本のサーバーへの大容量アップロードは、あまりにも不安定で時間がかかりすぎたのです。
「解決策は、AWSのポテンシャルを最大限に活用することでした。クライアントから直接S3にアップロードさせることで、地理的な最適化を実現したのです」 —— ojima_h氏
RailsからS3の署名付きURLを発行し、クライアントは最寄りのAWSエンドポイントを経由して直接S3にアップロード。完了通知を受けたLambdaがサムネイル生成などの後続処理を行う。このアーキテクチャ変更により、みてねはグローバルなスケーラビリティを手に入れました。しかし、その代償として**「複雑性」**という新たな課題を抱えることになります。開発環境の構築は困難になり、運用難易度も上がりました。
第二の壁：4年間放置された「野良Lambda」と、原点回帰
S3への直接アップロード方式は、4年もの間、安定して稼働し続けました。しかし、安定は時として「停滞」を生みます。メインのRailsアプリケーションから分離されたLambda関数は、開発のサイクルから取り残され、気づけばランタイムのEOL（サポート終了）が目前に迫っていました。
「コア機能であるにも関わらず、誰も手を入れられない『聖域』になってしまっていた。この課題を解決するため、私たちはLambdaを廃止し、再び処理をRailsに統合するという決断をしました」
S3からのイベント通知をSQSで受け、Railsアプリケーションに組み込まれたジョブワーカ（Shoryuken）が非同期で処理を行う。この「原点回帰」とも言える構成変更により、アップロード処理は再びRailsの統一された開発・運用フローの管理下に戻りました。サーバーレスのメリットを一部手放すことにはなりましたが、**「開発体験」と「保守性」**という、長期的な信頼性を担保するための重要な価値を取り戻したのです。
このセッションが示したのは、SREの仕事が、常に最新の技術を追い求めることだけではないという事実です。サービスの歴史、組織のスキルセット、そして事業のフェーズ。それら全ての文脈を読み解き、時には「退化」に見える選択をすることも厭わない。その柔軟な思考こそが、10年続くサービスを支えるSREの神髄なのかもしれません。
『GitHub Self-hostedに移行しました。CIが最大55%速くになり、コスト9割ダウン！』
株式会社SODA / DANG MINH DUC氏
次に登壇したSODAのDUC氏が投げかけたのは、多くの開発組織が密かに頭を悩ませているであろう、**「CI/CDのコスト」**という、極めて現実的な課題でした。
「ある月の請求を確認した時、私たちは驚きました。GitHub Actionsの費用が、本番環境のFargateのインフラ費用を超えていたのです。ピーク時には月額2万ドルに達することもありました」 —— DANG MINH DUC氏
月間600万人が利用する「スニーカーダンク」を支えるSODAでは、CI/CDの実行回数が膨大になり、GitHubホステッドランナーの費用が経営を圧迫するほどの問題となっていました。コストだけでなく、ディスク容量の制限なども、開発のボトルネックになりつつありました。
この課題に対する彼らの答えは、GitHub Actionsのランナーを、AWS上のセルフホスト環境へ移行することでした。
9割のコスト削減を達成した、現実的な道のり
彼らが採用したのは、OSSとして公開されているTerraformモジュール（philips-labs/terraform-aws-github-runner）。これを活用し、EC2のスポットインスタンス上でCIジョブを実行する仕組みを構築しました。しかし、その道のりは平坦ではありませんでした。
課題1：高額なNAT Gateway
当初、ランナーをプライベートサブネットに配置したため、外部との通信で高額なNAT Gateway費用が発生。AMIをカスタマイズし、DockerイメージをECRにキャッシュするなどの工夫で、外部へのトラフィックを劇的に削減しました。
課題2：スポットインスタンスの中断
スポットインスタンスは安価な反面、いつ中断されるか分かりません。EC2 Fleetの獲得戦略を、価格優先の
lowest-priceからキャパシティ優先のcapacity-optimizedに変更することで、中断率を約4〜5倍改善しました。課題3：ジョブの詰まり
GitHubとの通信障害などでジョブが詰まってしまう問題に対し、15分以上詰まっているジョブを自動でキャンセル＆リトライするワークフローを構築。
これらの地道な改善の末に彼らが手にした成果は、驚異的なものでした。GitHubホステッドランナーを利用した場合と比較して、コストは実に90%以上削減。さらに、S3キャッシュの活用などにより、CIの実行時間も最大55%高速化されたと言います。
DUC氏の発表は、SREの活動が、単にシステムの安定性を守るだけでなく、開発者体験の向上と、ビジネスのコスト効率に直接的に貢献できることを、具体的な数字と共に力強く証明してくれました。
『"SRE チーム" の存在しない組織における SREing』
Repro株式会社 / 今 利仁 (temama)氏
イベントの最後を飾ったのは、Reproの今氏による、組織論に深く踏み込んだセッションでした。大量のイベントデータをリアルタイムに処理するReproには、驚くべきことに**「SRE」という名前の専任チームが存在しません**。では、彼らはどのようにしてSREプラクティスを実践しているのでしょうか。
「私たちの組織では、SREは『名詞（チーム名）』ではなく、『動詞（SREing）』として存在します。Platformチームが、各FeatureチームがSREを実践できるよう『イネーブリング（支援）』する。それが私たちのスタイルです」 —— 今 利仁 (temama)氏
Reproの開発組織は、顧客に価値を届ける複数の「Featureチーム」と、その基盤を支える「Platformチーム」に分かれています。そして、各機能コンポーネントのアラート対応やSLOの運用責任は、それを作成したFeatureチーム自身が負います。
この**「You build it, you own it」**を徹底した体制の中で、Platformチームは、FeatureチームがSREプラクティスを円滑に導入・運用できるよう、以下の4つのステップで支援を行っていると言います。
合意形成: まず、四半期のロードマップに「SLOを導入する」といったSRE施策を明記し、全チームの合意を得る。これにより、「よくわからない仕事が降ってきた」という反発を防ぎます。
担当者を決める: Platformチーム内で、その施策を推進する「担当者」をアサイン。彼らはSREのスペシャリストである必要はなく、その特定のプラクティスに関する知識を深め、伝道師となります。
主導して取り組む: 担当者が主導し、Featureチームと共に実践する。勉強会を開いて知識を共有し、具体的なToDoまで落とし込み、ゴールを明確にします。
振り返りと改善: 導入後も、定期的な振り返りの場を設け、施策が本当に役立っているか、負担が大きすぎないかを確認し、継続的に改善していきます。
このアプローチは、SREを一部の専門家の仕事にせず、組織全体の文化として根付かせるための、非常に現実的で優れたモデルです。SREチームの立ち上げに悩む多くの組織にとって、これ以上ないほどのヒントが詰まったセッションでした。
アーキテクチャは、組織とビジネスを映す鏡
「深堀り！現場のSRE」。3社の三者三様の発表を通して、私たちが改めて確信したのは、SREに銀の弾丸はない、ということでした。
みてねが選んだのは、10年の歴史とグローバルなスケールを支えるための、トレードオフを許容する進化し続けるアーキテクチャ。 SODAが選んだのは、ビジネスの成長とコスト効率を両立させるための、徹底的に無駄を削ぎ落とした実践的なアーキテクチャ。 そしてReproが選んだのは、チームの自律性を最大化し、文化として信頼性を醸成するための、組織と一体化したアーキテクチャ。
彼らが設計し、運用しているアーキテクチャは、それぞれのサービスが持つ特性、ビジネスが置かれた状況、そして組織の文化そのものを、ありのままに映し出す鏡のようでした。
SREの仕事とは、ただインフラを構築することではない。自らが向き合うビジネスと組織を深く理解し、その文脈の中で、信頼性という終わりのない問いに対して、最適解を模索し続ける、知的な探求の旅なのです。その旅路の一端を垣間見ることができた、刺激的な一夜でした。
Yardでは、AI・テック領域に特化したスポットコンサル サービスを提供しています。
興味がある方は、初回の無料スポットコンサルをお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...