Observability Meetup #1 に参加して性能監視・可観測性の重要性と New Relic の新機能を聴いてきた #observability

過日 9/12、パフォーマンスモニタリングの雄である New Relic が主催の Meetup が開催されました。ここ最近のキーワードである「可観測性 (Observability)」について、その背景や事例を交えたセッションと、9/17 深夜発表予定の New Relic 新機能も先出し紹介を聴いてきました。

セキュリティ製品特集

#レポート

#イベント

#勉強会

#New Relic

#監視サービス

渡辺聖剛

2019.09.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

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

システムの監視（モニタリング）は昨今、その軸足が「死活監視」や「リソース監視」から「性能（パフォーマンス）監視」に移ってきています。それは何故でしょうか？
そしてここ最近台頭してきた「可観測性（Observability）」とはどういう意味でしょうか？

New Relic 社の主催する Observability Meetup が先日開催されました。GA technologies 社の事例と、この分野の第一人者である Google の山口氏による背景の解説、そして New Relic が今月以降リリースする予定の新機能についてのセッションを聴いてきましたのでレポートします！。
自分の中で前述の答えがふわふわしていたのですが、これらのセッションによって具体的に落ちてきた感じがします。

なお、すでに運営側より公式のレポートブログが上がっていますので、そちらもあわせてご覧ください。

Observability Meetup (New Relic ユーザー会) 第1 回を開催しました

会場には、ノベルティを配布するテーブルも用意されていました。靴下のノベルティは珍しいですねｗ

Observability Meetup #1

Observability Meetup - connpass

Observability Meetup #1

Observability Meetup は New Relic ユーザを主な対象に「オブザーバビリティ（可観測性）」というテーマをもとにオフラインで話し合ったり、知識経験を共有したり、同じロールの人々とつながりを作ったりする会です。

とあるように、主催は New Relic 社ではありますが、ミートアップはあくまで「可観測性」がテーマとなっています。¹
今後定期的に開催予定とのことなので、今回参加出来なかった方も、興味があれば次回以降参加してみてください！

なお当日のアジェンダは下記のようになっておりました。

17:00 New Relic からのご挨拶 / 松本大樹氏, CTO - New Relic 株式会社
17:05 SRE チームの取り組みについて / 中村郷史氏, SRE Lead - GA Technologies
17:15 What is "Observability"? / 山口能迪氏, Developer Advocate - Google
17:55 New Relic One + 最新機能のご紹介 / ハリー日吉氏, Solution Consultant - New Relic 株式会社
18:00 SUSHI & SAKE （懇親会）

New Relic からのご挨拶

まずは New Relic 株式会社の CTO、松本氏からのご挨拶と、New Relic の紹介を兼ねたクイズ大会がありました。
商品は New Relic オリジナルのワイアレスヘッドフォン！　社員でも簡単には入手できない代物とのことです。

出題された問題は以下のとおり：

Q : New Relic の社名の由来は？
- （せっかくなのでここでは正解は書きませんが、興味のある方は Wikipedia の英語版の記事を読んでみて下さいｗ History の第一段落目に書いてありました）
Q : 「22 億」とは何か？
- New Relic に毎分インジェストされるイベントとメトリクスの合計
- 他にも：
  - 毎秒 1,500 万超のメッセージ
  - 毎分 3,000 億超のクエリ
  - 4PB 超の SSD ストレージ
  - （恐らく）世界最大の Apache Kafka クラスタを運用
Q : New Relic がバックエンドに持つデータベースの名前は？
- New Relic Database
- 今後 OpenTelemetry 対応を計画
- 上述の数字のイベントを捌いたうえで、規模拡大しても大丈夫な備えがある

それから、 New Relic 社としてのメッセージが届けられました：

New Relic のミッション
- A More Perfect Internet (Software)
- インターネット（ソフトウェア）をより完璧なものにする
New Relic One
- 業界最大の “Observability = 可観測性” プラットフォーム
日本での活動を加速
- 2018/08 日本法人の設立
- 2019/09 日本語の公式ブログ開始
- 2019/09 日本語テクニカルサポート開始
- 日本法人の人員増強（絶賛ハイヤリング中）

GA technologies

続いて GA Technologies 社の SRE Lead である中村郷史氏から、同社において SRE の働きと、そこに APM (New Relic) がどのように役立ったかのプレゼンテーションが行われました。

株式会社GA technologies -ジーエーテクノロジーズ

GA technologies では New Relic を 7 年使っている
- APM メイン
- 最近は INFRASTRUCTURE も使い出した
同社のこと
- 売り上げも従業員数も増えている
- 不動産業界のサービス
- アナログな不動産業界をテクノロジーで変える
- ビジネスモデルは Amazon に近い？
  - 場を提供しながら在庫を持ち、配送まで行う、という一気通貫性が似ている
- RENOSY (リノシー)
  - https://www.renosy.com/
