一人でがっつりAWSでサービス開始しましたが、運用を始めると多くの問題が起きえます。
今回はコストに対する問題を,AWSだけでなく、他のクラウドを活用することで大きく削減できたという事例を共有したいと思います。

例えばNetflixが

Netflix、マルチクラウド対応の継続的デリバリを実現する「Spinnaker」をオープンソースで公開

といったオープンソースを公開していることを鑑みるに、すでにマルチクラウドでの運用は行われていることでしょうし、今後はこういった事例も多くなっていくことでしょう。

クラウドを複数使うにあたった経緯

前回

goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話

といった記事でリリースしたおしゃべりマルチというサービスですが、おかげさまでユーザー数も順調に増え、利用者に楽しく使っていただいております。

ただ、運用してみると、急激な成長やコスト面の見積もり甘い部分があり、リリース前の見積もりに比べて大きく増加傾向にありました。特に問題となりそうなところが、

特にネットワーク通信費がかかりすぎていた

こちらは、リリース前からちょっとどうなるか不透明な部分だったのですが、予想よりユーザーさんが楽しんで使ってくれた結果、見積もりより大きく超えてしまいました。

リリースしたばかりなのですが、元々コストが大きく増加することも設計時にある程度想定していて、対応策も頭には入れておいたので、これを解決するための対応を早めに打つことにしました。

対応したこと

コスト高のサービスコンポーネントを別のクラウドに移行した

３つの大きなサービスコンポーネントのうち、２つをネットワーク通信コストが下がるクラウドへ移行しました。移行先のクラウドを検討した結果,通信費を定額にできるクラウドが存在したため、そちらへの移行を決定しました。

移行作業

DBなどデータレイヤに対するアクセスを全てAPI経由に切り替え

これは設計時から、意識していたのでそれほど大変ではありませんでした。元々データ層に依存しないように作りをしていたのですが、リリース優先で直アクセス実装にしていたところがあったのでそれらもインターフェースは大体同じのAPIアクセスを行うクラスに切り替えました。

goですべて実装していた為、この辺の移行の実装の修正は型の安全性に救われた部分が結構ありました。
ポータビリティ性も高い。

また、音声サーバーなどは、こちらが開発しているものではなくオープンソースのサーバーなのですが、こういうことを想定していたため、選定時からDB直アクセスではなく、API経由のアクセスができるかは調査はしておりました。リリース時はDB直アクセスでリリースしたのですが、こちらも今後利用できるようなライブラリ設計は作っていたので、API化してきりかえました。

サーバーの移行はansibleレシピをちょっと変更したくらいで終わった。

インフラ部分はansibleを使ってるのですが、AWS特有の処理などは入れてなかったため、移行先で利用するOSに微調整するくらいで終わりました。ただAmazon Linuxを使ってしまっていたので、ubuntuなどを利用しておけば、この作業すらなかったかなあと、ちょっとだけ設計の後悔をしました。

以上、マインクラフト用ゲームサーバー、音声チャットサーバー群の２つのサービスコンポーネント、台数でいうと数十台のサーバー群を一週間ほどで完了させました。

コスト面では大きく言えませんが、

ざっくりで10分の1くらいまで下げれました。

それだけでもかなりの削減なのですが、移行先が定額制なので、今後ユーザー数が増えれば増えるほど、その差は大きくなるはずです。

移行作業所要時間

大体１週間くらいで作業を終えました。人月でいうと3人/日程度です。設計当初から想定していたため、思ったほど時間がかからずほっとしました。

設計時にやっておくと良いかもしれないこと

自分のサービスがコスト面も含めて、どこがボトルネックになっていくかは想像しておく。

エンジニア自体がコスト感をきちんと意識しながら、サービスの設計、開発をすすめておくとこう言った問題を解決しやすい設計になっているかの観点も入れつつ設計でき、また今回コスト増が致命的になる前に、かなり早い段階でサーバー移行を決めたのですが、解決策が最初から頭には入れておいたので、いつ解決するかの決断も下しやすかったです。

自分のサービス形態の特質に合わせて、ライブラリやサービスの境界を分離できるようにしておく

マイクロサービスなどの話が盛り上がっていたりしますが、まだサービスが小さいうちからなどまで考えると、ただ実装コスト、運用コストが増えてしまいます。今回のケースのように、サービスの成長した時のイメージを描いて、分離しておけば、メリットが出ると分かっている部分から始めておくと良いかと思います。

あまりにも1クラウドに依存しないような設計にしておくと柔軟性が上がる。

インフラ面をがっつりAWSの機能を使うと、運用コストは下がるのですが,あまりにもロックインしすぎると別のクラウドを利用したいとう選択肢になりずらいかもです。インフラ面のAWS依存は、正直インフラの面倒まで自分一人なので、AWS使い倒したほうが楽だったかもしれませんが、このような問題に対応できるようにAWS依存の部分は極力減らす方針で整備しておいて助かりました。

思うこと

自分自身新規サービスを立ち上げることが非常に多いのですが、いつも思うのはサービスをヒットさせることは非常に難しいと思っています。いつ資金が尽きる、打ち切られる可能性があるわけで、エンジニアとしてのできる努力の一つとしてこう言ったコスト削減に対しても、手を打てるように考えておくことも重要だと実感しました。

あとは移行して思ったけどgoで作っておいたおかげで色々とスムーズに進んだと思う。一番面倒だったのメインじゃないバックエンドで使ってるruby周りだった。。。

今後もサービスをヒットさせるための努力やアイデアをどんどん実行していきます。

UUUM株式会社ではその他様々な技術課題を解決していただけるエンジニアを募集しております！

「YouTuberプロダクション」にとどまらないUUUMが挑む、ゼロイチのプロダクト開発

UUUM攻殻機動隊