リアーキテクチャから Datadog 導⼊へ 〜動かす基盤の次は、⾒る基盤を整える〜 Shota Okunaka 2026-10-06 / Japan Datadog User Group Meetup#22@⼤阪 ©akippa Inc. All Rights Reserved. 

⾃⼰紹介 名前 奥中 将太 所属 • akippa株式会社 / Backend Engineer Tech Lead • Japan Datadog User Group アカウント • X : @okkun_sh • GitHub : @okkun-sh 2 

サービス概要 使っていない空きスペースを簡単に貸し借りできる 駐⾞場マーケットプレイス「アキッパ」 3 

アジェンダ 1. リアーキテクチャについて 2. ⾒る基盤が閉じていた理由 3. Datadog 導⼊ 4. 導⼊後の変化 5. まとめ 4 

1. リアーキテクチャについて 5 

リアーキテクチャについて 今回メインの話ではないためさらっと話します！！！ 6 

リアーキテクチャの背景 10年以上続くサービスで、サービスの成⻑とともに技術的負債が積み上がっていた ● システム運⽤負荷の増加 ● 開発体験の低下 今後も継続してより良い価値をユーザーに届けるには、 技術的負債と向き合う必要があった 7 

具体的な課題と⽅針 課題 ● 同じ責務のアプリケーションの重複 ● 密結合で複雑化した1つの⼤きなコードベース ● スケールしづらいインフラやアーキテクチャ ● 本番‧検証環境のインフラ差異による認知負荷 ⽅針 ● コードベースの分割‧移⾏ ● EC2 から ECS への移⾏ ● 本番‧検証環境のインフラの⼀致‧IaC 化 8 

社内管理サイトの例 9 

リアーキテクチャの進捗と効果 社内管理サイトに続き、モバイルアプリ向け API やその他のアプリケーションも進⾏中 得られた効果 ● コードベース分割によりメンテナンス性が向上 ● オートスケーリングによる柔軟なスケーリング ● 環境の⼀致と IaC 化による認知負荷の低下 10 

リアーキテクチャによって 動かす基盤の整備は進んでいたが、 「⾒る基盤」はまだ閉じていた 11 

2. ⾒る基盤が閉じていた理由 12 

閉じていた3つの理由 1. 状態把握の属⼈化 2. 権限の不⾜ 3. メトリクスの不⾜ 13 

状態把握の属⼈化 システムの詳細な理解 (どこに何が出ているか) に加えて、かけ合わせる各ツールへの習熟も必要 ● ● ● インフラメトリクス ○ CloudWatch Dashboard を確認 ○ Container Insights を確認 ログ ○ EC2 : サーバに接続して確認 ○ ECS : CloudWatch Logs Insights でクエリ検索 レスポンスタイム ○ ● ALB のログを Athena でクエリ検索 スロークエリ ○ CloudWatch Logs Insights、Database Insights からクエリの特定 14 

権限の不⾜ 社内統制上、業務委託メンバーへの AWS 権限は限定的で、 インフラメトリクス、ログ、レスポンスタイム、スロークエリなどの調査‧分析を業務委託メンバーだけ で完結できないことがあった 15 

メトリクスの不⾜ PHP-FPM や Nginx といった、ミドルウェアの少し踏み込んだメトリクスが取れておらず、 障害などで踏み込んだ調査もできていなかった また EC2 から ECS への移⾏が進んだとしても、アプリケーションやインフラリソースの最適化ま で⼿が届きにくかった 16 

Before ⾒る基盤の状況 対象 正社員 業務委託 インフラメトリクス ◯ ダッシュボード × 権限がなく不可 ログ △ サーバへの接続 / クエリ検索 × 権限がなく不可 レスポンスタイム △ クエリ検索 × 権限がなく不可 スロークエリ △ クエリ検索 / Database Insights × 権限がなく不可 踏み込んだメトリクス × 取得できていない × 権限がなく不可 17 

⾒る基盤をひらくために、 Datadog の導⼊へ 18 

3. Datadog 導⼊ 19 

導⼊対象の検討 (システム) ● ● リアーキテクチャ済みの ECS 基盤 ○ 社内管理サイト ○ モバイルアプリ向け API メインで開発していてトラフィックも多く導⼊しやすい EC2 基盤 ○ ● コストを考慮し、冗⻑化されたサーバのうち1台にのみ導⼊ (サンプリング⽬的) メインで開発しているが、トラフィックが少ない、または導⼊コストが⾼い EC2 基盤 20 

導⼊対象の検討 (Datadog サービス) ● Infrastructure Monitoring ● Application Performance Monitoring ● Log Management ● Continuous Profiler ● Database Monitoring 21 

導⼊⽅法 ● ドキュメントと Bits AI のおかげで、ハマることはなかった ○ Agent や Tracer の設定 ○ Nginx、PHP-FPM のインテグレーション設定 ○ ダッシュボード作成 22 

4. 導⼊後の変化 23 

After ⾒る基盤の状況 対象 正社員 業務委託 インフラメトリクス ◯ ◯ ログ △ △ レスポンスタイム ◯ ◯ スロークエリ △ △ 踏み込んだメトリクス ◯ ◯ 可能な限り情報を集約し、誰でも簡単にアクセスできるようになった ● 業務委託のエンジニアから「何が起きているか把握しやすくなった」という声があった ● バックエンド以外のエンジニアも Datadog を活⽤している 24 

⾒られる深さの変化 踏み込んだ調査や分析を可能にした ● トレース (APM) を⽤いることで、「なんとなく遅い」から「ここが遅い」へ、 原因特定が⼿軽になり、パフォーマンスチューニングなどの改善が⾏いやすくなった ● PHP-FPM や Nginx などのメトリクスが取得できることで、 ミドルウェア、インフラリソースの最適化も⾃信を持って進められるようになった 25 

導⼊後の定着に向けた取り組み ツールの導⼊だけではなく、活⽤を定着させるための取り組みとして⾏ったこと ● ユースケース別の説明会実施 ○ ● Datadog に触れる時間を作る ○ ● バックエンド、モバイル、QA それぞれの使い⽅に合わせて実施 毎⽇の朝会で直近のリリースや⽇々の気づきを画⾯を⾒ながら共有 Datadog さんと合同社内勉強会の実施 ○ オブザーバビリティ基礎、⺠主化について 26 

5. まとめ 27 

まとめ ● リアーキテクチャによって動かす基盤の整備は進んでいたが、⾒る基盤は閉じていた ● ⾒る基盤が閉じていた理由は、状態把握の属⼈化、権限の不⾜、メトリクスの不⾜の3つ ● Datadog へ集約することで、誰でも簡単に、踏み込んで⾒られるようになった ● ツールを⼊れるだけで終わるのではなく、各々が⾃分で⾒る⽂化を育てる取り組みが重要 28 

⽬指す姿 オブザーバビリティの⺠主化 観測するのは⼀部の⼈だけではなく、全員が⾃分で⾒て、⾃分で改善する⽂化をつくりたい 29 

©akippa Inc. All Rights Reserved.