- 不動産業だけでなく、その周囲にも進出
同社における SRE のとりくみ
- 1 年たって「そろそろインフラ周りなんとかしよう」-> SRE チーム発足
監視構成の見直し
- 原因が特定できない -> リッチなインスタンスに替えてパワーでなんとかする
- コストがつらい
CloudWatch で頑張っていた -> Datadog -> New Relic
- グループ会社のイタンジが New Relic をごりごり使っていた
- 似たようなツールを複数使うよりはひとつにそろえる方向 -> New Relic へ
- Datadog Logs への移行は様子見中
  - New Relic にも Log 機能が来るし！
- APM には New Relic を使用する
開発者にパフォーマンスを意識してもらうための施策
- 社内の「インフラが見るツールじゃないの？」という意識を変える
- 成果 -> ブログが公開されている (本日！)

New Relic を使って、アプリ API の応答速度を 10 倍早くしました - GA technologies Tech Blog

What is Observability

続いて、Google にて Developer Advocate を務められておられる山口能迪氏から、「可観測性（Observability）とは何か」についてのセッションが行われました。

オブザーバビリティは現代になぜ重要視され始めたのか？SRE Book の発祥でもある Google でオブザーバビリティ領域を担当さえれている見地から歴史的な背景踏まえその考え方をお話いただきます。

オブザーバビリティ？
- 監視？　モニタリング？　APM？
- 何かしらのメトリクス/ログでシステムが正常に動作しているのか否かを知りたい、という需要がある
概要として以下の4項目

手法
- 手動から自動へ
- 実現したいこと
  - オペレーション数削減
  - 再現性の向上
  - アーキテクチャ最適化
- 自動化に伴った新たな需要
  - 自動プロセスそのもののコスト
- モジュール疎結合化の流れ
  - 依存関係増 = ビルドとデプロイの時間増
  - なるべくサービス単位に粒度を小さくしたい、という需要は前からあった
実行環境の変化
- 調達・置換コストの削減
- ハードウェア（実機） -> VM（仮想マシン） -> コンテナ
- コンテナ環境のフルマネージド化
- インフラがより ephemeral（短命、使い捨て可能）になっていった
システムがちゃんと動いていることが見たい
- （インフラよりも）アプリをみるのが重要になってきている時代
SRE = DevOps の実践方法
- システムの信頼性のために方針をもって DevOps を行うこと
- システムの信頼性を向上させるために
  - 意思決定にデータを用いる
  - 運用の課題をソフトウェアエンジニアリングで解決
SLI・SLO・SLA
- Service Level Indicator
  - 必要な指標
- Service Level Objective
  - 目標値
  - SLI + 目標
  - SLO 100%は意味がない
- Service Level Agreement
  - SLO + 規約
- エラーバジェット
  - 許容可能なエラー率
  - 100% - SLO = システム改善に使える時間
ここまでの流れ
- アプリの重要度が増した
- データが最重要になった
Observability
- 1960 年くらいから制御理論で使われていた
- システムが、その出力から、内部状態を観測できるようになっていること
- IT システムにおいて、システム運用上判断に必要な情報が取得できる状態であること
- システムの属性
  - テスト、パフォーマンス、使い勝手と同じ必要なデータの三本柱
- ログ・トレース・メトリクス
- ランタイムだけでなくアプリケーションも観測する
（ログについての話は今回は省略）
分散トレース
- 複数のサービスにまたがったトレース

プロファイリング
- 性能ボトルネックの発見
ログベースメトリクス
ダッシュボード
各種モニタリング SaaS の活用
- 目的は監視であって、監視機構の運用ではない
- システムの運用点が増える = 不安点が増える
- できるだけ自分たちで運用するところを減らすのが良い・監視に集中
- ニーズに合わせた選択利用を
  - プラットフォーマ寄り（GCP なら Stackdriver など）
  - 独立系（ New Relic ）

New Relic One ＋最新機能のご紹介

最後に New Relic 株式会社の Solution Consultant、ハリー日吉氏より、今後予定されている New Relic の新機能について、デモを交えつつのご紹介がありました。

なおこれらは、当時は未開催だった Futurestack 19 の情報先だしとのことでした。
今ではもう開催されて情報もでてきているので、興味のある方はご一読ください。

FutureStack 19: Introducing New Capabilities for New Relic One

New Relic One とは
- 既存の NR のサービスに追加
One とは
- 複数のアカウントをひとつに
- 複数の監視対象をひとつに
- 複数のデータソースをひとつに

複数のアカウントをひとつに
- Quick find
  - 複数アカウントをまたがって横断的に検索
- Distributed tracing
  - 全てのアカウントを横串に分散トレーシング
- Dashboard
  - 一つのアカウントに閉じないダッシュボード
- Chart builder
  - イベントもメトリックも
複数の監視対象をひとつに
- サーバもアプリもフラットに
- 関連性を見る
- Entity explorer
  - エンティティ = 観測単位
  - 特定のサービスから、依存しているサービスをたどれる・関係性からピックアップしていく
複数のデータソースをひとつに
- データ収集方法も増える
- あらゆる API から収集されたデータを寄せる
- Logs
  - 現時点では、ログをそのまま流し込むシンプルなもの
- New Relic Metric
  - Introducing New Relic Metrics API and Traces API
- Programmable platform (custom application)
  - New Relic そのものをカスタマイズ