Tag Archives: wordpress

GCP運用の諦めとIDCFへの帰還

IDCFクラウドが個人向けサービスを閉じるとのことで急遽GCPへ移行した。GCPでの運用は、無料のf1-microインスタンスとプリエンプトなg1-smallインスタンス2つを使う構成。常時稼働のf1-microをディスパッチャにしてg1-smallにphp-fpmやmysqlなどの実体プロセスを置く。しかし、プロキシ的なプロセスのみのf1-microが安定しない。一定期間経過すると(おそらくスラッシングで)沈黙してしまう。いろいろ工夫はしてみたんだけど、残念ながら改善には至らなかった。 ... 続きを読む

WordPress on Google App Engine by php72

前回、Google App EngineからDBへの接続部分を検証したので、今回は実際にGAE上でwordpressを動かしてみる。DBはGCE上のMySQLでもCloud SQLでもどちらでもよいので好みで。ただ、f1-microでMySQLを動かすのはあまり安定しなかったので、GCEでやる場合でもg1-smallくらいは使った方がよさそう。そうすると金額的にはf1-microのCloud SQLでいいかなって感じになるね。g1-smallのプリエンプトインスタンス2つでレプリさせる形でも動かないことはないと思うけど。... 続きを読む

wordpress キーボード ショートカット 実装

最近はG Suiteだけでなく、ConfluenceやJIRAなど、ブラウザでドキュメントを編集する事が多い。その際に何気なく便利に使ってしまうのが、キーボードショートカット。中でも『E』を押して編集モードに入るのが癖になってしまっている。自分のwordpressの記事ページを見ていても、ついついEボタンを押してしまう始末。それで編集画面にいけないことが、逆にストレスになるほど。こういう状況がしばしばあったので、今までも何度かキーボードショートカットへの対応を検討したことがあった。... 続きを読む

Google App Engine 検証 GAE+GCE(MySQL)

年度内くらいにIDCFクラウドを追い出されそうなので、無料利用枠の充実しているGCPへの引っ越しを試みる。GCPでwordpressを動かすには、GCEで普通に構築するか、GAEで動かすか。どちらも1インスタンスは無料なので、PHPをGAEで動かして、DBをGCEで動かせば完全無料じゃん、という安直な発想。GCEは今までとそれほど変化はないだろう。NICをブリッジ化できなかったり、フローティングIPが使えなかったりで、多少の構成変更は求められるが。一方のGAEは触ったこともないので、こちらから使ってみる。... 続きを読む

IDCFクラウド終了? 移行先はGCPかAWSか

年末に舞い込んだIDCFクラウドからのメールに驚いた方も少なくないはず。内容は個人向けサービスを年度内に終了するというもの。見返してみると2年近くIDCFクラウドにはお世話になっている。これから安価なクラウドサービスとして利用していくつもりだっただけに、この通知へのショックは大きい。想像以上に期限も短いので、何はともあれ急いで引っ越す準備をしなければならない。引越し先としては他のワンコインクラウドか、GCP/AWS等の大手か。正直仕事で使うことなさそうなクラウドは遠慮しておきたい。... 続きを読む

WordPress 5.0 更新と wpautop 障害

たまにはタイムリーなネタを。Wordpressの5.0が遂にリリースされた。さすがにメジャーバージョンアップに当たるので、事前にソースとDBをバックアップしてから作業を始める。久々にサーバを覗いてみると、ファイルシステムとして使っているGlusterfsが片肺になってて、Split-brainしまくり。ここだけまだGlusterfsのバージョン上げてないからSplit-brainの対応が面倒なんだよね。。。IDCFが個人向けサービスやめるとか言ってるから、その移行の際にまたアーキテクチャ変えてみたいな。おっと、脱線。... 続きを読む

MariaDB Galera Cluster の Split-Brain 問題

MySQLのマスター・スレーブ構成からMariaDBのマルチマスター構成に移行してから、DB側の運用は非常に楽になった。wordpressに関して言えばWeb+DBのセットが2つあるので、その単位でラウンドロビンしている限り、まったく問題なく複数台構成を取れる(Webの接続先DBがlocalhostという状態)。しかし、DBのみを分離してreadもwriteも関係なくラウンドロビンさせると、どうしてもdead lockが頻発してしまって不都合が起きやすい。... 続きを読む

IDCFクラウド wordpress 障害対応

今までVPSやGMOクラウド時代に、wordpress運用で障害らしい障害は起こしたことなかった。サーバ運用が硬直的だったので大きな変更を行えなかったというのも理由の1つではあるが。IDCFクラウドへの移行後は、vmwareノード上にlxcコンテナを作成して、そのコンテナ上でwordpressを運用している。更にwordpressのphp部分はGlusterFSで、データ部分はMariaDBで2台を同期している。これだけ構成を複雑化させてしまったせいかもしれないが、遂にwebサーバにて予期しない障害が発生した。... 続きを読む

IDCFクラウド wordpress 複数台構成 構築

wordpressの運用は既に8年近くに渡っているが、まともな複数台運用が実現できていなかった。大したコンテンツではないが、それでもクラウド費用くらいは稼いでくれるので、出来る限りダウンタイムの少ない運用を行いたい。その結果としてwordpressサーバは大胆な停止が行えなくなり、構造変更がまともに出来ず、古臭い構成に成り下がってしまう。クラウドに移行した一番のモチベーションは、複数台構成にすることで頻繁に更新出来る環境を維持したかったからだ。... 続きを読む

DBサーバ 比較 MySQL vs MariaDB 移行編

