リアーキテクチャから Datadog 導入へ 〜動かす基盤の次は、見る基盤を整える〜

Transcript

1. リアーキテクチャから Datadog 導⼊へ 〜動かす基盤の次は、⾒る基盤を整える〜 Shota Okunaka 2026-10-06 / Japan Datadog User Group Meetup#22@⼤阪 ©akippa Inc. All Rights Reserved.
2. ⾃⼰紹介 名前 奥中 将太 所属 • akippa株式会社 / Backend Engineer Tech Lead • Japan Datadog User Group アカウント • X : @okkun_sh • GitHub : @okkun-sh 2
3. サービス概要 使っていない空きスペースを簡単に貸し借りできる 駐⾞場マーケットプレイス「アキッパ」 3
4. アジェンダ 1. リアーキテクチャについて 2. ⾒る基盤が閉じていた理由 3. Datadog 導⼊ 4. 導⼊後の変化 5. まとめ 4
5. 1. リアーキテクチャについて 5
6. リアーキテクチャについて 今回メインの話ではないためさらっと話します！！！ 6
7. リアーキテクチャの背景 10年以上続くサービスで、サービスの成⻑とともに技術的負債が積み上がっていた • システム運⽤負荷の増加 • 開発体験の低下 今後も継続してより良い価値をユーザーに届けるには、 技術的負債と向き合う必要があった 7
8. 具体的な課題と⽅針 課題 • 同じ責務のアプリケーションの重複 • 密結合で複雑化した1つの⼤きなコードベース • スケールしづらいインフラやアーキテクチャ • 本番‧検証環境のインフラ差異による認知負荷 ⽅針 • コードベースの分割‧移⾏ • EC2 から ECS への移⾏ • 本番‧検証環境のインフラの⼀致‧IaC 化 8
9. 社内管理サイトの例 9
10. リアーキテクチャの進捗と効果 社内管理サイトに続き、モバイルアプリ向け API やその他のアプリケーションも進⾏中 得られた効果 • コードベース分割によりメンテナンス性が向上 • オートスケーリングによる柔軟なスケーリング • 環境の⼀致と IaC 化による認知負荷の低下 10
11. リアーキテクチャによって 動かす基盤の整備は進んでいたが、 「⾒る基盤」はまだ閉じていた 11
12. 2. ⾒る基盤が閉じていた理由 12
13. 閉じていた3つの理由 1. 状態把握の属⼈化 2. 権限の不⾜ 3. メトリクスの不⾜ 13
14. 状態把握の属⼈化 システムの詳細な理解 (どこに何が出ているか) に加えて、かけ合わせる各ツールへの習熟も必要 • • • インフラメトリクス ◦ CloudWatch Dashboard を確認 ◦ Container Insights を確認 ログ ◦ EC2 : サーバに接続して確認 ◦ ECS : CloudWatch Logs Insights でクエリ検索 レスポンスタイム ◦ • ALB のログを Athena でクエリ検索 スロークエリ ◦ CloudWatch Logs Insights、Database Insights からクエリの特定 14
15. 権限の不⾜ 社内統制上、業務委託メンバーへの AWS 権限は限定的で、 インフラメトリクス、ログ、レスポンスタイム、スロークエリなどの調査‧分析を業務委託メンバーだけ で完結できないことがあった 15
16. メトリクスの不⾜ PHP-FPM や Nginx といった、ミドルウェアの少し踏み込んだメトリクスが取れておらず、 障害などで踏み込んだ調査もできていなかった また EC2 から ECS への移⾏が進んだとしても、アプリケーションやインフラリソースの最適化ま で⼿が届きにくかった 16
17. Before ⾒る基盤の状況 対象 正社員 業務委託 インフラメトリクス ◯ ダッシュボード × 権限がなく不可 ログ △ サーバへの接続 / クエリ検索 × 権限がなく不可 レスポンスタイム △ クエリ検索 × 権限がなく不可 スロークエリ △ クエリ検索 / Database Insights × 権限がなく不可 踏み込んだメトリクス × 取得できていない × 権限がなく不可 17
18. ⾒る基盤をひらくために、 Datadog の導⼊へ 18
19. 3. Datadog 導⼊ 19
20. 導⼊対象の検討 (システム) • • リアーキテクチャ済みの ECS 基盤 ◦ 社内管理サイト ◦ モバイルアプリ向け API メインで開発していてトラフィックも多く導⼊しやすい EC2 基盤 ◦ • コストを考慮し、冗⻑化されたサーバのうち1台にのみ導⼊ (サンプリング⽬的) メインで開発しているが、トラフィックが少ない、または導⼊コストが⾼い EC2 基盤 20
21. 導⼊対象の検討 (Datadog サービス) • Infrastructure Monitoring • Application Performance Monitoring • Log Management • Continuous Profiler • Database Monitoring 21
22. 導⼊⽅法 • ドキュメントと Bits AI のおかげで、ハマることはなかった ◦ Agent や Tracer の設定 ◦ Nginx、PHP-FPM のインテグレーション設定 ◦ ダッシュボード作成 22
23. 4. 導⼊後の変化 23
24. After ⾒る基盤の状況 対象 正社員 業務委託 インフラメトリクス ◯ ◯ ログ △ △ レスポンスタイム ◯ ◯ スロークエリ △ △ 踏み込んだメトリクス ◯ ◯ 可能な限り情報を集約し、誰でも簡単にアクセスできるようになった • 業務委託のエンジニアから「何が起きているか把握しやすくなった」という声があった • バックエンド以外のエンジニアも Datadog を活⽤している 24
25. ⾒られる深さの変化 踏み込んだ調査や分析を可能にした • トレース (APM) を⽤いることで、「なんとなく遅い」から「ここが遅い」へ、 原因特定が⼿軽になり、パフォーマンスチューニングなどの改善が⾏いやすくなった • PHP-FPM や Nginx などのメトリクスが取得できることで、 ミドルウェア、インフラリソースの最適化も⾃信を持って進められるようになった 25
26. 導⼊後の定着に向けた取り組み ツールの導⼊だけではなく、活⽤を定着させるための取り組みとして⾏ったこと • ユースケース別の説明会実施 ◦ • Datadog に触れる時間を作る ◦ • バックエンド、モバイル、QA それぞれの使い⽅に合わせて実施 毎⽇の朝会で直近のリリースや⽇々の気づきを画⾯を⾒ながら共有 Datadog さんと合同社内勉強会の実施 ◦ オブザーバビリティ基礎、⺠主化について 26
27. 5. まとめ 27
28. まとめ • リアーキテクチャによって動かす基盤の整備は進んでいたが、⾒る基盤は閉じていた • ⾒る基盤が閉じていた理由は、状態把握の属⼈化、権限の不⾜、メトリクスの不⾜の3つ • Datadog へ集約することで、誰でも簡単に、踏み込んで⾒られるようになった • ツールを⼊れるだけで終わるのではなく、各々が⾃分で⾒る⽂化を育てる取り組みが重要 28
29. ⽬指す姿 オブザーバビリティの⺠主化 観測するのは⼀部の⼈だけではなく、全員が⾃分で⾒て、⾃分で改善する⽂化をつくりたい 29
30. ©akippa Inc. All Rights Reserved.