Datadog Live Tokyo 2024 scraps

https://www.datadoghq.com/ja/event/datadoglive-tokyo202407/
2024/07/30 JPタワー東京 4Fカンファレンス 14:30~

ミスミのグローバル事業を加速させる基幹システム刷新とオブザーバビリティの構築

株式会社ミスミ
NEWTON推進本部
力田 章 様

状況

• 八千垓の製品を管理 システム泣かせ
• 14カ国ECを展開
• 基幹システムの刷新 プロジェクト名 NEWTON

NEWTON

30年利用していた機関システムの刷新
ECの拡大に耐えられないのでマイクロサービス化が狙い

• 2016 従来の期間システム ベンダーロックイン
• 2017~2019 クラウド移植
• 2020マイクロサービス

利点

• API連携で依存性が低下
• アジリティアップ
• 生涯耐久性

問題

• 管理が複雑
• 27サービス、1000API

datadogの課題

• ログ保管コスト増加
• 過敏な通知
  TAMと最適化に向けて対応中

活用事例

• ダッシュボードで会話
• 事業コアメンバーと開発メンバーが監視
• プライベートロケーションでの死活監視

SDV 実現に向けた Honda のコネクテッド領域における挑戦と取り組み

野川 忠文 様
本田技研工業株式会社
電動事業開発本部 BEV開発センター ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部長

世界一のパワーユニットメーカー

• 世界で初めてカーナビ開発
• 2013年AWS導入
• 2020年Datadog導入

導入課題

• アプリ側のエラー検知
• 監視が複雑
• 初動対応の遅れ

Dash情報

• LLMオブザーバビリティ
• ログワークスペース
• agentless scannong
• live debugger
• incident response
• datadog on call
  obseve secure act

オブザーバビリティを DIY する : Datadog を活用したカインズの挑戦

岩間 俊樹 様
情報システム事業部 ソリューションアーキテクチャ部 システム運用G

オブザーバービリティへの取り組み

• ボトムアップ

ハードル

• 開発者へのメトリクス、ログ、APMの実装の許可

解決策

• デモもしながら導入
• 5システム、10チーム
• ステージングのみ

パネルセッション

モデレーター
萩野 たいじさん
Datadog Japan合同会社
シニア デベロッパー アドボケイト

パネリスト
鹿野 市郎 様
東芝デジタルソリューションズ株式会社
デジタルエンジニアリングセンター マネージドサービス推進部 フェロー

大木 竜勝 様
freee株式会社
エンジニアリング基盤本部SRE部・マネージャー

菅野 滉介 様
合同会社DMM.com
デジタルコンテンツ開発本部 動画配信開発部 動画SREチーム チームリーダー

近藤 健司 様
株式会社リクルート
プロダクト統括本部 プロダクト開発統括室 プロダクトディベロップメント室 販促領域プロダクトディベロップメント５ユニット(まなび) 教育支援小中高プロダクト開発部 部長

トピック

パフォーマンスとユーザーエクスペリエンス

メトリクスを活用したリソースやあインフラコストの最適化

• 継続的な監視による特定時間のスパイクを監視。
• リソースをうまく活用できるようにインフラを整備している。
• ダッシュボードはデイリー用とそうでないものを分けている。
• デイリー用は必ず見る。
• コストはチームで監視できるようにしSREに聞かなくても判断できるようにしている
• 大きな組織ではサイトがおおい。標準化が必要にある。

Notebookの活用による効果

• 動画配信によってスパイクの仕方が違う
• メトリクスを振り返るときにnoteookを活用
• テンプレートが使えるのでイベント規模、コメントなどを記録
• 誰でも共通のナレッジを作り、毎度ブラッシュアップしている
• データをロストしてもNoteBookにはスナップショットの機能があり画像を記録できる
• 時系列を変えた表示やメッセージの共有などはNoteBookの方が優れている
• インシデントレスポンス、ケースマネージメントのNoteBook
• 多数のプロダクトのアラートを貼り付けて週に共有したりしている
• Jsonでエクスポートして、マージしたりできる
• アラートを見ることも重要だが減らすことは重要

SLOの導入・活用はどこまでできてる

• 各マイクロサービスごとにSLOを設定
• サービス立ち上げ時にデザインしてしまうTraformを活用
• 主要サービスに入れているがアクションに繋がらない
• エンジニアだけで進めていてもアクションに繋がらない。機能開発が優先されるから
• アラートがなっても優先度が上がらないので閾値を下げてしまう
• 信頼性が差あっているからアクションするに変えていきたい
• 新規サービスではエンドユーザーへの機能追加が優先られる
• apiがエラーでもhttpレスポンスが200を返すことがある
• メトリクスベースで評価する機能が実装された
• インフラチームのSLOはサーバーの死活のみ。求められるSLOは100%が求められる
• SLOを99.9で設定しても、求められていることは100に変わりはない
• SLO、SLIがある。何の指標で数値を決めるか
• 決めた指標は更新していくことが重要
• SLOは開発者だけがみていて仕方がない
• 払い出したユーザーの活用を可視化したい

SRE、インフラ周りと開発メンバーとの役割の責任分解点

• アプリチームが多い。インフラの方が少ない
• インフラチームはアプリレイヤーに入らなければいけない
• 運用よりのおブザーばビリティは開発がはのフェーズになっている
• アプリもメトリクスを見る
• フロントが見ないケースもある。どちらかというとインフラのフェーズ
• 完全にインフラをフロントを設計しているわけではない
• インフラチームがうまく抽象化したレイヤーをアプリチームが使うことはある