Share
Embed
OPTiMized SRE 〜共通基盤で、SREの改善を個別対応から横展開へ〜
2026/06/05 開催「Road to SRE NEXT 2026 @神戸」でのオプティム 加藤の発表資料です。
https://sre-lounge.connpass.com/event/390064/
OPTiM
June 08, 2026
Transcript
14 slides
-
© 2019-2026 OPTiM Corp. All rights reserved. OPTiMized SRE 〜共通基盤で、SREの改善を個別対応から横展開へ〜
Road to SRE Next 2026 @神戸 最終更新日:2026/06/05 -
© 2019-2026 OPTiM Corp. All rights reserved. 2 だれ ◼加藤
◼株式会社オプティム所属 なにしてる ◼Platform Engineeringチームのマネージャー ◼社内の技術標準、開発環境改善、セキュリティ統制の活動にも関与 技術 ◼AWS / Kubernetes ◼Terraform / Helm / Helmfile ◼Grafana Stack 好き ◼キーボード ◼旅行 自己紹介 -
© 2019-2026 OPTiM Corp. All rights reserved. 3 今日話したいこと SREの発足と挫折
SREのリブート オプティムに最適化されたSREとは -
© 2019-2026 OPTiM Corp. All rights reserved. 4 以前のSRE活動 オプティムでは多種多様なサービスを展開している
サービスごとに個別の事情はある一方で改善したい観点は共通している ◼可用性、レイテンシー、セキュリティ、運用負荷、コストなど 共通課題にサービス・組織横断で向き合うためにCenter of Practice型のSREチームを発足 ◼プロダクトを持たず横串で改善を行う サービスの早い・安い・安心の実現を目標として活動 ◼サービス横断で品質をレビュー ◼一律に改善する方法を検討 ◼一部サービスで試験実装 ◼他サービスへ展開 -
© 2019-2026 OPTiM Corp. All rights reserved. 5 課題 ◼サービスごとに実装が違い、横展開のたびに個別対応が必要
◼また、実装の違いから測定方法も個別対応が必要 ◼改善適用は各サービスチームの優先度に左右される SREとして成果が出しにくい状況と様々なタイミングが重なりSREチームを解散した サービス横断SREの課題 Service A AWS EC2 Datadog SendGrid Service B AWS EKS Datadog SendGrid Service C AWS EKS AWS CloudWatch AWS SES モニタリング モニタリング モニタリング メール メール メール プロセス実行基盤 プロセス実行基盤 プロセス実行基盤 異なる実装 手作業構築 手順書もコードもない 採用技術が異なる -
© 2019-2026 OPTiM Corp. All rights reserved. 6 SRE解散後は元いたサービス開発チームに復帰 新規サービスごとにインフラ基盤を都度構築していた
◼構築していたのは基本EKSをベースとしたインフラ基盤だが、 担当者の違いからノウハウが共有されていなかった サービス開発チームの課題 -
© 2019-2026 OPTiM Corp. All rights reserved. 7 課題解決のためにノウハウの共通化を図った ◼EKSベースの環境のインフラコードをTerraform
Moduleでテンプレート化 ◼そのテンプレの運用実績をつくるための共通インフラ基盤Cavorの構築 ◼基盤の改善はテンプレートへ、テンプレートの改善は基盤へ取り込まれる形となった SREのリブート 標準クラス (テンプレート) インスタンス (共通インフラ基盤) 派生クラス オプティムサービスに提供する 共通インフラ基盤に載せられない場合は テンプレートベースで開発する 継承 + 標準で 足りないものを加える 具象化 インスタンス 標準にできるものは フィードバックする 具象化 コード群 コード群 テンプレを構成する インフラコード群 フィードバック 構成 フィードバック サービス開発チーム フィードバック 利用 -
© 2019-2026 OPTiM Corp. All rights reserved. 8 オプティムにおける標準インフラ テナントの分離
◼権限やコストを分離することで共通基盤でもサービスごとの独立性を保てる 共通化により改善の横展開が容易に ◼EKSを使ったコンテナ実行環境 ⚫Linux、Windows、GPUノード ◼Grafana Stackによるモニタリング ⚫メトリック、ログ、トレース、外形監視、ダッシュボード、アラート ◼コスト計算 ⚫使った分のコスト + 共用リソースコストの按分 ◼CI/CD実行基盤 ⚫GitLab Runner 共通インフラ基盤 Cavorが実現したこと -
© 2019-2026 OPTiM Corp. All rights reserved. 9 直近1年のNode/Pod数の推移 (荒目)
直近1年間のNode数の推移 直近1年間のPod数の推移 -
© 2019-2026 OPTiM Corp. All rights reserved. 10 コスト削減
◼新規インフラ基盤の構築: 原則不要 ◼インフラ基盤の運用: 管理は基盤管理者へ委任 ⚫E.g. EKSアップデートや基盤起因のインシデントの対応、 RI/SPの購入、脆弱性対応 ◼通信費: かかったコストすべて → 使った分のコスト+共用リソースコストの按分 ⚫共用リソース: EKS Cluster / Node, ELB, NAT GWなど 責任分界点の引き直し ◼You build it, you run itの文化醸成 モニタリング ◼ダッシュボードのデフォルト提供 ◼アラートのテンプレ提供 セキュリティ ◼IAM Roleの徹底 ⚫人はSSOとし、共有ユーザやIAMユーザを排除 ⚫マシンはIRSAやOIDCによるアクセス ◼権限の最小化 ⚫サービスの範囲に権限を最小化 ◼WAF, IDS, 監査ログのデフォルト有効化 ⚫WAFルールはサービスごとにカスタマイズ可能 Cavorの導入の効果 -
© 2019-2026 OPTiM Corp. All rights reserved. 11 現在
◼23サービスが利用中 ◼社内ハッカソンや有志開発の基盤としても利用中 導入の歩み ◼2023年度: 立ち上げ ⚫1サービス追加 ◼2024年度: マルチテナント化 ⚫3サービス追加 ◼2025年度: 開発組織Aへの利用促進 ⚫19サービス追加 ◼2026年度: 開発組織Bへの利用促進 ⚫1サービス追加 今後 ◼上期中に13サービスの追加を予定 ◼それ以降で検討中も含めると20サービス Cavor活用の広がり -
© 2019-2026 OPTiM Corp. All rights reserved. 12 ゴールデンパスの提供
(具体的な改善方法、テンプレの提供) ◼高信頼性のための設定がデフォルトで入ったHelm Chart ◼高セキュリティや低コストを意識した設定がデフォルトで 入ったAWSリソース用のTerraform Module デベロッパーポータルの提供 ◼高信頼性のために必要な設定や実装のガイドライン ◼AI Agentから参照するためのSKILL Kyvernoを使ったポリシーの適用 ◼E.g. DockerHubのレートリミット対策を目的とした ECR Pull through cacheのためのイメージURL自動変換 Trivy Operatorを使ったイメージの脆弱性や マニフェスト設定の不備の評価 ◼大きめの脆弱性が公開された際はCavor全体での 脆弱性対応状況のレポーティングを実施 Limit Rangeの設定によるPodおよびノードの安定化 ◼Resource Requests/LimitsのデフォルトとMaxの設定 ◼各PodのResource Requests/Limitsの見直しも実施 露出している管理用ツールの自動保護機能の提供 ◼Okta認証 休日・夜間のPodの停止方法の提供 ◼コスト削減のため 定期的な勉強会の開催 ◼25年度は年間で27回実施 ◼信頼性を高めるための方法や提供機能の使い方など サービスごとに定期的な課題解決のためのMTGの実施 定期的な第三者によるセキュリティ診断の実施と改善 Cavorで実現した改善 -
© 2019-2026 OPTiM Corp. All rights reserved. 13 インフラの共通化 (Cavor)によって、
基盤を利用しているサービスの統一された方法での評価と改善がしやすくなった 多種多様なサービスがある場合はインフラの共通化がSRE活動を進める上で有効だった ◼オプティムでは、SRE活動を組織横断的なアプローチで進めるのは課題が多かったが、 インフラの共通化が解決した 2026年度のCavor ◼Cavorが社内標準の共通インフラ基盤の地位を確立できて乗り入れが進んでいるが、 乗り入れ作業がネックになっているため自動化を進める ◼AIの利用が進んでいる現在、利用者がAIを活用してより効率的にCavorを活用できるようにする 必要があるため、利用者のAI活用に注力する まとめ