New Relicで始める、.NET Applications on AWSのObservability

©2008–19 New Relic, Inc. All rights reserved
New Relicで始める、
.NET applications on AWSの
Observability
田中孝佳

©2008–19 New Relic, Inc. All rights reserved 2
Safe Harbor
This presentation and the information herein (including any information that may be incorporated by reference) is provided for
informational purposes only and should not be construed as an offer, commitment, promise or obligation on behalf of New Relic, Inc.
(“New Relic”) to sell securities or deliver any product, material, code, functionality, or other feature. Any information provided hereby is
proprietary to New Relic and may not be replicated or disclosed without New Relic’s express written permission.
Such information may contain forward-looking statements within the meaning of federal securities laws. Any statement that is not a
historical fact or refers to expectations, projections, future plans, objectives, estimates, goals, or other characterizations of future events is
a forward-looking statement. These forward-looking statements can often be identified as such because the context of the statement will
include words such as “believes,” “anticipates,” “expects” or words of similar import.
Actual results may differ materially from those expressed in these forward-looking statements, which speak only as of the date hereof, and
are subject to change at any time without notice. Existing and prospective investors, customers and other third parties transacting business
with New Relic are cautioned not to place undue reliance on this forward-looking information. The achievement or success of the matters
covered by such forward-looking statements are based on New Relic’s current assumptions, expectations, and beliefs and are subject to
substantial risks, uncertainties, assumptions, and changes in circumstances that may cause the actual results, performance, or
achievements to differ materially from those expressed or implied in any forward-looking statement. Further information on factors that
could affect such forward-looking statements is included in the filings New Relic makes with the SEC from time to time. Copies of these
documents may be obtained by visiting New Relic’s Investor Relations website at ir.newrelic.com or the SEC’s website at www.sec.gov.
New Relic assumes no obligation and does not intend to update these forward-looking statements, except as required by law. New Relic
makes no warranties, expressed or implied, in this presentation or otherwise, with respect to the information provided.

自己紹介
3
● @tanaka_733
● 仕事
○ New Relic 株式会社シニアテクニカルサポートエンジニア
○ 日本語サポート始めました
● コミュニティ活動
○ 最近はC#、kubernetes、Q#関連の勉強会で登壇
○ Microsoft MVP for Azure
● 好きなAWSサービス
○ EKS、AWS SDK for .NET

本日の目的
4
● Observabilityに興味を持ってもらう
● C#で開発できるAWSのサービスで
どのようなObservabilityを獲得できるか知る
○ New Relicの画面を例に、
どのような観測をすればよいか考えてみましょう
● C#エンジニアに
New RelicでのObservability獲得に興味を持ってもらう
○ New Relicを使う場合のメリットをご紹介します

Observability
5

Observability(可観測性)
6
● 聞いたことがある人？
● 担当するシステムで考えたことがある人？
● 自分なりに理解している人？
● 人に説明できる人？

Observabilityがなぜ注目される？
7
● システム自動化やDevOpsからSREへの流れ
○ アプリケーションの重要度の増加
○ DevOpsを推進するSREというロール
● もともとは制御理論で、システムの特性を表す言葉
○ システムの出力からある時点でのシステムの内部状態を一意にしることができる
● ソフトウェア、サービス視点では？
○ システムが運用する上で必要な内部状態の情報を取得できる状態にあること

Good to read
8
● オブザーバビリティ（可観測性）がなぜ必要だと考えるのか
● CloudNativeCon Europe 2019 Keynote: ...What Does the
Future Hold for Observability?
● Google’s Approach to Observability
● OpenTelemetry 101: What Is Tracing?

なぜObservabilityが必要か
9
● インフラ中心からアプリケーション中心へ
○ かつてはインフラをそろえるのに時間も手間もかかった。インフラ第一。
○ インフラが動けばOKから、アプリが正常に動かないとNGに。
● インフラがサービスとして利用可能に
○ AWSなどパブリッククラウドが広まる
● インフラのコード化、抽象化
○ ElasticBeanStalk, Fargate, EKS
● アーキテクチャの複雑さ
○ マイクロサービスの採用が進む
○ 迅速なサービスインは可能になった反面、監視が複雑に

