カテゴリー別アーカイブ: サイト運営

lsyncd でファイル変更監視して、S3にアップロードする

WordPress のメディアファイルを自動でバックアップしたり、CloudFront のオリジンにするために wp-content/uploads/ の中身を S3 にアップロードするようにしたいなぁとか言う要望が結構あります。
特に AutoScaling 構成にする場合は、ソースファイルについては git リポジトリなどで管理すればいいですが、ダッシュボードからアップロードされるメディアファイルについては git リポジトリに含めるわけに行かないっすよね。
そんな時、僕の作ったプラグイン絡新婦とか、Amazon S3 for WordPress with CloudFrontとか使うわけですが、なんと 4.3.x 系ではちゃんと動かないような気がするんです

まぁ、僕が絡新婦をメンテナンスすればいいのですが、最近 php プログラム書くの辛いので代替手段として lsyncd でファイル変更を監視して S3 に自動アップロードするようにしてみました。
参考URL: lsyncdをrsync以外の用途で使う – Qiita

続きを読む

AWS WAF で CloudFront 環境にIPアドレス制限を設定する

本番環境で CloudFront を使用しているため、ステージング環境でも CloudFront を適用したいとかって要望は多々あると思います。
ただ、ステージング環境なんで全体に公開はしたくない、IPアドレス制限とかかけたいってなりますよね。
そんな時、今までは署名付きURLとか署名付き Cookie とかで対応せざるを得ませんでした。

参考URL

結構、めんどくさい。

そんな、僕達のために re:Invent 2015 に合わせるように発表された新サービス AWS WAF という救世主が現れましたよ。
この記事では AWS WAF を使用して、IP アドレス制限された CloudFront ネットワークを作成する方法をざっくり解説してみます。

続きを読む

dogmap.jp を t1.micro から t2.micro に変更してみました

AWS から 7/2 に新しいインスタンスタイプ T2 インスタンスがリリースされました。
【AWS発表】バースト可能な性能を持つ新しい低コストEC2インスタンス

dogmap.jp は、網元の実証実験も兼ねて、網元の t1.micro インスタンスで稼働させているのですが、アクセスが集中して負荷が高まってバーストした後、一定時間極端に性能が悪化するという問題がありました。
# これは t1.micro インスタンスの特性です。
これ結構辛くて、表側では Nginx のリバースプロキシキャッシュでなんとか凌いでいても、WordPress のダッシュボードにアクセスできないとかの状況に陥ることがしばしばあったんですよね。

T2インスタンスでも t1.micro 同様に負荷がかかったときに自動的にバーストします。
ただし、バースト可能な時間には制限があって、これを管理するために新たに CPU Credit という仕組みが追加されました。
簡単に言うと

  • 負荷が高くなく CPU がベースライン性能にとどまっている場合、CPUクレジット残高が貯まっていく
  • 負荷が高まった場合、CPUクレジットを消費してバーストする
  • 1CPUクレジットで1分間バースト可能
  • CPUクレジット残高が無くなった場合は CPU 性能はベースライン性能にとどまる
  • 未使用のCPUクレジットは、最大24時間有効

という感じらしいです。

名前 vCPUs ベースライン性能 1時間あたりのCPUクレジット
t2.micro 1 10% 6
t2.small 1 20% 12
t2.medium 2 40% 24

CPUクレジット残高については、Cloud Watch で確認することができます。
「CPU Credit Usage (使用量)」「CPU Credit Balance (残高)」という項目が追加されているので、そちらを参照してください。

2014-7-18 追記
Amazon MarketPlace からも HVM 版の網元AMIが利用できるようになりました。
WordPress powered by AMIMOTO (HVM)
t1.micro などの m1 インスタンスなどの HVM に対応していないインスタンスタイプはご利用になれません。
そちらが必要な場合は、従来の PVM 版をご利用ください。
続きを読む

Web サイトのメンテナンス中画面の出し方

しょっちゅう必要になるので、メモ書き程度に
参考にしたのは、以下の URL です。

前提としてメンテナンス中画面として表示する際に使用する html は以下のファイルを使うものとします。

  • maintenance.html
  • style.css
  • /img/corp_logo.png

また、以下の IP アドレスからのアクセスは管理者からなのでメンテナンス中画面を表示しないものとします。

  • 192.168.0.4
  • 192.168.0.5

続きを読む

MySQL バイナリログからデータを復旧

MySQL で作業してるときにうっかりオペミスしてしまったときの対処方法。
作業前にダンプ取ってて、作業終了後すぐにオペミスに気づいた場合は、そのダンプから戻せば良いですが、ダンプ取ったのが結構前だったとか、オペミスに気づいたのが時間をおいてからだったとかって時の復旧方法です。
前提条件として、以下の状況だった場合のみです。バイナリログを取ってない場合はあきらめましょう。

  • バイナリログを取っている( /etc/my.cnf で log-bin=mysql-bin とか設定してある )
  • mysqldump 等でバックアップしている
  • バックアップ時点でのバイナリログの書き込み位置を保存している。またはバックアップした日時が特定できる

