「Cloudflare」の記事 - Crieit

【個人開発】アイデア出しから公開・プロモーションまでまとめ(Nuxt3、Cloudflare、GooglePlay)

2023-07-29T05:35:55+09:00

1. はじめに

個人開発の大体の流れがつかめるように、アイデア出しから公開・プロモーションまでをまとめました。

1-1. 作ったアプリ

About	List	History

	基本操作
① リスト作成 ② 買い物完了でチェック ③ チェック済みを削除 ※これらの手順だけで簡単操作

『買い物リスト・メモ - Lisble リスブル』

iOS,PC	Android

iOS,PCの方は、PWAの為、メニューから｢ホーム画面に追加｣をお願いします。	このアプリは Google Play で入手できます。

2. 0から公開までの流れ

2-1. アイデア

1番大事だけど一番頭を悩ませました。
新しいものか、既存のサービスでの差別化の二択で、はじめてということで後者にしてしまいました。
これからもアンテナをはって次につなげたいです。

アイデアの出し方
* とにかく紙に書く
* 不満・面倒・悩み・困っていること
* 人間観察(周りの人)・他業種の業務課題
* 真似 → シンプル化・別分野へ応用・既存のサービスの不満解消
* 海外のサービス調査
* ニッチ・マニアック(自分の強み・趣味)
* 合体・逆

既存のサービスの発展系か、何かの組み合わせか
思いついたらメモ 📝

参考サイト
アプリ開発でアイデアが浮かばないあなたへ。独創的なアイデアの出し方
 ポートフォリオや個人開発で使えそうなアイデア

2-2. 要件定義

①要件(こうだったらいいな)
* 出来る、出来ないを考えずあげていく

②要件の為の機能
* ここで出来る、出来ないを考える
* 最低限必要な機能を絞る
* 実装方法が思いつかない機能は省略

出先で「あれあったかな❓」を解決したい → 買い物履歴を残して最近買ったものをわかるようにする機能
在庫の把握・重複購入を減らしたい → 買い物履歴から同じ単語入力時に色の変化で知らせる → 入力中に知らせることにより在庫を思い出すきっかけにもなる
etc...

③出来ればマネタイズも考える
1. 広告：アフィリエイト､AdSense(web)､AdMob(アプリ)
2. 課金：広告削除､追加コンテンツ､アイテム
3. 寄付
4. 有料：買い切り
5. サブスク：月額制

とにかく一連の流れを経験したく、マネタイズまでの道のりが見えたのが本アプリ案で、結果Amazonアソシエイト､AdSenseになりました。
AdSenseは受かりませんでした。継続して挑戦します。

④利用技術
🔑 ログイン・ユーザー登録無し、、広告も可でとにかくお金をかけずにを優先して、SPAで制作することにしました。
- GooglePlay Developer 申請・登録25ドル(当時3,352円)
- 独自ドメイン Xserverドメイン初年度のみ1円
- 更新、移管はCloudflare予定

アイデア・デザイン
Xmind(マインドマッピング)
Figma
コード
Nuxt3(Composition API)・TypeScript・Tailwind CSS
インフラ
Cloudflare
開発環境
VSCode・Git、GitHub

参考サイト
【5ステップ】初めてのオリジナルアプリの作り方！アイデアの出し方も公開

2-3. 設計

①画面設計
1. 必要なﾍﾟｰｼﾞ列挙 ➡ 階層・整理
2. ワイヤーフレーム(紙手書き)下書き
3. ワイヤーフレーム(figma)清書

参考サイト
ワイヤーフレーム(画面設計)の作り方
 Web画面設計の手順と重要なポイント

デザインの４原則
1. ｢近接｣：関連する要素をグループ化
2. ｢整列｣：関連する要素を見えない線で整列
3. ｢反復｣：要素の一貫性、デザインの統一
4. ｢対比｣：要素の優先度を強弱で示す

参考サイト
お役立ち知識：デザインの4原則 - デザインパートナー

②データ設計(構造)
* データの設計図

2-4. 開発

設計通りに作る
最低限の機能
制作途中で機能の追加案を我慢して、とにかく完成させることに集中する(追加の機能を制作してしまいました。なのでここに残しておきます。)

①工夫した機能
- 並べ替え(D&D)・スワイプ機能をライブラリ(Vue.Draggableは､思うような機能にならなかった)を使用せずに作成
- ↳シンプル化のため､同じ発火点で､参考サイト様(Trello風タスク並び替えドラッグ&ドロップクローン(Vue.js利用))を参考に､【マウス、タッチ、処理回数削減、d&dとswipeの融合、グループ間並べ替え、d&d中の上下の画面端scroll】ロジックを考え自作しました。

並び替え機能	スワイプ

	←色 →削除※ﾀｯﾁﾃﾞﾊﾞｲｽのみ

スマホとPCの挙動の違いなど(ENTER､終了時の処理...)
日本､世界の日時の表示形式(履歴)
Amazonアソシエイトの各国の設定(OneLink)
アニメーション(数字のドラムロール、追加削除時...)etc...

②多言語化(i18n)
@intlify/nuxt3使用
日/英で単語の長さの違いによる表示崩れに注意

未解決問題
日本語で検索時、検索結果が英語サイトのtitleとdescriptionになってしまう問題(同じURLで日/英にしたい)

確認
meta tagの設定(title、description等)日/英切替時にきちんと切り替わっている。

