Re:Define 可用性を支える モニタリング、パフォーマンス最適化、そしてセキュリティ

SRE Kaigi 2025でお話した資料です。

1. Re:Define 可用性を支える モニタリング、パフォーマンス最適化、 そしてセキュリティ 2025.01.26 P山@GO株式会社
2. © GO Inc. 2 SREの生き様は失っていません、信じてください GO株式会社 山下 和彦 所属 開発本部 ソフトウェア開発統括部 　バックエンド開発部 　　バックエンド1グループ @pyama86
3. © GO Inc. 3 Re:Define Google社をはじめ多くの企業のアウトプットにより、 「SREとは何か」ということや、それを実践するための ノウハウは広く伝えられてきた。 そのさまざまな定義やノウハウに対して、 「私はこう思う」「こうしている」というアンサーソング として話したいという意図から、本稿のタイトルに「Re:」を 付けた。「Re:」はメールの返信のときに付く「Re:」が元ネ タである。
4. © GO Inc. 4 哲学 足し算できるような運用をする 1. 運用を育てる 2. ベネフィットがあるなら出せ
5. © GO Inc. 5 ベネフィットがあるなら出せ 0% 100% 時間 完成度 リリース 断続的に 再発を繰り返し 破滅 100%教 動くなら出せ派
6. © GO Inc. 6 Site Reliability Engineering
7. © GO Inc. 7 “SREとは、ソフトウェアエンジニアに 運用チームの設計を依頼したときに できあがるものです。” O’Reilly社 SRE サイトリライアビリティエンジニアリング初版 P5 1.2 サービス管理へのGoogleのアプローチ:サイトリライアビリティエンジニアリングより引用
8. © GO Inc. 8 可用性とは システムが利用できるかどうかを示す尺度 　SREが担保すべきシステム要件の代表例 　セキュリティ特性（機密性・完全性・可用性）の 　観点においても、可用性は必須
9. © GO Inc. 9 SLI/SLO SLI - Service Level Indicator(サービスレベル指標) SLO - Service Level Objective(サービスレベル目標) 例: HTTPステータスコードの比率、レスポンスのレイテンシ 例: ステータス200が99.99%以上、99%tailのレイテンシが3msec以内
10. © GO Inc. 10 今日話すこと 1.監視(モニタリング) 2.パフォーマンス・チューニング 3.セキュリティ 4.GOに入社して良かったこと400選
11. © GO Inc. 11 監視
12. © GO Inc. 12 なぜ人類は監視をするのか？ 1. システムの健全性を測るため 2. システムの傾向を観測するため
13. © GO Inc. 13 何を監視すべきか？ 1. リソース監視 2. ログ監視 3. セマンティック監視 4. 4大シグナル
14. © GO Inc. 14 リソース監視 1. CPU/Memory/Diskなどの監視 2. クラウドサービスのメトリクス
15. © GO Inc. CPU使用率95%は異常か？ 15
16. © GO Inc. 16 ログ監視 1. ログレベルでの監視 2. 特定のメッセージを監視 3. 発生量の監視
17. © GO Inc. 17 セマンティック監視 1. 合成監視 例：「トップページにアクセス → ログイン → ページ 遷移 → ログアウト」といった 一連のユーザー操作をスクリプト化し、定期的に実行 することでサービスの稼働状況を確認する。操作フ ローのどこかが失敗した場合、ユーザーに影響が出て いると判断できる。
18. © GO Inc. 18 4大シグナル 1. レイテンシ 2. トラフィック 3. エラー 4. サチュレーション O’Reilly社 SRE サイトリライアビリティエンジニアリング初版 P61 6.6 4大シグナルより引用 “ユーザーが直接利用するシステムで、メトリクスを4つだけ 計測できるなら、この4つに集中してください”
19. © GO Inc. 19 現代の監視事情 旧来とクラウドネイティブな昨今では考え方が違う クラウドの弾力性やスケーリングを踏まえると、CPUの飽和 などはただのノイジーアラートになりがち 現代においてはセマンティック監視の重要度が高い
20. © GO Inc. 20 監視の原則 無視できるアラートは 出すな！！！！！！！(意訳) ※正確な内容は O’Reilly社 SRE サイトリライアビリティエンジニアリング初版 P66 6.10 原則の取りまとめを参照
21. © GO Inc. 21 足し算する監視 1. 障害をきっかけに監視アラートを追加 a. 傾向を早く掴む 2. 障害が自動復旧するようなスクリプトを実装 a. Mackerelのcommand句などを活用
22. © GO Inc. 22 オブザーバビリティ
23. © GO Inc. 23 オブザーバビリティの高いシステム ソフトウェアを変更しなくても 外部からシステムの状態が 手に取るようにわかる
24. © GO Inc. 24 オブザーバビリティを高めるには 1. それぞれのテレメトリーが相互にリンク されており、掘り進めるように調査できる ようにする 2. 自動計装に加えて、手動計装も追加する 3. 可能な限り細かい粒度でテレメトリデータを 取得する
25. © GO Inc. 25 以前の俺 def process_order(order_id): print(f"Checked inventory for {order_id}") check_inventry(order_id) print(f"Payment started for {order_id}") payment_process(order_id) print(f"Order {order_id} completed") order(order_id) [12:34:56.623] Checked inventory for 1 [12:34:56.923] Payment started for 1 [12:34:57.323] Order 1 completed これが最高だと思ってた時期が僕にもありました
26. © GO Inc. 26 時代はトレース、トレースもってこい！！！ 何がどれくらいの時間かかってどういう パラメーターか直感的にわかる T r a c e Checked inventory for 1 Payment started for 1 Order 1 completed
27. © GO Inc. 27 オブザーバビリティも足し算 日々、調査のたびに不足してる何かはある。 それをそのままにせずにちゃんと計装を追加する。 そしてそれを次回の調査で使えるようにしておく、 またはメトリクスなら監視する。 そういう積み重ねが明日の平穏を作る
28. © GO Inc. 28 本当にあった 怖い監視の話
29. © GO Inc. 29 ノイジーアラート 僕「このアラート、ずっと出てるけど何もしなくていいの？」 ???「普段は大丈夫なんすけど、たまにだめなんすよね」
30. © GO Inc. 30 ノイジーアラート 1. メトリクスの粒度が足りてなくて、真因をアラートに 　設定できてない 2. 当事者のスキル、モチベーションに課題があり適切な 　アラートが設定できない 3. 日々に忙殺されていて、後回しになっている
31. © GO Inc. 31 一生なくならないアラート 僕「このアラート、毎晩対応してない？」 ???「そうなんすけど、とりあえずコマンド打てば復旧します」
32. © GO Inc. 32 一生なくならないアラート 1. 担当者のスキルミスマッチ unknown/unknownの壁 2. 木こりのジレンマ トイル
33. © GO Inc. 33 パフォーマンス・ チューニング
34. © GO Inc. 34 なぜパフォーマンス・チューニングが必要か 非日常的なトラフィックの増大や、不具合による処理性能の悪化などに より、最悪システムダウンが発生すると可用性が損なわれる。 そのため、SREとしてパフォーマンス面のリスクを常に監視し、 問題があれば改善を行うことが非常に重要である。 SREが取り組むパフォーマンスチューニングは大きく2つある。 1. システムのパフォーマンス・チューニング 2. アプリケーションのパフォーマンス・チューニング
35. © GO Inc. 35 システムのパフォーマンス・チューニング システムとは、ハードウェア、ソフトウェア、ネットワークなどが組み合わさったもの システム全体のパフォーマンス向上には、それぞれの要素に対するチューニングが必要 トラフィックが多い場合の対策 • LB（ロードバランサ）を設置し、負荷を分散 • リバースプロキシを配置し、キャッシュを活用 • クラウドサービスならCDNを適切に活用 • データベースのリードレプリカを増やす 「金で殴る」という表現について • SREの視点では「負け」 • いかに妥当なコストで問題を解決するかが重要
36. © GO Inc. 36 アプリケーションのパフォーマンス・チューニング アプリケーションのパフォーマンス・チューニング • コードや設定を変更し、処理速度を向上させることを指す • 例：SQLクエリのチューニングによるデータベースのパフォーマンス向上 初手としての対応 • テレメトリデータを拡充 • APM（Application Performance Monitoring）サービスの導入 APMサービスの役割 • アプリケーションの内部動作を可視化 • ボトルネックの特定を支援 パフォーマンス分析の変化 • 以前はDBのスロークエリを重点的に分析 • 近年はスロークエリの監視を行いつつ、 APMを最初に確認するほうが問題を見つけやすい
37. © GO Inc. 37 パフォーマンス・チューニングにおけるジレンマ SREと開発チームの役割分担 • SREがパフォーマンス改善の調査を担当 • 実際のコード改修は開発チームに任されることが多い 課題：開発チームの優先度 • 新機能開発が優先され、パフォーマンス改善や可用性の担保が 後回しになることがある 対応策 1. SREの取り組みを組織的なものにする 2. 全部やればええやろ
38. © GO Inc. 38 SREの取り組みを組織的なものにする 可用性の重要性 • 可用性が落ちる＝サービスが利用できない状態 • どんなに新機能を作っても、ユーザーに使われなければ価値を生み出さない 可用性の担保は組織全体の責務 • SREだけでなく、開発者や管理者も責任を持つべき • 管理者や経営層を含めた優先度の調整・合意形成が不可欠 ダッシュボードの活用 • SREだけが見るものではなく、開発者や管理者も活用すべき • ダッシュボードを通じて全体の状況を把握し、問題があれば優先度を 調整する
39. © GO Inc. 39 全部やればええやろ SREの主体的な対応 • 開発チームの対応が遅れる場合でも、 SREが問題を解決できれば ユーザー視点では問題が解消される • 可能な範囲でSREがコードや設定変更を行い、 システムの可用性や パフォーマンスを改善するアプローチが有効 @941さんのXから引用 https://x.com/941/status/1703357155729195467
40. © GO Inc. 40 どうすればSREがアプリケーションのパフォーマンス・チューニング できるようになるのか 1. 計算量で考える • スロークエリやN+1問題は、計算資源の浪費によるものが多い • スロークエリ → 過剰なテーブル走査 • N+1問題 → 不要なクエリの繰り返し実行 • 「計算量を削減する」視点が重要 • アルゴリズムやデータ構造の知識を身につけ、ボトルネックに気づきやすくする 2. 道具を磨く • エディター、Linuxコマンド、SaaSなどのツールを活用する • エディターの設定 : タグジャンプを活用し、コードを追いやすくする • Linuxコマンド : strace や tcpdump を使いこなし、システムの内部動作を観察 • SaaSの活用 : 監視やログ収集を効率化し、迅速な問題解決を可能にする 3. 引き出しを増やす • 計算量の問題を把握するだけでなく、それを改善する手法を知ることが重要 • データベース最適化 : インデックスの適切な利用、 SQLチューニング、ER図の読み解き • キャッシュ戦略 : HTTPリクエストの遅延対策 • 指数バックオフリトライ : 通信失敗時の再試行 • 多様な技術の引き出しを持つことで、柔軟な解決策を提供できるようになる
41. © GO Inc. 41 どうすればSREがアプリケーションのパフォーマンス・チューニング できるようになるのか 4. Linuxの仕組みを理解する • カーネルチューニング やプロセス間通信の理解でシステム全体のパフォーマンス向上 • バッファ管理やカーネルパラメータの意味を理解し、システムの挙動を把握 • Linuxはソフトウェアの基盤であり、学ぶことで広範な技術知識が得られる 5. ルールチェンジする柔軟な発想を持つ • 直接的に「処理を速くする」以外のアプローチも考える • 仮想待合室の導入: ユーザーアクセス数を制御 • 機械学習を用いたアプローチ : ルールベースではない判定 • スループットを物理的に抑制する施策も有効な解決策になり得る
42. © GO Inc. 42 趣味開発を通じたスキル向上 趣味開発を通じたスキル向上 • 実際に自分でサービスや仕組みを作り、運用を体験するのが効率的 • AIを活用すれば、対話的に学習しながら簡単な Webアプリケーションを構築可能 得られる学び • ブログシステム程度の実装でも、 Web表示からDB書き込みまでの流れを理解できる • ライブラリの問題点を深掘りする機会になる • 実際に不具合を発見することもあり、システム理解が深まる SREにとっての趣味開発の価値 • インフラ視点だけでなく、開発スキルも伸ばせる • 開発チームとの共通理解が深まり、より効果的な SRE活動が可能になる • 実践的な知識が身につき、本番環境でのトラブルシューティングにも活かせる
43. © GO Inc. 43 セキュリティ
44. © GO Inc. 44 セキュリティインシデントを発生させないために 1. シフトレフト 2. 多層防御 3. ソフトウェアのバージョンアップ 4. 異常・変更検知
45. © GO Inc. 45 シフトレフト 構成管理のガードレール整備 • インフラ構成管理において、意図しないホストやポートの公開がないかをワークフローで検知 • コンテナの権限が適切かを自動でチェックし、必要に応じて修正 • アプリケーションエンジニアがクラウド設定を行うケースが増加 • 誰が作業しても問題が発生しない仕組みの自動化が重要 ヒヤリハットのコード化 • 小さなミスやインシデント予兆を放置せず、 それをコードとして記録・防止 • 「過去に問題を引き起こした変更」をガードレールに反映し、再発防止を徹底 AIを活用したレビューの導入 • AIを活用したコードや構成ファイルの自動レビューが可能に • インシデントリスクを低減するため、 AIレビューの導入を検討 早い段階で問題を検出し、リスクを低減するアプローチ
46. © GO Inc. 46 多層防御 多層防御の重要性 • セキュリティ対策を複数組み合わせる考え方 • 一つの対策が突破されても、他の対策で防御可能 多層防御のメリット • ヒューマンエラーのリスク軽減 • 脆弱性発見時の影響を最小化 • インシデントの未然防止
47. © GO Inc. 47 ソフトウェアのバージョンアップ ソフトウェアのバージョンアップの重要性 • 脆弱性の放置リスク ◦ 脆弱性を狙うボットが多数存在 ◦ 更新が遅れたソフトウェアが攻撃対象になりやすい 対策方法 • ライブラリ・パッケージの自動更新 ◦ Dependabot や Renovate を活用し、定期的に更新 • OSレベルのセキュリティ対策 ◦ Linuxディストリビューションの自動アップデート機能を活用 ◦ OSの脆弱性を継続的に修正
48. © GO Inc. 48 異常・変更検知 異常・変更検知の重要性 • システム内の異常な振る舞いを検知し、迅速に対応 異常検知システムの導入 • データ流出や不審なネットワーク通信を監視 • 普段通信しない経路へのアクセスを遮断（ネットワーク監視ツールの活用） 変更検知の強化 • ファイル配置やプロセス変更をリアルタイム監視 • 意図しない変更が発生した際に即座にアラート発報 誤検知対策 • 正常なデプロイによるノイズアラートを除外 • 機械学習を用いたルールベースではないフィルタリングも有効
49. © GO Inc. 49 セキュリティインシデントが発生してしまった時のために 1. 影響範囲を特定するための情報保全 2. 利用できるバックアップを確保する 3. インシデント訓練を実施する
50. © GO Inc. 50 影響範囲を特定するための情報保全 ログの保全 • 監査ログやデータベースクエリログを収集 • 改ざん防止のため外部システムに保存 • インシデント発生時の調査を容易にする ストリーミングの活用 • 特に重要なログはリアルタイムでストリーミング保全 • 影響範囲の特定を迅速化
51. © GO Inc. 51 利用できるバックアップを確保する ランサムウェア対策 • 攻撃を受けた際に備え、暗号化されていないバックアップを確保 • ゼロからの復旧を避けるため、定期的なバックアップと検証を実施 リストアの検証 • バックアップデータの有効性を確認するため、定期的にリストアテストを実 施 • リストアテストを自動化し、復旧可能性を常に維持
52. © GO Inc. 52 インシデント訓練を実施する 実践的なシミュレーション • 攻撃を想定したインシデント対応訓練を実施 • 進行中の攻撃シナリオを用意し、影響範囲の特定・復旧手順を確認 外部サービスの活用 • Chaos Engineering やセキュリティ訓練支援プラットフォームを導入 • より実践的なスキル向上を図る
53. © GO Inc. 53 余談:障害対応
54. © GO Inc. 54 障害対応には矜持がある 障害対応に対する考え方（ SRE視点） • 偶発的な障害は、今夜にも再発する可能性がある • 根本対応をいかに早く行うかが重要 • 個人としては即日での根本対応を目指すべき 暫定対応（止血対応）のリスク • 一時的な対応が習慣化すると、根本対応が後回しになる • 結果として障害の再発を招く危険性がある SREとしての矜持 • 障害対応に対して責任を持ち、早急に根本対応を実施することが重要
55. © GO Inc. 55 結び SREの役割と信条 • サービスの安定稼働に必要なことは、壁を作らずすべてやる • モニタリング、障害対応、セキュリティ、パフォーマンスチューニング、 フロントの実装、RFPの作成など全部やる SREの醍醐味 • やることは多いが、それがSREの面白さ • SREはサービスの安定稼働を担保するためのエンジニアリング SREに求められるスキルとキャリアの魅力 • 多岐にわたるスキルが必要だが、その分やりがいも大きい • SREとしてのキャリアや開発エンジニアとの往来がおすすめ
56. © GO Inc. 56 謝辞 数々の書籍を出してくれるO'Reilly社と 執筆者、翻訳者、監訳者の方々 GMOペパボに所属する元同僚たち SRE Kaigi 2025を始め、多くのイベント を支えてくださるスタッフの方々
57. © GO Inc. 今日一日、楽しんで行きましょう 57 私たちと一緒に 未来を作っていきませんか？