【レポート】ソフトバンクの携帯基地局を活用した映像配信システムと Agile開発基盤におけるAWS活用事例 #AWSSummit

AWS Summit Tokyo 2019

#AWS

#イベントレポート

渡辺聖剛

2019.06.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

昨日より開催されています AWS Summit Tokyo 2019。こちらで開催された、ソフトバンク株式会社様によるパートナーセッション I2-02 をレポートします。

ソフトバンクの携帯基地局を活用した映像配信システムと Agile開発基盤におけるAWS活用事例

スピーカー(敬称略)

関修康
- ソフトバンク株式会社
- テクノロジーユニットモバイル技術統括アプリケーション技術本部
- エンジニア
山根武信
- ソフトバンク株式会社
- テクノロジーユニットモバイル技術統括アプリケーション技術本部
- 課長
茶園篤
- ソフトバンク株式会社
- テクノロジーユニットモバイル技術統括アプリケーション技術本部
- 課長
田中俊輔
- ソフトバンク株式会社
- テクノロジーユニットモバイル技術統括アプリケーション技術本部
- エンジニア

ソフトバンクの新たなIoTサービスとして、月間数PByteを処理する映像配信システムを構築しました。
クラウド上に蓄積される映像データとソフトバンクの社内システムのアセットを繋ぐ閉域網を構築する中で
クラウドガイドラインの策定、CCoEを組閣しクラウドに取り組みました。
合わせてKubernetesベースのDevOps環境とその基盤の上で動作するアプリケーションを完成させた事例を紹介します。

資料

（後日公開されましたら掲載します）

内容

本日話すこと：4名によるリレー方式
- CCoE / DevOps基盤 / Agile開発 / スマート情報カメラ開発
- 4つの開発がパラレルで走った

スマート情報カメラ開発

情報配信システムの紹介
- スマート情報カメラ
- 基地局設置カメラの映像コンテンツ配信サービス
ソフトバンクイノベンチャーがきっかけ
- 基地局リソース、保守ノウハウを有効活用したサービスを
はじまり
- 各テレビ局などを対象、高品質映像を
  - 7Mbps/30fps
- 最大カメラ数もそれなり（数字はだせない）
- 基地局と閉域詣で繋いで提供するサービス
- 曖昧な要件多数（イノベンチャー由来
- 期限あり
オンプレかクラウド化
- カメラ台数
  - この規模の設備を構築するのはかなりたいへん。。。
- 曖昧な要件
  - 都度変更に対応しつつ、短納期
- -> AWSを採用
構成概要
- お客様と基地局とAWSがSmartVPN閉域サービスで接続
  - AWSへはDX
  - AWSの映像系マネージドサービスはほぼ使っていない
苦労したこと
- 映像は何をするにも制限に注意
  - 10G回線のDX接続
    - 増設プランも検討要
  - NW、スループットの見積もり
    - スループットやベースラインが非公開で使いにくい（主にS3）
      - そのためS3におけなかった
      - EC2 + EBS で腹持ちしている
    - 公開していても設計が難しい
    - 実測しても、商用として売るとなるとそれでは厳しい
- 閉域での利用制限は多い
  - AWS Elemental MediaLiveなど閉域では使えない
- オンプレスタンダードの打破
  - オンプレベースの社内ルールや考え方に苦慮
    - クラウドの理解
    - 開発・運用・セキュリティチェックシート
    - 運用受け入れ基準
良かったこと・面白かったこと
- フォーキャスト　ブレへの即時対応
  - 削除・構築が簡単
  - フォーキャストに即して相似にサーバ増減可能
- 試験環境も即時準備可能
  - 擬似トラヒックサーバをささっと準備
    - 映像送信可能なスペックのEC2を数百台規模

CCoE

クラウドCoE（Center of Excellence）
CCoE開発
- 勉強 > ガイドライン作成 > ガイドライン改版
取り組み当初を振り返ってみると
- 最初は知らないことばかり
  - ルール未整備
  - ほぼ知識ゼロ
  - 体制も未整備
ゼロからスタート
- ルール未整備
  - 統一的な開発・運用で楽に
    - どちらか一方だけ楽、は避けたい
  - すぐに利用できる環境提供
- ほぼ知識ゼロ
  - 知識習得（AWSプロフェッショナルサービス）＋知の共有ループ
  - 本部内ポータル、学習＋Tool
- 体制も未整備
  - ルール＋推進する、「クラウドを使う！」という心意気
  - ガバナンスの心を統一

DevOps

CCoEが整備したガイドラインの上にDevIOps基盤を構築
- 勉強/PoC > 採用検討 > 構築
課題
- 環境構築など開発以外の作業負担
- 開発から商用環境へのスムーズな以降
  - 仮想化時代、商用が稼働し出すまで3日くらいかかった
- 可用性（継続的な稼働）の向上
  - LBなど都度調整していた
- 監視設定・統計解析の作業負荷
  - これも都度調整していた
  - 「こういう観点のグラフを作って」> 一生懸命grepしてた
DevOps実践環境導入
- DevOps Kiban
- CI/CDパイプライン
- アプリ実行基盤 - Pivotal k8s
- 監視運用基盤 - Datadog コンテナ・オンプレ・アプリパフォーマンス全部を一度にできる
スケジュール
- 開発環境で得たナレッジを商用に活用。。するつもりだった
- 別部署からのリクエストで前倒し必要 -> やり方を変えた
どう変えたか
- Try&Errorを繰り返す（11回）
- 現物で作りながら設計
  - まずは作る
    - 最初からTerraFormを使っていた <- これは良かった
      - Terraform by HashiCorp
  - 手順を理解しながら再構築
  - 失敗から学ぶ
    - 設計見直し
    - パラメータ見直し
    - バージョンアップ失敗　etc
結果：商用環境提供1.5ヶ月前倒し
AWSでよかったこと
- Route 53 Resolver
  - DNSサーバの構築・運用が不要に
- アラート連携開発
  - Datadog, Zabbix -> SNS > SQS > 連携VMS + 既存監視システムへ
  - マネージドサービスで開発工数減

アジャイル開発

はなすこと
- どうやったのか
- 何が良かったのか
これまで：ビジネス側から要件をヒアリングして開発する立場
- オンプレ＋ウォーターフォール
- リリースまで概ね最短6ヶ月
- 仕様変更に弱い
-> アジャイルにチャレンジ
アジャイルで開発した結果 -> 10ヶ月
- 遅くみえるが、結果的には成功
- 1ヶ月目：ビジネス側で現物確認が可能
  - 最初から動作イメージを共有できる
- 3ヶ月目オンプレ > AWSに移行
- 7ヶ月目AWS＋コンテナに <- DevOps Kibanを使わせてもらった
- 8ヶ月目：仕様FIX
  - アジャイルのスピードと柔軟さ
ツールチェイン : 既存の環境を有効に活用するために
- CI/CDを中心
- 処理時間・期間を短縮
環境設定はk8sマニフェスト化
コンテナアプリケーションのログの実装
- アプリ側では管理しない
- Fluentdなどのログ収集ツールを利用
k8sの課題
- 各プロジェクトのコスト按分
- k8sだとすぐに計算できない（安くなっているはずなのに見えにくい、見るためにコストがかかる
どう活用したか
- 無理に利用しない、つまみぐい
- 部品ごとに利用できそうであれば利用する
- 道東機能のマネージドサービスがあれば乗り換える