技術ブログ - 毎日が成長！

2011年11月 のアーカイブ

次ページへ »

FMS on AWSを動かしてみる。

2011年11月21日 by chiba

on

はじめまして、開発担当の千葉です。

Adobe社がモバイル向け「FlashPlayer」の開発中止を発表した矢先ですが
空気を読まずにFlashネタを投稿させて頂きます。
（モバイル版Flashについては、カスリもしないので悪しからず）

今回は、EC2上にビデオ・オン・デマンド環境を構築してみたいと思います。
「メディアサーバ」には「Flash Media Server（以下、FMS）」を利用します。

これまで、『Flash Media Serverは非常に高価』と言われてきました。
その為、LGPLライセンスで提供されてる「FMS」のクローンである
「red5」が採用されるシーンを多く見聞きしてきました。

「red5」を提案する際のイメージは、こんな具合かな？


でも、実際は「red5」ではサーバサイドとクライアントサイドで開発言語が違っていたり
RTMPEに未対応だったりと、すこしカユいところがありました。

そんな中、2011年04月に東京リージョンでも「FMS」がプリインストールされた
AMIが利用可能となりました。「Adobe Flash Media Server on Amazon Web Services」

これにより、イニシャルコストはサブスクライブ代金の500円のみで
『インストールの手間なし』＋『従量課金』で「FMS」を利用することが可能となりました。
これからは「FMS」が採用されるシーンが”ぐ”っと増えていくのではないかなと思います。

それでは、さっそく環境を構築して動作検証したいと思います。

1. サブスクライブ

以下のページにて「Subscribe now>」をクリックして
クレジットカード情報を入力してサブスクライブしてください。


2. インスタンスの起動

インスタンスは、投稿時の最新版である、AMI ID「ami-bcd366bd」を選択しました。
Instance Typeは、動作検証が目的なので最小構成である「large」とします。
（large以下は選択できません）

3. Security Groupの設定

以下の接続を許可します、詳細はリンクを参照してください。
「FMS」が使用するポートについて

tcp

  • 22
  • 80
  • 443
  • 1111
  • 1935
  • 8134

udp

  • 1935
  • 19350-65535

4, sshでの接続

まずは、sshでログインします。

$ ssh -i ~/.ssh/example.pem root@ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com
Last login: Wed mm dd hh:mi:ss yyyy from xxx.xxx.xxx.xxx
       ___     _       _
      /   |   | |     | |
     / /| | __| | ___ | |__   ___
    / /_| |/ _  |/ _ \|  _ \ / _ \
   / ___  | (_| | (_) | |_) |  __/
  /_/   |_|\__,_|\___/|____/ \___|
  Revolutionize Interactive Media Experiences

  Adobe Systems Incorporated
  Adobe Flash Media Server on Amazon Web Services
  Version: 4,0,3,8001             AMI Version: r1

  Product Information: http://www.adobe.com/go/fmsaws
  Support Forums: http://forums.adobe.com/community/flash/flash_media_server
  Paid Product Support: http://www.adobe.com/support/flashmediaserver/

[root@ip-xxx-xxx-xxx-xxx ~]#

5. 時刻の設定

[root@ip-xxx-xxx-xxx-xxx ~]# cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

6. 動画コンテンツ等の設置ディレクトリ変更

このままでも利用できるのですが、動画ファイル・ログファイル等はEBSに設置し
可用性を高めたいと思います。

6-1. fmsの停止

[root@ip-xxx-xxx-xxx-xxx ~]# /etc/init.d/fms stop

6-2. EBS Volumeの作成

以下の手順で、EBS Volumeを作成します。
[AWS Management Console] -> [EC2] -> [ELASTIC BLOCK STORE:Volumes] -> [Create Volume]

6-3. EBS VolumeのAttach

作成したEBS VolumeをFMSサーバの「/dev/sdf」に設置します。

6-4. EBS Volumeのファイルシステム作成、マウント

