Amazon Auroraのカスタムエンドポイントをフェイルオーバーに追従させる

この記事はGENDA Advent Calendar 2023の5日目の記事です。qiita.comはじめに新しい会社にインフラエンジニアとして入社して、9か月が経過しました。この9か月間、難なく対応できたこともあれば、非常に苦労したこともあります。そこで今回は、入社してから「役に立ったスキル」と「補ったスキル」をそれぞれ振り返ってみようと思います。役に立ったスキルまずは、これまでの経験で培ったスキルのうち役に立ったものを紹介します。AWSの知識この能力を買われて採用されたのですから、ここは一番大事ですね。特に、CloudFormationテンプレートを読み書きできることが大きく役立ちました。入社してすぐ担当プロダクトのキャッチアップから入りましたが、インフラ構成図とCFnテンプレートをあわせて読むことで、インフラがどうなっているかスムーズに理解できました。自分が使ったことのない機能が使われていても、テンプレートに設定内容が全て書いてあるため理解にはさほど苦労しませんでした。各サービスができることを一通り知っていることも大きく作用していると思います。他にも、以下のようなスキルが役に立っています。RDSのパフォーマンスインサイトや監査ログ出力、S3に出力したログをAthenaで読む、など調査に役立つ知識スポットインスタンスやリザーブドインスタンスといった費用削減の知識AWS CLIを使ったスクリプト開発スキルトラブルシューティング能力インフラエンジニアあるあるだと思うのですが、知らないプログラムでもログを元にソースコードを追いかけて問題箇所を特定するの、得意だったりしませんか？「アプリ側でこのエラーメッセージが出るということは……、このエラーメッセージを定義している定数名はこれで、この定数が使われるシーンはここにあるから、なるほどこのメソッドで問題が起きているのだな。このときバックエンドではこのログが出ているから……、原因わかりました」簡単な問題であれば自分で直してしまうこともありました。ただこれは、あくまでエラーメッセージやログにヒントがあることが前提となります。実装担当のエンジニアのみなさん、わかりやすいログを出してくださってありがとうございます。手書きノートによる情報整理以前、手書きノートのよさを語る記事を書きましたが、手書きノートを書く習慣は今でも健在です。note.com基本的にタスクの進め方について細かい指示はなく、どう進めるかは自分に任せられています。そのため、数か月がかりで進めるような大きなタスクは自分で計画を立てて進める必要があります。ゴールが遠すぎて、次に何をすればいいか迷ってしまう場面もしばしばありました。そんなとき、手書きノートが役に立っています。目指すゴールはどんな姿なのかゴールに到達するには何を満たす必要があるのかどんな選択肢があり、それぞれのメリット・デメリットは何か今できていることとできていないことは何で、できていないことは何でつまづいているのか関係者は誰で、何を伝えておかないといけないのかなど、自分がおかれている状況をノートに書き出してみると、今の自分の課題や疑問が見えてきて、次にやるべきことが分かります。例えば、「どうしてこの選択肢を選ぶのか、ちゃんと人に説明できる？ちょっと自信ないな……」と感じたら、「不安な部分をもう少し調べよう」「分かりやすい説明資料を書こう」というように次のアクションを決めることができました。新しい会社に入社してから、ノートとボールペンの消費ペースが明らかに早くなっています。補ったスキル次に、これまで経験がなく学習が必要だったスキルを紹介します。Amazon ECS興味はありつつも実務で触れる機会の少なかったECSを、ここへきてガッツリ触っています。「サービス？タスク？よくわかんない……」という状態から始めたため、習得するまでにかなり苦労しました。とにかく事例を読み漁ってみたり、aws.amazon.comハンズオンをやってみたり。aws.amazon.comありがたいことに時間をかけてじっくりやらせてもらい、（いくつか課題は残るものの）自分ひとりで環境を構築できるまでになりました。GitHub Actions自分の担当プロダクトではCI/CDの一部にGitHub Actionsを使っています。GitHub Actionsを使うのは初めてだったので、これも0から学習しました。AWS公式が便利なアクションを提供しているので、変わったことをしなければ簡単に実装できるのが非常に便利です。今回は上述したECSと合わせて、GitHubからECSにデプロイするワークフローを作りましたが、大まかな流れはほとんど公式サンプルの通りです。docs.github.comただし、正常系を書くだけなら簡単ですが、「リトライ時の挙動は？」「Revertしたときの挙動は？」というように異常系を考慮すると記述量が増えます。これは全てのプログラミングに共通して言えることかもしれませんね。Datadog多機能な監視ツールです。できることが多く、未だにすべての機能を把握しきれていません。自分の担当プロダクトでは、ログ収集、APMのトレース、SLO、ダッシュボードを主によく利用しています。入社時にはすでに前任者がいい感じにセットアップしてくれており、ログ収集とAPM、各種メトリクスは見られる状態でした。前任者いわく「セットアップは簡単だった」とのことですが、それが本当ならこんな充実した機能を簡単に使えるのはすごいことだと思います。入社してから自分で設定したものは、主に以下の2つです。SLOサービスの中でも重要な機能をSLI（Service Level Indicators, サービスレベル指標）として定義し、閾値を定めてSLO（Service Level Objectives, サービスレベル目標）を設定しました。例えば、「〇〇機能が0.1秒以上かかっていたら異常なレスポンスとみなす」「7日間でレスポンスの99.9%が正常でなければならない」といった設定をしています。SLI・SLOについては概念こそ知ってはいましたが、実務に取り込むのはこれが初めてでした。ダッシュボード現在起きている（または起こりそうな）問題を検知したり、過去に起きていた問題を調査するため、サービスの状態を俯瞰できるダッシュボードを作りました。毎朝出勤してすぐ確認することを日課としています。まだメトリクスを並べるしかできてないので、もう少し使いこなしたいです。まとめ自分のスキルが活かせるだけでなく、新しいスキルを伸ばす機会も得られたのがうれしいですね。そんな弊社ではインフラエンジニアを募集中です。イケてるインフラを作りたい！という方をお待ちしております。hrmos.co来年もどうぞよろしくお願いいたします。

