AWSでジョブWorkerを構成するベストプラクティス 〜 SQSの巻 | DevelopersIO
よく訓練されたアップル信者、都元です。AWSでシステム構築をする場合は、Design for failureという考えに基いて、複数AZにまたがる形の冗長構成を組むのがベストプラクティスです。さらに、このように分散させた各インスタンスには、出来る限りマスターを作らない、つまりSPOFとなるインスタンスを避ける構成であるのが理想です。 という話題については以前AWSにおける可用性の考え方というエントリーでも書きました。 可用性 (availability) と拡張性 (scalability) 本題はジョブWorkerですが、WebサーバやDBサーバの可用性と拡張性を先におさらいしておきましょう。 Webサーバ この考えで構築する最も基本的な構成が、Webシステムにおける ELB + Webサーバ の構成です。この構成マルチAZと呼び、片方のAZが丸ごとダウンしたとしても、サービス自体はダウ
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
livedoor Techブログ : なんでもありのWebアプリケーション高速化バトル、#isucon 開催のお知らせ
こんにちは、ライブドア技術部会の櫛井です。 Webサービスの高速化に取り組んでいる全てのエンジニアに存分にその腕をふるってもらうべく、ライブドアがサーバ100台を準備してイベントを行います。いい感じにスピードアップコンテスト、略して ISU Contest (Iikanjini Speed Up Contest) #isucon です！レギュレーション事前公開、細かいルール無用のチームバトル。腕に覚えのあるエンジニアにはぜひ参加していただきたい！ なお、参加者募集の開始は7月28〜29日頃を予定しています。Ustream等による中継はございませんので、ぜひ直接ご参加ください！ レギュレーション概要 レギュレーション詳細は後日、参加募集の際に全て発表します。現状は概要のみでご容赦ください。また詳細が変更される場合があります。(参加応募開始時に公開するものからは変更されません。) ライブドアが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
