漫画ビレッジを支える技術とオススメのマンガ
1つ前のエントリで書いた漫画ビレッジっていうサービスをリリースして3週間弱経った。
その後もITmediaの記事でインタビューして頂いたり、 出版社絡みの方と色々話したりなど諸々各所反響があって最近はちょっとバタバタ気味。（何事においても暇なことが嫌いなので忙しいのは嬉しい）
作り始めた当初は、これ作ることで技術的にも人脈的にも本業に活かせれば良いかなぁ、、くらいのゆるい感じだったので、今の状態はとにかくありがたい限りという感じ。
3週間の間に漫画村UIに寄せてリニューアルしたり、Heroku2台体制で運用しているときにYahoo!砲がきたりと色々あって、なんか色々変化だったり進捗もあったりしていて。
Twitter経由だったり問い合わせだったりで割と技術的な構成がどんな感じなのかを興味頂いている方も多かったので、こんな感じで作ってますよ〜っていうのを色々まとめてみた。補足として前エントリをざっくり見ていただくと理解が早いかと。
個人開発の常でとにかくリソースが限られているので、無駄な工数（開発も運用も）は最小限にしないと全て破綻するので、とにかく巨人の肩の上に立つことを意識していて、自前で作らなくてもいいものはとにかくSaaSを使って解決するようにしている。
今現在使っているフレームワークやサービスは大体こんな感じ。
Nuxt
前エントリではNuxtで Framework7 っていうUIフレームワークを使っている旨を書いたが、色々つらみがあったので捨てた。今はCSSフレームワークとしてBulmaを入れている。
Framework7は簡単にネイティブアプリ風のデザインを作れるんでそれはそれで良いんだけど、ただRouter周りをwrapしてしまっているUIフレームーワークは自分で拡張しようと思ったときにかなり制約があってつらみがあることが多いなぁという学びがあった。
あと大きく変えたのはSSRにしたことくらい。SEO的な要件をいくつか満たしたかったのでSSRにしたが、結果的にこれはSPAのままでも満たせたので結果的にそこまで頑張らなくても感はあったかも。
First Meaningful Paint周りの対応(Avoid the fold)がまだうまくできていなくて（めっちゃ運用のつらみを伴えばできる）、Nuxtでここらへんの知見ある方いたらぜひお話聞かせてください。
Firebase
バックエンドではFirebaseで今は Firestore と Cloud Functions を使っている。
Firestoreはとにかく便利で、ざっくり言うと Database + WebAPI + Mobile Databaseをくっつけたようなもの。Scalabilityも全く意識しなくていい。すごい。 しかも料金もFirebase Realtime Databaseよりかなり安い。（それでも、漫画ビレッジにおいてはここ一番コスト面で掛かっている）
まだβではあるものの安定性は特に困ってはいないが、ただ、機能周りがいくつか制約があって
- SubCollectionに対してQueryが使えない(SubCollectionの存在意義って･･・)
- Webコンソールが絶妙に機能不足な上にカジュアルにTruncate(Drop table)できてしまう
- バックアップ周りが全くない
と、運用面でのつらみはそこそこある。
これは完全に自分が悪いんだけど、FirestoreのWebコンソールから操作をしていて、あるレコード(Document)を消そうと思って間違ってメインの商品テーブル(Collection)を全消ししてしまったことがあってめっちゃ血の気が引いた。大惨事になる前に即時復旧ができたのでそのときは良かったけど、心臓にはとてもよくない。
恐らく現時点での実務上の運用においては、FirestoreのWebコンソール画面にはアクセスできないように権限設定しちゃうのが一番安全なんだろうなぁ、、っていう気はしている。
Cloud FunctionsはFaaSなもので、ビレッジではクローラーの実行と、あとDB(Firestore)に新刊追加があった際のトリガーでスコアを変更したり、Algoliaのインデックス登録とかをやっている。 とりあえずログ周りはconsole.logしておけばStackdriver Loggingで扱えるのでなにかと便利。
Cloud Functionsは実質ほぼ無料枠で収まる程度で使っているくらい。こっちは現状そこまで不満はないが、cron相当の定期実行が自前ではできなくて、外部からなにかしらトリガーを走らせてやらないと動かないので、そこらへんのつらみがあるくらい。
Heroku
フロントはNuxtで書いているので単純にホスティングだけしたかったので、運用周りで自分が知見があったHerokuを選定した。 ローンチ当初は色々模索してPerformanceプランに上げたりオートスケール入れたりしたけど、 今は一番安いStandard-1X dynos * 2台($25*2/month)という最小限の構成に落ち着いていて Yahoo!砲が来た時も結果的に最後まで2台構成のまま乗り切った。（これはFastlyの功績が大きい）
Fastly
高機能CDN。Herokuのプラグインとして今はPro(TLS)プランの$130/monthを使っている。 基本的な使い方しかしていないが、運用を続ける中で一番このサービスに助けられている。
最初結構設定でハマって（というか反映されなくて）いくつかサポートに問い合わせたりもしたけど中の人が割と手厚いサポートをしてくれる印象。
Algolia
全文検索エンジン as a Service。日本語にも対応している。$59/month。
FirestoreはQueryでの検索周りは弱く、部分一致での検索などはできないので、漫画ビレッジでの検索機能はAlgoliaを使っている。 とにかく高速で平均7msくらいでレスポンスが返ってくる。
SynonymもWeb上から簡単に管理できるのがとても楽。まだ運用に置けるBest practicesは模索中だが、例えば「ワンピース」で検索したときに「ONE PIECE」に紐付けるようなことは全部Algolia管理画面で完結してできる。Synonm生成自動化は精度がかなり落ちそうなのでいまのところ手動でやっている。
検索にHITしなかったワード一覧もAlgolia上から管理できるので（もちろんAnalyticsでも取ってはいるけど）、「ユーザの需要はあるが漫画ビレッジではカバー出来ていないマンガ」の傾向も把握できて便利。
Bugsnag
エラー監視 as a Service。$29/month。 これは全くこだわりはなくて、3年くらい前からこれ使ってる。
細かなバグまでは対応しきれなかったりするのだけれど、どんなバグがどこでどれくらいの頻度で起きているっていうのは割と見落としがちなので、対応可否を判断するためにも入れておいて損はないかなぁ、、というのが自分の中の位置付け。
Librato
HerokuのプラグインとしてMetrics & Monitorig用として入れている。$19/month。
日中はそこまでがっつりメトリクス見ることはできないので、基本的にはヤバイ閾値でのアラート設定入れといて、これの通知がきたらなにか対応する必要がある、くらいの温度感で入れている。
これ飛んできた時大体ヤバイことになっているのでだいぶ役に立ってる。
オススメのマンガ
今年読んだ中だと 7seeds（全35巻+外伝1巻) とかゴールデンカムイ（現在14巻・今まで読まず嫌いしてたことを反省）とかヒナまつり（現在14巻・LINEマンガ12話まで無料）とか。
現時点で5巻以下のものだとあげくの果てのカノン（全5巻・小学館eコミックで1巻無料）とかブルーピリオド（現在2巻）、左利きのエレン（現在2巻）とかが好きです。
有名所ばっか挙げましたが、そんなん全部読んどるわって人はぜひ色々語り合いましょう。
まとめ
βのサービスだったりを本番で使う判断を下せるのは個人開発の強みだなーとかは痛感してます。（なにか起きたら全て自己責任なので、自分が色々忙しくなるだけで済む）
実際作ってみて、この領域は大きすぎてやはり個人で運営していくには色々と深い領域だなぁ、、、と思ってはいますが、考えうる最善手を最短ルートで通っていくのが得意な性分なので、生温かい目で見守って頂ければ幸いです。
