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

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

概要

  • 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暗号化は基本中の基本だよね。

幸せな顧客として、Nanitを選んだのは実際に機能したから。スマート機能は使わなかったけど、「どこにいてもアプリを起動して、動画フィードがちゃんと動く」ってのは、残念ながら試した競合製品は誰も達成できなかった基準だった。他のはほとんどがソフトウェア会社じゃないところが作ったもので、外注したアプリは50%の確率でしか動かなかった。こういうことに対してローカルファーストでE2EEの消費者向けソフトウェアがあればいいのにと思うけど、使えるソフトウェアとその選択肢があれば、後者を選ぶよ。

私たちはオフラインのInfant Opticsのベビーカメラを3人の子供に使ってきたけど、オンラインカメラが提供するスマート機能を求めたことは一度もないよ。本当に知りたいのは、子供が寝ているか、泣いているかだけだから。ほとんどの子供のためにその動画を録画する良い使い道が見えないな。(特別なニーズの状況では役立つこともあるだろうけど)

セルフホストの動画はそんなに難しくない ベビーモニターの典型的なユーザーがセルフホストの動画を考えることはまずないよね。

子供たちにはipカメラを使ってた。今はユビキティで、セットアップもストレージも超簡単だよ。SynologyはRTSPを出力するものなら何でもサポートしてると思う。ここでのベビーモニターは、Alectoっていう人気ブランドがあって、値段は2倍で機能は半分しかない。

すべてのNanitユーザーは、E2EEなしで自宅や赤ちゃんの動画と音声をNanitにライブでアップロードしている。近くで話したことが全部クラウドに送られるホットマイク状態だ。 あなたの言い回しだと、もしE2E暗号化されていたら動画をアップロードするのは問題ないように聞こえるね。これは明確にする価値があると思う(多くの人がE2EEのトレードオフを理解していないから):E2EEは全ての処理を行うスマートクライアントと、盲目的なルーティングとストレージにのみ使われるダムサーバーのためのものなんだ。この場合、Nanitはルーティングや(永続的な)ストレージを行っていないように聞こえる。アップロードの唯一の目的は、処理をクラウドにオフロードすることだから。そうなると、トランスポート暗号化(通常はTLS)は可能だけど、エンドツーエンド暗号化は不可能だよね。もしエンドツーエンド暗号化で同じ機能を望むなら、動画分析をローカルで行って結果をアップロードする必要がある。全体の動画をアップロードするのではなくね。これにはおそらく、より強力なハードウェアが必要になるか、指定されたコンピュータや電話にオフロードする方法が必要だろうね。

そもそも、これにクラウドサービスが必要な理由がよくわからない。赤ちゃんは普通、少なくとも一人の信頼できる大人が近くにいる状況に置かれるんじゃないの?

自己ホストのビデオはそんなに難しくないけど、赤ちゃんモニターに特化したソリューションは誰も作ってないね。実際、そんなに簡単じゃないよ。実際に本当に簡単なのは、カメラとそれにアクセスしようとしているデバイスが同じネットワークにいるときだけ。発見のためのブロードキャスト、それだけ。だけど、昔コンピュータ修理してたときに、Wi-Fiで「クライアントアイソレーション」をオンにしてる人も見たから、これが必ずしも機能するわけじゃないんだよね!でも、その前提が崩れると、例えば庭に出て雑草をチェックする時にWi-Fiが届かない場合、急にタスクがめちゃくちゃ難しくなる。 - 「最も簡単な」ケースは、ISPがあなたのWi-FiルーターにグローバルにルーティングされたIPv4アドレスを渡し、UPnPが設定できて、ユーザーがUPnPを設定していること。カメラはここでポートを開けるリクエストをするだけ。それでも、製造者としては、ユーザー、IPアドレス、ポートのマッピングを保存するサーバーが必要だよね。(ユーザーのモバイルデバイスやISPが非標準ポートをブロックする厄介なファイアウォールを持ってないことを願う必要もあるし) - UPnPがない?そしたら、製造者としてはSTUN/TURNサーバーが必要になるか、ユーザーに手動でポートフォワーディングを有効にする方法を説明しなきゃいけない。 - 最悪のケース:ユーザーのISPがIPv6だけ、CGNAT、ダブル/トリプル/... NATなどを使っている場合、顧客に十分なIPアドレスを供給できないから、これはほぼ不可能だよ。STUN/TURNを使っても、途中で問題が起こる可能性がめちゃくちゃ多い。 - 理論的には、全員がグローバルにルーティングされたIPv6アドレスを持っていて、すべてのISPがルーティングをうまく機能させている世界でも、問題は解決しない。なぜなら、消費者向けのISPルーターは、オンラインゲームのチーターが古いバージョンのゲームをプレイしている相手を「ボコボコにする」のを避けるために、IPv6でファイアウォールを有効にしているから。悲しい現実だけど、クラウドサービスを運営するのが、どんなスマートなものでも顧客が期待するように動作させる唯一の痛みのない方法なんだよね。それに加えて、ビデオを保存できるNASは約300ドルくらいで、24/7動作できるHDDが必要で、電力消費は約10ワットくらい。これだけでも結構なコストだよね。確かに、HNの「オタク集団」は数日で動くものを作れるかもしれないけど、赤ちゃんがベビーベッドから脱出したかどうかを見つけるための簡単なAIを含めてね。でも99%の人は「ルーターの設定ページを開いてUDPポート65535を通過させてください」ってところでつまずくと思う。なぜなら、5年前に設定したパスワードを忘れちゃってるから。

