概要
自分は普段Webやアプリのバックエンドエンジニアとして従事しており、ここ1年はずっとアプリのバックエンドとして、開発、保守を担当している。
インフラは当然のようにAWSが使われているが、構築と保守自体はアウトソーシングされているため、設定変更などは依頼ベースとなっている。
そんな事で知見はある程度貯まっていくが、自分で触らない以上最低限のレベルには到達出来ないという想いから本を買って実際に手を動かす事にした。
まず、以下の本が評判良かったのでAmazonで即購入。
Amazon Web Services 定番業務システム12パターン設計ガイド
本に書いてある事はなるべく書かないで、それ以外にやった事や、本当にど素人だとつまづきそうなところ、自分もハマったところを中心に書いていこうと思う。
過去記事
「Amazon Web Services 定番業務システム12パターン設計ガイド」を読みながら実際に構築する① 〜VPCとサブネットとEC2とセキュリティーグループ〜
「Amazon Web Services 定番業務システム12パターン設計ガイド」を読みながら実際に構築する② 〜Route53〜
「Amazon Web Services 定番業務システム12パターン設計ガイド」を読みながら実際に構築する③ 〜ssh公開鍵認証〜
1-2 [パターン2]コーポレートサイト - P26
1-1のシンプルなものよりやや複雑なWebサイトの例としてコーポレートサイトを構築するパターンの紹介。
概要は本書を参考にして頂き、インフラデザインのポイントはWebサーバ、DBサーバの助長化である。
概要図(以下図2参照)見て一般的なWebサイトの基本となるお手本的な構成かな、と思った。実際今自分が開発と保守を担当しているインフラもかなり似ている。Webサイトはあるが内部用の管理画面なのであまり凝っておらず、管理画面にはCloudFront(CDN)は使っていないが、アプリ用のコンテンツには使用している。DBの助長化もアベイラビリティーゾーン(AZ)を跨って配置しており、最近はユーザが増えてきて負荷が高まってきている事もあり、集中が予想される時間に合わせてAuroraの読み込みエンドポイントの機能(2016年10月リリース)を使って、リードレプリカを１つ追加して負荷を分散させるような事もしている。
※VPCとインターネットの接続にルーター、DNSにRoute53、EC2インスタンスのストレージにEBSを利用しているが図では省略している
ELBを利用してWebサーバーを助長化する
- 本題に入る前にEC2に事前準備をする。今回EC2は2台以上用意する必要があるが、振り分けを確認できれば良いので2台とする。まずEC2を作成するには新規で1個ずつ作成するかAMIから作成するかの方法があるが、頻繁に破棄したり作成&セットアップは面倒臭いので、1-1で作成したEC2を選択→アクション→イメージの作成でAMIを作ってしまえば、インスタンスの作成ステップ１で「マイAMI」というタブより、作成したAMIから新規のEC2が作成出来るため便利だ。
-
AMIからEC2を新規作成した場合、すでにsshdやApacheが動いているはずだ。まずはApacheの公開ルートディレクトリである /var/www/html に healthcheck というファイルを作成し、中身をそれぞれ
1つ目のEC2
ok - 1
2つ目のEC2
ok - 2
という風に内容をそれぞれ変える。
EC2の準備が出来たところでELBを作成する。ALB(Application Load Balancer)、NLB(Netword Load Balancer）、CLB(Classic Load Balancer)の3つがあるが、新規の構築であればALBで問題ないと思う。NLBは高トラフィック用で、CLBは既存のEC2-Classicネットワークを使用するための場合のものだ。
オフィシャルの説明はこちら→ALB/NLB/CLB比較表
ステップ１：ロードバランサーの設定
注意点としては、「アベイラビリティーゾーン」の説明にあるように、 ２つ以上のアベイラビリティーゾーンからサブネットを指定する必要があります。 というところ。1-1では1つのVPC内に1つのサブネットを作成したが、今回はさらに異なるアベイラビリティーゾーンにサブネットを作成したものを指定し、合わせて2つ以上のサブネットを指定する必要がある。
ステップ２：セキュリティ設定の構成
HTTPSを使用するために証明書を指定する必要があるが、これは無料のACM(AWS Certificate Manager)で証明書を取得する方法が最も簡単だ。
下図の ACM から新しい証明書をリクエスト より別フローへ進む
証明書のリクエスト（ドメイン名の追加）
お名前.com 等で取得したドメインを入力して「次へ」
証明書のリクエスト(検証方法を選択する)
こちらは「Eメールの検証」の方が楽だと思う。選択して「確認」
証明書のリクエスト(検証)
以下のEメールアドレスのどれかでメールが受信出来るはずなのでメールボックスを見てみる。（自分は赤線で消した箇所のメールアドレスだった）
証明書の確認(メールの確認)
下記のようなメールが来てるので、メール内の Amazon Certificate Approvals クリック
I Approve
ステップ2：セキュリティ設定の構成
証明書の名前 に、追加した証明書が表示されるようになりました。
ステップ3:セキュリティグループの設定
ここは本の通りHTTPとHTTPSを受けられる設定を作成するか既存のものを選択
ステップ4:ルーティングの設定
ここの「ヘルスチェック／パス」の項目に /healthcheck と入れます。さき程各EC2の中に配置したファイル名です。これはロードバランサーがターゲット内にある各EC2に対して 「/healthcheck にGETでアクセスするからHTTP200が返却されるようにしておいてね」という約束毎だ。デフォルトではチェク間隔が30(秒)、正常の閾値が5、非正常のしきい値が2となっているため、ロードバランサ作成後、約150秒後にロードバランサに2台のEC2がターゲットとして登録される事になる。逆に /healthcheck がHTTP200以外を返却するようになると約60秒後にはロードバランサのターゲットから解除されるため、EC2へのアクセス不可となる。
ステップ5:ターゲットの登録
登録済みのEC2をチェックして「登録済みに追加」ボタン押して、追加されたEC2を選択するだけ
以上の設定でロードバランサーを作成し、作成されたロードバランサーを選択すると下部に「DNS名」と書かれた値があると思うので、これを1-1でやったように Route53 のCNAMEのValueに登録するだけ
振り分けが行われたかどうか、ブラウザから {ドメイン}/healthcheck にアクセスしてみる。すると、アクセスするたびに以下のようにランダムでどちらかのEC2に振り分けられている事がわかる。
1つめのEC2
2つ目のEC2
今回はここまで。次回はRDSの助長化など。
「Amazon Web Services 定番業務システム12パターン設計ガイド」を読みながら実際に構築する⑤ 〜RDS、S3、CloudFront〜