大規模サイト運用における mtの具体的な活用方法

Copyright 2013 EWM Group, Ltd. All rights reserved.

2013年12月 7日株式会社　EWMファクトリー

大規模サイト運用におけるMTの具体的な活用方法


自己紹介

松本　光司

株式会社　EWMファクトリーに２０１１年６月入社。

入社当初から自社のMT案件のほとんどを担当。


今回のスピーチ内容の流れ

1. EWMの大規模サイト運用事例の概要

2. これまでの経験を踏まえた大規模サイト運用の在り方とMTの活用方法


今回紹介する事例

• イベントサイトにおける負荷分散を考慮した

ウェブサイト運用

• 大規模組織におけるMTでのワークフローを用いた



イベントサイトにおける負荷分散を考慮した



運用案件の概要

● 大規模なスポーツイベントを扱うウェブサイト運用


運用作業の概要

• お客様側では対応の難しい作業を行った。

• コンテンツの追加・更新（ニュース、イベント情報、ブログ etc...）

• デザイン作成（キービジュアルなどの画像）

• 各種イベントへの申し込みフォームの作成・運用

• CMSのカスタマイズ（機能追加や変更）

• 運用依頼は要求管理システムで一元化した。


運用体制

通常時イベント開催期間とその直前

● 次の体制で対応。

○ 窓口担当者　1人

○ ディレクター　1人

○ デザイナー兼

マークアップエンジニア　1人

○ CMS担当兼

マークアップエンジニア　1人

○ サーバー運用担当 1人

● お客様よりの運用依頼件数がい

つもの2,3倍、対応時間が通常の

2倍に。

● 昼夜、休日問わず依頼が発生。

● 当番制で担当を設ける。


運用設計 - 運用開始当初は、

記事を作成・保存

プレビューを生成

弊社製作者

本番サーバー（弊社クラウド上の仮想マシン）

確認

・運用依頼・差し戻し・公開依頼

お客様記事の投稿・公開

確認依頼

ファイルの出力閲覧者

修正もしくは公開

本番サイト

弊社製要求管理システム


ただ、、開催が近くなると運用依頼がどっと増える

• お客様よりの依頼件数は、週10件前後。

• 開催一ヶ月前から、依頼が急増。


ページ規模も、、、どんどん大きくなる

• 運用開始当初は、300ページ程度。

• 月30件程度のペースで記事が増え、現在1500ページ程度に。


● 開催まで近くなるにつれ、

○ アクセス数が増大。

○ 運用件数も増える。

● CMS操作による負荷、およびアクセス数増加による負荷の「2重の負荷」で公開

サーバーが不安定になる事が予想された。

途中で運用設計の変更の必要性出てきた

そこで、


運用設計 -開催数ヶ月前

記事を作成・保存

弊社製作者

確認用サーバー（弊社クラウド上の仮想マシン）

確認


お客様

記事の投稿・公開

確認依頼

ファイルの出力

閲覧者

修正もしくは公開


ニュースなどお客様で更新するものはRsyncで同期

弊社製同期ツールで手動同期

PublishSystem

サーバーを本番・確認用に分けた。※旧本番サーバーは　確認用サーバーになった。

本番サイト確認用サイト



● 要求管理システムで運用のやり取りを一元化

● 本番サイト用・確認用サイト用にサーバーを分けて、

負荷分散

● 確認用サイトを設けて、お客様確認を簡単にした

サーバー負荷が高くなる時期も乗り越えられた！


大規模組織におけるMTでワークフローを

用いたウェブサイト運用


• 大学様のウェブサイト。

• 人数規模

• 生徒数（学部の学生のみ）

• 3000人程度

• 教員数

• 200人程度

• 職員数

• 百数十人程度



コンテンツの概要

● ほぼすべてのページをCMSで管理。

● サイトトップページはFlashを大きく利用。

● フォームが2,3個（phpによる自社フレームワーク、DB連携あり）

● Namazuによる、サイト内ページの検索機能（後にGoogleカスタム検索に置換）

● PC向けサイトのみ。


運用メンバーの体制

● 次の体制で対応。

○ 窓口担当者　1人

○ ディレクター　1人

○ デザイナー兼マークアップエンジニア　1人

○ マークアップエンジニア・CMS担当　1人

○ サーバー運用担当　1人

