この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、大前です。絶賛 AWS re:Invent 2019 に参加中です。
早速セッションレポートの方書いていきたいと思います。
セッション概要
原題
Streaming media workloads within the AWS Well-Architected Framework
スピーカー
Kiran Patel - Solutions Marketing Manager, Amazon Web Services
Shawn Przybilla - Solution Architect - M&E, Amazon Web Services
Bryan Samis - Sr. Solutions Architect, Amazon Web Services
概要
The Well-Architected Framework can help cloud architects build secure, high-performing, resilient, and efficient infrastructure for their applications. Join AWS solutions architects for an interactive discussion that examines streaming media workloads alongside the architectural pillars and best practices found within the AWS Well-Architected Framework.
概要（機械翻訳）
適切に設計されたフレームワークは、クラウドアーキテクトがアプリケーション向けに、安全で高性能で、復元力があり、効率的なインフラストラクチャを構築するのに役立ちます。 AWSソリューションアーキテクトに参加して、AWS Well-Architected Framework内にあるアーキテクチャの柱とベストプラクティスとともにストリーミングメディアワークロードを調べる対話型ディスカッションを行ってください。
レポート
所感
本セッションは、Chalk Talk というスピーカーがセッション参加者に QA などを投げかけながら進める形式のセッションになります。
英語力ゼロの自分としてはビクビクしながら参加してきましたが、結果的にとても楽しい1時間を過ごすことが出来ました。
内容としては、例として挙げられたメディアワークロードに対して、 AWS が提供する AWS Well-Architected フレームワーク に沿って QA を交えながら改善案を出していくというものでした。
Well Architected フレームワークをメディアワークロードに対して適用してみるという体験を初めてしたため、非常に面白く、また学ぶことも多かったです。
レポート
Well-Architected フレームワークについて
まずは Well-Architected フレームワークについての軽い説明がありました。
「使った事ある人？」という質問には会場の 1/3 ぐらいが手を挙げていたでしょうか。
今回は 5本の柱に沿ってワークロードの評価をしていきます。
柱はそれぞれ以下が存在します。
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
また、各柱にはそれぞれ設計原則というものがあります。
ご存知ない方は、ホワイトペーパーを一読しましょう
シナリオベースのワークタイム
Well-Architected フレームワークの説明をしたのち、いよいよ本題のワークが始まりました。
「Are you well-architected?」、決めゼリフとして使っていきたいですね（？）
以下のシナリオが提示されました。ざっくり意訳すると以下になります。
- メディアを扱う会社でライブストリーミングのマネージャーになりました
- ライブストリームをダウンさせないようにシステムを維持する必要があります
- 昨年のライブストリーミングイベントで使用されたアーキテクチャがあるが、非常に原始的
- カメラからラップトップへソースを取り込み
- 取り込んだソースを標準のビットレートに変換
- 単一のEC2インスタンスに変換したソースを送信する
- クライアントのデバイスは直接EC2に繋がっている
- SecuritGroupの設定も全世界にオープン
ホワイトボードに絵がかかれました。これを修正していくのが今回の目的ですね。ラップトップに「Windows XP」と書いてあるのがじわじわきます。
まず最初の質問は「現時点でこのアーキテクチャの良い点は？」でした。これに対し、以下の意見が挙がっていました。
- 安い
- シンプルなので管理が楽
「基本的にトレードオフなので、明らかに改善点のあるアーキテクチャでも良い点は存在している」という言葉が印象的でした。
次の質問は以下です。
「改善を行うにあたり、知っておくべきことは？」
以下の意見が出ていました。
- 予算は？
- 想定している視聴者は何人？
- どのぐらいの回復力が必要とされている？
- 視聴者は地理的にはどこに存在している？
会場からはどんどん意見が出てきており、ほとんどの参加者が実際のワークロードを動かしている人だったのではと思います。
ここまで話したら、いよいよ Well-Architected フレームワークの出番です。
各柱についてスピーカーが質問を投げかけ、実際にどんな改善をするべきかについて意見が出ていました。
信頼性
設計原則
- ネットワークリンクの多様化
- 不測の自体に備えた設計
- 使用パターンの想定
- 自動的な変更管理
- 水平スケーリング
設計原則を満たしているかについてのチェック項目
- 大きなイベントを計画する前にサービスの制限を確認していますか？
- CDNを使っていますか
- 求められている信頼性や可用性から遠ざかっていませんか？
- 変更によるエンドユーザへの影響を把握していますか？
- 物理的な劣化に対する対策は出来ていますか？
ここで出た意見としては、ネットワーク経路の冗長化、インスタンスのMulti-AZ配置、AutoScalingの使用、CloudFrontの使用などでした。
パフォーマンス
設計原則
- 高品質のソースから始める
- 転送中のメディアソースの最適化
- 転送時のビットは少なく
- メディア処理の並列化
- 頻繁、かつ早めにキャッシュを行う
設計原則を満たしているかについてのチェック項目
- コンテンツのキャッシュや配送についてのアプローチは何ですか？
- メディアオリジンには何を使っていますか？
- メディアの配送に最もパフォーマンスが発揮されるプロトコルを選んでいますか？
- クライアント体験の向上と帯域幅の削減のために、どんなトレードオフを許容しましたか？
ここで出た意見としては、カメラを4Kにする、ラップトップではなく専用のエンコーダーを使う、圧縮アルゴリズムを使用する、等が出ました。
EC2 ではなく、MediaServices を使用するという選択肢ももちろんありました。
また、AWS がサポートしている Zixi や Rist といったプロトコルや、QVBR といった技術の使用も推奨されていました。
セキュリティ
設計原則
- 全レイヤでセキュリティを適用する
- 転送中および保存中のデータを保護する
- セキュリティのベストプラクティスを自動化する
- コンテンツを分離する
- セキュリティイベントの準備
- トレーサビリティを有効にする
設計原則を満たしているかについてのチェック項目
- コンテンツ保護やコンプライアンスの要件は何で、それを AWS でどう実現しますか？
- 予期しないデータアクセスパターンはどのようなものですか？
- 第三者とメディアやインフラのセキュリティについての責任を共有していますか？
ここで出た意見としては、通信の暗号化や、WAFやShieldの使用、OAIでオリジンアクセスを防ぐ、等でした。
コスト最適化
設計原則
- 最も効率的な圧縮アルゴリズムを使用する
- タスクに適切なリソースを作成する
- コストの分析と属性付け
- 必要に応じてマネージドサービスを使用する
設計原則を満たしているかについてのチェック項目
- コンテンツの管理や処理にかかるコストをどうやって最適化しますか？
- 使用する帯域を最小限にしつつ、どのように高品質なビデオ配信を達成しますか？
- どのトレードオフを許容しましたか？
ここからは時間も迫っていたこともあり、あまり議論は交わされませんでした。
必要以上に大きいインスタンスを選ばない、等の意見が出ていました。
運用上の優秀性
設計原則
- 操作はコードベースで行う
- 失敗を予測する
- 運用の障害から学ぶ
- ベースラインを知る
- 明確に定義され、実践されたランブックを持つ
設計原則を満たしているか確認するための質問
- 大きなイベントに対してどう準備をしますか？
- どのようにビデオ配信システムに対する変更の実装やテストを行いますか？
- どのようにユーザ体験をモニタリングしますか？
終わりに
「Streaming media workloads within the AWS Well-Architected Framework」の参加レポートでした。
Well-Architected フレームワークをメディアワークロードに適用する体験が非常に楽しく、またスピーカーの喋りがうまかった事もあってか非常に楽しい1時間を過ごすことが出来ました。
もしメディアワークロードのアーキテクチャをレビューするような場面があればこの1時間を思い出したいと思います。
以上、AWS 事業本部の大前でした。
25
