こんにちは。クレスコDTのKHといとーです。
IT業界に飛び込んでから、あっという間に2年が経ちました。
まだまだ新しい発見や学びの連続で、目まぐるしい毎日です。
今回はこれまでの自身の経験を通じて、率直に“すごい！”と感じたAWSの魅力と「EC2のコールドスタンバイ構成」について紹介したいと思います。

■あわせて読まれている資料：
クラウドのコンサルティングから導入までをワンストップで支援！
→クラウドテクノロジーサービス​​​​​​​

AWSの魅力：圧倒的なサービスの多さ！

クラウドサービスと言えば、世界でトップシェア率を誇るAWSが有名ですよね。
AWSは現在、様々なニーズに対応するために200を超えるサービスを提供しています。初めてAWSに触れたとき、そのサービスの多さに驚いたのを覚えています。

種類が多すぎてサービスの名前を覚えるだけでも精一杯…かもしれませんが、各サービスを上手に組み合わせることで様々な課題を解決できます。

本記事では、「EC2のコールドスタンバイ構成」に焦点を当て、導入事例をもとに6つのサービスを組み合わせた運用方法について紹介します。

そもそもコールドスタンバイって何？

タイトルに”コールドスタンバイ実装”と掲げましたが、そもそもコールドスタンバイってどんな構成？というところから追っていきたいと思います。
 
クラウド環境に限らず、システムを構築する上で可用性を考えることはとても重要です。
稼働中のシステムに障害が起きても、継続してサービスが利用できるようにスタンバイ機を用意しておくことは一般的ですよね。
 
スタンバイ機をどのような状態にしておくのかは要件によって様々ですが、ベースとして「コールドスタンバイ」、「ウォームスタンバイ」という考え方があります。
 
・コールドスタンバイ
スタンバイ機を常時停止状態にしておく構成です。
アクティブ機のシステムがダウンした場合に、スタンバイ機を起動することでサービスを継続できます。
コストは抑えられますが、停止状態から起動をするため復旧までに多少時間がかかります。
 
・ウォームスタンバイ
スタンバイ機を常時起動状態にしておく構成です。
アクティブ機と同じ設定を常に保持できるので、障害発生時にすぐに切り替えることができます。
ダウンタイムを最小限に抑えられますが、常に稼働しているためコストがかかります。
 
どちらを選択するかは、システムの用途や種類、顧客要件によって異なります。
メリット・デメリットのバランスをよく考え、検討する必要があります。

【導入事例の紹介】EC2のコールドスタンバイ構成

前置きが長くなりましたが、導入事例の紹介です。
AWSの強みである多様なサービスを活かして、ウェブアプリケーションのコールドスタンバイ構成を実装した事例を紹介します。
 
利用するサービスは以下の6種です。

これらのサービスを連携させることで、コールドスタンバイ、また障害時の自動フェールオーバーを実現できます。

■実装環境
構成を実装する環境は以下の通りです。
 
前提として、単一障害点の無い構成とするため、2つのAZ（アベイラビリティゾーン）をまたいだ冗長構成としています。複数のAZを使用する構成は、「マルチAZ構成」と呼ばれ、クラウド上でシステムの可用性を高めるためのベストプラクティスの一つです。
 
※AZとはAWSにおいてデータセンターのことを指します。各AZは物理的に少し離れた場所に設置されており、マルチAZにすることで障害が発生した際にもシステムの可用性を高めることができます。
 
【実装環境構成図】

＜補足＞
・EC2 1号機と2号機は同構成
・ALBを用いてEC2に対してヘルスチェック（死活監視）を実施
・EC2の２号機は常時停止しているコールドスタンバイ構成
・顧客要件に伴い、ALBには常時サーバ1台のみを紐付けておく
・障害時には2号機の起動を行い、ALBの接続先を切り替えることで継続性を高める
・仮想サーバ2台の共用データ配置場所として、FSx（Master/Slave構成）を利用
 
この環境をベースに、必要なリソースを追加で設定していきます。
 
■実装手順
（1）CloudWatchのアラームの設定
CloudWatch は、AWSで作成したリソース（EC2やRDSなど）を監視するサービスです。エージェントを利用することでオンプレミスのサーバ監視も可能です。
 
CloudWatch の中には、ログ収集、監視アラーム、特定のイベントをトリガーにしてアクションを自動化する等、様々な機能があります。
 
今回は、監視アラームの機能を利用します。
 