● Flash・フォームの調整や大掛かりな作業が発生する場合は、

その時だけ人員を1～3人程度増やす。



• お客様側では対応の難しい作業を行う。

• コンテンツの追加・更新（各種ニュース、ブログ etc...）

• デザイン作成（キービジュアルなどの画像）

• 各種イベントへの申し込みフォームの作成・運用

• CMSのカスタマイズ（機能追加や変更）


更新頻度

• 月3～5件程度。

※お客様側で多く更新を行う為、リクエスト件数自体は少ない。


ページ規模の推移

● 運用開始当初（2012年1月）は、800ページ。

● 月40件程度のペースで記事が増え、現在2150ページ程度に。


ワークフローが必要になったけど、、、

• お客様側でワークフロー（記事の公開・更新に際し、承認者が承認する）が必要

になった。

• お客様の組織が大きい事もあり、システム側でワークフローをやる事に。

• でも、諸事情で確認用サイトは用意できないので、確認用サイトから本番サイト

にマージするときに制限をかける方法は使えない。

• そもそもCMSでワークフローをやるのは面倒！

そこで、


運用設計

記事を作成・保存・修正


弊社製作者


確認


お客様承認者

記事の投稿・公開

確認依頼


閲覧者

公開

本番サイト


お客様作業者

公開申請

記事を・作成・保存・修正

差し戻し


● 記事の公開、および差し替えについて制限をかける事に成功。

● 承認依頼、差し戻しは、MTからメールでやり取りできる。

MT + MTプラグインでワークフローを実現

MT とプラグインで大規模組織が利用するワークフローを実現できた


これまでの経験を踏まえた大規模サイト運用の在り方とMTの活用方法


外部とのやりとりの効率化



• 難しい場合もあると思うが、提案時・PJの開始時にお客様に

働きかける事がやはり大事。

• 担当者毎に確認手順が異ならないよう、確認ルールを統一。

• イベントサイトの運用では、定時外や休日対応の対応がでるので、

そこも考慮しておく。

お客様側のウェブサイト運用体制をしっかりしてもらう。



• 大規模サイト運用では、情報のやり取りが特に多いので、大事！

• 一元化しないと漏れが必ず出る！！

運用作業に関するやりとりは、要求管理システムで窓口を一元化。


ＩＴ関連が苦手なお客様側担当者への対応

（お客様の方で出来るだけ運用を行っていただくには）


ＩＴ関連が苦手なお客様側担当者への対応（お客様の方で出来るだけ運用を行っていただくには）

• 問い合わせに都度対応するのは非効率。

• CMSなどシステムのUIを、分かりやすく直観的に使えるようにするのも

大事。

お客様はマニュアルを作っても読んでくれない。聞いてくる。


MTでの対策 - ウィジウィグエディタを利用してもらう

• 「でも、MT標準のウィジウィグってへ○かったよね、、、」

「CKEditorのプラグインはいつHTML5に対応するの、、、？」

→それはMT5.1系まで！！

• MT5.2よりウィジウィグエディタが「TinyMCE」に変更。

• HTML5対応

• 定型文機能

• プラグインによる拡張（表組の利用、装飾を行うツールボタンの追加など）



• 例えば、、、

• 項目「本文」、「続き」を非表示にする。

• 各項目の縦横幅の変更

• 入力項目「タグ」はテキスト入力だが、チェックボックスグループに変え

る事もできる。

※「MTAppJQuery」（作者：奥脇知宏　氏）

http://www.tinybeans.net/blog/download/mt-plugin/mtapp-jquery.html

MTプラグイン「MTAppJQuery」を使えば、より手の込んだカスタマイズが可能。





本番サイトとは別に確認用サイトを設ける


• そもそもCMSのプレビュー見せるより、ミラーサイト見てもらった方が確実・

安心！

• お客様確認でCMSのプレビュー機能が使えない時に、とても便利。

• いちいちCMSでプレビューするよりも、分かりやすい。

• 大規模サイト運用では、本来必須（と弊社は考えている）。

確認用サイトがあると、、、

本番サイトとは別に、確認用サイトを設ける

でも、、、運用設計はどうしたらいいの？


確認用サーバー（弊社クラウド上の仮想マシン）



ニュースなどお客様で更新するものはRsyncで同期

弊社製同期ツールで手動同期

PublishSystem

本番サイト確認用サイト

