無職の私は、生活のために100円でも出費を切り詰めなければなりません。WordPressでサイトを再構築した際も、AWSのLightSailは「月額 3.50 USD から」の安さが売りなので、迷わず月3.5ドルのコースを選びました。

　しばらく様子を見ていましたが、1日のアクセス数が30人前後なのでサイトへのアクセス負荷は問題なし。その後、写真や動画を掲載するために別途CloudFrontでCDNを構築して大きなファイルを逃がしたため、ギリギリ乗り切れるだろうと高をくくっていました。

　しかし、その考えは甘かったのです……。

プラグインの処理で高負荷がかかりサイトが落ちる

　しかし、サイトを整備してプラグインが増えてきたことから、プラグインの設定変更を伴うメンテナンス作業を行うたびに管理画面がフリーズ状態になり「サイトが落ちている」という警告メールがWordPressから届くようになってしまいました。

プラグインがブラックボックスなので、設定変更での問題解決は難しい

　一般的なWebサーバーやデータベースサーバーなどが高負荷で落ちる場合は、使用メモリなどの設定を変えたりデータを整理することで負荷軽減が可能なこともあります。しかしプラグインは色々なベンダーから提供されている上に、ブラックボックスで処理内容がユーザーにはよく分かりません。個別の設定変更では解決が難しいので、泣く泣くLightSailのプランを月3.5ドルから月5ドルにアップグレードすることにしました。

WordPressでプラグインを使うなら、メモリ1GBは必要

　LightSailの3.5ドルプランはメモリが512MBと「5年前のスマホかよ」という少なさです。LightSailのWordPressインスタンスはbitnamiスタックというシステム構成でOSはDebian Linux。GUIが無くCUI操作なので512MBでも動作はします。しかしギリギリなので、重い処理をするとメモリ不足で処理が止まってしまいます。CPUは遅くても待てば済むことが多いのですが、メモリ不足は致命的です。

　今時のVPSではGCPやOCIなど大手がメモリ1GBのVMを無料で提供しています。プラグイン作者もメモリ消費を考慮してはいるはずですが、既に「WordPressを立てるならメモリ1GBがミニマム」と判断されていると思われます。ソシャゲの肥大化と同じですね

LightSailがメモリ512MBでWordPressインスタンスを立てられてしまう理由

　天下のAWS、WordPressでちょっと欲張ると3.5ドルプランでは管理しきれなくなることを知らないはずがありません。しかし実際には3.5ドルプランでWordPressインスタンスを立てられてしまい、私のように管理画面が落ちることになってしまいます。

　これは、LightSailが『OS／アプリケーションスタック』と『インスタンスプラン』を一切紐づけておらず、全ての組み合わせでインスタンスを立てられるのが理由です。端的に言えば、プラン選択もアプリ選択も『自助』『自己責任』という考え方でサービスが構築されている、ということです。

　WordPressはまだ512MBでも動きはしますが、ショッピングカートの『Magento』ではアップデートに2GBのメモリが必要で、512MBでは初期設定すらまともに出来ません(月10ドルのプランなら動くでしょう、たぶん)。このように、自分が使いたいアプリと用途でちゃんと動くミニマムのプランを見極めてから始めるのが基本です。

　とは言え、サービスが落ちると致命的な企業サイトでなければ「とりあえず立ててみて、ダメそうならスナップショットを取ってアップグレードする」という「痛い目に遭って覚える」やり方もアリでしょう(負け惜しみ)。ボタンひとつでサーバーを落として引っ越せるため失敗のダメージが少ないのはクラウドの長所です。

泣く泣く月5ドルのプランに移行する

　というわけで、無職で経済的に厳しい折ではありますが、月3.5ドルのプランから月5ドルのプランに移行することにしました。

手順①　スナップショットの作成

　LightSailは、システムの再構築なしにプラン変更が可能です。具体的には、まず既存インスタンスのスナップショットを取ります。

手順②　スナップショットから新規インスタンスを作成

　スナップショットが出来たら、クリックして『新規インスタンスの作成』を選びます。

　古いスナップショットを使うと先祖返りしてしまうので、アップグレードしたいインスタンスの最新のスナップショットであることを再確認します。

手順③　月5ドルのインスタンスプランを選んで作成

　『新規インスタンスプランの選択』で、左から2番目の『$5 USD』のプランを選びます。メモリが1GBと倍増するほか、ストレージ40GB、転送量2TBと全体的にスペックが倍増します。

　一時的に同じ中身のインスタンスが2つ併存する状況となります。固定IPアドレスが古いインスタンスに紐づけられているので、新しいインスタンスはまだ公開されていない状況です。

手順④　固定IPアドレスの付け替え

　『静的パブリックIPアドレス』の管理画面で古いインスタンスから固定IPアドレスの割り当てを『デタッチ』で解除します。この操作に伴って一時的にサイトが落ちるので、アクセスが少ない時間帯に実施するのが無難です。

　続いて、固定IPアドレスを新しいインスタンスに紐づけます。

　アタッチが終わったら、Webブラウザでサイトが無事表示されていることを確認します。キャッシュの影響でサイトが落ちていても表示されてしまうことがあるので、動作確認は他のブラウザやスマホを使うかキャッシュを削除してから行うのが安全です。

手順⑤　古いインスタンスの削除

