株式会社ビズリーチのサービスを支える ECSとAWS Batchの活 … ·...

株式会社ビズリーチのサービスを支えるECSとAWS Batchの活用事例

株式会社ビズリーチ・HRMOS採用管理事業部SREグループマネージャー

國井匡生 / Masao Kunii2018.6.1

アジェンダ● アプリケーション概要

● ECS / AWS Batchの使用例

● 環境について

● 運用 / 監視について

● Dev / Opsの役割分担

● ビズリーチ社の他のサービスの取り組みの紹介

名前: 國井匡生（くにいまさお）

所属: 株式会社ビズリーチ

HRMOS採用管理事業部

職業: SRE マネージャー（雑務）

趣味: 沖縄旅行とIoT

自己紹介

外の天気を光る試験管で表したり

しゃべるBotをつくったり

顔認識で勤怠をつけるやつをつくったりしてます

会社について

株式会社ビズリーチ / BizReach, Inc.

創業：2009年4月

代表者：南壮一郎

従業員数：1,202名（2018年5月現在）

拠点：東京／大阪／名古屋／福岡／シンガポール

事業内容：インターネットを活用したサービス事業

SRE/インフラエンジニアを募集しています

社会課題の解決を目指す事業を立ち上げている

事業承継

人手不足（人財採用）

企業のIT化（バックオフィス）

社会課題の解決を目指す事業を立ち上げている

事業承継

人手不足（人財採用）

企業のIT化（バックオフィス）

求人作成応募者管理人材紹介会社への依頼

面接日程調整面接評価面接結果登録

採用実績報告＋分析

求職者が、求人媒体や人材紹介会社、自社採用サイトなどを通じて求人に応募

各種採用手法から獲得した応募者情報（職務経歴など）を管理

テストや面接を通じて応募者を評価

選考実績を確認して、改善活動プランを策定・実行

アプリケーション概要

コンテナ化前のアーキテクチャ

CloudFront

Elasticache

コンテナ化後のアーキテクチャ

CloudFront ALB ECS

Elasticache

ECR CloudWatch

Lambda

CloudFront ALB

Elasticache

ECR CloudWatch

Lambda

CloudFront ALB

Elasticache

ECR CloudWatch

Lambda

おまけで必要になる▼

● マネージドのコンテナオーケストレーションサービス

● コンテナ毎のアクセス制御が可能

● ゼロダウンタイムのデプロイが可能

● スケジュールもしくは

CloudWatch Alarmと組み合わせたオートスケール

ECSについて軽く；

● クラスター○ コンテナインスタンスをまとめたもの。コンテナのhostとなる

コンピューティング環境の単位

● コンテナインスタンス○ クラスターとして扱われるEC2インスタンス。ECS Agentと

Dockerが含まれるECS用のAMIを使用する

● タスク○ 一まとめにして扱うコンテナ（webサーバーとアプリケーション

サーバーのコンテナ等）≒ docker-compose

ECSの概念

● タスク定義

○ タスクを定義する（イメージ、ポート、ボリューム

等）≒ docker-compose.yml

● サービス

○ タスクを管理する概念（クラスター、タスク数、デ

プロイ戦略等）

ECSのイメージ

ECSクラスター

ECS Agent

Docker

タスクA タスクB

コンテナコンテナコンテナ

ECS Agent

Docker

タスクCタスクB

コンテナコンテナコンテナコンテナ

サービスコンテナインスタンスコンテナインスタンス

AWS Batchのイメージ

ECS Agent

Docker

ECS Agent

Docker

ECSクラスター

ECSのイメージ

ECSクラスター

ECS Agent

Docker

ECS Agent

Docker

DockerとAgentが入ったEC2▼

ECSのイメージ

ECSクラスター

ECS Agent

Docker

ECS Agent

Docker

ECSのイメージ

ECSクラスター

タスクA

コンテナ

タスクC

コンテナコンテナ

ECS Agent

Docker

ECS Agent

Docker

タスクB

サービス

ECSのイメージ

ECSクラスター

ECS Agent

Docker

ECS Agent

Docker

コンテナインスタンス

ECSのイメージ

ECSクラスター

ECS Agent

Docker

ECS Agent

Docker

コンテナ化して良かったこと

● アプリケーションの成果物（イメージ）が本番でもロー

カルでも同じ

● リソースを共有

● 水平スケールが容易

● インフラコード/コンピューティングリソースからのアプ

リケーションの分離

● Immutable Infrastructure

○ Ansibleとの訣別、ロールバック、Blue/Greenデプロ

イが容易https://bit.ly/2x0ICou

ECSの使用例 - 規模感

サービス(モジュール)数：30タスク数：45コンテナインスタンス：24

ECSの使用例 - モジュールの分類

