2014年05月15日
AzureBlobStorageプラグインで複数サーバーにファイルを配信する
このプラグインは現在公開中の PowerCMS パッケージには含まれず、次期リリース時に追加されます。
AzureBlobStorage については PowerCMS のオプション製品として提供を開始いたします。(費用)
ご利用をご希望される方はPowerCMS試用版のお申込みフォームからお問い合わせください。
AzureBlobStorage については提供を終了しました。
AzureBlobStorage プラグインは Microsoft Azure の Blob ストレージを利用してパブリッシュされたコンテンツのバックアップと複数の冗長化されたサーバーにコンテンツを配信するソリューションです。
Blobストレージは永続化されたデータ保存場所
Microsoft Azure の Blob ストレージはひとことで言えば「信頼性の極めて高いデータ保管場所」ということになります。AWS(Amazon Web Services)で言うところの「S3」にあたるものと考えていただいてよいでしょう。詳しくは以下のサイト等をご覧下さい。
一般に、Blob は、画像、ビデオ、ドキュメント、コードなどの大きなデータのためのストレージを提供します。1 つのサブスクリプションに含まれる各ストレージ アカウントは、任意の数の "コンテナー" を持つことができ、各コンテナーには任意の数の Blob を格納できます。ストレージは、特定のコンテナーまたは Blob ではなく、アカウント レベルで制限されます。Blob は、次の形式で作成された URL によって参照されます。
http(s)://<ストレージ アカウント名>.blob.core.windows.net/<コンテナー>/
ストレージに保存したデータは、同じデータセンター内でトラブルが生じたときのために3箇所にコピーされるようになっており、そのコピーされたデータに違いが無いか、定期的にスキャンされるようになっています。
さらに、自然災害等の影響でデータセンター自体に万一の事があった時のために、ユーザーのデータは数百キロメートル離れた別のデータセンターにもコピーされるようになっています。
Azureのクラウドサービスはデータの永続性がない
PowerCMS の Microsoft Azure対応版ではCMS環境にクラウドサービス(Webロール)を利用します。クラウドサービスはOSのアップデート等は自動的に行われるためサーバーの管理の煩わしさから解放されるという特長がある代わりに、データの永続性がありません。つまり、OSの自動アップデートとともにデータも初期化されてしまいます。
そこで、PowerCMSのインストールやデータの復旧には 「スタートアップタスク」を作成してサーバーのスタート時にインストールやデータの復旧を行うようにします。
スタートアップ タスクを使用して、ロールの開始前に操作を実行できます。実行する操作には、コンポーネントのインストール、COM コンポーネントの登録、レジストリ キーの設定、長い実行プロセスの開始が含まれています。
スタートアップタスクを用意することにより、OSアップデートに伴うインスタンスの初期化に備えるだけでなく、障害発生時の復旧や負荷増大の際のインスタンスの追加などにも柔軟に対応できるようになります。
スタートアップタスクでインストールするデータやコンテンツのバックアップに Blob ストレージを使う
Azure のクラウドサービスを利用する PowerCMS では、これらスタートアップタスクでインストールする必要のあるデータやコンテンツのバックアップには Blobストレージを使います。AzureBlobStorageプラグインはPowerCMS がパブリッシュする静的ファイル、アップロードされた画像などのファイルを、「ほぼ」リアルタイムにBlobストレージに同期する機能を持っています。また、Blobストレージに同期されたファイルの情報をキューに保存し、複数のフロント機に配信する機能を持っています。
尚、AzureBlobStorage プラグインは Windows OS以外(Linuxなど)でも動作します。PowerCMS の Microsoft Azure対応版以外の環境であっても、データのバックアップに信頼性の高い Blob ストレージを使う、といった用途にも利用いただけます。
PowerCMS の Microsoft Azure対応版の構成
PowerCMS の Microsoft Azure対応版 の構成をご紹介します。概要は以下のとおりです。
- CMS機、FRONT機は別サーバとする
- CMSは一台、FRONT機は冗長構成(複数台構成)とし、ロードバランサを用いて負荷を分散する
- データベースには SQL Azure を利用し、CMS及びFRONT機からアクセスできるようにする
- CMS及びFRONT機の両方からデータベースアクセス可能な構成にすることで、フォーム機能やダイナミックパブリッシングの利用が可能
- CMSとフロント機の間のデータ転送は Blobストレージを介して行う(常にバックアップを兼ねる)
PowerCMS の Microsoft Azure対応版とは、上記を実現するためのスタートアップタスクを含んだデプロイキットのご提供ということになります。
FRONT機が2台構成の場合、以下の図のようになります。
AzureBlobStorageプラグインの機能
AzureBlobStorageプラグインは以下の機能を持っています。
- PowerCMS が管理するファイルをリアルタイムにBlobストレージに差分同期する
- Blobストレージに同期されたファイルの情報をキューに保存する
- 複数のフロント機から、キューの情報を元に差分同期を行う
AzureBlobStorageプラグインの設定
環境設定の追加
mt-config.gi に以下の情報を追加します。Cloud.packがインストールされている場合、管理画面の「クラウドサービス」メニューの「MT環境変数」から値を追加することができます。
AzureBlobInsertUpdateQueue 1
AzureBlobSyncTargetIDs PowerCMS_IN_0_Web,PowerCMS_IN_1_Web
AzureBlobSyncRoot C:\webdata\contents
AzureBlobInsertUpdateQueue は、CMSからBlobへの同期時にフロント機に同期するためのキューを保存するかどうかの指定です。バックアップのみ行いフロントへの配信が不要な場合(1台構成でCMSとフロントを兼ねるような構成の場合)は指定する必要がありません。 AzureBlobSyncTargetIDs には、フロント機のIDをカンマ区切りで指定します。ここで指定した値は、フロント側それぞれののmt-config.cgiにAzureBlobSyncServerID として記述します。
フロントA
AzureBlobSyncServerID PowerCMS_IN_0_Web
フロントB
AzureBlobSyncServerID PowerCMS_IN_1_Web
尚、ここで指定する AzureBlobSyncRoot は、フロント側の展開先ディレクトリです。CMS機には必要ありませんが、管理画面の「クラウドサービス」メニューの「MT環境変数」から値を追加する場合にはCMS機から追加します。
続いてプラグイン設定を行います。事前にAzureの管理ポータルでBlobストレージのプライマリアクセスキーを取得しておいてください。
同期対象となるウェブサイトもしくはブログのプラグイン設定で、AzureBlobStorageプラグインの設定を開きます。ウェブサイトが一つで、ウェブサイトのサイト・パス配下にブログが複数ある場合は、親ルートとなるウェブサイトの設定だけで構いません。この例では、c:\webdate\contents 以下のファイルを同期対象とします。 同期は差分ファイルに対してのみ行われるので、設定段階で現状のデータをBlobストレージの該当コンテナ配下のディレクトリにコピーしておいてください。
| 設定名 | 説明 | 入力例 |
|---|---|---|
| アカウント名 | Blobストレージのアカウント名を入力します。 | powercms |
| プライマリアクセスキー | Azure管理ポータルから取得したストレージへのプライマリアクセスキーを入力します。 | ハッシュ文字列 |
| API接続プロトコル | https(推奨)又はhttpを指定します。 | https |
| コンテナ名 | 同期先のコンテナ名を指定します。 | webdata |
| ディレクトリ名 | 同期先のディレクトリを指定します。 | contents |
| ドキュメントルート | CMS環境の同期元のパスを指定します。 | C:\webdata\contents |
| リアルタイム同期 | チェックを入れると(ほぼ)リアルタイムに同期を実行します。 チェックを入れない場合、同期処理は一旦キューに保存され、run-periodic-tasks又はrun-workers(-daemon)スクリプトの実行時に同期されます。 | チェックあり |
CMSからBlobへの同期処理は、run-workers-daemon スクリプト経由で実行します。run-workers-daemon はサーバーに常駐するPerlスクリプトです。
ファイルやディレクトリの監視との組み合わせ
常駐プロセスとして実行する run-workers-daemon では、ファイルやディレクトリの監視を行うことができます。これを行うには、--watch_path にディレクトリまたはファイルのパスを指定します。指定したパスがディレクトリの場合はディレクトリ内のファイル、ファイルの場合はそのファイルが生成・削除・更新された時に処理を行うことができます。
--watch_path 及び --watcher=1 オプションを付けてスクリプトを起動することで、ドキュメントルートの監視を行い、「新規追加」「更新」「削除」されたファイルの情報を検知してプラグインに渡します。
CMS機のタスクスケジューラの設定
30秒間隔でファイル更新監視する場合は、以下のように起動するように設定します。lifetime オプションを付けるとその時間経過後にプロセスが終了しますので、3300 を指定すると55分で一旦終了します。タスクスケジューラで1時間に一回起動するようにすると良いでしょう。
/c cd /d C:\mt & perl.exe tools\run-workers-daemon --interval 30 --lifetime 3300 --watch_path c:\webdata\contents --watcher 1
あわせて、以下の2つの指定をタスクスケジューラに設定します。
# 例: 10分おきに起動(転送失敗時にキューに保存された差分反映をリトライするための設定)
/c cd /d C:\mt & perl.exe tools\run-workers --jobs AzureBlobStorage::Worker::SyncTo
# 例: 15分おきに起動(run-periodic-tasksの代わり※)
/c cd /d C:\mt & perl.exe tools\run-tasks
※ run-periodic-tasks では、Task、Workerをすべて実行してしまうため、run-workers(-daemon) の処理と被らないようにするために run-tasks を起動するようにします。
フロント機側のタスクスケジューラの設定
フロント機側の同期処理については、Perl版とPHP版を用意しています。常住プロセスにする場合はPerl版を、フロント機の負荷を少しでも下げたい場合はPHP版を利用してください。
Perl版
/c cd /d C:\mt & perl.exe tools\run-workers-daemon --interval 30 --lifetime 3300 --jobs AzureBlobStorage::Worker::SyncFrom
PHP版
/c cd /d C:\mt & php -f C:\mt\plugins\AzureBlobStorage\php\Worker\worker.php
PHP版を利用する場合、PEARの HTTP/Request2.php 及び Net/URL2.php が必要です。また、PEARのパスをmt-config.cgi又は管理画面のMT環境変数に指定する必要があります。
PHPPearDir C:\webdata\pear
必要に応じてAzCopy(Microsoft製のコマンドラインツール) によるフルバックアップ(フル反映)を走らせても良いかもしれません。但し、AzCopyでは削除されたファイルの反映や差分転送ができないため、深夜に行うか、上記の設定を組み合わせて設定する(50分常駐し、常駐スクリプトが終了した後一時間に一回AzCopyを起動するなど)ような設定をお勧めします。
AzureBlobStorage の価格 (税別)
価格 : 100,000円 (初年度サポート込み : 次年度以降20,000/年)
- PowerCMS のライセンスが別途必要です。
- PowerCMS Advanced については無償バンドルされます。
- Movable Type 単体での利用をご検討の場合にはお問い合わせください。
コメントを投稿する