AWSソリューションアーキテクト模擬
AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト
- 作者:NRIネットコム株式会社,佐々木 拓郎,林 晋一郎,金澤 圭
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2019/04/20
- メディア: 単行本
この本の模擬をやった。 AWS自体は業務で触ったりしてたけど、ほぼ無勉に近い。
20/30なのでこのまま本試験受けると多分落ちるやつ。
間違った問題
S3の静的ホスティングの問題
- S3エンドポイントはVPC特にプライベートサブネットからS3にアクセスすることができる機能のこと
IAMの問題
- EC2インスタンスに紐づけることができるのはIAMグループではなくIAMロール
EBS最適化
- EBS最適化オプションはEC2の通常のネットワーク帯域とEBSアクセス用の帯域を別々にするオプション
ネットワーク設計 インターネットゲートウェイに関する設問
インメモリキャッシュ
- CloudFrontはCDNなのでキャッシュとは違う
- Lambda@Edgeはユーザに近いリージョンでLambdaを実行するもの
- ElasticCache for Memcachedは揮発性がある。
- ElasticCache for Redisは永続化可能
監査の問題
- CloudTrailでマネジメントコンソール上の操作の監視ができる
- CloudWatch Logs でCloudTrailが出力したログを引っ掛けることで、検知ができる
セキュリティーグループとネットワークACLについて
- セキュリティーグループは、ステートフルなので、インバウンド通信が許可された場合、戻りのトラフィックに関しては阿吽とバウンドのルールは関係しない
- ネットワークACLはステートレスなので、インバウンド・アウトバウンドどちらの許可もないと通信ができない
- セキュリティーグループはEC2インスタンスを対象とするもの
- ネットワークACLはサブネット全体の通信に関するもの
Elastic Beanstalkについて
- All at Onceは全てのインスタンスに一気にデプロイするような形
SES
- メール受信もできる
- マネジメントサービスだから冗長性や可用性について利用者側が意識する必要がない
- とは思うんだけど、バウンスレートが多いと利用止められるし、利用者側が意識する必要があるような気もする。冗長性はともかく可用性って面で。
S3の特徴
- イレブンナインは可用性ではなく、耐久性
まとめ
- あまり意識することがなかったIAMやネットワーク周りは勉強する必要がありそう
- Elastic Beanstalkは使ったことないんでここも勉強が必要
- あとはEBSとかもちょっと見ないとなぁ。
オープンソースで実現するログ分析技術入門
ログ分析におけるElasticStackの勘所
www.slideshare.net
※ESはver7.0
時系列データの勘所
- 時刻情報を持つイベントデータ(ログ/メトリックス) , 時刻データが大事
- logstashやBeatsから取り込んだ時系列データは自動的にローテートしてくれる(indexの肥大化を防ぐ、ただしUTC)
セキュリティにおけるログとは
- フォレンジック調査
- ハンティング業務(驚異を見つけるために主体的に見に行く)
- 監査
- 監視業務
ElasticStack
- Kibana+elasticsearch+(beats+logstash)
beats
- beats family
- metricsをとるならmetricbeatのような感じ
- ちなみにgoで書かれている
logstash
- beatsで取り込んだものの加工
- DB接続
beatsとlogstash
- beatsはagent投入してelastic stackへ投げるようなもの 軽量
logstashはソースとフィルタが多様
機械学習したいならElastic Cloudがいいかも
- AWS ES
- Open Distro for ES
Elasticsearchの設計
- nodeの役割がいろいろある。兼務もできるし専用ノードでもいける
- メモリとストレージの設計において JVM Heapを効率良くできるかがポイント
全文検索と時系列データの違い
- 全文検索はcache上にのこるか。がポイント
- 時系列はwritecacheの方がおおいはず。 なのでread cacheには乗らないのでDiskから読むようになる。
なのでDiskのI/O性能が大切
スキーマ定義は?
- やったほうがいい。stringで格納されるので分析したいのが正しく分析できなくなる
Elastic SIEMってのがでたよ
- OSSじゃないけどBasicなので無料で使える
ETL
parseとenrich
- parse: csvをパースする
- enrich IPをhostにしたり、 blackリストのIPであればflag立てたり
- ログの加工はいろいろ流派ある。
- ログ自体を加工する
- logstashで加工する (前処理
- elasticsearchで引っ張ってきたデータをあとから加工する(後処理
plugin作るか、rubyfilter書くか
ESにつっこめなかったのはDeadLetterQueueにファイルとして突っ込める。 これをLogstashで再取り込みする
- logstashのfingerprint filterで一位になるようなIDを生成してdocument_idで突っ込む
Molochではじめるネットワークフォレンジック
ネットワークフォレンジック
- ネットワークログ = パケットデータの情報収集・侵入検知など
パケットキャプチャ
- エンドポイントでキャプチャする
- ミラーリングしてネットワーク経路上でキャプチャする
課題
Moloch
splunk→ ElasticStackで芽生えたなにか
- 用途に応じて複数存在しているログ分析システムを統合するかどうか
- AWS上でElasticStack環境を構築して、オンプレミス環境からログを転送する構成とした。
- 各パイプラインごとにLogStashをFargate上にデプロイしている。
- 外はEC2運用
- オンプレからS3へログ転送 するLogStashと実際にESに入れるLogStashがある。
問題
- Logstashのinput s3はスケールアウトできない
- S3に入っているデータをQueueに突っ込んだりするのは別にする必要がある
まとめ
- 時系列データで性能を出そうとするとインフラコストかかる
- 長期データはあまり向かないかも？
AbemaTV Developer CONFERENCE 2018
だいたい一ヶ月前だけど AbemaTV Developer CONFERENCE 2018にいってきた。
AbemaTV Developer Conference 2018
これも2016-2017と連続で参加していた。
今回の開場は渋谷に新しくできた渋谷ストリーム グーグルの日本法人も六本木からここへ移転するみたい。
グーグルも入るんだっけ たしか。
— y.takky (@y_takky2014) 2018年10月13日
ホール自体は割と小さめで GCP NEXTの開場がここになることはなさそう
あとはメモなので
【Keynote】 AbemaTVのエンジニア組織論と今後の技術的戦略
- MAUがだいたい1,100万ぐらい
- 中途採用が2006, 新卒採用開始が2008年ぐらいから
- エンジニア組織的には1000人ぐらい
求められる３つの開発力
組織論について
- 施策自体は当たり前のものだけど組織のカルチャーや時流によって入れていくことが大事
- 全体のKRから分解していってOKRを導入した。
- 横軸でTechTeamをおいている
- グレード制 上位のエンジニアが評価する
- 目標設定: HRBrainを導入。目標のオープン化
- 同じグレードで目線合わせ、上位グレードへの目線上げ
- キャリブレーション : 評価のすり合わせ
成長機会 : input/outputの後押しをしている
Management -- 組織成果を最大化する -- TechLead15人に対してエンジニア51人。 TechLead育成を勧めている
- チーム全員でひねり出して案を出す
デバイス戦略
技術的戦略
- AbemaTVの初期開発はだいたい4ヶ月ぐらい
- チケット駆動開発で職種でトピックを分離、優先度定義されたチケットが降りてきてやれるだけやる
スタンドプレイの最大化になっている
GCPを有効活用した。ロギング,LB,コンテナマネジメント
- 機能開発にフルコミットするように
配信構成の見直しをしなくちゃなーと思うように(亀田興毅事件)
Encoder->配信システムの遅延やパケットロス zixiを定常運用化
技術ドメインを抽出してチーム化した。
どこに責務を負うかという観点で。
プロダクト開発に集中できるようにオンコール対応などを受ける。
A1「72時間ホンネテレビ」の負荷対策とその裏側
- 技術本部 : CAのメディア事業を社内横断的に見る人。
- エンジニアブログ委員長など
- Developer Blogであとから情報は公開する
キックオフに向けて
- ドックフーディングしたり、ログ見たり
対策内容
- 優先度を決めた
- 72時間ホンネテレビとCMの配信
CDNでのキャッシュ
- プレイリストをCDNキャッシュ
- Web用をCloudCDNに対応させた
- キャッシュヒット率を向上させた
リクエストのポーリング間隔調整
- 視聴数やコメント数の部分
別系のシステムへ
- スパイクしやすいトラッキング用のリクエスト
- プライベートクラウドからAWSへ
負荷試験/サーバ台数の調整
- 去年のDevConで発表あったやつ
負荷対策が間に合わない部分
- エラーハンドリングの見直し
- メンテナンスへ入れられるように
- 間に合わない機能を使ってもらわないように
リリースをしてもアップデートが
- 強制アップデートの仕組みがあったので..
カウントダウンするだけの直前番組
エスカレーションのレベルとアクションを規定しておいた
Future
A2 AbemaTVのアーキテクチャの変遷
仮開局まで
- 収録番組の配信がマスト
技術選定
- オンプレはコスト以外のメリットがなかった
- なぜGCPを選んだか
- Googleが使っているのと同じようなL7LB
- GKE/k8s
- ネットワーク帯域に対するコストの安さ
- AWSはマシンのスペックに応じてネットワーク帯域が決まっている
- GCPはその制約がなかった
- StackDriver Logging / BQ
- 台湾リージョンしかなかった
- 日本<-->台湾間のインジェストの安定性が問題
- 台湾<-->東京に移行する人的リソースが避けない
- 言語 Java -> Node.JS -> Golangへ
- 編成ツールを完成する必要がありMongoDBを愛用
アーキテクチャ
- Microservices
- コンテナ化でリソースの有効活用
- gRPC+Protocol Buffers
- Gateway系/Backend系に分けたGateway Pattern
番組表
- スナップショットをGCSから取得する
- 編成途中の番組表がユーザに表示されるのを防ぐ
- バージョン管理しとくことで実機確認ができる
仮開局〜本開局
- 生番組/広告/コメントができることがマスト
広告
- abemaTVの広告局が用意したAdサーバと連携
- 予めトランスコードされた動画セグメントをGCSから取得して配信
- ターゲティング広告
- CMをパースなライズできる設計だった
本開局後
動画セグメントのキャッシュ
- GCSがSPOF
- GCSへの一時的なスループットの低下
- Redisキャッシュつかった
ログ改善
- fluentdを使っていたがGolandで使いにくい
- GcloudPub/Sub + BQ
-- 各ゲートウェイでPub/Subにログを流してバッチサービスがBQにInsertする。 -- ログ解析チームがSubscribeすることが可能
メトリクスの可視化
- Stackdriver Monitoringを使用
- 各リソースを可視化したい
- Prometheus+Grafana
年末年始の対応
- 広告サーバからのレスポンスをキャッシュ
- Redis Clusterをスケールアウト
- 1/1に検証して1/2にバージョンアップを実施 redis-trib.rb 3.06にバグがったので
1周年~2周年
配信の安定化
RTMPでCMキューを入れていたが切れるとCM入れられないのでHTTPで
障害時に何をしていたか
- アラートのOnCallを受け取ったが根本原因をさぐるのに時間を用意した mongosが詰まっていたので再起動で解決した
データストアの分離
- 単一データストから各ドメインごとに分離した
24hホンネTV
2周年〜現在
- ターゲティング広告を開始
- ユーザをいくつかのセグメントに分けてセグメントごとにプレイリスト配信
- 安定稼働を取るように
とここで腰の痛みでリタイア。 最近カンファレンス言っても腰痛くて早めに帰ってしまうのがあれなところ。 年かな..
2018年4月に転職してました
2014年に新卒でエンジニアとして入社した会社を 2018年3月末で退職し 2018年4月からいわゆる Saasビジネスを行っている会社にWebエンジニアとして転職してました。
何をやってたの？
ハンドルネームでググると前職のテックブログの記事が出てくると思います。 主に、Webエンジニアとして2-3年間 新規メディア開発したり改修案件してました。
後半の1年ではSREとして主にGCP/GKE周りの導入をしたりしてました。 特にGCP関係では、 コミュニティであるGCPUGのSlackに入り浸ったり勉強会に参加してました。 GCP/GKE周りでも1-2回発表ができたのである程度コミュニティへの還元ができたんじゃないかなと思ってます。 それでも、早い段階からGCP/GKE周りを触っていた割にはあまり還元できてなかったのかなと思ってたりするのでもう少しやってればよかったなと思います。
なんでやめたの？
理由はいろいろありすぎるので私を知っている方は飲みにでも行きましょう。
主には、自社メディアなのに受託開発案件がちょくちょくはいってきてあれ？ってなったのと、
あまり戦略もなく新規メディア構築してその後放置しているみたいなのが結構増えてきてあれ？ってなったのがメインですね。
やっぱり自分が作ったものが使われないと悲しい。
なんでこのタイミングで書いたの
なんだかんだ言っても前職のエンジニアの人たちはリスペクトしていて、流石にすぐ書くのはなぁと思っていたからです。
特に新卒の頃からのメンターの方にはいつもお世話になっていて彼がいなければ今の私のエンジニアとしての生き方はなかったなと思っています。
あと台風で暇だったから。
転職活動どうしてたの？
転職ドラフトでお声がけ頂いた会社を何社か受けたり、エージェント経由で応募したりって感じでした。
10月末に活動を初めて12月中には決まってた感じですね。
今何しているの？
また webエンジニアに戻りました。 Sass系のWebアプリケーション開発をしています。 go書いたり Vue+nuxt.jsでフロントエンド周りちょっと書いたりしています。
例のあれ
偉い人がこういう記事には貼れって言ってたやつ
GDG DevFest Tokyo 2018 メモ
今年もGDG DevFest Tokyoに参加してきた。 gdg-tokyo.connpass.com
2016から毎年行っているらしい。
ytacky.hatenablog.com ytacky.hatenablog.com
今年は新宿だったので、かなり行きやすかった。
DialogflowとCloudFunctionsで作るGoogleアシスタントアクション
Googleアシスタントアクションの話
- コミュニティプログラムってのがあって、アクションをリリースするといろいろもらえたりする
開発する3つの方法
- Actions SDK
- Dialogflow
- テンプレート
- NonCodingで作れる。SpreadSheetを埋める感じ
Dialogflow
- LineやSlackなどにも
- アナリティクス機能
SDKが豊富
Dialogflowは聞き出すところまでできる
- それ以降のバックエンドはできない。計算とか
Intent
- 会話を開始する文(トリガー)を決める
- 会話を成立させるための条件を決める
- 作成したことのない謎の Intent
- Default Fallback Intent
- アクションが失敗したときのIntent
- Welcome Intent
- アクションが成功したときのIntent
Entity
- アクションが成功したときのIntent
- いわゆるメニュー1つ1つ。
- Key-Value方式
Fulfillment
- サーバにjsonを飛ばすことができる
acitons-on-google-nodejsライブラリ
- DialogFlowではjsonを渡すのでよしなに処理してくれる
TIps
- YoutubeのGoogleDevelopersチャネル
- AoG公式Docs
- Slack
Container
Kuma
- コンテナ（物理)はなにがいいのか。
- 統一規格なので何でも運べる
（ソフトウェアエンジニア的な)コンテナ
- 統一された規格
- どこでも動かすことができる
- 環境が隔離されている
だいたいコンテナを使っている人は会場だと90%ぐらい？
Prod環境でコンテナを使う利点
- 使い捨てが簡単
- 増やすのも簡単
減らすのも簡単
アプリケーションの依存性を内包できる
- もしchefやansibleなどでマシン自体をスケールアウトしたらどちらが責任を持つか
- コンテナの中と外で責任の分離ができる
注意点
- 一度コンテナを作ったらそのコンテナの中をいじらない (immutable)
- いわゆるコンテナにSSHしたら負けなやつ
- コンテナの中にデータを保存しない (stateless)
- ロードバランシングして画像がない方に振り分けられると見えない
- コンテナの管理・運用
- Monitoring,Orchestration などなど
InGCP
- Kubernetes Engine
- ちなみにkubernetesを使っている人は会場の中で10%以下ぐらい？
- kubernetesの説明があったが割愛
- コンテナのオーケストレーションツールで、水平スケールや自動ヒーリング、サービスディスカバリとロードバランシングなど。
- Node-poolの提供 Nodeをまとめて管理する概念と、Nodeのスケール機能
- GCPの連携
- StackDriver
- LoggingやTracing,profilling,Alertingなどモニタリングする際のツール
- Container Registry
- DockerHubみたいな
- Cloud Build
- コンテナのビルドとワークフローの指定管理を行うツール
GCPで作るデータ処理パイプライン
- バッチとストリーム処理の概要と問題
データ処理の分類
- バッチ処理
- 有限の範囲のデータを扱う
- ストリーム処理
- 処理対象となるデータの範囲が無限で時々集計する必要がある
機械学習の特徴量生成の場合
- 時系列系の特徴量
- リアルタイムレコメンド
GCP上ではプログラミングモデルとインフラを提供している
プログラミングモデル
分散実行インフラ
- フルマネージドでオートスケール
- GCP各種ストレージと連携できる
Cloud Dataflow+beam
- データの処理と分析を担う
- Cloud Dataprep -UI上でできる非プログラマ向け
- Cloud Dataproc + Hadoop
- Hadoopをそのまま移行する感じ
Apache Beam
- データの処理の流れを宣言的に記述する
- 抽出データ(PCollection)を処理(PTransform)でつないでグラフを作る
Google Cloud Dataflow
まとめ
- ApacheBeamはバッチ処理とストリーム閭里を簡易に記述するプログラミングモデル
- Dataflow使うと早く安く処理できる
Firebase Realtime Database in Production
AI メッセンジャー
B2Bのチャットサービスの提供、自然言語処理を含めて自社製 FIreBase:アプリケーションインフラの提供サービス WebSocketの管理をしたくなかった
なぜ書き込みをサーバからしか行わないか（直接クライアントから返さないか)
- フィルターなどが弱い(RealTime Database)
- BigTable等の別Storageから検索・フィルタリングできる。 ただし、データの分散や二重管理などが必要になるので、構成の吟味が必要
Filtering values
- FireBaseは値のクエリが苦手
- 設計時点でフィルタリングが必要なかったりしやすいように設計すべき
How to manage incidents
- Lineともつなげていて、絶対落とせない。証券会社とかあるし。
- FireBaseに障害が起きってるっぽいときには、Pollingに切り替えて Restでやるようにした。
- データをロストすることもあり得るので、全データはStackDriverにログを出力しておく
Future works
- 最終的にFireStoreかな。まだ検証はしてないけど
- Double Write以上になりそう。
感想
- AoG面白い個人的にやってきたい感じはあるんだけど、マネタイズのイメージがまだつかなくて企業導入はまだまだな感じ
- コンテナ自体は使っているけどKubernetesを使ってる人はまだまだ多くないようだ。
- CloudDataflowあたりはまだそんなに使ってるところ多くないのかな。セッションは人気だった。
- FireBaseが結構本番での利用事例が出てきた感じ
MacでMarkdown+umlを書きたかった(VSCode)
まえがき
Markdown+umlを書く機会がローカル(Mac)であった。 というよりWebサービス上で書くとサービスの性質上 publicにしないと下書きにできなかったので...
拡張機能 Markdown Preview Enhancedの準備
今回はMarkdown Preview Enhancedを使用した。 marketplace.visualstudio.com
今回やりたいuml(plantuml)だけでなく、PDF出力やhtml出力もできるスグレモノ。
拡張機能は[表示]->[拡張機能]で拡張機能メニューを出してMarkdown Preview EnhancedをインストールすればOK
plantumlの準備
plantumlをインストールする前にjavaが必要なのでjavaをインストールしておく
brew cask install java
その後graphvizもインストールしておく
brew install graphviz
plant umlのインストール
こちらもbrewを使ってインストールする
brew install plantuml
確認
vscodeで適当にmarkdownを作って以下のように書いてみる
# test ````plantuml title test class Class ````
そして.md形式で保存しておく。
その後 command+k -> vでpreviewを表示するとumlが表示される
まとめ
Abema TV DEVELOPER CONFERENCE 2017にいってきた
AbemaTV Developer Conference 2017
去年に引き続いて
Abema TV DEVELOPER CONFERENCEにいってきた。
今回の会場はTECH PLAY. dotsがTECH PLAYに変わってからははじめていったかも。
スライドとかはGoogleの福田さん以外のは順次公開されるはず...
AbemaTVを支えるGoogle Cloud Platform
福田潔さん (Googleの方)
- CDNはAamai(キャッシュできるコンテンツ)
- GCPではGLBで受けてバックエンドに流す。
- マイクロサービスとしてGKEを使ってる。
- GAEとGKEの違い
- GKEはkubernetesのマネジメントサービス
- GAEは制約が強いが動作環境自体のマネジメントはない。
- Kubernetesはデファクトスタンダードになった。
- Dockerもついにkubernetesをネイティブ Sawrmの併用も可能に
- SREはソフトウェアエンジニアとしての力も持っているし、運用もできるというのがGoogleのSRE
- GKE
- ノードアップグレード
- kubernetesのバージョン
- nodeOS
- Backendはマネジメント使えば
- GLB
- BackeEndで振り分けられる
- グローバル負荷分散
- 自分の近いところにアクセスが行く。
- Cloud LB / CDN
まとめ
福田さん自体は結構いろんなカンファレンスで話聞くことがあって、GCP周りの話に関しては結構調べれば出てきそうな感じかな。 あとAbemaTVの事例は Google Cloud Nextでもあったのでそっちの動画はみないとなーと。
#abematv_dev Google Cloud NextのAbemaTVの発表動画はこれかな https://t.co/N6fhjaHIIS
— y.takky (@y_takky2014) 2017年10月21日
(たしかこれ会場にいってたのに障害対応してた気がする..)
AbemaTV将棋チャンネルの配信技術 〜全国完全生中継への挑戦〜
藤崎さん
既存の中継
FPU(マイクロ波) で送信
- 専用線で秘匿性高いが免許必要だし高い。
- アンテナ合わせ...
衛生
- 遅延が多い。専用線だけど
- 天候に左右される
SKYPE
- 簡単で画質そこそこだけど不安定でPCベース
SkypeTx
- 放送用Skype , 画質Max720p 遅延が少ないが相手先のネットワークに左右される
LiveU
実際の将棋中継
- 2ヶ月前から設定する。
- 電気食うから発電機必要
- リピータも借りている
まとめ
- 放送1日でも実際は3-4日
- 平均2時間のカメラ調整
AbemaTVの画質定義～ラウドネスマネージメント（録画放送）
- 配信レゾリューション (配信サイズ) は多々。近々情報量節約モードが出る
技術用語
- CODEC
- 圧縮 , 符号化 / 復号化
- container / 拡張子
- TRASCODE
- 頂いたデータを配信用データに変換する
- 容量負荷の軽減と品質担保を保つ
中間ファイル作成
- DDP (ウォッチフォルダー運用)
配信トランスコード
- 速度と品質はトレードオフ。ユーザーファストで
ラウドネスマネジメント
- CMと本編の音量差を解消するために策定された。
- AbemaTVではこれを独自にモディファイ / 音量大きめで出力している
- 国際的議論があったり最適化をプロ(テレ朝）と話してる
- 将棋や麻雀のように喋っている部分が短いところは難しい。基準を変えて測定する
AbemaTV モバイルアプリの開発体制と開発プロセスの話
開発体制
- 開発局50人
- チームは別れている
- ビデオ/グロース/本質改善/テレビデバイスの4つに分けている。
repositories
-ios - tvos -api -protobuf-swift -script -その他 7~8 PR / 営業日
開発フロー
- スクラム開発
- 2週間スプリント
- 2wで修正
- 開発を2週間, QAを1週間でやってたけど、開発とQAの重複がつらい
- 開発1w,QA 1wにしてる。
タスク
- プロデューサー / プランナーが立案
実現されるための機能を上げる
エンジニアがコード品質やパフォーマンス化タスク化。
タスクの見積もり
- ストーリポイントは1人1人の
タスクの優先度
- ↑SAB/↓CD
- ↑ スプリント機関に開発完了 / テスト / リリース必須 定常リリース日に間に合わなければ遅らせる判断
- ↓ 後回しでもoK
会議体
- スプリント計画
- スプリントレビュー
- 案件会議
ツール
- Slack
- Jira
- Confluence
- esa
- Gtihub
- Bitrise
- Jenkins
- cmdshelf
開発スタイル
- CONTRIBUTING.md
- 3人以上からOK
- 軽微なら2人とか
- テストは極力書く
- UI周りは設計でカバーして、テストは書かない方針
ブランチ戦略
- 基本はGithub Flow
- 開発用のmasterとqa branch
Beta配信
Slack通知
- K.I.T.T -レビューがされていないPRを流す
QA効率化
- デバッグメニューを用意してあげている。
- アクティビティモニタ
- 通知周りエミューレート
デザインのBefore & After
- アプリ内通知バー
- AndroidのSnack Barと同じデザインにしたい
- 指が届かない
モーダル
- フルスクリーンのモーダルは避けられる傾向がある
- 指がと説かない
- AndoidのBottom Sheetと同じUX
ビデオページ
- サムネイルのパワーが弱いので文字で訴求したい
- 情報量のバランスを取るため
アプリアイコン
Web(モバイル)
AbemaTVにおけるモニタリング
- LE VAN NGHIA(ギアさん)
サービスから見る
- K8s Statelessなマイクロサービス -GCE Node (Stateful)
- その他GCPサービス
モニタリングサービス
- StackDriverのみ
- マシンメトリクス(CPU/Memory/Network)
全てのレイヤを監視したい
Prometheus + Grafana
- Kuebernetesと親和性が高い
- 性能が良い
Prometheusの導入
- クラスタ内に1つのPrometheus
- Grafana側で複雑なQueryを書くと待ち時間が長い
- PrometheusでRecording Rulesを追加して良くなった
- ただ問題と課題が上がってきた
時系列データの増加
- モニタリングターゲットの増加
- 新しいメトリクスが増えた
Node-exporter
- CPU / Memory ./ Disk / Network
- DaemonSetとして書くnodeに1つのpod
- GCEの場合Packer
k8sのメトリクス
- kube-dnsなど
CCUメトリクス
- 同時接続数にメトリクス
- アクセスログからリアルタイム計算
- HyperLogLogアルゴリズム
-Horizontal Pod Autoscalerで自動スケーリング
Prometheus sharding
- メトリクス首里でPrometheusを分ける
HA Prometheus
- 同じconfig / 同じターゲットリストで複数Prometheusを構築
- データの差分の吸収
Prometheus Operatorを導入した
- configの代わりに server-monitorを記述した
- ほっとリロード Sidecarコンテナでconfig/dashboard監視
問題
- k8sの必要なyamlファイルの重複
- DRY などに対応するのにHelmを導入した
Helm
- kubernetes package manager
- Helm Chartを作成してvalueに差分だけ与えればOkになった。
- Prometheusを使った分散トレーシングにPromvizを作った。
Microservices下におけるWebの負荷対策
- GLBで受けてGKEにmicroservicesが載っているという他と同じ構成
- Backend health / Timeout : 10s Internal 15s
- Nginxがassets系の配信をしている
- htmlのmeta情報はgrpc通してbackendから返している、
最初のランディングはabema.tv別ドメイン - フロントエンドエンジニアはUI/UXに専念したい。 APIGatewayは別ドメイン
障害原因
ケース1
ケース2
- Node.jsにはタイムアウトの実装がなかった
- GLBがtimeoutすると503帰ってくる
ケース3
- API Requestが通らない
- いわゆるnginxが詰まった。
対応策
CDNを通すようにする
- パフォーマンスと可用性
- 欠点は細かい振り分けができない
制約も多いがパフォーマンスにおける利点が多いが何より可用性が維持できる
新しい構成
- CloudCDNを頭につける
- UAごとの出し分けはやめる。
Webのパフォーマンス
- Service Worker有効時の First Meaningful Paintが遅い
対応策
- Server Side Rendering
- JSファイルの分割と動的インポート
まとめ
- 運用においての負荷対策は登竜門的なようなもの
AbemaTVを支えるアプリの優しさ
- バッテリーを使わないとかネットワークをあまり食わないとかはアプリとして大事
- システム的に見てもネットワーク帯域を使わない。というのも大事
現状の問題
- HLS(HTTP Live Streaming)
- playlistとりすぎ問題があった。
- 通常はMEDIA-SEQUENCEをインクリメントして次の.tsを取りに行く
- Playerのバグの問題(PR送った)
画面に最適なビットレート制御
- Andorid 7.0からは複数画面視聴もできるようになった。
- 端末や画面幅で切り替えた。
MPEG-DASHによるリニア型配信
- TECH PLAY TECH CONFERENCE 2017 の記事見るといい
HLSとは
MPEG-DASHとは
Dynamic Adaptive Streaming over HTTP - ISO/IECが企画したHTTPストリーミングを行う規格 - 各ベンダー(apple,adobeのHDSなど)が作った規格の統一のため
MPDとは
Media Presentation Description - メディア記述のXMLファイル
プロファイルが何故必要化
- 対応しているメディア形式を決めておいてプレイヤーがサポートする規格を制限できる
M4Sとは
- フラグメント(セグメント)化されたMP4ファイルのこと
AbemaTVのリニア配信
- リニア配信とは
- 予め番組表に従って行う配信
- 番組表に従って録画,生放送,CM,フィラーを配信する
なぜMPEG-DASH対応するか
配信品質の監視
- マスタールームで監視しているけど24h監視は辛い
- HTTPステータスコード監視入れるけどストリーミング監視には役立たない
監視ツールをつくった
- Procyon ー社内OSS的な
AbemaTVの裏側 - 大規模トラフィックを支える技術と負荷対策の話
負荷試験
- Locust & wrk
Locust
- Python製の分散型ユーザ負荷テストツール
- abemaTVでは GKE上で大量のdestibuted mode workerを配置してシナリオファイルを回して、high-throughputを実現している。
- machine Type n1-high-cpu-16, Node 104*3 , pod 5000
- Total 9984 Core
- GKE x Locustの相性が良い
- WebUIから各pathのreq/secやexptionを観測できる
- 自由度が高いゆえに秘伝のたれ化
- 9984コア要らない説
- 負荷試験環境の実行やレポートの週家まではChatOps化
- boomerを使用したシナリオreplace
- 1つのendpointに対しての限界性能試験ではちょっと...
wrk
- Lua製のHTTPベンチマークツール
- 単一のマルチコアCPU上で実行すると大規模な負荷与えられる
- レポート出力はカスタムできる
- Luaなので高速かつパワーも十分
- ちょっとしたシナリオも記述可能
- latencyのpercentile表示
- threadとconnectionのバランス表示
- レポートの集計には弱い
Bihind-thesceenes story
MongoDB
- MongoDB Cloud Manager
- Restore
- Cloud Managerのsnap shotを取るようにした
- 実行時間が1/2に
- Restore時はwrite防止の為mongoを止めるのでオンラインでは使用できない
Cloud Bigtable
Backup
Metrics
