「名ばかり」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がどれだけ発生していたかなど。またトレースデータの保存対象や保存期間を検討しておくといいだろう。
EUMで可視化するべきポイントはアプリ内部の動作やWebページ描画時の動作における、HTMLページアクセス、APIアクセス、リソースアクセス、外部サービスおよび外部リソースへのアクセスとなる。
エンドユーザー監視では、モバイルアプリならユーザーがアクセスしていた画面、クラッシュが発生した画面、クラッシュ発生前の操作、サーバーからのエラー、WebサイトならJavaScriptのエラーメッセージなどを把握できるようにしたほうがいい。また提供される情報がユーザー単位の操作履歴なのか全ユーザーの統計情報かを確認しておこう。
応用編となるが、ビジネスデータを収集するなら、アクセスしているユーザー属性、ECサイトなら商品IDや価格、アプリケーションのバージョン、リクエストごとのレスポンスなどを把握できるといい。
シスコのAppDynamicsはビジネストランザクションから深掘りできる
APMやEUMはSREにとって強力なツールとなる。調査可能な項目は同じでも、使い勝手はツールにより差異がある。例えばアプリケーションのフローマップを可視化すると、ツールによっては激しく複雑な表示になるものもある。どのように可視化されるか、どのように詳細を表示させていくかの操作性はSREにとって仕事の生産性を左右する。
シスコが提供しているAppDynamicsは顧客体験を軸としたオブザーバビリティが可能だ。つまりビジネストランザクションごとのトレースでアプリケーションフローを把握できる。トレースを使うことで問題のサービスを特定し、サービスのメトリック、ログ、イベントを分析して問題の原因を特定していくことができる。
実際にはビジネストランザクションの一覧で統計やヘルスステータスが分かり、そこからアプリケーションフローマップやトランザクションのトレースへと深掘りすることができる。
SREはAppDynamicsのビジネストランザクション一覧から、問題があるものを深掘りすることで業務を進めていく。例えばステータスに問題があるビジネストランザクションがあれば詳細を開き、トランザクションフローマップを表示し、さらにそのビジネストランザクション内でステータスに問題があるサービスの詳細を表示し、問題を特定することができる。またビジネストランザクションは業務トランザクションとマッピングして使うため、何らかの不具合がビジネスゴール（購入など）にどれだけ影響を与えているかも確認できる。
シスコシステムズ 関屋氏はAppDynamicsのビジネスオブザーバビリティのメリットとして次の3つを挙げる。
- アプリケーションの状態が把握しやすくなり予兆検知や原因分析に有効
- トランザクションと業務をマッピングしてビジネス部門と情報共有しやすくなる
- APMと他ITツールで連携すると、ビジネストランザクションの性能統計データで会話できる
AppDynamicsはAPIが豊富に用意されており、他ITツールとAPIで連携することができる。例えばIT運用管理「Cisco Intersight Workload Optimizer」と連携すればビジネストランザクション状態に応じたインフラのオーケストレーションができる。データセンター向け「Cisco Nexus Insights」と連携すれば、ネットワーク変更時のビジネストランザクション状態を確認できる。負荷テストツールのApicaと連携すれば、負荷テストの結果画面でビジネストランザクションの性能確認ができる。ServiceNowと連携すれば、IT管理者がServiceNowからビジネストランザクション状態を確認することもできる。可能性は大きく広がっている。
最後に関屋氏はSREを担当するエンジニアに向けて、次のようにアドバイスした。
「APMやEUMを使いましょう。今までとは異なる運用の世界が見えてきます。もし使い道に迷ったら、まずは自分たちの課題が何か考えてみてください。監視データと業務トランザクションを関連付けると、ビジネスへの影響が可視化できてSREがビジネスに貢献できるようになります」
