まえがき

ひとつ前のナレッジの記事の続き、その２のお話をさっそく記載いたします。

一般公開用インフラ設計のお話　その１「基礎知識編」

AWSクラウドのインフラを使ってお手軽な費用で公開したいという目的を主軸にしてのインフラ設計となります。

諸注意

本ナレッジは私が思う基礎知識を述べておりますが無料公開のナレッジのためある程度は大雑把にまとめています。
完璧な手順書ではなく、あくまで参考情報として基礎知識の補強程度としてお読みいただきますようお願いいたします。

画像が小さいですが直接画像を開いて頂ければ少しは見やすくなると思います。
より鮮明な画像が欲しい方や本ナレッジの内容を元により詳しく知りたいという方、その他追加のご希望があれば単発プランでご相談を頂ければと思います。

AWSの料金については2023年5月31日時点で情報を元に記載しています。
最新の請求金額は変わっている可能性がありますのでご注意ください。

AWSクラウドのインフラの基本的な設定
EC2インスタンスを起動
アプリのみでインフラを整える（簡易説明のみ）
Dockerを用いて素早く最小構成を整える（簡易説明のみ）
一通りの環境が出来たらバックアップ（自前のAMIを作ろう）

AWSクラウドのインフラの基本的な設定

AWSクラウドでウェブサイト（ウェブアプリ）を公開するために必要なこと

主に以下のVPC関連の設定を用意することでEC2のインスタンスを外部に公開が行えます。
数は多いのですが、以下のすべてはAWSのアカウントを作成した時点で自動生成されています。
そのため最初はすでにあるデフォルト設定を変更するだけで進められます。
後からネットワークが分離された（他のウェブアプリと競合しない）同じ環境を新規に作りたいときは以下のものを追加することになります。

細かな設定方法についてはこちらでは述べませんのでご自身で調べましょう。
大まかな対応が必要な項目のチェックリストとしてご利用ください。
どうしてもわからないことがあれば、MENTAなどで講師に質問したりサポートを依頼しましょう。

VPCの作成
ネットワークACLの作成
インバウンド・アウトバウンドの双方のパケット送信を許可します。
DHCPオプションセットの作成
デフォルト設定を利用するか、複製します。
インターネットゲートウェイの作成
ルートテーブルの作成
すべてのIPアドレス（0.0.0.0/0）をインタネットゲートウェイへつないでパブリックサブネットを作れるようにします。
サブネットの作成
後悔するアベイラビリティゾーンに合わせてサブネットを作成しルートテーブルと連動させます。
セキュリティーグループの作成
お使いのインターネット回線のグローバルIPアドレスからの接続を許可させるようにします。
ウェブアプリを一般公開する場合は、すべてのIPアドレス（0.0.0.0/0）の80(HTTP)を許可します。

以下の画像は私の所有のAWSアカウントのとあるリージョンで自動生成されているVPC環境情報です。
未使用のリージョンではありますが、アカウント作成時に有効なリージョンはすべてデフォルトVPCが自動で作られます。
使用予定がないリージョンを操作ミスを防ぐために無効化しておくのも手法の一つです。

AWSアカウント作成時のデフォルト設定について

セキュリティー対策を全くしない場合は何もしなくても自由にEC2を公開できるような設定になっています。
但し、だれでもアクセスできるので公開したくない情報もダダ洩れになります。
また、大量の要求によるトラフィック過多で意図しない料金発生にもつながりかねないです。

最小限の対策として、作業開始前に自分自身のグローバルIPアドレスを調べて自分のグローバルIPアドレス以外からのアクセスをすべて拒否するという設定を行うのが安全です。
注意点としてグローバルIPアドレスは固定化しない限り一定期間で変動します。
作業後はインスタンスを止めてアクセス許可を全部拒否にしておくとより安全でしょう。

AWSの利用の有無関係なく、在宅ワークをするならグローバルIPの固定化はほぼ必須

グローバルIPの固定化に対応しているISPと契約しIPアドレスの固定化の契約を行っておくと色々と便利です。

セキュリティー対策で強めの対策と言えばIPアドレス制限です。
グローバルIPの固定化によりデータの交換を行う上でIPアドレスによる制限が掛けやすくなります。
IPアドレス制限は一般的にセキュリティー対策の一つとして広く普及しているものなのでクライアントとの取引もスムーズになります。

