インフラ勉強会とは インフラ勉強会は、コミュニケーションツール「Discord」のサーバ上に作られた、オンラインの勉強会コミュニティです。Discordアカウントとインターネットがあれば、どこからでも・誰でも（※1）無料 […]

こんにちは、昨年キャディ株式会社に入社した佐野です。入社して初めての技術記事になります。 この記事では、これまでの開発経験を振り返りながら、それが推論システムの運用にどう活きたのかを整理してみようと思います。 対象読者 機械学習システムを運用したことがないSRE、バックエンドエンジニアの方々 これから機械学習システムを運用していくSRE、バックエンドエンジニアの方々 伝えたいこと 機械学習のモデル開発経験や機械学習システムの運用経験がなくても、機械学習システム(推論システム)の運用に貢献できます。SREの領域と被るものが大半であるため、今までの経験を活かせることが大半です。 入社前までの経験 直近5年くらいはバックエンド、SREを往復するようなキャリアでした。APIの設計・開発から始まり、DB設計、システム設計などを色々やっておりました。機械学習の経験はというと、プロジェクトで半年ほど画像認識で使用する画像をOpenCVでコネコネしていたことはあります。ただそれも7年以上前なので、記憶の彼方に消えてしまってます。 配属先のチーム キャディに入社後の私の配属先のチームは、Analysis Platformチームで、機械学習システム(推論システム)を開発・運用しています。具体的には、モデル開発以外(システム設計、API設計・開発、インフラ構築など)の業務を全て担っています。 役に立った経験 実際チームでシステムを運用、タスクを消化していく中で感じたことは、バックエンド、SREの経験をそのまま使えるということです。例えば、以下のような経験はそのまま活かすことができます。 システム設計 データリソースの選定 モニタリングやアラートの設計/運用 ネットワーク設計 など システム設計(非同期設計) システム設計については、推論システムだからといって特別なものはほぼなく、通常のシステム設計の考え方(非同期設計など)に似た部分が多いように感じています。その中でも特に非同期設計の経験は役に立ちます。なぜ役に立つかは後述します。 データリソースの選定 この経験も非常に有用だと考えています。推論APIの設計にも依存しますが、モデルによってはAPIのレスポンスが肥大しがちです。例えば物体検出のモデルでは、検出数によってレスポンスが大きくなることもあり得ます。この推論結果をどのデータリソースに格納するのが望ましいかは腕の見せ所であり、面白いポイントだと感じています。Cloud SQLのようなRDB、mongoDBのようなNoSQL、GCSのようなストレージサービスなど様々な選択肢がある中で、要件に応じた選定を行う必要があります。これを決めていくにあたり、これまでのデータリソースの運用経験が非常に活きると考えています。 モニタリングやアラートの設計/運用 推論システムといえど、運用という点ではこれまでのシステムとほぼ変わりません。SLOの定義や、アラート疲れを起こさないための運用設計など、まさにSREの知見が求められるシーンが多かったです。 また私が入ったタイミングで、既存の推論システムをGKEへ移行しており、システムをいかに安全に移行するか、モニタリングをどう再設計するかなどの知見も非常に有用でした。 zenn.dev 通常システムとの違い 今までの経験がいきるとはいえ、推論システムと通常システムには多少違いがあります。自分の中で感じた部分を少し書ければと思います。 非機能要件: 非同期処理にしたい モデルによって推論に時間がかかることはしばしばあります。例えば物体検出のモデルでは、検出数が多ければ多いほど推論に時間がかかるため、処理時間が数十秒になることも珍しくありません。そのため非機能要件を定めるに当たっては注意が必要になります。システムを運用する視点では、非同期処理によせることができれば、同期処理と比較し、シビアに処理時間を気にしなくて良くなります。 また、当たり前ですがGPUは通常のインスタンスと比較してコストが高くなります。そのためGPUを使用しないときは、インスタンスを停止してコストを抑える必要があります。具体的にはkubernetesの場合はKEDAのScaledObjectなどを使い、使用していない期間のインスタンスの停止などの工夫を行い、コストを抑える必要があります。 このようなこともあり、非同期処理の経験が非常に活かせると考えています。 技術選定: GPUを利用するための術を知りたい 推論システムを運用していく上で避けて通れないのは、GPUの運用です。私の知る限りGoogle Cloudでは、Compute EngineはもちろんのことマネージドサービスであるVertex AI、サーバーレスであるCloud RunでもGPUを扱えます。これらの選択肢の中で、何が要件としてマッチしているかは検討できるようになる必要があると感じています。 docs.cloud.google.com 余談ですが、Compute Engineのマシンタイプでは、A2 マシンシリーズやN1 マシンシリーズ(T4)、G2マシンシリーズ(L4)という名前が出てきます。最初これらのアルファベットを聞いて、何を言ってるのかさっぱりわからなかった記憶があります。 docs.cloud.google.com リソース管理: GPUを効率的に使いたい GKE上でGPUを効率的に使用するにはいくつか方法があります。マルチインスタンスやタイムシェアリングなどの方法があります。私はまだ実装経験はありませんが、これらをどのように使っていくかはまさに推論システムの特徴なのではと感じています。 docs.cloud.google.com ライブラリ管理: マイナーバージョンの更新であっても細心の注意を払いたい 機械学習で使用されるライブラリであるnumpyやtorchなどのバージョン更新には細心の注意が必要です。たとえマイナーバージョンの更新であってもnumpyは2.0系統であれば、推論結果に影響が出る可能性があるようです。私もPR作成時に意図せずバージョンが上がった時があり、機械学習エンジニアに指摘してもらうことがありました。 最後に まだまだ入門したばかりで、学ぶことも多々あると思いますが、SREやバックエンドでの経験は確実に活き、運用できていると感じます。皆さんもぜひチャレンジしてみてくださいね！

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 小林 健太郎 氏 本ブログは、データベーススペシャリストソリューションアーキテクトの藤田 将大とシニアソリューションアーキテクトの半場 光晴が執筆しました。