少人数SREで信頼性を配るためのセルフサービスとガードレール設計

Road to SRE NEXT 2026@沖縄
https://sre-lounge.connpass.com/event/383393/

Transcript

1. 少人数SREで信頼性を配るための セルフサービスとガードレール設計 Road To SRE NEXT 2026@沖縄 2026-05-08 株式会社グラファー 仲嶺 良
2. 2 自己紹介 仲嶺 良 / Ryo Nakamine 株式会社グラファー SRE / Platform Engineering として、Kubernetesクラス タの運用・信頼性向上をはじめ、デプロイ基盤の改善や IaCの推進など、SaaS基盤の安定運用と継続的な改善に取 り組んでいます。 • 沖縄県出身 • x: @r_nakamine
3. 行政サービスのデジタル変革 Graffer Platform 生成AIを企業の業務で活用していくために必要な、伴走支 援、研修、活用プロダクトを包括的に提供。 生成AI活用によるビジネス変革 Graffer AI Solution 3 行政・自治体向け 事業者向け 事業内容 住民接点から行政の内部事務まで切れ目のない行政サービス を実現する、数千万人の市民が使うことのできるデジタル行 政インフラを提供。
4. Graffer Platformとは 4 行政サービスのデジタル変革 オンライン手続き Graffer スマート申請 手続きの案内 Graffer 手続き イド 窓口のネット予約 Graffer 窓口予約 スマートフォンやウェブから 行政サービスが利用できます 手続きや制度の案内、窓口の予約からオンライン手 続きまで、様々な行政サービスをインターネットか ら行えるようにする、行政機関向けのクラウド型の サービススイートを提供しています。 数百万人の市民が使う デジタル行政インフラです これまでに顧客である地方自治体を通じ、数百万人 の市民の方がGraffer Platformを通じてオンライン手 続きなどの行政サービスを利用しています。 電話自動応答／電話発信 Graffer コール
5. Graffer Platformのサービス提供実績 5 6団体 102団体 50団体 273団体 2020年3月 2022年3月 2021年3月 2023年3月 160団体 2024年3月 行政サービスのデジタル変革 194団体 2024年9月 ✔ 自治体中心に273団体にサービスを導入 ✔ 4,100万人超の市民を対象にサービスを提供 ✔ 政令指定都市の70%で導入実績がある 導入団体の例（一部）
6. データ分析・処理 一括処理 アプリケーション エンタープライズ向け生成AISaaS「Graffer AI Studio」 • 汎用的に活用できるチャットサービスを起点としながら、より簡易的に生成AIを活用できるアプリケーションや、 高度な活用や定常業務の効率化につながるような機能を幅広く提供 6 チャットサービス • GPT/Geminiなどモデル切り替え機能 • プロンプトのテンプレート共有機能 • 法人利用に即したアカウント管理 など多数搭載。 タスクライブラリ 営業や経営企画など業務タスクごとにアイテムを用意。 フォーム入力をするだけでプロンプトなしに生成AI活用が可能。 ExcelやCSVなどのファイルを読み込んで、 集計処理や詳細なデータ分析を行うことが可能。 定性的なアンケートのカテゴリ分類や、大量の求人原稿の作成な ど、同種のプロンプトの実行を繰り返し行う場面で、その処理を 一括で行うことが可能。 ワークスペース 社内のドキュメントを継続的に管理し、チャット機能を通じて検 索・参照をしながら新しい成果物を生み出すことが可能。 音声文字起こし 音声や動画データをアップロードすることで、簡単に文字起こし ができ、議事録の作成やWord / PDFファイルの生成が可能。 ファイル検索 その場でPDFなどのファイルを読み込んで、単発的に、 チャットの指示で文言の検索や示唆出しなどの処理が可能。 事業者向け
7. Graffer AI Solutionの導入企業（一部） 7 枚方市 その他、IT・広告企業、食品卸売業、人材派遣会社、鉄道、銀行などさまざまな業界で導入 2.8万人超のビジネスパーソンの生成AI活用を支援 生成AI活用によるビジネス変革
8. 複数プロダクトの信頼性を少人数で支えるという課題 • 業務プロセスに摩擦がある領域のプロダクト群を多数展開。 • 全プロダクトを横断して「高い信頼性・セキュリティ・運用性」を担保する必要がある。 • しかし、インフラ基盤(主にAWS / EKS) と運用を見るSREチームは少人数。 主なシステム構成 • アプリケーション基盤は主にAWS / EKS • プロダクト・環境ごとにAWSアカウントを分離 • 一部でGoogle Cloud / Azureも利用 • SREはクラウド境界、EKS、CI/CD、Datadog、セキュリティ検知を横断して見る 8
9. サービス固有の変更をすべてSREが抱えると組織のボトルネックになる 9
10. 機械的に満たすべき4つの基準: Security | Maintainability | Monitoring / Observability | Reliability これらを人間のチェックリストではなく、3つのフェーズでシステムに組み込む 本番準備の基準を仕組みに落とす「3層のガードレール」 10
11. 1. 作る前 Before 11
12. 【作る前】組織レベルで「越えてはいけない線」を敷く セルフサービスの前提として、SREがクラウドアカウントやプロジェクトの責任境界を事前に整える。 監査ログ、権限、CI/CDの入口を強固に設定する。 12 絶対的ガードレール(変更不可の制約の例):
13. 【作る前】SREの判断をコードとして配る - Terraformモジュール よく使うリソースをTerraformモジュールとして提供する。 • S3 / KMS / ECR • Aurora / RDS • backup • Datadog Forwarder 目的は単なるコードの再利用ではない • セキュリティ、ガバナンス、運用ルールを「標準部品」として配るための仕組み。 • プロダクトチームはモジュールを使うことで、推奨設定に自然に乗れる。 • 標準から外れる場合は、Pull Requestに理由を残す。 13
14. 【作る前】SREの判断をコードとして配る - Kubernetes / Helm Chart Kubernetesでアプリを動かすには、DeploymentやServiceなど複数の設定ファイルを書く必要がある。 これを各チームが毎回ゼロから書くと、設定漏れやサービスごとの差分が生まれやすい。 また、すべての開発者がKubernetesに精通しているわけではないため、社内標準のHelm Chartを用意している。 標準化している例: • アプリの起動方法 • 通信の受け口 • ヘルスチェック • CPU / memoryなどのリソース設定 • 安全に動かすためのsecurityContext • 共通で入れたいsidecar 14
15. 【作る前】新規プロダクトを最初から「標準の運用」に乗せる 新しいプロダクトをEKSで動かすには、アプリ本体のコード以外にも、デプロイに必要な設定やファイル配置が必要にな る。ただし、KubernetesやArgoCDの構成をすべて理解していないと始められない状態にはしたくない。 新規サービス追加時に必要な作業をテンプレート化して提供している • Kubernetes manifest用、Terraform用ディレクトリ • ArgoCD Application • GitHub Actions workflow • Makefileによるセットアップ支援等 ゼロから調べて作るのではなく、コマンドを実行すると標準の置き場所と設定が用意される。 新規サービスを作った段階から、標準のデプロイ・監視・運用に乗せやすくする。 15
16. 2. 作る時 During 16
17. 【作る時】CIとPolicy as Codeで検知する Pull Requestの段階で、変更範囲とリスクを機械的に確認する • 変更されたservice / envだけを対象にCIを実行する • terraform fmt / validate / plan をPull Request上で確認する • applyは原則CI経由にする • TrivyやRego policyで設定ミスを検知する • 補助的にAIレビューも使う • CODEOWNERS reviewで責任境界を明確にする レビューで毎回思い出すべきルールは、できるだけCIに寄せる。 17
18. 3. 作った後 After 18
19. 【作った後】運用を始めた段階からログとイベントが集約される アプリケーションをEKSで動かすと、運用に必要な情報が自動的にDatadogへ集まる。 プロダクトチームがサービスごとにログ収集やイベント収集の仕組みを作る必要はない。 • コンテナの標準出力・標準エラーに出したログ • Podの起動失敗や再起動などのKubernetesイベント • PodやDeploymentの状態 • CPU / memoryなどの利用状況 • process / network / runtime security events これらはPodのlabelやannotationから、service、env、owner、通知先チームに紐づけられる。 アプリを標準の形で載せるだけで、調査・監視・通知に必要な情報が揃う。 19
20. 【作った後】運用リスクを検知し、担当チームへ自立的に通知する EKS上でよく起きる運用リスクは、共通のDatadog Monitorで検知する。 • OOMの多発 • Job / CronJobの失敗 • BackOff / CrashLoopBackOff • DaemonSetのready不足 • NodeGroup単位のCPU / Memory request過多 • ログ取り込み量の急増 アラートはowner情報からチームごとにSlackでメンションする。 確認先や対応方針も入れて、担当チームが自分たちで動ける状態にする。 20
21. 【作った後】IaCやCIで防げない異常な振る舞いを見続ける セルフサービス化すると、各チームが自分たちでインフラやmanifestを書けるようになる。 一方で、SREやセキュリティチームから見ると、作った後にも問いが残る。 この「作った後も見続ける」レイヤーとしてDatadogを使っている。 21 標準から外れた設定が 入っていないか IaCでは検知できない 実行時の異常をどう見 るか 不審な操作やイベント が起きていないか
22. 【作った後】Datadogを使ったセキュリティモニタリング Datadog CSM(Cloud Security Management) • クラウドリソースの設定ミスを検知する • S3 bucketやRDSの暗号化、backup retention period • 意図しないPublic設定 • IaCで防いだはずのルールが、実環境でも守られているかを見る Datadog Workload Security • コンテナやPod上の実行時イベントを検知する • 不審なプロセス実行 • 想定外のファイル・ネットワーク操作 • 実行時にしか分からない異常を拾う MonitorやCSMカスタムルールもTerraformで管理し、監視設定そのものもレビュー可能にしている。 22
23. 【作った後】Datadogを使ったセキュリティモニタリング 具体的なセキュリティモニタリングや自動化の取り組みは、同僚の発表資料で詳しく紹介されています。 23 https://speakerdeck.com/mrtc0/datadog-woshi-tu tapurodakutotokuraudono-sekiyuriteimonitaringu https://speakerdeck.com/mrtc0/product-security- casual-talk-number-1-datadog-woshi-tutasekiyuri teimonitaringuto-zi-dong-hua-noqu-rizu-mi
24. まとめ 少人数SREでは、信頼性を仕組みとして配る • 振り返ると、やっていることはPlatform Engineering的でもある • ただし目的は、開発者体験だけではない • 少人数SREで信頼性・セキュリティ・運用性を維持すること • セルフサービスは自由放任ではなく、ガードレールとセットで成立する • 標準部品・CI・監視を通じて、プロダクトチームが安全に自走できる状態を作る 24