　インスタンスがふたつ併存した状態では二重に課金されてしまうので、古いインスタンスを削除します。インスタンスを削除すると自動スナップショットも同時に削除されるので気を付けましょう。

手順⑥　手動スナップショット作成と自動スナップショットの設定

　インスタンスを作り直すとスナップショットの設定も消えてしまいますので、作り直します。念のため、手動スナップショットも作成しておいた方が良いでしょう。

メモリが1GBになったが、それでもギリギリ感が……

　新しいインスタンスのメモリ使用状況を確認すると、メモリ1GBでも128MBしかメモリが余っていません。

　スワップがあるとは言え、データがSSDに落ちると処理速度が大幅に下がってしまいます。スワップ処理がフリーズにつながることもあるので、やはり最低限メモリ1GBはあった方が良いでしょう。もちろん、その分お高くつきますが……

The post LightsailのWordPressは3.5ドルプランだと落ちまくる件 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　既に何度か指摘していますが、Wordpressはセキュリティに様々な問題を抱えています。特に根深い問題が「動的にページを生成する」ことです。具体的には

• WordPressはPHPで動的にページを生成する（ユーザーがアクセスするたびにプログラムを動かしている）
• 「動的にページを生成する」ということは、プログラムにセキュリティの問題があると常に攻撃されるリスクがあることを意味する
• WordPressは本体が静的にページを出力する機能を持たず、コンテンツ管理用サーバー（CMS）とコンテンツ配信サーバーを分ける機能も無い
• WordPressのロードマップを見る限り、動的なページ生成に伴うセキュリティ上の問題を解決する意思が開発者に無さげ

という感じで、特に改善の見込みが無いのがかなり絶望的な状況です。フロントエンジニア界隈でWordpressが『技術的負債』とまで言われる理由です。

「何でもプラグインで解決する」のがWordpress流

　Wordpressは、オプション的な機能はすべてサードパーティーのプラグインに任せる文化です。このことがWordpressの多機能化に寄与し、トップシェアのCMSに成長する原動力となりました。

　個人的には、セキュリティはシステムの根幹部分であるため、プラグインに任せるのはおかしいと思っています。しかしWordpressのプラグインが提供する多彩な機能を自力で実装するのは無理なので、Wordpressの静的サイト化も当面はプラグインで実現するのが現実的です。

　本家が自力で対応しようとしていないので「ほかに現実的な方法が無い」ということです。

WordPressのページを静的サイトとして出力するプラグイン『Simply Static』

現在、Wordpressで無償利用できる静的サイトジェネレータープラグインは『Simply Static』です。

　このプラグインにS3やGoogleドライブなどに静的サイトを出力する機能はありませんが、zipファイルでのダウンロードが可能です。

　私は当サイトのコンテンツをGitHub Pagesに試験的に静的出力しています（手動）。

https://masaru-kmt.github.io/

リンク切れの嵐……犯人は『URLエンコード』

　……と、ここまではキレイな話ですが、現実はそう甘くありません。zipファイルをGitのワーキングディレクトリに展開して

$ git add .
$ git commit -m ‘simply-static-1-1626516830.zip’
$ git push

するとリンク切れの嵐が……。原因を調べたところ『日本語のURL』にあることが判明しました。具体的には

• WordPressはデフォルトで記事タイトルをURLのフォルダ名として使用する
• 日本語で記事タイトルを書くと、URLには当然日本語のフォルダ名が含まれる
• WordPressはURLの日本語をUTF-8で出力する
• ところが、Simply StaticプラグインはURLを『URLエンコード』で変換して出力する
• 結果、ページ内のリンクが「URLデコード状態」でリンク先のフォルダ名が「URLエンコード」状態なのでリンクが切れる

というカラクリになります。

　以前の記事「WordPressサイトを静的に出力してGitHub Pagesを作る」ではこの問題に敢えて触れていませんでした。というのも、Wordpress側の設定を変えれば

• 記事タイトルをURLに含めない
• 投稿時に、都度URLを英数字で設定する（手動）

のいずれかの対応が可能だからです。

そもそも、URLに日本語を使うのは適切なのか？

　URLに日本語を平気でぶち込んで来るCMSは、私が知る限りWordpressくらいです。ウェブに詳しい方なら、URLに日本語が含まれているだけで「濃厚なWordpress臭」を感じて敬遠するかも知れません。また文字コード的にも、UTF-8(Unicode)が支配的になる以前からシフトJISやEUCなどでウェブページを作られていた方も、文字化けで苦しんだ経験から「日本語のURL？ダメゼッタイ！」と思われていても無理はありません。

　私はこれらの問題を理解した上で、敢えて日本語のURLをそのまま使うことにしました。URLがUTF-8を含むこと自体は「WHATWGでは、URLはUTF-8とされています」ので不正ではありませんし、事実Google ChromeなどのWebブラウザでは正しく表示されています。

　そして何よりも

URLはまだWebブラウザで見える状況なのだから、日本語の方が日本人にはわかりやすい

からです。スマホアプリではURLが（たとえ存在していても）既に見えなくなっていますが、ウェブサイトとして運営している限りは日本語URLの方がユーザーに親切だと判断しました。

わがままを言うなら自分で変換するしかないじゃない

　というわけで、前回は手動でURLデコードを行っていましたが、さすがに実運用としてはあり得ない手間なので、ものすごく面倒臭いのをこらえて思い切ってフォルダ名を一括変換するbashスクリプトを作成しました。

