AWSでジョブWorkerを構成するベストプラクティス 〜 Beanstalk worker tierの巻 | DevelopersIO
よく訓練されたアップル信者、都元です。先日、AWSでジョブWorkerを構成するベストプラクティス 〜 SQSの巻として、SQSを使ったスケーラブルなジョブWorkerアーキテクチャをご紹介しました。人間相手のHTTPリクエストの間に完了させるには長すぎるジョブを実行したい場合は、とりあえずSQSに投げて非同期に処理させよう、という仕組みです。 投げる側は、Javaであればこんな感じですね。キュー毎にURLがあるのでそれを指定して適当なメッセージ（本来はJSONなんかが良いんだと思います）を投げ込みます。 sqs.sendMessage(new SendMessageRequest(QUEUE_URL, "foobar")); Worker側としては、こんな感じでメッセージを受信しては処理して削除、というのを繰り返せばよいです。 while (true) { ReceiveMessageR
AWSでジョブWorkerを構成するベストプラクティス 〜 SQSの巻 | DevelopersIO
よく訓練されたアップル信者、都元です。AWSでシステム構築をする場合は、Design for failureという考えに基いて、複数AZにまたがる形の冗長構成を組むのがベストプラクティスです。さらに、このように分散させた各インスタンスには、出来る限りマスターを作らない、つまりSPOFとなるインスタンスを避ける構成であるのが理想です。 という話題については以前AWSにおける可用性の考え方というエントリーでも書きました。 可用性 (availability) と拡張性 (scalability) 本題はジョブWorkerですが、WebサーバやDBサーバの可用性と拡張性を先におさらいしておきましょう。 Webサーバ この考えで構築する最も基本的な構成が、Webシステムにおける ELB + Webサーバ の構成です。この構成マルチAZと呼び、片方のAZが丸ごとダウンしたとしても、サービス自体はダウ
Amazon SQS による分散キュー | DevelopersIO
Amazon SQS とは Amazon SQS は、AWSが提供する分散キューサービスです。APIを使ってアクセスすることができます。SQSによってアプリケーションのメイン処理と非同期に動いてほしい処理を分離することができます。キューは待ち行列を提供し生産者（Producer）によって生成されたメッセージのバッファリングをし、消費者（Consumer）によってコンポーネントへメッセージデータが渡されます。キューは複数登録することができます。キューに対して複数のリーダーとライターが接続できますので、ひとつのキューに対して複数のアプリケーションから同時に利用することができます。 分散キュー SQSは障害時に正常系へ切り替わるように設計された（フェイルセーフな）仕組みを提供しています。おなじみの分散配置されたAWSインフラの成せる技です。キューの仕組みは自前でも構築は容易ですが、フェイルセーフ
Amazon SQSの使いどころ 実際編
PDFを作る処理をWeb上でやります。このPDFを作るには、最低でも数分かかる事が解っています。したがって、PDFが出来たら、ユーザーにメールでお知らせする事にします。 ここでは、フロントエンドにRuby on Railsを、バックエンドにJavaを用いています。両者は同一のデータベースを参照出来るようになっています。言い換えると、両者で共有している部分はデータベースだけで、粗な結合になっています。 フロントエンドの役割は、ユーザーと直接対話する事です。ここでは、PDF作成受付画面と、受付完了画面の表示を行います。 動きを解説する前に、少しデータベースに関して書いておきます。データベースは、ごく一般的なRDBを使用し、PDF作成ジョブを表す「Jobs」というテーブルを用意してあります。 このJobsテーブルは、このように定義してあります。 CREATE TABLE jobs ( id SE
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
