AWSバッドノウハウ集 2017/02 - Qiita
おことわり 主観であり何らかのデータにもとづいてはいない この記事に書いてあることは信じずに自分で試そう EC2 t2 ファミリーは他ファミリーと比べて不安定 どのインスタンスもいつかは死ぬという点では共通なのですがそのなかでもt2は故障したり不具合が発生したりする確率が非常に高い気がする なので死んだり、死にかけ状態で動き続けたりしてほしくないインスタンスはあんまりリソースを使わなくても t2.micro とかじゃなくて m3.medium にしとくとすこし可用性があがる 追記: CPUクレジット理解していないだけではとか書かれていたんですがその辺は確認している。 t2の可用性が問題になったケースいくつかあるんだけど、自分の場合はネットワークがたまに断する問題が多くて、分散DBクラスタの死活監視で1secごとにpingするだけでCPUは常に1%以下みたいなものとかに使うとカジュアルに10
GlusterFSで高可用性メールサーバを構築する | DevelopersIO
はじめに AWSでメールシステムの高可用性確保を考えたとき、どのような構成を思い浮かべるでしょうか。私が脳内に思い浮かべたのはこのような構成です。 外部から内部へのメール配送は以下の流れになります。 Route 53にてMXレコードを2行(MailGateway1とMailGateway2)設定します。 MailGatewayからMailBoxへはPostfixのtransportとrecipient_bcc_mapsで冗長的に配送するよう設定します。 内部から外部へのメール配送は以下の流れになります。 ClientのメールクライアントソフトウェアでSMTPサーバとしてInternalELBを指定し、ELBがMailBox1とMailBox2に振り分けます。 MailBoxのpostfixではrelayhostに自AZのMailGateway、fallback_relayに別AZのMail
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
