category: プログラミング 作曲の補助ツールを作るまでの日記
# 日記# 終わり

【26日目】インフラを構築し、サービスを開始する

投稿日 最終更新日

2024年5月25日～2025年1月4日

サービス名を考える

ここまでサービス名はconfig("app.name")で逃げて来たんだけど、ドメインの取得で必要になるのでもう決めなきゃいけない。

サービス名の決定で辛いところは、サービスの本質でないのに重要で、進捗が見えにくいというところだと思う。

進捗が無い、進捗が思い通りにならないのは意外と結構辛い。

今のところ、私のサイトは「作曲知識を記事で共有するサイト」だけど、核の部分は作曲知識の共有だと思っている。

だから、それに沿ったネーミングができたら嬉しい。

また、以下の条件がある

ドメインは国内のICANN公認レジストラが出しているサービスを使うのが無難っぽい。

正直、2,3ヵ月くらいどうしようか悩んでるんだけど、これというのが思いつかない。

音楽の「メロディ」と「情報をつないでいく」という意味の「DNA」を合わせてmelodnaというのを思いついたんだけど、「女の子みたい」という誰かの意見で揺らいでしまった。

更に、音楽＝メロディなのかという問題もある。
あと、MelodyneというDTMで有名なプラグインがあり、それと混ざってややこしい。

また、迷走してひらがなのサービス名を考えたりもしたんだけど、ひらがなのサービス名はこういう文章中に現れると分かりにくかったのでぺけ。

このサイトの目標、目的を整理する

このサイトの目的が私の中にしかないので、整理したい。前もやった気がする。

整理した結果からサイト名が決まればいいなぁ。
どうまとめるのがいいんだろうか。

このまとめには私目線と、社会的目線の２つがある気がする。

私目線

私がなぜこのサービスを作り、提供し続けたいか。

  • 音楽が大好きだけど、音楽制作がめっちゃ苦手
    • 人生で一番感動するものが音楽
    • 音楽制作始めるけど、2年で一曲も完成しないくらい苦手
    • 個人での音楽制作のむずかしさや辛さを実感してるので、どうにか和らげたい
  • プログラミングが得意
    • やっていて苦痛じゃない
    • プログラミングやった後DTMやると尚更実感する。
  • じゃあ、得意なプログラミングで音楽制作を補助できたら私もみんなもハッピーだよね ここまでの内容だと知識共有サイトじゃなくても、音楽制作の難しさが和らぐものをプログラミングで作れば当てはまる。

じゃあ、なぜ音楽知識共有サイトなのか。

それは、必要な音楽制作の知識を仕入れるのが難しいと感じたから。
音楽制作知識を検索する難しさ、音楽制作の知識を表現する難しさ。それに付随して情報が集まる嬉しさとか。

この課題を音楽制作知識を共有するプラットフォームで和らげる事ができないかなという。

音楽制作知識を検索する難しさ

音楽のデジタルな表現は楽譜・midi・mp3・DAWのプロジェクトファイルなど、普通の検索エンジンで検索できないものが多い。

だから、DTMerが何か情報を仕入れたいとき、悩んだ時に私たちは作曲のアナログな悩みを自分なりの検索できるデジタル情報に変換し、検索をかける必要がある。

例えば、一般的にケロケロボイスと言われているものの本質は”あれ”なんだけど、こうやって文章だと「ケロケロボイス」「ピッチ補正」「オートチューン」「ロボットボイス」などと表記が揺れるし、これらの単語を知らないと文章では”あれ”としか表現できない。

そんな辛さが音楽制作の検索にある。

私のサイトでは今の初期段階だと文章による検索しかできないけど、可能ならば他のアプローチから検索できるようにもしたい。

音楽制作の知識を表現する難しさ

これ、よく考えたら検索の難しさと難しい理由は一緒かも。

アナログなものをデジタル空間で表現する以上、デジタルに変換しないといけない。 しかも、音楽は表現方法がMIDI、DAW、動画、画像、音源ファイル、楽譜、文章と結構多い。 それを包括化または対応したいし、これも音楽制作に特化したサイトだからこそできる。

あと、音楽は芸術の1つというのもある。

音楽は芸術で、だからこそ私は音楽制作の悩みを「センス」という雲をつかむような表現で片づけてしまうことがある。
音楽制作の悩みやその解決には絶対に理由があり、人に伝わるよう表現できるはず。

情報が集まる嬉しさ

