LoginSignup
6
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@takarake(やんすぃ～)in株式会社シーエー・アドバンス

AWSにて、バッチ処理系のCDPを実装してリリースした話

Last updated at Posted at 2016-11-28
1 / 28

■これをやった理由 :question:

  • 担当プロダクトにおいて、バッチサーバがスケール可能な状態になく、今後の利用ユーザの増大に備えて対応が必要となったため。
  • proxyやwebはスケールできる状態なのに！！＞＜

■そもそもCDPって:question:

  • AWSクラウドデザインパターン(略してCDPと呼ぶ)
  • システムアーキテクチャ設計時の問題と解決方法のノウハウを整理したもの
  • ロゴもあります！　cdp_logo.jpeg
  • 詳しいサイトはこちらですが、ちゃんと説明します

■そもそもCDPって:question:

わかりにくいですが、要はこれらのことです↓

web_cdp.jpegdb_cdp.jpeg

■そもそもCDPって:question:

下記は「Multi-Serverパターン」と呼びます

web_cdp.jpeg

$\color{red}{\rm ※利点　}$片方のインスタンスに障害が起きてもシステム全体としては稼働可能

■そもそもCDPって:question:

下記は「DB Replicationパターン」と呼びます

db_cdp.jpeg

$\color{red}{\rm ※利点　}$片方のDBに障害が起きてもデータのロストを防げる

ここまでは皆さん良くご存知と思います :ear:

ここからは、バッチ処理のCDPの説明

ここで、１つ質問 :exclamation:

バッチ処理のスケールの仕組み実装のご経験のある方？

それでは本題

■どんなCDPがあるか

cdp_document.jpeg

■どんなCDPがあるか

  • 下記も勉強しました！

■どんなCDPがあるか

  • まとめると、下記のようなCDPがありました
  • ①SQSに処理対象のメッセージ送信し、それを受けるWorkerで処理実行
  • ②優先的に処理するキューを作成して処理するが、ほぼQueueChainと同じ
  • ③CloudWatchの閾値により、処理するインスタンス数を増減させるが、それ以外はほぼQueueChainと同じ
  • ④JobObserverパターンのスケジュール版
①QueueChain ②Priority Queue ③JobObserver ④Scheduled Autoscaling
queue_chain.jpeg priority_queue_chain.jpeg job_observer.jpeg Scheduled_Autoscaling.jpeg

どのCDPの導入が適切か検討しました

■大まかな仕様＜以前＞

  • Jenkinsより定期的ジョブ実行にて、バッチサーバ(EC2)へSSHログイン
  • SSH先のEC2にて、シェルコマンド実行で、$\color{blue}{\rm パラメタ別で各バッチ処理を別プロセスで起動}$
    • A処理＋B処理＝1000プロセスが２分おきに起動していた・・・
    • $\color{red}{\rm ※問題点}$
      • １インスタンスのみで上記を実行しているため、アプリ数の増大と共にプロセス数が増大し、頭打ちが来る

siyou_before.png

■大まかな仕様＜これから＞

  • Jenkinsより定期的ジョブ実行にて、バッチサーバ(EC2)へSSHログイン
  • SSH先のEC2にて、シェルコマンド実行で、$\color{blue}{\rm 処理対象のパラメタを持つSQSメッセージをキューへ送信}$
  • メッセージを取得するワーカープロセスを複数のインスタンスで起動し、$\color{blue}{\rm １つのSQS内のメッセージを奪い合う形に実装}$
  • ワーカープロセスにて、メッセージ内のパラメタ別でバッチ処理をシェルコマンドで起動

siyou_after.png

結論

:dart: QueueChainパターンを導入 :dart:

sqs_queue_chain.jpeg

しかし、そう簡単ではなかった :cold_sweat:

sqs_limit_things.jpeg

重複実行処理回避の仕組みが必要・・・ :cry:

ということで作りました :thumbsup:

■重複実行ロック機構＜以前＞

  • シェルコマンドにて、プロセス実行時にロックファイルをローカルに保存し、重複実行されるのを回避
    • １つのインスタンスで実行のため、これで良かったが・・・
      lock_before.png

■重複実行ロック機構＜これから＞

  • バッチサーバ共通でアクセスできるElasticCache(Redis)へロックを保存し、重複実行を回避
    • 送信(send)と受信(receive)で保存されるキーを分けて、バッチ処理開始時に存在チェック＆登録。
    • 終了時に存在チェック＆削除を実行。
      lock_after.png

■利用したツール

  • ワーカープロセス実行ツール
  • 重複防止ロックデータ保持機構

■はまったところや改善点

  • はまったところは特になかった
  • ElasticBeanstalkのWorker tierを利用した形での実装
    • メリット
      • AutoScalingも自動で設定され、突然の負荷増大にも対応できそう
    • デメリット
      • 現在のCI、開発フローで改修したソースのリリースなどに対応できていないため、影響範囲が大きい。
  • Jenkinsにも依存しない状態での定期実行をさせたい。
    • 現状はJenkinsが死ぬと困るので、Jenkinsの死活監視＋NewrelicでのSQS監視を入れている。
  • 本番運用時に、ワーカーによりSQSのメッセージを受け取らず、処理が行われない状態が発生 :exclamation:
    • 原因調査と対応が必要。

■参考サイト

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

6
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?