AIシュリーマンは「契約企業のサイトから script タグを読み込んでもらい、それによってページ内を翻訳する」という仕組みです。
そのためサイトの規模によっては数億PV/月という規模のリクエストが発生します。しかも翻訳されて表示されるまでに時間がかかるとユーザー体験を損なうため、大量のアクセスを捌きつつ1msでも速くレスポンスを返すことが求められます。
この記事では、その要求を満たすために選んだインフラ構成と、そこに至る判断の理由を解説します。多言語化を内製で検討している方の参考になれば幸いです。
全体の構成
サービスは大きく3つのコンポーネントで構成しています。
- Webサイトに対する翻訳処理サーバ
- 翻訳管理などを行うクライアント側ダッシュボード
- 検索エンジン向けに多言語静的ページを返す「SEOオプション」
それぞれ求められる性質が違うため、採用している技術も異なります。
翻訳処理サーバ：エッジで動かす
アーキテクチャ全体を通してもっとも特徴的なのは、Cloudflare Workers と Hono を全面的に採用している点です。
「世界中からのアクセスに対して高速に翻訳結果を返す」というサービス特性上、エッジでの処理は必須だと考えています。世界中に散らばった Cloudflare Workers はエッジロケーションで翻訳処理を実行できるため、どの地域からアクセスしても高速なレスポンスを返せます。
TCPが使えないという制約
Cloudflare Workers には TCP での通信が行えないという制約があり、これがデータベース選定の悩みどころになります。
ダッシュボード側では Firestore を使っているのですが、Cloudflare Workers から Firestore へは直接接続できないため選択肢から外れます。
接続できる選択肢としては Neon（PostgreSQL）、Cloudflare KV、Cloudflare D1（SQLite）などがあります。ただし前述のとおり1msでも速く返したいという要求があるため、検証の結果 Upstash（Redis）を採用しました。
従量課金で利用できるためコストコントロールがしやすく、障害時のサポート対応も迅速かつ的確で助けられています。
Cache API を徹底的に使う
Cloudflare Workers の利点のひとつが、Cloudflare 内の Cache API を使えることです。
Upstash も十分速いのですが、取得したデータを集約して返す処理があるため十数ms程度はかかります。そこで一度返した結果は一定時間 Cache API に保持しておき、同一の翻訳についてはこちらを経由して返すことで、さらに高速化しています。
Cache API はエッジごとにキャッシュされ他のノードからは読み出せないため、ヒット率はそこまで高くなりません。それでも十分な利点があるので「基本的にキャッシュできるものはすべてキャッシュする」方針で実装しています。
この構成により、レスポンスタイムは平均100msを下回る水準を維持できています。縮める余地はまだありますが、突き詰めるとインフラコストの肥大化との戦いになるため、バランスを見ながら少しずつ削っているのが現状です。
ダッシュボードのサーバサイド
管理画面側のサーバ処理は性質で分けています。
Next.js の API Routes で動かせる範囲は Vercel Functions 上で実行し、実行時間の上限を超えるような長時間処理やバッチ処理は Cloud Run で動かしています。モノレポ内でパッケージを分離し、処理の性質に応じて配置先を選ぶ形です。
この分離の判断基準はシンプルで、リクエストに同期的に応答する処理か、時間をかけてよい非同期処理かです。前者はサーバレス、後者はコンテナ、という切り分けにしています。
サーバレスプラットフォームは立ち上げ期のSaaSにとって手間もコストもかからない選択肢ですが、リクエスト数や転送量が増えてくると従量課金の項目が効いてきます。翻訳SaaSのようにリクエスト数が桁違いに多いサービスでは、この点を初期段階から意識して設計しておくことをおすすめします。実際に私たちも、エッジで処理できるものはできるだけ Cloudflare Workers 側へ寄せる方針を取っています。
SEOオプション：独自ドメインでの多言語ページ配信
JavaScript による翻訳だけでは、クローラーから多言語サイトとして認識されません。そのため事前に多言語化した静的ページを別URLで出力する「SEOオプション」という機能を持っています。
ai-translate.com に対して en.ai-translate.com のようにサブドメイン、あるいはサブディレクトリ方式でURLを分け、HTML生成の時点で多言語化する仕組みです。これを実現するには、顧客ごとの DNS（CNAME）設定と SSL/TLS 証明書の自動発行が必要になります。ここは Cloudflare for SaaS を使って実装しています。
Cloudflare for SaaS は、顧客の独自ドメインをホスティングする際に必要な証明書管理と DNS 設定を自動化するサービスです。証明書の期限切れ前の自動更新も行ってくれます。もともとは上位プラン限定の機能でしたが、現在は一般のプランでも利用できます。
「SaaS事業者が顧客ごとに独自ドメインをホスティングしたい」というニッチな要件向けの機能ですが、同種の要件が出てきたらまず検討する価値があります。
使ってみて感じたこと
全体を通して Cloudflare 関連のサービスをかなり使っています。機能面もさることながら、コストが圧倒的に優位なので助けられています。
一方で不便に感じる点もあります。CDN のキャッシュ Purge はプランによって細かい制御ができません。サポート対応もテンプレート的な回答になりがちで、込み入った問題は自力でドキュメントを読み込んで解決することが多いです。
とはいえ現状は利点のほうが上回っているため、引き続き積極的に使っていく方針です。
多言語化を内製する場合の勘所
この構成から一般化できることをまとめます。
- 翻訳結果の配信は読み取りが圧倒的に多い。書き込み性能より読み取りレイテンシとキャッシュ効率を優先して設計する
- エッジで完結できるかがコストを決める。オリジンまで往復する設計にすると、リクエスト数が増えたときに費用が線形以上に効いてくる
- クローラー対応は別系統で考える。JavaScript翻訳とサーバサイド生成は目的が違うため、同じ仕組みで両方を満たそうとすると無理が出る
- 顧客独自ドメインの証明書管理は自作しない。マネージドサービスを使うほうが確実に安い
多言語化そのものは翻訳の問題に見えますが、規模が出てくると実態はインフラの問題になります。翻訳品質と同じくらい、配信の設計に時間をかける価値があります。
