Traffic ServerでWORDPRESSを高速化する

最近地道にトラフィックが増えてきているので、そろそろWORDPRESSの高速化を検討してみる。世間ではNginxがはやっているようだが、ここは敢えてApatch Traffic Serverを使ってみたい。

OSはUbuntu 15.xを使用しています。

Apatche Traffic Serverの初期設定

apt-getを使用して標準のレポジトリからApatche Traffic Serverをインストールします。

sudo apt-get install trafficserver

Reverse-Proxeの接続先を設定します。

sudo nano remap.config
map http://www.example.net:8080/ http://127.0.0.1/
reverse_map http://127.0.0.1/ http://www.example.net:8080/

サービスを起動してポート8080に接続してみますが、動作しません。

sudo service trafficserver start

ログファイルを閲覧すると、以下のようなエラーが発生しています。

less /var/log/trafficserver/traffic.out
traffic_server: using root directory '/usr'
FATAL: Trafficserver has not been designed to serve pages while
        running as root. There are known race conditions that
        will allow any local user to read any file on the system.
        If you still desire to serve pages as root then
        add -DBIG_SECURITY_HOLE to the CFLAGS env variable
        and then rebuild the server.
        It is strongly suggested that you instead modify the
        proxy.config.admin.user_id directive in your
        records.config file to list a non-root user.

どうやら標準のままだとrootアカウントで起動されてしまうけど、trafficserverはrootアカウントで起動できないため権限周りでエラーとなっているようです。/etc/trafficserver/records.configを編集してproxy.config.admin.user_idの設定を追加するように指示されているので追加します。trafficserverアカウントは既に作られているので、追加の必要は無いようです。

sudo nano /etc/trafficserver/records.config
CONFIG proxy.config.admin.user_id STRING trafficserver

サービスを再起動してポート8080に接続してみると、今度は動作しました。

sudo service trafficserver restart

サービスの移行

正常に動作するようなので、本番に移行します。
Windows Azureを使っているので、エンドポイントの設定を変更してポート80への接続を、ポート8080に振り分けるようにします。こういう所、手抜きできるからクラウド好きです。

remap.configの設定を本番用に変更します。先ほどはポート8080の記載がありましたが、それを削除します。

sudo nano remap.config
map http://www.example.net/ http://127.0.0.1/
reverse_map http://127.0.0.1/ http://www.example.net/

このままだとWORDPRESSが正常に動作しないので、以下の設定をwp-config.phpに追記します。

sudo nano /var/www/wordpress/wp-config.php
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];

apatch2とtrafficserverを再起動します。

sudo nano /var/www/wordpress/wp-config.php
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];

ポート80に繋いでみますが、正常に動作しているようです。

ローカルストレージへのキャッシュ移動

標準設定のままだと/var/cash/trafficserverにキャッシュデータを保存します。クラウド上の仮想サーバーは一般的にIO速度が遅いため、あまり速度が改善しません。その代わりにWindows Azureでは高速な揮発性のローカルストレージも提供されています。揮発性のストレージは仮想サーバをシャットダウンすると失われますが、キャッシュデータなら失われても問題ないのでこちらに移動します。
ローカルストレージはスワップファイル用に/mntにマウントされているので、/mnt/trafficserverと言うフォルダを新たに用意してこちらを使います。

新たにフォルダを作成します
sudo mkdir /mnt/trafficserver
sudo chown trafficserver /mnt/trafficserver

storage.configを編集して、キャッシュの保存先を変更します。
sudo nano /etc/trafficserver/storage.config
/mnt/trafficserver 256M

trafficserverを再起動します。
sudo service trafficserver restart

どの程度改善されたか

トップページの表示完了まで5,000msかかっていたのが700ms程度に。トップページのhtmlだけなら2,500ms程度かかっていたのが、20ms程度にまで高速化されました。応答速度が125倍改善して、体感的にも7倍くらい速くなっている計算。

参考

WordPressをリバースプロクシ対応にする3つのポイント
How to Set Up Apache Traffic Server as a Reverse-Proxy on Ubuntu 14.04

機械学習でtotoの予測をしてみた

せっかく学習したのだし多少は実益に・・・・ということで、機械学習(Deep Learning)でtotoの予測を立ててみた。
過去の対戦成績のデータはJ.Leagu Data Siteから頂いた。これだけではつまらないので、気象庁の過去の気象データ・ダウンロードから対戦時の気象情報をダウンロードした。これを元に学習をさせてみる。

チームの構成人員や、それらのパフォーマンスなど入力データを増やすのは疲れるのでやらない。むやみにデータを増やせばよいというものではないし、それらのデータは対戦結果として既にフィードバックされているので問題ないと判断した。

予測結果は次のようになったが、果たして・・・

広島 x G大阪 -> 広島勝
磐田 x 名古屋 -> 名古屋勝
広島 x 川崎F -> 川崎F勝
鳥栖 x 福岡 -> 鳥栖勝
柏 x 浦和 -> 浦和勝
湘南 x 新潟 -> 新潟勝
神戸 x 甲府 -> 神戸勝
横浜FM x 仙台 -> 引分
FC東京 x 大宮 -> FC東京勝
G大阪 x 鹿島 -> G大阪勝
東京V x 札幌 -> 札幌勝
金沢 x 長崎 -> 金沢勝
清水 x 愛媛 -> 引分
山口 x 岡山 -> 引分
熊本 x 松本 -> 引分
群馬 x 岐阜 -> 群馬勝
町田 x C大阪 -> 引分
横浜FC x 讃岐 -> 横浜FC勝
千葉 x 徳島 -> 徳島勝
京都 x 水戸 -> 水戸勝
北九州 x 山形 -> 北九州勝

totokounyuu

