AWSでジョブWorkerを構成するベストプラクティス 〜 SQSの巻 | DevelopersIO
よく訓練されたアップル信者、都元です。AWSでシステム構築をする場合は、Design for failureという考えに基いて、複数AZにまたがる形の冗長構成を組むのがベストプラクティスです。さらに、このように分散させた各インスタンスには、出来る限りマスターを作らない、つまりSPOFとなるインスタンスを避ける構成であるのが理想です。 という話題については以前AWSにおける可用性の考え方というエントリーでも書きました。 可用性 (availability) と拡張性 (scalability) 本題はジョブWorkerですが、WebサーバやDBサーバの可用性と拡張性を先におさらいしておきましょう。 Webサーバ この考えで構築する最も基本的な構成が、Webシステムにおける ELB + Webサーバ の構成です。この構成マルチAZと呼び、片方のAZが丸ごとダウンしたとしても、サービス自体はダウ
非同期処理を使いこなそう ! - 第 3 回 AWS サービスを活用した非同期処理アーキテクチャ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは、プロフェッショナルサービス本部クラウドアプリケーションアーキテクトの五十嵐です。 「非同期処理を使いこなそう !」シリーズの第 3 回となる今回は、いよいよ物理アーキテクチャ、つまり AWS サービスを利用したアーキテクチャ構成を考えていきます。 これまでの連載記事では、EC サイトを例として 第 1 回 で同期処理と非同期処理の使い分けについてご説明し、第 2 回 で各処理のステップや論理構成についてご説明しました。これをベースとして、第 3 回は非同期処理を実現するための AWS サービスをご紹介し、それらを活用した非同期処理アーキテクチャについてご説明します。 みなさまは AWS を活用したアーキテクチャ (以下「アーキテクチャ」と記載) をご自身で描かれたことはありますでしょうか。もしあまりイメージがわいていなかったり、見たことはあるけどもご自身で描いたことがないという
非同期処理を使いこなそう ! -第 2 回 非同期処理と同期処理の処理構造 - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
皆さんこんにちは。プロフェッショナルサービス本部のデジタルトランスフォーメーションチームでマネージャーをしています堀場です。 さて、いきなりですが、先日、ふと、頭に思い浮かんだ単語があります。それがこちら。 「機能」「情報」「連絡」「手順」「時間」・・・ 25 年以上前に覚えた単語がふと出てきたわけで・・・・この後、何が続くかご存知でしょうか ? 答えは、「論理」「暗号」です。 これは、モジュール強度 (または凝集度) の段階を表すもので「暗号」は凝集度が低く「機能」がもっとも高いと定義されています。なぜ、思い出したのかは謎です。ちなみに、10 年前の資料ですが IPA が提供している IT 人材育成用の汎用コンテンツ の 講義ノート に簡単な解説がありましたので興味がある方は読んでみてください。 凝集度が高いほど、堅牢性、信頼性、再利用性が高く、コードの読みやすさなどの点で好ましく、凝集
非同期処理を使いこなそう ! - 第 1 回 非同期処理ってなんだろう ? - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは、プロフェッショナルサービス本部クラウドアプリケーションアーキテクトの五十嵐です。 先日、Web で美味しそうな料理の写真を見かけ、自宅で作ってみることにしました。 大きく分けて以下の手順が必要でしたが、みなさまでしたらどのように調理を進めるでしょうか ? 鍋で水を沸騰させる 野菜を切る 野菜を茹でる 調味料で味付けをする 皿に盛り付ける 1. で鍋を火にかけた後、鍋の前で沸騰するのをじっと待ちますか ? 今回は次の手順が沸騰を待たなくてもできる「野菜を切る」のため、沸騰を待たずに 2. で野菜を切り始め、沸騰したことを確認してから 3. で野菜を茹で始めると思います。 このようにして、完成までの時間を短縮化させる工夫をするのではないでしょうか。「他タスク (今回は水の沸騰) の完了を待たなくても良いケース (野菜を切る)」と、「他タスクの完了を待つべきケース (野菜を茹でる)」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