クラウドネイティブの定義としてのObservability
10
● クラウドネイティブ技術は、パブリッククラウド、プライベート
クラウド、ハイブリッドクラウドなどの近代的でダイナミックな
環境において、スケーラブルなアプリケーションを構築および実
行するための能力を組織にもたらします。このアプローチの代
表例に、コンテナ、サービスメッシュ、マイクロサービス、イミ
ューダブルインフラストラクチャ、および宣言型APIがあります。
● これらの手法により、回復性、管理力、および可観測性のある疎
結合システムが実現します。（後略）
CNCF Cloud Native Definition v1.0

Observabilityの具体例
11
● レスポンスタイム、スループット

12
● Transactionごとのレスポンス、エラー率

13
● 分散トレーシング

14
● ログベース

15
● モニタリングダッシュボード

Observabilityの活用例
16
● 運用の問題に気づく、修正する
○ インフラだけでなく、サービス利用時のあらゆる問題を気づく
○ 問題に自動化した対応が可能であれば自動的に対応を行う
○ 深刻な問題(incident)が発生した場合に適切に通知する
○ 問題の対応策を提案する、調査するためにわかりやすい情報を提示する
● サービスの運用を日々改善する
○ サービスの可用性を追跡する
○ 変更による運用への効果を計測する
○ ビジネス視点でのKPIをメトリクスの一つとして監視できる

Observabilityの三(四)本柱 M(E)LT
17
● MLT = Kubecon 2019 Europe のkeynoteより
● MELT = New RelicとしてはEventも含めて考えています
• ある状態に関して集約した値＋ラベルMetrics
• ある時点で発生した事象Event
• ある時点で発生したメッセージLogs
• ある処理に関するSpanの集合Trace

Trace
18
https://github.com/open-telemetry/opentelemetry-
specification/blob/master/specification/overview.md#trace
Spanに含まれるもの
• 経過時間
• 開始時間、終了時間
• 属性のセット
• イベントのセット
およびSpanの親子関係をたどれる情報

Observabilityの将来(kubeconより)
19
三本柱のさらなる連携
新しい計測や分析
ノーインデックスなログ収集の台頭

Observabilityの標準化の流れ
20
● 従来
○ APMベンダーを中心に
各社が独自実装をしていた
● OpenTelemetry
○ OpenCensusとOpenTracingの
発展的合併
○ 各言語からのメトリクスと
トレースの取得・送信の標準化
● Prometheus
○ コンテナまわりのメトリクス
各社標準化への対応を進めている最中

