0.はじめに

0.1.筆者について

元々ITエンジニアとしてキャリアを積んできましたが、ここ数年は構築やプログラミングをせず、現在はとあるBtoBtoCサイトのディレクションをしています。具体的には、ビジネスサイドと討議を重ね、要件をまとめ、何よりもビジネスをグロースするための開発施策を最優先に推進している立場です。

しかし、エンハンスを重ねるごとに、アーキテクチャが徐々に歪んでいくのを目の当たりにしており、それが僕としてはジレンマに感じられてしまいます。施策と並行してリファクタリングを進めたいのですが、そのような作業はビジネス視点で重要視されないためなかなか工数が取れません。

そんなある日、社内のSREから「AWSを広めていきたい」という話を持ちかけられました。もちろん興味はありましたが、最初は上述の経緯もあって、「本当に実現できるのかな」と不安でした。しかし、会話を重ねるごとに、「これはBiz側にも刺さるかも！」と直感したのです。

0.2.このテーマに決めた理由

現在では担当プロダクトの大部分がAWSへマイグレーションを終え、改めてクラウドサービス（以下、当記事ではもっぱらAWSを指す）の恩恵を感じるようになりました。

従来のオンプレやプライベートクラウドと比較し、クラウドサービスには多くのメリットがありますが、僕は真っ先にTCO(Total Cost of Ownership)削減と柔軟なスケーラビリティをメリットに挙げます。

なぜなら、「コストが年間◯◯％削減できる」とか「ピーク時のページ表示が遅くなるのを改善できる」という効果は、普段システマチックなことにあまり興味を示さないBiz側のステークホルダでも強く関心を示してくれることが多いからです。

特にWebサイトのページ表示速度はSEO評価に大きく影響するため、ピーク時にも耐えられる設計にしなければならない。だから、従来のオンプレでは無し得なかったAWS Auto Scalingを使わない理由は無いなと真っ先に思いました。

そこで今回は学び直しという観点で、Auto Scalingを使った入門レベルのWebサーバ構築をハンズオンしてみようと思いました。システム構成は下図の通りです。

具体的には、EC2で簡単なWebサーバを構築し、Auto ScalingでマルチAZの冗長構成を作ります。
そして、セッション管理のため、マネージド型のインメモリデータベース"ElastiCache for Redis"も構築したのですが、その手順まで書き切ると長くなっちゃうので、本記事ではAuto Scalingのみを対象とします。

1.簡単なWebサーバを構築する

今回はAuto Scalingの構築をメインに紹介したいので、構築するWebサーバは最低限の設定にしています。また、構築手順も他のサイトや記事で紹介されているものばかりなので、ここではざっくり行ったことだけ書いていきます。

※ちなみに、本記事の作業PCはMacですが、以下の操作はWindowsユーザを考慮し表記を統一します。
・TeraTarmなどのSSH接続ツール → ターミナル
・control+クリック → 右クリック
・Returnキー → Enterキー

1.1.EC2インスタンスを起動

今回は無料枠で作成できる以下のインスタンスを作成しました。
・AMI：Amazon Linux 2
・インスタンスタイプ：t2.micro
・セキュリティグループ：下表の通り

ここまで出来たら、最後にキーペア作成のダイアログが出てくるので忘れずにpemファイルを作成しダウンロード。これでEC2インスタンスが完成です。

1.2.Apacheのインストールと起動

ダウンロードしたキーペアを使ってデフォルトのec2-userでSSH接続でログインします。

ターミナルを開いてec2-userでログイン後、Apacheのインストールはいたってシンプルにyumを使用。
インストールができたら起動確認とテストページの表示確認（1.1.で作成したEC2インスタンスの"パブリックIPv4DNS"をブラウザのアドレスバーに入力してEnterを押下する）を行い、最後にApacheの自動起動を有効化しておきました。

$ sudo systemctl enable httpd

こうすることで、後ほどAuto Scalingによって起動される他のインスタンスでも、Apacheが自動的に起動されるようになります。

これでWebサーバの構築は完了となります。(実はPHPもインストールしてますが、本記事ではPHPを使用しないので割愛します。)

2.Auto ScalingとALB(Application Load Balancer)を作る

ここでは、先程作成したEC2インスタンスのAMIを取得し、Auto Scalingの際、そのイメージからインスタンスを起動し、さらにロードバランサーとの紐付けまで行なっていきます。

2.1.Webサーバのイメージを作成する

①マネジメントコンソール左ツリーの「▼インスタンス」＞「インスタンス」をクリックし、1.で作成したインスタンスIDをcontrol+クリック(Windowsの右クリック)し、「イメージとテンプレート　▶︎」＞「イメージを作成」を選択します。

②「イメージ名」と「イメージの説明」に任意の文字を入力し、画面下の「イメージを作成」をクリックします。

③下図のような表示が出てきたら完了です。

2.2.起動テンプレートを作成する

