アーカイブ動画
【動画配信】AWSを活用した令和時代のライブ動画サービスの作り方
アマゾンウェブサービスジャパン合同会社
技術統括本部 インターネットメディアソリューション部
部長 / シニアソリューションアーキテクト 廣瀬 太郎氏
最初に登壇した廣瀬氏は、ソリューションアーキテクトチームのリードをしながら、自身もSAとして顧客の支援を行っている。2018年にAWSに入社するまでは、eスポーツやゲーム配信に特化したライブ配信プラットフォーム「OPENREC.tv」のサービスエンジニアとして、配信基盤を始めとするバックエンドシステムの設計開発に携わっていた。
SAの活動のミッションには、外部に向けた技術発信をすることも含まれる。廣瀬氏もこれまでカンファレンスやウェビナーでさまざまな発信をしており、「AWS Media Servicesで始めるライブ動画配信」「AWS上で実装するライブ動画配信のアーキテクチャパターン」で動画などが公開されている。
ライブ動画配信は時流の変化に伴い、配信スタイルも形を変えている。昨今のトレンドは大きく2つ。1つが配信者層の変化である。従来は、動画配信というと情報感度の高いアーリーアダプターが多かったが、様々な SNS や自己表現できるプラットフォームが登場したことで非常に身近な存在となった。
ユーザー駆動のライブ配信（UGC）の場合、配信数が増減するため、技術的な配慮が必要になる。「実はここが難しいポイント」と廣瀬氏は指摘する。ライブ配信はRTMPの接続持続型のプロトコルを使うのだが、一度配信が始まるとサーバを停止したり縮退することが難しくなるからだ。
トランスコーディング処理はコンピュータリソースをそれなりに使うため、常時稼働させるとコスパが悪くなる。配信者の裾野を広げようとすると、配信需要に基づいたスケーリング戦略が必要になる。
廣瀬氏がAWSに入社したタイミングで、AWSは動画関連のマネジメントサービス「AWS Elemental Media Services」をローンチした。非常に良いサービスだが、配信数の増減に対応させるには、チャネルの上げ下げや管理を行うスケジューラの実装が必要になる。ユーザーからも、UGC向けのライブ配信をより簡単にしてほしいという要望が届いていた。
「ユーザーの要望をサービス開発支援のチームにフィードバックし、新機能や新サービスの開発に繋げていくのがSAの役割です。日本だけではなく、時にはUSチームのメンバーと徹底的に議論しました」（廣瀬氏）
AWSは毎年多くの新機能やサービスアップデートを行っているが、その90％がユーザーからの要望に基づいて開発されたもの。残りの10％も、「世の中が必要としている」いう仮説やデータをもとに潜在的なニーズを想像しながら開発されている」と、廣瀬氏は語る。AWSはユーザーファーストで活動しているのだ。
そして2020年、廣瀬氏たちのフィードバックから生まれたのが、「Amazon Interactive Video Service（Amazon IVS）」である。IVSはUGCに特化した、ライブストリーミングのためのフルマネージメントサービスだ。動画に関する知見が十分になくても、簡単に低遅延のライブ配信サービスを立ち上げることができる。
このサービスを使えば、従来のようなチャネルの上げ下げ、余剰管理は不要になる。事前にストリームキーを発行しておくだけで、配信者が配信したいときに配信できる環境を構築できる。さらに、デバイスから最も地理的に近いPoPが自動選択される。もちろんストリーミング機能においては、海外展開も可能だ。
もう一つ重要なことは、簡単に配信できる環境の提供である。これまで配信者はマイクやカメラはもちろん、ミキサーやエンコーダなどを自前で揃えることも珍しくなかった。だが、配信者の層を広げるには、配信のためのリテラシーをなるべく下げる必要がある。例えばスマホだけで配信できるような環境作りが重要になる。
そこでAWSでは、2021年7月にはネイティブアプリケーションからIVSへライブソースを送出できるBroadcast SDKをiOSとAndroid向けに提供。さらにこの7月にはWebブラウザからもIVSにライブソースを送出することが可能となった。この2つの機能強化により、ネイティブアプリケーションやWebアプリケーションで作った映像を、簡単に配信できるようになったのである。
もう一つのトレンドは、リモート化である。コロナ禍以降、さまざまな業務や生活がリモートにシフトした。「配信やライブコンテンツの制作に大きく影響を与えた」と廣瀬氏は指摘する。1on1や対談形式で複数の話者が登場するライブ配信が困難となったのだ。
手っ取り早い方法としてはオンライン会議ツールを使うことだが、収容できる人数には制限があることが多い。数千人、数万人のような大規模な集客が見込まれる場合には、ミーティングそのものをブロードキャストするパイプラインを組み込む必要がある。
Amazon Chime SDKというビデオ通話を実装するためのマネジメントサービスを使えば、アプリケーションの中にn対nのビデオ会議の機能を実装することが可能になる。「だがこの方法は非常にトリッキーだった」と廣瀬氏は振り返る。そこでシンプルに実現できるように、2022年8月、Chime SDKからIVSやMediaLiveへの出力をサポートした。
廣瀬氏は最後に「AWSの新機能や新サービスは皆さんの要望から生まれます。要望があればぜひ、積極的に私たちにぶつけてください」と呼びかけ、セッションを締めた。
【SaaS】テナント分離アーキテクチャとスキルキャッチアップ方法
アマゾンウェブサービスジャパン合同会社
ISV/SaaSソリューション本部
ソリューションアーキテクト 福本 健亮氏
続いて登壇した福本氏は、2020年4月にAWSに新卒で入社。大学・大学院時代は情報工学を専攻し、機械学習を利用して質感を対象とした画像処理や推定の研究をしていた。福本氏が、現在の部署でSAとして活動してきたのは約1年半だが、「実にいろいろな経験をしてきた」と語る。
SAの基本的な活動は「技術的支援に伴うお客さまとのミーティング」「対外的な発表・登壇」「技術コンテンツの作成」の3つ。「ISVやSaaSを提供している顧客が多いため、SaaSに関する知識やスキルを身につけることが必要だった」と福本氏は振り返る。
福本氏はSaaSの開発や運用経験がなかったので、ホワイトペーパーやAWS SaaS Factoryのコンテンツ、AWS SaaS Factory Insights Hub、re:Inventなどイベント動画、ワークショップなど外部向けに公開されているコンテンツを活用して勉強した。
「もちろん社内でも技術・業界に特化した社内コミュニティ、社内勉強会、ナレッジシェアの仕組みなど、キャッチアップの仕組みがあるので、それらも活用しながら日々キャッチアップしています」（福本氏）
福本氏はインプットするだけではなく、アウトプットも積極的に行っている。例えば日本の開発者向けのWebマガジン「buliders.flash」にSaaS関連の記事を寄稿している。またAmazon Web Serviceブログでは「SaaSにおけるテナントリソースへのリクエストルーティングを、JWTを用いて実現する」という記事を執筆している。
SaaSアーキテクチャを考える上で重要なことは、以下の図にあるようにオンボーディングやアイデンティティ、管理とモニタリング、指標と分析など、SaaS全体で共通するコンセプトを考慮に入れつつ、要件に合わせることだと、福本氏は言う。
SaaSにおける一般的なアーキテクチャモデルとしては、専用のリソースを割り当てるサイロモデル、すべてのテナントでリソースを共有するプールモデル、そしてプールモデルとサイロモデルの中間として部分共有するブリッジモデルの3つがある。
「サイロモデル、プールモデルにはいずれも長所短所があります。どちらを使うかというゼロイチの話ではなく、要件に応じて部分的なモデルを組み合わせることが重要になります」（福本氏）
従来、シングルテナントSaaSに対するリクエストをルーティングする手法は、図のようにドメインをベースにしたルーティング、パスをベースにしたルーティングが一般的だった。
だが、福本氏が提案するのは、データをベースにしたルーティングだ。テナントコンテキストというテナントの識別子を一緒に送信することで、該当するテナントを判断してルーティングを行うという方法である。
第一のメリットはテナントごとにサブドメインを払い出したり、それを管理する必要がないこと。第二のメリットは、テナント側からアクセスする先のドメインを変えずに、それぞれのリソースにアクセスできること。第三に、将来的にプールモデルに移行する際も、ドメインは統一されているため、テナントを意識させずに裏側の仕組みだけを変更できることだ。
このアーキテクチャは大きく6つのポイントで構成される。
1. テナントのIDを管理するサービスとしては、Amazon Congnitoを使用。Congnitoで認証し、テナント情報を含むJSON Web Token（JWT）を取得する
2. JWTをリクエストヘッダに含めてAPIゲートウェイに送信する
3. Lambda Autholizerを使用し、JWTの検証と認可を行う
4. Lambdaから返されるテナント情報をヘッダーにセットして後続のサービスにリクエストする
5. Network Load Balancer（NLB）からApplication Load Balancer（ALB）にリクエストを送信する
6. ALBのリスナールールで振り分ける
「NLBやALBを増やしている理由をはじめ、SaaS関連の情報はAWSのブログでも発信しているので、ぜひ役立ててほしい」と参加者に呼びかけ、セッションを終えた。
【ゲーム】仕様変更と戦うためのアーキティテクング技術
アマゾンウェブサービスジャパン合同会社
技術統括本部 ゲームソリューション部
ソリューションアーキテクト 木村 秀平氏
続いて登壇した木村氏は、ゲーム会社やWebベンチャー、個人投資家などを経て、AWSに入社。現在はSAとしてゲーム業界の技術支援を中心とした活動を行っている。
木村氏は、今回はゲーム開発を題材にしているが、他業界でも活用可能だと前置きし、「プランナーから依頼されたオープンワールドのマルチプレイアクションゲームを、PM経由で開発を進めるように指示された、あるサーバー・インフラエンジニアのアーキテクティングの話」を例に、アーキテクティングのポイントを解説した。
ちなみに、オープンワールドのマルチプレイアクションゲームとは、広大な空間をシームレスに移動することができて、操作にリアルタイム性があり、複数人が同時に遊ぶことができるゲームを指す。
アーキテクティングポイント①：事例や経験を活かす
「社内に知見のある人がいないが、新しいゲームとはいえ、あくまでもゲーム。タイトルのシステムを流用すれば、なんとかなるだろう」と軽く考えて開発してみたものの、テスターから「なんとかなっていません」という返答がきた。
では、どうすればいいのか。アーキテクティングのポイントは事例や経験を活かすこと。例えば、今回プランナーから伝えられた近いゲームタイプに、Amazon Gamesの「New World」というタイトルがある。
常時接続で他のユーザーとインタラクションできるゲームでは、スケールアウトに工夫が必要になる。特に数千人が同じ世界を共有しているゲームであれば、その必要性が増す。New Worldでは、1つの世界を複数のサーバに分割して処理するという方法を採っている。
「なぜかというと、距離的に近いユーザーは同じホストに収まるようにし、現実的に相互作用が起こらないユーザーを別のサーバーで処理すれば、ユーザー体験を損なうことなくスケーリングできるからです。このように事例の知識や経験があるかないかで、アーキテクチャの発想に差が出てくるのです」（木村氏）
アーキテクティングポイント②：要件を可能な限り、正確に把握する
事例や経験が役立つという知見を得たサーバー・インフラエンジニアは、3カ月かけて事例と同じように動くゲームを開発した。だがプランナーから「4人対戦なので、1,000人入れる必要はない」と言われてしまう。
アーキテクティングのポイントは、要件を可能な限り、正確に把握すること。例えば、マルチプレイとは具体的に何人なのか、配信地域はどこか、地域移動は可能なのか、一日にアクセスするユーザー数の予測や開発スケジュールなど。「アーキテクチャに関わることは先入観で決めず、必ず確認しましょう」と木村氏は強調する。
アーキテクティングポイント③：負荷試験を実施する
だが、要件をきちんと確認し、リリースしたとしても、プレイヤーから「ログインサーバーが落ちて、ゲームが開始できない」「ラグがひどくてゲームにならない」などのクレームが届くこともある。
ここでのポイントとしては、負荷試験を実施すること。非技術職のメンバーには、負荷試験の実施が頭にない場合もある。機能テストは必要だと認識されているが、インフラのテストは認知度も低い。しかし、負荷試験もアーキテクティングの一貫であり、新しく導入する際は十分試験時間を取ることが必要なのだ。
アーキテクティングポイント④：要件の曖昧さを把握する
また、完璧に要件に合うシステムができたとしても、途中でソロプレイのゲームに変更となるなど、企画ががらりと変わってしまうケースもゲーム業界ではよくあること。今までに作ったことが無駄になると、コストになってしまう。
このようなリスクを防ぐポイントは、要件の曖昧さを把握することである。まだ決まっていないことはもちろん、決定事項がどれだけ変わり得るか想定しておく。曖昧さと戦うには、2-Way doorな設計を行う意識を持つことだ。 「コンポーネント単位で差し替えられるように意識すること。そして、小さく作ってPoCを実施したり、詳細な実装を詰めすぎないことも必要です」（木村氏）
アーキテクティングポイント⑤：要件に照らし合わせてアーキテクティングを行う
リリース後、インフラ費用が高すぎて予算が枯渇するという問題が生じることもある。このような場合のポイントとしては、要件と自社状況を照らし合わせてアーキテクティングを行うことだ。
「アーキテクティングにはさまざまな要素が関わるため、事例や広い技術知識、開発経験、業界知識を身につけ、要件や状況の深掘りは念入りに行うことが必要です。そして仕様変更と戦うため、曖昧さをうまく扱う意識を持つこと。仕様に合わせて柔軟にWell-Architectedなシステムを模索しましょう」（木村氏）
【FinTech】ITインフラに学ぶセキュリティ対策とは
アマゾンウェブサービスジャパン合同会社
スタートアップ事業本部 技術統括部
ソリューションアーキテクト 齋藤 祐一郎氏
最後に登壇した齋藤氏は、2020年4月にAWSに入社し、スタートアップ企業を担当。FinTech企業をはじめとしたスタートアップ企業の技術支援を行っている。直近ではメルカリのフリマアプリや決済サービスのメルペイの開発に携わり、スタートアップの急成長期の課題と向き合い解決してきた。
「スタートアップ企業の最大の特徴は、急成長すること。開発組織や資金調達のあり方など、段階的な成長とは異なった考え方をすることが重要になります」（齋藤氏）
スタートアップチームの活動の中には、スタートアップ企業や起業家に対してAWSの使用を開始する際に必要となるリソース提供を目的とした無料プログラム「AWS Activate」も挙げられる。また、「CTO Night and Day」という技術者同士のネットワークを支援するイベントも開催するなど広範囲に及ぶ。
まず齋藤氏は、「FinTechには特別なセキュリティ対策があると思っている人が多いが、FinTechに限った特別なものはない」と切り出す。どうして金融がセキュリティ対策に厳しいのかというと、それは預かっているものが金融資産であり、問題が発生すると被害が大きくなりがちだからだ。
「金融領域のセキュリティガイドラインは、動画配信やSaaS、ゲーム、すべてのWebサービスで、参考にすることができます。また、その中にはすぐに始められるセキュリティ対策もあります」（齋藤氏）
セキュリティ対策には、大きく分けると予防的統制と発見的統制がある。予防的統制とは事前に潜在的な問題を洗い出し、問題発生を未然に防ぐこと。発見的統制は問題が発生したときに、素早く問題を発見し回復させることである。
これらはそれぞれ、学ぶためのプラクティスやリソースがある。予防的統制の参考になるのが、米国国立標準技術研究所（NIST）が発行した「米国連邦情報システムのセキュリティおよびプライバシー管理の管理策：NIST SP800-53 rev.5」である。その5番目に「職務の分離」という項目がある。
例えばスタートアップ企業では、ITインフラの管理と開発を一人で担っていることも珍しくない。だが、組織が大きくなり、何か起こったときには大きな問題となる可能性がある。お互いけん制し合う状況を作ることが重要となる。
発見的統制も様々な方法があるが、AWSが提供しているのが「Baseline Environment on AWS（BLEA）」である。BLEAはAWSアカウントに対して、安全なベースラインを確立するためのリファレンスCDKテンプレート群だ。
「ノウハウがソースコードに凝縮されているので、エンジニアであれば楽に読めます。カスタマイズして使えるコードのテンプレートなので、ぜひ試してください」（齋藤氏）
AWSのアカウント管理に役立つアーキテクチャも紹介。それが「FinTech Blueprint on AWS」である。Blueprintは、AWSの環境別にアカウントを分けることがポイント。この図の場合は、中央が企業、右がデベロッパー、左がエンドユーザー（商用環境）となっている。
「例えば本番機に入れるのはITインフラエンジニアのみという形で統制を効かせる。またデベロッパーの環境は、デベロッパーが自分たちで管理統制できるようにします」（齋藤氏）
ここでは、パブリックサブネット、プライベートサブネットを用意し、それぞれの業務ごとにサブネットを分割している。各サブネットには必要のない通信は通信させないようにする。それを可能にするのがネットワークアクセスコントロールリスト（ACL）である。
静的安定性の担保は、複数のアベイラビリティゾーンを立てることで実現する。こうすることで片方が止まっても、もう一方で安定性が担保される。
また、安全な接続管理を実現するには、「AWS Client VPN」や「AWS Systems Manager Session Manager」という方法、コンプライアンス準拠を確認するサービスとしては、「AWS Config」がある。
「AWSではBLEAやFinTech Blueprintなどのテンプレートを用意しており、素早く学んで構築できるように情報を提供しています。FinTech以外のガイドラインや認証、セキュリティ対策でも有効なノウハウが詰まっているので、ぜひ活用してください」（齋藤氏）
【Q＆A】多くの質問が寄せられたセッション
セッション終了後、Q&Aセッションが実施されたのでいくつか紹介したい。
Q．事例を探す上でのポイントやおすすめの方法について
木村：事例を探すという観点であれば、AWS Summitやre:Inventなど、AWSのイベントをチェックするのがお勧めです。一方、リファレンスアーキテクチャの観点では、AWSの公式ブログ、各種記事、ホワイトペーパー、AWS ソリューションライブラリなどから探すこと。業界に特化した情報を手に入れたいなら、業界イベントに参加することをお勧めします。
廣瀬：今年5月に開催された「AWS Summit Online」のアーカイブが公開されているので、ぜひ参照してください。11月8日からは「AWS Dev Day 2022 Japan」が開催されます。
Q．世界中のSAとの連携はどのように進め、新機能追加を実現されているのか
廣瀬：Slackなどのチャットツールやビデオカンファレンスツールなどを使って、情報をシェアしています。新機能については、要望の数や実装の難易度などを鑑みながら、優先度をつけて開発しています。
木村：最近リリースされた「AWS Amplify」や「AWS App Runner」などのプロダクトは、GitHub Issuesで意見を集めています。欲しい機能があったら、そのissueにいいねをつけてください。
Q．Amazon IVSは、国内ではCloudFrontのエッジロケーションになるのか
廣瀬：これはNOです。CloudFrontのエッジロケーションとは全く別物のPoPがIVSでは動いています。IVSはTwitchがルーツなので、Twitchのナレッジやソリューションを活用した独自のPoPを構成し、ワールドワイドに分散配置しています。
Q．SaaS関連のシステム検討で特に重視するべき観点や顧客からよくある質問は？
福本：重視すべき観点はテナントごとの権限分離です。アプリのレイヤーでも権限分離を実装することはできますが、後々運用する中でつらい部分もでてくるので、できるだけAWSのサービスのレイヤーやIAMを活用して分離することが大事です。以下のブログが参考になると思います。
・SaaSテナント分離をAWS IAMとABACで実装する方法
・動的に生成された IAM ポリシーで SaaS テナントを分離する
もう一つ重要な観点は、できるだけ移行を見据えた上でアーキテクチャを考えること。SaaSを始めるにあたって手っ取り早いのはサイロモデルですが、テナントの中にステートをもたせてしまうと、マルチテナントに移行したいと思った時にスムーズに移行できないからです。
アマゾンウェブサービスジャパン合同会社
https://aws.amazon.com/jp/
アマゾンウェブサービスジャパン合同会社の採用情報
https://aws.amazon.com/jp/careers/
ソリューションアーキテクト採用情報
https://aws.amazon.com/jp/careers/teams/solutionsarchitect/
関連するイベント