↓ためしたこと↓
- Nuxt.jsのi18n多言語対応したら、日本語で検索した時の検索結果が英語になってしまった。解決できたので対応方法を記載します。
- @intlify/nuxt3 で detectBrowserLanguage: false,にあたる設定がない??
- sitemapの設定 (hreflang属性)
- Google Search Consoleに日/英を認識させる方法??...
- (2023年7月) Nuxt3での多言語化はまだ開発中らしいので情報待ち🍥 → intlify/nuxt3: Nuxt 3 Module for vue-i18n-next

③プライバシーポリシー
参考サイト
プライバシーポリシーとは何か？必要性、記載事項をわかりやすく解説

④テスト
- 個人情報を扱っているなら､徹底的に安全確認
- 例外処理

2-5. 公開

①(SPA SSG) 静的ファイルホスティングサービス【無料】
1. GitHub Pages
2. Firebase Hosting
3. Netlify
4. Vercel
5. Cloudflare Pages

無料プランの枠・サイトのパフォーマンス・商用利用可でCloudflare Pages

参考サイト
Cloudflare Pages・Vercel ・Netlify の違いや使い分けをまとめる
 NetlifyからCloudflare Pagesに引っ越しました

②Google Play Store 配信方法
PWA → TWA
* TWA変換ツール「Bubblewrap CLI」使用
* Lighthouse で 80 以上のパフォーマンススコアが必要(↓に記述)

参考サイト
信頼できるWebアクティビティ
 【TWA】完全開発ガイド＝超簡単にPWAをPlay Storeで配信しよう
 PWA対応サイトをAndroid APK（AAB）に変換する

③Lighthouse のパフォーマンス改善(リファクタリング)
- cssの最適化 → 読み込み順､削除､animation(transform,opacity...)etc...
- googleFonts, Analytics → GTM使用､読み込むタイミング､読み込み方､文字の限定etc...
- 【2022年3月】Google Fontsのパフォーマンス比較＆ハリー・ロバーツ方式の勝手に改良版
- Google Fontsを簡単にサブセット化する方法
- Web Worker → 並列処理 Web Workerの使い方
- requestAnimationFrame() → 「60fps」 requestAnimationFrame の使い方
etc...

Mobile :arrow_down:

Desktop :arrow_down:

2-6. リリース後

①掲載用スクリーンショット、画像作成
* figma制作
* サイトにより、サイズ、比率、枚数、が異なる

②登録サイトに投稿/掲載依頼
当たって砕けろ、チャレンジ精神で色々掲載依頼を出してみた結果です。
個人開発者に告ぐ！「告知＝恥ずかしい」を脱却しよう～実例データから重要性を解説

登録or掲載 → 🎉
メール・問い合わせ反応待ち → 📧
更新が止まっているサイトが多い

日本
- Appliv → 🎉 レビュー、とても丁寧な対応 :thumbsup:
- APPLION → 🎉 ランキング
- 放課後ｱﾌﾟﾘ部 →🎉 登録
- Applishow → 🎉 登録
- AppRoom → 🎉 登録 アプリ記事掲載
- SeekUps → 🎉 登録
- ロケットリリース → 🎉 登録
- Appstimes → 🎉 登録
- AnyMake → 🎉 登録
- makepost → 🎉 登録
- MITSUKARU! → 🎉 登録
- DevHaunt! →🎉 登録、とても丁寧な対応 👍
- 個人dev → 🎉 登録
- アプリゲット → ゲームのみ
- AppBank → 📧
- Applision → 📧
- ツクログ → 📧 クリエイター登録済み､まだ作品は掲載されない(2度投稿)
- octoba → 📧
- NewLaun-ch → 📧
- appllio → 📧
- appnavi → 📧
- Androライオン → 📧条件:レビュー
- AndroRank → 📧条件:レビュー
- Androidアップス → 📧
- Androidコレクション → 📧
- マイナビニュース → 📧
- ITmedia → 📧
- ITmedia ねとらぼ → 📧
- AndRock → 📧
- AppVIP → 📧
- AppLink → 📧
- GAPSIS → 📧

海外

Product Hunt → 🎉 登録から１週間待つ必要がある
AlternativeTo → 🎉 登録
app store apps → 📧
AppCraver → 📧
arttechnica → 📧
Apps Review → 📧
community → 📧
App Log → 📧
Get Android Stuff → 📧
Android Guys → 📧
androlib → 📧
APKMirror → 📧
PCMag → 📧
NEWSREPORTS → 📧
iFanzine → 📧

※上記以外で無料で宣伝できるサイト、方法があれば教えていただけると嬉しいです。

③記事を書く
- Qiita
- 【Nuxt3】はじめての個人開発「買い物リストアプリ」開発記録
- Zenn
- Nuxt3で初めての個人開発記録【買い物リストアプリ】
- Crieit
- シンプルな買い物リストアプリ「lisble リスブル」の紹介
- 【個人開発】アイデア出しから公開・プロモーションまでまとめ(Nuxt3、Cloudflare、GooglePlay)
- note
- 値上げ対策！買い物リスト作成で節約
- シンプルな買い物リストアプリ「Lisble リスブル」のご紹介
- Medium(英語記事)
- Price increase measures! Save money by making a shopping list

④Twitter(日本語/英語)
- Twitter日本語ver.：@arieight_8
- Twitter英語ver.：@Lisble_en
- 登録or掲載 → つぶやく
- 機能一覧、設定一覧、動画(gif)でツイート
- 開発中からつぶやいた方が良い