https://github.com/Masaru-KMT/WordpressURLdecoder

　……言うてコードは数行ですがな(；´Д｀)

#!/bin/bash
# WordPressURLdecoder
# WordPressプラグイン『Simply Static』が出力する
# URLエンコードされたフォルダ名を一括デコードするbashスクリプト
# Version: 2021-07-17

# WordPressのデータはプラグイン『Simply Static』でダウンロードします
# https://ja.wordpress.org/plugins/simply-static/

# 【注意】別途nkfのインストールが必要です
# sudo apt install nkf
# (Ubuntuの場合)


#  [変数設定]スクリプトを格納・実行するディレクトリ
scrdir="/home/masaru/"

# [変数設定]『Simply Static』が出力するzipファイルの解凍先ディレクトリ
workdir="/home/masaru/temp/"


# ディレクトリ一覧の取得(dirlist.txtに格納)
dirlist="${scrdir}dirlist.txt"
find $workdir -type d > $dirlist

# ディレクトリ一覧を一行ずつ読み込みnkfでデコードしたファイル名に変更
cat ${dirlist}  | while read line
do
 newname=$(echo $line  |  nkf -w --url-input)
 echo "${line} -> ${newname}"
 mv $line $newname
done

　ふだんPythonばっか書いたりJavaScriptに泣かされたりしていてシェルコマンドは1行しか書かないので長めのシェルスクリプトは書きたくないのですが……。機械学習でもないのにPythonをわざわざ書くのもおっくうだったので思い切って書いてみたら意外と簡単でした。

　ふだんはこの手のやっつけスクリプトは恥ずかしいので表に出さないのですが、Wordpress界隈でニーズが多そうなのと手頃なフリーソフトが見当たらなかったので無保証で公開することにしました。何よりパソコンが壊れたときにスクリプトをサルベージ出来ないと困るのは自分なので……

The post WordPress静的出力プラグイン『Simply Static』のリンク切れを修正するbashスクリプト first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　枯れた技術の入門記事で「今さら聞けない」を枕詞にしたものをよく見ますが、「本当に聞けない」のがセキュリティ対策です。なにせ「知らない」「やってない」ことがバレた時点で「セキュリティ甘々なサイト」と他所様に認識されてしまうのですから……。

　この数か月で少しAWSとWordPressに詳しくなったので、復習がてら導入のアドバイス・コンサルティングを始めました。お客様のお話をお伺いしていると情報セキュリティへのご関心が高いようです。WordPressは有名CMSなので、セキュリティホールを突く攻撃から面倒くさいコメントスパム、フォームスパムまで日々痛い目に遭っている方が多いようです。

　私自身は情報処理安全確保支援士(SC)の資格など持っていませんし、そもそもエンジニアですらありません(アドミン君でないとは言い切れませんが……)。従ってセキュリティを語る資格は無いのですが、現実問題としてウェブサイトを立てた瞬間からセキュリティのリスクと責任を負ってしまうのでどこぞの予約サイトのようにセキュリティを全く無視するわけにはいきません。

今さら「入れない」では済まない二段階認証(多要素認証＝MFA)

　昔は二段階認証と言えばオンラインバンキングなど金融系が中心でした。しかし、ここ数年でセキュリティ事故による情報流出が多発し、IDパスワードが攻撃者に奪われてしまいました。

　その結果、各種のサービスに不正取得したIDパスワードを使って侵入し不正送金などを行い、ユーザーが深刻な被害を受ける事件まで起こってしまいました。その結果、みんな大好きメルカリやYahoo!/PayPayを筆頭に、一般的なサービスでもすごい勢いでワンタイムパスワードによる二段階認証が普及しています。

　二段階認証で幅広く使われている方式は、下記となります：

1. トークン(認証専用ハードウェア)による認証
2. 携帯電話・スマホのSMSによる認証
3. スマホの認証アプリによる認証(これが当記事のテーマです)

　これらの方式をセキュリティ用語では『MFAデバイス』、特にスマホアプリによる方式を『仮想MFAデバイス』と呼びます。MFAはMulti-Factor Authenticationの略で、直訳すると『多要素認証』となります。

　個人サイトではトークンやSMSによる認証は難しいので、3.の『スマホの認証アプリによる認証』に頼ることとなります。しかし、予備知識がないと「認証アプリってなに？」「どの認証アプリを使えばいいの？」と頭がはてなマークで埋め尽くされてしまいます。

ワンタイムパスワードには共通規格がある(RFC 6238 – TOTP)

　結論から申し上げると、二段階認証で使われるワンタイムパスワードの方式には共通規格があります。『RFC 6238 – TOTP: Time-Based One-Time Password Algorithm』というもので、ざっくり言うとSSLなどと同じレベルです。

　従って、AWSやWordPressに二段階認証を入れようと思ったら、まず最初にやることは『TOTP対応の認証アプリ』のインストールです。「TOTP対応なら、どれでも良い」ということです。Googleで検索してみると、下記のような認証アプリがヒットします：

• Google 認証システム – Google Play のアプリ
• Microsoft Authenticator – App Storeプレビュー
• IIJ SmartKey｜スライド認証・ワンタイムパスワード管理

注意点①　アプリ認証はSMS認証に依存している

