[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO
水平分散のアーキテクチャを考えるときに、「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」「AWS であれば３ AZ にまたがるとよい」とはよく聞かれます。それがどういう意味をもつのか、主に可用性の面から考えてみました。 みなさん、AWS使ってますか！（挨拶 AWSに限らず、ある程度の規模の何かしらの本番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。 「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」 「AWS であれば３アベイラビリティゾーン (AZ) にまたがるとよい」 負荷分散装置（ロードバランサー）は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね？ AWS の３ AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。
![[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
ALBは3つのAZを指定するのがベストプラクティス？
先日発生したAWSの大規模障害に関して、2つのAZを使う構成だと片方で障害が発生したときそのAZを切り離して1つのAZで運用できないので、切り離せるように3つのAZで運用すべきという話（ITMedia News, orangeitems’s diary）がありますが、これは理想的ではないと思います。 RedisやMongoDBなどのpersistenceのクラスタで3つの独立したゾーンに各ノードを配置する設計は定番で、それは障害でネットワークが分離した場合にsplit-brain問題を防ぐために原理的にそうせざるを得ないわけですが、今回の障害はそれとは関係ありません。 ALBが2つ以上のAZの使用を前提としており、1つのAZのみの設定ができないのは、AWSが提唱するベストプラクティスを強いることを目的とした（言わば「おせっかい」な）仕様のためです。ロードバランサの原理として2つ以上の独立し
AWSのAZ(アベイラビリティーゾーン)とは？AZ障害が起きたときどうすればよいのか
アドテク本部の黒崎( @kuro_m88 )です。 2019/08/23にAWSの東京リージョンで特定のAZ内で大きめの障害がありました。 私が開発しているプロダクトもAWSの東京リージョンを利用していて、常時数百インスタンスが稼働しているため、今回の障害の影響範囲に含まれていました。 何が起きたのか？ AWSから公式発表が出ています。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 データセンタ内の冷却の障害が原因で一部のハードウェアホストが過熱し電源が失われてしまったようです。これにより影響を受けたハードウェアホスト上で稼働していたEC2インスタンスやEBSボリュームは電源が失われているため、外部から見ると突然応答がなくなったように見えました。 担当サービスでも公式発表と同じくらいの時刻にELBやその配下のサーバ
AWSバッドノウハウ集 2017/02 - Qiita
おことわり 主観であり何らかのデータにもとづいてはいない この記事に書いてあることは信じずに自分で試そう EC2 t2 ファミリーは他ファミリーと比べて不安定 どのインスタンスもいつかは死ぬという点では共通なのですがそのなかでもt2は故障したり不具合が発生したりする確率が非常に高い気がする なので死んだり、死にかけ状態で動き続けたりしてほしくないインスタンスはあんまりリソースを使わなくても t2.micro とかじゃなくて m3.medium にしとくとすこし可用性があがる 追記: CPUクレジット理解していないだけではとか書かれていたんですがその辺は確認している。 t2の可用性が問題になったケースいくつかあるんだけど、自分の場合はネットワークがたまに断する問題が多くて、分散DBクラスタの死活監視で1secごとにpingするだけでCPUは常に1%以下みたいなものとかに使うとカジュアルに10
通信すら飲み込むAmazon、ルーター用半導体も自社開発と公表
「全世界を100Gビット/秒の専用光ファイバー網で接続」「ルーター/スイッチ用半導体は自社開発」「一つのアベイラビリティゾーンで30万台のサーバーを運用」――。米Amazon Web Services（AWS）でデータセンター（DC）戦略を統括するJames Hamiltonバイスプレジデント（写真1）は2016年11月29日（米国時間）、「AWS re:Invent 2016」の基調講演で同社のクラウドの衝撃的な内部仕様を明らかにした。 Hamilton氏はこれまでもAWSの内部仕様を明らかにしているが（関連記事：「AWSの裏側を数字で教えよう」、上級エンジニアが秘密を公開）、同社の大陸間ネットワークの詳細やネットワーク機器用半導体を開発している事実、自社開発サーバー/ストレージの詳細を明らかにしたのは今回が初めて。ライバルである米Googleも最近、DCや自社開発サーバーの詳細を明らか
AWSの一括請求に関するアレコレ - Qiita
一括請求(Consolidated Billing)とは？ 複数のAWSアカウントの請求を1つのアカウントに紐付けて請求を一本化する機能です。 主に複数プロジェクトを抱える組織などで便利な機能だと思いますが、これを活用することで受けられるメリットもいくつかあるので覚えておくと良いです。 一括請求に関する詳細は、公式ドキュメントや、ぐぐれば他にもっと手順や何やらを詳しく説明しているサイトがあるのでそっちを見てください。 ここはそれらのざっとググった情報からは見つけることが出来なかった、一括請求に関する細かい点を調査して補足するメモです。前半にざっとメリットなども書いてますが、 後半の「注意点」以降がこの記事のメイン です。 メリット 請求を1箇所にまとめられる 一番よくある活用方法は、プロジェクトや顧客ごとに新規AWSアカウントを作って分けて使うことでしょう。こうすることでプロジェクト毎の利
AWSの複数アカウントのAZ名の対応を調査する - Qiita
AZ名と実データセンターの対応はアカウント毎に異なるということ AWSのアベイラビリティゾーン名（以下AZ名）と実データセンターの対応は実はユーザ毎に異なります。 これは多分使用されるAZが偏ることを防止する為だと思われます（一番上のAZを選ぶユーザが多いと予想される）が、まぁ真相はわかりません(^^; AZ名の対応不一致に関わる問題 AZの不一致はアカウント間のデータ転送料金に影響してきます。 同一AZ同士の通信（Availability Zone Data Transfer）は無料ですが、同一リージョンの別AZ間の通信（Regional Data Transfer）は低価格ながら料金が発生するからです。 要はアカウントAのap-northeast-1aとアカウントBのap-northeast-1aの間で通信を行う際は、どちらもap-northeast-1aというAZ名ですが、それぞれの
Amazon EC2のAvailability Zoneの名前はアカウント毎に違う
はじめに 先のエントリにて、EC2のデータ転送と課金の関係についてまとめました。EC2では、同一のAZ内に存在しているインスタンス間でのデータ転送は、プライベートIPを使ったものについては課金されません。 Scutum(スキュータム)はSaaS型のWAFなので、お客様のウェブサーバとScutumのWAFインスタンスの間にそれなりの量のトラフィックが発生します。そのため、この課金されないトラフィックをうまく使いたいと考えていますが、ここに落とし穴が潜んでいました。実は、EC2でのAZは、アカウント毎に指している実体が異なることがあるのです。 (クリックで拡大します) 発見に至ったきっかけ 先のエントリの内容を調査する段階で、私たちは2つの異なるAWSアカウントを用意しました。これは(ScutumがEC2でサービスを提供する場合には)、お客様のウェブサーバのインスタンスの管理アカウントと、Sc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「AWSの裏側を数字で教えよう」、上級エンジニアが秘密を公開