静的生成のMTを用いた場合では、、、

確認用サーバーのＭＴから静的ファイルを確認用サイトに

吐いて、内容がOKだったら本番サイトにマージする。



• プレビュー用ページのURLを用意してくれるプラグインを利用する手もある。

• 「PreviewURL」（作者 : Yuichi Takeuchi 氏）

http://communities.movabletype.jp/plugins/2011/07/previewurl.html

確認サイトが用意できないときは、、、





一つのブログに記事を持たせすぎない


一つのブログに記事を持たせすぎない

（※サーバーインフラのスペックにもよるが。。。）

• ブログ一つが持てる記事数は実質300～400記事。

• これ以上持ったらブログ全体の再構築時が悲しいことに。

• ブログ記事単体を再構築するときに遅くなることも。

• （ＥＷＭの過去の例）

• 記事数400　→　レスポンスが返ってこない（ヽ´ ｀）

• 記事数800　→　終了までに12分

MTのブログ一つが持てる記事数の限界


複雑なナビゲーションもＭＴタグだけで生成出来る



• MTのCMSテンプレート向けタグ言語「MTML」は、変数、ハッシュ、繰り返し、条

件判断を行うタグがあり、プログラムのコードのような書き方もできる。

• ある案件では、パンくずやサイドナビの更新をCMSテンプレートで

完全自動化した。

大規模サイトはサイトマップが複雑だけど、パンくずやサイドナビの更新をMTでじどう

かできないの？

→MTMLだけでも、複雑なナビゲーションリンク生成

　の処理を十分にこなせますよ！


（イメージ図）



プラグインで大きな組織の

ワークフローを実現できる


• ブログ毎で個別にユーザー権限を設定可能。

• 権限の雛形である「ロール」をユーザーに付与する形で権限を付与する。

→複数ユーザーの権限の一括変更が可能。

MTはユーザー権限管理が強力なので、素のままでもある程度は制限できる

プラグインで大きな組織のワークフローを実現できる

しかし、MTのみでは下書き記事を公開する際にしか制限を掛

けれない、、、


• 公開中の記事の内容を変更する際も制限を掛ける事が出来る。

• 承認申請や差戻しの連絡を、MTの管理画面からメールを飛ばして行える。

ワークフロー管理のプラグインはいくつかあるが、

EWMでは「CheckRelease」プラグインがいいね！＼（^0^）／


http://www.ideamans.com/products/checkrelease4mt/

有償（84,000円(税込)）

※有償なので、中規模以上の組織でちゃんとしたワークフローがほしい時に！






確認

お客様承認者

記事の投稿・公開ファイルの出力

閲覧者本番サイト

お客様作業者

公開申請

記事を・作成・保存・修正

差し戻し


MT + CheckReleaseプラグインによる

ワークフローの構築例


負荷の問題はMT6とウェブサーバーで緩和できる



• CMSの同時利用者が増えると負荷が高まる。

• 本番サーバーにCMSと本番サイトを同居させると、

本番サイトのレスポンス落ちる事も。

• MTは再構築時の負荷が高い。

負荷にまつわる一般的な問題をまとめると、、、



• MT6はMT5と比較して、再構築の速度が約1.6倍に。

→MT6を導入しよう！

MTのバージョンを最新（MT6）にする事で、負荷を緩和。


ApacheにFastCGIを導入する


○ レスポンスが導入前の約1.5倍程度早くなる模様。

○ 弊社で導入実績があるが、定期的なApacheの再起動なく安定して

動いている。

○ SixApartのサイトにも導入についてドキュメントあり。

http://www.movabletype.jp/documentation/developer/server/fastcgi.html




（※弊社はまだ実務で扱う機会がなく検証中だけど、、、）

MTは5.2よりウェブサーバー「nginx」に対応


• FastCGIよりもレスポンスが約1.4倍程度早くなるらしい。

• 「nginx」は高速なウェブサーバーとして近年注目されている。

• SixApartが行っているクラウド版MTサービスは「nginx」を利用している。http://www.sixapart.jp/movabletype/news/2012/09/26-1135.html

http://www.sixapart.jp/movabletype/news/2012/09/26-1135.html

http://www.sixapart.jp/movabletype/news/2012/09/26-1135.html


ご静聴ありがとうございました

大規模サイト運用における mtの具体的な活用方法

Technology