　実際に認証アプリを使う前に、絶対に確認しておくべきことがあります。スマホをなくしたり壊したりしてしまったら、アプリ認証も出来なくなってしまいます。従って、二段階認証を入れる前に、必ず認証アプリの機種変更方法を把握しておかなければいけません。私が使っているIIJ SmartKeyで機種変更を行うための本人確認は、SMS認証を用いています：

　これが意味することは、「電話番号を変えてしまったら認証アプリの機種変更が出来なくなり、ワンタイムパスワードも最終的には使えなくなる」ということです。アプリによって本人確認の方法は異なる可能性がありますが、頭の片隅に置いておいて下さい。

注意点②　AWSの二段階認証はルートユーザーとIAMユーザーの両方で必要

　セキュリティ重視の方は、AWSでもユーザー登録時に付与されるルートユーザーではなく別途IAMユーザーを作成して運用していることも多いかと思います。しかし当然ながら、仮にふだんは使っていないとしても、ルートユーザーも二段階認証を入れないとIDパスワードを抜かれたら終わりです。

注意点③　WordPress自体にも二段階認証を入れないと意味がない

　WordPressは一般的にブログなどを公開するウェブサイトと同じサーバーに管理画面があり、ウェブ上で記事を編集します。WordPressは5.xの時点では本体に二段階認証の機能がないため、サードパーティーの認証プラグインを入れる必要があります。WordPress 6.xでは絶対に改善してもらわないと困る状況ですが、いま出来ることとしてWordfence Security – Firewall & Malware Scanを入れています。

　正直、CMS全体の動作に大きな影響を与えるセキュリティ関連でサードパーティーのプラグインを入れるのは怖いので、「インスタンスのバックアップを取った上で恐る恐る入れている」というのが本音です。

　私自身は無職でノマド()なのでWordPressに接続するIPアドレスを固定するのが難しい状況ですが、企業ユーザーの方などでIPアドレスの固定が可能な方は、IPアドレスの指定による管理画面へのアクセス制限が可能かどうか、併せてご検討されるのがよろしいかと思います。

まだの方は今すぐ始めて下さい

　正直、情報セキュリティ関連の投稿は、自分の手口を明かしてしまう上に本職のエンジニア様などによる恐ろしいマサカリにも晒されているので「書きたくない」のが本音です。

　しかし、非エンジニアの方が多く利用しているWordPressがセキュリティ面で脆弱な状況に置かれている現状は非常にまずいと感じたため、敢えて二段階認証の投稿をするという決断をしました。

　このような状況ですので、セキュリティが本職の皆さまが当記事に問題を発見した場合は、何卒、優しくご指摘ください。ご指摘そのものは、当サイトのセキュリティ改善につながるので歓迎です。

The post [AWS+WordPress]今さら聞けない二段階認証(MFAデバイス)でのセキュリティ強化 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　can.ne.jpではサイトを丸ごとCDN(配信サービス)で配信しないようにしています。CloudFrontなどのCDNはそれなりにお高い上に、フォームを置いたインタラクティブなサイトでトラブルが生じる可能性を否定出来ないからです。

動画や画像だけCDNに置く

　can.ne.jpが使っているWordPressというCMSは基本的にはローカルでファイルを管理します。ただし、『HTMLブロック』機能でリンクを手書きすれば外部の画像を表示出来ます。

　また、WordPressプラグインの動画プレイヤー『FV Flowplayer Video Player』や音声プレイヤー『MP3 Music Player by Sonaar』はURL指定で外部ファイルを再生できます。

　これらを使うことで、ファイルサイズが大きい動画や画像だけをCDNに置くことが出来ます。

2サーバー＋CloudFront構成で大きなファイルだけCDN配信する

　これらを念頭に置いて構築したcan.ne.jpの構成図は下記となります。

　まず、WordPress MultiSiteを設置したブログサーバー(can.ne.jp)とは別に配信サーバー(cloudfront.can.ne.jp)をLightSailで作ります。ただのファイル置き場なのでCMSなどは動かさず、Webサーバーも高速と言われるNginxを選びました。このようなサーバーを『オリジンサーバー』と呼びます。オリジンサーバーは外部からのアクセスを想定しないため、SSL証明書は不要です。

　次に、CloudFrontのインスタンス(cf.can.ne.jp)を作成してSSL証明書を取得します。can.ne.jpのドメインはAWSのDNSサーバー『Route 53』に置いているので、cf.can.ne.jpへのアクセスをCloudFrontに流し込む設定を簡単に行えます。

　なお、CloudFrontのようにサイト訪問者に最寄りから高速にデータを配信するサーバーを『エッジサーバー』と呼びます。各種設定の際は、オリジンサーバーとエッジサーバーが別のサーバー名(FQDN)になる点に気を付けて下さい。

Amazonの回し者のような図をついに描いてしまいましたが

　AWSがAmazonの利益率が高い事業であることは知っているので、AWSが決して『最安』ではないとの認識です(Amazonの商品が必ずしも最安ではないように)。

　CDNの導入にあたっては、無料枠があるCloudflareも検討しました。しかしDNSをRoute 53からCloudflareに移さなければならないことが分かったため断念しました。とにかく安くサイトを運営したいなら、DNSを設置する段階からCloudflareを選んでおくのが良いと思います。