＜余談ですが・・・＞
ISPを変更する機会があればIPoEに対応するかについても検討してみてください。
IPoEに対応することでお使いの回線にもよりますが最大2Gbps程度の超高速インターネット回線にグレードアップできる可能性もあります。
私の場合は首都圏ではありますが下り30Mbps/上り5Mbpsから下り500Mbps/上り200Mbpsくらいまでアップグレードできました。

EC2インスタンスを起動

EC2インスタンスの起動を実施

VPCの準備が出来たら次はEC2インスタンスの起動を行います。

！！！EC2起動後は条件に応じて実費料金が発生します！！！

AWSに登録して間もないアカウントであれば登録日から１年のみ無料枠が利用できます。
無料利用で進めたい場合は、以下の画像の無料利用枠の対象となっているAMI（Amazonマシンイメージ）とインスタンスタイプを選びましょう。

AWSには各種OSのひな型となるイメージデータが用意されています。
イメージのデータは、Amazonマシンイメージ(AMI)といいます。

Amazonクラウドサービス向けに調整されたLinuxのAMIとしてAmazonLinux系が用意されています。
その中でも、AmazonLinux2023は最新のOSでありサポートが５年ついていますので積極的に採用を試みたいOSとなります。

ですが、AmazonLinux2023はFedora系をベースにしていますので一部コマンドが異なる点に注意です。
CentOS(RHEL)をベースとしたAmazonLinux2022やAmazonLinux2など古いAMIもありますし、UbuntuのAMIもあります。
ですが、無料枠で利用できない場合や逆に高額になる場合もありますので慎重に選択してください。

インスタンスタイプはARM64系が安価で利用可能

無料枠が利用できるのであれば t4g.small を選択しましょう。
もし、無料期間が終了している場合は、ウェブアプリの要件に応じてインスタンスを選びます。

インスタンスの選び方の例として、シンプルなウェブページの表示だけなどプログラムが小さい場合など、0.5GiBメモリ（512MB)以内でプログラムが動作するのであれば最小のt4g.nanoを選びましょう。
t4g.nanoであればEC2を起動しっぱなしで１か月放置しても月額 $4（約542円 135円/ドル）程度の費用で済みます。

＜その他の例１＞
私の開発環境（nginx,php-fpm,mariadb,redisの４アプリをDockerで起動）では、t4g.microかt4g.smallを選択しています。
ウェブアプリなのでCPUのスペックはさほど気にしませんが、メモリが0.5GB～1GB程度で見積もっているためです。

＜その他の例２＞
ひとまずt4g.smallで起動し、アプリケーションを動かしてメモリが６０％～７０％以上余るようであればt4g.mircoに減らすという選び方もありです。
念のためメモリサイズを減らす場合はメモリをたくさん使う想定の処理を動かして事前にチェックしておきます。
topやfreeコマンド、AWSのモニタリングなどを見てピークメモリ使用量の状態を確認し、問題がなさそうならインスタンスを変更します。
逆にt4g.smallで運用していてアプリが勝手に終了する（ログを見てメモリ不足が原因と読み取れる）場合はt4g.mediumなどにグレードアップを行います。
そしてメモリ使用量が多くなっている原因を特定して意図していないメモリ仕様用であれば修正しましょう。

T系CPUはバーストという概念に注意

Tが名前につくインスタンスにはバーストという概念があります。

参考情報
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/unlimited-mode-examples.html
https://dev.classmethod.jp/articles/ec2-t-or-m/

ざっくりまとめるのであればCPU使用率に制限があるということになります。
ゲームのような常に重たい処理をし続けるようなCPU使用率100%の状態で何分も何時間も実行し続けることができません。
ウェブアプリのような時々アクセスがあってその時だけCPU使用率が増えるというCPU利用環境に向いているインスタンスです。

制限はありますがCPUクレジットというポイントが配布されて１ポイントにつき1 vCPUを1分だけ100%状態で続けて利用できます。
または1 vCPUが25%の状態を４分間使用することでも１ポイントとして換算されます。

t4g.smallは1時間に24ポイント配布され最大で576ポイントまでためることができます。

クレジット仕様にスタンダードと無制限があり、t4gは無制限がデフォルトとなります。
インスタンス起動時にスタンダードに設定されていないと、CPUクレジット不足の際にCPU使用率の制限がない代わりに追加料金が発生します。

