winds.from.oz 技術メモ

Category: AWS

MediaLiveをCloudWatchで監視する

Posted:   |   Categories: AWS   |   Tags: AWS, CloudWatch, lambda, MediaLive

背景 MediaLive ですが、いろいろなエラーを通知してくれます。 やれ「RTMP 接続が切れたよ」とか「オーディオ入力 or ビデオ入力が無いよ」とかですね。 通常、ライブ配信が始まる前は当然、MediaLive への入力は無いはずなので、通知は構わないのですが、 ライブ配信中に出ると、それはもうトラブルシューティングの情報の一つとして重要なものになります。 ( というか当初、エラーは出てるっぽいし、挙動はおかしいんだけど、どんなエラーが出てるか分からないケースがあって窮地な時がありました ) 今は管理画面の[ channels ]->[ 目的のチャンネル ]->[ Alerts ]から確認できます。が、ログとして残しておくのは良い事だと思います。 このエラー出力のフォーマットは決まっている訳ではなく、たまに変わります。ので 『あー、エラー出力が変わったからアラートが上がらなくなったのね』、という事がログを残しておくと分かります。 手順 WebUI SNS トピック作成 SNS のページ( https://ap-northeast-1.console.aws.amazon.com/sns/ )を開く [ トピック ]->[ 新しいトピックの作成 ]->トピック名の入力、私は[ MediaLiveEvent ]、表示名[ MediaLiveEvent ]と入れてみた 作成したトピックの ARN をコピペ arn:aws:sns:ap-northeast-1:1111111111111:MediaLiveEvent ( 同じ SNS 内の左側メニュー )[ サブスクリプション ]->[ サブスクリプションの作成 ] [ トピック ARN ]に先程作成した MediaLive のトピックの ARN を入力 Read more...

redisのスケールダウン手順

Posted:   |   Categories: AWS   |   Tags: AWS, ElastiCache

redisのスケールダウン手順 手順 大きな作業の流れ。このページから複数ページに飛ぶようになっているので、作業ボリュームを見誤らないように。 https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/Scaling.RedisStandalone.ScaleDown.html バックアップを取得する( m3インスタンス以上でないとバックアップは取れない模様。t2で検証したが取れなかった ) バックアップ自体は無停止( 内部的にはredisのBGSAVEが動いているようだ ) Webコンソールでのステータスは[ snapshotting ]に変わる。 バックアップから復元する バックアップ完了後、バックアップイメージから新しく立ち上げ直す。 既存のクラスターは削除する。 エンドポイントを付け替える、などを期待して検証したが、そういう機能は無かった。 https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/backups-restoring.html#backups-restoring-CON [ 管理コンソール ]->[ バックアップ ]->該当バックアップを選択->リストア [ クラスターID ]は作成したいエンドポイントを考慮して正確に作成する 動作確認 キーが帰ってくるか redis-cli -p 6379 -h test.hoge.ng.0001.apne1.cache.amazonaws.com --scan --pattern '*' | less redis-cli -p 6379 -h test.hoge.ng.0001.apne1.cache.amazonaws.com GET _PHCRhoge.v2.user-status-11111 Read more...

MediaLive+MediaStore+CloudFrontで手軽に動画配信

Posted:   |   Categories: AWS   |   Tags: CloudFront, MediaLive, MediaStore

2018年初頭 ライブ配信基盤を AdobeMdiaServer から MediaLive によるライブ配信に切り替えました。 2020年以降ですとVimeo Liveが有力候補です。 背景 動画配信システムだけで良いのでシンプルに立てたい( カメラの映像を手っ取り早くユーザに届けたい ) 必要なときだけ配信システムを立てて終了したい。 似たような案件ができたときに、似たようなシステムをスピーディーに構築したい 現状、EC2 で AdobeMediaServer 立ててライブ配信している AdobeMediaServer のバージョンアップ? <- それに伴う検証したいか、というと検証工数を割きづらい… その点、AWS 上のサービスなら、後から機能追加があったりする。 今回は使っていませんが、CMAF 対応が追加された。機能追加の検証をクラウドベンダがやってくれて、我々はその時間をもっと別な事に使える。あるいは早く帰れてハッピー。 逆に「我々は配信方法で独自のチャレンジをして差別化を狙うぜ」には向いてない(現状、弊社的にそこでチャレンジはしてない)その観点でのチャレンジは EC2 上で構築した方が様々な戦術がとり得る 何か仕様変更に伴う負荷上昇(対応ビットレートの追加とか)に対する検証工数がビジネスに繋がりにくい なぜ、MediaService? AWS で費用をまとめられる。あとトラフィックが増えた場合、ネットワーク費用のディスカウントができるかもという。 lambda から配信システムの起動/終了とかできそう Azure も魅力的に見える。ただ CLI や API での操作ってどうやるんだろうか、という調査に時間とられそうだった(その点、AWS なら手軽に CLI で操作できるのは知っていった) システム構成 カメラ -> エンコーダー -> MediaLive -> MediaStore -> CloudFront -> Safari CDN でコストを下げつつ、ライブ配信したい構成ですね。 それぞれの役割は MediaLive: RTMP などカメラからの情報を受け付ける。目的の動画フォーマットにエンコードする。ただ、これ自体にはストレージ機能は無い。 MediaStore: CloudFront と経由するためのストレージ Read more...

lambdaのあれこれ

Posted:   |   Categories: AWS   |   Tags: lambda

上限値 Lambda 関数の同時実行 - AWS Lambda 初めてのLambda 初めてのJavaScript、初めてのAWS Lambda invokeする時のオプション ブラウザから直接invokeする、という方法 AWS Lambdaのコードをローカルで実行する この方法は導入した方が良さそう。デバックスピードを上げられる。 AWS Lambdaのための関数のローカル開発とテスト handlerに渡ってくるeventとcontextというオブジェクトについての補足 event: 実際に渡ってくるイベントのデータ(S3のアップデートとかKinesisのレコードとか）。 context: Lambda functionの呼び出しコンテキスト。done()というAPIを呼び出すと関数が終了するのだが、コードをちょっと追いきれてないのでとりあえず単純にreturnするだけな感じにstub化。ちなみにcontextオブジェクトのダンプは以下のとおり。done()の中で呼び出されているpostDone()は後で追ってみる。 AWS Lambdaの関数をnpmでパッケージ管理 CLIで使う http://qiita.com/toshihirock/items/8d06a524df79e7bb675c Role作成 function作成( ファイルのアップロード ) Scheduleイベントで EC2を自動起動終了 Amazonのサイトの説明、aws-cliで設定している ユーザがEC2を起動 => CloudTrailがEC2起動を検知してS3バケットにログ記録 => Lambdaファンクション起動 => ログから実行ユーザを特定してEC2にタグ付け LambdaでEC2作成者をタグ付けする AWSへの接続に使う AWSのリファレンスを見て、左側のメニューから使いたいサービスをクリック トラブル集 node.jsでLambdaを実装した時のトラブル&解決策集 Read more...

AWS MediaLive + MediaPackageを使ってライブ配信

Posted:   |   Categories: AWS   |   Tags: AWS, MediaLive, MediaPackage

目的 2017/11 にリリースされた AWS メディアサービスを使って、ラクして動画配信したい。 できる限り遅延は無い方向で！ まずざっくりとした使い方を把握して、どの程度、細かく設定できるのか知りたい！ ( 実際のスマホでの確認までではなく、PC 上でエンコードされたライブが見えるところまでが今回のゴール ) 作りたいシステム構成 ライブカメラ -> Wirecast -> RTMP(ないし RTSP) -> エンコーダー -> CDN -> ユーザ CDN 使うと大規模に安く配信できるので使いたい。が、当然できる限り遅延は少なくしたい。 感想 あとマルチビットレートの設定が最初から入っているのとか、冗長化を初めから考慮されてる設定は素敵。 2017/12/04 時点では、MediaPackage で選択可能な配信フォーマットは HLS のみでした。Mpeg-DASH とか必要な場合は、対応待ちです。 ただ、UI というか画面遷移が迷うところが多いし、一通り設定が完了しないと、 カメラからのデータを送れないしで、挫けそうになりました。この辺は時間が解決してくれるよ！という気持ちで。 背景 EC2 で wowza や AdobeMediaServer 立てて運用するのはもちろんありだし、カスタマイズ性はこちらの方が高そうではある(インスタンスプランも選択できるし) が、運用コストはかかるのでありできれば減らしたい。 AWS メディアサービスって?(複数サービスの集合でした) 参考 クラウドベースの映像処理、保存、収益化 classmethod 様 2017/12 現在、MediaConvert、MediaLive、MediaPackage、MediaStore、MediaTailor という 5 つのサービスで構成されています。 このうち、自分に必要そうな『MediaLive』『MediaPackage』のみを使ってみました。 VOD、および他動画解析サービスなどと連携する場合は S3 に保存する MediaStore も併せて使う必要があるかもしれません。 設定方法 MediaLive について (先に MediaPackage から設定する必要があります ) 当初、名前に Live ってあるし、MediaLive だけで完結できるか? Read more...

AWS SQSを使う際に調べた事

Posted:   |   Categories: AWS   |   Tags: lambda, SQS

API リファレンス Class: AWS.SQS — AWS SDK for JavaScript 送信/受信/削除 AWS SDK for Node.js を用いた SQS の操作 – ゴミ箱 FIFO になって情報古くなってる面もあるが有益な情報 【AWS】SQS をただただ触ってみただけの話 - ニクニクドットミー Amazon SQS を利用する前に抑えておくべき 7 つのポイント - Qiita Amazon SQS を使う前に知っておきたい基本的なこと - Qiita Schoo の非同期パイプライン処理について - Qiita 『ロングポーリングして』という話は下記でも触れてる(一番下の方) フレクトのクラウド blog(New): lambda から lambda を起動するリレー方式 SQS コンシューマ ショートポーリングの場合、キュー内のメッセージ数が少ない(1000以下など)場合、 キュー内のメッセージ数で重み付けされたサンプル数のサーバにしか問い合わせにいかないため、 MaxNumberOfMessagesに指定した数より少ないメッセージしか返ってこず、 キュー内のメッセージ数が極めて少ない場合、メッセージが返却されないことがあるため、 繰り返しreceiveMessageを発行する必要がある。 という理解であってるんですかね？ ロングポーリングの場合はどうなんでしょうか？ 次の記述が見つかりました。 どうやらロングポーリングの場合、上記の問題は発生しないようです。 (receiveMessageのWaitTimeSecondsを1以上にすると、ロングポーリングになる) Lambdaはコンピューティング時間で課金されるため、なるべく「待ち」の時間は減らしたいところですが、ショートポーリングで1,2件づつメッセージを処理するよりは効率が良さそうです。 ログポーリング必須… ロングポーリングを利用する(これは必須。劇的にリクエスト数が改善されます) ロングポーリングは管理画面から設定できるので簡単。 送信側はバッチリクエストを利用すると良い(SendMessageBatch) 受信側も複数メッセージを一度に受信すると良い(MaxNumberOfMessages) FIFO に関する情報 【新機能】Amazon SQS に FIFO が追加されました！（重複削除/単一実行/順序取得に対応） ｜ Developers. Read more...

CloudFrontに関する雑多なメモ

Posted:   |   Categories: AWS   |   Tags: CloudFront

障害時の対応に付いて AWS - Amazon CloudFront の障害に備えてフェイルオーバーを設定する ログフォーマット s3, MediaPackageをオリジンとして使った時 ウェブディストリビューションでの Amazon S3 オリジン、MediaPackage チャネル、およびカスタムオリジンの使用 TTLがどのように効くのか 【新機能】Amazon CloudFrontに「Maximum TTL / Default TTL」が設定できるようになりました！ ｜ Developers.IO パスパターンはワイルドカード このため、HLSを配信するCDNは様に設定しました。 /studio*-lq.m3u8 /studio*.m3u8 重要 エラーページについて 『どの程度エラーページを保持するべきか』という設定がある エラーレスポンスのカスタマイズ - Amazon CloudFront CloudFrontのエラーキャッシュのTTLを変更する - Qiita カスタムオリジンの話 別ドメインをオリジンとする。大抵のサービスはこれなのではないか カスタムオリジンの場合のリクエストとレスポンスの動作 - Amazon CloudFront 初期設定 参考 キャッシュしないCloudFrontを設置する | // sakura note Minimum TTL / Maximum TTL の話 一覧がある 【新機能】Amazon CloudFrontに「Maximum TTL / Default TTL」が設定できるようになりました！ ｜ Developers.IO 「Mimimum TTL / Maximum TTLはヘッダより強い」 「ブラウザのキャッシュはヘッダが優先される」 「何も設定しなければDefault TTLの値になる」 くらいのざっくりで覚えておいて、実際に設定する際にこの記事を参考にして頂ければと思います。 CDNのレイテンシ比較 Is TLS Fast Yet? Read more...

cloudwatchメモ

Posted:   |   Categories: AWS   |   Tags: CloudWatch

クォータ 上限値 EC2 から Logs に飛ばす方法 結構、簡単に飛ばせる。 AWS CloudWatch Logs エージェントで Amazon EC2 上の Nginx の access.log , error.log , php-fpm error.log , Linux の messages , secure ログを収集する セットアップ EC2 の IAM ロールに下記を追加 CloudWatch Logs でのアイデンティティベースのポリシー (IAM ポリシー) の使用 実際のケースだと EC2 には既に IAM ロールが設定済みの場合が多いと思うので、下記を追記する形になる [ IAM ]->[ ポリシー ]->[ ポリシーの作成 ]->[ JSON ]->テキストフィールドに下記の内容入り込んで[ Review Policy ] ポリシー名には[ CloudWatchLogs ]とした。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogStreams" ], "Resource": [ "arn:aws:logs:*:*:*" ] } ] } ついで[ ロールの作成 ]->[ 使用するサービス ]は EC2 にして、名前は[ webfront ]などにしてロールを作成した。 Read more...

aws/codebuild

Posted:   |   Categories: AWS   |   Tags: AWS, CodeBuild

CodeBuildで設定した方が良さそう環境変数リスト ※ サービス固有に設定した方が良さそうな環境変数もあるので注意が必要( たとえば外部サービスの鍵など ) 変数 用途 例 ${AWS_ID} 開発と本番で共通のbuildspec.ymlを利用したい。それぞれAWS IDが異なるので環境変数で設定可能にする。 ${API_ROOT} 開発時に参照するエンドポイントと本番系は異なるため 開発: dev.hoge.com 本番: wwww.hoge.com ${NODE_ENV} 開発時はdev、本番時はproductionを指定することが多い( productionを設定していると、yarn install時、devDependinciesが無視される) devはMac上の開発環境で使い、ECSはproductionを用いる 開発: dev 本番: production ${ECS_TASK} 開発時はenv**という名前でECSのリソース(タスク定義、サービス)をアサインする。本番系はenvではなくサービス名称を用いるため異なる。 開発: dev32 本番: wwwなど ${ECS_SERVICE} 開発、本番で異なるため ${ECS_CLUSTER} ECSクラスター名も開発と本番で異なる(開発環境は都度クラスターを構築するのは工数がかかりすぎるので統一している。が本番系は別にクラスターを構築し、コンテナ間でリソースの上限やお互いのサービスの負荷の影響を与える可能性を考慮して、クラスターレベルで分離している) ${API_SHARED_ACCCESS_TOKEN} ${AWS_ACCOUNT_ID} ${AWS_DEFAULT_REGION} ${HOST_NAME} ${IMAGE_REPO_NAME} ${IMAGE_TAG} ${PORT} ${WWW_ROOT} ECRのタグ( buildspec内でdocker pushしている )ポリシー 開発用のECSタスク定義で使用するDockerイメージには dev のタグをつける イメージに対しては必ずタグをつける( タグがないイメージにアクセスしにくいので、実質的にバックアップの意味にもならない。 Read more...

aws/codebuildで設定を複製する

Posted:   |   Categories: AWS   |   Tags: AWS, CodeBuild

CodeBuildの設定を複製する 環境固有の環境変数の修正がある。 既存の設定情報を取得する aws codebuild batch-get-projects --names hoge-web | jq '.projects[0] > ~/original.json 取得したjsonファイルを修正する 比較として、CodeBuildを作成する際に参考になるjsonは aws codebuild create-project –generate-cli-skeleton で取得可能 取得したjsonと –generate-cli-skeleton で取得した雛形を比較しながら、 取得したjsonを修正する。 name を修正 arn は新規に割り振られるので削除 environment.environmentVariables を修正 IMAGE_REPO_NAME SERVICE_NAME logsConfig.cloudWatchLogs.groupName を修正 badge を削除 反映 aws codebuild create-project –cli-input-json file://修正したもの.json Read more...