[root@ip-xxx-xxx-xxx-xxx ~]# mkfs -t ext3 /dev/sdf
[root@ip-xxx-xxx-xxx-xxx ~]# mkdir /mnt/ebs
[root@ip-xxx-xxx-xxx-xxx ~]# mount /dev/sdf /mnt/ebs

6-5. applicationsディレクトリの移動

[root@ip-xxx-xxx-xxx-xxx ~]# mv /mnt/applications /mnt/ebs/applications

【設定ファイルの修正】/opt/adobe/fms/conf/fms.ini

LIVE_DIR = /mnt/applications/live
VOD_DIR = /mnt/applications/vod/media
VHOST.APPSDIR = /mnt/applications
↓
LIVE_DIR = /mnt/ebs/applications/live
VOD_DIR = /mnt/ebs/applications/vod/media
VHOST.APPSDIR = /mnt/ebs/applications

【設定ファイルの修正】/opt/adobe/fms/Apache2.2/conf/httpd.conf

HttpStreamingLiveEventPath "/mnt/applications"
HttpStreamingContentPath "/mnt/applications"
↓
HttpStreamingLiveEventPath "/mnt/ebs/applications"
HttpStreamingContentPath "/mnt/ebs/applications"

6-6. webrootディレクトリの移動

[root@ip-xxx-xxx-xxx-xxx ~]# mv /mnt/webroot /mnt/ebs/webroot

【設定ファイルの修正】/opt/adobe/fms/conf/fms.ini

VOD_COMMON_DIR = /mnt/webroot/vod
↓
VOD_COMMON_DIR = /mnt/ebs/webroot/vod

【設定ファイルの修正】/opt/adobe/fms/Apache2.2/conf/httpd.conf

DocumentRoot "/mnt/webroot"
<Directory "/mnt/webroot">
HttpStreamingContentPath "/mnt/webroot/vod"
↓
DocumentRoot "/mnt/ebs/webroot"
<Directory "/mnt/ebs/webroot">
HttpStreamingContentPath "/mnt/ebs/webroot/vod"

6-7. logsディレクトリの移動

[root@ip-xxx-xxx-xxx-xxx ~]# mv /mnt/logs /mnt/ebs/logs

【設定ファイルの修正】/opt/adobe/fms/conf/fms.ini

LOGGER.LOGDIR = /mnt/logs
↓
LOGGER.LOGDIR = /mnt/ebs/logs

6-8. FMSの起動

[root@ip-xxx-xxx-xxx-xxx ~]# /etc/init.d/fms start

7. サンプルページへの接続

ブラウザからFMSサーバの「Public DNS」に記載されているアドレスへアクセスしてみましょう。
ページ中心部で動画が自動再生されれば、まずは環境構築完了です。