参考サイト
個人開発したWebサービスをリリースした後にやったこと / やり続けていること

3. 気付き・反省点・まとめ

開発を0からして、初めてコードをさわって新しい概念にふれた時くらい勉強になり、とても知見が広がり良かったです。
プログラミング以外の作業が初だったので「プログラミング：他＝ 3：7」くらいの感覚でした。様々なデザインが予想より大変でした。
一番面白いと感じた作業は、ロジックを考えて形になった時でした。
アイデア → 紙やXMindに思いつく限りまとめたのですが、総合的な判断で結局既存のサービスに追加機能の方向になってしまいました。マネタイズまで含めたアイデアが難しいです。どうせやるなら一通りやってみたかったので次回以降にしました。常にアンテナをはって知見を広げていいこうと思いました。
要件定義 → 運用費がかからない、個人情報は扱わない、AdSense以外のマネタイズまで考える､などを考慮してアイデアを絞り、考え、すでにあるサービスと見比べ、アイデアと要件定義をぐるぐるしていました。
AdSenseは、コンテンツ不足でwebアプリは受かりづらいらしいです。
利用技術 → 平凡なアイデアだったので初めて挑戦する技術(Nuxt3､TypeScript､etc...)を使用してしまいました。
デプロイ先など、お金をかけずに運用していくための他の効率の良い方法やサービスを引き続き調査していきます。(Firebaseをﾃﾞｰﾀﾍﾞｰｽ等)
設計 → 画面デザインは、UI足したら引き算・データ設計は構造整理
開発 → 追加の機能を制作してしまいました。最低限の機能でまず完成を目指すべき
工夫した機能 → ToDoの変化型アプリで平凡なアプリで非常に多く数があるため、機能にこだわりました。
多言語化して作業が増えた。[Amazon設定､時間形式､表示崩れ､metaタグ､etc...]
テスト → 多視点が重要
公開 → 運用費をかけないにこだわる
パフォーマンス改善 → 良い学習
マネタイズ → Amazonまでの導線が弱い要検討
著作権・プライバシーポリシー・DDoS対策etc...
プロモーション → Twitterは開発中から・アイデア段階でSNSを考慮したサービス・地道にor金をかけるか・個人の場合限られるので勉強段階からブログや記事など書いておけばまた違ったかも
「告知＝恥ずかしい」があったので、経験せずにはわからないからできることは全部しようと思いました。

作る前に想像していたよりコード以外の作業が多いとうことに改めて気付かされました。
制作中、何度も宇宙兄弟のセリフが脳内再生してました。ありがとうございました。

「また積めばいいよ」
「次はもっと上手く積めるようになってるよ」

出典: 『宇宙兄弟』17巻小山宙哉（講談社、2012年3月23日第1発行）

購入履歴が残せるシンプルな買い物リストアプリ 『買い物リスト - Lisble リスブル』 です。メモ、ToDoアプリとしても機能します。
購入履歴の保存機能により、無駄な重複購入を防ぎ、在庫の備忘録にもなります。
ログイン・ユーザー登録不要、無料ですぐにご利用いただけます。
もしよかったら、触ってみてください。

『買い物リスト・メモ - Lisble リスブル』

iOS,PC	Android

iOS,PCの方は、PWAの為、メニューから｢ホーム画面に追加｣をお願いします。	このアプリは Google Play で入手できます。

Twitter:＠arieight_8

Google Play および Google Play ロゴは、Google LLC の商標です。

Nuxtアプリを無料で公開するときに試した5つの環境まとめ(Firebase/GAE/Netlify/Heroku)

2020-03-20T13:51:56+09:00

最近Nuxtでいろいろ作っているけど、無料で使える環境をいろいろ試してる。
いろいろメリデメあるけど、SPAならNetlify/SSRならHerokuがよさそう。
いままで試したものをまとめてみた。

ほしかったもの

主に開発してるのがCGM系のWebサービスなので、

動的なOGP画像などが設定できる(OGP芸)
カスタムドメインが使える
日次のランキング集計などの定期実行ができる

が、無料でできて、なるべく実装が楽で、そこまで遅くないのがうれしい。

試した5つのパターン

試したのは以下の5パターン。試してみた順で記載。

Nuxt(SSR) + Cloud Function
起動がかなり遅かった。。実装も大変なのでNG
Nuxt(SPA) + Firebase Hosting
構築はかなり楽。ただ、OGP芸が大変でFunctionsが必要
Nuxt(SPA) + Netlify
プレレンダリングでOGP芸が楽。定期実行はFunctionsでできる
Nuxt(SSR) + GAE(f1:256M)
メモリの制限きつく、たまに落ちる。。定期実行はcron.yamlでできる
Nuxt(SSR) + Heroku(free:512M) + Cloudflare
メモリ多くてよい。SSLはないのでCloudflareを併用。定期実行はHeroku Scheduler

SPAで十分であれば、「3.Nuxt(SPA) + Netlify」が構築も簡単で良かった。
積読ハウマッチは、現在この構成。

SSRの場合、「5. Nuxt(SSR) + Heroku(free:512M) + CloudFlare」が良い感じ。
へんあいマップがこの構成。

各パターンについて

1. Nuxt(SSR) + Cloud Function

一番はじめに積読ハウマッチでやろうとした構成。

細かいやり方は、以下の記事の「Firebase Cloud Functionsの設定してSSRできるようにする」あたりに。
・Nuxt.jsではじめるときのやることリスト(SSRも国際化も自動デプロイも) - くらげになりたい。

