AWS を使わず、レンタルサーバーで自社のアプリを動かすと決めた理由

自社のアプリのサーバーは、AWS（Amazon のクラウド）ではなく、すでに使っているレンタルサーバー（Xserver）に置きました。大きな音声は各社のオーナーの Google ドライブに置き、文字起こしや採点の結果、利用者の情報や設定だけをレンタルサーバーに置く形です。

接客の録音アプリ（TalkLens）を、ほかの会社にも使ってもらうアプリとして作り直す時、サーバーをどこに置くかを決める必要がありました。最初に考えたのは、使う人が増えても自動で規模を広げられる AWS（Amazon のクラウド）です。

けれども、私たちは AWS を採りませんでした。音声は各社のオーナーの Google ドライブに置き、文字起こしや採点の結果、利用者の情報や設定は、すでに会社のサイトで使っているレンタルサーバー（Xserver）に置いています。この記事は、その判断の理由の記録です。

最初は AWS（S3・Lambda・DynamoDB・Cognito）を考えた

録音のアプリは、使う店舗が増えるほど、音声のファイルが増えます。音声は大きいので、置き場所と、それを処理する仕組みが要ります。そこで最初は、AWS のファイルの置き場所（S3）、必要な時だけ動く処理（Lambda）、データベース（DynamoDB）、ログインの仕組み（Cognito）を組み合わせる形を考えました。

音声を、各社の Google ドライブに置く

大きな置き場所が要るのは、音声があるからです。そこで、音声を私たちのサーバーに置くのをやめました。

こうすると、サーバーが扱うのは、文字（文字起こしと採点の結果）と、設定の情報だけになります。設計の時の見積もりでは、録音1件あたり約11KB（文字起こし約9KB、採点約2KB）、1社の90日分でも約30MB、100社でも約3GB です。この量なら、すでに使っているレンタルサーバーで十分に扱えます。

レンタルサーバーに置いたもの

ほかに採らなかったもの

同じ考え方で、ほかにもいくつかの選択肢を採りませんでした。

• Google Workspace の共有ドライブ：Workspace の契約が要り、契約していない店舗が使えなくなる
• Apple の CloudKit：個人の iCloud のアカウントに結びつく作りで、「会社にスタッフを招く」形を作れない
• 予備の文字起こしの外部サービス：1つでも持つと、名前や料金や仕様の変更を追い続ける手間が増える

どれも、「長く保守できるか」「小さな店舗が使い始められるか」で判断しています。

規模が大きくなったら

レンタルサーバーには、AWS のように自動で規模を広げる仕組みはありません。そのため、処理を順番に流す仕組み（ジョブの待ち行列）を作り、同時に動かす処理の数を決めて、少しずつ流しています。サーバーの上で動く処理の数を増やす時も、設定の値を変えるだけにしました。

もっと大きくなった時に別の場所へ移す判断は、その時の実際の量を見て行います。少なくとも今は、すでに慣れているサーバーで、確かめながら動かせることを大事にしています。

まとめ

• 最初は AWS を考えたが、仕様の変更やサービスの終了が多く、長く任せられないと判断した
• 音声は各社のオーナーの Google ドライブに置き、サーバーは文字と設定だけを扱う
• 文字と設定だけなら、すでに使っているレンタルサーバーで十分に足りる