PART1：ドキュメント指向データベースの活用と Amazon DocumentDB の選択 -検討編- AWA 株式会社は、1 億 8,000 万曲以上の楽曲を提供する音楽ストリーミングサービス「 AWA 」を運営しています。 独自のライブ配信機能「 AWA ラウンジ 」やフラワーチャット / フラワースタンプ（投げ銭）機能を備え、幅広いデバイスに対応しています。 2015 年のサービス開始当初から AWS 上でシステムを構築してきた同社は、2025 年にサービス基盤のデータベースを MongoDB on Amazon EC2 から Amazon DocumentDB （MongoDB 互換）へ移行しました。 本ブログシリーズでは、ドキュメント指向データベースの活用方法と Amazon DocumentDB への移行プロセス、そして移行後の効果について、全 2 回に分けてお客様の声を紹介いたします。 PART1（本記事） : ドキュメント指向データベースの活用と Amazon DocumentDB の選択 PART2 : 23 億ドキュメントの移行プロセスとコスト約 50% 削減の効果 移行検討の背景と課題 AWA では、マイクロサービスの実行基盤に Amazon ECS on AWS Fargate 、キャッシュに Amazon ElastiCache for Redis 、検索基盤に Amazon OpenSearch Service を採用するなど、「マネージドサービスへの集約」と「技術スタックの統一」を方針として掲げ、段階的にマネージドサービスへの移行を進めてきました。 その中で最後に残っていた大物が、Amazon EC2 上で MongoDB Cloud Manager を使用してセルフホストしていたデータベースでした。 この環境には、いくつかの運用上の課題がありました。 コストの高騰 : セルフホスト環境の運用コストに加え、Cloud Manager の仕様変更によりバックアップコストがさらに増大した。 スケールダウンの困難さ : ピーク時に合わせて拡張した 10 シャード 構成を縮小できなかった。 バージョンアップの負荷 : 複数環境のクラスターを個別にアップグレードする必要があり、その作業中に予期しないエラーでの中断が発生、サポートケースへの問い合わせが頻発した。 事業継続リスク : MongoDB クラスターの運用には専門的な知識が求められ、対応できるエンジニアが限られていた。担当者が不在の際の障害対応や、引き継ぎの難しさが事業継続上のリスクとなっていた。 当初は、MongoDB のシャード数を削減してスペックを調整し、コストを最適化する案も検討されていました。 しかし、シャードを減らすためのデータ退避が何ヶ月経っても完了せず、最終的に MongoDB 側の問題であることが判明しました。 この経験から、セルフホスト環境でのコスト最適化に限界を感じ、マネージドサービスへの移行に舵を切ることになりました。 2022 年にマネージド化の計画書が作成されましたが、本格的にプロジェクト化したのは 2025 年 4～5 月でした。 Cloud Manager のバックアップコスト高騰が最終的な決め手となり、約 4 年越しの移行プロジェクトが始動しました。 移行前のシステム構成 移行対象データベースの概要 項目 内容 DB エンジン MongoDB 4.4.29（Cloud Manager 管理） 構成 10 シャード、各シャードが レプリカセット インスタンス r6a.2xlarge × 20 台（データノード） ドキュメント数 約 23 億 ( TB 規模 ) 主な格納データ アーティスト情報、プレイリスト、ログイン情報、再生回数、AWA ラウンジ機能 アプリケーション言語 Go クエリパターン find、update、insert が中心（アグリゲーションパイプライン不使用） Read/Write 比率 約 30:1 以上（コンテンツ配信の特性上、Read ヘビー） AWA におけるドキュメント指向データベースの活用 AWA はサービス開始当初からドキュメント指向データベースを採用しており、そのデータモデルはサービスの特性と深く結びついています。 移行先の選定にあたっては、ドキュメント指向 DB であることが重要な要件でした。 スキーマレス設計：サービス無停止でのスキーマ変更 「スキーマレスのところが最高です。 AWA のポリシーとして、メンテナンスによるサービス停止をゼロに近づけたい。 ALTER TABLE のためにサービスを止めるようなことはできれば避けたいですからね。」 AWA では、新しいコレクション（RDB におけるテーブルに相当）の追加が 2～3 ヶ月に 1 回程度、既存コレクションのフィールド変更 ( RDB における列追加などに相当 ) が月 1～2 回程度の頻度で発生します。 ドキュメント指向データベースでは、これらの変更をサービスを停止することなく実施できます。 新しいフィールドを追加する際は後方互換を保つようにフォールバック処理をコードに組み込み、新しいフィールドがないドキュメントに対してもアプリケーション側で対応する運用を採用しています。 スキーマレスの柔軟性を活かしつつ統制を保つため、Go 言語の Struct 定義をスキーマの正として管理しています。 Go のフィールド定義がそのまま DB スキーマに反映される仕組みで、直接 DB を変更することはせず、必ず Go コードを通じてアクセスする運用です。 アプリケーションのクラス定義と DB のデータ構造が一致するため、RDB で必要になるようなオブジェクトとテーブル間のデータ変換が不要です。 開発者は DB の構造を意識せずにアプリケーションのコードに集中でき、変換処理に起因するバグも防げます。 RDB : アプリのオブジェクト → O/R マッピング → テーブル（変換が必要） ドキュメント指向DB : Go Struct → そのまま JSON ドキュメント 配列・ネスト構造：JOIN 不要のシンプルなクエリ AWA では、ドキュメント指向データベースの柔軟なデータモデリングを活用しています。以下に、2 つの活用例を紹介します。 配列の活用例：外部サービス連携の管理 ユーザーが連携を許可した外部サービスの ID を配列として保持し、「特定のサービスと連携しているユーザーを検索する」といったクエリを、外部キーや JOIN を使わずにシンプルに実現しています。 RDB では、ユーザーテーブルと連携サービステーブルを外部キーで関連付け、JOIN で結合する必要がある処理を、1 回のクエリで完結できます。 ネスト構造の活用例：認証情報の管理 ユーザードキュメント内に外部認証サービスのログイン情報をネストしたオブジェクトとして格納し、auth_provider.id のようなドット記法のクエリで、特定の外部認証サービスの ID でログインしているユーザーを直接検索できます。 RDB であれば外部キーと JOIN が必要になる処理を、1 回のクエリで完結できます。 非正規化設計：Read ヘビーなサービスに最適化 AWA のサービスはコンテンツ配信という特性上、Read に大きく寄っています。 この特性を活かし、あえて正規化せず 1 ドキュメントに関連する ID を配列で保持する設計を採用しています。 1 つのドキュメントを取得すれば関連するエンティティの ID が全て分かり、それらの実体を主キーで取得するという 2 段階のクエリで、必要なデータを効率的に取得できます。 クエリの運用性を高めるため、複雑なクエリやアグリゲーションパイプラインは使用しない方針を取っています。 MongoDB のバージョンアップで仕様が変わることがあったため、アグリゲーションが必要にならないようデータ構造自体を設計し、集計が必要な値は書き込み時にカウントアップする方式を採用しています。 これにより、読み込み時に集計処理を実行する必要がなくなり、Read の負荷軽減にもつながっています。 インデックス戦略：Read 最適化の設計 AWA では、アプリケーションから発行される全ての Read クエリに対して専用のインデックスを設定しています。 論理削除フラグには専用のインデックスを設け、日付範囲検索にもクエリごとのインデックスを用意するなど、Read 性能を最優先としたインデックス戦略です。 多数のコレクション・インデックスを運用していますが、クエリごとに専用インデックスを設計しているため、意図しない実行計画が選択されることはほとんどありません。 MongoDB ではクエリがパイプライン形式で実行されるため、RDB のように複数テーブルの JOIN で実行計画が複雑化しにくいという特性も寄与していると考えられます。 Amazon DocumentDB を選択した理由 AWA がこれらのドキュメント指向 DB の設計を維持しつつ、移行先として Amazon DocumentDB を選択した理由は大きく 3 つあります。 1. MongoDB 互換による低リスクな移行 「MongoDB にこだわりはなく、ドキュメント指向 DB であることが大事。 MongoDB との高い互換性がある Amazon DocumentDB が最も移行しやすかった。」 Amazon DocumentDB は MongoDB との互換性を備えており、AWA で使用していた find、update、insert といった基本的なクエリはそのまま動作しました。 2. 本番実績に基づく性能への信頼 AWA では移行前から別のワークロードで Amazon DocumentDB を利用しており、1 クラスター・1 ノードの xlarge～2xlarge 程度のインスタンスで高い書き込み性能を確認していました。 MongoDB で 10 シャードに分散していた処理を、Amazon DocumentDB の 1 クラスターで処理できるという仮説が、既に本番環境で裏付けられていました。 3. AWS への集約によるコストと運用の最適化 「AWS に集中していたほうがやりやすい。 セキュリティ的にも Amazon VPC 内で完結させたかった。」 MongoDB Atlas も検討しましたが、AWS 上で全てを管理したいという方針から Amazon DocumentDB を選択しました。 Amazon VPC 内で通信を完結させることでセキュリティ要件を満たしつつ、ネットワーク構成を簡素化できる点も決め手の一つでした。 また、Amazon DocumentDB はコンピューティングとストレージが分離されたアーキテクチャを採用しており、Read ヘビーな AWA のワークロードに対して Reader インスタンスを柔軟にスケーリングできます。 マネージドサービスとしての自動バックアップや PITR も、運用負荷の軽減に寄与すると判断しました。 なお、 Amazon DocumentDB Serverless も検討しましたが、11 月の Amazon EC2 Savings Plans 満了に合わせた移行スケジュールの中で検証時間を確保できなかったため、まずはインスタンスベースで移行し、今後の検証課題としています。 次回予告 PART1 で紹介したスキーマレス設計、配列・ネスト構造、非正規化設計、インデックス戦略といったドキュメント指向 DB の設計は、Amazon DocumentDB でどのように機能したのか。 PART2 では、23 億ドキュメントのニアゼロダウンタイム移行の具体的なプロセスと直面した課題、そしてコスト約 50% 削減を含む移行後の効果についてご紹介します。 [ Part 2 に続く ] 信田 悟至 氏 山下 剛史 氏 小林 健太郎 氏 AWA 株式会社 信田 悟至 氏 山下 剛史 氏 株式会社サイバーエージェント メディア統括本部 SRE 小林 健太郎 氏 本ブログは、データベーススペシャリストソリューションアーキテクトの藤田 将大とシニアソリューションアーキテクトの半場 光晴が執筆しました。

