無職の私は、生活のために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.

　2021年の6月に受験した『基本情報技術者試験』（受験までの顛末は「40代後半のおじさんが今さら基本情報技術者試験(FE)を受けた理由」参照）ですが、受験から1ヶ月以上経った7月29日にようやく合格発表がありました。

結果は『合格』。これで『エンジニア』を名乗れる（名乗らないけど）

　プロメトリックのスコアレポートからほぼほぼ合格なことは即日で確認済でしたが、結果は『合格』となりました。

　私は元ウェブ担当者でありディレクター的な立場なので、決してシステムエンジニアではありません。年齢的に今からエンジニアを目指すのは現実的でないことも過去の記事で明記しています。

　しかし、他業種からの未経験転職者が1～2ヶ月で取得出来てしまう『ITパスポート』レベルの方とは実務経験や知識量が違うことを証明するため、今のタイミングで基本情報を取得することはどうしても必要なことでした。

40代後半の非エンジニアにとっての『合格』の意味

　基本情報技術者試験(FE)は経済産業省の国家資格ですが、IT業界の新卒が入社2～3年以内に取るようなレベルのものです。
　スキルアップを確認するというよりは、むしろ『40代後半』という年齢で「まだ現役の知識を維持している」ことを証明する手段のひとつ、との認識です。

そして、終わりがない加齢との戦いへ……

　先の記事でも指摘しているとおり、基本情報技術者試験(FE)は決して「時代遅れの試験」ではありませんが、クラウドやデータベースなどベンダー固有の知識や実務能力を証明するものではありません。そうした意味では「有意義だがnot enough」な資格です。　

　今後、クラウドやデータベースなどの資格も追加で取得したいと考えています。これらは有効期限がある資格なので、終わりがない加齢との戦いになります……。

The post 基本情報技術者試験(FE)の合格を確認しました first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　突然GCP(Google Cloud Platform)からメールが届きました。Googleからなので「またセキュリティ警告かよ」とびっくりして開いたところ、なんと「無料枠のVM(仮想サーバー)が2021年8月1日からグレードアップするからお引越ししてね」という嬉しい内容。

　GoogleにはColab Proで月1,072円課金していますが、正直GCPには課金する魅力を感じていませんでした。今回無償のままグレードアップということで、新VMのインスタンス仕様を調べてみました。

新無料VM『E2-Micro』はメモリ1GBで「まあまあ」

　GCPの料金ページを見ると、

• 2 つの vCPU の 12.5%
• メモリ1GB
• ディスクの記載なし

というわけで、メモリが1GBでOCIに並んだほかはイマイチよく分かりません。vCPUに関しては、おそらく「ご近所が空いている時は2vCPU使ってくれるが、使いすぎたり混んでいる時にはリソースを減らされる」ということだろうと思います。常時フル稼働する用途でなければ、実質的には2vCPUと考えて良さそうです。

ディスクは別枠で最大30GBのストレージをアタッチするらしい

　ディスクに関する記載がなく相変わらず初心者に不親切だなと困っていたところ、Qiitaで「標準永続ディスク ストレージは30 GB まで無料枠内」との記載をみつけました。

　どうやら、何も考えずに無料枠でVMを立ち上げると10GBのSSDが30GBの枠から割り当てられ、明示的に割り当てを30GBに変更することで30GBがフルで割り当てられるようです。「VMとは別枠だからVM側のスペックには記載がない」ということなのでしょう。

持っておいて損はなさげ

　これまでのGCPの無料枠は「お情け」「お試し」というイメージがありましたが、OCIに近いスペックになったことで「真面目に使ってみてもいいかな」という印象に変わりました。特にAWS LightSailの最安プランよりはハイスペックなので、なんとなくLightSailを使っている人は引っ越した方がシアワセになれそうです。

　おそらく、VMとストレージを別枠で確保したクラウド構造になっていることで、E2-Microへの引越しもウィザード的に簡単に出来るはずです（ですよねGoogle先生）。

【追記】E2-Microに移行しました

　Google先生から告知があった新無料VM開始日の8/1から、時差を考慮して1日遅れの8/2にE2-Microへ移行しました。

　基本的に作業はマウスポチポチだけですが、さすがにVMをいったん止めないとインスタンスのグレード変更は出来ませんでした。インスタンスの停止後『編集』をクリックし、『マシンの構成』から『汎用』『E2シリーズ』『マシンタイプ：e2-micro(2 vCPU、1GBメモリ)』を選び、保存。インスタンスを再起動します。

無事移行。ただし無料かどうかは次の請求まで不明……

　インスタンスの変更後、 e2-microのメモリが1GBになっていることを無事確認しました。apacheとPostgreSQLが動いている状態で600MB以上メモリが余っているのは嬉しいですね。

　しかし、GCPはOCIなどと違って管理画面に『無償です』といった表示は特に出ないので、次回の請求まで無料枠が適用されているかどうかは分かりません。ドキドキですね（）

The post GCPの無料クラウドVMが性能アップするらしい(F1-Micro → E2-Micro) 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.

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+Insert、Shift+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万円しましたから、伸びしろがある方なら無駄な投資にはならないと思います。

The post Google Colaboratory(Colab Pro)でkaggleデータをダウンロードする方法[備忘録] first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

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

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

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

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

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

　上図のケースでは、各チェックポイントのフォルダごとに複数個作成される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ブラウザ同士で直接テキストやファイルを送受信するものです。追加アプリのインストールが全く要らない、すごい……。

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

ダウンロード中に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

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

The post Googleドライブの鬼仕様な『フォルダダウンロード』を回避する裏技(Piping Server) first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

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

The post 40代後半のおじさんが今さら基本情報技術者試験(FE)を受けた理由 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.

　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

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

　can.ne.jpが動いているAWS 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より一歩遅れているように思います。

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

The post Oracle Cloudの無料枠が太っ腹（ただし初心者向きではない） 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.