バッチ処理をAWS Batchを利用して本番運用してみた | CyberAgent Developers Blog
こんにちは。OPENREC事業部で基盤系のエンジニアをしている石田です。 今回はOPENREC.tvに導入されているバッチ処理の基盤をご紹介したいと思います。 この記事では以下のことに関して話そうと思います。 OPENREC.tvでのバッチ処理内容 従来のバッチ処理基盤の課題 新バッチ処理導入のモチベーション 新バッチのインフラ構成 実際に稼働してみて 本番稼働をして明らかになった課題 まとめ OPENREC.tvでのバッチ処理 OPENREC.tvでは、主に以下の処理をバッチとして実行しています。 視聴時間の計測結果の集計 ランキングの集計 検索用のデータの作成 おすすめ動画の作成 従来のバッチ処理基盤の課題 初期のバッチ処理は、1台のEC2で稼働していました。それゆえ、以下の問題を抱えておりました。 インスタンス1台で稼働していることからスケーラビリティが皆無 SPOFなので万一ハード
DBが真っ白になっても55分で完全復旧ができるまでの道 | CyberAgent Developers Blog
初めまして。サイバーエージェント技術本部インフラエンジニアの@prog893です。今回は「AWA」という音楽ストリーミングサービスのMongoDBクラスタの復旧時間を短縮するために行ったインフラの改善について紹介したいと思います。復旧時間が12時間から55分まで短縮できたのですが、皆さんの参考になれば幸いです。（※注意：今回紹介する施策はAWAのインフラ構成や設定のものであり、他の環境で同じような効果が得られるとは限りません） AWAのデータストア構成 まず、現在のデータストア構成について軽く説明します。こちらの図でAPIサーバ，MongoDBに関連する構成の概要を示します： AWAのデータストア構成概要 メインのデータストアとしてはMongoDBを使っており、MongoDBのインスタンスはAWSで管理しています。APIサーバ、MongoDBのインスタンスがそれぞれのプライベートサブネット
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