PART2：23 億ドキュメントの移行プロセスとコスト約 50% 削減の効果 -移行・効果編- PART1 では、 AWA がドキュメント指向データベースの特性をどのように活用しているか、そして Amazon DocumentDB の採用に至った経緯を解説しました。 PART2 では、23 億ドキュメントの大規模環境をニアゼロダウンタイムで Amazon DocumentDB へ移行した具体的なプロセスと、直面した課題、そして移行後の効果についてご紹介します。 移行前後のシステム構成 移行先の構成 移行前の環境は MongoDB 4.4.29、10 シャード・レプリカセット構成、r6a.2xlarge × 20 台（データノード）、23 億ドキュメントという大規模な環境でした（詳細は PART1 の移行対象データベースの概要を参照）。 移行先の Amazon DocumentDB の構成は以下の通りです。 項目 内容 インスタンス db.r6g.8xlarge（移行後に db.r8g.8xlarge に変更） ストレージ I/O-Optimized 構成 1 クラスター（Writer + Reader） I/O-Optimized ストレージを選択した理由は、コスト予測のしやすさです。 db.r8g への変更は、コスト最適化および Database Savings Plans への対応を目的としています。 移行スケジュール 本プロジェクトは、AWA の少人数の開発チームが自社で実施しました。 本格的なプロジェクトは 2025 年 4 月に始動し、以下のスケジュールで進められました。 時期 フェーズ 内容 2025 年 4～5 月 計画策定 移行対象の洗い出し、移行方式の決定 2025 年 6～7 月 準備 負荷試験環境の構築、データ連携ツール DB Sync の全コレクション対応 2025 年 8 月 負荷試験 通常営業負荷と AWA ラウンジ 高負荷の 2 種類を約 1 ヶ月実施 2025 年 10 月～ 並行運用・切り替え マイクロサービスごとに段階的に切り替え 2025 年 12 月中旬 完了 全マイクロサービスの切り替え完了 11 月に Amazon EC2 の Savings Plans が満了するタイミングに合わせてスケジュールを組みましたが、バッチ処理の切り替えに想定以上の時間がかかり、最終的に 12 月中旬の完了となりました。 データ移行の流れ データ移行は、自社開発のデータ連携ツール DB Sync を中心に、3 つのフェーズで実施しました。 AWS Database Migration Service (AWS DMS) の利用も検討しましたが、DB Sync で既にデータ連携運用の実績があり、それを流用するほうが安定した移行につながると判断しました。 DB Sync は MongoDB の Change Streams を利用したサブスクリプション形式のデータ同期ツールで、以前から一部コレクションの同期に利用していた実績がありました。 フェーズ 1：初期データロード mongodump / mongorestore を使用して、MongoDB 上の 23 億ドキュメントのデータを Amazon DocumentDB へ一括投入しました。 フェーズ 2：継続的データ同期 初期ロード完了後、DB Sync で MongoDB と Amazon DocumentDB 間のリアルタイム同期を開始しました。 DB Sync は MongoDB の Change Streams をサブスクライブし、変更イベントを Amazon DocumentDB へ書き込む仕組みです。 今回の移行では、以前の限定的なコレクション同期から全コレクション対応に拡張しました。 フェーズ 3：マイクロサービスごとの段階的切り替え 約 10 のマイクロサービスを、依存関係の少ないものから順に Amazon DocumentDB へ切り替えました。 切り替えは各サービスの DB 接続先を DNS レベルで変更する方式で、サービス停止はほぼ発生していません。 移行途中では、マイクロサービスによって参照先の DB が新旧で異なる状態が発生します。 そのため、サービス間の依存関係を考慮し、他のマイクロサービスへの影響が少ないものから順に切り替えを進めました。 切り戻しも考慮しており、実際に本番で一度切り戻しを実施しています（詳細は後述）。 移行時の課題と対応 Writer への負荷集中と切り戻し 本番環境で大規模な AWA ラウンジ（AWA 独自のライブ配信機能）イベントを実施した際、以前は 10 シャードに分散していた書き込みが 1 クラスターの Writer に集中し、サービスに影響が出ました。 再生ごとにカウントされるクエリがユーザー数分発生し、Writer がボトルネックとなりました。 事前に切り戻しの手順と判断基準を準備していたため、問題発生時に即座に旧環境への復旧を決断できました。切り戻しまでの間に発生した一部の書き込みデータは失われましたが、サービス全体への影響を最小限に抑えることを優先したビジネス判断でした。 その後、以下の対応を実施しました。 負荷試験の追加実施 : AWA ラウンジ高負荷を模した追加の負荷試験を実施しました。 書き込み頻度の調整 : インクリメント処理など、高頻度の Write クエリをアプリケーション側で最適化しました。 Reader/Writer の分離 : MongoDB 時代は全てのクエリを Writer（Primary）に送信していた設計を見直し、Amazon DocumentDB の Reader エンドポイントと Writer エンドポイントへの接続を明確に分離。それぞれ専用のドライバー設定を用意しました。 Amazon DocumentDB はコンピューティングとストレージが分離されたアーキテクチャを採用しており、Writer インスタンスとは独立して Reader インスタンスを柔軟に追加できます。 Read ヘビーな AWA のワークロードでは、この Reader/Writer 分離が特に重要でした。 「Reader と Writer を意識してアプリケーションを組むようになりました。 やらないと Writer に負荷が集中してしまい、Reader のスケールメリットを活かせません。 Amazon DocumentDB のベストプラクティスを学んで、頭を切り替えていきました。」 データ同期の課題 DB Sync を全コレクション対応に拡張した際、2 つの問題が発生しました。 1. 同期サーバーの過負荷 以前は限定的なコレクションのみ同期していたため、全コレクション対応で同期サーバーが過負荷になりました。 2. ObjectID 型のハンドリング 主キーの大半は String 型でしたが、一部コレクションで ObjectID 型が使われており、正しく同期されないケースが発生しました。 この問題は移行後に発覚し、迅速に対応を行いました。 データ同期ツールを使用する場合、データ同期ツール自体に精通しておくことだけでなく、全コレクションのスキーマとデータ型を事前に網羅的に把握しておくことが重要です。 TLS 通信と認証への対応 移行で最も工数がかかったのは、Amazon DocumentDB の TLS 通信と ID/パスワード認証への対応でした。 Amazon DocumentDB では TLS がデフォルトで有効化されており、以前の MongoDB 環境ではネットワーク隔離のみで認証を設定していなかったため、接続設定の変更が必要になりました。 「一番大変だったのは、ID/パスワード認証の対応でした。 以前の MongoDB では設定していなかったのですが、Amazon DocumentDB では必要となるため、これを機に認証と通信の暗号化を導入しました。」 結果的にセキュリティの向上につながりましたが、移行を検討される際は事前に認証設定の影響範囲を確認しておくことをお勧めします。 MongoDB 互換性 AWA では複雑なアグリゲーションパイプラインを使用しない方針を取っていたため、クエリの互換性問題はほとんど発生しませんでした。 find、update、insert を中心としたシンプルなクエリパターンにより、Web アプリケーションのクエリに関しては Amazon DocumentDB Compatibility Tool での事前確認でも問題は検出されませんでした。 一部、古いバッチ処理と Go 言語のドライバーで対応が必要な箇所がありましたが、影響は限定的でした。 PART1 で紹介したスキーマレス設計、配列・ネスト構造を活用したデータモデル、Read 最適化のインデックス戦略、Go Struct によるスキーマ管理といったドキュメント指向 DB の設計は、Amazon DocumentDB 上でも問題なく動作しています。 Amazon DocumentDB への移行の効果 移行前後の比較 項目 移行前（MongoDB on Amazon EC2） 移行後（Amazon DocumentDB） 構成 10 シャード、レプリカセット 1 クラスター（Writer + Reader） インスタンス r6a.2xlarge × 20 台 db.r8g.8xlarge（Writer + Reader） 月額コスト – 約 50% 削減 バージョンアップ 10 クラスター個別対応 マネージドサービスで一括管理 バックアップ Cloud Manager 20 世代管理 自動バックアップ + PITR スケール変更 シャード削減が困難（数ヶ月かかることも） Reader の追加・削除が容易 認証・暗号化 未設定（ネットワーク隔離のみ） TLS 通信 + ID/パスワード認証 ネットワーク MongoDB 専用サブネットで複雑な隔離構成 Amazon VPC 内でシンプルな構成 ※ 移行前コストには Amazon EC2、Cloud Manager、バックアップ、通信費を含みます。 コスト削減 データベース関連コストは約 50% 削減されました。 コスト試算は、ベストプラクティスドキュメントを参考に既存クラスターの CPU・メモリ使用率から必要スペックを机上計算し、負荷試験で実証した上で本番稼働させています。 さらに、Database Savings Plans の適用により追加で約 20% の削減を見込んでいます。 性能 20 台の Amazon EC2 インスタンス（10 シャード構成）から 1 クラスターへの集約にもかかわらず、レスポンスタイムに大きな変化はありませんでした。 コンテンツ配信という特性上 Read ヘビーなワークロードであり、Amazon DocumentDB の Reader インスタンスを活用して Read 処理を分散させることで、台数を大幅に削減しつつ性能を維持できています。 MongoDB のシャーディング構成ではスケールダウンに数ヶ月を要することもありましたが、Amazon DocumentDB では Reader の追加・削除が容易です。 運用 マネージドサービスの活用により、特定のエンジニアに集中していたバージョンアップやノード障害対応の負荷が軽減され、スロークエリの改善などアプリケーション本来の改善に注力できるようになっています。 モニタリングについては、 Datadog と連携した Amazon DocumentDB 用監視ダッシュボードを構築し、フェイルオーバー検知には AWS Chatbot を使用して Slack に通知する体制を整えています。 今後は、Amazon DocumentDB の クローン機能 を活用し、本番データを用いた負荷試験環境の迅速な構築にも役立てていく予定です。 補足：Amazon DocumentDB の クローン機能 とは 本番クラスターのデータを短時間かつ追加ストレージコストを抑えてコピーできる機能です。コピー元とコピー先でストレージを共有する Copy-on-Write 方式のため、クローン作成時点ではデータの物理コピーが発生せず、大規模なクラスターでも高速にクローンを作成できます。 セキュリティ 移行前は MongoDB 用に専用サブネットを作成し、複雑なネットワーク構成で隔離していました。 Amazon DocumentDB への移行により、TLS 通信と ID/パスワード認証が導入され、ネットワーク構成も簡素化されました。 10 年以上前に構築された初期のネットワーク構成を、移行のタイミングで整理できたことも副次的な効果です。 移行を検討されている方へ 本プロジェクトを通じた気づきとして、以下の点に留意されることをおすすめします。 「反省として、流れてくる Write クエリの頻度とタイミングを事前に詳細に把握しておくべきでした。」 Write クエリの頻度とパターンを事前に詳細に把握する : シャーディング構成から 1 クラスターへの集約では、Writer への負荷集中が最大のリスク。特にイベント時など負荷が変動するワークロードでは、ピーク時の Write パターンを把握した上で負荷試験を実施することが重要です。 Reader/Writer の分離設計を事前に計画する : Amazon DocumentDB のアーキテクチャを活かすため、アプリケーション側で Reader と Writer を意識した設計に変更することをお勧めします。 TLS 通信と認証の影響範囲を事前に確認する : Amazon DocumentDB では TLS と認証がデフォルトで有効化されているため、MongoDB で未設定の場合は接続設定の変更が必要です。 データ同期ツールを使用する場合、全コレクションのスキーマを網羅的に把握する : 特にデータ型の違い（String vs ObjectID など）に注意が必要です。 「相当凝ったクエリでもなければ MongoDB のまま移行できると思います。今回は ID/パスワード認証の対応が最も大変でした。」 今後に向けて 「今回の移行はラスボスぐらいの強敵でしたが、やっと倒せました。 マネージドで、気持ちの面でも運用の面でも楽になりました。 副次的に、ドライバーのアップグレードや通信の暗号化など、気になっていた部分を改善するきっかけにもなりました。 今後は Database Savings Plans の適用や Amazon DocumentDB Serverless の検証を進め、さらなるコスト最適化を目指していきます。 マネージドに極力寄せていける構成にしていきたいです。」 「これまでバージョンアップやノード障害の対応に追われていましたが、今後はスロークエリの改善など、本来注力すべき領域に集中できるようになりました。 Amazon DocumentDB では Reader の増減やスペックの上げ下げも柔軟にできると期待しています。」 まとめ AWA 株式会社は、MongoDB on Amazon EC2 から Amazon DocumentDB への移行により、以下の成果を達成しました。 データベースコスト約 50% 削減 （さらに Database Savings Plans で約 20% の追加削減を見込み） 23 億ドキュメントのニアゼロダウンタイム移行 20 台の Amazon EC2 インスタンスから 1 クラスターへの集約 （性能を維持） 運用負荷の大幅軽減 と属人化の解消 セキュリティの向上 （TLS 通信、認証、ネットワーク構成の簡素化） 2022 年の構想から約 4 年。 マネージドサービスへの集約という一貫した方針のもと、大規模移行を完遂した AWA の事例は、MongoDB 環境から Amazon DocumentDB への移行を検討している企業にとって、具体的な道筋を示すものです。 Amazon DocumentDB の詳細については、以下のリソースをご参照ください。 Amazon DocumentDB のベストプラクティス Amazon DocumentDB のベストプラクティス MongoDB からの移行に使えるドキュメント Amazon DocumentDB と MongoDB の機能的な違い Amazon DocumentDB への移行ガイド Amazon DocumentDB 移行 Runbook Amazon DocumentDB の便利なツール群 以下のツールは Amazon DocumentDB Tools リポジトリで公開されています。 compat-tool — MongoDB との互換性チェック index-tool — インデックスの分析・最適化 migration — 移行支援ツール sizing-tool — サイジング見積もり monitoring — モニタリング performance — パフォーマンス分析 operations — 運用支援 信田 悟至 氏 山下 剛史 氏 小林 健太郎 氏 AWA 株式会社 信田 悟至 氏 山下 剛史 氏 株式会社サイバーエージェント メディア統括本部 SRE 小林 健太郎 氏 本ブログは、データベーススペシャリストソリューションアーキテクトの藤田 将大とシニアソリューションアーキテクトの半場 光晴が執筆しました。

