LINEで送る
Pocket

さて、一時的なアクセス負荷対策としてEC2やECSの台数を増やす以外にも(以下ブログより)、DBもスケールアウトを設定しなければなりません。今回は初めて、TerraformでAmazon Aurora Auto Scalingを設定してみたのでブログします。

[AWS][Terraform]ECS/FargateでAuto Scalingの設定をしてみた


Aurora レプリカでの Amazon Aurora Auto Scaling の使用

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html

接続およびワークロード要件を満たすために、Aurora Auto Scaling は、シングルマスターレプリケーションを使用して、Aurora DB クラスター用にプロビジョニングされた Aurora レプリカの数を動的に調整します。Aurora Auto Scaling は、Aurora MySQL と Aurora PostgreSQL の両方で使用できます。Aurora Auto Scaling により、お使いの Aurora DB クラスターは急激な接続やワークロードの増加を処理できます。接続やワークロードが減ると、Aurora Auto Scaling は未使用のプロビジョニングされた DB インスタンスに対する料金が発生しないように、不要な Aurora レプリカを削除します。

 

Aurora Auto Scaling は、DB クラスターのすべての Aurora レプリカが利用可能な状態にある場合のみ、DB クラスターをスケールします。Aurora レプリカのいずれかが利用可能以外の状態にある場合、Aurora Auto Scaling は DB クラスター全体がスケーリングに利用可能になるまで待機します。

前提としてリードレプリカに対して平均CPU使用率や平均接続数に応じて自動でリードレプリカ台数をスケールアウトすることができます。事前にアプリケーション側で接続設定をread/writeで分けるように設定する必要があります。エンドポイントは必ずクラスターのreadonlyを指定しましょう。

また、Amazon Aurora Auto Scalingを導入することで、急なスパイクアクセスに備えて手動でリードレプリカを作成するなどの運用コストがかからないというメリットもあります。しかしながら、レプリカを増やす時差がありますので502が避けられないのと、CPUの閾値を予め低めに設定すればいいというほど単純ではありません。事前に放映などで分かっているのであれば手動で予め増やしておく運用は避けられないというデメリットもあります。


Terraform

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_target

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy

  • rds.tf

スケーリングポリシーではターゲット値がCPU 80%以上になればリードレプリカが最大5台まで増やすようにしました。また自動でのスケールインは無効化にしていますが、自動削除により、うまく切り替わらずにエラーが出てしまった経験がありました。ですが、2年前だったので現在ではAWS側で修正されているかもしれない!?(以下より)

https://qiita.com/yKanazawa/items/a4342928e78f7ed44e4d

※追記

自動でのスケールイン試してみましたが、リードレプリカ削除中でも問題なくアクセスはできました。 disable_scale_in = false に有効化しても問題なさそうです!


まとめ

導入は非常に簡単だったのと構築時には設定必須だと感じました。が、オートスケール時のリードレプリカの作成が長いので、結局は事前に増やすということも念には念を入れる必要がありそうです。

LINEで送る
Pocket

カテゴリー: AWSTerraform

adachin

1989年生まれのLancers SRE。 ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。好きなツールはAnsible,Terraform,CircleCIで、ECS/Fargateでのインフラ構築を得意とする。副業では数社サーバー保守とベンチャー企業のインフラ改善やMENTAで未経験者にインフラのコーチングを実施している。また、「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、緊急対応、インフラコード化、リファクタリング、セキュリティ強化、新技術の検証、Docker開発環境の提供、AWSでのインフラ構築、ECS/Fargateへ移行、CakePHP4での管理画面作成、メンター、分析基盤の運用を担当している。個人開発では「夫婦、パートナー向け家事管理サービス/famii」をCakePHP4で絶賛開発中。

0件のコメント

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください