株式会社ビズリーチのサービスを支える ECSとAWS Batchの活 … · 採用実績報告＋分析求職者が、求人媒体や人材紹介会社、自社採用サイトなどを通じて求人に応募

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

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

國井匡生 / Masao Kunii2018.6.1

Copyright (C) 2018 BizReach, Inc.

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

● ECS / AWS Batchの使用例

● 環境について

● 運用 / 監視について

● Dev / Opsの役割分担

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


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

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

HRMOS採用管理事業部

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

趣味: 沖縄旅行とIoT

自己紹介


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


しゃべるBotをつくったり

https://www.slideshare.net/MasaoKunii/d3chat-opsiotvoiceops-20170619Copyright (C) 2018 BizReach, Inc.

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


会社について


会社について



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

創業：2009年4月

代表者：南壮一郎

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

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

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


11

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

https://bit.ly/2x0ICouCopyright (C) 2018 BizReach, Inc.

12

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

事業承継

人手不足（人財採用）

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


13

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

事業承継

人手不足（人財採用）

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



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

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

採用実績報告＋分析

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

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

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

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


アプリケーション概要


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

CloudFront

ALB

EC2

SQS

S3

Elasticache

RDS


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

CloudFront ALB ECS

SQS

S3

Elasticache

RDS

ECR CloudWatch

Lambda



CloudFront ALB

SQS

S3

Elasticache

RDS

ECR CloudWatch

Lambda

ECS


ECS


CloudFront ALB

SQS

S3

Elasticache

RDS

ECR CloudWatch

Lambda

おまけで必要になる▼


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

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

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

● スケジュールもしくは

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

ECSについて軽く；


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

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

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

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

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

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

ECSの概念


ECSの概念

● タスク定義

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

等）≒ docker-compose.yml

● サービス

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

プロイ戦略等）


ECSのイメージ

ECSクラスター

EC2

ECS Agent

Docker

タスクA タスクB

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

EC2

ECS Agent

Docker

タスクCタスクB

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

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


AWS Batchのイメージ

EC2

ECS Agent

Docker



EC2

ECS Agent

Docker




ECSクラスター


ECSのイメージ

ECSクラスター






EC2

ECS Agent

Docker

EC2

ECS Agent

Docker

DockerとAgentが入ったEC2▼


ECSのイメージ

ECSクラスター


EC2

ECS Agent

Docker

EC2

ECS Agent

Docker






ECSのイメージ

ECSクラスター

タスクA

コンテナ

タスクC

コンテナコンテナ


EC2

ECS Agent

Docker

EC2

ECS Agent

Docker

タスクB


タスクB


サービス


ECSのイメージ

ECSクラスター




EC2

ECS Agent

Docker



EC2

ECS Agent

Docker

コンテナインスタンス


ECSのイメージ

ECSクラスター






EC2

ECS Agent

Docker

EC2

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

Job

in-comming processed

ジョブキュー



Lambda

AWS Batch

Job

processed

ジョブキュー

in-comming



AWS Batch

Job


Lambda

ジョブキュー


processed


Lambda

in-comming

AWS Batch

Job

ジョブキュー



Lambda

in-comming

AWS Batch

Job

processed

ジョブキュー



Lambda

AWS Batch

Job


ジョブキュー


AWS Batch - 定時バッチ

AWS Batch

Job

CloudWatch Eventsジョブキュー



AWS Batch

Job





AWS Batch

Job



AWS Batch

Job



AWS Batchの残念なところ

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

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

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

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

改善はできる)


環境について

● ローカル環境

● Pull Request 環境

● 開発環境

● ステージング環境

● 本番環境


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

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

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

PR環境用 ECS クラスター

Task B Task C

ALB

PR環境

モジュール A

開発PC

sbt / gulp

nginx


環境について - Pull Request環境

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

機能テストを行う

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

Task A Task B Task C

ALBPR-1環境 PR-3環境

Task ATask ATask A

ALB

Task A Task B Task C

ALBPR-2環境


環境について - 開発環境

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

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

Task A Task B

ALB

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

ALB

Job HJob G

ECS クラスター default

Task C Task D Task E

AWS Batch（Spot使用）

S3 Elasticache


運用・監視について

● CI/CD

● 環境差分

● デプロイオプション

● ロールバック

● メトリクス

● オートスケール

● ログ

● Spot Fleet


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

ECR

CIサーバー

image

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に流すことが可能

ECS

Task A

AWS Batch

Task ATaskTask ATask AJob

CloudWatch Logs Lambda

S3

log




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

Lambda

S3


ECS

Task A

AWS Batch


log CloudWatch Logs




S3


ECS

Task A

AWS Batch


CloudWatch Logslog Lambda

Lambda





ECS

Task A

AWS Batch


CloudWatch Logslog

S3




ECS

Task A

AWS Batch


CloudWatch Logs Lambda

S3

log


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



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



ログストリーム名の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

○ ECS/EKSを使用するが、費用より運用の手間をなくしたいCopyright (C) 2018 BizReach, Inc.

これからの取り組み

● 目指すはNoOps

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

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

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


まとめ

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

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

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

● ログはJSONに

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


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


Documents

株式会社ビズリーチの サービスを支える ECSとAWS Batchの 活 … · 採用実績報告＋分析 求職者が、求人媒体や人材紹介会社、自社採用 サイトなどを通じて求人に応募

株式会社ビズリーチのサービスを支える ECSとAWS Batchの活 … · 採用実績報告＋分析求職者が、求人媒体や人材紹介会社、自社採用サイトなどを通じて求人に応募