スタンダードはCPUクレジットが足りなくなった場合、CPU効率は最大で２０％まで制限されます。
無制限モードの場合はCPU100%の時間が１時間につき$0.04ずつ追加料金となります。

CPU使用率が高い状態が何時間も続くのであればt4g系のインスタンスからc6g系のインスタンスに置き換えた方がコストが抑えられる可能性が出てきます。

CPUクレジットの動向の確認

EC2インスタンスの管理画面からモニタリング情報としてCPUクレジットの使用量や残高が確認できます。
重たい処理を行う前のCPUクレジット段高の確認や使用量の変化など監視しながら実装を進めることである程度のコントロールは可能です。

キーペア、ネットワーク、ストレージ、高度な詳細

キーペア設定

EC2サーバーにSSHでログインするための設定となります。
VSCode RemoteやMobaextermやTerminaなどのSSHクライアントから接続する際の秘密鍵として利用されます。
AWS EC2へのログインはパスワードを使用せず、ユーザーアカウント（ec2-user）と秘密鍵による認証でログインを行います。

ネットワーク設定

デフォルトまたは独自に作成したものを利用します。

ストレージ設定

小規模のウェブアプリであれば10GBもあれば十分でしょう。
容量が大きくなるほど料金が掛かりますが、無料枠が利用できる場合は30GBまで無料で使用できます。

高度な詳細

上記のバーストのところで記載していますが、クレジット仕様は高度な詳細の設定に含まれますので要件に応じて忘れずに設定しましょう。

アプリのみでインフラを整える（簡易説明のみ）

EC2インスタンスが起動したらSSHクライアントを用いてEC2インスタンスに接続します。
接続先のIPアドレスはインスタンスの一覧から パブリック IPv4 アドレス から確認が行えます。

パブリックIPアドレスはグローバルIPアドレスとなります。
AWS上のLinuxサーバーではありますが、ネットワークACL・サブネット・セキュリティーグループなど正しく許可が出来ていれば接続が可能です。

Mobaextermでの接続設定例

Remote host：パブリックIP
Specify usarname：ec2-user
Port：22 (SSHの標準ポート)
Advanced SSH settings／Use private key：インスタンスの起動時に指定した接続キーのPEMファイル
※接続キーのPEMファイルは事前にダウンロードした際に保存したアクセス元のローカルパソコン上のパス

正しく設定で来ていれば以下のようにSSHでログインが出来て自由にコマンドが実行できます。

LAMP構成、LEMP構成などご希望の構成に合わせてセットアップを行います。
インストール方法は多種多様なブログにて紹介されていますのでこちらでは割愛します。

LAMP

Apache, MySQL or MariaDB,PHPの組み合わせ

LEMP

Nginx, MySQL or MariaDB, php-fprmの組み合わせ

その他欲しいアプリ

必要に応じてインストールしてください。
phpMyAdminなどを入れて利用するのも可能です。
直接EC2にHeidiSQLやMySQL Workbenchなどの編集ツールを接続することもできます。
私はサーバー上で無駄なリソースを使いたくないので余計なアプリは入れないです。
topコマンドでCPUやメモリ使用量を見て気になるものは削除することもあります。

各種アプリの設定を行う

大まかには以下の設定ファイルにてデータの保存パスやアクセスパスおよび受付ポートなどの設定を済ませます。
以下の[]の数値は一般的な受付ポートです。

apache：httpd.conf [80]
Nginx：nginx.conf [80]
MySQL or MariaDB ; my.cnf [3306]
PHP (apache) : php.ini (Apacheのモジュール追加、httpd.confへの設定追加)
PHP-FPM (Nginx) : php.ini,php-fpm.conf,www.confなど (nginx.confへの設定追加) [9000]

接続確認とIPアドレスの固定化

パブリックIPのアドレス先へブラウザでアクセスします
問題がなければEC2インスタンスにElastic IPで取得した固定のグローバルIPアドレスを割り当てます
ElasticIPの設定が終わったらグローバルIPアドレスでアクセスします

PHP情報表示ページ

初期のインストールのチェックにはとても便利ですが色々情報が駄々洩れです。
自分自身以外の人が見ることができないように注意しましょう。

テストページ

私が契約しているドメイン名を使用してアクセスした場合は意図したウェブページが表示される仕組みにしています。

SSL対応など必要があればドメイン登録

