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

by Kazuhiko Yamashita

Slide 1

Slide 1 text

Re:Deﬁne 可用性を支えるモニタリング、パフォーマンス最適化、そしてセキュリティ 2025.01.26 P山@GO株式会社

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 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 これが最高だと思ってた時期が僕にもありました

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© GO Inc. 34 なぜパフォーマンス・チューニングが必要か非日常的なトラフィックの増大や、不具合による処理性能の悪化などにより、最悪システムダウンが発生すると可用性が損なわれる。そのため、SREとしてパフォーマンス面のリスクを常に監視し、問題があれば改善を行うことが非常に重要である。 SREが取り組むパフォーマンスチューニングは大きく2つある。 1. システムのパフォーマンス・チューニング 2. アプリケーションのパフォーマンス・チューニング

Slide 35

Slide 35 text

© GO Inc. 35 システムのパフォーマンス・チューニングシステムとは、ハードウェア、ソフトウェア、ネットワークなどが組み合わさったものシステム全体のパフォーマンス向上には、それぞれの要素に対するチューニングが必要トラフィックが多い場合の対策 ● LB（ロードバランサ）を設置し、負荷を分散 ● リバースプロキシを配置し、キャッシュを活用 ● クラウドサービスならCDNを適切に活用 ● データベースのリードレプリカを増やす「金で殴る」という表現について ● SREの視点では「負け」 ● いかに妥当なコストで問題を解決するかが重要

Slide 36

Slide 36 text

© GO Inc. 36 アプリケーションのパフォーマンス・チューニングアプリケーションのパフォーマンス・チューニング ● コードや設定を変更し、処理速度を向上させることを指す ● 例：SQLクエリのチューニングによるデータベースのパフォーマンス向上初手としての対応 ● テレメトリデータを拡充 ● APM（Application Performance Monitoring）サービスの導入 APMサービスの役割 ● アプリケーションの内部動作を可視化 ● ボトルネックの特定を支援パフォーマンス分析の変化 ● 以前はDBのスロークエリを重点的に分析 ● 近年はスロークエリの監視を行いつつ、 APMを最初に確認するほうが問題を見つけやすい

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© GO Inc. 38 SREの取り組みを組織的なものにする可用性の重要性 ● 可用性が落ちる＝サービスが利用できない状態 ● どんなに新機能を作っても、ユーザーに使われなければ価値を生み出さない可用性の担保は組織全体の責務 ● SREだけでなく、開発者や管理者も責任を持つべき ● 管理者や経営層を含めた優先度の調整・合意形成が不可欠ダッシュボードの活用 ● SREだけが見るものではなく、開発者や管理者も活用すべき ● ダッシュボードを通じて全体の状況を把握し、問題があれば優先度を調整する

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© GO Inc. 40 どうすればSREがアプリケーションのパフォーマンス・チューニングできるようになるのか 1. 計算量で考える ● スロークエリやN+1問題は、計算資源の浪費によるものが多い ● スロークエリ → 過剰なテーブル走査 ● N+1問題 → 不要なクエリの繰り返し実行 ● 「計算量を削減する」視点が重要 ● アルゴリズムやデータ構造の知識を身につけ、ボトルネックに気づきやすくする 2. 道具を磨く ● エディター、Linuxコマンド、SaaSなどのツールを活用する ● エディターの設定 : タグジャンプを活用し、コードを追いやすくする ● Linuxコマンド : strace や tcpdump を使いこなし、システムの内部動作を観察 ● SaaSの活用 : 監視やログ収集を効率化し、迅速な問題解決を可能にする 3. 引き出しを増やす ● 計算量の問題を把握するだけでなく、それを改善する手法を知ることが重要 ● データベース最適化 : インデックスの適切な利用、 SQLチューニング、ER図の読み解き ● キャッシュ戦略 : HTTPリクエストの遅延対策 ● 指数バックオフリトライ : 通信失敗時の再試行 ● 多様な技術の引き出しを持つことで、柔軟な解決策を提供できるようになる

Slide 41

Slide 41 text

© GO Inc. 41 どうすればSREがアプリケーションのパフォーマンス・チューニングできるようになるのか 4. Linuxの仕組みを理解する ● カーネルチューニングやプロセス間通信の理解でシステム全体のパフォーマンス向上 ● バッファ管理やカーネルパラメータの意味を理解し、システムの挙動を把握 ● Linuxはソフトウェアの基盤であり、学ぶことで広範な技術知識が得られる 5. ルールチェンジする柔軟な発想を持つ ● 直接的に「処理を速くする」以外のアプローチも考える ● 仮想待合室の導入: ユーザーアクセス数を制御 ● 機械学習を用いたアプローチ : ルールベースではない判定 ● スループットを物理的に抑制する施策も有効な解決策になり得る

