solaの投稿 - Crieit

MariaDB (MySQL innoDB) が急にダウンする際に行ったパラメーターチューニング

2020-04-06T06:18:12+09:00

はじめに

処理が遅いアプリの改善を行った後、処理性能が改善されたものの、MariaDB が急に落ちる問題が頻発。
落ちるたびにシステムが停止し悩まされたが、なんとか解決したので備忘録。

結論

アプリ側で処理数が上昇した事で、IO 負荷が高くなっていた事が根本原因。
ストレージの IOPS を考慮して innodb_io_capacity, innodb_io_capacity_max, innodb_read_io_threads, innodb_write_io_threads を可能な限り増やす。増やすと上昇値が平準化される。負荷が上がり innodb_log_file_size の上限を超えて落ちることが無くなる。
innodb_buffer_pool_size は可能な限り上げる。余裕を持たせ処理を平準化させる。
innodb_log_buffer_size も一定水準まで上げる。上の対処を行った場合でも、負荷が上昇するとこの数値次第で落ちる原因になる。

環境

項目	値
筐体・メモリ	さくらVPS 16GB
ストレージ	SSD
用途	nginx PHP ウェブサーバー + DB サーバー

具体的な my.ini 設定値 (関連値含む)

innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_read_io_threads = 12
innodb_write_io_threads = 12
innodb_buffer_pool_size = 6144M
innodb_log_buffer_size = 250M

innodb_buffer_pool_instances = 4
innodb_flush_method = O_DIRECT
innodb_checksum_algorithm = CRC32
innodb_change_buffer_max_size = 10
innodb_log_file_size = 256M
innodb_log_files_in_group = 2
innodb_lock_wait_timeout = 10
innodb_lru_scan_depth = 1024
innodb_flush_neighbors = 0
innodb_read_ahead_threshold = 0

経緯や補足など

特定の処理タイミングでのみ落ちていた為、アプリ側の問題を疑ったが、単純な参照と更新を繰り返すだけの処理な為、アプリ側の問題はほぼなかった。
MariaDB そのものについての情報が少ない。MySQL の情報はそこそこある為、適宜参考にする。
用いている MariaDB 10 は MySQL 5.6, 5.7 両バージョンをベースとしたキメラで若干ややこしい。
監視ツールの Mackerel の MySQL プラグインが役立った。知識がなくとも何かが制限を超えたような事が見て取れるので当たりが付けられた。
innoDB Checkpoint Age (Uncheckpointed) が急激に上昇し MariaDB が落ちていた。当初は innodb_log_file_size を上げて解決を図った。
多少ライフタイムが伸びたが、問題の根本は IO パフォーマンスにある為、上記は本質的な解決策にならず同様の問題が発生していた。
IO パフォーマンスはあくまで設定次第であり、物理側の IOPS に併せて勝手にスケーリングされる訳ではない。
ストレージが HDD では対処不能だったので SSD で助かった。
上記パラメーターが最善値であるか不明。安定し始めてから1週間程度な為、再調整の可能性あり。

参考

YouTube API Quota 無料割り当て増申請が通った件

2020-03-31T00:53:18+09:00

はじめに

こちらの英語専用フォームから YouTube API Quota の割り当て増申請を行ったところ、最終的に一部受理されましたので備忘録です。

Google からのメール

Hello,

Your quota extension request has been approved based on the information you provided and your representation that your use of YouTube API Service(s) are in full compliance with the YouTube API Services Terms of Service.

The total quota for ************ is now 1,500,000 units / day.

Please note that the quota extension has been granted ONLY for the use-case(s) mentioned in your quota extension request application and we may change your quota based on your actual quota usage as well as on your continued compliance with the YouTube API Services Terms of Service at any time.

Do not reply to this email, you may complete and submit this form to get in touch with us.

Thanks,

YouTube API Services team

Twitter

【速報】Google 様から YouTube API Quota 500,000/day 頂戴する事に成功
— sola (@sola_io) March 26, 2020

つぶやいたところ

(もしよければ)Q1. いつの申請？(やり取りの期間は？)Q2. 500,000/dayは申請時の希望通り？Q3. 現状Quota使用量と将来見込みは？Q4. みんなへのアドバイスはある？Q5. YouTubeにひとことどうぞ！
— かんたんきかく (@kantankikaku) March 27, 2020

このような質問を頂きました。
元々申請が通ったら記事を残すつもりでした。
項目がまとまっており嬉しい限りです。

回答 (備忘録)

Q1. いつの申請？(やり取りの期間は？)

2019年12月22日に申請を送っていたようです。
2020年3月26日に承認が降りたので、約3ヶ月程度のやりとりです。

Google (YouTube API Service team) から7回メールが届き、(Google 翻訳を活用した拙い英語で) 丁寧に回答しました、

Q2. 500,000/dayは申請時の希望通り？

5,119,530 で申請しました。
約1/10ですが、以下の通りカツカツな状態が続いていたのでありがたいです。

Q3. 現状Quota使用量と将来見込みは？

青のグラフが現状の使用量目安です。

