AWS

AWS SQS Queueの用途

 

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

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

 

AWS SQSを利用するメリット

サーバレス

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

 

AWS SQSの注意点

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. ログに出力を行う

 

 

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)