なんか、思いつくままに書きなぐったらこんなことになってしまった(*´∀`)
大きくなる一方
なんか、サービスが大きくなるにつれて、システムはどんどん複雑になって、管理するのが大変になっていくよなぁってのがある。
仮想サービスCber(しーばー)
例えば「Cber」(しーばー)って仮想サービスがあるとして考えてみる。じゃあ、CycleのCだってことで「自転車のシェア」みたいなサービスにしようか(適当)。あ、僕、あの、かっこいい感じの自転車は全然知らないので、ママチャリ的なのくらいのを想像してます。
ビジネスモデル
どんなビジネスにしようか?
自転車を持ってる人が使ってないときに貸してあげられる感じにしようか。月に1回くらい自転車ででかけたいなーって思うけど、買うのはなぁ、って人と、自転車持ってるけどいつも使うワケじゃないから有効活用できないかなーってののマッチング的な。あとは、観光地で自転車を持ってる人が、観光客に提供とか。かな。
自転車のオーナー
- 登録無料
自転車を借りる人
- 固定費月額100円(ただし、100円分のレンタル費を含む)
- レンタル
- 1時間100円
- 1日500円
これぐらいでどうかな。オーナーは月に3000円くらいになれば登録しようという気にもなるかな?月に10日貸し出すとしたら、1回で300円はオーナーに、残りの200円はCberがシステム運用とかでもらう感じ?1万ユーザーが1人平均月2日使ってくれたとして、400万か・・・。10万ユーザーぐらい必要なの?だめだ、こういうの全然分かんないや・・・。どれくらいだったら儲かるって言えるの?まいっか。
データモデル
さて、上記のビジネスモデルに対して、データモデルを考えてみる。
登場人物としては、自転車の所有者のOwnerと、自転車を借りるUserがいる。Ownerには、契約、振込先口座、貸出履歴、入金履歴、所有自転車、貸出可能日時、管理ツールアカウント、とかがあって。Userには、アカウント、基本情報、カード情報、レンタル履歴、支払い履歴、とかかな。
で、そういうのを全部リレーショナルデータベースに保存するのかな。
追加要件
サービスローンチ前に「法人オーナー」対応が必要だ!とかなったり。1年くらいして、サービスがなんとか生き残ってるので、拡大していこう!ってことになって。例えば、スポーツタイプの自転車のシェアもしようよ、とかなって。その場合、元が高価だからレンタル費用をアップしなきゃ。とか。ユーザーとかオーナーのレビューが必要だわ。とか。そもそも、ビジネスとして、Cber所有の自転車と駐輪場を持って、乗り捨てできるようにしよう!とか。
そういうのが出てきて、DBのテーブルはどんどん複雑になっていって、「このカラムはスポーツタイプフラグってなってるんですけど、0から5の値を取ります!」とか、なんだとか、そういうことになっていったりする未来があったりなかったりする。
変わり続ける
言いたいのは「そうならないようにするためには、追加要件を最初に考えておかなければならない!」ってことじゃなくて「追加要件を柔軟に取り込んでいきながらも、複雑さを抑えて、ビジネスを引っ張っていく」ってアーキテクチャだといいなってこと。「動いているものは触るな!」じゃなくて、ガンガン触りながら、変化しながら成長していく感じ。
DDD + Microservices
全然違う方向にそれたけど、そいういうわけで、サービスの規模が大きくなっていってもシステムの複雑さを抑えて攻めながら開発していくのに、DDDが良さそうだなと思って勉強してる。境界づけられたコンテキスト、という考え方が上記の複雑さを軽減してくれるんじゃないかと思っている。
で、勉強してるうちに「これを実現するための技術的な土台」みたいなものが自分の中に欲しいなぁって思ってるところで、Microservicesが出てきて、「あぁ、いいかも」って思ってるところ。
参照: www.nttdata.com
Spring Cloud
Microservicesのことを考えてたら、Spring Cloudが良さそうだなと思って触ってみてるところ。Spring Bootをベースにしてて、ほんとに「誰もが書く必要のあるコード」を既に用意してくれてて、自分で書く必要がないので、コアな部分に集中できて幸せ。
Azure
じゃあ、それをどこにデプロイして動かそうかな?って考えるんだけど。
Spring CloudならPivotal Cloud Foundryが相性良いだろうなー、何か分かんなかったら光の速さで教えてもらえる人もいるしなぁ、と思いつつも、CF自体は触ったことあるし、折角プライベートでごにょごにょするなら全然知らないプラットフォームを触って引き出しに入れておきたいなと思ってて。
参照: Cloud FoundryにSpring Boot/Java EEアプリケーションをデプロイしよう - BLOG.IK.AM
そんな折に、Azureのサブスクリプションをゲットしたので、Azureでやってみることにした。MicrosoftのDevOpsハッカソンで少し触ったことがあるけど、あらためてAzureのPortal開いて、自分の理解のできなさと自分のドキュメントの読めなさにしばらく絶望してた。全然分かんない。
Docker
しばらく逃避したあと、もう一度向き合ってみた。全然インフラの知識がないもんで、できるだけそっちに寄らないようにしたいなって思って。それと、Azure特有の機能はできるだけ少なくしておいたいかなーって。
なので、Dockerがいいかなと思った。Spring CloudのアプリケーションをDockerで動かす感じ。
DC/OS
でもDockerコンテナ2,3個ならいいんだけど、Microservicesで考えるとたぶん少なくても10個くらいとかになると思うので、全体をコントロールできるようなのがいいなーって思ってAzureを眺めてたらAzure Container Serviceというものがあった。ので、それを使ってみることにした。
Azure Container ServiceにはDocker SwarmとDC/OSが選べるみたいで、これまた、プライベートプロジェクトなので全然知らないDC/OSの方を選んでみることにしたのであった。