コンテナ化したことでリソースを共有できるようになった。モジュールを３種類に分類した。

1. CPUを多く使うもの2. バッチ的な常に起動しなくて良いもの3. それ以外

クラスタのインスタンスタイプもそれに合わせて構築

ECSの使用例

● CPU強めのインスタンスのECSクラスタ○ 主にオンライン同期系の重めのAPI○ 画像処理やアプリケーションjoinなど○ コスト的にあまりスケールアウトしたくない

ECSの使用例

● メモリ多め(安め)のインスタンスのECSクラスタ○ オンライン同期系の軽めのAPI○ オンライン非同期系の処理○ 気軽にスケールアウトする

ECSの使用例

● AWS Batch○ 定時バッチ○ ファイル系処理

AWS Batchについて

● コンピューティング環境のECSとその上で実行されるジョブを登録するキューがセットになったもの

● ジョブキューにジョブ定義を送信することでジョブを起動できる

● ジョブ ≒ ECSのタスク

ECSクラスター

Job Job

ContainerRegistry

Job定義

Job イメージ

AWS Batch

AWS Batchのイメージ

Jobキュー

AWS Batchのいいところ

公式ドキュメントのユースケースを見ると金融やサイエンス、デジタルメディアというのが前面に出ているが、単純なバッチ処理基盤としてもかなり便利。

● EC2の管理が不要● スポットも使える● リトライ処理が自動● 処理の成功・失敗がわかる● 料金がかかるのは処理中のみ

AWS Batchの使用例

ずっと起動させておく必要はないけど、Lambdaにさせるには大きすぎる処理に使用

● ドキュメントのPDF化処理● アップロードされたファイルのウィルススキャン● 論理削除したデータの物理削除処理● ETL処理

AWS Batchのダッシュボード

AWS Batch - ファイル系処理

Lambda

AWS Batch

in-comming processed

ジョブキュー

Lambda

AWS Batch

processed

ジョブキュー

in-comming

AWS Batch

Lambda

ジョブキュー

processed

Lambda

in-comming

AWS Batch

ジョブキュー

Lambda

in-comming

AWS Batch

processed

ジョブキュー

Lambda

AWS Batch

ジョブキュー

AWS Batch - 定時バッチ

AWS Batch

CloudWatch Eventsジョブキュー

AWS Batch

AWS Batchの残念なところ

● CloudWatchで処理結果のmetricsが見れない

● 起動までに時間が掛かる

○ ニアリアルタイム処理には向かない

(常にコンテナインスタンスを起動させておくことで

改善はできる)

環境について

● ローカル環境

● Pull Request 環境

● 開発環境

● ステージング環境

● 本番環境

環境について - ローカル環境

開発するモジュールをローカルで実行し、

それ以外はPull Request環境にアクセス

PR環境用 ECS クラスター

Task B Task C

PR環境

モジュール A

開発PC

sbt / gulp

環境について - Pull Request環境

Pull Request毎に環境のサブセットを作って

機能テストを行う

PR環境用 ECS クラスター（Spot Fleet使用）

Task A Task B Task C

ALBPR-1環境 PR-3環境

Task ATask ATask A

Task A Task B Task C

ALBPR-2環境

環境について - 開発環境

本番と基本的に同じ構成の環境。結合テストに使用

ECS クラスター CPU optimized（Spot Fleet使用）

Task A Task B

Job HJob G

ECS クラスター default（Spot Fleet使用）

Task C Task D Task E

AWS Batch（Spot使用）

S3 Elasticache

環境について - ステージング/本番環境

同じ構成。ステージング環境の一部は夜間停止。

ECS クラスター CPU optimized

Task A Task B

Job HJob G

ECS クラスター default

Task C Task D Task E

AWS Batch（Spot使用）

S3 Elasticache

運用・監視について

● CI/CD

● 環境差分

● デプロイオプション

● ロールバック

● メトリクス

● オートスケール

● ログ

● Spot Fleet

運用・監視について - CI/CD

CIサーバー

CDサーバー

ECS クラスター

デプロイ（タスク定義の更新）

タスクの更新

運用・監視について - 環境差分

環境ごとのDockerイメージが同じでも、host名等環境によって差分はある。差分があるものはParameter storeかSecrets managerに入れて、entrypoint.shで読み込む。

ECS クラスター

タスク起動時

Parameter store

運用・監視について - デプロイオプション

最小を100%にしておくことで、ゼロダウンタイムの更新が可能

運用・監視について - タスク配置戦略

用途に合わせてちゃんと選ぶ● binpack

○ タスクのCPU/メモリの利用量に基づいてできるだけイン

スタンスに詰め込む

● spread

○ AZ、instanceId、host等を指定して均等に分散して配置す

● random

○ タスクをランダムに配置

運用・監視について - ロールバック

https://bit.ly/2x0ICou

