Elastic Beanstalk環境のT3インスタンス変更を実施してみた

AWS Elastic Beanstalkのインスタンスタイプ、費用対効果に優れたNITRO世代のT3インスタンスに変更してみました。
2018.11.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWSチームのすずきです。

AWS Elastic Beanstalk、2018年9月にリリースされたプラットフォーム3.0.4より、費用対効果に優れたNITRO世代のT3インスタンスを利用可能になりました。

「M3」世代のEC2インスタンスを利用していた古いElastic Beanstalk環境、サービス影響を最小化させつつ「T3」インスタンスに切り替える機会がありましたので、 紹介させて頂きます。

AWS Elastic Beanstalk が T3 インスタンスと Go 1.11 のサポートを追加

T3インスタンスの性能をWordPress環境で確認してみた

概要

今回メンテナンスを実施した環境は、プラットフォーム1.x。カスタムAMIは利用せず、Amazon Linux AMI release 2014.09 のAMIで起動した環境でした。

無停止での切替実現と、万一不具合が発生した場合の切り戻しを可能とするため、 Elastic Beanstalk のクローン機能を利用して、更新用の新環境(ELB+EC2)を用意。 インスタンスタイプ変更後、DNSスイッチによる入替を実施しました。

手順

クローン

  • 複製元となるEB環境の「アクション」よりクローンを作成します。

  • 最新プラットフォームへの更新(1.x→3.0.5)も、クローン作成と同時に実施しました。

  • 今回のクローン環境、約10分程度で起動しました。

設定変更

  • 新環境の起動完了後、Elastic Beanstalk環境の設定変更を行います。

  • Elastic Beanstalk プラットフォームを1.x→3.xへのアップデートと合わせ、拡張ヘルスモニタリングとログのストリーミングも有効化しました。

[Elastic Beanstalk] 拡張ヘルスモニタリングを試してみた

Elastic BeanstalkのCloudWatch Logs のストリーミングを試してみた

インスタンス

  • インスタンスタイプを「t3.medium」に変更、AMIはデフォルトのもの利用しました。

  • Elastic Beanstalk プラットフォーム3.0.4以降に更新により、T3の選択が可能となります。

  • 複数の設定を同時に反映させるため「続行」を指定します。

ソフトウェア

  • CloudWatch Logs へのインスタンスログのストリーミング を有効とします。

モニタリング

  • ヘルスレポートを「ベーシック」→「拡張」に変更し、拡張ヘルスレポートを有効にします。
  • EC2インスタンス性能測定のため、インスタンスの一部カスタムメトリクスを有効としました
  • 環境のヘルスイベント変化を追跡可能とするため、CloudWatch Logs出力を有効にします。

変更の確認
  • 2018年8月のアップデートで利用可能になったレビュー機能を利用し、設定変更内容を確認します。

  • [AWS Elastic Beanstalk で設定変更のレビューが可能に] (https://aws.amazon.com/jp/about-aws/whats-new/2018/08/aws-elastic-beanstalk-adds-the-ability-to-review-configuration-changes/)

  • インスタンスの入替が発生する内容については再確認が求められます。

  • 今回はサービスに利用されないクローン環境であるので、そのまま継続します。

確認

  • 今回の環境では5分程度で、ステータスRed(重大) が解消し、Green(Ok)となりました。

イベント情報

ヘルス

Elastic Beanstalk ダッシュボードの「ヘルス」を開き、EC2の状態を確認します。

ストリーミングログ出力

  • インスタンスログのストリーミングにより出力されたログは、Cloudwatchダッシュボード「ログ」から、ロググループ「/aws/elasticbeanstalk/<EB環境名>」に出力されている事を確認します。

  • 「eb-activity.log」は、Elastic Beanstalk の初期化やデプロイ処理で発生したエラーが記録されます。特に.ebextention を多用した環境では注意してご確認ください。

カスタムメトリクス

  • 拡張モニタリング設定で、インスタンスのカスタムメトリクスを有効としていたので、カスタムメトリックの出力を確認しました。

切替

  • アプリケーションの動作テスト、冗長化設定などが完了した後、DNS切替による公開環境の入替を実施します。

  • 入替を実施するElastic Beanstalkの環境名を指定し、「スワップ」を行う事でDNS切替が実施されます。

  • 切替後、新環境の正常稼働が確認され、切り戻し不要となった段階で旧環境の撤去(環境の終了)を実施します。
  • デプロイスクリプトが旧環境に依存、Cloudwatchなどの監視メトリクスの継続が望ましい場合、旧環境のメンテナンス後、切り戻しとクローン環境を終了させます。

まとめ

Elastic Beanstalk プラットフォームの更新、「T3」など費用対効果に優れた新しいインスタンス対応だけでなく、 OS、ミドルウェアの脆弱性対応や、AMIが最新パッチの適用済みのものとなる事で、 オートスケールで起動したEC2の初期化時間の短縮などの効果も期待できます。

Elastic Beanstalk のクローン機能と、DNS切替(スワップ)を利用する事で、 アプリケーションがOS、ミドルウェアの特定バージョンに依存する場合でも事前評価や、 サービス影響を抑えたメンテナンスを行う事が可能です。

Elastic Beanstalk、AWSによりOS、ミドルウェアなどがメンテナンスされた プラットフォームが不定期(数ヶ月ごと)にリリースされています。

Elastic Beanstalk、最新プラットフォームへの自動更新を実現するマネージドプラットフォーム更新機能もリリースされています。 開発、テスト用のElastic Beanstalk環境が存在する場合、合わせてご活用ください。