New Relic {FUTURE} STACK スーパー書き殴りメモ

New Relic {Future} STACK
2019年3月14日
https://futurestack19-lp.eventcloudmix.com/

ハンズオン

はじめに

アプリケーション監視が特別である理由

• 影響を受ける要素が多い 外部サービス・DB・ユーザー入力・出力・ほかプロセス
• ただ動いているだけでは十分ではない マネタイズしているか

データ収集の仕組み

• トランザクション（リクエスト窓口）の自動検出とパフォーマンス計測
• 外部プロセスとの通信の自動検出とパフォーマンス計測

やるべきこと

• ビジネス目標を達成したか
  • Insightsで確認できる
• 全体のパフォーマンスを確認
  • ヒストグラムでデータの分布区分ごとの件数（1秒台が10件…など）を確認
  • パーセンタイルでデータを小さい順に並べたときの、全体の割合とその値を時系列で確認
  • Apdexスコア (満足の件数 + やや満足の件数の半分) / 総数
• 個別のトラブルシューティングもしくは全体の最適化
  • Trancactionsで消費時間・処理時間が遅い順でソートできる。そこから処理ごとの詳細サマリが見られる

重要なこと

• トランザクションがどんな処理なのかを理解すること
  • Key Transactionを考慮してみる
• ビジネス目標を意識すること
• トランザクション全体のパフォーマンスを意識する
• 個別事象の対応なのか、全体の最適化なのかを意識すること
  • 個別の事象の確認: トランザクショントレース、エラーアナライティクス
  • 全体の最適化

Insights

データを分析しダッシュボードを作成

• 一番簡単なダッシュボードの作成は、既存のチャートを貼り付ける。

• APMの各チャートをマウスホバーするとメニューが出る。

• エージェントは対象上で発生した各種イベントを検出し、様々な属性と一緒にInsightsのデータベースにストアする。

• InsightsではそのイベントをNRQL (New Relic Query Language) を使って分析することができる

  • APMではTransaction, Transaction Errorがストアされる。
  • Transactionでは例えばデフォルト定義のものの他にユーザー定義も設定できる

• Data Explorerからマウスをポチポチするとグラフができる。NRQLも生成されダッシュボードにも追加できる。