Slide 42

Slide 42 text

© GO Inc. 42 趣味開発を通じたスキル向上趣味開発を通じたスキル向上 ● 実際に自分でサービスや仕組みを作り、運用を体験するのが効率的 ● AIを活用すれば、対話的に学習しながら簡単な Webアプリケーションを構築可能得られる学び ● ブログシステム程度の実装でも、 Web表示からDB書き込みまでの流れを理解できる ● ライブラリの問題点を深掘りする機会になる ● 実際に不具合を発見することもあり、システム理解が深まる SREにとっての趣味開発の価値 ● インフラ視点だけでなく、開発スキルも伸ばせる ● 開発チームとの共通理解が深まり、より効果的な SRE活動が可能になる ● 実践的な知識が身につき、本番環境でのトラブルシューティングにも活かせる

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© GO Inc. 45 シフトレフト構成管理のガードレール整備 ● インフラ構成管理において、意図しないホストやポートの公開がないかをワークフローで検知 ● コンテナの権限が適切かを自動でチェックし、必要に応じて修正 ● アプリケーションエンジニアがクラウド設定を行うケースが増加 ● 誰が作業しても問題が発生しない仕組みの自動化が重要ヒヤリハットのコード化 ● 小さなミスやインシデント予兆を放置せず、それをコードとして記録・防止 ● 「過去に問題を引き起こした変更」をガードレールに反映し、再発防止を徹底 AIを活用したレビューの導入 ● AIを活用したコードや構成ファイルの自動レビューが可能に ● インシデントリスクを低減するため、 AIレビューの導入を検討早い段階で問題を検出し、リスクを低減するアプローチ

Slide 46

Slide 46 text

Slide 47

Slide 47 text

© GO Inc. 47 ソフトウェアのバージョンアップソフトウェアのバージョンアップの重要性 ● 脆弱性の放置リスク ○ 脆弱性を狙うボットが多数存在 ○ 更新が遅れたソフトウェアが攻撃対象になりやすい対策方法 ● ライブラリ・パッケージの自動更新 ○ Dependabot や Renovate を活用し、定期的に更新 ● OSレベルのセキュリティ対策 ○ Linuxディストリビューションの自動アップデート機能を活用 ○ OSの脆弱性を継続的に修正

Slide 48

Slide 48 text

© GO Inc. 48 異常・変更検知異常・変更検知の重要性 ● システム内の異常な振る舞いを検知し、迅速に対応異常検知システムの導入 ● データ流出や不審なネットワーク通信を監視 ● 普段通信しない経路へのアクセスを遮断（ネットワーク監視ツールの活用）変更検知の強化 ● ファイル配置やプロセス変更をリアルタイム監視 ● 意図しない変更が発生した際に即座にアラート発報誤検知対策 ● 正常なデプロイによるノイズアラートを除外 ● 機械学習を用いたルールベースではないフィルタリングも有効

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© GO Inc. 54 障害対応には矜持がある障害対応に対する考え方（ SRE視点） ● 偶発的な障害は、今夜にも再発する可能性がある ● 根本対応をいかに早く行うかが重要 ● 個人としては即日での根本対応を目指すべき暫定対応（止血対応）のリスク ● 一時的な対応が習慣化すると、根本対応が後回しになる ● 結果として障害の再発を招く危険性がある SREとしての矜持 ● 障害対応に対して責任を持ち、早急に根本対応を実施することが重要

Slide 55

Slide 55 text

© GO Inc. 55 結び SREの役割と信条 ● サービスの安定稼働に必要なことは、壁を作らずすべてやる ● モニタリング、障害対応、セキュリティ、パフォーマンスチューニング、フロントの実装、RFPの作成など全部やる SREの醍醐味 ● やることは多いが、それがSREの面白さ ● SREはサービスの安定稼働を担保するためのエンジニアリング SREに求められるスキルとキャリアの魅力 ● 多岐にわたるスキルが必要だが、その分やりがいも大きい ● SREとしてのキャリアや開発エンジニアとの往来がおすすめ

Slide 56

Slide 56 text

Slide 57

Slide 57 text