Google Colaboratory(Colab Pro)でkaggleデータをダウンロードする方法[備忘録]

 技術的な要素は無いのですが、忘れやすいのでコピペ出来るように記事を残しておきます。

kaggle.jsonをGoogleドライブに保存しておく

 kaggleのAccount画面でCreate New API Tokenボタンを押してkaggle.jsonをダウンロードし、Googleドライブに保存する(私の場合は’Colab Notebooks’直下)。

Colabの規定ディレクトリにkaggle.jsonをコピー

 Colabのノートブック画面でGoogleドライブに接続。

from google.colab import drive
drive.mount('/content/drive')

 ターミナルでkaggle.jsonを所定の位置に配置。ColabのターミナルではCtrl+C、Ctrl+Vでコピペ出来ないので、それぞれCtrl+InsertShift+Insertのショートカットで代用する(メニューバーの『編集』でもコピペ出来ない……)。

/content# mkdir /root/.kaggle/
/content# cp '/content/drive/MyDrive/Colab Notebooks/kaggle.json' /root/.kaggle/

kaggleコマンドでデータダウンロード

 Kaggleのコマンド自体はkaggleのサイトに表示されるので、コンペの利用条件を承諾してからコマンドをコピペするだけです。

/content# kaggle competitions download -c house-prices-advanced-regression-techniques
Warning: Looks like you're using an outdated API Version, please consider updating (server 1.5.12 / client 1.5.4)
Downloading train.csv to /content
  0%|                                                                                           | 0.00/450k [00:00<?, ?B/s]
100%|███████████████████████████████████████████████████████████████████████████████████| 450k/450k [00:00<00:00, 61.1MB/s]
Downloading sample_submission.csv to /content
  0%|                                                                                          | 0.00/31.2k [00:00<?, ?B/s]
100%|█████████████████████████████████████████████████████████████████████████████████| 31.2k/31.2k [00:00<00:00, 33.8MB/s]
Downloading test.csv to /content
  0%|                                                                                           | 0.00/441k [00:00<?, ?B/s]
100%|███████████████████████████████████████████████████████████████████████████████████| 441k/441k [00:00<00:00, 60.6MB/s]
Downloading data_description.txt to /content
  0%|                                                                                          | 0.00/13.1k [00:00<?, ?B/s]
100%|█████████████████████████████████████████████████████████████████████████████████| 13.1k/13.1k [00:00<00:00, 12.4MB/s]

Colabの操作性は初心者に優しくない

 Colabのインスタンスを立ち上げるたびに各種操作が必要なのが果てしなくだるいですね……。GoogleのColabチームは操作性の向上に消極的なようで、細かいところでストレスが蓄積します。GBレベルのデータダウンロードが厄介なのも大きな弱点です。

 AutoMLがオープンソースでも出てきており、細かいチューニングが不要な用途ではnotebookの体裁すら不要なノーコードの時代になってきています。本来はGUIでボタンぽちーで分析完了出来てしかるべきです。ちなみにお高いDataRobotや無料でもそこそこ使えるAutoAI with IBM Watson Studioでは既にGUIでAutoMLが可能です

伸びしろがある若い方なら思い切ってワークステーションを買ってみては?

 ワークステーションに50万円払える方は、買ってしまってローカルのJupyter Notebookで分析した方がシアワセになれるかも知れません。もちろんLinuxの知識が多少はあることが前提ですが。

 私が大学時代に貯金をはたいて購入したDECのパソコンは50万円しましたから、伸びしろがある方なら無駄な投資にはならないと思います。

Googleドライブの鬼仕様な『フォルダダウンロード』を回避する裏技(Piping Server)

 最近、Google Colab Pro(月1,072円)を契約したので、『NVIDIA V100』という高性能GPUで機械学習ごっこ(GPT-2,BERT等)をして遊んでいます。

 ところが、機械学習は10GB単位で鬼のようにデータを吐き出すので、Googleドライブが100GB有料契約(月250円)でもすぐ満杯になってしまいます。

 学習したモデルを即消しすれば良いのですが、様々なデータを食わせてAIの挙動を比べるような楽しいことが出来なくなってしまいます。

 そこで考えるのが学習データのバックアップ=Googleドライブからのダウンロードです。しかし、Googleドライブがまさかの変な挙動を示しましたので、注意喚起しつつ対処方法を記録しておきます。

