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
22
【弥生】20250130_AWSマルチアカウント運用セミナー登壇資料
yayoi_dd
1
330
Amazon OpenSearchのコスト最適化とZeroETLへの期待 / Amazon OpenSearch Cost Optimization and ZeroETL Expectations
yayoi_dd
1
46
フロントエンドとバックエンド非同期連携パターンのセッションを見てきた話 / Talk about seeing a session on front-end and back-end asynchronous coordination patterns
yayoi_dd
0
47
reInventで学んだWebシステム運用のBadDayへの備え方 / How to Prepare for BadDay in Web System Operations Learned at reInvent
yayoi_dd
0
33
AWS reInventで感じた世界に見る生成AIの競争 / Competition in Generative AI as Seen Around the World at AWS reInvent
yayoi_dd
0
45
データの意味を適切に伝えましょう データ可視化のお手本/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
57
Other Decks in Technology
See All in Technology
クラウド関連のインシデントケースを収集して見えてきたもの
lhazy
7
940
Apache Iceberg Case Study in LY Corporation
lycorptech_jp
PRO
0
320
短縮URLをお手軽に導入しよう
nakasho
0
150
あなたが人生で成功するための5つの普遍的法則 #jawsug #jawsdays2025 / 20250301 HEROZ
yoshidashingo
2
290
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
83k
OCI Success Journey OCIの何が評価されてる?疑問に答える事例セミナー(2025年2月実施)
oracle4engineer
PRO
2
150
システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling
i125
1
320
Change Managerを活用して本番環境へのセキュアなGUIアクセスを統制する / Control Secure GUI Access to the Production Environment with Change Manager
yuj1osm
0
100
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
360
クラウド食堂とは?
hiyanger
0
110
EDRの検知の仕組みと検知回避について
chayakonanaika
12
4.9k
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
11
3.8k
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
Done Done
chrislema
182
16k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
How to Ace a Technical Interview
jacobian
276
23k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
A better future with KSS
kneath
238
17k
What's in a price? How to price your products and services
michaelherold
244
12k
Building an army of robots
kneath
303
45k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Why Our Code Smells
bkeepers
PRO
336
57k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
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 社とディスカッションしながら進めた内容と概ね一致 • 弥生が進んでいる方向が正しいことが客観的に確認できた