MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru
Cross the cliffs of the times
2022年の11月から3か月以上かかった練馬から田無への引越し。サーバー20台を始めとする家財の異常な多さに気が遠くなりそうでした。レンタル倉庫を借り、サーバー群を梱包して自転車で数台ずつ運ぶことから始まり手荷物での無限往復が数十回。2023年2月下旬現在、ようやく引越しが9割がた完了しました。
落ち着いたので放置していたcan.ne.jpを開いたところ、WordPressが落ちていて恐ろしいエラーメッセージが😱
泣く泣くワードプレスで「このサイトで重大なエラーが発生しました。」と表示された場合の対処方法を参考にエラーログを有効にした結果、Simply Staticプラグインがぶっ壊れていることが判明。WordPressプラグインをFTPで強制無効化・停止する方法でSimply Staticを外すことでいったん解決しました。
まだ、目次のプラグインがぶっ壊れてますね……まぁとりあえず良いか。個人サイトだし。
理由は……お察しです😭
AWSやAzure、GCP、OCIなど大手ITはクラウドサービスを揃え、熱心に推進しています。個人でもクラウドを学習しやすいように、無料枠やクーポンを拡充するベンダーも増えてきました。
クラウドはPCやLANなどの初期投資が不要でコスト的にも敷居は低く、高性能PCを上回る処理能力の仮想マシン(VM)インスタンスも提供されています。
しかし、常時稼働するとランニングコストが1台あたり月1万円を超えてきます。私は90年代からレンタルサーバーで当サイトを運営してきましたが、普通のサラリーマンとして自腹でサーバー費用を負担するのは月 1万円あたりが限界でした。
クラウドがコスト的に有利なのは「必要なものを必要なときだけ」調達するからです。具体的には当Webサイトのように最小限のリソースだけ常時稼働する場合、あるいは機械学習などのために高性能GPUなど贅沢なリソースを一定時間だけ用いる場合などに限られます。技術力が高い方なら、データ処理タスクにしか課金されないサーバーレスアーキテクチャでシステム全体を構築することも選択肢となり得ます。
いずれにせよ、「使い放題はクラウドでは実現出来ない(現実的な費用では)」ということです。例外として、常時稼働こそ出来ませんが月1,000円でGPUインスタンスが使い放題なColab Proあたりがデータ基盤として個人が契約出来るクラウドの限界、との認識です。
ここでいったん原点に戻り、「個人が何のためにデータ基盤を構築するのか？」というテーマを考察します。
学校の課題や仕事で、初めてデータ分析に取り組んだときのことを思い出してみましょう。ほとんどの人はExcelだったと思います。機械学習界隈では「なぜかいきなりPython」というストーリーが多いです。しかし、PythonやRはExcelより圧倒的に敷居が高いですから、本来は「Excelでは無理だから」PythonやRに取り組むのが筋、というものでしょう。具体的には
といった動機であるはずです。これってかなり高度で贅沢ですよね。まずExcelやGoogleスプレッドシートを試してみて、データ分析の目的が本当にExcelやGoogleスプレッドシートで足りないのか確認することをお勧めします。特にGoogleスプレッドシートはPC版のExcelではやりにくいウェブからのデータ取得も無料で出来ますので、集めたいデータがビッグデータでなければ最初に検討するべき選択肢だと思います。
ここまで来ると、個人でデータ基盤を作るのは「ビッグデータを贅沢に使いたいから」だということが見えてきます。本来なら企業や大学でしか扱えないような巨大なデータを敢えて個人で蓄積・活用したいのが動機ですから、石油王でもなければクラウドでは無理ということになります。
オンプレと言っても、PC1台で出来るタスクなら『データ基盤』などという仰々しいものを個人で作る必要はありません。バックアップの観点でもGoogleドライブでは100GBが年額2,500円ですから、将来的に1TBを超えるようなデータを管理したいような人が『データ基盤』を検討する価値がある人、ということになります。
個人でテラバイト単位のデータを大量に蓄積して利活用するには、さすがにクラウドやPC1台では無理があります。そこで複数台のPCを連携する『PCクラスタ』を考えてみます。
個人用PCは最近ではノートPCが主流ですし、タワー型のような大型PCを複数台自宅に置くのは現実的ではありません。しかしコールセンターや受付用に販売されている超小型PCなら、5台くらい自宅に置いても場所はさほど取りません。私の自宅では、実際に超小型PCが10台ほど稼働しています。
1台あたりの消費電力は30W前後で、電気料金は1台あたり月額数百円程度です。電気料金だけで見れば「オンプレデータ基盤のランニングコストはクラウドの100分の1」ということになります。
データ基盤としてのPCクラスタ利用を想定する場合、LANの速度が深刻なボトルネックとなります。現状ではコストとの兼ね合いから2.5GbEで構築するのが現実的です。少しお値段が張りますが2.5GbE対応のハブとUSB接続のLANアダプターを用意することをお勧めします。
OSは、アップデート時の通信量の少なさやサーバー管理の容易さなどからUbuntu Linuxを使用しています。現在はUbuntu 20.04 LTSを使用していますが、2022年4月末にリリース予定のUbuntu 22.04 LTSに入れ替える予定です。Ubuntu 22.04 LTSは、最近のAMD Ryzen APUでも素のバニラ状態で動く初のLTSリリースとなるため大いに期待しています。なお、後にご紹介する『分散データベース』は大半がJava VM上で動作するため、中古PCバンドルで安価に入手出来るWindows Professionalなど一般の方が使い慣れたOSでも構築運用自体は可能と思われます。
念のため補足しておきますが、超小型PCをクラスタ運用する際には、モニターやキーボードは邪魔なので外しています。必要に応じてHDMI/DisplayPortで接続出来るモバイルモニター、キーボードとタッチパッドが一体化した入力装置を接続してメンテナンスを行います。部屋が暑くなる方は先の写真のように超小型PCと同サイズのUSBファンを重ねて設置しておくと夏場も少し安心です。
PCクラスタ向けのデータ管理には専用のソフトウェアが必要です。スタンドアロンのデータベースは定期的なバックアップでデータを保全しますが、PCクラスタ向けの分散データベースはデータ本体を分割して複数の『レプリカ』としてサーバーに分散格納する『シャーディング』という仕組みで動きます。
これまで分散データベースにはNoSQLの『Elasticsearch』を使ってきました。しかしElasticsearchはKibanaなど同社のBIツールと連携して用いることを前提としており、無償の範囲では汎用的なJDBCコネクタを利用出来ないことなどから、次期のデータ基盤は分散RDBに替えようと思っています。
NoSQLはJSON&KeyValueでのデータ格納を前提としています。ログデータの蓄積に向いており柔軟なデータ構造に対応出来るという意味では優れています。しかし、データ分析の際はほぼほぼ表形式に加工して用いることやデータ格納時にデータ型をチェックしておかないと分析時に前処理で困ることが多いことなどから、私にとってはSQL対応の分散RDBでデータを管理するのが一番、という結論に至りました。
分散RDBは分散データベースの一種で、複数のサーバーにデータを複製して保存するシャーディングという技術を用います。サーバーの数を増やしてレプリカを再構築すれば自動的に新しいサーバーにデータが複製されますし、サーバーのうち1台が壊れても他のサーバーにレプリカが保存されているのでデータを失わずに済みます。
個人でもNASなどでRAIDを運用している方も多いと思いますが、NASそのものが壊れてしまうとデータはHDDからサルベージしなければならず、無事サルベージ出来るかも運次第、というのが現実です。ハードウェア障害時にもデータを実運用出来る形で保持するためには、PCクラスタでデータをレプリケーションして分散運用するのがオンプレで唯一の有効な手段と考えています。
このような技術は、大手クラウドでは既に当たり前のものとなっています。GoogleのCloud Spannerやデータ分析に特化したBigQuery、AWSのAmazon Redshiftなどはユーザーが意識しない形で巨大な分散データベースを構築しており、これによりペタバイト級のデータを扱えるとされています。データのレプリケーションもユーザーに意識させることなく複数のデータセンターに分散して格納されているため、データの堅牢性という意味ではクラウドが最強であることに疑いはありません。ただし、当然ながら堅牢な分だけお高いので、データ保全命でクラウドにビッグデータを置くかどうかは「お財布と相談」になります。
しかし、オンプレ用の分散RDBには従来、めぼしいものがありませんでした。オープンソースの製品もいくつか存在してはいるのですが、SQLの対応が弱かったりJDBCドライバで文字化けが出るなど汎用的なデータ基盤としては厳しいものがありました。開発元もアメリカではなく会社としての事業継続性も未知数、という印象。
ところが最近になって、マイクロソフトからAzure Database for PostgreSQL – Hyperscale (Citus) というクラウドサービスが出てきました。これ自体は他社クラウドの分散RDBと大差無いのですが、
など利点が多く「まさに決定的」という印象です。
マイクロソフトの藤田氏によれば「Citus Dataの創立者から聞いた話ですが、買収提案を受け入れた理由は、MicrosoftがOSSコミュニティーに最も貢献しているパブリッククラウドプロバイダーだったからとのことです」とのこと。ベンダーがここまで明言している以上は、CitusがOSSサポートを中止することは当分ないはず、です。
Citusを使うのはAzureが一番楽だと思いますが、Citusがオンプレで提供されている限り、その気になればAWSやGCPのVM上でもCitusによる分散RDBを構築運用できるはず、です。これはクラウドベンダーにロックインされた挙句、突然の大幅値上げで泣く羽目になっても逃げる余地があることを意味します。これがどれだけ重要なことかは、IT業界に長い方ならよくご存知でしょう。
我が家の自宅クラスタは、2022年4月末のUbuntu 22.04 LTSのリリースを待って全てのサーバーOSを入れ替える予定です。これに合わせて分散データベースもCitusに入れ替えたいと考えており、「全部これから」です。近い将来PostgreSQL自体も分散RDB機能を持つようになるかも知れませんが、それを待っていられるほど私の寿命は長くなさそうです。
データ活用の観点からも、従来kibanaやPythonなどに限られていた分析ツールがJDBC/ODBC対応の各種BIツールに拡がることが期待されます。無償で多機能なPower BI Desktopなどが使えるはずですし、PostgreSQL自体が持っているマテリアライズドビューなどの機能を用いてRDB側でクエリを高速化することも(スキル次第では)出来るでしょう。
これからマイペースで記事も投稿していこうと考えていますので、引き続きよろしくお願いします。
クラウドの無料インスタンスを利用している方の用途は、だいたいWordPressなどを用いた個人サイトかと思います。最近はメモリ１GBの無料VMが各社から提供されるようになり、個人サイトの運営はだいぶ楽になりました。私も、無料でこそありませんがAWS LightSailのメモリ512MBでさんざん苦労したWordPressを１GBに増やしたら安定した経験があります。
しかし、少し欲張ったとたんにメモリ１GBでも足りなくなってしまいます。自宅にもLinuxサーバーを置いている方は、だいたいこんな感じで
メモリ３２GB以上、プロセッサ8vCPUくらいはあるので、重いサーバーソフトを入れても「いきなり全く動かない」事態に直面することは無いと思います。しかしこの感覚でメモリ１GBの無料インスタンスを使うと大変なことになります……。
2年ほど前からツイートデータなどの蓄積・抽出にElastic Stackを使っています。全文検索エンジンのElasticsearch、データ前処理(ETL)ツールのLogstash、BIツールのKibanaが3点セットで構成されています。
今回、このうちLogstashだけOCIの無料枠VMインスタンスに設置を試みました。というのも、自宅の回線が低速・不安定なため各種情報サービスからAPI経由で安定してデータを取得するのが難しいからです。
ところが、データベース周りなどエンタープライズ系のツールは、複数のOSやプラットフォームで互換性を確保するため、たいていJava VM上で構成されています。まずJava VMを起動して、その上で各種アプリを起動する仕組みです。しかしこれがデカい……。
メモリ１GBのインスタンスにLogstashをインストールして起動したところ、またたく間にメモリがすべて食いつくされてしまいました😨
こうなるともう大変。sshでのログインすら出来なくなり、モニターを見ると再起動をかけるたびにOSがフリーズしているのです😭
私はメモリー極小のレンタルサーバー時代からLinuxを使っていたので、てっきりクラウドのインスタンスにもスワップメモリ(メモリが足りなくなったときに、一時的にデータをディスクに退避させてメモリ不足を防ぐ仕組み)が設定されていると思い込んでいました。
ところが、サーバー向けUbuntu Linuxのイメージは初期設定ではスワップが設定されていないのです。従って、メモリ使用量が1GBに達するとそのままOSがフリーズしてしまうことになります。
私は泣きながら再起動して速攻でsshしてLogstashをいったん止めた上で、スワップの設定を行い、なんとかLogstashの動作を安定させることが出来ました。
なぜ、Ubuntuサーバーでは初期設定でスワップが無いのでしょうか。理由はふたつ考えられます。
第一の理由は、『速度重視』です。Webサーバーなど多数のアクセスをさばかなければならないサーバーは、常に高負荷の状態にあります。データを頻繁にディスクに退避させると、メモリとの速度差のぶんだけサーバーの処理速度が落ちてしまいます。特に業務用途では避けたいところです。
第二の理由は、『ディスクの消耗』です。一般的にディスクはメモリーと比べて寿命が短く、頻繁にアクセスすると故障につながる恐れがあります。サービスダウンが許されない業務用途では、これも避けたいところです。
しかし、個人用途のサーバーはめったに高負荷になりませんし、遅くても我慢すればどうにかなります。しかも、遅いと言ってもハードディスクの時代とは違い、今ではSSDなので大して遅くありません。さらに言ってしまえば、ディスクが消耗しても困るのはクラウドサービス側だけです……💦
というわけで、
個人用途のクラウドインスタンスには遠慮なくスワップを設定しよう
というのが私の結論です。
無職の私は、生活のために100円でも出費を切り詰めなければなりません。WordPressでサイトを再構築した際も、AWSのLightSailは「月額 3.50 USD から」の安さが売りなので、迷わず月3.5ドルのコースを選びました。
しばらく様子を見ていましたが、1日のアクセス数が30人前後なのでサイトへのアクセス負荷は問題なし。その後、写真や動画を掲載するために別途CloudFrontでCDNを構築して大きなファイルを逃がしたため、ギリギリ乗り切れるだろうと高をくくっていました。
しかし、その考えは甘かったのです……。
しかし、サイトを整備してプラグインが増えてきたことから、プラグインの設定変更を伴うメンテナンス作業を行うたびに管理画面がフリーズ状態になり「サイトが落ちている」という警告メールがWordPressから届くようになってしまいました。
一般的なWebサーバーやデータベースサーバーなどが高負荷で落ちる場合は、使用メモリなどの設定を変えたりデータを整理することで負荷軽減が可能なこともあります。しかしプラグインは色々なベンダーから提供されている上に、ブラックボックスで処理内容がユーザーにはよく分かりません。個別の設定変更では解決が難しいので、泣く泣くLightSailのプランを月3.5ドルから月5ドルにアップグレードすることにしました。
LightSailの3.5ドルプランはメモリが512MBと「5年前のスマホかよ」という少なさです。LightSailのWordPressインスタンスはbitnamiスタックというシステム構成でOSはDebian Linux。GUIが無くCUI操作なので512MBでも動作はします。しかしギリギリなので、重い処理をするとメモリ不足で処理が止まってしまいます。CPUは遅くても待てば済むことが多いのですが、メモリ不足は致命的です。
今時のVPSではGCPやOCIなど大手がメモリ1GBのVMを無料で提供しています。プラグイン作者もメモリ消費を考慮してはいるはずですが、既に「WordPressを立てるならメモリ1GBがミニマム」と判断されていると思われます。ソシャゲの肥大化と同じですね😭
天下のAWS、WordPressでちょっと欲張ると3.5ドルプランでは管理しきれなくなることを知らないはずがありません。しかし実際には3.5ドルプランでWordPressインスタンスを立てられてしまい、私のように管理画面が落ちることになってしまいます。
これは、LightSailが『OS／アプリケーションスタック』と『インスタンスプラン』を一切紐づけておらず、全ての組み合わせでインスタンスを立てられるのが理由です。端的に言えば、プラン選択もアプリ選択も『自助』『自己責任』という考え方でサービスが構築されている、ということです。
WordPressはまだ512MBでも動きはしますが、ショッピングカートの『Magento』ではアップデートに2GBのメモリが必要で、512MBでは初期設定すらまともに出来ません(月10ドルのプランなら動くでしょう、たぶん)。このように、自分が使いたいアプリと用途でちゃんと動くミニマムのプランを見極めてから始めるのが基本です。
とは言え、サービスが落ちると致命的な企業サイトでなければ「とりあえず立ててみて、ダメそうならスナップショットを取ってアップグレードする」という「痛い目に遭って覚える」やり方もアリでしょう(負け惜しみ)。ボタンひとつでサーバーを落として引っ越せるため失敗のダメージが少ないのはクラウドの長所です。
というわけで、無職で経済的に厳しい折ではありますが、月3.5ドルのプランから月5ドルのプランに移行することにしました。
LightSailは、システムの再構築なしにプラン変更が可能です。具体的には、まず既存インスタンスのスナップショットを取ります。
スナップショットが出来たら、クリックして『新規インスタンスの作成』を選びます。
古いスナップショットを使うと先祖返りしてしまうので、アップグレードしたいインスタンスの最新のスナップショットであることを再確認します。
『新規インスタンスプランの選択』で、左から2番目の『$5 USD』のプランを選びます。メモリが1GBと倍増するほか、ストレージ40GB、転送量2TBと全体的にスペックが倍増します。
一時的に同じ中身のインスタンスが2つ併存する状況となります。固定IPアドレスが古いインスタンスに紐づけられているので、新しいインスタンスはまだ公開されていない状況です。
『静的パブリックIPアドレス』の管理画面で古いインスタンスから固定IPアドレスの割り当てを『デタッチ』で解除します。この操作に伴って一時的にサイトが落ちるので、アクセスが少ない時間帯に実施するのが無難です。
続いて、固定IPアドレスを新しいインスタンスに紐づけます。
アタッチが終わったら、Webブラウザでサイトが無事表示されていることを確認します。キャッシュの影響でサイトが落ちていても表示されてしまうことがあるので、動作確認は他のブラウザやスマホを使うかキャッシュを削除してから行うのが安全です。
インスタンスがふたつ併存した状態では二重に課金されてしまうので、古いインスタンスを削除します。インスタンスを削除すると自動スナップショットも同時に削除されるので気を付けましょう。
インスタンスを作り直すとスナップショットの設定も消えてしまいますので、作り直します。念のため、手動スナップショットも作成しておいた方が良いでしょう。
新しいインスタンスのメモリ使用状況を確認すると、メモリ1GBでも128MBしかメモリが余っていません。
スワップがあるとは言え、データがSSDに落ちると処理速度が大幅に下がってしまいます。スワップ処理がフリーズにつながることもあるので、やはり最低限メモリ1GBはあった方が良いでしょう。もちろん、その分お高くつきますが……😭
枯れた技術の入門記事で「今さら聞けない」を枕詞にしたものをよく見ますが、「本当に聞けない」のがセキュリティ対策です。なにせ「知らない」「やってない」ことがバレた時点で「セキュリティ甘々なサイト」と他所様に認識されてしまうのですから……。
この数か月で少しAWSとWordPressに詳しくなったので、復習がてら導入のアドバイス・コンサルティングを始めました。お客様のお話をお伺いしていると情報セキュリティへのご関心が高いようです。WordPressは有名CMSなので、セキュリティホールを突く攻撃から面倒くさいコメントスパム、フォームスパムまで日々痛い目に遭っている方が多いようです。
私自身は情報処理安全確保支援士(SC)の資格など持っていませんし、そもそもエンジニアですらありません(アドミン君でないとは言い切れませんが……)。従ってセキュリティを語る資格は無いのですが、現実問題としてウェブサイトを立てた瞬間からセキュリティのリスクと責任を負ってしまうのでどこぞの予約サイトのようにセキュリティを全く無視するわけにはいきません。
昔は二段階認証と言えばオンラインバンキングなど金融系が中心でした。しかし、ここ数年でセキュリティ事故による情報流出が多発し、IDパスワードが攻撃者に奪われてしまいました。
その結果、各種のサービスに不正取得したIDパスワードを使って侵入し不正送金などを行い、ユーザーが深刻な被害を受ける事件まで起こってしまいました。その結果、みんな大好きメルカリやYahoo!/PayPayを筆頭に、一般的なサービスでもすごい勢いでワンタイムパスワードによる二段階認証が普及しています。
二段階認証で幅広く使われている方式は、下記となります：
これらの方式をセキュリティ用語では『MFAデバイス』、特にスマホアプリによる方式を『仮想MFAデバイス』と呼びます。MFAはMulti-Factor Authenticationの略で、直訳すると『多要素認証』となります。
個人サイトではトークンやSMSによる認証は難しいので、3.の『スマホの認証アプリによる認証』に頼ることとなります。しかし、予備知識がないと「認証アプリってなに？」「どの認証アプリを使えばいいの？」と頭がはてなマークで埋め尽くされてしまいます。
結論から申し上げると、二段階認証で使われるワンタイムパスワードの方式には共通規格があります。『RFC 6238 – TOTP: Time-Based One-Time Password Algorithm』というもので、ざっくり言うとSSLなどと同じレベルです。
従って、AWSやWordPressに二段階認証を入れようと思ったら、まず最初にやることは『TOTP対応の認証アプリ』のインストールです。「TOTP対応なら、どれでも良い」ということです。Googleで検索してみると、下記のような認証アプリがヒットします：
実際に認証アプリを使う前に、絶対に確認しておくべきことがあります。スマホをなくしたり壊したりしてしまったら、アプリ認証も出来なくなってしまいます。従って、二段階認証を入れる前に、必ず認証アプリの機種変更方法を把握しておかなければいけません。私が使っているIIJ SmartKeyで機種変更を行うための本人確認は、SMS認証を用いています：
これが意味することは、「電話番号を変えてしまったら認証アプリの機種変更が出来なくなり、ワンタイムパスワードも最終的には使えなくなる」ということです。アプリによって本人確認の方法は異なる可能性がありますが、頭の片隅に置いておいて下さい。
セキュリティ重視の方は、AWSでもユーザー登録時に付与されるルートユーザーではなく別途IAMユーザーを作成して運用していることも多いかと思います。しかし当然ながら、仮にふだんは使っていないとしても、ルートユーザーも二段階認証を入れないとIDパスワードを抜かれたら終わりです。
WordPressは一般的にブログなどを公開するウェブサイトと同じサーバーに管理画面があり、ウェブ上で記事を編集します。WordPressは5.xの時点では本体に二段階認証の機能がないため、サードパーティーの認証プラグインを入れる必要があります。WordPress 6.xでは絶対に改善してもらわないと困る状況ですが、いま出来ることとしてWordfence Security – Firewall & Malware Scanを入れています。
正直、CMS全体の動作に大きな影響を与えるセキュリティ関連でサードパーティーのプラグインを入れるのは怖いので、「インスタンスのバックアップを取った上で恐る恐る入れている」というのが本音です。
私自身は無職でノマド()なのでWordPressに接続するIPアドレスを固定するのが難しい状況ですが、企業ユーザーの方などでIPアドレスの固定が可能な方は、IPアドレスの指定による管理画面へのアクセス制限が可能かどうか、併せてご検討されるのがよろしいかと思います。
正直、情報セキュリティ関連の投稿は、自分の手口を明かしてしまう上に本職のエンジニア様などによる恐ろしいマサカリにも晒されているので「書きたくない😭」のが本音です。
しかし、非エンジニアの方が多く利用しているWordPressがセキュリティ面で脆弱な状況に置かれている現状は非常にまずいと感じたため、敢えて二段階認証の投稿をするという決断をしました。
このような状況ですので、セキュリティが本職の皆さまが当記事に問題を発見した場合は、何卒、優しくご指摘ください。ご指摘そのものは、当サイトのセキュリティ改善につながるので歓迎です。
「自前主義で行こう」と独自ドメインでサイトを再開した私ですが、動画はYouTube先生に依存しています。動画はファイルが大きいので自分のサイトに置くのは正直怖いのですが、自前主義をテーマにしてみたので動画もサイトに置いてみることにしました。
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に置けば、万が一アクセスが増えてもサーバーが落ちる事態は防げそうです。
「でも、お高いんでしょう？」
特に仕事でアカマイなどのCDNを入れたことがある方は、とても、とても心配になると思います。実際、企業向けのサービスなので多少の出費は覚悟する必要があります。具体的には、
日本向けの料金が1GBあたり0.114ドルです。20MBの動画が月間1万再生されると約200GBになりますので、月22.8ドルになります。
「やはり、お高い……」
しかしここはぐっと歯を食いしばって「1万再生もあれば22.8ドルくらいの収入は期待出来るだろう」と前向きに考えます。
その後試行錯誤した結果、なんとか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 cloudfrontX-Cache: Hit from cloudfront
次回以降、どのような設定を行ったかをゆっくり書いていきたいと思います。
AWS LightsailのWordPressには通常版とマルチサイト版(WordPress Multisite)の二種類があります。どちらを選んでも致命的な影響はなさそうですが、複数のサブドメインでWordPressを展開したいならMultisiteを選ぶ余地があります。
上図がWordPress Multisiteと一般的なWordPressの違いです。
「① 一般的なWordPress」では複数のサブドメインを展開するために同数のLightSailインスタンスを作る必要があります。インスタンスごとにリソースを確保するので、リソースを使い切らない小規模のサイトでは割高になります。一方で、特定ドメイン用のインスタンスを停止しても他のサブドメインに影響が無いと言った利点もあります。
「② WordPress Multisite」では単一のLightSailインスタンス内で複数のサブドメインを展開出来ます。プラグインなど管理が一元化されるほか、LightSailインスタンスをひとつしか起動しないのでアクセス数が少ないうちは料金的にお得になります。ただし、一般的なWordPress用のプラグインが使えなくなる（有償契約が必要など）ことがあるため、初心者やサブドメインの展開予定が全くない場合は避けた方が良さそうです。
また大規模なアクセスを期待出来るサイトの場合は、LightSailインスタンスのリソース制約があるのでWordPress Multisiteは避けた方が良いでしょう。「そもそもLightSailで大規模サイトを運用するのか？」という話もありますが💦
今春から長期の仕事を探しています。40代なので「採用はちょっと……」という人事ご担当者様も多いと思います。正直20代の元気な方のような伸びしろはありませんが、当サイトでスキルレベルが適切と思われた方は、お気軽にお声がけ頂ければと思います。下記フォームかツイッター(https://twitter.com/masarumkt)、あるいはメール(masapon05 アットマーク gmail.com)でご連絡下さい。
ウェブマーケ畑の人間なら1日も早く導入したいSSL。個人サイトということもあり、定番の無償SSLであるLet’s Encryptを導入しました。LightSail環境で立ち上げたWordPressなので一般的な環境と少し異なるので、メモしておきます。
Generate And Install A Let’s Encrypt SSL Certificate For A Bitnami Application
bncert-toolというBitnami専用のツールをAWS Lightsailのコンソール上で行います。設定自体はとても簡単ですが、certbotの手順とは異なるので注意が必要です。
certbot instructions(一般的なdebian – apacheの場合はこちら)
ブログのようなオープンなサイトではSSLはセキュリティ面で必須とは思いませんが、Webブラウザで派手な警告が出ること、Google検索などで低評価を受けることを考えると個人サイトでも不可欠との認識です。
技術畑ではない人にはどんどん敷居が高くなる独自ドメインでのサイト構築ですが、何とか時代の変化を追い続けてサイトを延命することには自身のスキル維持という意味でも重要と思います。