当時は動的ページのSEO対応するには、この方法が多く検索に出ていたので試したけど、
Cloud Functionのコールドスタートがつらすぎてお蔵入り。。SPAでいくことに。。

2. Nuxt(SPA) + Firebase Hosting

積読ハウマッチをリリースしたときの構成。

課題だった動的ページのSEOは、Cloud Functionsを経由して返す方法で対応。
こちらも当時よく検索に出てたけど、実装が大変そうだったので2番手に。

細かいやり方は、以下の記事に。（2020/03/22追記: OGP画像生成系の記事を追加）
・Nuxt(SPA)+FirebaseでSEO！OGP！: 特定のパスだけheadだけ返すやつ - くらげになりたい。
・Nuxt.js(SPA)+Firebaseで積読用の読書管理サービスを作ってみたときにハマったこと - Qiita
・Cloud Functions + ImageMagickでOPG画像の動的生成してCloud Storageにアップロードする - くらげになりたい。
・Cloud FunctionとSVGでOGP画像生成を試行錯誤したまとめ - くらげになりたい。

カスタムドメインについては、Firebase HostingでSSLと合わせて無料で設定可能。

定期実行は、Cloud Functionsでできるのでそれを利用した。
・関数のスケジュール設定 | Firebase
・Cloud Functions for Firebaseのcronみたいな定期実行を試したら簡単だった - Qiita

ただ、Cloud Functionsの定期実行は、
「Googleアカウントごとに3つのジョブを無料で使用できる」
なので、注意が必要。プロジェクトごとじゃない。。

3. Nuxt(SPA) + Netlify

積読ハウマッチの現在の構成。

NetlifyのPrerenderingが無料化されて使えるようになり、よいという話を聞くように。。

実装が複雑で、変更もしにくかったので、この方法に。
Netlify自体がCDNも提供していているので、すこしはやくなった(気がする)

カスタムドメインも、NetlifyのDNSを設定して無料で対応できる。

定期実行は、2.と同じ感じで、Cloud Functionsのまま。

コード量も減って変更もしやすくなったので、OGP画像の改善とかが楽にできるように。。(´ω｀)

4. Nuxt(SSR) + GAE(f1:256M)

SPAの課題として、初期表示が遅いのでなんとかしたいなと、SSRの環境を模索しはじめ。。
公開していないけど、1つ作ってみた。

試してみたところ、起動するだけでメモリ上限すれすれで、複数アクセスがあったりすると、落ちる場合も。。
(ts-nodeで動かしているのも悪い気がしている。。)

ただ、定期実行はcron.yamlを用意すればURLに送信でき、無料範囲も広い。
料金も「その他のリソース」をみるとcronは無料のよう。
・cron.yaml を使用したジョブのスケジューリング

カスタムドメインやSSLも無料で利用できる感じ。(試してないので未確認)

5. Nuxt(SSR) + Heroku(free:512M) + Cloudflare

GAEでうまくいかなかったので、無料でメモリも多いHerokuを利用。
へんあいマップがこの構成で稼働中。

定期実行は無料のアドオン(Heroku Scheduler)が利用できる。
Nuxt側でserverMiddlewareを用意すればOK。

ただ、メモリは多く定期実行もが、Herokuの無料枠だと制限も多い。

SSLは非対応
30分アクセスがないとスリープする
クレジットカードの登録で1000時間/月xアカウント
(未認証だと550時間/月xアカウント)

1. SSLは非対応

単体だけだとSSLに対応していないので、Cloudflareを併用。
CloudflareがCDNも提供してくれるので良い感じに。

2. 30分アクセスがないとスリープする

これは、Heroku Schedulerを使えばOK。
任意のURLを叩けるため、15分毎などスリープしないようにしておく。

3. 無料枠は1000時間/月xアカウント

1000時間あれば、24時間x31日でも744時間なので、大丈夫な感じ。
ただ、アカウント単位での無料枠なので、複数アプリを無料で稼働はできない。。

実際のやりかたとかは、

以下の記事に。
・Heroku+CloudflareなNuxtでSSRしてみる - くらげになりたい。

まとめ

いろいろ試してみたけど、Nuxt.jsを無料で公開するときは、

SPAならNetlify
- prerenderingで動的ページのSEOも対応
- カスタムドメインやSSLもNetlifyでOK
- 定期実行はCloud Functionsで。
- ただし、定期実行は1アカウントにつき、3ジョブまで
SSRならHeroku
- SSRで動的ページのSEOも対応
- 定期実行はHeroku Schedulerで
- Cloudflareを併用し、SSL対応
- 無料枠は1アカウントにつき、1アプリが限界かも

SSRの方は他にCloud RunやZEIT nowがある。
Cloud Runは立ち上げがGAEより遅いときので後手だけど、
ZEIT nowは気になってるので試してみたい(´ω｀)

以上!!

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで！

へんあいマップもリリースしました！

「偏愛マップ」を簡単に作れるWebアプリです!
へんあいマップも、Nuxt.js+Firebaseで開発してます!

偏愛マップは人見知りや口下手な人にも優しいコミュニケーションツールで、
勉強会、懇親会、オフ会などの余興・アイスブレイクや自分のプロフィールにも！

よかったら遊んでみてください(´ω｀)

全部無料でWebサービスを公開しよう！(Heroku + Laravel + MySQL + 独自ドメイン + SSL)

2019-10-31T08:02:18+09:00

