フレンバシーのシステムをどのようにして作ってきたか語ります（その１）
歳を取ると、たまには自分のルーツにふれる旅というのも悪くないなと思ったりもします。時々かつて住んでいた場所や、昔見た漫画とか映画とかを見ることで逆に新しい発見につながることがあります。
刹那的でもあるけど、人間はその時その時が全く異なるもので、同じ体験には絶対ならないから面白いのかもしれません。
フレンバシーの歴史の最初に登場するTokyoDinnerTicketの作りについてお話します。そのつくりは非常にシンプルで
お名前サーバー？にホスティング
PHPにPostgresという組み合わせ
フレームワークは一切使用しておらず、ロジックに当たるコードとHTMLは同じソース
Twillioのコードもある
設定ファイルにデータベースのIPが直書き
ソース管理システムは使っていない
など若干クセのあるシステムでした。何でこうなっているのかというところに関していうと、ここは播が知り合いづてに格安でやってくれるという業者に頼んだからというのがあります。この会社の人に私はかつて一度だけお会いしたことがあるのですが、もともとインフラエンジニアでコードを書くのが専門じゃないとのことでした。なのでモダンな開発に対する知見は無いということでした。
リーンスタートアップにおけるMVCを作るという意味合いではこれでもいいのかもしれません。実際にこれで利用者がつくようになったら改めて作り直しです。しかし、リソースが限定されているスタートアップの現場で、既に稼働しているアプリの作り直しは現実的ではありません。例え最小限の動くプロトタイプ（MVC）だとしても先を見越してちゃんと作るのは大事だと思います。
この話でふと思い出したことがあります。以前とある会社の社長がパッと思いついたアイデアでiPhoneアプリを作ろうと思うのだけどクラウドワーカーに作ってもらうと格安でできそうなんだけどどう思うか？と聞かれたことがあります。「どう思うか？」というのは普通に開発会社に頼めば数百万から数千万取られる事案だけど、クラウドワーカーなら10万とか20万でやってくれたりします。そこにメリットデメリットがあるのかというを聞いているのです。大してデメリットなければ安いに越したこと無いと考えるのが経営者です。その社長はビジネスサイドの人なのでもちろん開発の中身についてはわかりません。
私はうーんとうなってしまいましたが、その後結局社長はクラウドワーカーに依頼をしたそうです。その成果物のクオリティに満足しているとのこと。満足しているならクラウドワーカーでもいいのかもとは思いました。
でもよく考えたら保守を考えたときに、ある程度の専門知識は必要だし、そこに値段がついていることを考えるとやはり安かろう悪かろうになるんじゃないかと思っています。安物買いの銭失いとも言えるでしょう。もちろん、この話のクラウドワーカーさんはちゃんとしている人で全部きちんとやった上で価格を下げて提供しているのかもしれないのでなんとも言えませんが・・・。
さて、フレンバシー入った頃は、このTokyoDinnerTicketの保守するのは厳しいなと思っていたので、サービスがクローズになるということが決定して新たにVegewelをやるということが決まったときには少し気が楽になるとともに、全部自分で決められるということにワクワク感がありました。
Vegewelはレストランデータベースなのでウエディングパーク時代のSEOの知識などが活かせます。英語と日本語のバージョンが有りすべて階層構造となります。都道府県、エリア、駅や料理などでも検索ができます。
こういったことと過去に副業でやってきた技術の中からベストな組み合わせを考えたら以下のような形になりました。
RubyonRails
MySQL
AWSのElasticBeansTalk
View部分はSlim＋jQuery
デザイン部分はBootstrap
BitBucket
CircleCIでデプロイ
監視はMackrelとSentry
Railsは多少は勉強していたものの、本格的にやるのは初めてで勉強しながらではありましたがなんとか形を3ヶ月位で作りました。ただ、デザイン面はどうにもいただけない感じだったのでコーディングもデザインもやってくれる人を探したところ、紹介でGMOで仕事をしていたさくらちゃんに加入してもらえることになりました。フロントエンドはRailsのSlim+JQuery+BootStrapなのでデザイナーなのにまるっとコーディングしてもらえるというのは立ち上げにかけられる工数が限られている中では非常にありがたかったです。
AWSに関してはRailsで作ったアプリをどうやってEC2で公開するかというところです。UnicornとかCapistranoの設定とか、作り上げるのに更に時間取られそうだなと悩んでいました。そこであるときに古い知り合いのサーバーワークスのAWSエバンジェリストに相談したところElasticBeansTalkというのがあると教えてもらいました。マネージドでRails動かすのに必要な機能が全部揃っているという話でコマンドライン（CLI）でデプロイ出来るという話を聞いたときにHerokuを思い出しました。
デプロイといえばCIも流行ってきていて、世の中的にはJenkins使っているところが多かったのですが、これのためにEC2を1台用意しないといけなくてサーバー台数をコストの関係で増やしたくなかったのでSaaS型のCircleCIを選択することにしました。しかも最低限の機能なら費用が無料です。BitBucketの特定リポジトリへのコミットをトリガーにしてデプロイが動くようにしました。この際にCircleCIのコンフィグファイルからAWSのCLI（コマンドラインインターフェース）を起動してElasticBeansTalkのデプロイを行うようにしただけなのですが、DevOpsが簡単にできるようになってとても便利、CICDツールの良さに感動しました。導入時の話は過去にQiitaにも書いています。
サーバの監視も自動化は必要です。なぜならエンジニアは高見沢一人しかおらず、リソース監視はもとより、各ページの表示確認を都度やることを考えたらクレイジーだからです。毎日日課で自分のサイトを何ページも巡回するとか考えられないです。これをやるためにMackrelを導入しています。Mackerelは「はてブ」で有名な株式会社はてなが作った監視システムで導入の敷居も低く（エージェントをワンライナーで入れるだけ）ページ巡回を外形監視という仕組みで出来るのが非常に便利だということで採用しました。
Sentryは例外監視のために導入しています。本番でエラーが発生して、ログに吐き出ししても正直その状況を調べるのは容易じゃないし、だったらリアルタイムで例外だけでも検知する仕組みがあれば不具合調査のハードルを下げます。2019年まではよその会社でフリーランスとして働いていたので、各現場で得たノウハウはフレンバシーでも非常に役立ちました。MackrelやSentryも現場で知ったツールです。（続く）
続きはこちらでどうぞ！
この記事が気に入ったらサポートをしてみませんか？