参考 : unoh.github.com by unoh

続きを読む

Monit でプロセス監視 ( WordPress Advent Calendar 2013 全部オレ 20日目 )

WordPress Advent Calendar 2013 全部オレ 20日目のできる限り俺です。

WordPress を運用するサーバでは、Nginx や Aapche などの Web サーバ、MySQL、fastcgi を使っているのならば php-fpm などのプロセスが稼働しています。
夜中だとか旅行中にこれらのプロセスが落ちてしまうとサイトに繋がらなくなってしまうこともあります。
そういった障害を検知し、復旧するための様々な障害検知を行うツールが存在するのですが、今回は Monit の紹介をしようと思います。
これはプロセスを監視して異常を検知したらメールを出したり、自動的に再起動したりしてくれる便利なツールです。
続きを読む

さくらVPS512で、Yahoo!砲食らっても WordPress を平常運転させるための設定

2010年の年末に、「カイ士伝」のさくらVPSへの引っ越しを手伝ったわけですが、その後も元気にサーバは動き続けているようです。
引っ越し当初は、Web サーバとして lighttpd を導入してたんですけど、僕の個人的な好みがかわって、途中で Nginx に切り替えました。
特に大きなトラブルもなくサクサクと動いてたようですが、昨日突然の Yahoo!砲で、平常時の数倍のアクセスがあったようです。

Yahoo!砲くらったけど月額980円のさくらVPSとチューニングでサーバー落とさず乗り切ったよ – カイ士伝

ただ、アクセスが大量にあった初日(1記事に5.5万PV)にもサーバ負荷が高くなってるとか気付かずに、余波でちょっと多くなってた翌日(1記事に1.3万PV)に気づいたというくらいの平常運転っぷり。
Nginx 痺れますわー。

僕は、カイ士伝の WordPress ダッシュボードにログインする権限もらってないんで、プラグインとかどんなのが入ってるか知りませんので、バックエンドのサーバ環境についてだけ。
たぶん、WP Super Cache とかのキャッシュ系プラグインは使ってないと思うよ。
続きを読む

GlusterFS で分散ストレージ環境を手に入れる

さて MariaDB Galera Cluster で DB を冗長化したら、次はファイルも冗長化したくなりますよね?
そこで、使えるのが分散ファイルシステム GlusterFS です。
GlusterFS は UserLand で動作する FS ベースのファイルシステムで、自動復帰・ミラーリング/ストライピングを行うことができます。
サーバからは Glustefs Native Client や NFS でマウントして使用することができます。
GlusterFS でボリューム作っておいて、それを Web サーバでマウントして使えば、簡単に Web サーバをスケールアウトできて、嬉しいことこの上ないですね!

そんなわけで AWS で GlusterFS を試してみたので、やりかたを書いておきます。
続きを読む

MariaDB Galera Cluster による DB サーバの冗長化

さくらインターネット研究所さんの「MariaDB Galera Clusterを試す」という記事を読んで居ても立ってもいられなくなり、さっそく AWS で構築してみました。
上記の記事によれば

簡単にまとめると次のようになります。

  • Galera Replicationが複数のRDBMをレプリケーションするwsrep APIを提供し、同期をとります
  • 完全同期型であるため、すべてのノードがアクティブかつマスターとなります
  • クラスターノードのどれに対してもリード/ライトが可能です
  • ノードの追加/削除は自動で行えます
  • クライアント接続は通常のMySQLとなんら変わりなく使えます

via. MariaDB Galera Clusterを試す (1) « さくらインターネット研究所

おー!スレーブ/マスター形式のレプリケーションよりも、断然使いやすそうやんか!
ってわけで AWS の ELB 配下に複数台 MariaDB Galera Cluster を配置する方法を解説します。
続きを読む

WordPress サイトの永代供養

イベント用に立ち上げた WordPress サイトとか、もう将来にわたって更新する可能性の無いサイトって一つや二つありますよね。
もう要らないからと言ってドメインを手放したりすると、中古ドメイン屋に買われ風俗サイトにリニューアルされたりするので、できればそのままにしておきたいです。
しかし WordPress のバージョンアップをせずに放置していると、これまた最悪の場合脆弱性をつかれて乗っ取られたとかってことにもなりかねません。
また、月々のサーバ代もバカにならないですよね

そんなときは、AWS の S3 でホスティングしてあげましょう。これを「サイトの永代供養」と呼ぶらしいです。
恐ろしいほどコストダウンできますよ。
月額10円~でレンタルサーバーをはじめる方法 | アマゾン ウェブ サービス(AWS)
月額10円〜 – Amazon S3でウェブサイトをホスティングする方法 – Amazon Web Services ブログ

では、WordPress サイトを S3 でホスティングさせる方法について説明します。
続きを読む