私がQiitaを使っていて良いなと思ったのが、Qiita内に情報が集まること。

エンジニアが主なQiita内に情報が集まるから、エンジニア向けのニッチなリコメンド、関連記事を提供できる。また、投稿する人が無名の人でも見てもらえる。

あと、Qiitaというサイトはサイト自体が評価されているからSEOがめっちゃくっちゃ強い。
初めて書く人が書いた記事でも有益な記事なら2日もあれば検索上位にいる。
でも、それにはデメリットの側面もあって、あまり良くない記事が上位を占めるという問題もある。

ユーザー目線

次はユーザー目線からした、このサイトを使う理由。

閲覧する側の理由はいくらでもあると思うんだよね。 ○○がわからないから。○○を解決したいから。 それで疑問で検索→記事に当たるという感じで使ってくれるようになると楽観的でいる。

記事を書く理由は何だろう。私がQiitaや個人ブログで記事を書く理由は情報の還元をしたいというものだったし、この日記を書く理由は知識の保存と自分が監視されている感。

じゃあ、同じ理由で書いてくれる人はいそうだし、こんなの考察してても始まらないので早くサービス開始しよう。 正直、こんなこと言うと悲しいんだけど、なんも宣伝しなかったらユーザー数は確実に0人なので、とりあえずサービス開始してもここらへんは間に合うと思う。

このサイトの目標と解決手段

このサイトは、私のような個人DTMerが理想の音楽を作れるようになるのが目標。 その為に手段・価値として知識の共有があり、少しでも悩みの解決に繋がれば御の字という感じ。

サービス名の考えで進捗がある感を出す為に

何かを進める上で辛いのが、思った通りに物事が進まないこと。 プログラミングは手を動かせば進捗が出るのに対し、サービス名決定は進捗が出ている感が少ない。

そこで、進捗がある感を出す工夫が大事になる。

人にもよると思うが、サービス名には意味が込められていることが多い。

ということは、以下のプロセスを辿ると良さそう

  1. このサービスに込められた想い、達成したいこととまとめる
  2. それに関するキーワードをまとめる
  3. キーワードを足し引き合成したりする
  4. 以下1~3の繰り返し

「サービスの想い、達成したいこと」はドキュメントとかにまとめてもらうとして、「キーワードをまとめる」作業は私なりの方法があるので残しておく。

キーワードをまとめる

「まとめる」とあるけど、発想するフェーズも含まれる。

個人的におすすめなのがマインドマップ。

知ってる人は知ってると思うけど、樹形図のようにアイデアをまとめていくフレームワークっていうのかな。

例えばYoutubeのような動画共有サービスで考えるなら マインドマップの画像 こんな感じで枝分かれさせていってキーワードをまとめる。

私はMindMup2というサービスを使っているんだけど、このMindMup2の嬉しいところが、親をコピーすると子もリスト化されて一緒にコピーされるところ。

例えば、上の画像でいう「拡張子」という親をコピーすると

  • 拡張子
    • mp4
    • mov
    • avi

こんな感じでリストで表示される。
html対応してなくてもインデントで表示される。

これができると、ChatGPTにマインドマップの構造を投げられるんだよね。
マインドマップで行き詰ったときにChatGPTにそれを投げれば、そこから関連したキーワードを出してくれる。

一人でも色んなキーワードが出せるのでよいし、マインドマップを埋めることで進捗がある感が出るので良い。

サイト名を決めた

このサイト名は「dtmru」です！
88888

dtmruの由来は、「DTM」と「できる」の合わせ言葉。
このサイトは、DTM（作曲）ができるようになるのをサポートするのが目的なので。

この「できる」は単純に作曲ができるようになるという意味もあるし、私の目標である「感動する音楽を作れるようになる」という意味もある。

この名前のプラス点、マイナス点を挙げる。

  • プラス点
    • 何のサイトかわかりやすい
      知識を共有するサイトかは分かりにくいかもだけど、DTMに関するサイトなのはわかる。
    • 意味がしっかりこもっている
      「意味的にちょっと違うかも」が無いのは良い。
    • ドメインが短い
      dtmru.comは奇跡的にプレミアムドメインじゃなかった。
    • 程よくダサく、親しみやすい
      カッコよすぎてもどうなんだろうと思ってたので。
    • 日本のサイト感
      日本でのサービス展開なので、DTMという和製英語を入れるのはちょうどよいのでは。
  • マイナス点
    • 発音すると長い
      「ディーティーエムル」は長い。敢えて略すなら「エムル」とかどうだろうか。
      ちょっと発音しにくいのも×。
    • サイトの領域がDTM(作曲)に限定される
      個人規模だし、目標はDTMの悩み解消なのでヨシ。
    • DTMというキーワードとぶつかる
      良いか悪いかはわからないけど、DTMという単語とぶつかってしまいそうなのは、SEO的にどうなのだろうかとは思う。
    • 普通にちょっとダサい
      もっと横文字っぽいサイト名も思いついてはいたんだけど、しっくりこなかったり。
      DTMるはしっくり来ているけど、ダサめ。

