Observability Meetup #2 に参加して New Relic の活用事例をがっつり聴いてきた #observability

はじめに

みなさん、観測してますか！（挨拶

New Relic 社の主催する Observability Meetup、9 月に行われた第 1 回に続き第 2 回目が行われたので参加してきました。今回は真新しい Slack Japan さまのオフィスが会場です。

Observability Meetup は New Relic ユーザを主な対象に「オブザーバビリティ（可観測性）」というテーマをもとに話し合ったり、知識経験を共有したり、同じロールの人々とつながりを作ったりする会です。
第 2 回は Slack Japan 様の最高立地オフィスをお借りして、名刺管理サービスで著名な Sansan 様でのパフォーマンス改善ストーリーや、Slack 様とのユニークなインテグレーション、New Relic One の新しい開発機能を使ったダッシュボード開発事例など初心者から高度活用までを含めたストーリーラインナップでお送りいたします。

なお、第 1 回のレポートはこちらとなります。

アジェンダ

  • 恒例 New Relic クイズで学ぶ新機能 (景品強化編)
    • 松本 大樹 氏, CTO - New Relic
  • 速さは機能！国内最大級のビジネス SNS を支えるパフォーマンスチューニング！
    • 藤井 洋太郎 氏, Eight 事業部 Platform Unit Leader / Engineering Manager - Sansan
  • New Relic in Slack for real-time observability
    • 瀬良 和弘 氏, Partner Engineer - Slack Japan
  • SaaS 型車両管理ソリューション"Cariot"に稼働状況を顧客提供する機能を New Relic で開発した話
    • 佐藤 正士 氏, 事業開発室長 クラウドインテグレーション事業部 - FLECT
  • 告知＆懇親会

恒例 New Relic クイズで学ぶ新機能 (景品強化編)

  • スピーカー：松本 大樹 氏, CTO - New Relic

普通の新機能紹介じゃつまらないですよね。そこで恒例の New Relic クイズに新機能紹介を組み合わせてみました。目玉景品は New Relic 小型ドローン (予定) です。

予定は決定でした！　New Relic 社員向けのノベルティのなかでは最も高額のものだそうです。太っ腹ですね！

それ以外にも、iPhone 充電器や Slack 社・ Sansan 社からの豪華ノベルティ（タンブラーやゴルフボールなど）も景品となっていました。

  • New Tech Members の紹介
    • 清水さん、齊藤さん、大谷さん
    • 今日の懇親会にもきている

問 1 : New Relic が 2020 年に最も力を入れるであろう領域は？

  • AIOps
    • デモ
    • 何かアラートがでたら、その対象が示すグラフと同じ傾向の他のグラフも探し出してサジェストをくれる
    • -> 因果関係の把握から Root Cause への到達が速くなる
    • 役に立ったか Y/N で返答 -> 賢くなっていく
  • 他の選択肢（株主アピール、年功序列）は「そうなったら終わり」と思ってる

問 2 : 今年 9 月に GA 対応した AWS の Serverless 関連のサービスは？

問 3 : 今年 9 月の発表で一番人気だった新機能は何でしょう？

  • 3 択
    • Serverless Lambda 対応
    • Programmable
    • Logs in Context <-正解
  • 登壇者（松本さん）の主観
    • k8s の pod をクリックしてログが見られる機能への食いつきが良かった

問 4 : New Relic が Observability として柱にしている 4 つの概念は？

  • MELT
    • Metric（数値）
    • Event（有意イベント）
    • Log（非正規テキスト情報）
    • Trace（分散トレーシング）
  • New Relic は全方位で対応していく

まとめ : New Relic の目指しているもの

  • ミッション：ソフトウェアをより完璧なものにする！

速さは機能！国内最大級のビジネス SNS を支えるパフォーマンスチューニング！

  • スピーカー：藤井 洋太郎 氏, Eight 事業部 Platform Unit Leader / Engineering Manager - Sansan