.NET におけるOpenTelemetry
21
opentelemetry-dotnet
● 他の言語と比べても遜色ない進捗（に見える、多分）
● （.NETに限らずプロジェクト全体として）This autumnの予定
è来年 SDK実装完了に延期
● SDKを出すところまでがひとまずのゴール
● どのメトリクスをとるか、どこをトレースするか、は
SDKを使って実装する側の対応(になりそう？）
○ New Relicなどの既存のエージェントはこの設定をすでに持っている

SDK
OpenTelemetry DotNet の現時点での仕組み
22
計測対象の
コード
（アプリ本体）
Data collector
Collectoｒライブラリ
Collectorの実装
exporter
ライブラリ
で送信先
指定
対応サービス
Zipkin
Prometheus
Stackdriver
など
Collectorは2通り
• HTTP、Redisなどを収集するライブラリを参照
• SDKを使って自前でコードに埋め込む送信先のサービスによってExporter切り替え

AWSを使って
C#で作るサービスの
Observability
23

C# on AWSのアーキテクチャ一例
24
（C#に限らず）AWSの様々なサービスを組み合わせ可能
● EC2
● EKS
● Lambda
● ECS, ElasticBeanstalk, etc…
それぞれどのような視点で計測するかと、
New Relicの画面を可視化例として紹介します

サービス全体としてのObservability
25
● エンドユーザー視点でのメトリクスの取得
○ リアルなユーザー体験を計測する
● 合成モニタリングによる計測
○ 人工的にリクエストを生成して、定期的かつ詳細に計測する
● サービスを構成する「もの」の依存関係の把握
● コスト管理
○ 使用量がコストに直結するパブリッククラウドならでは
● ビジネス視点でのKPIの計測
è ServiceMap, 合成監視(Synthetics)、ダッシュボード

Service Mapで依存性の可視化
26

Browserで実際のユーザー体験の計測
27

Syntheticsで自動化された外部からの監視
28

ダッシュボードで柔軟な可視化
29

WebアプリのObservability
30
● スループット、レスポンスタイムなどの計測
● レスポンスタイムの詳細な分析
○ プログラムの実行時間、外部呼出しにかかっている時間
どんな呼び出しをしているかの識別
● トランザクション分析
○ トランザクションごとのスループット、レスポンスタイム
○ どのトランザクションを改善するとアプリ全体の処理が改善するか
● エラー分析
○ どんなエラーがいつ発生しているか
○ どのトランザクションと結びついているか
○ エラーの詳細

Webアプリのメトリクス
31

エラー分析
32

トランザクション分析
33

.NET Core on コンテナ（EKS、ECS）のObservability
34
● コンテナ内のWebアプリのメトリクス
● Pod単位でのメトリクス、イベント
○ CPU,メモリ
○ Podのデプロイ不可、強制終了イベントなど
○ Podとアプリのひもづけ
● Kubernetesのメトリクス、イベント
○ ノードのCPU、メモリ
○ ストレージの利用料
● AWSサービスとしてのメトリクス
○ リソースの使用量/上限
○ 使用料/予算

Kubernetesクラスタの可視化
35

AWS CloudWatchとAPM, kuberentesの紐付け
36

Lambda関数のObservability
37
● 呼出し回数、cold start回数
● CPU、メモリ è コストの直結
● エラー発生率
● ラムダ関数の構成情報
● 詳細なトレース
● 呼出し元のアプリからの分散トレーシング
● CloudWatchで取得できるものと、そうでないものがある
○ ラムダ関数対応のAPMで取得

Lambda関数
38

C# on AWS での
New Relic紹介
39

C# on AWSでのNew Relicの始め方
40
● New Relicの全体像
● AWS Integration
● New Relic各製品の紹介 (C#アプリ向け）
● 付録（後ほど必要に応じて参照してください）
○ APM Agentについて
○ Lamdba監視について
○ kubernetes監視について

New Relicを使うメリット
41
● SaaSで運用をする手間がない
○ インストールして数分でダッシュボードに表示される
● MELTをすべて1つのサービスで提供している
○ お互いの関連付けを含めて標準機能として利用できる
○ 異なるツール、サービスを組み合わせる必要がない
● すべてをまとめるダッシュボード
○ 標準ですぐに使える画面
○ ウィザード形式のChart Builder + プログラマブルなUI
● Open、Connected
○ OpenTelemetryへの対応
○ APIのZipkinフォーマット対応、Prometheus対応、fluentdからのログ受信など
New RelicのAgent以外からのデータも取り込める

New Relic とは何ですか︖︖
Pure SaaS の APM (Application Performance Management) ツールです
New Relic ３つの特徴
ü フロントエンドからバックエンドまで、アプリケーションのパフォーマンスを監視します
ü APM を SaaS で提供しています。簡単なユーザー登録とセットアップだけですぐに始められます
ü APM のパイオニアである Lew Cirne が率いる、APMのマーケットリーダー(2017年Gartner社）です
製品ラインアップ
Browser, Mobile, Synthetics: フロントエンド監視
APM, Infrastructure: バックエンド監視
Insights: アナリティクス
New Relic を導⼊すると...
ü どこでどんな問題が起きているか分かります
ü 問題の原因が分かります
ü 問題によるビジネスインパクトが分かります

Confidential ©2008–17 New Relic, Inc. All rights reserved
Lambda
New RelicによるAWS エコシステムの
フルスタックインストゥルメンテーション
AWS仮想化インフラストラクチャ
EC2
Elastic
Beanstalk
RDS,
その他 (*)
OS アプリケーション
アプリケーション
Docker
コンテナ
Infrastructure
エージェント
Cloud
Watch
New Relic コレクタサーバ（データリポジトリ、UI)
Lambda関数
APMエージェント
アプリケーション
APM
エージェント
APMエージェント APMエージェント
AWS
Integrations
ECK, ECS,
Fargate
Infrastructure
エージェント
アプリ
agent
HTML
agent
Docker
On-Host
Infrastructure
エージェント
(*) AWS Integrationでインストゥルメントできる場合と、On-Host Integrationでできる場合があります

Confidential ©2008–17 New Relic, Inc. All rights reserved
AWS 各種サービスのパフォーマンス管理が可能です
AWS Integrations リスト
ALB API Gateway Auto Scaling Billing CloudFront
CloudTrail DynamoDB EBS EC2 ECS/ECR
EFS Elastic Beanstalk ElasticCache Elasticsearch ELB
EMR Health IAM IoT Kinesis Firehouse
Kinesis Streams Lambda RDS RDS Enhanced Redshift
Route 53 S3 SES SNS SQS
VPC Flow Logs VPC
2018年12⽉現在
32種のサービスのパフォーマンス監視が可能です

AWS Integration
45
● CloudWatch APIを利用します
○ 見られる情報はCloudWatchと同じ。
● 単体で使うのではなく、別機能との組み合わせがおすすめ
○ 複数AWSアカウントまたいでのダッシュボード
○ APMなどアプリのメトリクスとAWSのメトリクスの組み合わせ
○ コストの可視化

APM
46
● .NET Framework, .NET Core両方対応
○ Windows EC2上のIISで動くASP.NET (Framework), .NET Framework, .NET Core
○ ElasticBeanstalk上のASP.NET
○ Linux EC2上のASP.NET Core
○ Windows Docker上のASP.NET
○ Linux Docker上のASP.NET Core
○ etc
● Agentを.NETプロセスのプロファイラーとして読み込ませる
■ 従来のAgentとは別に、OpenTelemetryを利用しZipkinのexporterの送信先をNew
RelicのAPIとすることで収集することも可能に

Thread Profiler
47

● OpenTelemetry(実装中)などZipkin対応のコレクターを入れて、
Zipkin exporterの送信先をNew Relicのエンドポイントにするだ
け
○ 表示されるデータはコレクター依存
Zipkin対応
48

.NET Coreラムダ関数監視
49
● betaですが、.NET Coreも対応しています
○ NuGetライブラリ追加＋ラッパー関数の作成

Infrastructure
50
● Windows、Linuxホストを監視
○ インベントリ機能でEC2関連の情報も取得可能
● Integrationにより、ホストからDB,MQなどのミドルウェアも監
視
○ RDS, ElastiCacheなどの情報をEC2ホストなどから取得可能
● Kubernetes Cluster Explorerも製品としてはこのカテゴリ
○ kube-state-metrics (kubernetes提供)を利用
○ 必要な情報を取得してNew Relicに転送するためのPodや権限を定義した
YAMLを使ってkubernetes上に展開
○ EKSなどのマネージドkubernetesも監視可能

Kubernetes Cluster Explorer
51

APMとの連携、イベントの表示
52

EKS監視ダッシュボード
53

New Relic Logs
54
● ログの収集・可視化・アラート
● CloudWatchのログをLambda pluginを使うことで転送可能
● Fluentd, Logstashなどからログを収集可能
○ C#アプリのログはアプリのロガーからfluentdの転送サーバー経由が簡単かも
○ Kubernetes上で動かす場合は専用のpluginあり
● APMやKubernetes pluginと連携して、
関連あるログを表示するメニューを提供

New Relic Logs (Logs in Context for Kubernetes Pod)
55

New Relic One
56
● すべての機能を一つにまとめて表示するUI
● New Relicのアカウントをまたいだ表示
● カスタムチャートの作成
● ReactとGraphQLを使ったカスタム可能なUI部品の作成
○ ”Programmable Dashboard”
○ GitHubですぐに使えるサンプルを提供
○ https://github.com/newrelic?utf8=%E2%9C%93&q=nr1&type=&language=

AWS コスト最適化サンプル
57https://github.com/newrelic/nr1-cloud-optimize

アラート
58
● アラートトリガー
○ メトリクスベース
○ NRQLベース
○ 異常検知 è New Relic AIとして強化予定
● 豊富な通知先
● アラート回復処置
○ Runbookによる手順書の提供
○ HTTP通知をトリガーとした回復処理の自動実行（Lambdaなど）
⾃動で報告します
異常を⾒つけて

Thank You

付録
60

.NET Framework (IIS/Windows)でのAPM
61
● MSIによるインストーラー実行でのセットアップが基本
○ インストーラーの実行が不可能な場合、
NuGetでアプリ側に配置することも可能です
● .NET Frameworkのプロファイラーに関する
レジストリーキーの設定が必要です
○ AWSではあまり見かけないですが、
PaaSのプロバイダーなどがレジストリーを強制的に設定する環境では要注意
https://docs.newrelic.co.jp/docs/agents/net-
agent/installation/install-net-framework-agent

.NET Core でのAPMインストール
62
● いくつかの方法があるのでお好みで
○ インストーラーの実行(Windowsのみ、Frameworkと同じインストーラー）
○ パッケージマネージャーの使用（Linuxのみ、Linuxでの推奨）
○ Zipダウンロードして展開（Windowsのみ、Windowsでの推奨）
○ NuGetでアプリ側に配置（Windows, Linux）
● 環境変数をセットします
○ .NET Core CLRが使うプロファイラーのものと
ライセンスキー、アプリ名などNew Relic Agent用のもの
agent/installation/install-net-core-agent#install-zip-file

.NET on DockerでのAPMインストール
63
● Windowsコンテナ、Linuxコンテナともにアプリのコンテナに
agentを仕込む
● インストール操作をコマンド化してDockerfileに記述
○ ドキュメントにサンプルDockerfileがあるので
必要な部分を抜き出してコピペ可能
agent/installation/install-docker-container

New Relic APMをより使い倒すために
64
● アプリ名は複数つけられます。ラベルを付けられます
● 見たい単位でトランザクションが分かれていることを確認
○ １つのコントローラーで複数機能へ振り分けて別トランザクションにしたい
è New Relicのライブラリを参照して SetTransactionName を指定
● トランザクション詳細で経過時間が見られないところがある
○ XML設定ファイル or APIでカスタムインストルメントに追加
● カスタムイベントを活用して、KPIや詳細の調査に
https://docs.newrelic.co.jp/docs/apm/new-relic-apm/guides/new-
relic-apm-best-practices-guide

Browserのインストール
65
● .NET Framework agentではデフォルトでBrowser用のJavaScript
をHeadタグの中に挿入します
● .NET Coreの場合は、RazorなどViewを生成する部分で
New Relic APM AgentのAPIでうめこむJSを取得できる
● もしくは、JavaScriptコードそのものをコピーペーストで配置
https://docs.newrelic.co.jp/docs/browser/new-relic-
browser/installation/install-new-relic-browser-agent

Lambda monitoring (.NET Core)のインストール
66
● AWS Integrationの有効化＋Lambda監視の設定
● GitHubで提供されているスクリプトを使って
ログ転送用ラムダ関数の作成などを行う
○ 数コマンド程度
● .NET Coreのラムダ関数にNuGetを追加して、
ラッパー関数の作成
https://docs.newrelic.co.jp/docs/serverless-function-
monitoring/aws-lambda-monitoring/get-started/enable-new-
relic-monitoring-aws-lambda

New RelicによるLambdaモニタリングの仕組み
New Relic ラッパー
CloudWatchログ
ログ収集(Lambda関数)
New Relic
(ログ収集機能)

Kubernetes pluginのインストール
68
● kube-state-metricsをインストール
○ kubernetesが提供しているmetricsコレクター
● kubernetes用のinfrastructure agentをインストール
○ kubernetes上のコンテナとして動作するagent
● OpenShiftなどkubernetes製品、サービスもサポート
○ ノードホスト上での操作が不要なため、
マネージドサービスでも動作可能

New Relic Logs
69
● Fluentd, Fluet Bit, Logstash, Kubernetes, AWS Lambda(Cloud
Watchログの転送）をpluginとして提供
● 汎用的にはHTTP API
● .NET アプリのログは現状はFluentdなどを介して転送
kubernetes上の場合はkuberenetes pluginで可能
https://docs.newrelic.co.jp/docs/logs/new-relic-logs/get-
started/introduction-new-relic-logs

New Relic One Programmability
70
● GraphQL とReactを使ってプログラミングすることで
New Relic OneのUI部品を作成可能
● 作成した部品は公開できる
● いくつかの実用できるサンプルをGitHubで公開
https://docs.newrelic.co.jp/docs/new-relic-one/use-new-relic-
one/build-new-relic-one/new-relic-one-build-your-own-custom-
new-relic-one-application

New Relicで始める、.NET Applications on AWSのObservability

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à New Relicで始める、.NET Applications on AWSのObservability

Similaire à New Relicで始める、.NET Applications on AWSのObservability (20)

Plus de Takayoshi Tanaka

Plus de Takayoshi Tanaka (20)

Dernier

Dernier (8)

New Relicで始める、.NET Applications on AWSのObservability