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 ...
Search
yayoi_dd
January 31, 2023
Technology
0
6.1k
オブザーバビリティのベストプラクティスと弥生の現状 / 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
“お客さま視点”を手に入れろ!! / Get the Customer’s Perspective!!
yayoi_dd
0
85
プロジェクト改善、まずは“ネタ出しの文化”から / Improving Projects Starts with a Culture of Idea Generation
yayoi_dd
0
83
使いにくい仕様を改善した件 / How We Improved a Difficult-to-Use Feature
yayoi_dd
0
78
弥生のQAエンジニア 品質保証活動と今後の課題 / Yayoi QA engineers, Quality assurance activities and future challenges
yayoi_dd
0
110
【弥生】20250130_AWSマルチアカウント運用セミナー登壇資料
yayoi_dd
2
3.4k
Amazon OpenSearchのコスト最適化とZeroETLへの期待 / Amazon OpenSearch Cost Optimization and ZeroETL Expectations
yayoi_dd
1
96
フロントエンドとバックエンド非同期連携パターンのセッションを見てきた話 / Talk about seeing a session on front-end and back-end asynchronous coordination patterns
yayoi_dd
0
81
reInventで学んだWebシステム運用のBadDayへの備え方 / How to Prepare for BadDay in Web System Operations Learned at reInvent
yayoi_dd
0
61
AWS reInventで感じた世界に見る生成AIの競争 / Competition in Generative AI as Seen Around the World at AWS reInvent
yayoi_dd
0
73
Other Decks in Technology
See All in Technology
敢えて生成AIを使わないマネジメント業務
kzkmaeda
2
440
Flutter向けPDFビューア、pdfrxのpdfium WASM対応について
espresso3389
0
130
第4回Snowflake 金融ユーザー会 Snowflake summit recap
tamaoki
1
280
MobileActOsaka_250704.pdf
akaitadaaki
0
120
Claude Code に プロジェクト管理やらせたみた
unson
6
3.9k
ビギナーであり続ける/beginning
ikuodanaka
3
750
KubeCon + CloudNativeCon Japan 2025 Recap by CA
ponkio_o
PRO
0
300
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
280
Delegating the chores of authenticating users to Keycloak
ahus1
0
140
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
300
2025 AWS Jr. Championが振り返るAWS Summit
kazukiadachi
0
110
いつの間にか入れ替わってる!?新しいAWS Security Hubとは?
cmusudakeisuke
0
120
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
524
40k
Testing 201, or: Great Expectations
jmmastey
43
7.6k
Documentation Writing (for coders)
carmenintech
72
4.9k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Become a Pro
speakerdeck
PRO
29
5.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Code Review Best Practice
trishagee
69
18k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
GitHub's CSS Performance
jonrohan
1031
460k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
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 社とディスカッションしながら進めた内容と概ね一致 • 弥生が進んでいる方向が正しいことが客観的に確認できた