自己ホストのビデオはそんなに難しくないけど、赤ちゃんモニターに特化したソリューションは誰も作ってないね。 でも、彼らはホスティングしているわけじゃないみたい。処理して、一時的に保存しているだけで、キューに入れている間。正確に睡眠状態や危険な状況を検出する完全に自己ホストのAI駆動の赤ちゃんモニターは、今は信じられないくらい高価だろうね。でも、数年後にはそうでもないかも。

そのすべてのビデオ/音声映像がAIトレーニングデータとして使われたり、売られたりすることを想像してみて。

タイトルは「正しいサービスじゃないのにS3を使った」ってすべきだったね。

そうそう、最初に思ったのは「一体なぜ誰がS3が何百万もの小さな一時的ファイルを保存するのに適したサービスだと思うのか?」だったけど、今は彼らがRedisみたいなものを使う代わりに、自分たちのインメモリストレージを発明したみたい。もし彼らのDIYのやつがクラッシュしたら、動画は失われるのかな?最初からKinesisやSQSに送らなかったのはなぜだろう?

僕は十分年を取ってるし、常識もある(どっちでもいいけど)から、赤ちゃんの動画をどこかにアップロードするのってめっちゃ変だし、怖いし、そもそも必要ないと思う。これは問題のない解決策だよ。さらに悪いことに、親や若い親の不安を煽ってる。ここには何もない - 必要な製品じゃないよ。赤ちゃんを「追跡」する必要なんてないし、寝てる間に見る必要もない。毎回の呼吸を見せる必要もない。人々は何世紀も前から、赤ちゃんをこの超変な監視社会に生まれた瞬間から登録せずに育ててきたんだから。なんてひどい、めちゃくちゃな世界を自分たちで作り上げてしまったんだろう。

世界がどう messed up してるかについての議論の中で、これが一番馬鹿げてる気がする。人それぞれ育て方が違うし、文化も進化する。君は「古い考え」を持つ自由があるし、こういうサービスを使う人たちにも自由がある。公に発表してるわけじゃないしね。話題のサービスは特に、サーバーに一時的に保存してMLを使って寝てるか泣いてるかを検出するだけだから、無害に思える。多くの人が自分で計算できるし、自分の信念に基づいて選択をすることができる。それが本当の自由だよ。

彼らは合計でいくらの中で50万ドルを節約したの?500,001ドルか5500万ドルか?この情報がないと、投稿は意味がないよ。

おそらくかなりの額だと思う。S3は安いサービスの一つだからね。AWSからすべてのコンピュートを移行することを検討しているけど、S3(とSQS)はまだ素晴らしい価値があるから、残すサービスになると思う。

最初から間違ったアーキテクチャを使ってた気がするし、今はその問題をキャッシュの追加層でごまかしてる感じ。平均2秒間だけS3に動画を置く実用的な理由は、追加の冗長性を提供するためだけで、それをキャッシュに置き換えるとほとんどの冗長性が失われる。もしこれを実際のサーバーにアップロードしたら、サーバーがアップロード時に処理できて、S3やSQSのキュー、ラムダを一気に排除できる気がするんだけど…

そう、シンプルだよ。S3はオブジェクトを保存するためのもので、処理のためのものじゃない。こんなに悪くて複雑なクラウドデザインがどうして生まれたのか、全然わからない。

自分でもS3を作ったよ。以前に2つのS3互換サービスを使ったけど、いつも何か問題があったんだ(最初のは特定のファイルがアップロードできなくて、サポートも役に立たなかった;2つ目はファイルメタデータを正しく移行できなかったから、これはずっと問題になるだろうなって思った)。結局、ただのバカなファイルストレージに過ぎない。基本的なHTTPS APIレイヤーとファイルメタデータや場所を管理するロジックを書く必要があるだけ。それだけ。テストを含めて数日かかるけどね。でも、ファイルのアップロードやダウンロードについても考えなきゃいけない。すべての役割を果たす単一のサーバーを持つことはできないから、ボトルネックができちゃう。だから、このファイルストレージはエンドユーザーが直接アクセスしないプライベートバックエンドサービスになった。ユーザーがファイルをアップロードできるようにするためだけのアップロードサービスを追加したんだ。そして、その後に中央のファイルストアにアップロードすることで、実質的に分散ファイルアップロードキューを作った(ファイルIDの作成と検証に関するもう少しロジックもある)。次に、ダウンロード用に独自のCDNが必要だった。でも、カスタムアクセス処理を使っているから、商業サービスを使えなかったんだ(トークン経由のアクセスはサポートしているけど、私にはうまくいかなかった)。これは難しかったけど、ノード同士でファイルを配布し合って、常にオリジンから取得するのを避けるために、ネットワークコストを抑える必要があったから。だから、ノード同士が見つけ合って、話し合って、誰がどのファイルを持っているかを知る必要があった。要するに、自分で作るのは思ったほど難しくないし、むしろ好ましいべきだと思う。時間を節約するために、最初はクラウドを使ってもいいけど、一度動き出してビジネスアイデアが顧客によって検証されたら、すぐに自分のインフラに移行して、クラウドサービスの天文学的なコストを避けるべきだよ。ちなみに、私もブログ記事に書かれていたように、ビデオ処理をやってるよ :)

これは明らかなポイントかもしれないけど、(それ以外は素晴らしい)記事の中で言及されていなかったので、興味があったのは、彼らが最終的に自家製のインメモリキャッシュソリューションで使用した「読み取り時削除」をS3で実装することでのコスト削減について。S3の請求ページではこれが見えないけど、他のAWSサービスのように使用が秒単位で請求されるなら、節約はかなり大きいかもしれない。彼らが文書化しているソリューションは、S3の「冗長性削減」ストレージオプションにも一致するから、最初からこれを有効にしていたことを願ってる。