新しい会社で役に立ったスキルと補ったスキル

はじめにこんにちは、インフラエンジニアのなみきです。私の担当プロダクトでは、ステージング環境のAuto Scaling Groupでスポットインスタンスを利用しています。当初、ステージング環境では費用の安さを優先して意図的にベストプラクティスから外れた設定にしていました。そんな中、スポットインスタンスの起動に関する2つの問題に遭遇しました。結論としては単純に「ベストプラクティスに従いましょう」というだけの話ですが、一見して何が悪いのかすぐには分かりませんでした。したがって、今後同じ問題に遭遇した人の役に立つよう、「こんな設定にするとこんな問題が起きる」という一例として紹介したいと思います。結論Auto Scaling Groupの設定を以下のように変更しました。対応前割り当て戦略（SpotAllocationStrategy）: lowest-priceインスタンスタイプ: t4g.medium対応後割り当て戦略（SpotAllocationStrategy）: price-capacity-optimizedインスタンスタイプ: t4g.medium / t4g.large / c6g.large / m6g.largeステージング環境では安定性よりも費用の安さを優先して、意図的に lowest-price かつインスタンスタイプ1種類としていました。ですが後述の問題が発生したため、割り当て戦略を変更し、インスタンスタイプを増やしました。問題1: インスタンスが無限に起動と終了を繰り返すある時、ステージング環境のAuto Scaling Groupにおいて、異常な頻度でスポットインスタンスが起動と終了を繰り返していることに気付きました。異常な頻度で増減するインスタンス数遡って確認すると05/16から発生しており、徐々に発生時間が長くなっていることが分かりました。ある時期から発生していたスポットインスタンスを使っているのはステージング環境だけなので本番ユーザーへの影響はありませんが、不安定な状態が続くことで予期せぬ問題が発生すれば開発に支障が出るため、詳しく調査することにしました。リバランスレコメンデーションの意図せぬ挙動Auto Scaling Groupのアクティビティ履歴を確認すると、およそ7分おきに次のようなイベントが発生していました。大量の「rebalance recommendation」イベントAt YYYY-MM-DDThh:mm:ssZ an instance was launched in response to an EC2 instance rebalance recommendation.At YYYY-MM-DDThh:mm:ssZ an instance was taken out of service in response to an EC2 instance rebalance recommendation.「rebalance recommendation」とは、スポットインスタンスの中断リスクが高まったときに、中断リスクの低い別のスポットインスタンスに置き換えを試みる機能です。今回、起動と終了を繰り返すスポットインスタンスはすべてap-northeast-1aに偏っていたため、ap-northeast-1aでスポットインスタンスのキャパシティを確保しづらい状態が続いていたことが分かります。このとき以下のようなループが発生していました。中断リスクが高いスポットインスタンスに対し、リバランスレコメンデーションが発生中断リスクが高いスポットインスタンスが終了するAuto Scaling Group内でAZのバランスをとるため、同じAZにインスタンスを起動するap-northeast-1aで起動したスポットインスタンスが、中断リスクが高いと判断される（1へ戻る）Auto Scaling Groupの設定見直しこの時点でのAuto Scaling Groupの設定は以下のとおりです。前述の通り、ステージング環境では費用の安さを優先してこのような設定にしていました。割り当て戦略（SpotAllocationStrategy）: lowest-priceインスタンスタイプ: t4g.medium割り当て戦略を lowest-price とすると、スポットインスタンスの中断リスクが高くなります。docs.aws.amazon.comlowest-price 割り当て戦略を使用している場合、代替スポットインスタンスが中断するリスクが高くなることがあります。これは、代替スポットインスタンスが起動後すぐに中断される可能性が高い場合も、必ず、その時点で利用可能な容量を持つ最低料金のプールでインスタンスを起動することが原因です。中断のリスクが高くなるのを避けるため、lowest-price 配分戦略を使用せず、代わりに price-capacity-optimized、capacity-optimized、capacity-optimized-prioritized 配分戦略を使用することを強くお勧めします。中断リスクを許容した上で lowest-price を選んでいましたが、ここまで頻繁に起動と終了を繰り返すのは想定外のため、まずは割り当て戦略を公式推奨の price-capacity-optimized に変えてみました。問題2: スポットインスタンスのキャパシティ不足今度は別の問題が発生しました。Auto Scaling Groupのアクティビティ履歴に Failed が連続して発生するようになったのです。大量の「failed」イベント（説明）Launching a new EC2 instance. Status Reason: Could not launch Spot Instances. UnfulfillableCapacity - Unable to fulfill capacity due to your request configuration. Please adjust your request and try again. Launching EC2 instance failed.（原因）At YYYY-MM-DDThh:mm:ssZ instances were launched to balance instances in zones ap-northeast-1a ap-northeast-1d with other zones resulting in more than desired number of instances in the group. At YYYY-MM-DDThh:mm:ssZ availability zones ap-northeast-1a ap-northeast-1d had 0 2 instances respectively. An instance was launched to aid in balancing the group's zones.スポットインスタンスの起動と終了を繰り返すのは収まりましたが、かわりにスポットインスタンスの起動ができなくなりました。ここでは以下のようなループが発生していました。ap-northeast-1dでスポットインスタンスを起動するap-northeast-1aに0台、ap-northeast-1dに2台、とAZが偏るAZのリバランス機能（AZRebalance）により、ap-northeast-1aに起動しようとするキャパシティ不足により起動失敗（3へ戻る）lowest-price では中断リスクが高いながらも起動できていたのに、 price-capacity-optimized では起動すらできなくなるのは不思議ですが、おそらくスポットリクエストの内部処理が異なるのでしょう。Auto Scaling Groupの設定見直しこの時点でのAuto Scaling Groupの設定は以下のとおりです。割り当て戦略は変更しましたが、インスタンスタイプは1種類のままです。安いインスタンスを使ってほしいためこのような設定にしていました。割り当て戦略（SpotAllocationStrategy）: price-capacity-optimizedインスタンスタイプ: t4g.mediumキャパシティ不足の対策としては、より多くのAZを使うこと、より多くのインスタンスタイプを使うことが有効とされています。repost.awsワークロードを設定する際には、リクエストするインスタンスタイプとデプロイするアベイラビリティーゾーンを柔軟に決定してください。 例えば、us-east-1a で m5.large をリクエストする代わりに、複数のアベイラビリティーゾーンで m4.large、c5.large、r5.large、または t3.xlarge をリクエストします。このタイプのリクエストにより、Amazon Web Services (AWS) が必要とする量のコンピューティングキャパシティを見つけて割り当てる可能性が高まります。具体的に、スポットプール数（AZ数 x インスタンスタイプ数）が20を超えるよう設定すべしという記事もあります。dev.classmethod.jpAWS ではスポットプール数について最低 20、可能なら 30 を⽬指すことをお勧めしてます。※スポットプール数 = インスタンスタイプの数 x AZ の数ap-northeast-1で利用可能なAZは3つなので、インスタンスタイプが1種類の場合のスポットプールの数は 3 x 1 = 3 です。さすがにこれでは少なすぎたため、起動テンプレートを上書きする形で、インスタンスタイプの選択肢を追加しました。t4g.mediumt4g.largec6g.largem6g.largeこのAuto Scaling GroupではArm64のAMIを使っているため、Gravitonベースかつなるべくt4g.mediumに近い性能のインスタンスタイプを選びました。世代を問わないAMIを使っていれば、前世代のインスタンスタイプも含めるとさらに安定すると思います。スポットプール数は 3 x 4 = 12 となり、20には満たないものの最初に比べると選択肢が大幅に増えました。設定変更後…t4g.mediumのキャパシティが確保しづらいap-northeast-1aでは、別のインスタンスタイプが起動するようになりました。ap-northeast-1aではt4g.largeが起動しているインスタンス数のメトリクスからも、高頻度の増減がなくなって安定していることが分かります。設定変更後はインスタンス数が安定したおわりに例えば「本番環境ではマルチAZで冗長構成、非本番環境では1台構成」というように、非本番環境ではベストプラクティスよりもコスト削減を優先することはよくあることかと思います。ですが、スポットインスタンスの利用においてはベストプラクティスに従わないと想定以上に安定性を欠くことが分かりました。同じ問題で悩む人の参考になれば幸いです。付録対応後のCloudFormationテンプレートを一部抜粋して掲載します。  AutoScalingAutoScalingGroup:    Type: 'AWS::AutoScaling::AutoScalingGroup'    Properties:      CapacityRebalance: true      MixedInstancesPolicy:        InstancesDistribution:          SpotAllocationStrategy: 'price-capacity-optimized'        LaunchTemplate:          LaunchTemplateSpecification:            LaunchTemplateId: !Ref EC2LaunchTemplate # 補足: AWS::EC2::LaunchTemplateのInstanceTypeでt4g.mediumを指定している            Version: !GetAtt EC2LaunchTemplate.LatestVersionNumber          Overrides:            - InstanceType: 't4g.medium'            - InstanceType: 't4g.large'            - InstanceType: 'c6g.large'            - InstanceType: 'm6g.large'

