フォーム読み込み中
こんにちは。ソフトバンク株式会社の王文礼です。
今回は後編記事です。
前編では、サンプルアプリの準備からはじめて、デモ①とデモ②を通じて単一インスタンス環境に Web アプリをデプロイする方法と、アプリのアップデートについて解説しました。今回の後編では、Blue-Green デプロイメント、ワーカー環境の作成および高可用性環境の作成について解説します。
準備
後編では、前編のデモ①とデモ②で作成したアプリと環境を使用します。前編はまだご覧になっていない方は、まず前編をご覧ください。
デモ②では、最終的に「Production 環境」で「myapp-blue」が実行されていますが、デモ③のために、「Production 環境」で「myapp-green」を実行するようにやり直します。
1. 「アプリケーションバージョン」>「myapp-green」を選択した状態で、「アクション」>「デプロイ」の順にクリックします。
2. 環境は「Production」を選択して、「デプロイ」をクリックします。
3. デプロイが完了すると、「myapp-blue」は「Development 環境」に、「myapp-green」は「Production 環境」にデプロイされた状態となります。
これで、準備が完了しました。
デモ③：Blue-Green デプロイメント
アプリのバージョンをアップデートする際、AWS Elastic Beanstalk は in-place アップデートを実行するため、一時的にユーザがアプリを利用できなくなる可能性があります。
Blue-Green デプロイメントを使えば、二つの環境の CNAME を交換して、トラフィックを新バージョンに直ちにリダイレクトできるため、アクセスへの影響が最小限に抑えられます。
また、環境を互換性のないプラットフォームバージョンにアップデートする際、Blue-Green デプロイメントの使用が必要となります。
デモ③で実施する内容としては、もともと「Production 環境」にバージョン「myapp-green」はデプロイされていて、「Development 環境」にバージョン「myapp-blue」はデプロイされていますが、「Production 環境」と「Development 環境」の URL をスワップすることで、「Production 環境」にバージョン「myapp-blue」を反映することで、アプリのアップデートを行います。
環境 URL をスワップ
1.「MyApp」>「Prodution」>「アクション」>「環境 URL のスワップ」の順にクリックします。
2. 環境名を「Development」を選択し、「スワップ」をクリックします。
3. しばらくすると、URL のスワップが完了します。「Production 環境」の URL が「Development 環境」の URL に変わったことが分かります。
注）再度 URL をスワップすると、「Production 環境」の URL を元の URL に戻すことができます。
4.「Production 環境」の URL をクリックすると、もともと緑色背景の Web ページが青色背景の Web ページに変わりました。アップデートが成功しました。
5. スワップなので、「Development 環境」の URL をクリックすると、緑色背景の Web ページが表示されます。
Development 環境の削除
6.「Development 環境」はもう使わないので、削除します。「環境」ページで「Development」を選択した状態で、「アクション」>「環境の終了」をクリックします。環境を終了すると、関連付けられたリソースも削除されます。
バージョンラベルの削除
7.「アプリケーションバージョン」ページから、バージョンラベル「myapp-bule」を削除します。常に不要なリソースの削除を心掛けましょう。
注）環境を削除する際、バージョンラベルは削除されないため、手動で削除する必要があります。
デモ④：ワーカー環境の作成
AWS Elastic Beanstalk には、2 種類の環境枠があります。
- ウェブサーバ環境
- ワーカー環境
ウェブサーバ環境は、今までのデモで使われているもので、通常、ポート 80 を介し、 HTTP リクエストをリッスンして処理を行います。
注）デフォルトでは、Elastic Beanstalk は誰もがポート 80 (HTTP) を経由してアクセスできるセキュリティグループを定義します。セキュリティグループとは、AWS ネットワーク上で通信を制御するファイアウォール機能です。一つのインスタンスに複数のセキュリティグループを割り当てることができます。
ワーカー環境は、Amazon SQS キュー上のメッセージをリッスンするバックグラウンド処理タスクに使用されます。時間がかかる操作（画像やビデオの処理、電子メールの送信）を実行する場合、それらをワーカー環境にオフロードし、 Web アプリのフロントエンドを分離することで、負荷がかかってもアプリの応答性を維持できます。
注）Elastic Beanstalk は、常にワーカーキューメッセージをポート 80 に送信します。ワーカー環境アプリまたはそのプロキシは、ポート 80 をリッスンする必要があります。
デモ④では、改めて「MyApp」にワーカー環境を追加します。
ワーカー環境の作成
1. 「アプリケーション」ページで、「MyApp」>「新しい環境の作成」>「ワーカー環境」>「選択」の順にクリックします。
2. 環境名を「Worker」、プラットフォームを「Node.js」に設定します。プラットフォームのブランチ、プラットフォームのバージョンはデフォルトのままにします。「アプリケーションコード」のところで、「サンプルアプリケーション」を選択して、「環境の作成」をクリックします。
3. ワーカー環境の作成が開始され、約 5 分後にワーカー環境の作成が完了します。各サービスのコンソールを確認すると、以下のリソースが生成されたことが分かります。
- SQS
- EC2 インスタンス
- EBS ボリューム
- セキュリティグループ
- Auto Scaling グループ
- CloudFormation スタック
4. 「キューの表示」をクリックすると、Amazon SQS に遷移します。
5. Amazon SQS で二つのキューが作成されました。一つは通常のメッセージを処理するためのキューで、もう一つの「DeadLetter」というキューは、メッセージが正しく処理されなかった場合、原因分析用のキューとなります。
6. ワーカーの確認および編集は、「Worker 環境」の「設定」ページより行うことができます。
注）今回使ったデモアプリは、ワーカー環境を動作させることができないため、ワーカー環境の動きを見せることができなくて、簡単な紹介となります。
Worker 環境／Production 環境の削除
7.「Worker 環境」も使わないので、削除します。環境ページで「Worker」を選択して、「アクション」>「環境の終了」の順にクリックします。
8. 上記と同じ手順で「Production 環境」を削除します。
バージョンラベルの削除
9.「アプリケーションバージョン」ページから、バージョンラベル「Sample Application」と「myapp-green」を選択して削除します。
デモ⑤：高可用性環境の作成
高可用性環境では、Elastic Load Balancing と EC2 Auto Scaling を使用して、デプロイされたアプリケーションに必要な EC2 インスタンスをプロビジョニングします。EC2 Auto Scaling は、アプリケーションへの負荷の増減に応じてインスタンスを追加したり、減らしたりします。
高可用性環境は、本番運用やミッションクリティカルシステムに適します。
デモ⑤では、「MyApp」アプリに高可用性環境「HA-env」を作成して、コード「MyApp-version-green.zip」を「HA-env 環境」にデプロイします。
高可用性環境の作成
1. 「MyApp」>「新しい環境の作成」の順にクリックします。
2. 環境名に「HA-env」、バージョンラベルに「myapp-green」を記入します。プラットフォームを「Node.js」を選択し、コード「MyApp-version-green.zip」をアップロードしてから「より多くのオプションの設定」をクリックします。
3. プリセットされている「高可用性」を選択します。
4. 容量の「編集」ボタンをクリックします。最小インスタンス数を 2 に設定して、他の項目はデフォルトのままで「保存」をクリックします。
5. ロードバランサーの「編集」ボタンをクリックします。「Application Load Balancer」が選択されていることを確認します。
6. モニタリングの「編集」ボタンをクリックします。システムのところで「拡張」を選択し、「ログのストリーミング」を有効にして、ライフサイクルのところで「終了時にログを削除する」に設定して、保存をクリックします。
7. 他にもいろいろな設定ができますが、本デモは上記の設定ができたら「環境の作成」をクリックします。
設定可能なカテゴリとオプションの一部を表にまとめました。ご参照ください。
カテゴリ | オプション |
|---|---|
ソフトウェア |
|
インスタンス |
注）デフォルトでは IMDSv1 と IMDSv2 両方が有効化されています。ただし、IMDSv2 の方が安全性に優れているため、Elastic Beanstalk のセキュリティベストプラクティスとしては、インスタンスに IMDSv2 を適用することが推奨されています。アプリの全てのコンポーネントが IMDSv2 をサポートしていることを確認してから、IMDSv1 を無効にすることで、 IMDSv2 のみが適用されます。
|
容量 |
|
ロードバランサー |
|
ローリング更新とデプロイ |
|
モニタリング |
|
マネージド更新 |
注）Elastic Beanstalk は、プラットフォームバージョンが定期的に更新されます。更新には、重要なセキュリティ修正が含まれているため、Elastic Beanstalk のセキュリティベストプラクティスとしては、プラットフォームを最新バージョンに維持すべきです。プラットフォームの更新に最も簡単な方法としては、マネージドプラットフォーム更新を使用するように環境を設定します。
|
通知 |
|
データベース |
|
8. 約 5 分後、環境の作成が完了します。以下のリソースが作成されました。
- 二つの EC2 インスタンス（Elastic IP なし）
- セキュリティグループ
- Auto Scaling グループ（インスタンスの最小数：2、最大数：4、希望容量：2）
- EBS ボリューム
- S3 バケット
- CloudFormation スタック
- Application Load Balancer
- CloudWatch ロググループ
9. アプリを開き、アプリを動かしながら、 EC2 コンソールにアクセスしてEC2 の稼働状況を確認してみます。高可用性環境で稼働中の二つのインスタンスを全部選択したら、モニタリングの結果が表示されます。CPU 使用率、ネットワーク受信量／送信量、CPU クレジットなどの情報を一覧できます。
10. 稼働中の二つの EC2 インスタンスのうち、一つを中止して高可用性環境の動きを確認してみます。下記一連の動きが見られます。
- EC2 を停止すると、Elastic beanstalk のヘルスチェックにアラートが出ました。
- アプリが問題なく稼働し続けます。
- EC2 停止後、自動的にシャットダウン（終了）されます。
- 新しいインスタンスがローンチされます。
- Elastic beanstalk のヘルスチェックが正常状態に戻りました。
11. Elastic beanstalk コンソールで、環境のモニタリングを確認してみます。ヘルスホストの数、レスポンス時間、リクエスト数、CPU 使用率、最大ネットワーク受信／送信などの情報を一覧できます。
12. CloudWatch で Elastic Beastalk に関するアラーム、ロググループなどの情報を確認できます。
クリーンアップ
1.「アプリケーション」ページで、「MyApp」を選択した状態で、「アクション」>「アプリケーションの削除」の順にクリックします。
2. アプリ削除完了後、念のため、各リソースが削除されたかどうかを確認しましょう。
注）リソースがうまく削除できない場合、AWSEBSecurityGroup の削除に失敗したときに、AWS Elastic Beanstalk 環境を終了または再構築する方法を教えてください をご参照ください。
所感
デモを通じて、AWS Elastic Beanstalk におけるアプリケーション、アプリケーションバージョン、環境、環境枠、環境設定、プラットフォームなどの概念およびお互いの関係について、理解していただけると思います。
コードさえ用意できたら、数分以内にアプリが使用できるようになることを実感して、AWS にアプリをデプロイするなら、AWS Elastic Beanstalk を利用するのは一番速くて簡単ではないかと思います。何よりも、インフラに関する専門知識の習得やプラットフォーム更新などの面倒な作業をしなくていいので、効率よく開発できることです。
関連サービス
Amazon Web Services (AWS)
ソフトバンクはAWS アドバンストティアサービスパートナーです
「はじめてのAWS導入」から大規模なサービス基盤や基幹システムの構築まで、お客さまのご要望にあわせて最適なAWS環境の導入を支援します。
＼ 業務課題をデジタルで支援 ／
デジタルツールの選定から導入の手引きまで、中小規模のお客さまへわかりやすくお伝えします。
メールマガジン登録（無料）
ビジネスに役立つ記事やウェビナー情報をお届けします。
おすすめの記事
条件に該当するページがございません