とりあえず、名前が決まったのでドメイン取得やらのフェーズには入れる。

ロゴを作る

そういえばロゴも必要だった。
ロゴは初期段階であれば後から変えるのは簡単だと思うので、ブラウザのタブに表示されるファビコンと簡単なロゴを作ろうと思う。

といっても、私はそういうデザイン系に長けていないことは明白なので、SPATIEみたいに簡単なロゴにした。

フォントはSIL OFLで、私のサイトでも利用しているNoto Sans JPを。
ロゴの画像 シンプルすぎるけど、リリース速度を優先する。

インフラを考える

ここらへんも日記としてめちゃめちゃ書き殴ったんだけど、書き殴りすぎてるのと、セキュリティ的に全然載せられないのでリリース後の私が考えていることを書く。

Laravel個人開発のインフラ構成どうする？

個人開発で、何も宣伝してないのであればユーザー数がとっても低いのは明白なのでとりあえずリリースを第一目標にするべきだと考えている。

その上で取り得る選択肢はAWS、GCP、Oracle Cloudなどの有名クラウド環境の無料枠か、VPSだと思う。

最終的に私はVPS + AWS SESにしたけど、その結論までの過程を残す。

AWSで考えてみる

サービス構成&要件は以下のような感じ

  • Laravel(PHP)
  • Meilisearch
  • MySQL
  • Redis
  • Apache
  • メディアファイルを保存するサーバー
  • メールサーバー
  • 長期運用する予定
  • スケールによって変わるだろうが、費用は全部で月1万くらいに抑えれたらいいなぁ

こんな感じ。

この要件で本格的に運用するなら

  • Amazon EC2 : Webサーバー
  • Amazon RDS : MySQL
  • Amazon S3 : ストレージ
  • Amazon SES : メールサーバー
  • Route53 : DNS
  • Lambda : HLSに変換する非同期処理を実行

が必要そう。

全部軽く見ていく。

Amazon EC2

Amazon EC2。名前くらいは聞いたことあるよね。
Amazon EC2を簡単に言えばAmazonのIaaS。

従量課金制だしスケーラブル。
一応、これだけでもEC2のサーバーインスタンス内でMySQL動かしてストレージの保存もEC2にすればLaravelは動くはず。

小規模であればEC2じゃなくてもAmazon Lightsailという選択肢がある。
こっちのほうが安いし従量制料金じゃないので課金されすぎがなくて安心。

Amazon RDS

Amazon RDS。
Amazon RDSはリレーショナルデータベースを運用するもの。

MySQLには勿論対応している。

なんでわざわざDBを別で管理するかなんだけど、スケーリング、バックアップ、セキュリティ的な理由らしい。

個人開発の料金のボトルネックの理由になりがち。

Amazon S3

Amazon S3。
Amazon S3は単なるストレージ。

私の場合、画像や音源ファイルを保存することになる。 こちらもバックアップやスケーリング等の理由で分けてるのかな。

Amazon SES

Amazon SES。
メール配信サービス。

私の場合、登録の認証メールで利用する予定。

Route53

Route53。
DNSサービス。ドメイン登録とかもできるっぽい。

AWSで完結させたいなら使うべきだけど、日本サービスで管理するより高い。

Lambda

Lambda。
サーバーと違い、イベント発生時にだけ働くサービス。
これを使いサーバーレスも実現できるみたい。

私の場合、HLSの非同期処理に使えそうかなと思ったので入れてみた。

EC2とかだとインスタンスの性能が選べるんだけど、Lambdaは選べない。
じゃあ処理性能とかどうなってるんだろうと思ったんだけど、どうやらメモリの割り当ては選べるらしく、メモリの性能に比例してCPUもよくなるっぽい。
勿論、料金もお高くなる。

AWSの気になる料金

