Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

4,467 views

Published on

CMSどうでしょう〜MT・WP対決列島〜 仙台編での資料です。

Published in: Engineering
  • Be the first to comment

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

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

×