法人向け名刺管理サービスでもおなじみの Sansan が手がける個人向け名刺アプリ "Eight"。そのシンプルで高速なパフォーマンスチューニング方法をお話いただきます。

ほぼ同じ内容のブログ記事もすでにあるとのことです。

  • Eight
    • 名刺でつながる、ビジネスのための SNS
    • データは AI と手入力　99%の精度
    • 国内で行われる名刺交換の 10%以上をデータ化
    • Lite 版の機能もリリースしている
    • 採用サービスもリリースしている
  • 構成
    • クラウドは AWS
    • マネージドサービスをフル活用している

  • 今日の話のメインは APM
    • パフォーマンス改善は New Relic がないと何も出来ないくらい
    • APM のダッシュボードが常に表示されている
  • Mobile
    • インドなど通信環境が劣悪なところのモニタ
  • APM
    • マシンに余計なミドルウェアを入れる必要がない
    • Lite でも概要は充分把握可能
    • 本番環境は詳細をみたいので Pro を入れる（AZ に 1 台ずつ）
  • Agent を有効にすると、CPU 利用率が 5〜10%ほど上がる傾向
    • 全てで有効化するのは良くない
    • AZ ごとに 1 台ずつ入れている
  • DynamoDB をつかって Agent が有効になるインスタンスを制限している
    • リクエスト数 x レスポンスタイムでオートスケーリングしている環境
    • 数分程度 Agent が動いていない時間もできる（インスタンス入れ替え時など）
    • -> 数分程度なので許容している

  • 各 AZ に 1 台 Agent を配置することで
    • リージョン・ AZ ごとの異常検知が可能
    • 費用も最適化でき、持続可能な状態
    • 無理なく、最大限活用することが大事
  • パフォーマンスチューニング
    • メインテーマ
  • パフォーマンス改善
    • アーキテクチャ変更（効果大・工数は大）
    • アプリケーションコード改善（工数小・効果も小）
    • ほんとうに？
  • アプリコードの改善だけでも大きな効果がある
    • そういうタイミングがある
    • ファーストフェーズ
    • 直したらすぐ効果がでる
    • とはいえ、越えられない壁はどこかにある

  • 効率的なチューニング方法
    • 処理量が多い機能、遅い機能を中心に
    • ひとり 1 ヶ月で全体の 20%高速化

  • 処理量が多い機能
    • 1 件 1 件の処理は比較的速いが、ちりも積もって遅くなる
    • 20%をしめる機能ひとつを二倍高速にすれば、全体の処理量の 10％を改善できる
    • New Relic で簡単に可視化
  • 遅い機能
    • 遅い機能は本番環境でのみ顕在化することが多い
    • NR の平均/Max レスポンスタイムで抽出
    • ヘビーユーザ向け、管理機能など、普段では気づきにくい機能を改善
  • ボトルネックを探す
    • 繰り返し行っている処理はないか？
    • いわゆる「N+1 問題」となっていないか？
    • ループしている処理は改善しやすい、効果が大きい
    • Controller の処理の大部分はループだったりする
  • RDB
    • テーブル設計で丁寧に正規化すればするほど N+1 問題を意識する必要がある
  • キャッシュストア
    • キャッシュいれただけで速いが、良く見たらめっちゃコールしてた（というケース
    • 意外と盲点になる
    • 新規コネクション（ハンドシェイク）のオーバーヘッド
  • Elasticsearch Service
    • タグ付けしてすぐ検索したい、というニーズで Indexing をリアルタイムにやってる
  • 効果
    • 企業ユーザ向けの検索ページが遅すぎたことに New Relic で気付けた
    • サーバコストを 10%〜20%削減出来た
    • 某企業の担当者さまからフィードバック
  • まとめ：速い、は、伝わる
    • 機能開発者ではできないところを SRE 担当者がやろう
    • 速さは機能！

