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
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
340
Claude Code に プロジェクト管理やらせたみた
unson
6
4k
KubeCon + CloudNativeCon Japan 2025 Recap
ren510dev
1
380
United airlines®️ USA Contact Numbers: Complete 2025 Support Guide
unitedflyhelp
0
310
スタートアップに選択肢を 〜生成AIを活用したセカンダリー事業への挑戦〜
nstock
0
170
Glacierだからってコストあきらめてない? / JAWS Meet Glacier Cost
taishin
1
160
さくらのIaaS基盤のモニタリングとOpenTelemetry/OSC Hokkaido 2025
fujiwara3
3
440
Getting to Know Your Legacy (System) with AI-Driven Software Archeology (WeAreDevelopers World Congress 2025)
feststelltaste
1
130
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
190
品質と速度の両立:生成AI時代の品質保証アプローチ
odasho
1
340
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
460
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Writing Fast Ruby
sferik
628
62k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Adopting Sorbet at Scale
ufuk
77
9.5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
A Tale of Four Properties
chriscoyier
160
23k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
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 社とディスカッションしながら進めた内容と概ね一致 • 弥生が進んでいる方向が正しいことが客観的に確認できた