blog

DeNAのエンジニアが考えていることや、担当しているサービスについて情報発信しています

2024.12.27 イベントレポート

SLO 策定とアラート対応の最適化 DeNA インフラ/SRE MEET UP#9 レポート [DeNA インフラ SRE]

by Hidetaka Masuda

#infrastructure #sre-meetup #branding #recruiting #onboarding #infra-quality

はじめに

こんにちは。IT 基盤部ネットワークグループの増田です。

今年の 11 月に開催した「 SLO 策定とアラート対応の最適化 DeNA インフラ/SRE MEET UP#9 」というイベントの様子を紹介します!

SRE MEET UP は DeNA のインフラ部門(IT 基盤部)の活動を紹介するイベントで、今回で 9 回目の開催です。 これまでさまざまなテーマを取り上げてきましたが、今回はインフラの運用にテーマを絞りました。 発表の内容は以下のとおりです。

  • Pococha における SLI・SLO 策定までの道のり
  • PagerDuty によるアラート対応の効率化と最適化
  • 故障対応自動化の試み alert-handle-kicker の誕生

ここからは、それぞれの発表内容を詳しく紹介していきます。

登壇内容

Pococha における SLI・SLO 策定までの道のり

最初に登壇したのは、IT 基盤部第一グループの大田さんです。 Pococha というサービスの SLI・SLO を策定するための取り組みについて発表してくれました。 この発表は、SLI・SLO の設定で悩んでいる方の参考になる内容だと思います。

このグループでは、当初は API サーバーが正常に応答した割合を用いて、簡易的な SLI・SLO を設定していました。 しかし、この指標はユーザー体験を十分に反映できていなかったため、SLI・SLO を見直すことにしました。

SLI・SLO 見直しのきっかけ

見直しの第一歩として、ユーザージャーニーの洗い出しを行いました。 これはインフラ部門だけで進めるのは難しいので、事業部と密に連携をとりながら進めました。 ユーザージャーニーを考える際のコツとして、「ユーザーが何をできなくなると困るか」という視点を持つのが有効だったとのことです。

ユーザージャーニーの洗い出しの例

ユーザージャーニーを洗い出したら、それに対応する SLI を探しました。

ユーザージャーニーに対応する SLI の例

SLO の設定については、現在取り組んでいる最中で、適切な目標値を決めることに難しさを感じているとのことでした。 それでもすでに、インフラチームと事業部の連携が強化されるなど、この取り組みによる成果を感じ始めていました。

SLI・SLO の策定で感じた成果

PagerDuty によるアラート対応の効率化と最適化

次に登壇したのは、IT 基盤部ネットワークグループの三浦さんです。 PagerDuty の機能を活用してアラート対応をどのように効率化し、最適化したかについて発表しました。

ネットワークグループでは、アラートの通知経路が複数あり、誰がどのアラートに対応しているのか分かりづらいという問題がありました。

アラート対応の課題

そこで、PagerDuty のインシデント管理機能を有効活用し、オンコール体制を改善することにしました。

PagerDuty の活用

これまでも PagerDuty は使っていましたが、夜間の電話通知のためにしか使っていませんでした。 しかし、今では機能をフルに活用し、日中を含むほぼ全てのアラートを PagerDuty で一元管理するようにしています。 これにより、誰が障害対応をしているかが簡単にわかるようになりました。 さらに、障害対応を開始するまでの時間が短縮されるなどの成果も上がりました。

PagerDuty 活用の成果

故障対応自動化の試み alert-handle-kicker の誕生

最後に登壇したのは、IT 基盤部第四グループの呂さんでした。 既存のシステムで自動復旧が難しいインスタンスの不具合に対応するために開発した独自ツールを紹介しました。

まず、既存の自動復旧システムでは対応できなかった問題について説明してくれました。 不具合の内容は、あるインスタンスだけが同系統の他のインスタンスに比べて数十パーセント CPU 使用率が高くなるというものでした。 サポートに問い合わせたところ、この問題の原因はノイジーネイバーであり、回避は難しいと判明しました。 問題のあるインスタンスを削除するためには、多くの確認作業が必要で、対応に手間がかかっていました。

手動対応が必要な不調

そこで、「alert-handle-kicker」というツールを内製し、インスタンスの削除作業を自動化しました。 このツールは、CPU 使用率が同系統の他のインスタンスより 20% 以上高くなると実行されます。

alert-handle-kicker

そして、以下のロジックでインスタンスを削除して良いかを判断し、手動対応がどうしても必要な場合を除いて、インスタンスを自動で削除します。 この取り組みにより、運用における手動対応が減少し、運用負荷を軽減することができました。

インスタンスの削除判断ロジック

おわりに

第 9 回の SRE MEET UP で紹介した、インフラの運用に関する 3 つの事例についてまとめました。 SRE MEET UP は今後も connpass で開催していきます。 イベントの情報は DeNA Tech でお知らせするので、SRE MEET UP に興味を持ってくださった方は、ぜひグループのメンバーになってください。

最後まで読んでいただき、ありがとうございます!
この記事をシェアしていただける方はこちらからお願いします。

recruit

DeNAでは、失敗を恐れず常に挑戦し続けるエンジニアを募集しています。