サービスで前のバージョンを指定するだけ

運用・監視について - メトリクス

● 基本的には、サービスごとのCPUとメモリの使用率のみ

を監視

運用・監視について - メトリクスDatadogを使用

運用・監視について - オートスケール

● ２つのオートスケール

○ タスク(Application Auto Scaling)

○ コンテナインスタンス(ASG)

● CloudWatch Alarmを利用してメモリやCPU使用率をトリ

ガにスケールアウト、スケールイン

オートスケールは難しい

● コンテナインスタンスとタスクの増減を合わせる

● ASGがスケールアウトしなくてタスクが起動できな

かったり

● ASGでスケールインするとタスクごと落ちる

かったり

○ 頑張ってドレイニング処理を書くこともできる

かったり

● ASGでスケールインした直後にスケールアウトしたり

かったり

https://bit.ly/2x0ICou

● ASGでスケールインした直後にスケールアウトしたり

とにかく調整が面倒

● オートスケールは数十秒から数分のタイムラグがある

● toBのサービスはトラフィックが読みやすいのでスケジュ

ールでスケールさせた方が良さそう

○ 例）9:00 - 21:00は平均のタスク数の倍、その他の時

間はタスク数を半分

運用・監視について - ログ

● ログはCloudWatch Logsに流すことが可能

Task A

AWS Batch

Task ATaskTask ATask AJob

CloudWatch Logs Lambda

● json形式だとCloudWatch Logsからの検索が楽

Lambda

Task A

AWS Batch

log CloudWatch Logs

Task A

AWS Batch

CloudWatch Logslog Lambda

Lambda

Task A

AWS Batch

CloudWatch Logslog

Task A

AWS Batch

CloudWatch Logs Lambda

運用・監視について - ログ形式

割とざっくりで良い。細かいと管理が面倒

ログストリーム名のprefixでどの環境のどのタスクなのか等が分かれば良い

JSONだとカラムでフィルターできる

以下を出しておくと調査が楽

運用・監視について - Spot Fleet

開発環境の一部と Pull Request 環境は

Spot Fleet を使用することでコストを削減。

運用・監視について - Spot Fleet

開発環境の一部と Pull Request 環境は

Spot Fleet を使用することでコストを削減。

約80%コスト削減

● Dev

○ 開発

○ CIの設定

○ 成果物はDockerイメージ

○ JVMのチューニング/設定

○ メトリクスのダッシュボード作成

○ アプリケーション起因の障害調査・不具合対応

● Ops

○ CD

○ その他運用・改善

DevとOpsの役割分担

弊社他サービスでの取り組みの紹介

● が先行してコンテナ化を進めたが、他の事業も

並行して進めている。

▼一部がECS、AWS Batchで稼働中

の取り組み

● 運用系のサーバーがECSで稼働中

● アプリケーション本体もECSに移行中

● バッチ処理はAWS Batchで稼働

○ MySQLからRedshiftやBigQueryへのETL

○ DBのdump取得

○ 不定期に発生する運用作業をジョブ化

Elastic BeanstalkからECSへの乗り換えを検討中▲

の取り組み

● すでにElastic Beanstalk上で稼働中

● ECSへの移行を検討中

○ 結局ECSを知る必要がある

○ 1アプリケーション(=1API)ごとにALBが立つので、

ALBの数が膨大になる

○ 1アプリケーション=1EC2インスタンス

○ EB、ECS、EC2のモニタリング

全社として

● 監視、ログ基盤は全社で統一した方が良いので仕組みを

検討中

ECSを運用してみて

● 特に問題らしい問題は起きなかった

○ サービスが停止して困るというようなことはなかった

○ アプリの問題で落ちても勝手に再起動してくれる安心

感がある

● アプリのロールバックは1分くらいで素早く戻せてリリー

スする勇気が持てる

ECSの残念なところ

● オートスケールが中途半端

○ 調整するのが大変

● EC2の存在を割と意識する必要がある

○ 割と頻繁にECS agentをアップデートしたり

○ インスタンスタイプや台数を考える

● ECS agentがバグってると大変

● タスクの起動に失敗するとひたすら再起動し続ける

● コンソールが使いにくい（改善された）

足りないことはKubernetes / Fargateで

解決できます

Kubernetes

● Googleが開発しLinux Foundationの傘下にあるCNCF

(Cloud Native Computing Foundation) が管理するコンテ

ナオーケストレーションプラットフォーム

○ CI/CDの統合

○ ロールバック/ロールアウト

○ オートスケール

○ 他のクラウドでもサポートしている

○ AWSではマネージドのKubernetesであるEKS (Elastic

Kubernetes Service) がある

Fargate

● ECS/EKSのクラスタ管理をマネージド化するモード

● コンテナインスタンス管理の自動化