PowershellでActiveDirectoryのユーザーを管理する

ActiveDirectory(以下AD)のユーザーは人事異動等にともなって定期的に大きく変更されるので、手作用で更新していると非常に煩雑な事になります。Powershellの活用でADのユーザー管理の省力化を目指したいと思います。

Remote Server Administration Toolsのインストール

PowershellでActive Directoryのユーザー管理の為のコマンドレットを呼び出すためには、Remote Server Administration Tools(以下RSAT)をインストールする必要がある。インストールするRSATはクライアントOS毎に異なるので、対応するインストーラを以下からダウンロードする。
Remote Server Administration Tools (RSAT) for Windows Client and Windows Server (dsforum2wiki)

ADユーザーを更新する

更新する対象がデータベースなら削除して登録することを繰り返しても問題ない場合が多いが、ADユーザーの場合には削除して追加すると言うわけにはいきません。一度削除してしまうと、再登録してもユーザーを一意に識別するために使っているSIDやGUIDが異なる値になってしまい、別のユーザーとして識別されてしまいます。従って面倒でも既存のユーザーの有無を調べ、無ければ新規に作成し、あるなら必要に応じて項目を更新すると言う手続きにならざる得ません。

既存ユーザー有無確認

既存ユーザーの有無を確認するにはGet-ADUserを使う。Get-ADUserは一致するユーザーが存在しない場合には例外を投げるので、$existUserの値は変更されないまま$NULLとなる。

     $existUser = $NULL
     $existUser = Get-ADUser -Identity [ユーザー名]
     if ($existUser -eq $NULL)
     {
          # ユーザーが登録されていない場合の処理
     }
     else
     {
          # ユーザーが登録されている場合の処理
     }

ユーザーの追加

ユーザーを追加するにはNew-ADUserを使用します。ユーザーに関する諸設定を行うためにコマンドラインパラメータが非常に多いです。必要最低限を指定して、残りはSet-ADUserで処理した方が実装が容易かと思います。

     New-ADUser "[ユーザー名]"  -UserPrincipalName "[ユーザー名]@[ドメイン] .local") -DisplayName "[表示名]" -Path"OU=[新部署] , OU=[部門], DC=[ドメイン], DC=local " -Enabled $TRUE

既存ユーザーの一覧を取得

Get-ADUserは指定した条件にマッチするユーザーのリストを返す。フィルタ条件にアスタリスクを指定すると全てのユーザーが得られる。抽出条件の指定方法は多岐に渡るので詳細はオンラインヘルプに委ねる。

    $userAccountList = Get-ADUser -Filter *
     foreach ($userAccount in $userAccountList)
     {
          # 各ユーザーに対する処理
     }

組織単位の移動

組織単位はGet-ADUser で取得したユーザーアカウントのプロパティを参照すれば得られる。組織単位を変更する場合には、Move-ADObjectを使用して移動先の組織単位を設定する。

     if ($userAccount.DistinguishedName -notmatch ".*OU=[旧部署].*")
     {
           Move-ADObject -Identity $userAccount. ObjectGUID -TargetPath "OU=[新部署] , OU=[部門], DC=[ドメイン], DC=local"
     }

グループ設定の変更

ユーザーグループに割り当てるにはaddNoneGroupMemberを、ユーザーグループから削除するにはremoveExistGroupMemberを使う。

     # グループに追加する
     addNoneGroupMember $userAccount "グループ名"

     # グループから削除する
     removeExistGroupMember $userAccount "グループ名"

ユーザーの削除

Remove-ADUserを使えば削除する事が出来るが、誤って削除してしまうと同じSIDやGUIDを持つユーザーを復活させようとすると非常に難しくなる。従って削除するのではなくSet-ADUserでユーザーを無効にした上で、特定の組織単位に移動するに止める方が良い。

     if ($userAccount . Enabled)
     {
          $userAccount .Enabled = $FALSE
          Set-ADUser -Instance $userAccount
     }

     if ($userAccount . DistinguishedName -notmatch ".*OU=削除対象.*" )
     {
           Move-ADObject -Identity $userAccount. ObjectGUID -TargetPath "OU=削除対象 , OU=[部門], DC=[ドメイン], DC=local"
     }

マイナンバー登場でアナクロな金庫が売れている?

マイナンバー登場でアナクロな金庫が売れている? ハイテク時代に逆行する安全管理
普通に考えると、通帳や印鑑、実印、パスポート、保険証など、大切なものと一緒に保管しておくのがよさそうだ。現在、貴重品を保管してある場所に入れればいいだろう。

典型的な駄目な例。

窓口の手続きにおける本人認証は多要素認証によって行われている。例えば通帳だけ持っていても現金を下ろすことはできない。通帳と銀行印がそろって初めて本人と認証される。銀行印を持っていない場合には、実印と印鑑証明に保険証や免許証などの組み合わせで本人認証がなされる。印鑑証明の発行は実印の保険証や免許証の組み合わせって具合になる。これらを一か所にまとめて保存しておくと、万が一に盗まれた場合には容易に悪用されて被害にあうことになる。本人確認に使われるような大事なものを一か所にまとめて保管してはいけないのだ。

金庫に保管という方法は古臭くもあるが、金庫を設置する目的は盗難の難易度を上げることにある。金庫には耐火金庫と防盗金庫の二種類がある。防盗金庫はもっとも軽いものでも重量が100Kg程度になる上に、基本的に建物に固定する容易には搬出できない。これと機械警備などの通報システムやWEBカメラを併用すると、盗難を防いだり、不正利用を防ぐには十分に機能する。企業の手続きで毎ナンバーが必要になるのは年に一回源泉徴収票を発行する時と、入退社の時ぐらいでめったに利用しない。下手なITよりは余程効果的。