圧縮すらされず変なファイルが落ちてくる

 Googleではフォルダをダウンロードしようとすると、一つあるいは複数のzipファイルに圧縮して送ってきます。ところが、2.5GBあるような大きなファイルは、なぜか圧縮せずzipとは別にボコボコ送りつけてくるのです😭

Googleドライブは、圧縮しきれなかったファイルだけ非圧縮で送ってくる。最悪だ

 上図のケースでは、各チェックポイントのフォルダごとに複数個作成されるoptimizer.ptというファイルが非圧縮のままボコボコ落ちて来た例です。ファイル名が重複するので『optimizer-002.pt』『optimizer-005.pt』など謎なファイル名になっています。さすがにこれは私も

「どのoptimizer.ptだよ!!」

キレ気味困惑してしまいます。課金してもデレないGoogleドライブの仕様を何とかして回避しなければなりません。

こうなったら自力で圧縮だ

 Googleドライブの圧縮機能がおかしいなら、自力で圧縮するまでです。Colab ProにはUbuntu Linuxのシェルがついてくるので、notebookにシェルコマンドを記述しなくても普通にシェル芸が使えます。そこで、まずはtar.gzでフォルダごと圧縮します。

シェル間ファイル転送の裏技『Piping Server』

 24時間で落ちるシンデレラ型インスタンス()であるColab Proで、ファイル転送だけのためにサーバーを立てたりトンネリングの設定をするのは面倒くさい。そこで思いついた対策がRyo Otaさんの『Piping Server』です。

 Piping Serverは、遠隔地のシェルのWebブラウザ(curl等)を仲介してWebブラウザ同士で直接テキストやファイルを送受信するものです。追加アプリのインストールが全く要らない、すごい……。

【送信側】 『Piping Server』は、任意のWebブラウザ間で直接ファイルを送受信できるサービス
【受信側】 『Piping Server』は、任意のWebブラウザ間で直接ファイルを送受信できるサービス

あとは、回線品質の安定を祈るのみです……(現時点でまだダウンロード中です💦)

ダウンロード中にColabのセッション切れを防ぐ

  2時間ほどダウンロードしたところで、切断されてしまいました。シェルコマンドが動いていてもColabセンセイは容赦なく未使用とみなしてセッションを切ってしまうようです。

 これはColabでは有名な問題で、既に他の方が解決策を見つけられています:

Google Colab セッション切れを防止する

【追記】Colab Serverとの通信速度が上がらない……

 その後、梅雨の合間を縫って図書館に行き、Piping ServerでColabからローカルへのダウンロードを試みました。しかし、通信速度が低く、1GB/時くらいしか出ません。図書館のネットは1時間に一回くらい切断される仕様なので、もはやファイルを分割するしかありません。

/content/drive/MyDrive/work# ls -al
total 8449838
drwx------ 2 root root       4096 Jun 19 04:41 output
drwx------ 2 root root       4096 Jun 19 04:32 output-3epochs
-rw------- 1 root root 8631501037 Jun 26 23:59 output-3epochs.tar.gz
drwx------ 2 root root       4096 Jun 18 15:37 runs
-rw------- 1 root root   21116052 Jun 18 15:34 train.txt
drwx------ 2 root root       4096 Jun 18 15:01 transformers
/content/drive/MyDrive/work# split -b 1000m -a 2 output-3epochs.tar.gz output-3epochs_p_
/content/drive/MyDrive/work# mkdir split
/content/drive/MyDrive/work# mv output-3epochs_p* split/
/content/drive/MyDrive/work# cd split
/content/drive/MyDrive/work/split# ls -al
total 8429201
-rw------- 1 root root 1048576000 Jun 29 09:08 output-3epochs_p_aa
-rw------- 1 root root 1048576000 Jun 29 09:08 output-3epochs_p_ab
-rw------- 1 root root 1048576000 Jun 29 09:08 output-3epochs_p_ac
-rw------- 1 root root 1048576000 Jun 29 09:09 output-3epochs_p_ad
-rw------- 1 root root 1048576000 Jun 29 09:09 output-3epochs_p_ae
-rw------- 1 root root 1048576000 Jun 29 09:09 output-3epochs_p_af
-rw------- 1 root root 1048576000 Jun 29 09:10 output-3epochs_p_ag
-rw------- 1 root root 1048576000 Jun 29 09:10 output-3epochs_p_ah
-rw------- 1 root root  242893037 Jun 29 09:10 output-3epochs_p_ai
/content/drive/MyDrive/work/split# cat output-3epochs_p_aa | curl -T - https://ppng.io/epochs
[ERROR] Connection on '/epochs' has been established already.
/content/drive/MyDrive/work/split# cat output-3epochs_p_aa | curl -T - https://ppng.io/epochs2
[INFO] Waiting for 1 receiver(s)...
[INFO] A receiver was connected.
[INFO] Start sending to 1 receiver(s)!
% curl https://ppng.io/epochs2 > output-3epochs_p_aa.tar.gz
% curl https://ppng.io/epochs2 > output-3epochs_p_ab.tar.gz
% curl https://ppng.io/epochs2 > output-3epochs_p_ac.tar.gz
% curl https://ppng.io/epochs2 > output-3epochs_p_ad.tar.gz
% curl https://ppng.io/epochs2 > output-3epochs_p_ae.tar.gz
% curl https://ppng.io/epochs2 > output-3epochs_p_af.tar.gz
% curl https://ppng.io/epochs2 > output-3epochs_p_ag.tar.gz
% curl https://ppng.io/epochs2 > output-3epochs_p_ah.tar.gz
% curl https://ppng.io/epochs2 > output-3epochs_p_ai.tar.gz
% cat $ output-3epochs_p_* > output-3epochs.tar.gz
% tar -zxvf output-3epochs.tar.gz

 ただのデータバックアップなのに、気が遠くなる作業です。お金持ちの方は観念してGoogleドライブに多額の納金をするのが現実的かと思います……。

 Colabはお得で面白いサービスですが、なかなか癖も強いので付き合うのは大変そうです……。