以下図のように、ALBのEC2に対するヘルスチェック結果を監視するアラームを作成します。
ヘルスチェックが正常でない場合に、アラーム状態になるように設定します。

（2）CloudWatchアラームアクションの設定
CloudWatchアラームのアクション機能を利用して、SNSトピックにアラーム通知が送信されるように設定します。
 
SNSは、アプリケーション間のメッセージ配信サービスです。特定のアクションごとにスマホへのプッシュ通知、Eメール送信、Lambdaの実行等が可能です。SNSトピックは通信チャネルとして機能する論理アクセスポイントとなります。

以下図のように、CloudWatch での監視結果がアラーム状態だった場合の通知をSNSトピックに送信するようしています。

（3）SNS、Lambdaトリガー設定
SNSトピックのサブスクリプション（メッセージ配信先）にはLambdaを指定して、SNSからLambdaが実行されるように設定します。
 
Lambda側からも、実行トリガーの設定にSNSトピックを選択することで同様の設定が行えます。

​​​​​​​（4）Lambdaスクリプトの準備
Lambda はサーバのことを意識せずにコードを実行できるようにするサービスです。
 
サポートされている言語でLambda関数を記述することで、AWSのAPIを呼び出してリソースを操作したり、リソース情報を取得したりすることが可能です。
 
スクリプトには、以下の内容を記述します。（Lambda関数の詳細は割愛します）
・EC2 1号機の停止
・EC2 2号機の起動
・ALBからEC2 1号機を切り離す
・ALBにEC2 2号機の紐付ける
 
必要な設定は以上です。では、障害時の動きを見てみましょう。
 
■障害時の一連の流れ

①ALBがEC2に対してヘルチェック（死活監視）を実施
　そのヘルチェック結果をCloudWatchが監視する
②ヘルスチェックの結果に異常があれば、CloudWatchアラームからSNSへ通知
③SNSからLambdaを実行
④Lambdaスクリプトが実行され、1号機から2号機へ切り替えを実施
 
以上の流れで、コールドスタンバイと自動フェールオーバー構成を実装することができます。

サービスに必要な権限について

流れの説明では触れませんでしたが、実装していく上で重要になるのが権限管理です。
やりたいことができない！動かない！というエラーに遭遇した際は、アクセス許可が不足している場合が多いです。（個人の感想）
 
AWSではIAMというサービスを使用し、各ユーザーやサービスの権限を管理します。
ユーザーがAWSコンソールを使用してリソースを操作する際には、そのユーザーに対して適切な操作権限が付与されていれば問題ありません。
 
しかし本事例のように、LambdaからEC2の起動や停止を実施する場合は、Lambdaというサービス自体に操作権限が必要となる点に注意が必要です。
 
本事例では、Lambdaに以下の権限を付与する必要があります。
・EC2の起動、停止権限
・ALBのターゲット操作権限
 
上記のように、「誰が」「どのサービスに対して」「何をしたいのか」を意識する必要があります。
AWSの公式ドキュメントには最低限必要な権限が記載されていますが、実行環境によって追加の権限が必要になる可能性もあるので、予め動作検証をしておくのがお勧めです！
 
エラーログを確認すると、何の権限が不足しているのか記載されている場合もありますので、ヒントにすると良いと思います。

まとめ

いかがでしたか？このようにAWSの各サービスを上手に組み合わせて、ニーズに応じた最適な運用が可能です。サービスだけでなく、コストの管理方法や利用体系の選択肢も豊富になっています。

コンソールからポチポチとクリックするだけで、この構成が完成することに私は感動しました…
サービス同士が連携して動いているのが目に見えるとおもしろかったです。
要件により都度検証が必要となりますが、組み合わせ次第で可能性は無限大ですよね。

最適なコストとサービスの高可用性を両立するアーキテクチャを設計するためには、各サービスの性能や特性を理解し、最新のベストプラクティスや推奨されている組み合わせを利用することが大切です。

近年重要視されているセキュリティ観点も含めて、適切に設計や運用することが重要であり、多くの知識と経験が求められています。

AWS公式サイトや各種ドキュメントでも学ぶことができるため、ぜひ活用してみてください。
このブログが少しでも皆様の参考資料としてお役に立てば幸いです。
最後までお読みいただきありがとうございました。

■サービス資料一覧はこちら↓

引用元

【2024年】AWS全サービスまとめ
https://dev.classmethod.jp/articles/aws-summary-2024/