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

　私は『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.

　検索広告の存在は誰でも（嫌というほど）知っていますが、広告の出稿方法を実際に知っている人は「仕事で使ったことがある」方以外にはあまり居ないと思います。

　しかし、can.ne.jpでは敢えて皆さんにお勧めします。

誰でも広告を出稿しておこう

理由①　お金はあまりかからない

　Web広告の基本であり王道である『キーワード広告』。CPC(Cost Per Click)と呼ばれ、クリック毎に課金されます。キーワードごとにクリック単価が設定されており、出稿出来る総量も決まっています（検索されないと表示されないので）。

　つまり、「出稿量が少なくクリック単価も低い広告であれば、出稿しても微課金で済む(もちろん流入もそれなり)」ということです。そこで、私も実際にGoogle広告を出稿しています

　わずかではありますが、実際に広告をクリックしてcan.ne.jpをご訪問頂いた方もいらっしゃいます！

理由②　Google Analyticsの勉強になる

　Google Analyticsのキャンペーンメニューを見ると、『上位のキャンペーン』に『cpc』が表示されています。これがGoogle広告経由での流入となります。

　もちろん、この項目は広告を出稿しないと表示されません。実際に広告を出稿してみて初めて、GAが広告出稿をどのように捕捉するかが分かることになります。しかし、ふつうは仕事で広告に関わっていないと肌感覚で「広告出稿～効果測定」の流れを知ることが出来ません。運よく仕事（会社のカネ！）で広告出稿をする機会があれば自腹を切る必要はありませんが、そうでなければ自分で広告を出稿するしかありません。

　同じ発想で言えば、自分のショッピングカートや自分の商品もサイト上に置いておくべきです（can.ne.jpではまだ出来ていませんが）。「さすがにそこまでやるのは面倒すぎる」という方は、B2Bのお約束である『資料請求フォーム』を用意してリード獲得のコンバージョンを設定するのが良いでしょう。

　理由③　キーワードプランナーが使える

　これが私がGoogle広告を登録した最大の理由です。広告を出稿したことがない方でもGoogleトレンドなどでキーワードごとの検索動向をチェックしたことがあるかも知れません。

　しかし、Googleトレンドではグラフが出るだけで、実数として検索数を取得することは出来ません。実は、Google広告に付属の『キーワード プランナー』というツールを使えば、とてもざっくりとではありますが任意のキーワードに対する検索数を取得出来ます。

　　本来は出稿するキーワードやフレーズを検討するためのツールですが、とても自分では出稿出来ないようなビッグワードの検索推移なども把握できます。このツールを用いて、「どのような検索ワードの人気があるか」「どのようなテーマの人気が上がってきているか」が分かるので、

どんなテーマでブログを書けば人が来るか分かる

ということになります。私は実際に仕事でキーワードプランナーを用いてニーズが高まっているテーマを見つけて、人気ページに育てた経験があります。このような分野を『コンテンツマーケティング』と呼びます。

コンテンツマーケティングの光と陰

　ただし、アクセスがどんどん増えていったものの、取扱商品の売上はさっぱり伸びませんでした(苦笑)。アクセスさえ稼げばお金になるのはニュースサイトなどメディア系だけで、Eコマースでは「テーマへの関心」から「商品への関心」を引き出す『コンバージョン』というプロセスが欠かせません。

　コンテンツマーケティングは「ひたすら書くだけで、お金がかからない」という性質があるので、中小サイトではコンバージョンの有無に関わらず考え付く限りの関連ページを量産するのが普通です。しかし、人生もお金も有限なので、仕事である限りはコンバージョン率を常に念頭に置いてコンテンツマーケティングにも取り組むべきだと思います。

　Webは良くも悪しくも「無料が当たり前」の世界です。Webが好きな人はボランティア精神に溢れた方が多く、多くのアクセスや『いいね』をもらえれば、お金にならなくても熱心にコンテンツを作る方が少なくありません。

　しかし、私のように食うのにも困る状況になってしまっては元も子もありません。仕事では心を鬼にして、「いまのWeb作業はマネタイズにつながっているか」を常に意識する必要があります（自戒をこめて）。

The post Google広告を出稿してキーワードプランナーを使い倒す 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.

　「自前主義で行こう」と独自ドメインでサイトを再開した私ですが、動画は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

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

The post Cloudfront+LightSailでコンテンツ配信サービス(CDN)を作る 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.

　私が初めて独自ドメインで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.

　Kaggleはコンペティションで有名なため「データサイエンティスト以外はお断り」というイメージがあります。しかし、優秀な方々に及ばないことが分かっていてもKaggleを避けて通るのはもったいないと思います。

　BIツールの学習など、実務寄りのデータがほしい機会は多くあります。Kaggleにどのようなデータがあるか知っていれば、目的に近いデータを入手出来ます。特にマーケティング分野のデータは企業秘密の塊であり一般公開されることが少ないため、Kaggleのデータはとても貴重なものです。

　本日は、昨年Twitterでも触れていた「Google Analytics Customer Revenue Prediction – Predict how much GStore customers will spend」をご紹介します。

実在するEコマースサイトのアクセスログ

　このコンペはRStudio社の主催で、GoogleのEコマースサイト『GStore』のセッション単位のアクセスログが約33GB、提供されています。

　CSVのカラムにJSON風のデータが詰め込まれていて処理が手強いですが、BIツールの基本である日次統計にもってこいです。参考書籍などで数10GBのデータを扱っている例は見たことがありませんが、これくらいのサイズがなければExcelで十分であり、データベースやBIツール、データ分析基盤などのスケーラビリティを試すなら最低でもGB単位のデータが必要です。

　昨年はこのCSVデータを自力での展開を試みましたが、データ構造が複雑なため簡単な置換処理ではテーブル構造に出来ませんでした。今年は先達の方のnotebookなどを参考にして、まずはPostgreSQLへのデータ格納までたどり着きたいと考えています。他の方から学べるのもkaggleの良いところですね。

(base) masaru@ASUS-TUF-Gaming:~$ conda install --channel https://conda.anaconda.org/conda-forge kaggle
(base) masaru@ASUS-TUF-Gaming:~$ kaggle competitions download -c ga-customer-revenue-prediction

The post Kaggleのデータをコンペ以外の目的で利用する 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.