①マネジメントコンソールの「▼インスタンス」＞「起動テンプレート」をクリックし、右側の「起動テンプレートを作成」をクリックします。

②「起動テンプレート名」、「テンプレートバージョンの説明」に任意の文字を入力します。

③Amazon マシンイメージ(AMI)で、2.1.で作成したイメージを選択し、インスタンスタイプにはイメージの元となったEC2インスタンス(1.1.で作成したもの)と同じt2.microを選択します。

④1.1.で作成したEC2インスタンスと同じキーペアとセキュリティグループを選択。ここまで行なったら「起動テンプレートを作成」をクリックします。

⑤起動テンプレートの作成が完了しました。そのまま赤枠で示した「Auto Scaling グループを作成」リンクをクリックします。

2.3.Auto Scalingグループを作成する

①Auto Scaling グループ名に任意の文字を入力し、2.2.で作成した起動テンプレートを選択し、「次へ」をクリックします。

②インスタンスの購入オプションは「起動テンプレートに準拠する」を、VPCは既存のEC2インスタンスが存在する場所を選択。サブネットは耐障害性を考慮して既存のEC2インスタンスと別のAZを選択し、「次へ」をクリックします。

③新たにロードバランサーにアタッチするため、「新しいロードバランサーにアタッチ」を選択し、ロードバランサーのタイプからは"Application Load Balancer(いわゆるALB)を選択します。

④ロードバランサーの名前はデフォルトの値とし、スキームはInternet-facingを選択。アベイラビリティーゾーンとサブネットは、既存のEC2インスタンスが存在するAZにもチェックを付けます。

⑤デフォルトルーティング(転送先)で「ターゲットグループを作成する」を選択すると、新しいターゲットグループに自動的にグループ名が表示されるので、デフォルトのままとします。

⑥その他もデフォルトのまま、「次へ」をクリックします。

⑦今回は下図の通りグループサイズを設定します。(既存のEC2インスタンスに加え、④で指定したAZにもう1台インスタンスが作成されます。)

⑧スケーリングポリシーは「なし」を選択し、「次へ」をクリックします。以降、「通知の追加」と「タグの追加」のステップに進みますが、設定せず確認画面まで進みます。

⑨確認画面が表示され、内容に問題なければ「Auto Scaling グループを作成」をクリック。
下図の画面が表示されたら作成は完了です。

⑩左メニューの「▼インスタンス(INSTANCES)」＞「インスタンス(Instances)」をクリックすると、新たなインスタンスがap-northeast-1cのAZに作成されたのが確認できます。

ここでも、作成されたインスタンスのパブリックIPアドレスとキーペアを使って、SSHでログインすることも可能です。

3.ちょっと遊んでみた・・・

本来はエンジニアらしくフェイルオーバーテストの結果なんかをお見せするべきなんでしょうが、長くなるので、やや遊びに近いのですがAuto Scalingの凄さをもっとより実感できるオペレーションを行なってみました・・・
①Auto Scalingで作成されたインスタンスを停止します。

②すると下図のようなダイアログが表示されますが、デタッチなどせず「停止」します。

③インスタンスが停止されます。

④ところが、停止したインスタンスとは別に、見慣れないインスタンスが勝手に起動され、気づいたら実行中になっていました。

なるほど、これがグループサイズに指定した通り、1台止まったらすぐさまテンプレートから新たな1台を起動するようになっているのですね。
可用性を維持しサステナブル(持続可能性のある)なWebサーバと言えそうです！

4.おわりに

今回はおそらく入門レベルのハンズオンだったかと思いますが、このハンズオンを通して以下のようなことを実感しました。

①とにかくリソース供給が早い
もちろんしっかりしたインフラ設計は不可欠ですが、従来のオンプレやプライベートクラウドではここまで俊敏な構築は実現できなかったはずです。

②可用性に富み、サステナブルなプロダクトをユーザーに提供できる
冒頭にも述べましたが、ビジネスをグロースするための開発施策を最優先としつつ、いびつなアーキテクチャにならないようエンハンスを進めることが、僕の職責と捉えています。だから常日頃
プロダクトのグロースを推進するためには、SEOやCVR向上などの施策だけでなく、システムもサステナブル(持続可能な)ものであるべきだ！
と考えています。

テクノロジーばかり追求してもユーザーにプロダクトの進化を伝えにくいため、ユーザーがワクワクしビジネスを成功に導く施策を推進することは大事ですが、その施策は最適化されたアーキテクチャの上に成り立っていくものです。

ビジネスサイドや、クラウドの経験が浅いエンジニア(僕も含め)たちは、はじめは尻込みしてしまいそうですが、このAuto Scalingの構築の手軽さに触れ、ビジネスとシステムという点同士が線になっていくのを実感頂けると幸いです。

最後までお読みいただきありがとうございます。
次回は続編としてElastiCache for Redisのハンズオンについて投稿します。