サーバサイドエンジニアから見た MT構築のレガシーなノウハウ

（入門編）

!

@onagatani

自己紹介• 北海道からきました！

• 永谷　理（ながたに　おさむ）

• スカイアーク所属Movable Type歴６年目のインフラ・サーバサイドエンジニア

• Perlが大好きでHokkaido.pmやYAPC::Asia、MTの勉強会、最近はAWSの勉強会にも顔を出しています

• 好きなMTプラグインは自分が開発したプラグイン一部公開していますのでGitHubをご覧下さい@onagatani

• 活イカとスープカレーを主食にしています

(c) Japan Perl Association

YAPC::Asia 2012での発表風景（北の国から風）

PageButeの開発元ですMT案件ではかなり使用されていましたよね？

• 北海道帯広市で起業して11年目。Movable TypeでのCMS構築を主力事業として他にAWS導入やSalesforce導入も行っています

• GitHubで公開しているプラグインは商用利用も無料なので是非ご利用下さい（公開あまりできていないですが現在までに100以上のプラグインを開発しています）

• 関連会社Farmnoteの事業ではIVS Launch Padで３位入賞でした。AWS Cloud Roadshow 2014 Sapporoで登壇などしている会社です

IVS 2014 Fall Launch Pad

Github (ほとんどMT plugin)

少し会社の宣伝

北海道といえば

スープカレー

自分は最低週に三食は食べます

活イカ

死んだイカはイカじゃない！

本題 !

サーバサイドエンジニアから見た MT構築のレガシーなノウハウ

（入門編） !

現場はイマドキのノウハウを 取り入れられない場合がありますというお話

再構築は重い• 今まではMTでは普通に構築を行うとアー

カイブが増えてきた場合にカテゴリや月別アーカイブが非常に長いページになるためPageButeなどを利用する場面が多かった。

• ページ分割を行う事でほとんどPVが無い昔のアーカイブを再構築する事になり再構築負荷が半端ない事に。

• 例えばカテゴリアーカイブや古い記事はリクエストが来てからDataAPIで処理するようにしましょう。※SEO的な観点は考慮していません

index_1.html index_2.html

…

なんとなくPHPを使っている• 敵勢適所ですが余計な負荷になる事も多く、他の実装で回避できる場合が多いです

• .html拡張子でもPHPを動作するようにしている。※極力避けたい

• php includeのためだけにPHPを使っている場合はJSで代替できるか検討する

• 再構築をトリガーとしない表示切り替えを行う場合はJSやDataAPIを検討

• 結局楽をしたくてPHPを入れる人も多いのですがPHPのバージョンアップとかしているのかなと心配

<?php include(“/path/to/hoge.html”); ?>

え？これだけのためにPHPなのー！ という事もしばしば

静的htmlのみのサイトにする• やはりMTの強みは静的再構築！突然のアクセスも問題になる事はないでしょう

• コーポレートサイトの構築では静的htmlとJSだけでほぼ完結できるでしょう※今どきトラックバックやコメント機能はほとんど使わないし（ｵｲ

• 動的要素がないのでセキュリティもあんまり気をつけなくて大丈夫※MTの脆弱性はXSSを除けばmt-XXX.cgiがほとんどです、詳しくは後述します

• DataAPIはとても便利ですがむやみやたらに使用すると過負荷の原因にもなります

うちのエンジニアブログですが 静的htmlなのでスループットも数千です

toolsディレクトリの活用• tools内にはcliツールが沢山入っていますので活用しましょう。例えばrebuild-pagesスクリプトを利用して定期的に特定テンプレートの再構築を行うなんて事も出来ます

• MultiBlog機能を極力使わない事で再構築する対象を減らし、代わりに１時間に一度などで関連ページを再構築する（他にも色々方法はありますが）

• 記事データを全てJSONで静的出力しjquery等で必用なデータを使って画面をレンダリングすればアーカイブの差構築も不要かも？

• テンプレート例）setvarでデータを作成してto_jsonで定期的に出力する<mt:Var name="entries" to_json="1">

AWSを使う• AzureでもGCEでも良いんですが弊社では主にAWSを使う事が多いです。そしてAWSの機能は静的html生成型CMSにも非常に相性がいいです。

• AWSに用意されたMT AMIを使えば全てセットアップ済みのセキュリテイもバッチリの高速なMTサーバがすぐに使用できます

• 後述しますが、AWSを利用する事でLBや複数台サーバ構成も１時間もかからずに構築できオンプレ時代から比べると手間暇がかなり削減できます

t2.microならライセンス無料！ 仕事で使うならt2.midium以上ないと厳しいかも

セキュリテイに気をつける• CMSとコンテンツ公開サーバを切り分ける

• MTが動いているCMSサーバを外部から隔絶しコンテンツをS3等へ配信する事でセキュリテイをほぼ考えなくてよい構成になります

