Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
オブザーバビリティのベストプラクティスと弥生の現状 / best practices for observability and YAYOI’s current state
Search
yayoi_dd
January 31, 2023
Technology
0
5.9k
オブザーバビリティのベストプラクティスと弥生の現状 / best practices for observability and YAYOI’s current state
弥生株式会社 もくテク
AWS re:Invent 2022 参加報告会(2023/01/26)
https://mokuteku.connpass.com/event/266065/
yayoi_dd
January 31, 2023
Tweet
Share
More Decks by yayoi_dd
See All by yayoi_dd
プロンプトエンジニアリングに触れてみよう / Let's try prompt engineering!
yayoi_dd
1
32
ChatGPTによるお手軽データ分析 / Easy data analysis with ChatGPT
yayoi_dd
1
32
スクラムに出会って「できた」を実感できるようになってきた話 / Scrum makes me feel like I can do it
yayoi_dd
2
1.4k
CDKでの自動構築が超簡単で感動した話(超初心者向け) / Automated construction using CDK was easy, impressed
yayoi_dd
0
2.2k
IaCがない環境でインフラ担当じゃない人がAWS触ってみた話 / I tried using AWS in an environment without IaC
yayoi_dd
0
2.1k
CDKの実装のススメ方 / How to proceed with CDK implementation
yayoi_dd
1
2.1k
AWS初心者が苦労してCDKカスタムリソースを作った話 / AWS beginners struggled to create CDK custom resources
yayoi_dd
1
2.2k
AWS CDK 経験者が CDK for Terraform 使ってみた / I tried using CDK for Terraform
yayoi_dd
1
2.2k
Terraform v1.7のTest mocking機能の紹介 / Introducing the Test mocking feature of Terraform v1.7
yayoi_dd
2
2.6k
Other Decks in Technology
See All in Technology
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
0
190
ABEMAにおけるLLMを用いたコンテンツベース推薦システム導入と効果検証
cyberagentdevelopers
PRO
1
700
JBUG岡山 #6 WordCamp男木島の チームビルディング
takeshifurusato
0
150
さらに高品質・高速化を目指すAI時代のテスト設計支援と、めざす先 / AI Test Lab vol.1
shift_evolve
0
190
AI研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
130
VPoEの視点から見た、ヘンリーがサーバーサイドKotlinを使う理由 / Why Server-side Kotlin 2024
cho0o0
1
420
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
380
データ分析基盤を作ってみよう~設計編~
nrinetcom
PRO
1
110
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development
nologyance
0
180
AOAI Dev Day - Opening Session
yoshidashingo
2
430
[NIKKEI Tech Talk] KDDI/KAG Scrum & Community for Engineering Training
curanosuke
2
220
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
opelab
10
4.3k
Featured
See All Featured
A better future with KSS
kneath
231
17k
Art, The Web, and Tiny UX
lynnandtonic
291
20k
Become a Pro
speakerdeck
PRO
15
4.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
652
58k
Writing Fast Ruby
sferik
623
60k
Happy Clients
brianwarren
94
6.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
44
4.7k
Fashionably flexible responsive web design (full day workshop)
malarkey
399
65k
Git: the NoSQL Database
bkeepers
PRO
423
64k
Designing the Hi-DPI Web
ddemaree
276
34k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
149
45k
Ruby is Unlike a Banana
tanoku
96
10k
Transcript
LT3: オブザーバビリティの ベストプラクティスと 弥生の現状 弥生株式会社 牛尾哲朗
目次 • オブザーバビリティとは • オブザーバビリティの重要性 • オブザーバビリティのベストプラクティス • 弥生の現状
オブザーバビリティとは • システム内部の状態を推測・把握する能力のこと • 主な監視対象は以下の3つ • メトリクス • ログ •
トレース • これらをモニタリング(把握)し、問題の原因を推測する • CPUやメモリの使用率から、リソースに過不足ないか • エラーログの出力状況から、システムが期待通りに稼働している • APIの応答時間から、ストレスなく利用できているか
オブザーバビリティの重要性 • モノリシックアプリケーションからマイクロサービスへの変化 • モノリシックの監視は比較的簡単 • 単一の言語 • 単一のサービス •
単一のプラットフォーム • マイクロサービスの監視は複雑 • 複数の言語 • 複数のサービス • 複数のプラットフォーム(ECS、EKS、Lambda、etc) • 複数のAZ、クロスリージョン • 複数のデータストア
オブザーバビリティのベストプラクティス 最初に行うこと コスト最適化 アラート疲れの軽減 分断したトレースの回避
最初に行うこと • ツールやサービスの導入が必要 • AWS CloudWatch • AWS X-Ray •
New Relic • Datadog • Grafana • AWS上で運用する場合、以下のそれぞれに対して対応 • AWS管理の部分 • サービス提供者管理の部分
最初に行うこと • AWS管理の部分について • メトリクスやログについては、ほぼ自動で CloudWatch で可視化される • トレースについては、X-Ray の機能をONにすればよい
最初に行うこと • サービス提供者管理の部分について • Lambda • メトリクスについては、aws-embedded-metrics ライブラリを用いるのがよい • CloudWatch
Logs 経由でメトリクスが保存できるとのこと • メトリクスデータAPIは非推奨 • ログについては、console.log メソッドなどを用いれば CloudWatch で可視化 できる • トレースについては、X-Ray SDK を用いるのがよい • ECS / EKS • メトリクスやトレースについては、AWS Distro for Open Telemetry (ADOT) を用いて可視化するのがよい • ログについては、CloudWatch か FireLens agent を選択する • Open Telemetry の仕様で、ログはまだドラフトであるため • 将来は ADOT に一本化できるかも
コスト最適化 • マイクロサービスの場合、メトリクスの数が膨大になりがち • 例えば • モノリシックの場合、5サービス×10インスタンス=50メトリクス • マイクロサービスの場合、100サービス×10タスク=1,000メトリクス •
モノリシックでは多少コストをかけて全てのメトリクスを可視化すること ができたが、マイクロサービスの場合は現実的ではない • メトリクスではなく、ログで記録する選択肢もある • コスト効率はログの方が高い • ただ、視認性は劣る
コスト最適化 • メトリクスかログのどちらかではなく、両方を採用すべき • CloudWatch Embedded Metrics Format を用いると容易に可能 •
CloudWatch Logs から自動的にメトリクスを作成できるJSON仕様 { "_aws": { "Timestamp": 1574109732004, "CloudWatchMetrics": [ { "Namespace": "lambda-function-metrics", "Dimensions": [["functionVersion"]], "Metrics": [ { "Name": "time", "Unit": "Milliseconds" } ] } ] }, "functionVersion": "$LATEST", "time": 100, "requestId": "989ffbf8-9ace-4817-a57c-e4dd734019ee" }
コスト最適化 • メトリクスかログのどちらかではなく、両方を採用すべき • ログでフルデータを残す • 高カーディナリティの属性を除いたデータでメトリクスを作成する • ビジネス的に意味のあるメトリクスのみを作成する
アラート疲れの軽減 • 効果的なアラートのみを発砲する • KPI達成度を測定するワークロードメトリクスについてアラートを発砲する • CPU使用率とメモリ使用率が共に高い場合のみ、アラートを発砲する • どちらかだけ高い場合は問題でない可能性がある •
統計アルゴリズムや機械学習アルゴリズムを使用する • 静的閾値ではなく、動的閾値を用いる • 異常値の自動検出 • Amazon CloudWatch Anomaly Detection • 複合アラーム • Amazon CloudWatch Composite Alarm
分断したトレースの回避 • 全てのコードを一貫してトレースする必要がある • AWS X-Ray を導入しても自動ではトレースされないサービスがある • Amazon MQ
• Amazon MSK • AWS Step Functions の一部処理(Amazon ECS や AWS Batch の呼び出し等) • 呼び出し元と呼び出し先で明示的にコンテキストを受け渡すことでトレース 可能 Amazon ECS Amazon ECS Amazon MQ Trace ID: 100 Trace ID: 200
弥生の現状 • 数年前からオブザーバビリティへ力を入れ始めている • 運用中の全サービスに New Relic の導入を進めている • サーバーアプリケーションのモニタリング
• インフラストラクチャのモニタリング • リアルユーザーモニタリング • 外形監視 • など
弥生の現状 • ベストプラクティスの対応状況 • 最初に行うこと • New Relic はドキュメントが充実している •
不明点についてはサポート問い合わせで解決 • コスト最適化 • カーディナリティを意識せず、ログやトレースに情報を出力している • 重要なメトリクスについては、ダッシュボードで可視化
弥生の現状 • ベストプラクティスの対応状況 • アラート疲れの軽減 • 運用開始時は大量のアラートに悩まされた • New Relic
では柔軟なアラート設定が可能なので、試行錯誤の上で解消 • AI技術を用いた機能も充実しているので、そちらの活用も進めている • Proactive Detection(異常値の検出) • Incident Intelligence(同じ原因のアラートの統合) • 分断したトレースの回避 • 現状は未対応の個所が多数 • メッセージングサービスを利用している個所での分断が主 • 現状はユーザーからの同期通信を中心に監視しているので、あまり課題感はなかった • 非同期通信も含めて適切にトレーシングするのは今後の課題
まとめ • オブザーバビリティのベストプラクティス • 最初に行うこと • コスト最適化 • アラート疲れの軽減 •
分断したトレースの回避 • New Relic 社とディスカッションしながら進めた内容と概ね一致 • 弥生が進んでいる方向が正しいことが客観的に確認できた