　また、CDNを選ぶ際はエッジサーバーが日本国内でどの程度配備されているかが重要なポイントとなります。個人サイトなら落ちさえしなければ遅くても構いません(笑)。しかしビジネス目的なら国内に多数のエッジロケーションがあるかどうかが配信速度を左右しますので、無難にCloudFrontや、お高いことで有名なAxxxxxなど有名なサービスを選ぶことになると思います。

CDNは「逃げられるようにしておく」のが大事

　ロートルWeb担当者なら身に覚えがあるかも知れませんが、昔はCDNと言えばAxxxxx社だったので、CDNを入れるイコール「青天井の予算を組む」という恐ろしいタスクでした。

　特に企業サイトでは新製品発表など訪問者がスパイクするタイミングで波の大きさがどれくらいになるか、なかなか読めないものです。発表日にはCDNのコンソール画面に貼りついて、アクセスが殺到して予算超過にならないか見張らなければなりません。

　「いよいよ予算的にヤバイ」となれば、泣きながら手動でリンクをオリジンサーバーに付け替えるわけです。これでサーバーが重くなったり最悪落ちるかも知れませんが、CDNの青天井課金から逃げることだけは出来ます。

　「そもそもアクセスが殺到しても耐えられるくらい予算を確保(できる会社に就職)しておけよ」という正論が聞こえてきますが、悲しきかな日本の社畜はそうも行かないのが常です。保身の手段として覚えておくと良い、かも知れません。

The post CloudFront+LightSailでスケーラビリティが(それなりに)あるサイトを安く作る first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　こんにちは、まさるです。

　このブログはcan.ne.jpというドメインに設置しています。
　whoisというサービスでドメインの登録情報を確認すると、このドメインを登録したのは1998年3月26日、と分かりました。
実に、23年1ヶ月前くらいです。なんと長い年月が過ぎてしまったのでしょうか……。

　この化石のようなドメイン、実は維持にけっこうお金がかかっています。
can.ne.jpは属性型JPドメインというもので、1年分の維持費が7700円もかかります。
　これとは別に、ドメイン預かりというサービスが年間3960円かかります。
合計で毎年11660円も払ってます。お財布に厳しいですね……。

　それでもドメインを維持しているのは、can.ne.jpという3文字のドメインが珍しいからです。しかし、今となっては、単なる自己満足でしかないような気もします。

　初めてドメインを取った1998年ごろは検索エンジンがまだ発達しておらず、ドメイン名を覚えてもらったりブックマークしてもらうことに価値がありました。しかし今は検索が全盛の時代です。わざわざURLを入力してサイトを訪問してくれる人はほとんどいません。

　今では昔ほど独自ドメインを取る価値が無いのは間違いありません。では、どのような時に独自ドメインを使う価値があるのでしょうか。

　独自ドメインを選ぶ最大の理由は、「コンテンツを置く先のサービスに振り回されたくない」ということです。外部サービスは終了してしまうことがありますし、ツイッターやフェイスブックのようにアカウントが特に理由もなく凍結されてしまうことがあります。そうした時に独自ドメインという『本拠地』があれば、心配した人がGoogleで検索して自分のサイトを確認してもらえる可能性があります。

　もうひとつの理由が、自由なソフトでコンテンツを公開出来ることです。このサイトもワードプレスというCMSで運営しているので、自分が好きなようにサイトをカスタマイズできます。また、サブドメインを作ることで自分のサイトであることを証明しながら複数のサイトを運営することも出来ます

　独自ドメインは、集客力では、どうしても大手サービスにはかないません。技術ブログであればキータなどで記事を書いた方が、たくさんの人の目にふれると思います。大手サービスのアドバンテージを理解した上で、よそに振り回されずにサイトを運営したい方は独自ドメインを検討する余地があると思います。

　このブログで紹介しているギットハブ・ページーズは無料で独自ドメインのサイトを作れます。もちろんドメイン自体の取得・維持にはお金がかかりますが、興味がある人はまずギットハブで試してみるのも悪くないと思います。

The post 2020年代に独自ドメインは必要なのか？ first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　前にいた会社でキャラクター商品宣伝用のスペシャルサイトを作ることになりました。独自CMSを使っておりセキュリティ上の理由で制作会社さんからのCMS接続が難しかったため、系列会社のホスティングでサブドメインを作ることにしました。

　運営もコンテンツ修正が出来るようにしたかった(ベタHTMLで作ると都度制作会社さんに修正料金を払う必要がある)のでWordPressの導入を検討。しかし情シス担当者に「WordPressはセキュリティが弱いから止めてくれ」と言われ、制作会社さんにも「ベタHTMLにしてくれ(ないと面倒だし儲からない)」と言われ泣く泣くベタHTMLにしました。

WordPressのセキュリティが弱いのは動的CMSだから

　　WordPressのセキュリティが多方面から懸念されてしまうのは、PHPという動的なサイト生成基盤を使っていることと単に「有名だから狙われやすい」のが理由です。「狙われたくないから情シスが勧めるマイナーなCMSを選ぶ」のは消極的であって根本的な問題解決になっていません。

　WordPressで作成した動的サイトを静的サイト(HTML+CSS+JavaScript)に変換して公開すれば、サイトが動的に生成されることによるセキュリティの問題を回避出来ます。

無料のGitHub Pagesで試してみる

　当サイトを無料のGitHub Pagesに静的サイトとしてミラーしてみましたので、やり方をメモとして残します。