以下、大まかな説明のみです。

お安く構築する場合

外部サイトなどで安価なドメインを契約する
外部サイトなどで契約したドメイン用の証明書を購入して入手する
EC2に購入した証明書を設定
外部サイトなどのDNSサーバーにて契約したドメインの名前とElastic IPを紐づける

AWSのみで構築する場合

AWSのRoute53を利用してドメインの登録
AWS Certificate Managerにて証明書をリクエスト
Elastic Load BalancerにてApplication Load Balancerを作成（有料）
Application Load BalancerのTarget Groupに起動しているEC2を登録
Route53にてApplication Load Balancerとドメインを紐づける

Dockerを用いて素早く最小構成を整える（簡易説明のみ）

AWSのEC2単体での一通りのセットアップとウェブページの表示が出来ていれば後はDockerに移行するのも比較的スムーズです。
最終的にECSの利用を考えている場合は、DockerFileやDocker-Composeのどちらに設定を書くかはじっくり考える必要があります。

Docker Composeの設定例

私の環境で利用しているDocker-Composeをベースに不要な行をほぼ削除したものです。

間違えて別の環境で利用しないようにしつつ、ARM64で利用するためにplatformを指定しています。
また、ECS on EC2での実行が出来るようにも配慮しています。
実際にECSでコンテナを起動しウェブページが表示されるところまで動作も出来ています。

Docker Stats でコンテナのリソース使用量を確認

Docker経由で起動しているアプリケーションのCPU使用量及びメモリ使用量です。
CPU使用量はアクセスがなければ小さいですし、仮に100%でもアプリケーションが停止することはありません。
メモリが不足した場合にアプリケーションが停止するなどして正しく動かなくなったり不安定になりますのでしっかりと余裕を持たせましょう。

私の環境ではコンテナが利用する最小メモリは130MBくらいです。

top コマンドでLinux全体のリソース使用量を確認

私の現環境の場合ですと、Linux全体でメモリを0.5GB（５０％）ほど利用していることがわかります。
そうなると、現状では t4g.nano (2 vCPUs /0.5 GiB)に切り替えての運用は厳しそうです。（月額５００円近くまでお安くできる）

要件次第ではもっと初期のメモリ使用量を抑えることは可能です。
省メモリを意識してチューニングを行えば、t4g.nanoも不可能ではなさそうですね。

一通りの環境が出来たらバックアップ（自前のAMIを作ろう）

AWSには便利な汎用のAMIが用意されています。
ですが、自分の開発環境や扱いやすい構成とは違っていることがあります。
そのため色々と自分好みに変更を行いますが、それなりに時間が掛かります。
新規にインスタンスを起動するたびにセットアップを行うのは操作ミスなどもあり得ますし時間の短縮がしたくなります。
自分でこのインスタンスの構成のバックアップから復旧出来たら便利なのにな・・・となるわけです。

簡単に現在のシステム構成からAMIが作れます！

対象のインスタンスからイメージを作成を選んで名前を付けて終わりです。
注意点としてLinuxのシステムが動いている状態で中途半端にバックアップされるとゴミデータが残ってしまうこともあります。
そのため、AMI作成時にLinuxを一旦止めてバックアップ後に再起動させるようにしてバックアップをしましょう。
操作としては何もせずデフォルト設定のままで大丈夫です。

「再起動しない」の有効化のチェックボックスのチェックは付けないでくださいね！

５分くらいでAMIの登録が終わります。
AMIの一覧から起動させることもできますし、EC2インスタンスを起動する際のAMIの選択メニューから自分のAMIを選ぶこともできます。

あとがき

それなりの長めの記事になってしまいました。
AWSを使ってこれから何かしたいという方にはかなり充実的な内容になっているのではと思います。

インフラがなければウェブアプリは動かないのでアプリの開発をする上である程度のインフラの知識はやはり必要ですね。

基本的なインフラはマスターして安定した環境を用意できれば 安心して開発に集中できます。

無料ナレッジなので、ところどころ説明を省いたり画像のみになっている部分があります。
本記事だけがすべてではないのは大変だと思いますが、困った時はMENTAに登録されている講師に頼って頂けたらと思います。

一般公開用インフラ設計のお話　その２「AWS 費用重視（試作・検証・ポートフォリオ公開向け）」

まえがき

諸注意

目次

AWSクラウドのインフラの基本的な設定