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
弥生のQAエンジニア 品質保証活動と今後の課題 / Yayoi QA engineers, Quality assurance activities and future challenges
yayoi_dd
0
30
【弥生】20250130_AWSマルチアカウント運用セミナー登壇資料
yayoi_dd
1
450
Amazon OpenSearchのコスト最適化とZeroETLへの期待 / Amazon OpenSearch Cost Optimization and ZeroETL Expectations
yayoi_dd
1
47
フロントエンドとバックエンド非同期連携パターンのセッションを見てきた話 / Talk about seeing a session on front-end and back-end asynchronous coordination patterns
yayoi_dd
0
48
reInventで学んだWebシステム運用のBadDayへの備え方 / How to Prepare for BadDay in Web System Operations Learned at reInvent
yayoi_dd
0
39
AWS reInventで感じた世界に見る生成AIの競争 / Competition in Generative AI as Seen Around the World at AWS reInvent
yayoi_dd
0
46
データの意味を適切に伝えましょう データ可視化のお手本/Conveying the Meaning of Data Appropriately: Exemplary Data Visualization
yayoi_dd
0
57
「失敗」から学ぶこと ~ソフトウェア開発と失敗の歴史~/Learning from 'Failures': The History of Software Development and Failures
yayoi_dd
0
56
ソフトウェアアーキテクチャーの基礎 エンジニアリングに基づく体系的アプローチ/Fundamentals of Software Architecture: A Systematic Approach Based on Engineering
yayoi_dd
0
58
Other Decks in Technology
See All in Technology
エンジニア主導の企画立案を可能にする組織とは?
recruitengineers
PRO
1
280
IAMのマニアックな話2025
nrinetcom
PRO
6
1.3k
データベースの負荷を紐解く/untangle-the-database-load
emiki
2
540
Amazon Q Developerの無料利用枠を使い倒してHello worldを表示させよう!
nrinetcom
PRO
2
120
LINEギフトにおけるバックエンド開発
lycorptech_jp
PRO
0
390
ABWG2024採択者が語るエンジニアとしての自分自身の見つけ方〜発信して、つながって、世界を広げていく〜
maimyyym
1
190
AWS Well-Architected Frameworkで学ぶAmazon ECSのセキュリティ対策
umekou
2
150
IoTシステム開発の複雑さを低減するための統合的アーキテクチャ
kentaro
1
120
EMConf JP 2025 懇親会LT / EMConf JP 2025 social gathering
sugamasao
2
200
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
17
45k
サバイバルモード下でのエンジニアリングマネジメント
konifar
8
1.8k
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
230
Featured
See All Featured
Designing for Performance
lara
605
68k
How to Think Like a Performance Engineer
csswizardry
22
1.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
Product Roadmaps are Hard
iamctodd
PRO
51
11k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
KATA
mclloyd
29
14k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
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 社とディスカッションしながら進めた内容と概ね一致 • 弥生が進んでいる方向が正しいことが客観的に確認できた