https://masaru-kmt.github.io/

　もちろん、WordPressで静的サイトを作成したからといって大元のWordPressが安全になったわけではありません。セキュリティ上の観点からは、先にご紹介したLocalなど非公開のWordPressでサイトを作成し、GitHub Pagesなど公開環境に静的サイトをコミットするのが適切です。

　まず、GitHubでサイト名のレポジトリを作成します。

　次に、GitHubをまだ本格的に使っていない人はGitHub Desktopをダウンロードします(Windows/Mac)。私はUbuntuにはGitを入れていますが、Webサイトでは一度にたくさんのファイルをコミットするので今回はWindowsで試してみました。

WordPressから静的サイトを生成する『Simply Static』

　WordPressから静的サイトを生成するプラグインは複数ありますが、検索上位のSEOサイト()で紹介されているプラグインは数年間更新が無かったり有料化されてしまったダメダメなものばかりです。結局WordPress内で検索して見つけた『Simply Static』を使うことにしました。

　Simple Staticの設定はパブリッシュ先のドメイン名くらいで簡単です。HTML化したサイトデータをzipファイルとしてダウンロードし、解凍してGitHub Desktopのレポジトリにドラッグ&ドロップし、GitHubにコミットします。

しばらく待たないと404 Not Foundのまま……

　コミットしましたがページが表示されません。「なぜ？」と焦って検索したところ、GibHubにコミットしたHTMLがWebページとして反映されるまでに時間がかかるのが理由、のようです。

　即時に更新を反映したいサイトには、GitHub Pagesは向かないようです。とは言え、無償でサイトを公開出来る(独自ドメインもOK)のは魅力的です。「少なくともGit (Hub)の存在くらいは知っている」という証明にはなるので検討の余地はあると思います。

　ちなみに、コンタクトフォームやコメントなどWordPressの動的な機能はミラー先の静的サイトでは無効になります。静的サイトにする際は「コンタクトフォームだけ他サイトのサービスを利用する」といった対策が必要となります。

The post WordPressサイトを静的に出力してGitHub Pagesを作る first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　ということでコピペする方法を探してみたところ、nbconvertを使う方法が良さそうです。

$ jupyter nbconvert --to html --template basic gstore-cust-revenue-prediction.ipynb

　生成されたHTMLから該当セルをWebブラウザーのインスペクター(F12キーを押下)でコピーし、WordPressのカスタムHTMLブロックに貼り込みます。

<div class="input">
<div class="prompt input_prompt">In [7]:</div>
<div class="inner_cell">
    <div class="input_area">
<div class=" highlight hl-ipython3"><pre><span></span><span class="kn">import</span> <span class="nn">numpy</span> <span class="k">as</span> <span class="nn">np</span><span class="o">,</span> <span class="nn">pandas</span> <span class="k">as</span> <span class="nn">pd</span><span class="o">,</span> <span class="nn">os</span><span class="o">,</span> <span class="nn">matplotlib.pyplot</span> <span class="k">as</span> <span class="nn">plt</span><span class="o">,</span> <span class="nn">seaborn</span> <span class="k">as</span> <span class="nn">sns</span>
<span class="kn">import</span> <span class="nn">json</span><span class="o">,</span> <span class="nn">re</span><span class="o">,</span> <span class="nn">gc</span>                              <span class="c1">#garbage collector</span>
<span class="kn">from</span> <span class="nn">sklearn.preprocessing</span> <span class="kn">import</span> <span class="n">LabelEncoder</span>
<span class="kn">from</span> <span class="nn">ast</span> <span class="kn">import</span> <span class="n">literal_eval</span>
<span class="kn">from</span> <span class="nn">sklearn.model_selection</span> <span class="kn">import</span> <span class="n">KFold</span>
<span class="kn">from</span> <span class="nn">sklearn.metrics</span> <span class="kn">import</span> <span class="n">mean_squared_error</span>
<span class="kn">from</span> <span class="nn">sklearn.model_selection</span> <span class="kn">import</span> <span class="n">GridSearchCV</span> <span class="c1">#Experimented hyperparams a bit with this</span>

<span class="kn">from</span> <span class="nn">catboost</span> <span class="kn">import</span> <span class="n">CatBoostRegressor</span>
<span class="kn">from</span> <span class="nn">xgboost</span> <span class="kn">import</span> <span class="n">XGBRegressor</span>
<span class="kn">import</span> <span class="nn">lightgbm</span> <span class="k">as</span> <span class="nn">lgb</span>

<span class="k">for</span> <span class="n">dirname</span><span class="p">,</span> <span class="n">_</span><span class="p">,</span> <span class="n">filenames</span> <span class="ow">in</span> <span class="n">os</span><span class="o">.</span><span class="n">walk</span><span class="p">(</span><span class="s1">'/home/masaru/data/kaggle_google_analytics'</span><span class="p">):</span>
    <span class="k">for</span> <span class="n">filename</span> <span class="ow">in</span> <span class="n">filenames</span><span class="p">:</span>
        <span class="nb">print</span><span class="p">(</span><span class="n">os</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="n">dirname</span><span class="p">,</span> <span class="n">filename</span><span class="p">))</span>
        <span class="k">pass</span>
