ハクソク

世界を動かす技術を、日本語で。

自社開発の「S3」によって年間50万ドルを節約しました

2025年10月27日原文(engineering.nanit.com)

概要

  • Nanitの動画パイプラインで S3コスト が大きな問題となり、 独自メモリ着地点N3 をRustで開発
  • S3のPutObject課金 と24時間分のストレージ課金が主なコスト要因
  • N3は 2秒以内 の短期保存、 S3はオーバーフロー時のみ 利用
  • 導入により 年間約50万ドル のコスト削減
  • 技術的検証・実装・運用ノウハウを詳細解説

Nanit動画パイプラインのコスト最適化事例

背景と従来構成

  • カメラが動画チャンクを記録し、 S3のpresigned URL をCamera Serviceから取得し直接アップロード
  • AWS Lambda がSQS FIFOキューにオブジェクトキーを投稿
  • 動画処理ポッドがSQSから消費し、S3からダウンロードして処理
  • S3+SQS 構成により、アップロードと処理の非同期化・高可用性・順序保証を実現
  • S3ライフサイクルルールで自動GC（最短1日）のため、運用負荷低減

問題点

  • PutObjectリクエスト課金 が最大のコストドライバー
    • チャンク増加＝リクエスト増加でコストが直線的に増大
  • ストレージ課金 も無視できず、2秒で処理しても24時間分の課金が発生
  • 高頻度・短命オブジェクトへの課金が非効率

改善方針

  • アーキテクチャの単純化 で複雑さを排除
  • 透過的な置き換え で既存カメラから見て変更なし
  • 通常パスの最適化 と S3のフェールセーフ利用
  • 順序保証 ・ 高スループット ・ マルチミリオンバックログ耐性
  • 既存ファームウェア対応 ・ 小規模損失許容 ・ コスト最小化

N3アーキテクチャ概要

  • N3-Proxy （外部/内部API、stateless）と N3-Storage （RAM保存、stateful）に分離

  • 動画は一時的にRAM保存、2秒以内にSQSへエンキュー＆処理

  • N3-Storageが満杯時や障害時のみS3へ自動フォールバック

  • 厳格な順序保証 はSQS FIFOのgroup IDで維持

    • Tier1: N3-Storageが受け入れ不能時、N3-ProxyがS3へ代理アップロード
    • Tier2: N3-Proxy/Storage障害時は全トラフィックをS3に切り替え

  • N3-Proxy/Storage分離の理由

    • 障害時の影響範囲最小化
    • CPU/ネットワーク（Proxy）とメモリ（Storage）のリソース最適化
    • セキュリティ（Storageはインターネット非接続）
    • Proxyのみ無停止で安全に更新可能

設計検証・PoC

  • 合成負荷テスト で限界値・ボトルネック特定
  • 本番PoC（ミラーモード） で実カメラ挙動を観測
    • S3とN3両方へ書き込み、出力比較
    • Unleashによるfeature flag で細粒度切り替え・即時ロールバック
  • 主な発見
    • TLS終端が最大CPUボトルネック
    • RAMのみで十分なワーキングセット確保可能
    • Delete-on-GETで再ダウンロード不要
    • TTL GCの追加で処理漏れチャンクをクリーンアップ

実装詳細

  • DNSロードバランシング

    • Route53 MultiValue Aレコード＋ヘルスチェックで各ノードを動的に管理
    • ノード障害時は自動で除外、ロールアウトも安全
    • DaemonSet構成 で1ノード1Pod、TLS終端最適化

  • ネットワーク制限とインスタンスタイプ

    • AWSインスタンスの「Up to」Gbpsはバースト型で継続利用に非適
    • network-optimized c8gn.4xlarge （50Gbps）で持続高スループットを実現

  • HTTPS最適化

    • stunnelから rustlsネイティブ に切替
    • Graviton4 インスタンス＋最適化ビルド
    • これにより RPSが約30%向上

  • アウトバウンドトラフィック課題

    • 各アップロード毎にTLSハンドシェイク（~7KB証明書送信）が発生
    • カメラ側改修不可のため、現状は許容
    • ACKパケット も意外な通信量要因

効果とまとめ

  • 年間約50万ドルのコスト削減 を実現
  • 高負荷・短命オブジェクト処理に最適な設計
  • S3は信頼性確保のためのフェールセーフ としてのみ利用
  • CPU/ネットワーク/メモリ最適化 による効率的運用
  • TLS終端・GC・ロードバランシング などの運用ノウハウ蓄積

今後の展望と応用可能性

  • 他の高頻度・短命オブジェクト処理パイプライン でも応用可能な設計
  • コスト最適化と高可用性の両立 が求められる領域での導入事例
  • Rust＋クラウドネイティブ技術 の組み合わせによる新たな選択肢

参考情報・Tips

  • Route53 MultiValue Aレコード による安価なロードバランシング
  • Unleashなどのfeature flag 活用で安全な段階的リリース
  • Delete-on-GET＋TTL GC による効率的なメモリ管理
  • AWSインスタンスタイプ選定の落とし穴 （バースト型vs継続型）

