このページは個人開発の記録です。
要件
この要件は随時更新します。
- 既存の無料で読める（合法）漫画サイトをクローリングしてデータを集める。
- クローリングしたデータを取得出来るAPIを準備する。
- APIからブラウザに更新情報として表示する。
この要件をそれぞれ別リポジトリにして、独立した形にしたいと思います。もし人気が出てきたりした場合等、バックエンドはAPIにしておきたいと思います。その場合、フロントはVue.jsで初SPAにしたいと思います。Vue Routerを使用予定です。最終的にはアプリ版もリリースしたい為、バックエンドはAPIにしました。
また、AWSの知見もたまってきていますので、なるべくAWSを使用したスケーラブルな環境で立ち上げたいと思います。費用はかかりますが、これはもう必要経費として計上してガチでやっていこうかと思います。
3.の細かいところとしては、
- お気に入りの漫画の更新情報を見れる
- お気に入りの漫画の更新情報の通知を受け取れる（LINE、メール
- 盛り上がりグラフ（Googleトレンドのグラフを反映
- 盛り上がりグラフ（twitterでタイトル検索して前日の件数を記録しておき、グラフを反映
- TOPに月間人気ランキング、週刊人気ランキングを出せる
- Amazonの人気ランキングを出す
- 他プラットフォームの電子書籍ランキングを出す
ハードル上げすぎかもしれませんがとりあえずやってみます！
それではよろしくお願いいたします。
(2021/1/20更新)
2020/10/24～2020/12/3の開発記録
どのようなサービスにするか、競合分析をして、実現出来そうなイメージをふんわり固めました。
概要設計の１つとしてDB設計をしました。ER図を描いて必要なテーブルと項目を洗い出しました。クロールログテーブルがかなりふわっとしてしまいました。ひたすら溜め込むログなので、とりあえず突っ込むテーブルになりました。他、コミックテーブル、ユーザテーブル、メディアテーブル等はきっちり描けるところなので細かい項目まで洗い出せました。
このフェーズが一番わくわくしますね。このプロジェクトは自分でやりますが、今後流れに乗って来たら概要設計だけやって外注してみたいです。
どのような技術で構成するかについても少し検討しました。
今回AWSをなるべく駆使してスケーラブルで安定稼働出来る構成を作っておきたいと思っていますので、クローラーはLambda(Python)にしました。Goも対応しているのですが、まだ経験がない為今回入れると時間取られそうな為外しました。今回はきっちりと集客・売上を上げる為に、改善を積み重ねられる状況を大事にしたいと思った為です。
LambdaはCloudWatchEventでスケジューリングします。AWS Batchもありますが、簡単なLambdaにしました。
DBは最初からAWS RDSのAuroraを選択します。（高そう）クローリングログはS3に入れてストリーミングとか考えましたが、ログだけに開発時間がとられるのもモチベーションが沸かないので、最初はDBに入れる方向で進めます。
APIはAWS API Gatewayを選択します。EC2にLaravelを入れようか迷いましたが、スケーラブル方針なので思い切ってAPI Gatewayにしました。（高そう
ドメインはRoute53で取得します。
SSLはAWS Certificate Managerにします。
と、これだけ駆使すると実際の金額的な不安がありますが、とりあえずスタートしたいと思います。
今回6時間 計6時間
2021/1/20～2/23の開発記録
windowsで開発しようか迷いましたが、macで開発しようと思います。
とりあえずPython3.7をインストールしました。
AWS自宅環境のIAMユーザを作成し、MFA設定をしました。スマホが壊れた場合を考慮して、Chrome拡張機能のAuthenticatorを使用してバックアップしました。
クローラーの開発に取り掛かる為、集めるデータサンプルを先ず手動で取ってみる事にしました。いくつかコミック単位で取ったところ、そもそもページの更新情報だけでなく、新連載コミックも膨大になるのでクローリングしないと厳しい事がわかりました。それに伴いER図を修正しました。クローリング見積りが一気に2倍になった瞬間でした。
Lambda→RDSを実現する為のAWS構成調査を進めました。久々にVPC設定やると何が必要だっけ？みたいなど忘れしてしまい、昔やったRailsをAWSにデプロイした記録をあさり直しました。以下参照
他、SPA+バックエンドのAWS構成まで概要が見えてきました。現状の予定構成としてはこうです。
Route53+ACMでドメインとssl
CloudFrontをCDNとして、基本S3にして、S3に設置したVue.jsが同ドメインのAPIをパス/apiなどで呼び出します。同ドメインなのでCloudFrontに再度アクセスが行って、/apiのパスの場合はAPI Gatewayを見るように設定します。
API GatewayはAPI種別でLambdaを呼び分けます。（最初は１つで進める）
LambdaはプライベートサブネットのRDS(Aurora)を呼びます。
という感じです。現状では。クローラーの部分だけの開発なのに全体まで考えてしまいましたが、少し先が見通せた感じがしてきました。
RDSをAuroraにしようとしましたが、$30/月はするのでMySQLにしました。
使った事がなかったのですがRDSの接続情報をコードに書かずに済むAWS Secrets Managerなるサービスを見つけました。
Lambda から RDSへ接続するプロトタイプを作っていますが疎通確認に4時間ほど構成に時間がかかりました。
設計した各種テーブルをCREATEしました。
AWSの構成を変えました。LambdaからRDSへ接続するのにProxyを使用する事にしました。
RDS ProxyがDBログイン情報を保存したSecretsManagerを使用し、LambdaがRDS Proxyを使用するので、LambdaにはDBログイン情報が必要ないと思って苦戦していたのですが、これは必要なようです。どうも納得がいかないのでAWSサポートプランに入って問い合わせ中です。
（返答ありました。RDS ProxyがRDSに接続するには、SecretsMangerを使用出来ますが、LambdaがRDS Proxyを使用するのにIAM認証であればDBログイン情報は必要ありませんが、IAM認証を使わない場合はDBログイン情報は必要です。IAM認証のコネクション上限でどちらにするか決めれば良さそうです。）
IAM認証を使用すれば不要となりますが、IAM認証だとリクエスト上限がある為避けました。
LambdaからRDS Proxyを使用してRDSに接続するまでの事を以下の記事にざっくりアウトプットしておきました。
合わせてセキュリティグループやIAMロール・ポリシーも全て見直し、構成図にもセキュリティグループとIAM情報まで記載したものを作りました。絶対忘れるし重要な設定なので、個人開発でもここまで書いた方が良いと感じました。疲れた。
とは言え、ようやくLambdaからRDSへ接続出来るしっかりした枠が出来ました。
次回からはようやくクローラーのコードを書けるはずです。
と思って書いてみたところ、LambdaからDBへのアクセスは出来るもののインターネット接続ができない事に気づきました。NATゲートウェイを設置していなかった為だったのでまたまた構成をいじりました。
また、PythonでLambdaを書く場合のデプロイについて以下の記録をしておきました。
今回24時間 計30時間
2021/2/24～の開発記録
前回までで、無事DBへのアクセスとインターネット接続が出来たのでクローラーの開発に入る事が出来ました。素のpythonを使用しているため、DBアクセス用のクラスを作成するところを先に作っています。
途中までやって気づきましたが、LambdaでRDS触るのは本当に少しだけならLambdaで良いと思うのですが、がっつり触るとするとフレームワークを自作する事になりかねないなと思いました。Lambdaにフレームワークを入れるのはちょっと違うようにも感じます。そうするとやっぱりEC2でRDSを見るようにした方が良いのではと思ってきました。
RailsをEC2に入れるか検討してみます。
今回28時間 計34時間