<span class="n">gc</span><span class="o">.</span><span class="n">enable</span><span class="p">()</span>
<span class="n">sns</span><span class="o">.</span><span class="n">set</span><span class="p">(</span><span class="n">style</span><span class="o">=</span><span class="s1">'whitegrid'</span><span class="p">,</span><span class="n">palette</span><span class="o">=</span><span class="s1">'deep'</span><span class="p">,</span><span class="n">font_scale</span><span class="o">=</span><span class="mf">1.1</span><span class="p">,</span><span class="n">rc</span><span class="o">=</span><span class="p">{</span><span class="s1">'figure.figsize'</span><span class="p">:[</span><span class="mi">8</span><span class="p">,</span><span class="mi">6</span><span class="p">]})</span>
<span class="n">pd</span><span class="o">.</span><span class="n">set_option</span><span class="p">(</span><span class="s1">'float_format'</span><span class="p">,</span> <span class="s1">'</span><span class="si">{:f}</span><span class="s1">'</span><span class="o">.</span><span class="n">format</span><span class="p">)</span>     <span class="c1">#to display full numbers in dataframe and not just exponentiated form </span>
</pre></div>

    </div>
</div>
</div>

<div class="output_wrapper">
<div class="output">


<div class="output_area">

    <div class="prompt"></div>


<div class="output_subarea output_stream output_stdout output_text">
<pre>/home/masaru/data/kaggle_google_analytics/test_v2.csv
/home/masaru/data/kaggle_google_analytics/submission.csv
/home/masaru/data/kaggle_google_analytics/deep-learning-keras-ga-revenue-prediction.ipynb
/home/masaru/data/kaggle_google_analytics/gstore-cust-revenue-prediction.ipynb
/home/masaru/data/kaggle_google_analytics/ga-customer-revenue-prediction.zip
/home/masaru/data/kaggle_google_analytics/test.csv
/home/masaru/data/kaggle_google_analytics/sample_submission_v2.csv
/home/masaru/data/kaggle_google_analytics/GoogleAnalytics_Customer_Revenue_EDA_and_Prediction.ipynb
/home/masaru/data/kaggle_google_analytics/sample_submission.csv
/home/masaru/data/kaggle_google_analytics/train_v2.csv
/home/masaru/data/kaggle_google_analytics/train.csv
/home/masaru/data/kaggle_google_analytics/.ipynb_checkpoints/gstore-cust-revenue-prediction-checkpoint.ipynb
/home/masaru/data/kaggle_google_analytics/.ipynb_checkpoints/GoogleAnalytics_Customer_Revenue_EDA_and_Prediction-checkpoint.ipynb
</pre>
</div>
</div>

</div>
</div>

WordPressのテーマにNotebook用のCSSを追加する

　続いて、WordPressの『外観⇒カスタマイズ⇒追加CSS』でJupyter Notebookセル用のCSSを追加します(リンク先ページのソースを参照のこと)。

import numpy as np, pandas as pd, os, matplotlib.pyplot as plt, seaborn as sns
import json, re, gc                              #garbage collector
from sklearn.preprocessing import LabelEncoder
from ast import literal_eval
from sklearn.model_selection import KFold
from sklearn.metrics import mean_squared_error
from sklearn.model_selection import GridSearchCV #Experimented hyperparams a bit with this

from catboost import CatBoostRegressor
from xgboost import XGBRegressor
import lightgbm as lgb

for dirname, _, filenames in os.walk('/home/masaru/data/kaggle_google_analytics'):
    for filename in filenames:
        print(os.path.join(dirname, filename))
        pass
gc.enable()
sns.set(style='whitegrid',palette='deep',font_scale=1.1,rc={'figure.figsize':[8,6]})
pd.set_option('float_format', '{:f}'.format)     #to display full numbers in dataframe and not just exponentiated form 

/home/masaru/data/kaggle_google_analytics/test_v2.csv
/home/masaru/data/kaggle_google_analytics/submission.csv
/home/masaru/data/kaggle_google_analytics/deep-learning-keras-ga-revenue-prediction.ipynb
/home/masaru/data/kaggle_google_analytics/gstore-cust-revenue-prediction.ipynb
/home/masaru/data/kaggle_google_analytics/ga-customer-revenue-prediction.zip
/home/masaru/data/kaggle_google_analytics/test.csv
/home/masaru/data/kaggle_google_analytics/sample_submission_v2.csv
/home/masaru/data/kaggle_google_analytics/GoogleAnalytics_Customer_Revenue_EDA_and_Prediction.ipynb
/home/masaru/data/kaggle_google_analytics/sample_submission.csv
/home/masaru/data/kaggle_google_analytics/train_v2.csv
/home/masaru/data/kaggle_google_analytics/train.csv
/home/masaru/data/kaggle_google_analytics/.ipynb_checkpoints/gstore-cust-revenue-prediction-checkpoint.ipynb
/home/masaru/data/kaggle_google_analytics/.ipynb_checkpoints/GoogleAnalytics_Customer_Revenue_EDA_and_Prediction-checkpoint.ipynb

　無事、表示出来ました。

The post Jupyter NotebookのセルをWordPressに貼り付ける first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　私が初めて独自ドメインでWebサイトを立てたのは20年も前になります。しかし2010年代以前に作ったサイトで今も残っているものはひとつもありません。このcan.ne.jpドメインにもかつて別のブログがありましたが、もはやデータ復旧もままなりません。

