AWS

Auroraの機能など

更新日：

知識がないのに経験だけ積んだって力にならないんだよね。という話を聞いて腑に落ちた。
資格を取るために学んだことは、日々悩み考える色々な出来事を説明するための武器になる。
今自分は何をやろうとしていているのか、経験して後から回想するのでは余りに効率が悪い。

今回はAurora。やはり高いので個人では手が出ないのだけれど、
それなりの仕事であれば第1選択になり得る。
RDSと比較して圧倒的に高機能で運用時に困りそうなユースケースが通常の機能として既に備わっている.
参考書を1周したので、(著作権侵害にならないように)要約して自分の言葉でまとめていく。

【目次】

クォーラムモデル

  • コンピューティングリソースとストレージが分離している. コンピューティングとストレージを独立して管理する.
  • コンピューティングリソース、ストレージ共に3AZに分散してレプリケートする. 1AZにコンピューティングリソース1台、ストレージ2台.
  • 6台のストレージのうち2台が故障しても読み書き可. 3台が故障すると書き込みが不可となるが読み込み可.
  • RDSはスタンバイレプリカとリードレプリカが別扱いだが Auroraはスタンバイ、リード共に共通.
  • プライマリ、レプリカ、ストレージ(ボリューム)をセットでクラスタと呼ぶ.

可用性

  • 読み書き可能なクラスターエンドポイント. 読み取り専用エンドポイント、任意のインスタンスにつなぐエンドポイントなどなど.
  • クラスタ内の1台が読み書き用, 他は読み取り専用なので、読み書き用が落ちたときに読み取り専用が読み書き用に昇格する. これがフェイルオーバーの概念.
  • クラスターエンドポイントに繋いでおくと、エンドポイント先で障害時に勝手にフェイルオーバーが発生する
  • レプリカにはフェイルオーバー優先度をつけられる. 優先度が高い方が優先的にフェイルオーバー先になる. 同じだとインスタンスの大小で決まる.
  • 多くの場合、フェイルオーバーの時間はRDSよりも短い.
  • 通常、プライマリにのみキャッシュが効く. フェイルオーバーでキャッシュヒットしなくなる. クラスターキャッシュ管理をONにするとフェイルオーバー時に引き継がれる.
  • 複数のリージョンに跨ってクォーラムモデルを配置するAuroraグローバルデータベース. DR対策. リージョン間のデータコピーは1秒未満.
  • 複数のリージョンに跨ってクラスタを配置するクロスリージョンレプリケーション. DR対策. レプリカ間のデータコピーに時間がかかる.
  • 通常クラスタ内の1台が読み書き可能で他は読み取り専用だが、全てを読み書き可能にできる.

パフォーマンス

  • 書き込み性能を上げるにはインスタンスサイズを上げる.
  • Auroraレプリカはスタンバイレプリカ、リードレプリカを兼ねる. リードレプリカとして使うと読み込み性能が上がる.
  • 読み込みエンドポイントは全ての読み込み用レプリカを代表する. アプリ側からは1個だが中は数台.
  • Aurora AutoScaling. 読み込みクラスタのCPUまたは接続数が閾値以下になったときに自動スケールする.
  • Aurora Serverless. インスタンス数,インスタンスサイズを自動スケールする. 未使用時に勝手に落ち,高負荷時に勝手に上がる.
  • Aurora Serverlessは, 前提として利用頻度が少なくほとんど未使用だが、変化するときは大きく変化する、というアプリに適している.
  • スケールアップは限界がある. つまり重量級のクエリの高速化には限界がある. スケールアウトはより柔軟なので多数のクエリの同時実行はより簡単に対応できる.

セキュリティ

  • 基本的にRDSと同様.
  • VPC内に設置する. NACL、SGを使ってアクセス制御する.
  • データ格納時・転送時に暗号化する.
  • IAMロールを使ったクレデンシャルレス化.
  • Auroraの監査機能は Advanced Auditing. 記録するクエリ種別を選択できる. CloudWatchLogsに転送可.

コスト

  • Auroraレプリカ1台ごとの稼働時間で課金.
  • Aurora Serverlessはキャパシティユニット単位で課金. (cf.DynamoDB)
  • RDSはインスタンスとストレージが密結合しているためストレージ容量はインスタンスに紐づく. インスタンス作成時に確保した量に課金.
  • Auroraはストレージが分離しているためAuroraレプリカとは関係なく使った容量だけ重量課金.
  • データを削除して未使用領域が出ると自動的に課金対象が減る.
  • 通信はVPC外へのアウトバウンドにのみ課金.

メンテナンス

  • メンテナンスウインドウまたは即時で実行.
  • Auroraではクラスター単位でパラメータを管理する.設定はクラスタ内のレプリカ全てに適用される. インスタンス単位のパラメータ管理もできる.
  • ZDP(Zero Day Patch). ベストエフォートでダウンタイムなしのパッチ適用をおこなう. パッチ適用中も接続が維持される.

バックアップ

  • システムバックアップはメンテナンスウインドウで日時で行われる.
  • データバックアップは継続的かつ増分的な自動バックアップ. 保持期間中の任意の時点へ復元できる. (PITR)
  • データバックアップの保持期間は1日-35日. 0日(無効)には出来ない. S3に保存される.
  • 手動でスナップショットを取得可能.
  • システムバックアップ、データアップバック共に復元先は新しいAuroraクラスター. 保持期間の任意の時点を指定する.
  • Auroraクローン. ストレージではなくコンピューティング部分のみをコピーする. リードレプリカ複製による読み取り性能向上.
  • 1回でも書き込みしようとするとストレージ部分がコピーされる. データエクスポート、分析等読み込み専用のタスクに使う.
  • Aurora MySQLでのみバックトラックを使用可能. 最大24時間前までSQL操作を遡れる.
  • S3エクスポート. RDSはスナップショット作成操作だが, AuroraはSQLクエリ操作.

モニタリング

  • CloudWatchによるメトリクス監視. 拡張モニタリングによる詳細メトリクス監視.
  • コンピューティングに関わる(CPU,メモリ等)をインスタンス単位のメトリクスとしてCloudWatchLogsで監視.
  • ストレージに関わるクラスタ単位のメトリクスとしてCloudWatchLogsで監視.
  • 監視が上手くいっているかを確認するため、障害を自力でシミュレートできる. 障害挿入クエリ.
  • DBインスタンス,Auroraクラスタ,ディスクの障害.
  • CloudWatchLogsよりもリアルタイム性があるデータベースアクティティストリーム. Amazon Kinesisにリアルタイムで入る.
  • Kinesisに入ったデータストリームをElasticSearch等で可視化する.

その他

  • Aurora MySQL. SQLからLambda関数を呼べる.
  • Aurora MySQL. SQLからSageMakerエンドポイントを呼べる.

-AWS
-

Copyright© ikuty.com , 2024 AllRights Reserved Powered by AFFINGER4.