【追記】分割もダメでした……

 図書館で数日に分けて分割ダウンロードをして、ローカルでtar.gzの解凍を試みたところ

(base) masaru@MacBook-Pro-15 output-3epochs % tar -xvf output-3epochs_p_aa.tar.gz 
x output-3epochs/
x output-3epochs/checkpoint-5000/
x output-3epochs/checkpoint-5000/config.json
x output-3epochs/checkpoint-5000/pytorch_model.bin: truncated gzip input
tar: Error exit delayed from previous errors.

結局エラーが出て解凍出来ませんでした……。回線品質が劣悪でtarやPiping Serverにエラー補正がないため、ダウンロード途中でデータが壊れてしまったものと思われます。

 そんなわけで、「高速回線がないと使いこなせない」というのが、現時点での私のGoogle Colab Proへの見解です。

【追記】3分割で再試行し、ようやくダウンロード成功

 緊急事態宣言が出て図書館の人出が若干減ったので、3分割で再試行しました。

(base) masaru@MacBook-Pro-15 output-3epochs % cat output-3epochs_p_* > output-3epochs.tar.gz 
(base) masaru@MacBook-Pro-15 output-3epochs % ls -al
total 33769200
drwxr-xr-x  6 masaru  staff         192  7 29 18:15 .
drwxr-xr-x  4 masaru  staff         128  7 12 19:03 ..
-rw-r--r--  1 masaru  staff  8631501037  7 29 18:16 output-3epochs.tar.gz
-rw-r--r--  1 masaru  staff  3145728000  7 12 19:35 output-3epochs_p_aa.tar.gz
-rw-r--r--  1 masaru  staff  3145728000  7 21 19:47 output-3epochs_p_ab.tar.gz
-rw-r--r--  1 masaru  staff  2340045037  7 29 18:08 output-3epochs_p_ac.tar.gz
(base) masaru@MacBook-Pro-15 output-3epochs % tar -xvf output-3epochs.tar.gz 
x output-3epochs/
x output-3epochs/checkpoint-5000/
x output-3epochs/checkpoint-5000/config.json
x output-3epochs/checkpoint-5000/pytorch_model.bin
x output-3epochs/checkpoint-5000/tokenizer_config.json
x output-3epochs/checkpoint-5000/special_tokens_map.json
x output-3epochs/checkpoint-5000/spiece.model
x output-3epochs/checkpoint-5000/training_args.bin
x output-3epochs/checkpoint-5000/optimizer.pt
x output-3epochs/checkpoint-5000/scheduler.pt
x output-3epochs/checkpoint-5000/trainer_state.json
x output-3epochs/checkpoint-10000/
x output-3epochs/checkpoint-10000/config.json
x output-3epochs/checkpoint-10000/pytorch_model.bin
x output-3epochs/checkpoint-10000/tokenizer_config.json
x output-3epochs/checkpoint-10000/special_tokens_map.json
x output-3epochs/checkpoint-10000/spiece.model
x output-3epochs/checkpoint-10000/training_args.bin
x output-3epochs/checkpoint-10000/optimizer.pt
x output-3epochs/checkpoint-10000/scheduler.pt
x output-3epochs/checkpoint-10000/trainer_state.json
x output-3epochs/config.json
x output-3epochs/pytorch_model.bin
x output-3epochs/tokenizer_config.json
x output-3epochs/special_tokens_map.json
x output-3epochs/spiece.model
x output-3epochs/training_args.bin
x output-3epochs/train_results.json
x output-3epochs/trainer_state.json
x output-3epochs/eval_results.json
x output-3epochs/all_results.json

 ようやく無事、解凍までたどりつきました……。

40代後半のおじさんが今さら基本情報技術者試験(FE)を受けた理由

Web担10年、未だ資格無し

 私は『Web担当者』の仕事をのべ10年ほどやってきました。出版社で言えば『編集者』のようなもので、地味な裏方で世間にはほとんど知られていませんが、実在する仕事です。

 Web担当者は商品企画、情シス、制作会社など様々な社内外の部門と連携してWebサイトを企画・運営します。分かりやすく言えば「Web予算を取る部署」でもあります。

 Web担当者は基本的に自分で作業してはいけません。仮に文章や画像を自分で作れても、品質を保つため社外ライターやデザイン会社に敢えて任せます。HTMLやCSSなどの知識が多少あっても、Web標準やデザインガイドラインなどにキチンと準拠するため基本的には自分でコードを書きません。趣味でWebサーバーやデータベースをいじっていても、システムエンジニアではないので開発から運用まで情シスやSIerに任せます。

 結果、Web担当者はWeb関連のスキルや動向を広く浅く把握はするものの、自分のスキルを証明するような資格を業務の一環として取得することは稀です。自力で資格を取っても、それで給料が上がることもありません。職場ではいちおう「パソコンに強い人」として認められてはいますが、会社を辞めた途端にスキルを証明する手段が職務経歴書以外なくなってしまいます。

 「どんな仕事も同じでは?」と思う方もいらっしゃると思いますが、違います。私は新卒で雑誌社に入社し、編集者として働いていた時期もあります。編集者なら自身が携わった書籍が実績として残りますが、Webサイトは定期的にリニューアルされて消えてしまうため実績が形として残りません

『加齢』という第二の壁

 そうは言っても「面接で実績をアピールすれば何とかなる」とお考えかも知れません。しかし、Web業界でこれが通用するのは若いうちだけです。

 Web分野は凄い勢いで技術が変わっていきます。ここ数年でもモバイルファースト時代の常識『レスポンシブ対応』に始まり、サーバー側で動くJavaScript『node.js』とこれに続く『Vue.js』『React』『Angular』などの各種Webフレームワーク、1ページにコンテンツを詰め込む『SPA(Single Page Application)』、Webサイトをアプリ化する『PWA(Progressive Web Apps)』など気が遠くなるような新技術の嵐です。書いている私も正直よく分からない『フロントエンド』というカオスがここにあります。

 1990年代からWebに携わっていても、意識的に知識を更新していないと「HTML5?何それ?」という状況になってしまいます。Webサイトを重くする元凶ではあるけれどもWebの華だったFlashも姿を消しました。20年前のホームページも全く表示されないことは無いかも知れませんが、この20年でWeb技術はほぼ別物になったと断言出来ます。

 「ホームページ?誰でも作れるだろ?昔はみんな自分で作ってたじゃん」こんなおじさんはもうWebを語る資格がありません。Webが進化する中で、Web担当者が直接関わる技術はCMS(Contents Management System)をポチポチするだけになりがちです。個人でWebサイトを持つ人は減り、ブログを書くことすら面倒になり、自分では何もしないおじさんになり、SNSでくだを巻くだけに、なっていないでしょうか。

 この20年間の加齢により、私は「何も出来ないおじさん」になってしまっていないでしょうか。何らかの理由で会社を辞めた元Web担おじさんに、次の仕事はあるでしょうか。

「今どきのWeb技術を何も知らないおじさん」と思われないために出来ること

 加齢とモチベーションの低下で新技術の吸収を怠った元Web担おじさんは、今どきのWebサイト運営には何の役にも立ちません。昔から、社内Web担当者は専門家とは限らず「人事異動で何となくWeb担当になった」という腰掛けの人も少なくありません。全てを丸投げにすれば、何も知らないままでも任期を乗り切ってこれた人もいるでしょう(色々とまずいのですが)。

 私は仕事を辞めたことで、自分が「今どきのWeb技術を何も知らないおじさん」ではないことを40代後半にして証明しなければならなくなりました。そもそも現代のWebサービスは社内外の様々な情報システムと連携して動くのが当たり前なので、フロントエンドだけ知っていれば良いというものではありません。

 フロントエンドの怒涛の変化にすら正直ついて行けていないのですが、少なくとも「システムなんも分からん」おじさんでは無いことを証明するために思いついた窮余の策が『基本情報技術者試験』でした。

基本情報技術者試験は、皆が思っているほど『時代遅れ』ではない

 基本情報技術者試験(基本情報、FE)の起源は、2000年度に廃止された『第二種情報処理技術者試験(情報二種)に遡ります。そのため、昔をよく知るおじさんほど「そんな化石みたいな資格を今さら取ってどうするの?」というイメージを抱きがちです。「学生が取る資格」というイメージも強く、実際試験会場で見る他の受験者も20代前後が多いように感じます。

 しかし、基本情報は世間のイメージほど化石ではありません。過去問や試験対策本を読むと、特に情報セキュリティ分野ではSaaSの社内利用、クラウドへの移行、テレワークといった旬のテーマをそれなりに盛り込んでいることがわかります。

 学生が丸暗記で取った基本情報にはあまり価値が無いかも知れませんが「実務経験に裏打ちされた基本情報(や応用情報など各種上位資格)なら無駄な知識ではない」と現場でかつて働いていた経験から断言出来ます。

で、結局どうだったの?

 実際に基本情報を受けてみれば分かりますが、この資格がカバーする分野は非常に幅広いものです。正直、世間の「学生が片手間に取るもんだろ?」という評価と比べると「おじさんにはボリューム的になかなかしんどい……」というのが元Web担おじさんの本音です。

 午前試験・午後試験それぞれ60%以上正答出来れば合格なので、「何とかなりそう」という状況ではあります。合格発表がまだ先なので結果は後日追記しますが、もし基本情報が全く役に立たない資格だとお考えなら、だまされたと思って一度受けてみることをお勧めします。

 特に、機械学習やデータ分析などでPythonを覚える機会があった方は、話のネタにPythonで午後試験を受けてみてはいかがでしょうか。長いコードが出てはきますが、選択式で「コードが書けず苦しむ」といった要素はないので安心してください🐍

とは言え、『Not enough』

 基本情報は決して化石資格ではありませんが、良くも悪くも国家資格なのでベンダー固有のスキルやナレッジは試験範囲に含まれません。また、私のような本業マーケッターな人間は技術力だけを証明すれば良いわけではありません(技術力だけならポンコツエンジニアもどきです)。

 そんなわけで、基本情報に加えて下記のような資格を取ろうかと思案中です。

  • Webマーケティング関連の資格(Google アナリティクス個人認定資格、GAIQ)
  • クラウドの資格(AWS 認定ソリューションアーキテクト、AWS SAA)
  • データベースの資格(OSS-DB Silver Ver.2.0、PostgreSQL)
  • Web制作(あまり著名な資格が無いので、取るかは未定)

最後に:この歳からエンジニアになりたいわけではありません

 ここまでお読み頂いた方には今さらですが、「エンジニア系の資格を取る」ことと「エンジニアになる」ことは全くの別物です。40代からエンジニアの仕事を始めるなど有り得ません。あくまでも「システムに明るいWeb担当者(マーケッター)」を目指しているだけです。

 どのような事業でも、Webサイトやアプリなどを用いたデジタルマーケティングは当たり前のものになっています。エンジニアにはなれないことが分かっていても、技術的な基礎知識を薄く広くでも網羅的、体系的に持っていることがビジネスマン全般に求められている(「コミュ力が全て」ではない)と信じています。

[AWS+WordPress]今さら聞けない二段階認証(MFAデバイス)でのセキュリティ強化

聞くとヤバいので本当に今さら聞けないセキュリティ対策

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

 この数か月で少し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で検索してみると、下記のような認証アプリがヒットします:

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

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

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

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

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

ルートユーザーに二段階認証を入れるメニューは『マイセキュリティ資格情報』(2021年5月現在)
AWSの二段階認証は『多要素認証(MFA)』という名称

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

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

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

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

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

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

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

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

Oracle Cloudの無料枠が太っ腹(ただし初心者向きではない)

AWS以外のクラウドには仮想マシンの無料枠がある

 AWSで構築したcan.ne.jpですが、維持費に毎月数ドルかかります。「AWSのメールマガジンで毎月バウチャーをもらえばホニャララ」という話もあるのですが、AWSでWebサイトを作ると初年無料を除けば基本的に有料です(2021年4月現在)。

 一方で、AWSに対して出遅れ感があるGCP(Google Compute Engine)やOCI(Oracle Cloud Infrastructure)は永年無料でWebサイトを構築出来る仮想マシン(Virtural Machine, VM)を立てられます。

 クラウドに慣れる目的もあり、GCPとOCIの双方で仮想マシンを立ててみましたが、特にオラクルのOCIが太っ腹だったのでご紹介します。

無料枠なのにAWSのLightSailよりハイスペック

 OCIの無料枠『Always Freeリソース』にはデータベースやストレージもありますが、好きなデータベースをインストールして使えるのはAlways Freeコンピュート仮想マシン(VM)インスタンスです。スペックは

  • シェイプ: VM.Standard.E2.1.Micro
  • プロセッサ: 追加のCPUリソースを使用する機能を持つ1/8 OCPU
  • メモリー: 1 GB
  • ネットワーキング: 1つのパブリックIPアドレスと最大480 Mbpsネットワーク帯域幅を持つ1つのVNICが含まれます
  • オペレーティング・システム: 次のいずれかのAlways Free対応オペレーティング・システムを選択できます:
    • Oracle Linux (Oracle Autonomous Linuxを含む)
    • Canonical Ubuntu Linux
    • CentOS Linux

1/8 OCPUってなんぞや?

 「1/8 OCPUってなんぞや?」と調べてみたところ、AMD EPYC 7551 32-Core ProcessorというCPUの1コアが割り当てられていました。最近のCPUは6コア12スレッドくらいあるので、その1コアぶんくらいでしょう。

[opc@mysql ~]$ sudo cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 23
model		: 1
model name	: AMD EPYC 7551 32-Core Processor
stepping	: 2
microcode	: 0x1000065
cpu MHz		: 1996.249
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 nt_good virt_ssbd arat npt nrip_save
bugs		: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips	: 3992.49
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 23
model		: 1
model name	: AMD EPYC 7551 32-Core Processor
stepping	: 2
microcode	: 0x1000065
cpu MHz		: 1996.249
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 nt_good virt_ssbd arat npt nrip_save
bugs		: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips	: 3992.49
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual

メモリー1GBは余裕がある

 can.ne.jpが動いているAWS LightSailは最安プランではメモリが512MBしかありません。

LightSailの最安プランはメモリが512MBしかない

 OCIの仮想マシンはメモリが2倍の1GBあるので、アクセス負荷への耐性がLightSailの最安プランよりずっと高いと思われます。今から自分がWordPressのブログサイトを作るなら、少し面倒でもOCIで自分で構築すると思います。

ストレージは100GBまでいけそう

 画像をたくさん置くブログでは気になるストレージ容量ですが、「コンピュート・インスタンスをプロビジョニングする場合、インスタンスはストレージ用に50 GBのブート・ボリュームを自動的に受け取ります」との記述があり基本50GBです。

 さらに「ブロック・ボリュームを作成してアタッチすると、コンピュート・インスタンスのストレージ容量を拡張できます」「すべてのテナンシは、合計100 GBのAlways Freeブロック・ボリューム・ストレージと、5つのボリューム・バックアップを受け取ります」とあるので、ブロックボリュームをアタッチすることで100GBまで拡張出来ると思われます。

 上のLightSailプランの5倍ですね……。

やっちまった…… Oracle Linuxってなに??

 深く考えずにポチポチして仮想マシンを作ったところ、Oracle Linux 7.9という独自Linuxが入ってしまいました。Red Hat Enterprise Linuxのクローンなのでコマンド周りはCentOSに近いのですが、正直

「特に理由が無いのに、よく知らないOSは使いたくない。面倒くさい」

 というのが本音です。UbuntuやCentOSも選べるらしいので、これからOCIを始める方はOS選びに気をつけて下さい。

