Queue(キュー)サーバを利用するメリット

• サーバの処理を分離することで非同期処理が出来る
  →ユーザを待たせない、ユーザ体験の向上
• アプリ処理の分離、ログ入出力を分離出来る
  →疎結合なシステムの実現

 

1. 購入処理で決済を実行し、ページ遷移
   裏側：購入処理を行い最後にメール内容をキューとしてキューサーバに送信し、サンクスページに遷移をする
2. 処理しましたの表示
   裏側：キューサーバのキューを取り出してメールサーバに渡す

キューサーバに処理をためておくことで、メール処理の成功をクライアントに待たせずに素早くサンクスページを表示できる。

 

AWS SQSを利用するメリット

サーバレス

• Queueサーバが単一障害点にならない
• 高可用性、高障害耐性のサーバレスとして管理せずにすむ
• 障害に強い
  EC2側に障害が起こってもSQS側で4日間キューを保持してくれる(デフォルト設定)

 

AWS SQSの注意点

FIFO(先入先出)ではない。

FIFOに対応した。

// FIFO(First In First Out, 先入先出)

FIFOの場合

1. A, B, C, Dという順番でメッセージを投げ込んだ
   D → SQS{C, B, A}
2. 取り出してみる
   SQS{D, C, B} → A
   先に入れたものが先に出る

AWS SQSの場合

1. A, B, C, Dという順番でメッセージを投げ込んだ
   D → SQS{C, B, A}
2. 取り出してみる
   SQS{D, C, A} → B
   今回はBが出たがCが出るかもしれない、順番は保証されない！

 

 

クラウドデザインパターン Queuing Chainパターン

• EC2-A(A処理) → SQS → EC2-B(B処理) → SQS → EC2-C(C処理) → SQS → ・・・
  SQSを挟んで処理を繋いでいく構成

 

 

1つのサーバで処理した場合

1. ショッピングサイトでユーザがカートの決済ボタンをクリック
2. ロジック処理を行う →サーバローカルにログを出力する
   // 処理に時間がかかると3に進めずユーザをずっと待たせる
3. ユーザに『注文しました！』のメッセージを返す

ロジック処理中にサーバが死ぬとログが残らない。

 

Queueを利用して、処理とログ入出力を分離した場合

 

Frontサーバ(表示処理)

1. ショッピングサイトでユーザが注文ボタンをクリックする
2. 「注文ID」、「注文内容」、「注文ステータス(未処理)」をQueueサーバにキューを送る
3. ユーザに「有難う御座います。正式に受注を受け付けましたらメールを送ります、お待ち下さい」といったメッセージを表示させる

すぐにユーザにメッセージを返せる！

 

Queueサーバ(AWS SQS)

• メッセージをキューとして保管する

 

DBサーバ

• クエリがきたら処理するヾ(๑╹ꇴ◠๑)ﾉ”

 

Backサーバ(処理)

1. ひたすらずっとQueueサーバにキューがないか監視する！(´｡✪ω✪｡｀)
2. キューを見つけた！(´｡✪ω✪｡｀)ﾋﾟｺｰﾝ
3. DBサーバに「注文ID」、「注文内容」、「注文ステータス(未処理)」をINSERTする
4. ログ用のキューをキューサーバに発行「注文ID」、「注文内容」、「注文ステータス(未処理)」
5. アプリケーションなロジック処理をする
   // いろいろやる
6. 完了処理
   6-1. UPDATEクエリをDBサーバに送る：「注文ID」の「注文ステータス(完了)」
   6-2.  ログ用のキューをキューサーバに発行：「注文ID」の「注文ステータス(完了)」
   6-3. 正式受注したことをユーザにメール通知：「まいど！今用意してるから待っててな！」

 

 

バッチ・ログサーバ

1. バッチ処理でQueueサーバにログのキューを取りに行く
2. ログに出力を行う