● オートスケール

ECS vs Fargate vs Kubernetes

大まかにこんな使い分けなのでは

● ECS（Fargateなし）

○ クラスタをSpot Fleetやリザーブドインスタンスを使って

費用削減したい

○ コンテナ毎のアクセス制御がしたい

● EKS/Kubernetes

○ きっと全体的にECSより便利（EKSはpreview）

○ マルチクラウドを視野に入れている

● Fargate

これからの取り組み

● 目指すはNoOps

● 監視、ログ基盤を全社で統一

● Fargateが東京リージョンに来たらFargateに全部乗せ変える

● EKSに移行し、マルチクラウド化

まとめ

● デプロイ時の切り替えが早くなった

● スケールが簡単になった

● AWS Batchはバッチ処理に便利

● ログはJSONに

● EKS / Fargate に早くきてほしい

ご静聴ありがとうございました！

株式会社ビズリーチのサービスを支える ECSとAWS Batchの活 … ·...

Documents

求人・求職バランスシート...求人募集数 988 95 209 231 198 255 2,012 60 193 237 304 1,218 求職者数 1,634 114 250 301 363 606 2,950 85 273 335 432 1,825 求人倍率

求人・求職バランスシート - mhlw.go.jp...求職者数 172 28 35 30 36 43 153 11 24 32 24 62 求人倍率 4.51 5.64 5.63 5.53 3.53 2.98 6.42 6.55 6.58 6.56 6.54 6.23 求人募集数

福祉人材の求人求職動向...平成31年1～3月福祉分野の求人・求職動向（概要）全国社会福祉協議会中央福祉人材センター 1．基本動向

職業紹介業務取扱状況 · 2020-03-02 · 求人・求職対照処理表ハローワーク浦和有効求職有効求人新規求職新規求人有効求職

FHRマニュアルエージェント 20171130求人情報の追加掲載（求人情報の流用）登録済みの求人情報の内容を流用して、新しい求人を作成できます。

社社社社団団団団法法法法人人人人姫姫姫姫路路路市市市医 ...社社社社団団団団法法法法人人人人姫姫姫姫路路路市市市医医医師師師師会会会会

0007890-100007 求人票（新卒） - 高松商工会議所...求人番号 0007890-100007 求人票（新卒）受理日： 1 会社の情報かぶしきがいしゃかつら従業員数

求人・求職バランスシート - mhlw...求人募集数 3,209 533 980 828 562 306 892 40 153 165 169 365 求職者数 2,717 372 689 646 603 407 548 24 92 99 102 231 求人倍率

社会人講座トップページ | 資格の大原社会人講座...社会人講座トップページ | 資格の大原社会人講座

株式会社カカクコム会社案内 - Kakaku.com · 2020-05-17 · 株式会社webCGがグループに加わる求人情報の一括検索サイト「求人ボックス」を開設

これからの企業・社会が求める人材像と大学への期待...これからの企業・社会が求める人材像と大学への期待公益社団法人経済同友会

求人票 - CATS...Title 求人票 Created Date 10/31/2012 1:16:18 PM

activo 社員・アルバイト求人サービスご案内資料activo 社員・アルバイト求人サービス概要 NPO・社会的企業、福祉領域向けの完全成功報酬型の求人サービスです。

岩手労働局 Press Release - mhlw...Ⅰ求人倍率 ①有効求人数、有効求職者数及び有効求人倍率（季節調整値）の推移 (人・倍）項目年月 26年度（平均）

求人情報 - for fields › corporation › seikou › pdf › for_fields_manual.pdf · 求人情報サイト「for ﬁelds」求人情報更新手順求人掲載を自社でされる企業様向けマニュアル

福祉人材の求人求職動向...新規求人倍率 5.75倍 5.26倍 5.08倍 5.38倍 5.49倍 5.02倍 4.74倍 4.87倍 5.14倍新規求人数(人)-24 203 + 2,442 234 673 302 1,425

求醫不如求己 - 中里巴人感悟的天空

最近の雇用情勢 - mhlw...「正社員新規求人数」 20，225人前年月19，734人 2．5％増･2か月連続で前年同月比増。新規求人に占める正社員求人の割合は42．3％で前年同月より4．0ポイント上昇。・

求人・求職者賃金情報（フルタイム）【10月】...労務職 226,161 177,324 190,167 158,125 合計 252,586 185,714 212,223 171,988 求人・求職者賃金情報（フルタイム）

グローバル人材に求められる力とその育成方法について€¦ · 1．グローバル人材（リーダー）に求められるスキル・マインドは？弊社では、アジアのトップビジネススクールの

株式会社ビズリーチの サービスを支える ECSとAWS Batchの 活 … ·...

株式会社ビズリーチのサービスを支える ECSとAWS Batchの活 … ·...