Auto Scaling Groupでスポットインスタンス費用を節約しようとしたけどうまくいかなかった話

はじめにこんにちは、インフラエンジニアのなみきです。これまでは所属企業でブログを書いていましたが、退職に伴い自分のブログを開設しました。改めてよろしくお願いします。さて、今日のお題はみんな大好きEC2 Auto Scalingです。EC2 Auto Scalingでできる自動スケーリングは、大きく分けて3種類あります。動的スケーリング負荷状況に合わせてスケールできるどのメトリクスを基準にするか？増減させるときは何台ずつ増やすか？などスケールの仕様を細かく設定できるスケジュールされたスケーリング（以下「スケジュール」と表記）予定した日時にインスタンス数を増減させる予測スケーリングリソースの使用率などの規則性から、適切なインスタンス数を予測するこれらのスケーリングを組み合わせて利用されている方は多いのではないでしょうか。今回は、「動的スケーリング」と「スケジュール」を組み合わせて利用する際のオススメ設定方法を紹介します。前提知識3種類のパラメータAuto Scaling Groupには、インスタンス数を制御するパラメータが3種類あります。Desired Capacity （希望容量）Minimum Size （最小サイズ）Maximum Size （最大サイズ）起動するインスタンス数は希望容量に依存します。動的スケーリングを利用している場合、希望容量は最小サイズと最大サイズの間で増減します。自動で最小サイズを下回ったり、最大サイズを上回ることはありません。1NOTE: この記事では、説明を分かりやすくするためインスタンスの重み付けには触れず、単純に「サイズ=インスタンス数」として扱います。ご承知おきください。Desired CapacityはMinimumとMaximumの間で増減する一方、スケジュールでは希望容量を指定できるのはもちろん、最小サイズと最大サイズも指定できます。スケジュールでMinimumとMaximumを変化させる例スケジュールの利用シーン多くの場合、Auto Scalingの動的スケーリングは数分間の負荷状況を見てからスケーリングを始めるため、急激な負荷上昇には対応しきれないことがあります。2動的スケーリングあるある: スケールアウトが間に合わないそこで、負荷の高まる時間が予測できる場合は、スケジュールを利用して待ち構えておくことで対応できます。負荷に備えあらかじめスケールアウトしておく前述の通り、スケジュールでは希望容量だけではなく最小サイズと最大サイズも指定できます。「希望容量を変えたいんだから、希望容量を指定すればいいんじゃないの？」と思われるかもしれません。動的スケーリングを使わずスケジュールのみでインスタンス数を増減させている場合は、その通りです。しかし、動的スケーリングとスケジュールを組み合わせて使う場合、思い通りのインスタンス数を維持するために スケジュールでは最小サイズを指定するのがオススメ です。どういうことか、詳しく見ていきましょう。よくある問題と回避策スケジュールで希望容量を増減させるとどのような問題が起こりうるか、そして最小サイズを指定することでどのように問題を回避できるかを紹介します。問題その1: 即座にスケールイン負荷が高まる時間が分かっている場合、時間に余裕を持たせたスケジュールにすることが多いと思います。すなわち、インスタンス数を増やしてから負荷が高まるまで少し時間があるということですが、この間にインスタンス数が減ってしまっては困ります。希望容量の問題スケジュールで希望容量を増やすと、負荷が高まる前に自動スケールインが発生し、狙ったインスタンス数が維持できないという問題が起こり得ます。例えば、12:00に負荷が高くなるシステムにおいて、11:30のスケジュールで希望容量を増やすとします。この30分間は負荷の低い状態が続くため、動的スケーリングによる自動スケールインが発生し、希望容量が減らされる可能性があります。そうなると肝心の12:00にインスタンス数が足りず、パフォーマンス悪化やエラーを起こしてしまいます。即座にスケールインするイメージNOTE: 動的スケーリングの自動スケールインを無効にして勝手に減らないようにする、というのも一つの回避策ですが、後述する問題その2を併せて回避するため自動スケールインは有効にしておく必要があります。最小サイズで解決では、希望容量のかわりに最小サイズを指定するとどうなるでしょうか。スケジュールを以下のように設定します。希望容量: 無指定最小サイズ: 維持したいインスタンス数希望容量を指定せずに最小サイズを指定すると、希望容量は必ず「最小サイズ以上」になります。それより減ることはないので、次のスケジュールで最小サイズを下げるまでインスタンス数が維持されます。最小サイズ指定でスケールインを回避する問題その2: 問答無用でスケールイン負荷に備えてインスタンス数を増やすのとセットで、負荷が落ち着く頃にインスタンス数を減らすのもよくある使い方です。しかし、負荷の高い状態が予想よりも長引いていたらどうなるでしょうか。希望容量の問題スケジュールで希望容量を指定すると、負荷状況によらず問答無用でインスタンス数を変更してしまいます。問答無用でスケールインするイメージ図最小サイズで解決では、希望容量のかわりに最小サイズを指定するとどうなるでしょうか。スケジュールを以下のように設定します。希望容量: 無指定最小サイズ: 平常時の最小インスタンス数希望容量を指定しないことにより、スケールインは動的スケーリングに任せることになります。負荷状況を見た上で「減らして大丈夫」と判断されて初めて減らされるため、適切なインスタンス数を維持できます。負荷に合わせてスケールインするまとめスケジュールで希望容量を指定するのは分かりやすいですが、動的スケーリングと組み合わせた場合、予期せぬ増減が発生することがあります。希望容量を狙った値にするため、ぜひ最小サイズの指定を取り入れてみてください。インスタンスの重み付けや予測スケーリングを利用している場合は例外的に最大サイズを上回ることがありますが、この記事では詳しく説明しません。↩↩

Amazon Auroraのカスタムエンドポイントをフェイルオーバーに追従させる

新しい会社で役に立ったスキルと補ったスキル

Auto Scaling Groupでスポットインスタンス費用を節約しようとしたけどうまくいかなかった話

EC2 Auto Scalingで動的スケーリングとスケジュールを組み合わせる