サービスリリースしました(=ﾟ-ﾟ)ﾉ週休5日のプログラマーは快適という話。
上記で紹介した、Webサービス、My Favorite Recipe　の公開の手順を記事にしました。

◼️はじめに　(｡･ω･｡)

私は初心者です。

IT資格はわりと持っていますが、そんなの関係ありません。実務はほぼVBとVB.NETとVBAしかやってません。SQLもちょっとだけ。

WEB系は設計書レビューした程度です。テスト設計ならもうイヤという程にはやりました。

言い訳はこのくらいにして。

◼️作ったサービスを（気軽に）公開できる場所

LaravelでWEBサービスを作ってはみたものの、さてどこで公開するか？

ということで、試しにHerokuというもの？を使ってみることにしました。

私の事前知識は、Herokuって文字見たことあるけどなんて読むんだろう？まさかヘロクじゃないよね？程度です。（そのまさかの、"ヘロク"でした）

◼️無料万歳　v(｡･ω･｡)v

以下、すべて無料で揃いました。v(｡･ω･｡)v

・Heroku + Laravel + MySQL

・ドメイン取得は、Freenomを利用。

・SSL(https)は、Cloudflare を利用。

利用規約とか説明のための静的サイトは、Firebaseのhostingを使っています。

html/cssテンプレートはf-tpl.comです。これらもすべて無料です。

英語が読めなくても意味がわからなくても、無料ならとりあえず使ってみるの精神で挑戦しました。

◼️事前に用意するもの

・Laravel + MySQL で何か作る

ちなみに「SQLite」もHerokuで使えます。

◼️手順と参考にしたサイト

検索したら、Heroku+Railsの記事が多かったです。
Laravelでも(一部以外は)参考になるので活用しましょう。

・Herokuにアカウント登録して、がんばる o(｡･ω･｡)o

herokuにlaravel5とMysqlの環境を整える

Laravelをherokuにデプロイする(データベースはMySQL)

・独自ドメイン取得して、

Freenom

「Freenom 使い方」でGoogle検索すると使い方載ってるサイトが見つかると思います！

初めてHerokuで独自ドメインを公開するあなたへ

・httpsで接続できるようにがんばる o(｡･ω･｡)o

【完全無料】Herokuで独自ドメイン + HTTPSに対応する【Rails】

【無料】Cloudflareを使ってHerokuで独自ドメインで運用する方法

・MySQLを直で使いたいとき（自分のPCのMySQLの入っている環境でコマンドを実行しましょう）

HerokuのDBにローカルPCからアクセスしたいんだけど...

MySQL Serverに外部から接続する

・Herokuはアクセスしないと寝てしまうみたいなので対策

Herokuの無料dynoをスリープさせないで24時間稼働させる4つの方法

・おまけ (｡･ω･｡)

Firebaseを使って独自ドメインWebサイトを公開する方法

◼️メモ書き程度の記録（役に立つかわかりませんが私のブログです）
blog

◼️ちなみに

現在私は、MacでVagrant環境(CentOS)で開発しています。
CyberduckでファイルをMacローカルにコピーして、それをGitHubに上げて、それをHerokuの管理画面でポチッとDeployしています。

最初はコンソールからHeroku (Heroku Git) に上げていました（どっちでもいいのですが）。

◼️よくわからないこと

Vagrant環境でLaravelプロジェクトを作って、初回リリースは最初はLaravelプロジェクトを丸ごと載せてしまえばいいので問題ないのですが、
機能追加で、composer等で何か変更を加えた時に、何が変わったのかわからないと、本番環境に何を適用させたらいいのわからない、ということが起こります。

composer、今何してるの？っていう（便利だけど何がどこに入ったのかわからない）。
新しいパッケージを入れて使うなどの場合も、本番環境への反映のさせ方がわかりません。
プロジェクトフォルダを丸ごと更新するという技（？）で、ひとまず対応できますが・・・。

◼️おわりに

手順を全部書くと終わらないのでリンクで済ませてしまいましたが、何かあればココのコメントなどで聞いていただければ、だれかが答えてくれるかもしれません！？ o(｡･ω･｡)o　応援してます！気が向いたらやってみてネ o(｡･ω･｡)o　

Crieitの記事詳細ページが日本の技術系投稿サービスで最速になった

2019-03-04T07:21:16+09:00

Crieitの記事詳細ページのレスポンスがdev.toのような速さになりました。実際にはdev.toよりも速いです。技術記事系サービスとしてはQiita等を含めて日本一となります。

この画像は各サービスの記事ページのレスポンスにかかった時間を比較したものになります。タイミングによってばらつきもあるため速いものをメモしてみましたが、国内のQiitaやQrunchは170ミリ秒ほど、爆速で話題になったdev.toも意外にも30ミリ秒ほどで、平均だともうちょっと遅い感じがします。そしてCrieitは15ミリ秒くらいなのでダントツで最速です。

確認方法としては、トップページから記事ページのリンクをクリックするか、記事ページでリロードするかが分かりやすいと思います。

追記）
現在はZennがZennページ同じ速さになったので恐らく総合的に最速だと思います。Next.jsのキャッシュコントロールにまだ不足点がありますので、そちらがコントロールできるような実装がされると完璧になるでしょう。

なぜ速いのか