（直近で減ったのは作為的なものですが、Quota 使用量調整の結果、25%程度の使用量まで落ちていた時期が2週間ほどありました。）

申請分が満額通ればガッツリ使ったのですが、思い切って使用量を増やすには（今後の自然増を考慮すると）中途半端なボリュームです。・
追加申請で再度増やして頂けるかなんとも言えないので、増加分は優先される機能に割り当てたいです。
（出来れば安全マージンを持たせながら…）

Q4. みんなへのアドバイスはある？

英語が怪しい私ですが、拙くても内容がそれっぽい感じであれば申請が通るようです。
少しやりとりが面倒ですが、是非チャレンジしてみて下さい。

KUSANAGI wp-cron を cron で動かす

2019-05-06T09:06:29+09:00

はじめに

ウェブ上に同様のタイトルのソースはいくつかあったが、何故かそのままでは参考にならないものが多いため、改めてまとめ。

方法

コンソール画面ログイン後、以下のコマンドを実行。

cd /home/
sudo mkdir cronuser
sudo chown cronuser:www cronuser
sudo chmod 750 cronuser
sudo vim /etc/crontab
i

一番下に以下の内容を記載。

*/1  *  *  *  * cronuser php /home/kusanagi/kusanagi_html/DocumentRoot/wp-cron.php > /dev/null 2>&1

※ "kusanagi_html" の部分はプロビジョニングディレクトリを指定
※ "/1" の数字部分は実行間隔（分）を指定

[esc] キー押下。

:wq!

で完了。

動作確認

以下のコマンドで cron 実行結果を確認できる。

sudo tail -f /var/log/cron

WordPress では予約投稿が公開状態になる事を確認したり「WP Crontrol」等のプラグインを用いると楽。

補足

作成するユーザー名は cronuser 以外でも問題ない。
既存ユーザーをそのまま用いても良いが、権限の問題もあるため、専用ユーザーを用意した方が無難か。

参考

KUSANAGI で環境ごとにページキャッシュを生成する

2019-04-14T15:37:04+09:00

はじめに

KUSANAGI にはページキャッシュ機能があるが、通常環境ごとにキャッシュが分かれず、PCやスマホで表示が異なる場合問題が生じる。

方法

KUSANAGI 設定画面デバイス切替ページにアクセス

https://hogehoge.com/wp-admin/admin.php?page=kusanagi-core/core.php&tab=theme-switcher

ホスト等は各自の環境に置き換えて下さい。

「デバイスによるテーマ切り替えを停止」のチェックマークを外し、[変更を保存] をクリック

解説

方法はとてもシンプルでした。テーマ切替を行っていない場合でも有効。

KUSANAGI で MySQL が頻繁に落ちる際の対処

2019-04-14T15:12:18+09:00

環境

名前	バージョン
VPS	さくらインターネット 4GB
OS	KUSANAGI 8.4.2-2 (CentOS7 ベース)
ウェブサーバー	nginx 1.15.10
PHP	PHP 7.3.4
MySQL	MariaDB 10.1.38
アプリケーション	WordPress
その他	Mackerel

問題発生

サイトにブラウザからアクセスすると「データベース接続確立エラー」となる。

状況確認

コンソールにて。

sudo cat /var/log/messages

以下のログを発見。

Apr 14 00:31:06 hoge kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

MySQL が落ちている。

暫定対処

コンソールにて。

sudo systemctl start mysqld

「データベース接続確立エラー」は解消される。

数時間後に問題再発

「データベース接続確立エラー」

再度状況確認

コンソールにて。

sudo cat /var/log/messages

同様のログを確認。

Apr 14 07:48:32 hoge kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Mackerel でのメモリ状況を確認。

メモリを食いつぶした後スワップまで喰って無事死亡している。

nginx ログの確認

詳細は割愛するが、nginx のログを確認したところ、ブルートフォースアタックでの接続数増、pubsubhubbub での接続数増、行儀の悪い bot からの接続数増など様々な痕跡があった。

なお、KUSANAGI による nginx ログは以下の場所に分散している。
（筆者はしばらくの間ログ分散に気付かず、確認に時間がかかった。）

WordPress SSL

/home/kusanagi/kusanagi_html/log/nginx/ssl_access.log

※ kusanagi_html はプロビジョニングディレクトリ

WordPress HTTP

/home/kusanagi/kusanagi_html/log/nginx/access.log

※ kusanagi_html はプロビジョニングディレクトリ

恒久対処

コンソールにて。

sudo vim /etc/php-fpm.d/www.conf
/pm.max_children = 
i

PHP-FPM の設定を変更する。

pm.max_children = 50

を以下に変更。

pm.max_children = 17

[esc] キーで編集終了。

KUSANAGI (nginx + php-fpm) 再起動

sudo kusanagi restart

対処後の確認

Mackerel でのメモリ状況

ピーク時のメモリ消費量が 3.5GB 程度と、上限の 4GB から 0.5GB 程度余裕のある状態で消費しきらずに、スワップアウトも発生しない。

結果、「データベース接続確立エラー」とならず接続状況は安定している。

解説

