Day1～AWSで最初に行うべき設定信頼性編

Pocket

はじめに
(9)データのバックアップ
(10)障害や不具合への対策
おわりに

はじめに

こんにちは。この連載もいよいよ最終回(4回目)になります。

前回まで「Day1にAWSアカウントに最初に行うべき設定」のセキュリティカテゴリーと、コストカテゴリーについて紹介しました。未読の方はこちらから是非読んでみてください。

Day1～AWSで最初に行うべき設定　セキュリティ編 Part1

Day1～AWSで最初に行うべき設定　セキュリティ編 Part2

Day1～AWSで最初に行うべき設定　コスト編

最初に行うべき設定には、大きく分けて以下の3つのカテゴリーがあります。

セキュリティ
コスト最適化
信頼性

この記事では、信頼性を向上させるために行うべき設定について紹介します。

※この記事はあくまでもAWSから公開されている「Day 1 with Amazon Web Services　AWSご利用開始時に最低限おさえておきたい10のこと」を実現する方法の一例を紹介しています。この設定をしていれば必ず安全であると保証するものではありません。

(9)データのバックアップ

オンプレミスのサーバをバックアップする場合、バックアップサーバを立てたり、バックアップツールを導入したりといった手間や、どこにバックアップデータを保管するかという考慮が必要でした。

しかし、AWSのEC2ならサーバにエージェントなどを入れることなく簡単に、サーバのイメージを取得することができます。EC2のイメージを取得すると、AMI(Amazon Machine Image)というものが作られます。これは、サーバのソフトウェア構成、静的コンテンツ、動的コードなどが含まれるため、AMIから新しいサーバを起動することで、元のサーバと同じ内容を複製することができます。

ここでは、既存のEC2サーバのAMIを取得する手順を説明します。

EC2サーバを起動し、httpdをインストール。アクセス時に表示する簡易的なページを作成します。

簡易ページはこのように表示されました。

AWSマネジメントコンソールから、先ほどhttpdをインストールしたEC2インスタンスを選び、「アクション」＞「イメージ」＞「イメージの作成」を押下します。

イメージ名とイメージの説明を入力します。

「再起動しない」にチェックを入れると、EC2インスタンスの再起動を伴うことなく、イメージを作成することができます。インスタンスボリュームはEC2サーバを作成したときと同じボリュームでよいと思います。

設定値の入力後は「イメージの作成」ボタンを押下します。

正常に作成が開始されたら「閉じる」ボタンを押下します。

最初はステータスがpendingですが、しばらく待つとavailableに変わります。

実際にAMIからサーバを起動し、設定が保持されているか確認してみましょう。

「起動」ボタンを押下します。

インスタンスタイプの選択からは、普段EC2インスタンスを構築する際と同じ手順です。

インスタンスが作成されたら、簡易ページが表示されるか試してみます。

簡易ページが表示されました。ここから、AMIにはhttpdの設定や、作成したファイルが保持されていることがわかります。

(10)障害や不具合への対策

システムには必ず障害や不具合が発生します。障害によるダウンタイムを可能な限り抑えることを求められる場面も多いでしょう。

AWSでは、従来のオンプレミスのシステムで大きな手間や高額なコストが必要だったそれらの障害対策を少ない手間で必要な分だけ盛り込むことができます。様々な障害対策の方法があるため、規模やコスト、RPO(目標復旧時点)、RLO(目標復旧レベル)に応じてどの機能を使用するか検討するとよいでしょう。

ここでは、アクセス集中への対応や、インスタンスダウンの自動復旧に使用することができる、Auto Scalingの設定方法を説明します。

AWSマネジメントコンソール＞EC2＞ロードバランサーに遷移し、「ロードバランサーの作成」ボタンを押下します。

ロードバランサーには、主に2種類あり、以前の世代も選択することができます。(各ロードバランサーの違いについてはElastic Load Balancingをご参照下さい。)

ここでは、Application Load Balancerを使用します。「作成」ボタンを押下します。

ロードバランサーの名前、スキーム(インターネットからアクセスさせるのか、AWSの内部向けなのか)、IPアドレスタイプ(ipv4またはipv4とapv6のデュアルスタック)を入力します。