理由としては、Laravel側で動的にレンダリングしたHTMLをCloudflareというCDNでキャッシュしてもらっているため、サイトを閲覧している人のブラウザではそれが表示されているだけだからです。つまり、プログラム無しの単なるhtmlファイルを読み込んでいるのと同じレベルということです。実際に阿部寛のホームページも大体17ミリ秒という感じで同じくらいの速さです。

最近Gatsbyという静的サイトジェネレータが流行っています。これもコンテンツを事前にビルドし、サイト上では静的なファイルを表示するだけのため最速でコンテンツを届けることができるのですが、つまりはこれと全く同じレベルということです。しかもCloudflareのようなCDNは閲覧者の近くのサーバーから配信を行うため、ネットワークのレイテンシも非常に少なくあっという間にブラウザに表示されます。なので、速いのは何もすごくはなく、当たり前といえば当たり前のことです。

mizchiさんもブログで仰っていました。

フロントエンドの最適化の行き着く先の解の一つ、それは「CDN Edge で HTML をキャッシュして返却する」というものです。

Edge Worker PaaS の fly.io が面白い - mizchi's blog

完璧なのか

全然完璧ではありません。そもそも現在記事ページしか対応していないので、他のページは今までどおりです。

さらには、各ページには一度誰かがアクセスしなければならないので、投稿後や編集後に限っては今までどおりですし、普段誰もアクセスしない記事などはキャッシュされていないので最初に誰かがアクセスした時に重さを味わってもらわなければなりません。具体的にはChromeのDev Tools等で見ると下記のようにHITというレスポンスになっていればキャッシュが効いている状態です。（MISSになっている場合はリロードするとその後はHITになります）

あと僕自身の理解も完璧とは言えないので、何かしら勘違いしている可能性もあります。一度でもbotがアクセスされればキャッシュされるという認識ですが、適当な記事にアクセスしてみると意外にキャッシュされていないことが多いです。まだリリースして間もない時期ということもあり不明点や十分な確認ができていない部分も多いため、このあたりは引き続き要確認です。

ということで記事タイトルも文字数を気にしなければ「Crieitの記事詳細ページのHTML取得レスポンスはCDNのキャッシュが効いているページに限っては日本の技術系投稿サービスで最速になったが効いてなければすごく遅い」が正確です。

GatsbyやHugoとの違い

最近流行っているGatsbyやHugoを使えばよいのでは、と思うかもしれませんが、これらは事前にビルドが必要なため、Crieitのようなユーザー投稿型のサービスで利用することはできません。（何か方法があるのかもしれませんが、どちらにしろリアルタイムで反映していくのは難しそうな気がします）

そのためサーバーサイドでレンダリングしたものをそのままキャッシュしてもらうのが現実的な気がします。ビルドも不要です。

どんなメリットがあるのか

速い事自体が良い

とにかく速い事自体がメリットです。遅いとやはりイライラしますし、検索エンジン的にも速ければ速いほど良いと思います。そしてアクセスした時の気持ちよさも大きいです。

サーバーの負荷もない

CDN側で配信してくれるため、サーバーへのアクセスが来ません。そのためサーバーの負荷を抑えることができるようになります。実際にこのサーバーはGoogle Compute Engineの一番しょぼいサーバーで無料運用しているレベルのため、パフォーマンスも悪いしアメリカのリージョンのためレイテンシも大きいです。大体普通にアクセスすると１秒くらいかかってしまいます。（なので、dev.toは当然として、QiitaやQrunchも非常に高速という印象です）

まあそれはそれほどの問題にはならないのですが、記事や投稿が増えてそれに伴ってページが増えていくと、サイトを勝手に巡回するよくわからないbotのアクセスもどんどん増えていってしまいます。普通に閲覧してくれるユーザーさんのアクセスだけだと全く問題にはならないのですが、そういうbotのアクセスまで含めてしまうと結構限界が来るのも早くなってしまうのではないかと思います。

ですのでbotは全部もううちのサーバーに一切来なくなってほしいという思いからも対応を決意しました。

具体的にどうやったのか

そもそもCloudflareとは

CDNというのは各サービスの静的コンテンツをキャッシュし、それを世界中に張り巡らされた配信ネットワークを利用して、最も近い拠点から配信してくれる、というものすごい仕組みです。

例えばCloudflareではデフォルトではjs, css, 画像を配信してくれます。jsファイルやcssファイルは最近はビルドされていて数MBになっていることもあるため、サーバー上から配信するとかなり遅かったりします。うちでも初期はダウンロードに数秒かかっていました。CDNを通して配信すると一瞬で配信できるため、そもそもCloudflareがないと成り立たないレベルになっています。

デフォルトでは上記のファイルしか配信されないのですが、Page rulesを設定すると他のパターンでも配信できるようになります。それを用いて記事のURLのパターンを設定し、配信されるようにしました。

ヘッダーの調整が必要

しかし、ただPage rulesを設定してもキャッシュされません。というのもCloudflareはページのレスポンスヘッダの内容を見てキャッシュするかどうかを判断してくれます。キャッシュ期間を定めていればその期間でキャッシュを破棄して再度更新されるようにすることができますし、そもそも個人情報などを含んでいてキャッシュしてはならないページなどはキャッシュしないようになっています。

例えばLaravelとかであればデフォルトで全てキャッシュを無効化するレスポンスヘッダが含まれていますので、一切キャッシュされません。そのため、Middlewareやルーティングを設定してキャッシュを許可するためのレスポンスヘッダを返す必要があります。