経験に裏打ちされた、非常に濃いお話でした！
MC を務めておられた New Relic 佐々木さんが「お手本のような使い方」「『速さは機能』を New Relic でも使わせてもらいたい」とコメントされていたのが印象的でした。

個人的には有料のエージェントをサンプル的に導入するという話と、それを DynamoDB で管理しているというところが興味深かったです。
なお後ほど懇親会でも話を伺ったのですが、インフラストラクチャの監視としては Mackerel を利用している（使い分けている）とのことでした。

New Relic in Slack for real-time observability

  • スピーカー：瀬良 和弘 氏, Partner Engineer - Slack Japan

Slack が標準で提供する New Relic 連携についてのご紹介に加え、標準連携がカバーしていないようなユースケースに New Relic と Slack 双方の API を活用する実装例についてお話いただきます。

  • 会場内へ簡単なアンケート：
    • Slack 使っているひと -> ほぼ全員
    • New Relic->Slack 連携している：20%程度
    • 標準のコネクタ：その半分
  • New Relic アプリ

  • カスタマイズしたかったら Zapier を使うといい
  • Slack に Home っていうタブ機能ができた
  • これを使えば、New Relic のダッシュボードを Slack 上に作成することが可能

  • Slack アプリを New Relic で監視
    • アプリは Heroku で動かしている
    • Node なので Agent を有効にするだけ
  • コードは公開している。実際に動かしてみてください

ちなみに瀬良さんは、3 年前に re:Invent でもらったという「data nerd」の T シャツ（New Relic ノベルティ）を着ての登壇でした。

SaaS 型車両管理ソリューション "Cariot" に稼働状況を顧客提供する機能を New Relic で開発した話

  • スピーカー：佐藤 正士 氏, 事業開発室長 クラウドインテグレーション事業部 - FLECT

FLECT が提供する Saas 型車両管理ソリューションで性能監視ダッシュボードをお客様の信頼獲得のために開発し公開している技術的背景とそのカスタマートラストについてお話いただきます。

IoT システムの基本

  • データ量が多い
    • 相手が機械なので容赦がない
    • 全体 1 億レコードあっても、特定の 1 レコードがクリティカルになる場合も
  • 相手は Thing
    • 話せない、意思がない、きちんとインテグレーションしないと動かない
    • 問題が静かに発生、知らずのうちに傷口が広がる
  • ->モニタリングが重要
  • 連携システムが多い
  • 業務利用が多い

解決したい課題

  • システム障害の影響範囲を早期に特定したい
    • 適切にあやまりたい
  • 顧客に正しく「御社は正常稼働中」をアピールしたい
  • 障害が起きたシステムを使ってない顧客には謝らなくて良い

  • 障害が起きても、その時間誰も使っていなければ謝る必要はない

New Relic の使い方

  • ミニ Cariot を構築して実験
  • New Relic の Python エージェントの設定
    • ini ファイルを変更して 10,000/分まで送信するように
      • default = 1,000
      • 10,000 がハードリミットとのこと（undocumented）
    • カスタムアトリビュートをつけてまとめて送信する（データの調整
  • New Relic の制限があるので半集計して送信する
  • NRQL
    • INSIGHTS を使ってのデモ
    • New Relic はクエリのレスポンスが非常に速い
    • 理由は？ >New Relic
      • （なぜなら NRDB が世界最速だからです。速い DB である理由は秘密です、とのこと）

  • まとめ
  • これから↓

「Car + IoT = Cariot」というネーミングはうまいですね！　IoT ということで、桁違いの規模を扱うにはいろいろと工夫があったという興味深いお話でした。
なお New Relic + IoT の事例としては国内初とのことです。

告知＆懇親会

Observability Meetup はNew Relic Meetupと名前を変えて、次回は 1 月末に目黒にて行われる予定との告知がありました。こちらも楽しみですね！

PR満足度98%