セキュリティ周りが面倒くさい(間違ってはいないけど)

 OCIでインスタンスを作ると、他社とは異なりデフォルトでファイアウォールが有効になっています。ファイアウォールを設定してポート開放しないとWebサイトすら公開出来ないので、初心者向きではありません。

 とは言え、セキュリティの問題はサイトを公開する以上は避けて通れないので、敢えて苦しんで設定してみるのも良いかと思います。

 また、AWSやGCPには標準で備わっている『Webブラウザ版のSSHクライアント』が無い(ような)ので、RLoginなどのSSHクライアントをインストールするかシェル版のsshを長いコマンドを打って起動する必要があります。こういった「とっつきやすさ」では、OCIはまだAWSやGCPより一歩遅れているように思います。

 オラクルのビジネスモデルを考えると、そもそも初心者やライトユーザーは見込み顧客として想定していないと思いますが……💦

【追記】ufwでポートが開かない問題、私も遭遇しました😭

 OCIでのポート開放で、「ufwを用いてポートを開放できない問題に遭遇」する問題に私も遭遇しました。

 1つ目のインスタンスにLogstashを入れたところ凄いメモリ食いでメモリ1GBでもフリーズが頻発。泣く泣く他のサーバーを落としてOCIのサイトを見ていたところ「2つのAMDコンピュートVM」との記述を発見。「Oracleどんだけ太っ腹なんだ」と思いつつ2個めを立ち上げたところ、SSLが開きません。

 セキュリティーグループを作りイングレスを設定しても無反応。「これはインスタンス内部の問題か?」と思いufwを設定するも無反応。かなり絶望的な気分で1時間くらい検索しまくったところ

結論だけ先に言っておくと、Oracle Cloud上だとufwはバグっているのでiptablesをいじってポート開放すればいいです。

Oracle Cloudでポートを開放されない問題の解決策 – viasnake.com

との超ありがたい記述が。こんなんわかんねえよ先に言っといてくれよOCIさん😭😭😭

 ……というわけでサイトの記述に従ってiptablesを直接書き換えて無事解決しました。ufwは幅広く使われているのでポート開放でドハマりしたUbuntuユーザーは少なくないはず。不具合に対処するか、せめて「ufw使うな」と公式に書いておいてほしかったです。

CloudFront+LightSailでスケーラビリティが(それなりに)あるサイトを安く作る

敢えてサイト丸ごとCDNにしない

 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の構成図は下記となります。

can.ne.jpのCDN構成図

 まず、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の青天井課金から逃げることだけは出来ます。

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

Next.jsで苦しんでいます

Node.js以来、Web周辺の技術はすっかり変わってしまった

 WordPressによるサイト構築で苦しむことはなかった私ですが、Node.js以降時代が変わりSPA(Single Page Application)やJamstack(JavaScript/APIs/Markup)など訳の分からない技術であふれています。

 「PHPのままでいいじゃん」と正直思っているのですが、時代の変化から目を背けるとどんどん「昔の人」になり、「仕事では使えねーやつ」と若い人から後ろ指を差されてしまいます。

 基本的にはJavaScriptを用いたWebサイトの高速化とアプリ化、API連携あたりがトレンドなのだろうとは理解していますが、あまりにも複雑過ぎて手を出せないまま今日まで来てしまいました。さらにTypeScriptなる派生言語まで出てきて、おじさんはどこから始めたら良いかすら分からず頭を抱えています。

またインストールおじさんに

 取り敢えず環境を構築してみないと分かるか分からないかも分からないので、泣きながら環境構築を始めました。

 しかしフロントエンド周りの環境は複雑を極めており、エラーと試行錯誤とフォルダごと削除を何時間も繰り返すような地獄の様相です。素人なので確たることは言えませんが、フレームワークが林立して「混乱している」ように感じます。npm?npx?yarn?と首をかしげているうちに環境がぶっ壊れてしまいます。

 一番きつかったのが、またもやAnacondaとの競合です。Anacondaが起因と見られるエラーでインストールが止まってしまいました。仮想環境を切り替えても解決しなかったので、止むなくUbuntu LinuxにWeb専用のアカウントを追加し、そちらで作業することで何とかHello Worldまではこぎつけることが出来ました。

データ分析用とWeb開発用はアカウントを分けた方が良い

 完璧な設定をすればデータ分析用とWeb開発用で共通のアカウントを使うことも出来るのでしょう。しかし複数のフレームワークが混ざることに伴うトラブルシューティングの手間を考えれば、最初からWeb開発用のアカウントを別途作成した方が苦しまずに済むのではないかと思います。

 半日環境構築で格闘して皆さまのお役に立てそうなTipsはこれだけでした……。

