【AWS】SQSキューの前には難しいこと考えずにSNSトピックを挟むと良いよ、という話 | DevelopersIO
よく訓練されたアップル信者、都元です。SQSはみなさん使われていますでしょうか。複数のコンポーネント間の疎結合を保ち、バッチ処理等の冗長性・拡張性を確保するために必要不可欠なサービスです。 SQSの活用イメージにつきましては、AWSでジョブWorkerを構成するベストプラクティスのSQSの巻やBeanstalk worker tierの巻をご覧いただくと良いと思います。 さて。SQSを使うぞ、ということになった場合。メッセージを投げる側（＝プロデューサ）と、メッセージを受け取る側（＝コンシューマ）が必要です。どこかから持ってくる（実装済みの既成品を探してくる）か、もしくは自分自身で実装するわけです。 もちろん、プロデューサはSQSのインターフェイス（API）を理解し（依存し）ていなければなりません。要するに、キューにメッセージを投入する方法を知っており、それを使ってメッセージを投げるような
AWSでジョブWorkerを構成するベストプラクティス 〜 SQSの巻 | DevelopersIO
よく訓練されたアップル信者、都元です。AWSでシステム構築をする場合は、Design for failureという考えに基いて、複数AZにまたがる形の冗長構成を組むのがベストプラクティスです。さらに、このように分散させた各インスタンスには、出来る限りマスターを作らない、つまりSPOFとなるインスタンスを避ける構成であるのが理想です。 という話題については以前AWSにおける可用性の考え方というエントリーでも書きました。 可用性 (availability) と拡張性 (scalability) 本題はジョブWorkerですが、WebサーバやDBサーバの可用性と拡張性を先におさらいしておきましょう。 Webサーバ この考えで構築する最も基本的な構成が、Webシステムにおける ELB + Webサーバ の構成です。この構成マルチAZと呼び、片方のAZが丸ごとダウンしたとしても、サービス自体はダウ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