• また、S3でコンテンツ公開を行うことによって、Webサーバの冗長化やバックアップもほとんど考えなくてよくなります

Amazon EC2Movable Type

security group

Amazon S3

接続元IP制限 コンテンツ公開

ToI企画さんがAWSプラグインを公開しています https://github.com/usualoma/mt-plugin-amazon

管理画面の高速化• PSGIを利用する！これに尽きます・・・。CGIより数倍高速されます

• 管理画面自体はapache,nginx,mysql等をチューニングしてもほとんど速度に変化はないのでMT自体を高速化する事が一番

• FCGIでも良いのですが、さらにPSGIで高速化！ ※PSGIサーバはStarmanやStarletを使いましょう

• サーバ管理できない人はMT AMIを使う事を推奨します

自分でゼロからPSGIのMTを起動したい場合は 参考にして下さい

http://www.skyarc.co.jp/engineerblog/entry/ movabletype_psgi_mysql.html

コンテンツ配信の高速化• 静的htmlだけで構成されたコンテンツではサーバの限界性能に達する前に設定値の制限に引っかかる事があります※Apacheは最大接続数をチューニングしましょう。nginxはデフォルトでも結構捌けます

• そのため想定されるPVに耐えうるようにサーバのカーネルチューニングを行います。例えばファイルディスクリプタやIPTablesの最大接続数、TCP関連のチューニングする※AmazonLinuxだとインスタンスサイズによってチューニングされています

• ちなみにSSLを使うと10倍くらい重くなる事もあるので注意（SSLアクセラレータ付きのLBを使う事で回避）

CentOSの例） net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_timestamps = 0 kernel.panic_on_oops=1 kernel.panic=10 net.core.somaxconn = 10240 net.ipv4.ip_local_port_range = 10240 65000 net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.ipv4.tcp_rmem=4096 87380 16777216 net.ipv4.tcp_wmem=4096 65536 16777216 net.core.netdev_max_backlog = 30000 net.ipv4.tcp_no_metrics_save=1 net.core.somaxconn = 262144 net.ipv4.tcp_syncookies = 0 net.ipv4.tcp_max_orphans = 262144 net.ipv4.tcp_max_syn_backlog = 262144 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_syn_retries = 2 net.ipv4.tcp_max_tw_buckets = 56384 net.nf_conntrack_max = 1000000 fs.file-max = 794573

AWS環境構築• 新規案件の環境構築では、AWSの基本設定はCloudFormationで行い、残りのサーバ構築はAnsible/chefなどで行っています

• 弊社案件ではELB下にWEBサーバを冗長化し、MT/CMSサーバ、RDSを配下においた構成が多いです※細かいリダイレクトやDataAPIの利用など色々な事を行う事が多いためS3ではなくEC2を冗長化する事が現状多いです。。。

AWS CloudFormation

Availability Zone

virtual private cloud

Amazon EC2

DR対策• AWSではELBの下にEC2を複数MultiAZ設置し、１台が落ちても停止しない構成に

• データベースはRDS MultiAZで

• ストレージはGlusterFSなどで冗長化・共有を行う今後は価格次第でEFSが主流になると思います。EFSはMT界の救世主！

• とはいえ、通常のコーポレートサイトであればEC2一台で運用しスナップショット・バックアップ・自動復旧設定をしておけばほとんど問題ないはず

Elastic Load

Balancing

WEB/CMS

WEB/CMS

Availability Zone Availability Zone

RDS DB instance

RDS DB instance standby

(Multi-AZ)

データ同期

レプリケーション

片方のAZやEC2・RDSが落ちてもサービス停止しない構成

MTバージョンアップ• 一番怖くてやりたくない作業

• とはいえ、サボるわけにもいかない

• 基本的には出力されるコンテンツの中身がバージョンアップ前と後で同一であれば良い

• やりたくないが全コンテンツをクローリングするか静的htmlに対してdiffを行うのが安全※MTのバージョンアップではMTタグの挙動が多少変化したり、きちんと書いていない場合に動かなくなる場合がある

• もしくはMTのソースコードの差分を見て影響範囲を把握し対応

• 原始的なので良い方法あれば教えて下さい

MT5 MT6

Elastic IP

旧環境 新環境

スナップショットから起動

バージョンアップ環境を試してからEIPを切り替えて無停止でサーバ切

り替えを行う

まとめ• 再構築するファイル数が多くならないように気をつける（MTが敬遠される理由になった）

• とはいえ静的再構築しておけばT2インスタンスでも数千スループットは可能、PHPは適材適所で使う

• クラウドを活用してセキュアでスケーラブルなWebサイト運用を行う（どこかで聞いたセリフですね！）

• DataAPIを活用する（ユーザ参加型のコンテンツ開発や、非同期でのコンテツ表示による負荷軽減）