ローカルPCとリモートサーバの役割分担
（約 4,800文字の記事です。）
久々にTickTick以外の日記。WordPressとPCの話。
PC＝ローカル、サーバ＝リモート
ま、用語の定義だ。ネットワークという媒体を基準として、デスクトップPCやノートPCのほうをローカルと言い、メディアを保持しているサーバ側をリモートと言うらしい。
けどまぁ分かりにくいのでこの記事ではPCとサーバで話をしちゃいます😊
PCとサーバというと、例えば、動画を見るデバイスがPCであり、サーバ側というとYouTubeなどの動画配信サービスがあるところ、というイメージだろう。それで問題ない。
だがそれは「サービスを利用する側」の視点だ。
私の場合はコンテンツを提供する側なので、その理解だけでは色々と足りない。
PCは複数台の編集機器、サーバはコンテンツ置き場
まずPCは複数台が前提となる。自宅のデスクトップPCと、ファミレスなどに持ち込むノートPC、あるいはスマホでも編集できる場合もある。なのでローカル環境は複数ある。
実はこれだけでも頭の痛い問題が発生する。
PCが複数あると、どのPCで作業したかによってPC内のHDDやSSD内のデータがPCごとに異なってしまう。そして出先で「あのデータは自宅PCにある」と気が付いても後の祭りだ。
同期と一口に言うけれど
ではGoogleドライブなどを使ってデータを同期させればいいじゃない？確かにその通りだ。例えばOffice系やAdobe系は確かにそれができる。というのもソフトウェア側が同期に対応するように作られているから。
そして同期に対応していないソフトの場合、単純にGoogleドライブの同期フォルダにファイルを置けばいいかというと、そうでもない。予期せぬ不具合の原因がてんこ盛りだ。同期のタイミングとソフトがデータを書き換えるタイミングがバッティングしたり、ソフトがデータファイルについてOS側のアクセスを禁じる排他アクセスになっていたりなど、トラブルの原因は沢山考えられる。製作途中のデータが壊れて「アクセスできません、開けません」になってからでは遅い。
対策としては作業前に同期を一時停止し、任意のタイミングで一気に同期させる、くらいしか手がないだろう。
なので複数PCで「常に同一なデータを保持させる」というのは、結構面倒くさい。でもこれを放置すると、1つの作業の流れが「今使っているPC」によって一気に作業できるか、帰宅してから作業の続きになるかが変わる。こういう部分が作業効率に大きく影響を与える。
他にも、ソフトの設定を変えたときも大変だ。ソフト側が設定ファイルのExport/Importに対応していればまだ楽だが、デスクトップPCとノートPCとでフォルダ構造やパスが異なってくると、それでも気楽に同じ設定にはできない。多少は手作業でデータ他の修正が必要になる。
自宅PCで設定を変えたものを、ノートPCでも設定し直しだ。もし勘違いして設定が違うと、結果が異なる場合もある。その設定の違いに気が付かないと泣きを見ることも。
だから設定変更のたびにノートPCとデスクトップPCを並べて比べて設定しなければならなくなる。その作業は結局は自宅でしかできない作業になってしまう。
要するに何だかんだの変更についてとても億劫になるのだ。結果、動きが鈍化する。柔軟な対応を取りにくくなる。
サーバ管理もまた面倒臭い
そしてサーバだが、利用する側ではなくてサービスを提供する側で考えると、これまた苦労が大分増える。まずは見た目、UIの構築だ。わかりやすさ、アクセスしやすさ、読みやすさ、色々と気を使う。だが見た目で分かる部分はまだいい。
次に考えることはバックアップなどの保守だ。自分で間違ってデータを壊しても復旧させられるだけの備えが必要だ。そしてサイバー攻撃などの他者からのデータ破壊でも同様に復旧させる必要がある。なのでセキュリティ対策も必要だ。
さらには定期的にコンテンツのアップデートも必要だ。新規投稿や過去記事のメンテだ。
コンテンツの提供側になるだけでこんなにも大変なのだ。
もう大部頭の痛い問題だらけなのだが、ここでようやく本題に入っていける。
サーバのバックアップはローカルPCか別サーバへ
サーバのバックアップは、まずはサーバ内のストレージに最速で保存できる。だがそれだけではストレージをN倍も消費することになる。Nとはずばりバックアップの世代数だ。10回バックアップを取れば容量は11倍以上必要だ。すぐにストレージが一杯になる。
具体的にはブログの画像のバックアップが問題となる。一番ファイル容量を占めるメディアだ。それに対してテキストやWordPressの設定ファイル群はさほどでもない上に圧縮率が高いのでほとんど問題にならない。
そして無料のバックアッププラグインでは画像ファイルの差分バックアップに対応していない。そういう機能はたいていは有料版でしか提供していない。
またFTPで手動で同期させる場合、つまりFTPソフトに差分バックアップの処理をさせる場合、FTPソフトはそれで行けるのだが肝心のサーバ側が「自分自身に回帰するようなFTPソフトのファイル転送をNGとしている」ことが多い。こうなるとサーバ内で画像ファイルの差分バックアップが現実的に不可能になる。
なのでサーバの画像バックアップは必然的にPCか、別のサーバにバックアップすることになる。
もうこの段階で、普通の人がサービスを受ける側でいる場合の「PCとサーバ」の関係とは考え方が全く異なる。普通の人は「PC＝サービスを受ける手段であり、サーバ＝サービスを提供する主体」という考えになると思うが、サービスを提供する側からすれば、
PCは編集手段、サーバは完成品を保持させる場所
またサーバは編集機能も提供するものでもあり、PCはそこへのアクセス手段
サーバのバックアップ先はPCまたは別サーバ
PCは複数あっても、PCで保持している内容は同一であってほしい
複雑さが2のN乗で膨れ上がっていくのだ。
全てを解決するためには「PCとサーバの双方向の連携」が必要
サービスを利用する側からすれば「サーバからPCへ」の一方通行でいい。シンプルだ。だがサービスを提供する側からすればPCとサーバの双方向でやらなければならないことが山ほど出てくる。
そしてそれを完璧にこなさないと、これまでの問題を解決できない。実はここに2週間ほど取り組んでいる。
複数PC間の同期もPC1⇔サーバ⇔PC2
分かりやすいのがGoogleドライブによるフォルダ同期だ。仮想HDD領域を同期させることになる。これはファイル単位での同期に丁度いい。サーバはGoogleドライブというサービスということになる。当然ながらWebブラウザからでもアクセスできる。
だがこれではWordPressなどの自前のサーバとPC1, 2はつながっていない。
同一なファイルは複数じゃなくて1つであるべき
PC1または2で作った初稿の画像データをWordPressにUPしたとし、2ヶ月後に第2稿を作ったとしよう。PC1, 2は同期しているのでどちらで第2稿を作成しても問題ない。
だがWordPressには第1稿と第2稿の2種類のファイルがUPされている。ここで第1と2が「内容が異なっている」場合にはまだいい。同一ファイルを、勘違いなどで別々の時期にUPしてしまった場合、同一ファイルが複数WordPressサーバ上にできてしまう。こういうのが厄介だ。無駄にストレージを消費するだけでなく、1つに統一するときにもリンク切れのリスクや統一作業で神経を使う部分がとても増える。
基本的には「同一内容なものは1つのみ」であるべきなのだ。そうでないとメンテ時に差し替え作業が何度も発生したり、同一だと思ってコピーしたら実は微妙に違っていて、気が付けば何種類もの「似て非なるもの」がストレージ上に散見されるなんてことにもなりかねない。
つまり、どのPCで作業しても、いつWordPressにUPしても、重複するデータが存在せず唯一であることを保ちつつ、修正や変更作業をしたあとでも常にデータの唯一性を保ち続けるための仕組み、これが必要なのだ。
5つのサーバと2台のPCでファイルの唯一性を保つ
ここまででサーバ側はWordPressのみで話したが、私にとってはこれだけじゃない。note有料マガジン、note投稿、BOOTHの商品ページ、ArtStationの商品ページ、今はまだGumroadもある。
そう、サーバは1つどころか、5つもあるのだ😭
なので、複数PCと5つのサーバについて、1つのファイルの唯一性を保つためには、きちんとファイル管理のワークフローを作る必要がある。2つのローカルPCと5つのリモートサーバとの関係について、どのサーバについても同一手法でファイルをやりとりできるための仕組み作りが必要だったのだ。
これの構築に2週間かかったわけ。
今日、ようやく論理的な仕組みが完成し、テストとしてWordPressの画像ファイルの管理を始めたところだ。今のところ上手くいきそうな予感がある。
肝はCMSとしてのWordPress
ブログの仕組み作りだとかSEO対策だとかアフィリエイトがしやすいだとか、そういう表面的なことじゃなくて、本質的に「ファイルを管理する仕組み」としてWordPressを使うことにした。主にメディアライブラリの持つデータベース機能と、ブログ機能のためのカテゴリ分け、そこへの効率的なアクセス手段としてのブログUIを使う。
なので読者に対してはWordPressのブログ機能を使うのはもちろんだが、自分自身にとってもメディア管理のUIとしてもブログ機能とカテゴリ分けを利用するのだ。
WordPressへ非ログイン状態では読者用UIであり、WordPressにログイン後は管理者向けUIとして管理者自身もWordPressでメディアを管理する。どちらもユーザーのためのシステムとして利用可能だ。
そしてバックアップとしてはWordPressの標準機能である時系列の画像ファイル管理で十分だ。だがそれでは管理者からすればとても扱いにくい。そこで画像にアクセスしやすくするために「エクスプローラーのようにメディアライブラリを扱える」FileBirdプラグインを導入している。これで「人にとって利用しやすく」なった。有料版だがもう十分に価格以上の効率を手に入れた。
バックアップの冗長性と、ファイルの唯一性、ローカルとリモートの利便性。これらのうま味を引き出すのが大変だった。
だからワークフローの構築にとても時間がかかったが、ここから得られる効率も桁違いに上がる。この仕組みを整えてから、Zbrushプラグイン開発やBlender、3DCGに戻りたいと思っている。
今は壮大な、入念な、大規模な下準備の最中なのです😊
今日は執筆時間を45分オーバーの大作日記となってしまった（笑）
今回の創作活動は約1時間30分（累積 約3,173時間）
（865回目のnote更新）
筆者はAmazonアソシエイト・プログラムに参加しています。（AmazonアソシエイトとはAmazon.co.jpの商品を宣伝し所定の条件を満たすことで紹介料をAmazon様から頂けるという大変ありがたい仕組みのこと。）
以下のリンクを経由してAmazonでお買物をするとその購入額の1～3％ほどのお小遣いが私に寄付されます。誰が何を買ったという情報は私には通知されませんのでご安心下さい😊 以下のリンクを経由して頂ければ紹介商品以外のご購入でもOKですよ～。
読んでくれてありがとう。気長にマイペースに書いてます。この出会いに感謝😊