• QueryからNRQLを実行することができる。補完も効く

  • 関数を使って集計もできる
  • NRQLでsinceをつけないと１時間前までのデータが対象
  • しきい値を設定して色を付けることもできる
  • compare withで過去のデータと比較できる
  • timeseriesでグラフ化できる
  • WHERE, LIKEも当然できる
  • FACET (ファシット）で指定した列をグループ化し、結果によってはリストで出したり棒グラフで出したり円グラフで出したりできる
  • FILTER()で複数のグラフを同時に出せる
  • HISTGRAM()でヒストグラムを出せる。FACETと一緒に使える
  • FUNNEL()でこれの人で更にこれの人は何%というものが出せる (トップページ100%, 商品ページ70%, カートページ30%, 購入ページ5%みたいな）

custom attribute

エージェントにアプリケーションソース上の任意のデータをカスタム属性として取得させ、自分のアカウントに送信させて、ダッシュボード上で利用することができる。

custom events

custom attributeと同様APIを使うかREST APIでJSONを送信。
custom attributeとは違い、テーブルを新規追加するイメージ。
※Insightsのオプション料金が発生

Data Apps

複数のダッシュボードをタブで管理できる。
キオスクモードもある。

Alerts

アラートポリシー
* インシデントプリファレンス
* コンディション
* Notificationチャネル
* 適切なものだけ通知

通知が行われるタイミング

• コンディション違反ごとではなく、インシデントごとに通知
• インシデントプリファレンス: インシデントの粒度の設定

インシデントライフサイクル

• インシデントをwebhook経由でInsights（カスタムイベント）に送り、インシデントの傾向を分析する
• ブログポスト"Sending Alerts Data to Insights"参考

しきい値について

• 固定値
• ベースライン
  • 常に値が変動するもの、非線形、曜日や時間によって傾向が変わるもの
  • 幅を設定してそれを超えたらコンディション違反
  • 時間ごとの幅のベースはNew RelicのAIが自動調整

• 外れ値

  • 上記かつ対象が複数
  • 複数のコンテナやホストが入り交ざってるときなど (この場合はfacet hostすると便利)

• ラベルを設定し、ラベルごとに共通のアラートを適応できる。

  • たとえばDevelopmentラベルとStagingでは共通のアラートを設定するなど

• REST APIでアラートの設定を自動化できる

  • Puppet, Chef, Ansibleから設定できる
  • New Relic API Explorer

インサイトとデータを組織の力にする

ハイパフォーマンス組織を目指し、インサイトとデータで約1.7倍のパフォーマンスアップを達成した話

マイクロサービスをやっていくに当たり、開発タスクの約七割がメンテナンス・バグフィックスの時間が当てられた。
なかでも原因追求にかかる時間が一番多く、生産性を下げる悩みのタネだった。
また、IoTやスマートデバイスが増えることで悪化の一方だった。

可視化のためGoogle Analytics, New Relic, Tableauを導入した。
New Relicは監視を外部化するために移行した。

CI/CDにCloudFormation, CodeDeploy, Terraform & Packer, Travis CIを使い、Prod, Staging, Dev環境をBlue / Green環境に変更した。

• より実環境に近づけるようにした
• 環境間の際をなくせるようにした

TablueauへはTAIGA, New Relic, Githubから各ETLサービスを使ってデータを入れる

急成長するZOZOTOWNのシステムリプレースメントにおけるNew Relic活用術

New Relicを使う理由 -> 明確なパフォーマンスについてのルールがなかったから。
サイト表示が0.1%遅くなると売上が1%落ちるECサイトでこれは致命的

ルールのない曖昧なチューニングから定量化された有益なチューニングに変化した
今まで間隔でしかわかっていなかったことが数値として確認できるようになった。

ルールや基準ができたので、誰でもパフォーマンスの良し悪しがわかるようになった。

Kubernetesを使っているので、スケールイン・スケールアウトに対応し、更に多数のPODの一元管理ができる必要があった。
特定のPODが配置されているノードがわかりやすく、APMとの連回も可能。

エラーでPODが落ちたとき、ノード、POD、アプリケーションのどれが悪いのかがすぐに分かるようになった。

アラートについて

アラートはSlack、緊急事態はPagerdutyを使っている。
インフラからアプリまで対応できる必要があるので、属人化しないよう情報共有と勉強会を実施している。
週替りで監視担当を分担している。

今後はビジネス・インフラ・アプリ含め一人ひとり意識するような組織にしていきたい。

全世界400万人が利用する家族アルバム「みてね」を支えるNew Relic -高度な改善を繰り返す開発チームにおけるNew Relicの役割-

• 立ち上げ期から利用しており、開発環境のエラーや課題を迅速に対応することができていた。
• 成長期ではAPMを中心にアプリエンジニアが運用文化を醸成しサービスを支えてきた
  • デイリーのヘルスチェック

• スケール期は負荷が上がるだけではなく技術的課題が増えてきた。

  • 様々な視点からインフラの課題を抽出するための分析・モニタリング
  • APM: Web/Job Queueアプリケーション視点
  • MOBILE: クライアントアプリ視点
  • INFRASTRUCTURE: 各ホスト視点
  • SYNTHETICS: APIの死活監視
  • INSIGHTS:

• SYNTETICS: 世界中のロケーションからAPIリクエストを実行しパフォーマンスを改善

• MOBILE/INSIGHTS: MOBILEで取得したメトリクスをINSIGHTSでダッシュボード化

  • 各国からの画像や動画アップロード速度

年間9300万件のサロン予約を支えるホットペッパービューティー

システム投資に対して説明責任を果たすため、サービスを健全に継続するために今の状態を把握し、品質改善の必要性を提示する必要があった

サービスに対して何を守るべきなのかを少なくとも開発チーム全体で目線合わせを行う必要がある。

スモールスタートでスタート。SRE本のレイテンシとエラーの目標値を内部で定めるところからスタート。一般論からの数値でもよいので決める。

New Relicでは各画面のレスポンスタイムとエラー状況が可視化されリアルタイムで把握できるため採用。

APM, BROWSER, INSIGHTSを利用

モニタリングの結果をもとに、サービスの企画者から開発者まで巻き込んだ意識醸成を行うことが大切。

CHECK: 定常モニタリング: アラートに現れない変化（特に機能追加案件実施後など）
DO: 定期レポート: 案件の定義や優先度の意思決定者に対して稼働状況含めたレポートを提供 (ダッシュボードから気が付きづらい過去のスナップショットからの気付きもある）
ACTION: 定例ミーティング: 開発チーム代表者が参加しレポートをもとに優先的な改善ポイントを確認。確認だけではなく改善方式について一定の議論も行っている。技術力の全体の底上げとチーム横断での品質向上も狙っている
PLAN: 案件起案: モニタリングとレポートから定量的な改善施策を起案。改善後に改めてモニタリングを行うことで改善状況を把握 -> 目に見えた品質改善が開発チームのモチベーションにも繋がる

PDCAサイクルを回すことで、意識に加えて品質改善の取り組みを加速させることができる
攻めの案件だけではなく、改善企画も多くなってきた。
事業成長に直結する企画だけではなく改善の重要性も開発者含め企画側も理解し、成長企画も改善企画も平等に判断できるようになった。

コンバージョンと品質の相関を可視化できれば開発者だけではなく意思決定者や企画者も含めて改善施策に対するモチベーション動機づけに繋がる。

システム開発に喜びと驚きの連鎖を

ウォーターフォール型とアジャイル型でどちらも良さがあり、欠点がある。両方を兼ね備えた組織が強い。
両方が存在することで安定する。
ウォーターフォール型のモード2が方向を変えながら進むべき方向性を模索する。
アジャイル型のモード１は方向性が決まったら、前輪に少し遅れて自転車や事業を真っ直ぐに力強く進める。
どちらも敬意を持って楽しくやっていくのが大切。

HRTの原則
Humility・謙虚さ
Respect・尊敬
Trust・信頼

あらゆる人間関係の衝突は謙虚・尊敬・信頼の欠如によるもの

AI(After Internet)時代の基本原則

• Compass over maps
  • 複雑かつスピードの早い世界ではすぐに書き換わってしまう地図を持つより優れたコンパスを持つことが大切
• Practice over theory

モード１とモード２を組み合わせることで創業50年の会社がAWSで表彰されたりIoTのロボットアームに製品を組みこんだりできる。

ラストマンの育成ある場所、ある分野で一番を目指す。新人でも中途でも
向いてなかったら落胆することなくピボットする。向いていたら進む。
ラストマンになることで誇りが生まれ成長できる

今後の最重要強化ポイント
UI
UX
機能要件を満たしていても使いづらかったら使われなくなる。エンタープライズもこういった流れがある。

Fun Place to Work
すべての基本だと思っている