具体的にはCache-Controlヘッダで下記を返すようにします。CDN用のMiddlewareグループを作成し、それ用のルーティングファイルにルーティングを記述するようにしています。ヘッダだけでなく、安全のためセッションも無効にしています。

public

好き勝手にキャッシュしていいよ、というやつです。

s-maxage

CDN向けのキャッシュ時間です。とにかく大きくして永久にキャッシュしてもらうようにしました。（実際にされているかどうかは検証できていませんが）

max-age

ブラウザ向けのキャッシュ時間です。s-maxageを指定していない場合はCDNのキャッシュ時間にも用いられます。これは長くしすぎるとCDN側のキャッシュが切れたことに気づくことができませんので、短めにしています。ブラウザキャッシュが切れてもCDNのキャッシュを取ってくるだけなので、問題はありません。

Set-Cookieヘッダを送信しない

Set-Cookieをレスポンスで返すと個人情報が含まれている可能性があると判断されるようでキャッシュが行われませんので送信しないようにします。

Laravelであればこのヘッダを無効にするためのミドルウェアを追加します。ただ、webのルーティングでこのミドルウェアだけ追加しても動作しないようなので、別途CDN用のミドルウェアグループを作ると良いと思います。

キャッシュのpurgeが必要

このままだと永久にキャッシュされてしまい、記事を更新しても反映されなくなってしまいます。そのため、キャッシュを破棄する必要があります。

Cloudflareの管理画面で可能ですが、APIも用意されているためそれを用います。

PHPでCloudflareのAPI経由でキャッシュを削除する

これで記事が更新された時にキャッシュをpurgeするようにしました。今のところは上手くいっている気がします。

ログイン状態をどう管理するか

静的にキャッシュしてしまっているため、サーバーサイドのテンプレート上でログインしている場合だけこれを表示、みたいなことはできなくなります。そのため、VuexのStoreにログインしている状態を保持しておき、ページが表示されたあとに必要なところだけ置き換えるようにしました。

置き換えると言っても単にVueコンポーネント化しておき、Storeの情報によって表示を切り替えているだけです。

リアルタイムのデータをどうするか

リアルタイムのデータというのは、例えばキャッシュはできないけど表示が必要なコメントやアクセス数などです。これらはページが表示されたあと、ajaxで取って来ています。つまりキャッシュされていればまだ良いのですが、キャッシュされていない場合はページの描画を含めると２回通信していることになります。

ただ、これは独自でアクセス数をカウントするため元々通信していたので変わらないのと、あとあくまでもやろうと思ったきっかけはbot対策のため、そのアクセスを軽減できれば問題ないかなと思っています。よくアクセスがあるページはだいたいキャッシュされた状態になると思いますし、そうでないページはさほどアクセスも来ないと思うので誤差かなと思います。とにかくbotを無視して、実際に見に来てくれる方の負荷だけを気にすれば良くなると考えると大きなメリットだと思っています。

問題点等の考察

まだ謎や問題点があるので考察していきます。単なる知識不足の勘違いの可能性もあるのでわかる方は是非アドバイスをお願いします。また、この考察はあくまでもCloudflareの話ですので、他のCDNサービスの場合は全然関係ない可能性もあります。

キャッシュされていない？

Google Analyticsでアクセスされたことが確認できたページや、サーバーのログでbotが来たらしきページにアクセスしてみるのですが、キャッシュが効いていない事が多いです。（前述のヘッダがHITではなくMISSになる）

そのため上手く期限が設定できていなかったり、そもそもCDN自体の仕様を勘違いしているのではないか、と心配になりました。ただ、もしかするとネットワークのエリア毎にキャッシュをしているようであれば、そのようになる可能性もあるのかな、と思いました。

前述のように近いエリアからコンテンツが配信されるので、必ずしも全てのCDNサーバーがキャッシュを持っているとは限りません。確かにそのあたり細かく連携するとレスポンスの速さが失われる要因になるような気もするので、エリアごとの管理で十分なのかなという気はします。purgeは多分全て連動で行ってくれるのかな、と思います。（どこかで瞬時に削除する、というような記述を見たような）

もしくはbotっぽいアクセスはキャッシュを使わず素通りさせるようにしているとか？

アップデート時にpurgeが必要

あとで気づいたのですが、よくよく考えると何かしら機能を更新してリリースしても、HTMLが変わらないのでリリースしたことが反映されません。ビルド済みのJavaScriptファイルはバージョニングされているのですが、それも新しいバージョンのものを見てくれないので、結局何かアップデートした際にはpurgeが必要で、また全てのページが一度重い状態になります。頻繁にアップデートすればするほどキャッシュが効かない状態が多くなります。（とはいえ対応前と変わらない状況ではありますが）

そのためとりあえず手動全purgeするか、しんどくなってきたら今手動でやっているデプロイを自動デプロイできるようにしてその中に組み込むか、あとはCDN芸をやめて最速の座から降りるか、というところになりそうです。

まとめ

とりあえずCloudflareを使った無料でのCDN芸をやってみたかった、というところもあったので試してみました。有料にはなりますが、他のCDNサービスであればもうちょっと楽な運用ができるのではないかと思います。もしログイン情報をあまり使っていないサービス等であればすぐにでも導入できたりするかもしれません。

Crieit上でもボードのデータ数が増えてきているため、こちらもCDN化を試しているところです。プライベート機能があるのでそのあたりでちょっとコツが必要だったりします。また、サーバー側のアクセスログもどういう風にアクセス数が推移しているかも解析してみたいなと思っています。また面白い情報が出たら記事にしてみます。（詳しく設定を確認していないのでもう消えているかもしれませんが…）

