サーバサイドエンジニアから見た MT構築のレガシーなノウハウ (入門編)
•
5 recomendaciones•5,402 vistas
CMSどうでしょう〜MT・WP対決列島〜 仙台編での資料です。
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (16)
Similar a サーバサイドエンジニアから見た MT構築のレガシーなノウハウ (入門編)
Similar a サーバサイドエンジニアから見た MT構築のレガシーなノウハウ (入門編) (20)
サーバサイドエンジニアから見た MT構築のレガシーなノウハウ (入門編)
- 2. 自己紹介 • 北海道からきました！ • 永谷 理（ながたに おさむ） • スカイアーク所属Movable Type歴６年目 のインフラ・サーバサイドエンジニア • Perlが大好きでHokkaido.pmや YAPC::Asia、MTの勉強会、最近はAWSの 勉強会にも顔を出しています • 好きなMTプラグインは自分が開発したプ ラグイン 一部公開していますのでGitHubをご覧下 さい@onagatani • 活イカとスープカレーを主食にしています (c) Japan Perl Association YAPC::Asia 2012での発表風景（北の国から風）
- 5. • 北海道帯広市で起業して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) 少し会社の宣伝
- 6. 北海道といえば
- 10. 再構築は重い • 今まではMTでは普通に構築を行うとアー カイブが増えてきた場合にカテゴリや 月別アーカイブが非常に長いページに なるためPageButeなどを利用する場 面が多かった。 • ページ分割を行う事でほとんどPVが無 い昔のアーカイブを再構築する事にな り再構築負荷が半端ない事に。 • 例えばカテゴリアーカイブや古い記事 はリクエストが来てからDataAPIで処 理するようにしましょう。 ※SEO的な観点は考慮していません index_1.html index_2.html …
- 11. なんとなくPHPを使っている • 敵勢適所ですが余計な負荷になる事も多く、 他の実装で回避できる場合が多いです • .html拡張子でもPHPを動作するようにし ている。 ※極力避けたい • php includeのためだけにPHPを使ってい る場合はJSで代替できるか検討する • 再構築をトリガーとしない表示切り替えを 行う場合はJSやDataAPIを検討 • 結局楽をしたくてPHPを入れる人も多い のですがPHPのバージョンアップとかして いるのかなと心配 <?php include( /path/to/ hoge.html ); ?> え？これだけのためにPHPなのー！ という事もしばしば
- 12. 静的htmlのみのサイトにする • やはりMTの強みは静的再構築！ 突然のアクセスも問題になる事はないでしょ う • コーポレートサイトの構築では静的html とJSだけでほぼ完結できるでしょう ※今どきトラックバックやコメント機能は ほとんど使わないし（ｵｲ • 動的要素がないのでセキュリティもあんま り気をつけなくて大丈夫 ※MTの脆弱性はXSSを除けばmt-XXX.cgi がほとんどです、詳しくは後述します • DataAPIはとても便利ですがむやみやたら に使用すると過負荷の原因にもなります うちのエンジニアブログですが 静的htmlなのでスループットも数千です
- 13. toolsディレクトリの活用 • tools内にはcliツールが沢山入っています ので活用しましょう。例えばrebuild-pages スクリプトを利用して定期的に特定テンプ レートの再構築を行うなんて事も出来ます • MultiBlog機能を極力使わない事で再構築 する対象を減らし、代わりに１時間に一度 などで関連ページを再構築する（他にも色々 方法はありますが） • 記事データを全てJSONで静的出力しjquery 等で必用なデータを使って画面をレンダリ ングすればアーカイブの差構築も不要かも？ • テンプレート例） setvarでデータを作成してto_json で定期的に出力する <mt:Var name="entries" to_json="1">
- 14. AWSを使う • AzureでもGCEでも良いんですが弊社 では主にAWSを使う事が多いです。 そしてAWSの機能は静的html生成型 CMSにも非常に相性がいいです。 • AWSに用意されたMT AMIを使えば 全てセットアップ済みのセキュリテイ もバッチリの高速なMTサーバがすぐ に使用できます • 後述しますが、AWSを利用する事でLB や複数台サーバ構成も１時間もかから ずに構築できオンプレ時代から比べる と手間暇がかなり削減できます t2.microならライセンス無料！ 仕事で使うならt2.midium以上ないと厳しいかも
- 15. セキュリテイに気をつける • CMSとコンテンツ公開サーバを 切り分ける • MTが動いているCMSサーバを 外部から隔絶しコンテンツをS3 等へ配信する事でセキュリテイ をほぼ考えなくてよい構成にな ります • また、S3でコンテンツ公開を行 うことによって、Webサーバの 冗長化やバックアップもほとん ど考えなくてよくなります Amazon EC2 Movable Type security group Amazon S3 接続元IP制限 コンテンツ公開 ToI企画さんがAWSプラグインを公開しています https://github.com/usualoma/mt-plugin-amazon
- 16. 管理画面の高速化 • 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
- 17. コンテンツ配信の高速化 • 静的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
- 18. AWS環境構築 • 新規案件の環境構築では、AWS の基本設定はCloudFormationで 行い、残りのサーバ構築は Ansible/chefなどで行っています • 弊社案件ではELB下にWEBサー バを冗長化し、MT/CMSサーバ、 RDSを配下においた構成が多いで す ※細かいリダイレクトやDataAPI の利用など色々な事を行う事が多 いためS3ではなくEC2を冗長化 する事が現状多いです。。。 AWS CloudFormation Availability Zone virtual private cloud Amazon EC2
- 19. 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が落ちても サービス停止しない構成
- 20. MTバージョンアップ • 一番怖くてやりたくない作業 • とはいえ、サボるわけにもいかない • 基本的には出力されるコンテンツの中身がバー ジョンアップ前と後で同一であれば良い • やりたくないが全コンテンツをクローリング するか静的htmlに対してdiffを行うのが安全 ※MTのバージョンアップではMTタグの挙動 が多少変化したり、きちんと書いていない場 合に動かなくなる場合がある • もしくはMTのソースコードの差分を見て影 響範囲を把握し対応 • 原始的なので良い方法あれば教えて下さい MT5 MT6 Elastic IP 旧環境 新環境 スナップショットから起動 バージョンアップ環境を試してから EIPを切り替えて無停止でサーバ切 り替えを行う
- 21. まとめ • 再構築するファイル数が多くならないように気をつける （MTが敬遠される理由になった） • とはいえ静的再構築しておけばT2インスタンスでも数千 スループットは可能、PHPは適材適所で使う • クラウドを活用してセキュアでスケーラブルなWebサイ ト運用を行う（どこかで聞いたセリフですね！） • DataAPIを活用する（ユーザ参加型のコンテンツ開発 や、非同期でのコンテツ表示による負荷軽減）