今のフロントエンドは『プログラマー』になる覚悟が必要

 HTML/CSS、PHPあたりを軽くかじってWordPressなどのCMSをポチポチしてきただけの人には、相当厳しいと思います。今のフロントエンドは、Pythonなどと同様『プログラマー』になる覚悟が必要です。

 WordPressですべての用が足りている人は、無理に次のトレンドに乗る必要はないと思います。しかし、私のようにWeb担当の経験くらいしか売りモノがないおじさんは、この塹壕戦から逃れることが出来ません。

 正直、なぜフロントエンドをここまで複雑にしなければならないのか、未だに腑に落ちないところがあります。しかし時代の変化を嘆いていても仕方ないので、可能な限りキャッチアップしていきたいと思います。

 そんなわけで、更新が滞り気味な私の近況報告でした。

Cloudfront+LightSailでコンテンツ配信サービス(CDN)を作る

自前主義なら動画まで

 「自前主義で行こう」と独自ドメインでサイトを再開した私ですが、動画はYouTube先生に依存しています。動画はファイルが大きいので自分のサイトに置くのは正直怖いのですが、自前主義をテーマにしてみたので動画もサイトに置いてみることにしました。

LightSailは安いがしょぼい

 LightSailはAmazonの格安ホスティングサービスで「月額 3.50 USD から」が売りです。お財布に余裕が無い私は迷わず3.5ドルコースを選びましたが、スペックは下記のようなものです。

 うちのパソコンよりしょぼいです💦 無名サイトなので余裕ではあるのですが、動画を置くのは怖い。というわけで、Amazonのコンテンツ配信サービス(CDN) 『CloudFront』を入れてみることにしました。

 CloudFrontはWebサーバーのファイルをキャッシュして配信を代行してくれるサービスです。CodeZineによれば「東京における16のCloudFrontエッジロケーションおよび1つのCloudFrontリージョナルエッジキャッシュ、2つのAWS Direct Connectロケーション、大阪における1つのCloudFrontエッジロケーション、および1つのDirect Connectロケーション」とあり、2021年3月時点で日本国内に17か所の配信サーバーがあります。

 これならWebサーバーがしょぼいままでも、動画をCloudFrontに置けば、万が一アクセスが増えてもサーバーが落ちる事態は防げそうです。

で、CloudFrontはナンボなの?

 「でも、お高いんでしょう?」

 特に仕事でアカマイなどのCDNを入れたことがある方は、とても、とても心配になると思います。実際、企業向けのサービスなので多少の出費は覚悟する必要があります。具体的には、

 日本向けの料金が1GBあたり0.114ドルです。20MBの動画が月間1万再生されると約200GBになりますので、月22.8ドルになります。

「やはり、お高い……」

 しかしここはぐっと歯を食いしばって「1万再生もあれば22.8ドルくらいの収入は期待出来るだろう」と前向きに考えます。

CloudFront、なんとか動きました

 その後試行錯誤した結果、なんとかCloudFrontを動かすことが出来ました。

$ curl -svo /dev/null https://cf.can.ne.jp/v/my-domain-in-2020s.mp
4
*   Trying 54.239.169.55:443...
* Connected to cf.can.ne.jp (54.239.169.55) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /opt/bitnami/common/openssl/certs/curl-ca-bundle.crt
*  CApath: none
...
< HTTP/1.1 200 OK
< Content-Type: video/mp4
< Content-Length: 13960998
< Connection: keep-alive
< Server: nginx
< Date: Mon, 12 Apr 2021 09:15:50 GMT
< Last-Modified: Mon, 12 Apr 2021 08:33:00 GMT
< ETag: "607405bc-d50726"
< X-Frame-Options: SAMEORIGIN
< X-Cache: Hit from cloudfront

X-Cache: Hit from cloudfront

 次回以降、どのような設定を行ったかをゆっくり書いていきたいと思います。

2020年代に独自ドメインは必要なのか?

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

 このブログは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で運営しているので、自分が好きなようにサイトをカスタマイズできます。また、サブドメインを作ることで自分のサイトであることを証明しながら複数のサイトを運営することも出来ます

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

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

WordPressサイトを静的に出力してGitHub Pagesを作る

セキュリティが心配されるWordPress

 前にいた会社でキャラクター商品宣伝用のスペシャルサイトを作ることになりました。独自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 Pages用のレポジトリを作成する

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

GitHub DesktopならCLIが苦手な初心者でも安心()

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

Simply Staticは2か月前に更新されており無償なので安心

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

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

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

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

HTMLを表示するには、1つずつGitHub上でコミットし直すか数10分待つ必要がある

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

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