タグ

2020年12月15日のブックマーク (2件)

  • [Auroraの落とし穴]フェイルオーバー時に接続先が切り替わらない

    Amazon Web Services(AWS)のリレーショナルデータベースサービス「Amazon Aurora」のデータベースクラスターでは、1台以上のレプリカがある場合、プライマリーインスタンスに障害が発生すると、自動的にレプリカのうち優先度の高い1台がプライマリーインスタンスに昇格する。 このとき、リクエストが新しいプライマリーインスタンスに接続されるように、自動でクラスターエンドポイントのDNSDomain Name System)レコードが更新される。これによって、フェイルオーバーを実現する。通常は、障害検知からフェイルオーバーは1分以内に完了する。 しかし、アプリケーション側でDNSのTTL(Time to live)を無視し、DNSレコードをキャッシュする設定になっている場合、このフェイルオーバーに追従できず、障害インスタンスにアクセスし続けてしまう場合がある。 なおレプリ

    [Auroraの落とし穴]フェイルオーバー時に接続先が切り替わらない
    do_su_0805
    do_su_0805 2020/12/15
    それはそう、って感じだったけど言われるまでまさかーみたいな気持ちもあったDNSキャッシュについての注意喚起だった
  • Auroraの高速フェイルオーバーと無停止での切り替え | BLOG - DeNA Engineering

    こんにちは、IT基盤部の川原﨑です。 私の所属する第四グループでは、超大規模ゲームタイトルおよびゲームプラットフォームのインフラを運用しております。 そこでのAuroraの高速フェイルオーバーの仕組みと、実際に無停止で切り替えを行った手順について紹介させていただきます。 はじめに 第四グループでは、コストコントロールの一環でInstance数の増減・Instance Typeの変更を頻繁に実施しています。 例えば、 イベントなどでリクエスト増加が見込まれるときにInstance数を増やす、またはInstance Typeを1つ上のものに変更する リクエストが減少傾向にあれば、Instance数を減らす、またはInstance Typeを1つ下のものに変更する などです。 これはWebサーバだけにとどまらず、DBサーバについても同様です。 EC2上でMySQLを運用している環境では、フェイル

    Auroraの高速フェイルオーバーと無停止での切り替え | BLOG - DeNA Engineering
    do_su_0805
    do_su_0805 2020/12/15
    Aurora のクラスタ側のF/O追従ではなく独自でF/Oの仕組みを構築して高速化した例