まとめ

  • Nanitの事例は クラウドコスト最適化 と システム設計 の好例
  • S3のコスト構造理解 と 独自着地点の構築 で大幅な効率化
  • 設計・検証・運用の全プロセス が参考になる実践知見

Hackerたちの意見

正直言って、サーバーレスを使わなければもっとクリーンなシステムになったと思う。2秒の寿命しかないものをディスクに置いて、AWSのサーバーレスの枠にはめ込もうとしたせいで問題が発生して、無駄なコストがかかってる感じ。少なくとも部分的にインメモリソリューションに移行するのはいい解決策だね。

└

そうだね、今はネットワークスループットとRAMを得るために重いインスタンスを動かしてるけど、実際にはCPUはそんなに使ってないんじゃないかな。多分、余裕があるからエンコードもできるはずだし。記事ではTLSハンドシェイクがCPU使用の大きな要因だって言ってるけど、これがこのシステムの制約のトップに来るとは思えない。とはいえ、記事は楽しめたし、まだ自分たちのワークフローに合わせたシステムを作る方法を見つけている人たちがいるのは嬉しいね。

これを維持するのに年間何人のエンジニアが必要なのか気になるな。

└

そうそう、私もそう思った。ブレイクイーブンは1人ぐらいかな（2倍ぐらいの誤差はあるかも）？

└

それに、コードをクラウドサービスに移行するのにどれだけのエンジニア年数がかかるのかも気になる。クラウドではルート権限がないからデバッグできない問題がいくつも出てくるし。クラウドがなければ、ファイルを保存するのは「with open(...) as f: f.write(data)」とDBにレコードを追加するだけで簡単なのに。変なネットワークの問題もデバッグしなくて済むし。

└

1人の小さな割合ぐらいかな？あまり開発が必要ないシンプルなサービスに思える。

└

大企業は自社のプライベートクラウドやデータセンターを使ってるのが気になるね。彼らの規模だと、自前のストレージを持つ方が安上がりだし、サイドビジネスとしてクラウドサービスも自社で売ってる。小さい会社は、SSDやHDDを何台か買うか、WindowsサーバーでSMB共有を作る方がクラウドにお金を払うよりも合理的だと思う。

└

これを維持するのに年間何人のエンジニアが必要なのか気になる 記事の最後にはこう書いてある: 「十分な規模で意味のあるコスト削減ができる場合と、シンプルな解決策を可能にする特定の制約がある場合には、カスタムインフラを検討してください。システムを構築し維持するためのエンジニアリング努力は、排除するインフラコストよりも少なくなければなりません。私たちの場合、特定の要件（エフェメラルストレージ、損失耐性、S3フォールバック）のおかげで、メンテナンスコストが低く保てるシンプルなものを構築できました。この2つの要素がなければ、マネージドサービスを使った方がいいでしょう。彼らはトレードオフをよく理解していたようですね。」

実際には見出しが言ってることはやってないよ。S3の前に置くメモリキャッシュを作っただけ。クールだけど、自分でS3を作るのとは全然違うね。

└

キャッシュがメモリでなくてローカルストレージである必要があった理由がよくわからなかった。

HNスタイルで内容から逸れて、会社について愚痴るね：Nanitはクラウドベースのベビーカメラを運営してるから、このストレージが必要なんだ。Nanitのユーザーは、家や赤ちゃんの動画や音声をライブでNanitにアップロードしてるけど、E2EEはなし。近くで話したことが全部クラウドに送られるホットマイク状態だよ。ハードウェアは使うためにサブスクリプションが必要で、カメラ1台あたり200ドルもするのにね。睡眠トラッキングをしたいなら、Nanitのフロアスタンドにさらに200ドルかかる。これは完全にソフトウェアの制限で、他にオーバーヘッドカメラマウントを手に入れる方法はいくらでもあるのに。（スタンドを使ってるかどうか、USB-Cケーブルだけだからどうやって検出してるのか気になるな。もしかしてeタグ？）もちろん、Nanitは多くの親に支持されてる人気で成功した製品だけど、クラウドベースの家庭内音声/映像ストレージがこんなに普通になってるのを見るのは辛い。セルフホストの動画はそんなに難しくないのに、赤ちゃんモニターに特化したソリューションは誰も作らないんだろうな。クラウドベースの動画ストレージモデルは簡単だから人気が続くだろうけど、定期的なサブスクリプションを正当化するのにも役立ってるよね。編集：自分のコメントに皮肉を見つけた。Nanitがユーザーをサードパーティのクラウド動画ストレージに縛り付けてることについて愚痴ってるのに、この記事はNanitのエンジニアリングチームがサードパーティ（S3）から離れて、自分たちのストレージをホストしてることについてなんだ。S3から脱却した彼らには拍手を送りたい。

└

これが私がNanitのカメラを買うのを拒否した理由。つながってないモデルを選んだよ。E2E暗号化は基本中の基本だよね。

Hacker Newsで議論の続きを見る