PHP-FPM の pm.max_children はアプリケーションの最大プロセス数。php.ini ファイルでの memory_limitは 128M に設定されているため、pm.max_children を 17 に設定した場合 PHP-FPM のみで食いつぶすメモリ量を 2GB 程度に抑えることができる。
デフォルトで 1GB 程度消費しているため、計約3GB。さらに MySQL などで 0.5GB 程度消費しているものと思われる。
詳細は top コマンド等で確認できる。

今後

万が一落ちた場合に monit で MySQL の自動再起動、fail2ban によるブロッキング設定を行いたいが後ほど。

参考

MariaDB の InnoDB がぶっ壊れて起動できなくなったので復旧した

2019-04-04T03:18:36+09:00

はじめに

右往左往して復旧に6時間程度かかった。もうこりごりなので内容をざっくりまとめる。

手順（概略）

KUSANAGI（CentOS7）での手順。

sudo su
vi /etc/my.cnf.d/server.cnf
i

[mysqld]
innodb_force_recovery = 3

[esc] キーで vi 終了。

systemctl start mysqld
mysqldump -u root -p -x --all-databases > alldatabase.dump
systemctl stop mysqld
rm -rf /var/lib/mysql/*
yum remove -y MariaDB-devel MariaDB-client MariaDB-server
yum install -y MariaDB-devel MariaDB-client MariaDB-server
systemctl start mysqld
mysql -u root
UPDATE mysql.user SET password=password('password') WHERE user = 'root';
CREATE USER 'username'@'localhost' IDENTIFIED BY 'password';
GRANT ALL ON db_name.* TO 'username'@'localhost';
flush privileges;
exit;
mysql -u root -p < alldatabase.dump

要点

innodb_force_recovery を 3 以下に設定しておくと InnoDB が壊れていても Read only でとりあえず起動出来るようになるっぽい
起動したら mysqldump でバックアップ。MariaDB を再インストール後に戻す
構成ファイルがいかれていたので /var/lib/mysql/ 配下を消しておく。（必要であれば設定ファイルは逃しておく）

原因

数日前に単純に MariaDB が落ちたことがあり、何かしら高負荷がかかっている可能性があるが、アクセス数も多くなく、環境である仮想ハードウェアの負荷も目立った様子は無い。できれば関係ログを追って探りたいところだが不明。

(2019.4.14 追記) 原因判明したので記事書きました

KUSANAGI で MySQL が頻繁に落ちる際の対処 - Crieit

参考

MySQLでInnoDB破損したときの復旧方法 - Qiita

KUSANAGI で PHP7 + nginx を利用している際のタイムアウト時間設定

2019-02-02T09:32:29+09:00

はじめに

デフォルトでファイルが複数あって迷うので、備忘録です。
以下はタイムアウト時間が1時間（3600秒）の場合の例です。

必要な設定箇所は 3 (4) ファイルです。

PHP7

php.ini

/etc/php7.d/php.ini

max_execution_time = 3600

PHP-FPM

/etc/php7-fpm.d/www.conf

request_terminate_timeout = 3600

nginx

SSL

location ディレクティブブロック location ~ [^/]\.php(/|$) {} 内に記載があります。

/etc/nginx/conf.d/kusanagi_html_ssl.conf

fastcgi_read_timeout 3600s

HTTP

SSL を用いている場合は不要ですが念の為。

/etc/nginx/conf.d/kusanagi_html_http.conf

fastcgi_read_timeout 3600s

最後に

PHP (PHP-FPM), nginx の再起動を忘れずに。
KUSNAGAI の場合は、以下のコマンドで PHP (PHP-FPM), nginx の再起動を同時に行ってくれます。

sudo kusanagi restart

WordPress プラグイン「Contact Form 7」の reCAPTCHA (v3) ラベルを必要なページのみ表示させる

2018-12-17T13:28:01+09:00

はじめに

世界で最も使われている WordPress プラグイン「Contact Form 7」にて、後方互換性の無いオプション機能のアップデートが行われました。

具体的には本プラグインが reCAPTCHA (v3) に対応し、同時に旧版である reCAPTCHA (v2) への対応が廃止となりました。

v2 を用いている場合はアップデートと同時に無効となります。
引き続き reCAPTCHA を用いる場合は v3 への対応が必要で、新たに v3 用のサイトキー、APIキーの設定が必要です。

こちらの作業は管理画面上の操作で済むので、大した問題とは捉えていなかったですが、この設定を行うとあらゆるページ上で以下のラベルが表示されます。

これは非常にうざいので、以下のコードで必要なページに対してのみラベルを表示させるようにしました。

コード

以下のコードをテーマの functions.php 等に記載します。
'your_pagename' は適宜お使いのページスラッグ置き換えて下さい。

    add_action('send_headers', 'remove_recapcha');
    function remove_recapcha($wp)
    {
        if (array_key_exists('pagename', $wp->query_vars) && $wp->query_vars['pagename'] === 'your_pagename') {
            return;
        }
        remove_action('wp_footer', 'wpcf7_recaptcha_onload_script', 40, 0);
        remove_action('wp_enqueue_scripts', 'wpcf7_recaptcha_enqueue_scripts', 10, 0);
    }

実例

お問い合わせ – にじさんじ配信スケジュール

現在の Crieit のいいところ・イマイチなところと要望

2018-12-17T12:56:45+09:00

はじめに

040.副業元年／だらさんインタビューVol.4■Micro Hardening | フリーランスエンジニア実体験ブログ

こちらを聞いて、書こうと思い至りました。内容は個人的なものです。

いいところ

専門度の高い記事が多く、読み応えがある
書き込みが多すぎずパブリックタイムラインがしっかり追える
画面構成・機能がシンプルで、読んだり書いたりする事に集中できる
お題を気にせずに自由に書ける
ちゃんと個人フィードを吐いてくれるので、ブログとして使える
カノニカルを設定できる
シェアされやすい（スルーされにくい）
中の人と直接やり取りしやすい

イマイチなところ

細かい点で作り込みが甘い

要望

はてブのシェア数を記事上で知りたい
Twitter 上でアイコンを変更した際にアイコン画像が消えないようにして欲しい
Twitter 同様にプロフィール上の URL にリンクを貼って欲しい（nofollow で構わない）

さいごに

Posterous というブログサービスが好きだったのですが、似た雰囲気を感じています。
たまにしか書かないつもりですが、こちらをブログっぽい感じで使っていこうかなと思っています。

初めてのウェブサービスを WordPress + Vue.js で個人開発した話

2018-12-06T00:00:50+09:00

はじめに

11月25日(日) に「にじさんじ配信スケジュール」と呼ばれるウェブサービスをリリースしました。

正確には初めてリリースしたサービスでは無いのですが、会員登録機能が用意された本格的なサービスを出した事がこれまでなく、実質的には初めてのサービスと呼んでも良いだろうと考えています。

という訳で、Crieit「個人開発サービスに用いられている技術 Advent Calendar 2018」6日目は「初めてのウェブサービスを WordPress + Vue.js で個人開発した話」と題して、開発に WordPress や Vue.js を用いたこと、ウェブサービスを作るまでの話や、リリース直後の話をしたいと思います。

n番煎じなテーマですし、蛇足に感じられる内容も多々あるかと思いますが、適宜必要な箇所をお読み頂ければ幸いです。

この記事の想定読者

これからウェブサービスを個人で作りたい方や開発中の方
ウェブサービスで実際に用いられている技術やツールを知りたい方
開発ノウハウを知りたい方
技術面以外の話にも興味がある方

開発経緯

「にじさんじ」と呼ばれるバーチャルライバー (VTuber) グループが存在しています。

僕はこちらのグループのファンなのですが、公式がスケジュール情報の発信を行っておらず、スケジュールを把握しにくい問題がありました。
スケジュール情報を発信する非公式サイトやアプリも存在していますが、閲覧がしにくく使い勝手が悪い状態でもありました。
そこで、スマートフォンでも十分に閲覧でき、にじさんじライバーの配信スケジュールに特化したウェブサービスを作れば需要があるのでは考え、開発に着手しました。

主な機能

元々はシンプルにスケジュールを確認出来るだけのシンプルなサイト開発を考えていましたが、
自分自身が必要十分に感じるレベル（このサービスユーザーのペルソナの1つは自分自身です！）に加え、サービスとして多くの方々に利用頂く事を前提に機能検討した結果、リリース時は以下の機能を実装しようという結論に至りました。

ユーザー向け機能

バーチャルライバー (VTuber) グループ「にじさんじ」メンバーの生配信スケジュールの閲覧
実際の生配信（ライブ）、アーカイブ情報の閲覧
ライバー情報の閲覧
ライバーのフォローを元にしたスケジュール等の情報閲覧（要会員登録）
配信時間前のメール通知（要会員登録）
Twitter へスケジュール情報まとめツイート
端末を問わず利用可能（レスポンシブ）
ネイティブアプリっぽいリッチなデザイン

運営者向け機能

スケジュール、ライブ、アーカイブ情報の自動取得（API、スクレイピング）
情報登録時のメール通知
管理画面

機能についての詳細

ユーザー向け

にじさんじは59名（現在は58名）と多くのライバーを擁します。
ライバー全体の情報を網羅しようとした場合の情報量は馬鹿に出来ません。
ユーザーごとに追っているライバーは異なるため、にじさんじ全体の情報をすべてのユーザーに一律に見せる事はユーザーの負担に繋がります。
また、にじさんじには「1期生・2期生（無印）」「ゲーマーズ」「SEEDs」という3つのグループが存在していますが、それぞれを追っているファン層は異なります。
さらに、グループ問わず人気ライバーを追っている方や、特定のライバーに搾って追っている方など、ユーザーの興味は多種多様です。

そこで、以下のフィルタリング機能を備えることにしました。

にじさんじ内のグループごと
ユーザーによるライバーのフォロー

フォロー機能を用意する場合、会員機能の実装は欠かせません。

また、当サービスを多くの方に継続的に使っていただくことを考えた場合、アプリっぽいデザインで使いやすい UI を提供する事は欠かせないだろうと考え、フロンロエンドを Ajax で提供することに決めました。

運営者向け

過去に情報の手動更新で苦労した経験があった為、情報の自動取得は欠かせませんでした。
また、テストデータを作成したり、自動化を行った場合であっても、情報の編集は適宜必要となる事から、GUI の管理画面の存在も必要でした。

使用技術・開発ツール

今回用いた技術・開発ツール

WordPress

開発フレームワークとして WordPress を用いた理由ですが、

見知った技術であること
データの CRUD 、ページ作成、ユーザー認証など、会員機能付きウェブサービス作成に必要十分な機能が揃っていること
管理画面が標準で用意されていること
「プラグイン」を用いて楽が出来ること
枯れた技術であること

上のようなものが挙げられます。

特に「管理画面が標準で用意されていること」は重要で、管理画面が必要な状況において、これがあるのと無いのとでは開発工数に雲泥の差が生じます。

データモデルの構造上、複数のデータ項目への検索実装が難しい点が弱点ではありますが、検索を主体としたサービスでは無いため、あまり問題にならないと判断しました。

Advanced Custom Fields Pro

WordPress にてカスタムフィールドを扱う際 Advanced Custom Fields が欠かせません。
繰り返しフィールド（配列）を簡単に用いることが可能な有料の Pro 版を使用しています。

GUI でデータ構造や管理画面を作成する事ができ、大変重宝しています。
コードを書かずに済む作業は、書かずに越したことがないです。

WP-REST API

Ajax でのレンダリングを行う場合、情報元となる API が欠かせません。
以前は admin-ajax.php を利用して API を1から作る必要がありましたが、
今では WordPress コアに標準で API の機能が備わっています。WP-REST API を使わない手はありません。

jQuery

こちらも WordPress コアに標準で含まれています。
ユーザー画面においてもツールバーの描画に必要で、WordPress を用いる場合欠かせません。
また、後述する Semantic-UI のスクリプトも jQuery で出来ており、jQuery に依存せざる得ない状態です。

とはいえ、単一 DOM の表示切り替えといったシンプルな仕事は jQuery 向きであると言えると思います。
また、Ajax 用の仕組みも備わっており、上のような前提が存在する状況においては、別途 axios といったライブラリを用意しなくとも済む点は引き続き評価出来ます。

Vue.js

Ajax にて取得したデータを用いて画面を構成する場合、開発効率やコードの視認性、いずれを考慮してもビューとコントローラーの仕組みは欠かせないだろうと思います。

Angular, React, Vue.js あたりが採用候補にあたると思いますが、jQuery との併用可能な（最新バージョンを持つ）フレームワークは後者2つのみです。
元々 Riot.js を使っていた身として、またテンプレートエンジンライクな PHP 使いとして、 Vue.js の記法はとても親近感があり書きやすいものでした。
また、Vue CLI, Nuxt.js といった関連技術も充実しており、廃れる心配が少ない技術だろうという点も技術選定の後押しポイントになりました。

Semantic-UI

UI コンポーネントは Bootstrap が有名で、僕も用いたことがありますが、
あまりにも多くのサイトで用いられている事から見慣れてしまい、飽きを感じ始めていました。
そういった状況で Semantic-UI を見つけた時は感動したのを覚えています。

選定理由としてデザインの好みの影響は多分にありますが、UI パターンが Bootstrap 並に備わっており、技術者として実用に耐えうる UI コンポーネントであると感じています。

Twitter API

会員登録・認証に用いました。

利用に審査が必要となり導入敷居が上がりましたが、
Google 翻訳の手助けを得つつ簡単な英文で申請を行ったところ、サクッと審査がおりました。

また、Gianism と呼ばれる WordPress プラグインがあった為、認証に係る新規コードはほとんど書かずに利用することが出来ました。

YouTube API

YouTube のライブ、動画データを取得する為には欠かせませんでした。

動画 API は REST 形式でも提供されており、利用の敷居はとても低くなっています。

PHPMailer

メール通知の際にメール配信の仕組みが必要でした。

今回、サーバーはさくらインターネットさんのものを用いましたが、多くのスパム業者の利用実績の影響からか各プロパイダからの締め付けが強く、標準ポートでのメール配信は厳しいものがありました。

PHPMailer を用いると、Gmail といった各プロパイダからの受信規制の少ないサーバーを利用できるため、メール配信にあたり安心感があります。

さくらインターネットVPS + KUSANAGI

サーバーはさくらインターネットVPS（標準2GB） + KUSANAGI という形を取りました。

さくらインターネットVPS は国内サービスのため、契約周りでの安心感がありますし、国内サービスの中での信頼性は随一です。
また、ビジネス目的でのサービスでないため運用コストは抑える必要がありますが、従量課金で無く、不意な請求が絶対に起こりえない点もポイントでした。

KUSANAGI については WordPress サイトを運営する為に必要な nginx, PHP の設定がデフォルトで最適化されており、SSL 化に欠かせない Let's Encrypt も自動で走るなど、WordPress サイトを運営するために至り尽くせりな機能が OS レベルで備わっています。

heroku や Cloud9 といった PaaS に頼る手も検討しましたが、環境セットアップの安易さはそれらのサービスに劣らないことや、さくらインターネットの場合は VPS であってもスケールアップ可能といった特徴を持つことから、最初のウェブサービスはこの構成から始めることにしました。

VCCW

開発環境は VCCW を用いました。
VCCW とは Vagrant がベースの WordPress 開発に最適化されたツールです。
macOS での導入は一瞬でした。

PaaS ではなく VPS を用いた理由としては VCCW の存在も大きく、同梱された Wordmove で DB 含めたデプロイ（同期）が一瞬で完了するなど、VCCW を用いた際の総合的な体験がとてもスマートで感動しました。

実は、これまで Filezilla (FTP) を主なデプロイ手段としていましたが、どうして早く試さなかったのかと反省しています。

Visual Studio Code

コードはもっぱら Visual Studio Code で書いています。
これまで Sublime Text を用いていましたが、稀に落ちたり OS ごとの挙動差分が気になっていました。
Visual Studio Code は開発環境をベースとしており拡張性も高く安心感がありますし、動作が軽快なためストレスフリーにコードが書ける点がとても評価出来ます。

Google Chrome

開発関係のプラグインが豊富である事、検証ツールにてスマートフォンやタブレットの画面エミュレートが安易である点が良いです。

もちろん、最終的な動作確認の際は各種ブラウザ（Safari, Firefox, Edge, Opera, それぞれ最新）・OS（macOS, Windows, iOS, Android, それぞれ最新）でのテストも行っています。

Git

純粋にファイルのバージョン管理目的で用いました。

ちなみにホスト先は Bitbucket、クライアントには SourceTree を用いています。

Macbook Pro (13inch)

ハードウェアの好みで用いています。

スペックですがメモリ16GB、CPU Corei7 2.5GHz デュアルコア、SSD 512GBになります。

VCCW にて仮想環境を走らせる都合上、ある程度のメモリが必要となります。
8GB では処理が重く感じられる為、7月に new MacBook から移行しました。

メモ (Apple)

ToDo リスト機能が便利でした。

今回用いなかった技術・開発ツール

Gutenberg

WordPress のエディタにブロックの概念が導入され、レイアウトレベルで見たまま編集が行えるようになりました。その機能名の事を Gutenberg と呼びます。
WordPress 界隈においては有名な新技術ですが、Gutenberg を無効化する Classic Editor を入れ導入を見送りました。
以下のような理由からです。

今のところ新しい技術であり今後仕様が頻繁に変わるリスクがある
画面の表示要素を再利用したり、レイアウトを頻繁に変更したり、デザインを他人に任せたり、ユーザーに編集させたりといった、Gutenberg のメリットを享受可能な状況に置かれていない

Firebase

フロントエンド中心の開発の勉強も兼ねて用いることを考えましたが、自動化にあたってスクレイピングが必要で、サーバーサイド中心の開発にせざる得ませんでした。

Laravel, CakePHP 等の開発フレームワーク

複雑なデータモデルが必要であったり、検索が重要となるサービスを開発する場合は WordPress では限界があったと思いますが、そうではありませんでした。

Drupal, concrete5, baserCMS, Movable Type 等の CMS

前者2つについては、掲示板など会員管理周りの機能が充実している事やエディタのリッチさが売りかと思われますが、その点において今回メリットには感じませんでした。

baserCMS については、CakePHP がベースに採用されており、かつ管理画面も備わっている事から、開発者目線ではとても魅力的です。
今回は採用していないですが、データモデルが複雑で、管理画面もサクッと用意したいという状況においては、選ばざる得ない選択肢だと思われます。

Movable Type は WordPress 以上に一般サイト制作に特化しており、会員管理等の標準機能が弱い印象があります。

CDN

入れれば速くて良いのですが、コストが気になります。趣味のサービスには向かないでしょう。
今回は KUSANAGI (nginx + サーバーキャッシュ) に頑張ってもらっています。

gulp, babel, webpack 等のフロントツール

実はまともに用いたことがありません。（勉強せねば…）
ただ、これらのツールが活用できずともウェブサービスを開発し運用を開始出来る状態になる事が分かります。

初心者はWebpackの事は一度忘れた方が良い - Crieit

AMP

文章や写真ベースの記事がほとんど無く、JavaScript に頼るページも多く導入は見送りました。

ただ、Vue.js でのレンダリング結果を Googlebot が拾ってくれない都合で、Vue.js のレンダリングが完了するまでは SSR の結果を表示する仕組みを入れた事で、JavaScript に頼るページがほとんど無くなりました。

AMP を導入した場合 SEO 効果も期待できるため、後々導入する可能性があります。

PWA

アプリっぽい見た目にした事や Ajax での情報取得は PWA 化を見越しての方法でもありました。
一旦 apple-touch-icon の設定でお茶を濁しましたが、AMP 同様後々導入する可能性があります。

Docker

VCCW のお陰で、動作環境としては Linux ベースで開発が出来ており、本番サーバーに環境も近いはずで、環境を揃える意味ではほとんど不要だろうと考えていたのですが、本番リリース直前に本番でのみ発生する不具合に見合わされました。
始めから Docker ベースでの開発であればそのような悩みも発生しなかっただろうと思います。
今後の新規開発の際に導入を検討する可能性がありそうですが、費用を中心に何かとコストが増えやすい為、趣味のサービス開発での導入は難しそうです。

開発やリリースで苦労したこと

上で記載した以外の点について触れたいと思います。

類似サービスの登場

開発開始からわずか数日ほど経ったタイミングで、VTuber のスケジュールを扱うサービスが登場しました。

一見デザインも綺麗で、にじさんじ以外も含め、様々な VTuber のスケジュールが登録されています。

ただ、スケジュールが不十分な部分があったり、にじさんじ好きにとってはノイズとなる情報も多いなど、欠点や方向性の違いによる差がある事も分かってきました。

当初の目的を常に意識しながら、なんとかリリースする事が出来ました。

Twitter アカウント凍結

現在 @nijisanji_net というアカウントを用いていますが、元々はドメイン取得時に別のアカウント名で作成し放置していたところ、何故か凍結の事態に…

このような事は初めてでしたが、凍結直後に気づくことが出来ず、凍結解除申請も虚しく現在も凍結されたままになっています。

惜しかったですが、思い切って別アカウントを作成し事なきを得ました。

スクレイピング

スクレイピング対象に想定外のパターンの文字列が混ざった場合、データに不具合が発生します。
中にはスクレイピング先情報の typo など、どうしようもないものもありますが、
大きなデータ崩れが発生しないように抑えるべく、多くの分岐処理が必要となりました。
スクレイピングは本サービスのコア機能になりますが、最も実装に時間のかかった部分でもありました。

Google Search Console

リリース直前に noindex,follow 指定で本番環境でのテストを行っていた影響で、この記事を書いている現在もエラーを吐く状態となっています。
当初は別に問題があるのではといろいろ試したのですが、不慣れのため、単純な時間の問題だろうと気づくまでにとても時間がかかりました。

Googlebot 上で Vue.js が機能しない

Search Console 上の問題もあり、時間が経つまでの検索インデックスは DOM に頼るしかない状態となっていましたが、
その問題に追い打ちをかけるように Googlebot 上で Vue.js が機能しない問題にぶち当たりました。

Googlebot で JavaScript を解釈できる事は知っていましたが、Vue.js など一部のスクリプトが正しく認識されない問題についての知識が無く、これには参りました。

結局 Vue.js で出力される内容をサーバーサイドレンダリング (SSR) させ、 Vue.js が読み込まれるまでの間の表示をサーバー側に任せる事でなんとか事なきを得ました。

開発期間・工数

9月9日に開発を開始し、11月25日に公開しました。
開発期間は約3ヶ月、累計作業工数は142時間でした。

工数について

当初はせいぜい数十時間で終わるだろうと見込んで開発を開始しましたが、実際はサービス開発を行いながら仕様を詰めており、当初の想定よりも機能が増えたことから、予定よりも工数が嵩んでしまいました。

また、作成していたプログラムの不具合の影響で、手動で作成していたライバーデータを全て別データで上書きしてしまったのですが、そのライバーデータの作成に10時間近くかかっており、再度同様の工数が発生しました。

さらに、リリース直前に発生した本番環境限定の不具合もあり対処に10時間ほど時間が取られてしまいました。

実際にかかった時間と比較し20時間〜30時間ほどは短く出来たのではと思います。次に活かしたいです。

余談ですが、改めて2つ歳下のせせりさんのすごさを実感しました。

「1人で6時間で作った」　Twitterで匿名質問「Peing」人気、月間2億PV超えへ - ITmedia NEWS

開発以外で取り組んだこと

他の趣味活動の制限

ポッドキャストやブログでのアウトプット、仲間との Discord など、日常的に様々な趣味活動を行っていましたが、業務、他のプライベートでの活動も含め忙しく、削れる活動は制限する事に。

もちろん、万人が意識する事でも無いと思いますが、忙しい社会人が開発を継続していく為には、多少他の活動を制限する覚悟が必要だと感じています。

息抜きは欠かさない

とは言いつつも、仕事も開発、プライベートも開発で休み無しという状況では、つらい日々が続きます。

趣味のアニメ視聴時間は一切削らず、本サービスで扱っている VTuber 動画の視聴時間もある程度確保した事は、
モチベーションの維持に大きく貢献しただろうと思います。

開発者コミュニティへの加入

運営者ギルドのメンバーとなりましたが、他のみなさんの発言は「自分も頑張らないと」という刺激になりました。

リリースしてからの気付きや変化

アクセス数が気になって落ち着かない

公開から数日たった現在は多少慣れましたが、公開1日目は気づいたら Analytics の画面を見ている状態で本当に落ち着きませんでした。

運用に時間が取られる

理論上は自動化出来ているため、運用に時間が取られることも少ないだろうと考えていましたが、実際は更新ツールの不具合を修正したり、データを一部手直ししたり、アクセス数を増やすための SEO や PR を行ったりと、100%の自動化は中々難しく今後の課題であると感じています。

WordPress + Vue.js を用いてどうだったか

WordPress

サービス開発においても使用感は悪くなかったです。

そもそもとして、開発フレームワークではない WordPress を開発に用いる事に対する心配をお持ちの方は多いと思われますが、上に記載した通り

データモデルの構造上、複数のデータ項目への検索実装が難しい点が弱点

問題はこの程度だと考えています。

大規模な開発になった際に、規約が少なくコードの品質が担当者間で不揃いになりやすかったり、
データモデルの都合上パフォーマンスの問題も出てきますが、
個人開発レベルにおいてはほとんど心配する事ではないだろうと思いますし、
現実的な対策は十分可能ですので今後業務の開発でも用いると思います。

Vue.js

リリース後に SEO 面の問題が発生した為、フロントエンド技術に頼った開発は難しそうだと実感させられました。
ただ、今回のようなサーバーサイド技術との併用であれば小回りも効くため、十分実用的ではと思います。

WordPress と Vue.js の併用

下記2点があり、併用には全く支障がありませんでした。

WordPress 標準で API が提供されている
WordPress コアに含まれている jQuery と Vue.js が併用可能

その他

Semantic-UI と Vue.js のかみ合わせがあまりよろしくなく、
Semantic-UI 内の JS ライブラリで作成したフォームの value が Vue.js 側で上手く取得できませんでした。
Semantic-UI に value を直接返す関数が提供されておりどうにかなりましたが、
サードパーティ製ではあるものの Semantic UI Vue と呼ばれる UI コンポーネントも存在している事から、今後はそちらを使っていく可能性があります。

これから取り組みたいこと

サービスの継続運用、機能拡張

一部不具合も残っているため、それの改善も含めた継続的なサービス運用を目指したいです。
また、ある程度機能を絞ってリリースしており、残りの機能もしっかり開発できればと考えています。

数字、結果

現状、Twitter のフォロワーは 50 に満たず、まだ SEO の効果も出ていないことからアクセス数はご察しのとおりです。
趣味のサービスのため、数字や結果が最優先ではありませんが、折角ですのでにじさんじファンの半数程度（数万人）に利用して頂けるサービスを目指せればと考えています。

別サービスの新規開発

上で記載の通り、継続運用の為の対策を打ったり、機能拡張も計画しており、新規着手までは中々骨が折れそうですが、平行開発も踏まえ新しいサービス開発にも取り組めればと考えています。

ありそうな質問

仕様書や設計書はきちんと書いたの？

ぶっちゃけるとほとんど書いていません。要件を前述のメモ (Apple) に数行書いた程度です。

上記の機能一覧
コード上の役割分担
- 投稿タイプ、API、情報フィルタリング、テンプレートなどデータ定義・表示制御は「nijisanji」と呼ばれるテーマが担う
- YouTube API へのアクセス、スクレイピングなどデータ更新は「nijisanji-cron」と呼ばれるプラグインが担う

代わりにコードへのコメントはしっかり入れています。
また、可能な限り WordPress コア標準の仕組みを用いています。
さらに作業中に発生した不要なコードやデータは逐次削除するなど、
仕様書が無くとも現状の確認で全体像が見えやすい工夫を行いました。

趣味の個人開発だから出来ることだと思います。

念の為補足ですが、余裕があれば情報は残すに越したことは無いと思います。

広告は入れないの？

数年前に月間数十万PVのサイトを運営していた事もありますが、 Adsense も大した額にはなっていませんでした。
本サービスでも同等のアクセス数が稼げれば広告の導入を検討しますが、利便性も下げますので、導入は慎重に判断したいと思います。

事業化はしないの？

そもそも趣味のサービスですし、権利問題も絡みますので考えてないですが、公式関係者の方々にも使って頂けるサービスにはしたいと考えています。

おわりに

自分のような素人の書いた記事が参考になるのだろうか、と思う節もあり、中々重い腰が上がらなかったのですが、

すごいですね～。個人開発はじめたい人とかだとどうやってるか知りたい人多いかもしれないので、もし気が向いて且つ12月もたまたま無茶苦茶暇だったらカレンダーも是非ｗhttps://t.co/iGA3PpFL6U
— だら@技術系投稿サービス運営中 (@dala00) November 26, 2018

Crieit のだらさんに直接お誘い頂き執筆するまでに至りました。
改めてお誘い頂きありがとうございました。

何かしらの Advent Calendar への参加は初となりますが、夢でもあったので参加出来たことはとても光栄でした。

また、これからウェブサービス開発を考えている方や、ウェブサービス開発中の方の一助になれば幸いです。

ご質問、ご指摘、アドバイス大歓迎です。コメントや @sola_io までリプライ、お気軽にお寄せ下さい。

ここまで読んで頂いたすべてのみなさま、本当にありがとうございました。

個人開発サービスに用いられている技術 Advent Calendar 2018、明日は Hiroz さんの「Koretteのオモテとウラ」になります。
そもそも「Korette」って何？というところも含め、とても気になりますね。