はじめに Architecture Design Grp で エンジニア をしている大塚です。 New Relic Advance: Tokyoというイベントに参加してきました。 New Relicのこれからについて、さまざまな発表がありましたので、簡単にまとめさせていただきました。 今回はCEOなどの登壇もあり、見応えのあるイベントでした！ TL;DR New Relicが日本リージョン（国内データセンター）を追加予定で、データ保管要件とレイテンシ面でメリット 生成AI（Analyzer + MCPなど）でアラート調査の初動を短縮し、運用定着を加速する事例が紹介された New Relic Lensで外部DBやDWHなどにクエリし、NRQLで既存データと結合して分析できる イベント概要 日程：2026/03/12 16:00 ~ 18:00 会場：八芳園 全体の所感 New RelicのCEOなどが登壇するようなイベントで、今まで参加したイベントとは雰囲気がだいぶ違いました。 生成AI時代なので、AIの活用を加速させる内容が多かったです。 AI for New RelicとしてAIアシスタントやSRE Agentなどの紹介があり、インシデントなどの対応フローの自動化などが大きなトピックでした。 New Relic for AIとしてMCPの紹介や、ほかプラットフォームとの統合についての紹介もありました。 基調講演でもAIとNew Relicのデータを用いてインシデントやアラート対応を効率化させるという話があったので、BASEでも取り込んでいこうと感じました。 セッション / トピック 1) 日本リージョン追加！ newrelic.com 日本にNew RelicのDCを設立するというお話です。 セキュリティやプライバシー要件的にNew Relicに保存できなかった（海外リージョンのため）データも日本国内にデータが保存されるようになることで、より幅広いデータを集約することが可能になります。 レイテンシなどのパフォーマンスにも寄与するような大きなトピックでした。 2) 生成AIで加速させるNew RelicのEnabling speakerdeck.com blog.kinto-technologies.com New Relicを組織に浸透させるための取り組みにAIを組み合わせて、活用を加速させるというお話でした。 勉強会やドキュメントなどのコンテンツをいくら揃えても、それぞれのエンジニアにはそれぞれのタスクがあるので、時間を使って活用してもらうのは難しいという課題が挙げられていました。 New Relicを用いて、計装→検知→調査→解消までのサイクルは回せるようになるが、結局は人の目や手で対応をする必要があるので非効率という課題が残ってしまっていました。 その課題に対してNew Relic Analyzerという仕組み（AIによる分析）を導入することで、初期調査の時間が大幅に短縮され、MCPを用いた対話型にすることで日常業務への定着も進んだとのことでした。 BASEではアラートはSentryで調査はNewRelicという構造になっているので、現状を維持しても良いがNew Relicを活用できていない部分も大きいと感じました。 インシデントやアラートの対応サイクルを改めて見直し、AIを導入した新しい仕組みづくりをしてみても良いかもしれない。。。 3) New Relic Lens docs.newrelic.com New Relic外のデータソースに対してクエリを実行することが可能になりました。 クエリ結果に対してNRQLでNRDBのデータとjoinして分析・可視化できるようです。 現状対応しているのは以下 クラウド データ ウェアハウス : Snowflake 、 Redshift 、 ClickHouse リレーショナルデータベース : PostgreSQL 、 MySQL 、 SQL Server ドキュメントデータベース : MongoDB 、 Elasticsearch スプレッドシート : Google Sheets データレイク : Iceberg メトリクスと監視 : Prometheus 、 AWS CloudWatch BASEでの活用の今後の展望 アラート対応やインシデント対応の実態調査 New Relic Analyzer的な機能の実装が可能かどうか New Relic Lensを利用してNew RelicからMySQLのデータをクエリできるようにする（可能か？の調査から） 最後に 生成AIの活用が進む中で、アプリケーション監視についてもこれらの技術を用いる必要性を感じました。 今回のイベントの内容はBASEでも活用できる内容が多かったので、積極的に取り入れることで社内のAI Observabilityを向上させていきたいと思います。 こうした生成AIを活用した取り組みは各社行っていると思いますが、BASEでも積極的に開発やサービスに取り入れています。 binc.jp