この様に、「手順6. コンテンツをEBSに(ry」が不要であれば
10分とかからずに、EC2上にビデオ・オン・デマンド環境を構築が可能です。

携帯電話やスマートフォンの普及で、動画の撮影がとても身近になったので
配信環境がもっと簡単に持てるようになればオモシロいだろうな。。。と思う秋の夜長なのでした。

 

タグ:, , ,

感動のクラウド転職（アフター８パスポート）開催レポート

2011年11月10日 by hashiva

こんにちは、羽柴です。

以前に当社代表の大石が AWSユーザー会（JAWSUG）にて発表したネタ枠LTにて、「アフター７パスポート」なるものを紹介させていただいたのですが、その中で今回は掲載OKを快くいただいた事例をご紹介したいと思います。

ちなみにこちらがネタ枠LTの内容です。

2011年7月 第9回JAWS-UG Cloudworksアップデート

View more presentations from Serverworks

今回は19時では間に合わないとのことで20時からとなりアフター８パスポートになりました。

ご来訪いただいた方は、@dz_ことO平さん。

まずは簡単に私から当社概要を熱く語り涙していただき、その後社内見学、そして代表大石による焼鳥屋での厳しい面接が始まりました。 ここでO平さん、AWSのインスタンス操作で言うところの stop を実行、記念撮影をして和やかに終了しました。

以上、ネタブログでした。大変失礼いたしました。

サーバーワークスではプログラマやインフラエンジニアなどまだまだ人材を募集しておりますのでぜひぜひご応募ください。

どうもありがとうございました。

 

HeartBeatとElastic IPを使用した冗長化構成をテストする

2011年11月4日 by yanase

こんちには！ インフラエンジニアの柳瀬です！

AWSにはElastic Load BalancerやRDSのMulti-AZなど冗長化を構成する上で便利な機能が盛り込まれています。
今回は英語版のフォーラムで紹介されているElastic IPとHeartBeatを使用した冗長化を試してみました。

今回テストを行った環境は以下の通りです。

  • Ubuntu 10.04 LTS
  • HeartBeat 3.0.3

それでは環境を用意しましょう。これから記載する設定はHAを構成するノードそれぞれで行ってください。
まずはそれぞれのUbuntuにHost名を定義します。

$ vi /etc/hostname
  1 heartbeat01

次にHeartBeatをインストールして設定を行います。

$ sudo apt-get install heartbeat

$ sudo vi /etc/ha.d/ha.cf
  1 logfile         /var/log/heartbeat.log
  2 node            heartbeat01 heartbeat02
  3 keepalive       1
  4 deadtime        10
  5 ucast           eth0 10.150.170.180 #internal IP of the peer
  6 auto_failback   no

$ sudo i /etc/ha.d/haresources
  1 heartbeat01 elastic-ip

$ sudo vi /etc/ha.d/authkeys
  1 auth 1
  2 1 sha1 yourpassword

Elastic IPの付け替えのスクリプトに使用しているツールをインストールします。

$ curl https://raw.github.com/timkay/aws/master/aws -o aws
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 76826  100 76826    0     0  43721      0  0:00:01  0:00:01 --:--:-- 80869

$ sudo mv ./aws /usr/local/bin/
$ chmod +x /usr/local/bin/aws 

$ vi .awssecret
  1 YOURACCESSID
  2 YOURSECRETACCESSKEY

$ chmod 600 .awssecret
$ sudo cp .awssecret /root/

$ aws describe-addresses --region ap-northeast-1
+---------------+------------+
|   publicIp    | instanceId |
+---------------+------------+
| 111.12.123.12 | i-xxxxxxxx |
| 111.21.210.21 |            |
+---------------+------------+

最後にElastic IPのつけかえを行っているスクリプトを用意します。
※例では東京リージョンを指定していますが、こちらはそれぞれの環境で変更してください

$ sudo vi /etc/init.d/elastic-ip
  1 #!/bin/bash
  2
  3
  4 MY_ID="i-6efaef6f" # different for each node
  5 ELASTIC_IP="176.32.87.217"
  6 REGION="ap-northeast-1"
  7
  8 case $1 in
  9     start)
 10         aws associate-address "$ELASTIC_IP" -i "$MY_ID" --region "$REGION" > /dev/null
 11         echo $0 started
 12         ;;
 13     stop)
 14     aws disassociate-address "$ELASTIC_IP" --region "$REGION" > /dev/null
 15         echo $0 stopped
 16         ;;
 17     status)
 18     aws describe-addresses --region "$REGION" | grep "$ELASTIC_IP" | grep "$MY_ID" > /dev/null
 19     # grep will return true if this ip is mapped to this instance
 20     [ $? -eq 0 ] && echo $0 OK || echo $0 FAIL
 21     ;;
 22 esac

$ chmod +x /etc/init.d/elastic-ip

最後にHeartBeatを実行して準備完了です。

$ sudo /etc/init.d/heartbeat start

動作確認として以下のようにHeartBeat01のHeartBeatを停止してみると、無事にElastic IPが02に移動しています。

$ sudo /etc/init.d/heartbeat stop

これはあくまでHeartBeatを使用してElastic IPを付け替えるだけなので実際にはデータはS3に外出ししたり、lsyncdなどのツールでサーバ間で同期をとるなどの設計が必要です。
今回は通常のEC2インスタンスで実験を行いましたが、ローカルIPが固定出来てElastic Load Balancerが使えないVPCとかではニーズがありそうですね。

 

タグ:, , ,

次ページへ »

PAGE TOP