PHPでCloudflareのAPI経由でキャッシュを削除する

2019-02-27T10:09:15+09:00

Cloudflareの管理画面でできる機能の多くにはAPIが用意されており、キャッシュの削除もAPI経由で行うことができます。これにより投稿に応じて指定したページのキャッシュをpurgeするといった事が可能です。

自分で処理を作っても良いのですが、どうもCloudflareの公式がPHP用のSDKを作成しているようなのでそちらを使ってみました。

インストール

composer require cloudflare/sdk

Adapterの作成

API接続用のAdapterを初期化します。下記の情報が必要になりますので、Cloudflareのダッシュボードの分かりやすいところに書かれていますのでそちらで確認し、アプリケーションの.env等に設定しておくと良いと思います。

アカウントのメールアドレス
API Key
ZONE ID

色々なAPIがありますが、共通の初期化です。

use Cloudflare\API\Auth\APIKey;
use Cloudflare\API\Adapter\Guzzle;
use Cloudflare\API\Endpoints\Zones;

$key = new APIKey(config('services.cloudflare.email'), config('services.cloudflare.key'));
$adapter = new Guzzle($key);

キャッシュのpurge

キャッシュを削除するにはzonesというエンドポイントの機能を使います。先程のadapterを利用して実行します。

$zones = new Zones($this->adapter);
try {
    $zones->cachePurge(config('services.cloudflare.zone_id'), [$url]);
} catch (\GuzzleHttp\Exception\RequestException $e) {
    \Log::error($e->getMessage());
}

URLのホスト名がおかしかったりすると例外が発生するので適宜エラー処理を行ってください。cachePurgeの戻り値はboolのためレスポンスの詳細は分かりませんが、$zones自体にレスポンスが保存されているのでダンプすれば確認可能です。（成功しているとたいした情報は無いのであまり意味はないです）

僕はなぜかpurgeされずおかしいな、と思っていたらURL指定が間違っていたりしたのですが、Cloudflare的には正常のため特にエラーなども出ないので、そのあたりはしっかりログを残して確認しておいてください。

CloudflareのDDoS攻撃対策を調べてみた

2018-11-06T09:29:58+09:00

CloudflareはCDNだけでなくDDoS対策も行っているというのは知っていたのですが、具体的にどういう機能があるのかよく分かっていなかったので調べてみました。

というのも先日からQrunchが攻撃を受けて非常に辛い状態が続いていたようです。個人開発のサービスに攻撃が来ると正直対処のしようがないというのが現実です。サーバーを使っていたりするともう止まるしかありませんし、サーバーレスにしていたら今度はクラウド破産の危険性があります。こういう時はこういったファイアウォールサービスに頼るしかなさそうです。

正直こういうことはどのサービスにも起こりうることで、考えれば考える程恐ろしいのでざっとCloudflareのDDoS対策について調べてみました。

Firewallの設定

Firewallの設定画面を開くとSecurity Levelの設定があります。恐らくここが一番シンプルなベースとなるセキュリティ設定項目になりそうです。

初期設定はMediumとなっています。 Essentially Off から I'm Under Attack! までのレベル設定があり、上から順番に低いレベルのようです。

Essentially off

最も脅威となる攻撃にのみ対処します。

Low

そこそこ脅威となるアクセスを防御します。

Medium

最も脅威となる攻撃とそこそこ脅威となるアクセスを防御します。

High

14日間に脅威を与えた全ての閲覧者に対して防御を行います。ここからその場限りでなく過去の行動も見ての防御となるようです。

I'm Under Attack!

現在攻撃を受けている場合の防御のようです。全ての閲覧者はサービスにアクセスする前に間に１ページ確認用の画面が表示され、問題ないと判断された場合のみにサービスにアクセスできるというもののようです。

Qrunchも現時点の最もひどい状況で利用していたものと思われます。確かにこれであれば連続アクセスが不可能のため、確実に防御はできそうです。そのかわりOGP等も表示できなくなっているようですし、他にも色々と影響がありそうですのでなかなか辛いところではありそうです。

その他

上記のようなベースの設定以外にもいくつかの機能があります。

Firewall Rules

こちらは独自にルールを設けて攻撃を遮断できます。ただ、IP、国等、攻撃者の情報がある程度分かる場合のみに限られそうです。

Rate Limiting

おかしな頻度でアクセスしてくるユーザーを遮断できます。軽い設定にしすぎると普通のユーザーも排除してしまいそうですので使う場合はきっちり考えたほうが良さそうです。

あとは強力な設定を使いたい場合は有料になるようです。

ただこちらもIPを大量に持っている攻撃者の場合は対策が難しいかもしれません。

まとめ

その他もいくつか設定がありそうですが、汎用的な設定は他にはなさそうですので、攻撃者の特性を把握しつつ設定を行っていく必要があるのかもしれません。

あとは並行してサーバーを強化したり、攻撃しにくい構成にしたりする必要があるのかもしれませんが、個人開発ではなかなか厳しそうです…。個人開発だけでなく、最近は質問箱も攻撃を受けて止まっていたりするようですので、ユーザーや関係者が穏やかな心で見守ってあげるというところが一番重要なのかもしれません。

あとは攻撃を受けて止まってしまっても、情報が閲覧できるようにTwitterの公式アカウントや、ステータスだけ確認できるページなどを用意してあげるのが良さそうです。