料金に関わる変数が多すぎて一概にいくらとは言えないんだけど、以下の条件と前提で試算してみる。

  • 無料枠は考慮しない
  • 東京リージョンを使う
  • EC2とS3の転送量は同一リージョンであればノーカン
  • EC2の転送量はネットワークからであればノーカン
  • EC2とS3転送量はAWSからネットワークまたは別リージョンの時にカウント
  • PVはすべて記事閲覧とする
  • 1記事の閲覧にメディアファイル2MB利用すると仮定
  • 1PVあたりHTTP通信合計500KB利用すると仮定
  • アクティブライターは毎月音源ファイル80MBストレージに保存する
  • 音源ファイルの半分の値でHLSも保存される
  • アクティブライターは毎月画像ファイル20MBストレージに保存する
  • 後から気づいたけど、Lambdaを考慮してなかった。多分そんなかわんない。

この前提に明確な根拠は無いので、大幅に間違っている可能性はある。
一回この前提で小・中・大のスケールに分け、かかりそうな料金をみてみる。

小規模

  • 月のアクティブライターが10人いる
  • 月のPVが1万

の場合

  • EC2
    • インスタンスはt4g.micro
    • データ転送量500KB*1万PV=5GB
    • ストレージはわからんけど大体5GBくらい
  • S3
    • 容量は(100+HLSの40)MB*10人の1.4GB≒2GB
    • データ転送量は2MB*1万＝20GB
    • 読み込み回数は適当に10万回
    • 書き込み回数は適当に1万回
  • RDS
    • MySQL
    • インスタンスはdb.t4g.micro
    • 台数1
    • 冗長構成なし
    • ストレージ適当に1GB
  • Route53
    • 管理するドメイン数1個
    • クエリ数1万
  • SES
    • EC2からの送信数1000(1000回認証メール送る仮定)
    • データ転送量文字だけなので適当に1GB

これでざっくりAWSという素晴らしいサイトで試算すると
ざっくりAWSの円グラフ
大体現時点のレートで月4600円。「ざっくりAWS」の共有URL。

最小規模にしては高いなあというのが正直なところ。
しかし、この規模であればRDS使わずにEC2だけで余裕だと思われるのでもう少し安くはなりそう。

中規模

  • 月のアクティブライターが100人いる
  • 月のPVが10万

の場合、

  • EC2
    • インスタンスはt4g.small。適当
    • データ転送量500KB*10万PV=50GB
    • ストレージはわからんけど大体5GBくらい
  • S3
    • 容量は(100+HLSの40)MB*100人の14GB
    • データ転送量は2MB*10万＝200GB
    • 読み込み回数は適当に100万回
    • 書き込み回数は適当に10万回
  • RDS
    • MySQL
    • インスタンスはdb.t4g.small。適当
    • 台数1
    • 冗長構成なし
    • ストレージ適当に10GB
  • Route53
    • 管理するドメイン数1個
    • クエリ数10万
  • SES
    • EC2からの送信数10000(10000回認証メール送る仮定)
    • データ転送量文字だけなので適当に10GB

これで試算すると
ざっくりAWSの円グラフ
大体月13000円。正直、ここが収益0でできるギリギリという感じ。
「ざっくりAWS」の共有URL。

RDSってそんなにお金かかるんだね。

大規模

  • 月のアクティブライターが1000人いる
  • 月のPVが100万

の場合、

  • EC2
    • インスタンスはm7g.large。適当
    • データ転送量500KB*100万PV=500GB
    • ストレージはわからんけど大体10GBくらい(ログやらなんやら増えると思うので)
  • S3
    • 容量は(100+HLSの40)MB*1000人の140GB
    • データ転送量は2MB*100万＝2000GB
    • 読み込み回数は適当に1000万回
    • 書き込み回数は適当に100万回
  • RDS
    • MySQL
    • インスタンスはdb.m7g.large。適当
    • 台数1(これ本当は複数台構成の方が良いと思う)
    • 冗長構成なし
    • ストレージ適当に100GB
  • Route53
    • 管理するドメイン数1個
    • クエリ数100万
  • SES
    • EC2からの送信数50000(50000回認証メール送る仮定)
    • データ転送量文字だけなので適当に50GB

これで試算すると
ざっくりAWSの円グラフ
だいたい86000円。ここまでくると広告やらなんやらでマネタイズできてないと無理という感じ。
「ざっくりAWS」の共有URL
しかも、S3は時間とともに容量を食っていくのでもっとかかるはず。