　不慮の事故、モチベーション喪失、技術の変化……。さまざまな理由でサイトは「死ぬ」のです。AdobeのFlash廃止でも話題になりましたが、多くのサイトが更改しなければ表示も難しくなり、いずれWebからひっそりと消えてなくなります。

　WordPressというオープンソースCMSのデファクトスタンダードが確立したことで、少なくともサイトデータのサルベージは行い続けられる可能性が高まりました。個人サイトは次々と書き捨てられていく商業サイトと異なり「生きた証」でもあるので、なるべく『生涯現役』を続けたいところです。

個人サイトのバックアップはローカルで分散

　商業サイトではクラウド上にバックアップを取るのが一般的です。複数のクラウドに分散することはあっても、ローカルへの手動バックアップを前提としているサイトは少ないでしょう。

　しかし個人サイトはクラウドの契約解除や無償ストレージ終了などでバックアップも消えてしまうのが常です。消える直前で対策すればサルベージや移行は可能ですが、仕事や生活の多忙で断念するケースも多いのが現実。やはり最終的には物理的に手元にもデータを置いておくのが一番です。

ローカルでWordPressサイトをミラー出来る『Local』

　『Local』はPC上にLAMPやLEMPなどにWordPressを加えたスタックをウィザード形式で構築し、クラウドからバックアップしたデータでローカルサイトとして表示、管理出来るソフトです。無償版があるので個人サイト向きです。Windows、Mac、Linuxの主要OSに全て対応しているのも魅力的です。

　当サイトを実際にローカルでミラーしてみましたので、メモを残します。

まずはバックアップ

　Local自体にはクラウド上のWordPressサイトをバックアップする機能はありません。WordPressにはバックアップ用のプラグインが複数ありますが、今回は『BackWPup』を使います。

　まず、ジョブを作成します。バックアップ対象は『DBバックアップ』『ファイル』『プラグイン』の3つ、宛先は『フォルダー』、圧縮形式は『zip』にしました。

　　バックアップファイルはまずクラウド(LightSail)上に作られますので、『バックアップ』サブメニューから『ダウンロード』を選んで取得します。

バックアップのLocalへのインポート

　バックアップデータを取得したらLocalを起動し、『Import Site』でzipファイルを読み込みます。

　LocalはWebサーバにApacheとnginxを選べるなどスタックの選択肢が充実しています。サイトの再現性の観点から、なるべくクラウド上のスタックとバージョンを合わせた方が良いそうです。

クラウド上のWordPressサイトがほぼローカルで再現

　ご覧のとおり、ローカルドメイン(can.ne.jp.local)でWordPressサイトが表示されています。テーマやプラグインまで再現されているので、クラウド上のサイトイメージそのままで見られるのは嬉しいところです。

　管理画面もローカルで動いています。この環境を複数のPCやMac上に持っておけば不測の事態でも生き延びた端末から復旧が出来そうです。Web分野のトレンドが大きく変わってしまったときは、Localで過去のサイトデザインを確認しながら、どのように移行させるか検討することになるでしょう。

The post WordPressをローカル環境と同期する『Local』 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　上図がWordPress Multisiteと一般的なWordPressの違いです。

　「①　一般的なWordPress」では複数のサブドメインを展開するために同数のLightSailインスタンスを作る必要があります。インスタンスごとにリソースを確保するので、リソースを使い切らない小規模のサイトでは割高になります。一方で、特定ドメイン用のインスタンスを停止しても他のサブドメインに影響が無いと言った利点もあります。

　「②　WordPress Multisite」では単一のLightSailインスタンス内で複数のサブドメインを展開出来ます。プラグインなど管理が一元化されるほか、LightSailインスタンスをひとつしか起動しないのでアクセス数が少ないうちは料金的にお得になります。ただし、一般的なWordPress用のプラグインが使えなくなる（有償契約が必要など）ことがあるため、初心者やサブドメインの展開予定が全くない場合は避けた方が良さそうです。

　また大規模なアクセスを期待出来るサイトの場合は、LightSailインスタンスのリソース制約があるのでWordPress Multisiteは避けた方が良いでしょう。「そもそもLightSailで大規模サイトを運用するのか？」という話もありますが

長期の仕事を探しています

　今春から長期の仕事を探しています。40代なので「採用はちょっと……」という人事ご担当者様も多いと思います。正直20代の元気な方のような伸びしろはありませんが、当サイトでスキルレベルが適切と思われた方は、お気軽にお声がけ頂ければと思います。下記フォームかツイッター(https://twitter.com/masarumkt)、あるいはメール(masapon05 アットマーク gmail.com)でご連絡下さい。

The post WordPress Multisiteを選ぶべきか first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

https://ja.wordpress.org/plugins/duracelltomi-google-tag-manager/

　　ソースにGTMのタグが入っていることまでは確認しましたが、正しく動いているかは実際に訪問者がカウントされてGAの画面上に出るまで分かりません。アクセス解析がらみの設定は正しいかどうか、ミスがないか分かりにくいのでなかなかの強敵です。

　Googla Analyticsはバージョン4の展開を始めており、当サイトのタグもGA4仕様となっています。ユーザートラッキングは国際的にプライバシーとの兼ね合いが問題視されるようになって久しく、今後GAFAなどがどのような対応を取るか見えないところがあり要注意です。

The post GTM(Google Tag Manager)とGA(Google Analytics)タグの導入 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.