リスナーはロードバランサーにアクセスするためのプロトコルとポートを指定します。

アベイラビリティゾーンでは、ロードバランサーを作成するVPCを指定します。ロードバランサーは複数のAZにサブネットが存在するVPCに作る必要があります。

指定したら「次の手順：セキュリティ設定の構成」ボタンを押下します。

セキュリティ設定の構成画面は、HTTPSをリスナーに指定した場合に証明書などの設定を行います。

今回の例ではHTTPSを使用しないため、そのまま「次の手順：セキュリティグループの設定」ボタンを押下します。

ロードバランサーに適用するセキュリティグループを指定します。新しく作成しても、既存のリソースを選択しても構いませんが、インバウンドでHTTP(80ポート)へのアクセスを許可しているセキュリティグループである必要があります。

指定したら「次の手順：ルーティングの設定」ボタンを押下します。

ここではロードバランサーから背後のリソースへリクエストを送信する際の設定を行います。それらの設定をターゲットグループと呼びます。

ターゲットグループの名前を入力し、ターゲットの種類では今回はインスタンスを選択します。

次に背後のインスタンスがリクエストを受けるプロトコルとポートを入力します。

ヘルスチェックではどのパスに対して通信が行える場合に正常であると判断するかを設定します。今回は簡易ページをヘルスチェックにも使います。ヘルスチェックの詳細設定では、ヘルスチェックをどのような頻度で行うかなどを設定できます。

入力が完了したら、「次の手順：ターゲットの登録」ボタンを押下します。

ここでは、ロードバランサーのターゲットになるインスタンスを指定することができます。今回は、Auto Scalingによって自動登録するので、この画面では特にインスタンスを指定しません。

このまま「次の手順：確認」ボタンを押下します。

内容に問題がなければ「作成」ボタンを押下します。

問題なく作成が開始したら、「閉じる」ボタンを押下します。

次に、Auto Scalingの設定を行います。

EC2＞Auto Scalingグループに遷移し、「Auto Scalingグループの作成」ボタンを押下します。

設定の手順の説明画面が表示された場合は、「今すぐ始める」ボタンを押下します。

Auto Scalingで起動するサーバの元になるAMIを指定します。

ここでは、前述の手順で作成したAMIを使用します。「選択」ボタンを押下してください。

Auto Scalingにて起動する際のインスタンスタイプを指定します。

インスタンスタイプにチェックを入れたら、「次の手順：詳細設定」ボタンを押下します。

起動設定を作成します。

起動設定の名前を入力します。購入のオプション(新しく起動するインスタンスをスポットインスタンスにすることができます)やIAMロールなど必要な設定があれば指定します。

入力したら「次の手順：ストレージの追加」を押下します。

Auto Scalingにて起動する際のストレージの容量やタイプを指定します。指定したら「次の手順：セキュリティグループの設定」ボタンを押下します。

Auto Scalingにて起動する際のセキュリティグループを指定します。指定したら「確認」ボタンを押下します。

設定内容に問題がなければ「起動設定の作成」ボタンを押下します。

そのまま次の画面でAuto Scalingグループを作成します。

グループ名を入力します。起動設定には直前に作成したものが指定されていると思います。

グループサイズは、このグループで起動する最初のインスタンス数を指定します。

ネットワーク、サブネットはロードバランサーの作成時に指定したものと同じものを指定してください。

高度な詳細セクションを開きます。ここで設定することで、ロードバランサーにAuto Scalingで起動したインスタンスを自動的に登録することができます。

ロードバランシングにチェックを入れ、先ほど作ったターゲットグループを指定します。ヘルスチェックのタイプはEC2にします。入力したら「次の手順：スケーリングポリシーの設定」ボタンを押下します。

Auto Scalingグループの作成では、グループのサイズを初期のサイズに維持する(障害が発生してEC2インスタンスの台数が減ってしまった場合に、初期のサイズまでサーバを起動する)か、グループのキャパシティを調整する(EC2インスタンスのスペックが不足した場合に必要な分だけインスタンスを増やす)かを選択できます。

今回はこのグループを初期のサイズに維持するにチェックを入れ、「次の手順：通知の設定」ボタンを押下します。