CodeZine(コードジン)

特集ページ一覧

これからのSREはモニタリングからオブザーバビリティへ APMやEUMを使いこなせ【デブサミ2021】

【18-A-8】ビジネスオブザーバビリティことはじめ - ひとつ上のSREを目指すためのAPM入門

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/04/13 12:00

 「どんどん開発して新機能をリリースしていきたい」と考えるDev(開発者)と「サービスを安定稼働させたいから、リリース頻度はできるだけ抑えたい」と考えるOps(運用管理者)だと対立してしまいがち。しかし「エンジニアリングでうまく回るようにしてみせる」と考えるSREならDevと協力体制を築くことができる。これからの、ひとつ上のSREになるためには?

目次
シスコシステムズ合同会社 アップダイナミクス事業部・アドバイザリー・セールス・エンジニア 関屋信彦氏
シスコシステムズ合同会社 アップダイナミクス事業部・アドバイザリー・セールス・エンジニア 関屋信彦氏

「名ばかり」SREと「できる」SREはどこが違う?

 サイト安定稼働のためのSRE(Site Reliability Engineering)チームの役割はサービスのモニタリング、効率、変更管理、緊急時の対応、キャパシティプランニングがある。求められるスキルには、スクリプティング、クラウド管理、運用監視、CI/CD、ネットワーク管理、データベース管理、ミドルウェア管理がある。SREがレベルアップするための方策について、シスコシステムズ 関屋信彦氏が指南する。

 スキルや経験が足りない「名ばかり」SREはサイトの監視をしていつつも、一般的なインフラ監視項目以外は開発チームに一任してしまいがちだ。SREもDevも互いに丸投げしてしまい、本番運用後にコネクションプールやAPI単位のトランザクション性能などが問題になってしまう。例えばユーザーからエラーが報告されても、下記のようなやりとりで的確な調査ができず、問題解決できずに終わってしまう。

ユーザー「画面が真っ白で何も表示されません」

名ばかりSRE「500エラーが発生している。開発者に聞こう」

開発者「白い画面だけじゃ分からない。エラー前後の動作は? 再現性は?」

ユーザー「また画面が真っ白です」

名ばかりSRE「再現したらしいです」

開発者「アプリのバージョンは? コードをチェックアウトして確認しないと分からない。今は立て込んでいるから数日待って」

 開発者がアプリに問題があるとうすうす感じていても、一部のユーザーだけに生じたエラーだとサービス全体の問題とされずに放置されてしまいがちだ。運用チームに危機感がなくて放置されているうちに、ユーザーに悪い口コミが広がってしまうと、気づかぬうちに売上に悪影響を及ぼすこともある。逆にトラブルシューティングのためにユーザーを長時間拘束すると、ユーザーにも迷惑がかかる。SREが未熟だと、ただ時間を浪費してしまうことにもなりかねない。

 熟練の「できる」SREなら、監視項目設定を主導し、開発者からインフラや監視について教えるほど頼れる存在になる。監視項目はリソースのボトルネックを確認できるように準備しておく。単なるインフラ監視にとどまらず、遅延しているAPIが何か、原因が何か、開発にフィードバックできるようにする。加えて不要なアラートは出さないようにする。やりとりは次のようになる。

ユーザー「画面が真っ白で何も表示されません」

できるSRE「500エラーが発生している。アプリケーションログから操作履歴の確認、問題発生時のトレースをして、と。問題のリクエストの詳細はこちらです」

開発者「ここまで問題の切り分けができていると、明日にでも改修可能です!」

 さらに準備がいいSREだと、エラーではなく遅延したAPIを検知して、開発者側に改善のヒントをうながすこともできる。もっとできるSREだとビジネス影響も分析して、ビジネス部門に情報をシェアすることもできる。例えば以下のようなやりとりになる。

できるSRE「通常より遅いトランザクションがあります。この影響は2500人におよび、機会損失金額はおよそ2000万円。エラー発生前と比べてコンバージョンレートが15%低下しています」

ビジネス部門「ビジネス影響の規模が数字で分かるなんて!」

開発者「ユーザーにそれほど影響を与えていたなんて。再発防止すべく修正しよう」

これからのSREはAPMやEUMを使いこなそう

 未熟なSREだと従来方式で監視や統計化することはできても、アプリケーション視点に踏み込めないなど何か課題を抱えている。できるSREはAPM(アプリケーション パフォーマンス モニタリング)を活用してリクエスト単位でアプリケーションの挙動を調べ、EUM(エンドユーザー モニタリング)でユーザーのアクセス状況を調査することもできる。やっていることがモニタリングからオブザーバビリティへと進化しているのだ。

モニタリングからオブザーバビリティへ
モニタリングからオブザーバビリティへ

 APMで可視化するべきポイントは、トランザクションの実行状況、SQLの実行状況、他サービスを呼び出すならプログラムコードの性能、外部サービスの呼び出し状況だ。

 アプリケーション監視では全てのエラーを検知するだけではなく、次のような項目を把握できるようにしたほうがいい。遅いSQLの原因は何か(CPU不足か実行計画か)、リクエストを処理したサーバーやコンテナはどこか、GCがどれだけ発生していたかなど。またトレースデータの保存対象や保存期間を検討しておくといいだろう。

APMで可視化できる情報の例
APMで可視化できる情報の例

 EUMで可視化するべきポイントはアプリ内部の動作やWebページ描画時の動作における、HTMLページアクセス、APIアクセス、リソースアクセス、外部サービスおよび外部リソースへのアクセスとなる。

 エンドユーザー監視では、モバイルアプリならユーザーがアクセスしていた画面、クラッシュが発生した画面、クラッシュ発生前の操作、サーバーからのエラー、WebサイトならJavaScriptのエラーメッセージなどを把握できるようにしたほうがいい。また提供される情報がユーザー単位の操作履歴なのか全ユーザーの統計情報かを確認しておこう。

EUMで可視化できる情報の例
EUMで可視化できる情報の例

 応用編となるが、ビジネスデータを収集するなら、アクセスしているユーザー属性、ECサイトなら商品IDや価格、アプリケーションのバージョン、リクエストごとのレスポンスなどを把握できるといい。


関連リンク

  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

バックナンバー

連載:【デブサミ2021】セッションレポート

もっと読む

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5