昔ながらのmaster/slaveでMySQLを運用してきたが、最近は大分考えが変わってきた。少なくとも自分の趣味環境においてはパフォーマンスより運用の利便性を優先しないと作業の生産性が改善しない。MySQLにおいてmaster/slave構成を取ってきたのは、趣味レベルにおいてはわずかでしかない性能を気にしての事。GMOクラウドからIDCFクラウドに引っ越して内部通信品質も大きく改善したので、今回はwordpressのDBをマルチマスターとなるMariaDBのGalera Clusterに移行してみる。... 続きを読む

wordpress 修正のプラグイン化

wordpressの細かい修正を割りとラフにハードコーディングしてきたんだけど、さすがに量も増えてきたし、バージョンアップも多いし、毎回直すのが億劫になってきた。という訳で、いい加減バージョンアップに影響を受けない修正方法を検討する。何となく想像は付いていて、専用のプラグインを作り、コアモジュール以外の部分で修正を行えるように準備する。そのプラグインの中でwidget作ったり、パラメータを上書きしたり、実現したいカスタマイズを実装していく。... 続きを読む

wordpress マルチサイト化 別ドメイン編

前回、検証機でのマルチサイト化に成功したので、同じ設定を本番機に適用する。その上で、サブドメインによるマルチサイトを別ドメインによる複数ドメインのマルチサイトに切り替える。稼働中のサーバに対して変更を実施する場合は、変更適用後に現行サービスの復帰を最優先する。検証機でマルチサイト化後に現状復帰のため必要だった作業は以下。... 続きを読む

wordpress マルチサイト化 サブドメイン編

久々にwordpressネタを。とある事情でもう1つサイトを作る必要が出てきた。別に何で作ってもよかったんだけど、最近はすっかりwordpressを使い込み始めているし、環境も揃っているから、wordpressでささっと作ってみる事にした。当初は律儀にもう1つwordpress環境を作るつもりだったけど、コードの二重修正とか両者の運用的な同期とか手間の方が大きそうなので、マルチインスタンス的なことが出来ないか調べてみた。... 続きを読む

wordpress チューニング (6) nginx編

長々と続けてきた、wordpressチューニング。当初3秒だった処理速度も前回の改善で300msec前後と10倍ほどの高速化に至った。あと残されている改善余地はwebサーバくらいなので今回はnginxを見ていく。webサーバのチューニングにおいて、httpdそのものの処理速度はあまり問題にならないので、通信速度についての改善を考えてみる。nginxのレベルで通信速度をチューニングするとなると、最初に思いつくのはHTMLやcss等のテキストコンテンツの圧縮。設定はそれほど難しくなくnginx.confに以下のような設定を追加する。... 続きを読む

wordpress チューニング (5) plugin編

前回までで、当初3秒だったトップページの表示は400msec前後まで改善した。今回はwordpressのプラグインで処理速度を改善できないか見ていく。クラウド環境の場合、リモートのDB通信がボトルネックになることはわかっているので、出来ればwordpressのロジック内でDBの値をキャッシュ出来ると望ましい。reverse proxy等でページそのものをキャッシュする事も同じような効果を得られるが、その場合はログイン時の出し分けなどが難しくなってしまうことになる。... 続きを読む

wordpress チューニング (4) php編

前回、php-fpmということでサーバプロセスを中心に見てみたが、今回はphpそのものについてのチューニングを考える。今更だけど、phpは仕事で扱った事ないので基本的には門外漢。適当にぐぐってみたところ、opcacheという機能によるチューニングが筋よさそう。opcacheはphp5.5から使えるようなので、現在のphp5.4を一旦消し去って、remiリポジトリからopcacheも加えた形でphp5.5を入れ直す。... 続きを読む

wordpress チューニング (3) php-fpm編

前回のmysql編に続き、今回はphp-fpmを見ていく。apache時代はmod_phpもあったが、nginxの場合はphp-fpmを使う事になる。まあ、mod_php使った場合のリソースのばらつきもひどい有様だったので、リソースの効率的な再利用という意味でphp-fpmの選択は順当と考えている。php-fpmの設定はほぼデフォルトのままだったので改善余地がないか探る。... 続きを読む

wordpress チューニング (2) mysql編

前回のOS編はほぼ改善なしで、相変わらずトップページが3秒かかる状態。早速今回はDB周りで改善余地がないかを見ていこうと思う。まずDBがローカルかリモートかで変化するか確認したところ、mysqlをwordpressが動いているサーバと一緒にするだけで、処理時間が1秒超縮まり、2秒弱で処理できるようになった。もともとクラウドの内部通信は品質低いと思っていたが、これほどとは。。。... 続きを読む

wordpress チューニング (1) OS編

wordpressを自宅環境からクラウド環境に移設した。クラウド上でwordpressを本番稼働させながら、諸々の整備を進めているため、わりと頻繁にchef-clientを実行したりしているのだが、その際のHTTPレスポンスが著しく劣化しているような気がしていた。実際、chef-clientしつつブラウザで触ってみると、ほぼレスポンスできてないに等しい状態が数分続く事になっている(chefの処理も遅い)。... 続きを読む

Count per Dayのカウントを日本のみに

その後も必要に応じてちょこちょこwordpressのプラグインを追加している。それなりに作り直すとやはり気になるのがPVで、自分について言えばアクセスログでも確認できるんだけど、やはりカウンター的なものを設置したくなる。いろいろ調べてみた結果、見た目も含めて選んだのがCount per Day。自分の場合wordpressの運用は初めてではないので、何となく前も使ってたような。閉鎖する前に使っていたプラグインのリストをメモっておけばよかったな。... 続きを読む