とりあえず、間違っているところ、考慮できていないところは多いと思うけどなんとなくはわかった。

また、挙げた5つのAWSのサービス以外にもストリーミング再生用のサービスがあったり、認証サービスがあったり、ファイアウォールサービスがあったりと、連携の強さ・包括力の強さがAWSの強みだと感じた。

もし、AWSで構成するなら無料枠でとりあえず様子見してっていう感じになると思われる。

なぜAWSではなくVPSを選んだか

結論だけ言えば、サービスの規模感に合わないのと定額にしたかったから。

個人開発サービスってなにかしら元から影響力が無い限り、必ずユーザー数はめっちゃ少ないところから始まる。

私のサービスはまだ多くの人に使ってもらうようなクオリティじゃないし、最初は規模を小さく運営して改善を重ねていきたいと考えていたので、スケールとかを考える必要が無い。
それに加え、AWSは無料枠はあるものの従量課金制ではあるので、そこが個人的にちょっと嫌だった。

予測可能なコストを取りたかったので、そうなると定額でサービスを運営できるVPSを選んだ感じ。

インフラ構成

サービス開始時点(2024/12/31)でのインフラ構成は

  • VPS(Conoha)
  • Amazon SES
  • Cloudflare(DNS/CDN/DDoS)

という感じに落ち着いた。

VPS(Conoha)

VPSサーバーはConohaを利用。
理由は、

  1. 12ヶ月契約だとキャンペーンで700円/月
  2. キャンペーンじゃなくても1000円/月　っぽい？　もしかしたら2000円かも？
  3. ストレージ100GBもある
  4. CPU 3 core
  5. RAM 3GB
  6. AlmaLinux OSが使える
  7. 時間課金プランもあるので、ステージング環境に便利(上の性能で3円/1hほど)
  8. 学割(Conohaカード)あり
  9. このはちゃんがKawaii
  10. 他の方の個人開発ブログを覗くとConohaを使っている人が多いイメージだった

というところに惹かれた感じ。

私が見たときの価格表は以下のような感じ
Conoha VPSの料金表

というか、Conohaにした理由を色々書いたけど、正直contaboという格安VPSでない限りどこのVPSサービスも大差ない感じはした。

そんなcontaboを利用しなかった理由は

  1. 即時契約ができなそう（契約していないためわからないが、英語メールでのやり取りが必要そうで、年末に契約できるか心配だった）
  2. 日本サーバーを選択するとConohaと料金大差ない
  3. 海外サービスでサポートが心配
  4. 選択できるOSがUbuntuのみ？

という感じ。

Amazon SES

認証に使うメールサーバーはSESを利用した。

Conohaのメールサーバーを使う手や、VPS内にサーバー置くことも一応できるはず。

でも、メール送信しかしないし、送信1000件で0.1ドル(添付ファイルの 1 ギガバイト (GB) のデータごとに 0.12ドル)と、めちゃんこ安いのでこの選択に。

サンドボックスというテストモードみたいのを解くのに申請が必要で、1日くらいかかるのと、独自ドメイン必要なのは注意。

Cloudflare

ドメイン契約自体は日本のレジストラだけど、DNSをCloudflareにした。

こうしてCloudflareをプロキシすることで、freeプランでもCDN、DNSに加えDDoS対策をしてくれる。

普通にどうやって利益だしてるのかわかんないくらい高待遇ではあるんだけど、ありがたみながら利用させていただく。

これから

とりあえず、かなり時間はかかっちゃったけどデプロイ&サービス開始まではこぎつけた。

ただ、ほんっとうにただ記事を作って投稿できるという最低限の機能しか無いので、dtmruをわざわざ使う理由がほとんど無いというのが、現状。

そのため、α版→β版に向け、主に以下の実装をしたいと考えている。

  1. DTM特化だからこその機能追加
    1. 音サムネイルの追加
    2. 音の簡単な加工投稿機能の追加
  2. UXの改善
    1. WYSIWYGエディタの改善
    2. 一部の非同期処理化
    3. その他細かいユーザーインターフェースの調整

おわりに

これでこの日記の目標である「作曲の補助ツールを作る」は達成できた。
でも、このツールで私の目標である「自分自身が感動する音楽を作る」はまだ達成できていない。

本当に、作曲って難しいと思う。

そんな誰かの作曲を、私の作曲を、少しでも手助けできるよう精進していきます。

category: プログラミング 作曲の補助ツールを作るまでの日記
# 日記# 終わり