はじめに

自己紹介

今回は、**AWS（EC2/S3）**について勉強しましたので、アウトプットしていきたいと思います！

記事の対象者

プログラミング初学者
これからAWSの勉強を始める方
EC2について勉強した人
S3について勉強したい人

メインはプログラミング初学者となります。
なので極力専門的なワードを使用せず、具体例を交えて記事を作成しています。

記事作成の背景

作成したポートフォリオに画像投稿機能を追加したかったので、調べたところ、AWSでデプロイするならば、S3というストレージサービスを使った方が良いということがわかりました。しかし、この時点で中途半端についていた知識が邪魔します。
「EC2にもストレージサービスあんだからそれ使えばいいんじゃね？」
「なんでS3なの？」
っていうところからです、黙ってS3使えばいいのに、、、
発言からわかる通り、あんまり賢くないです。ってかばk、、、

記事の構成

これ以降のざっくりした記事構成と概要です。

目次	概要
EC2の役割	EC2の基本的な部分について説明しています。
S3の役割	S3の基本的な部分について説明しています。
具体例：S3を活用したアプリケーション	画像投稿機能が実装されたアプリケーションの挙動やメリットについて説明しています。
具体例：EC2を活用したアプリケーション	上記同様ですが、ここではデメリットのみ説明しています
まとめ	まとめです
疑問を解決してくれたサービス、参考書籍	書籍、サービスの紹介

EC2の役割

EC2とは

一言で言えば、webサービス等における心臓です！（サーバーに必要なものを一式クラウドで借りられる）
バックエンドエンジニアやフロントエンドエンジニアが作り上げたアプリケーションを立ち上げる場所になります。
当然ですが、ここがダメージを受けると、webサービスは停止してしまいます。
なので、インフラエンジニアの皆様方は、そうならないようEC2に負担をかけない設計をしてくれています。

EC2の主要な機能

EC2インスタンス
EC2インスタンスとは、AWSクラウド上に作られた仮想サーバー（サービスを提供する場所）のことです。
インスタンスと呼ばれる所以としては、次項で説明するAMIを活用して同じ構成のサーバーを何個も作れるからです。
ちなみにEC2とは、AWSが提供するサービス名であって、正式名称はAmazon EC2となります。
AMI
よく例えられるたい焼きの話と一緒です。要は、AMIとはたい焼きを作る型です。これにたい焼きのもとを流し込むことで、EC2インスタンスが作成されるのです。
EBS
EBSとはEC2インスタンス専用のストレージサービスです。テレビの外付けハードディスク的な存在です。確保容量があらかじめ決まっています。
ElasticIP
固定IPアドレスです。EC2インスタンスは停止後に再起動をかけるとグローバルIPアドレスが変わってしまい、以前のグローバルIPアドレスではアクセスできなくなります。要はサイトやサービスにアクセスができなくなるということです。
それでは困るので、この機能により、固定のIPアドレスを付与できるのです。
ElasticIPは直接EC2インスタンスにアクセスする場合のみ使用します。後述するELBを使用する場合は、ElasticIPを使用することはありません。
ELB
サーバーにアクセスが集中した場合や、CPU使用率等により自動で複数のサーバーに負荷を振り分けてくれます。後述でも触れていますので、詳しくはそちらで。

WebサービスにおけるEC2

先ほど説明したEC2についてまとめるとこんな感じになります。
追加した部分についての簡単な説明を以下にまとめました。
- Availability Zone => データセンターのこと。東京に4つ、大阪に3つ存在しており、ここにVPCを設置します。ap-northeast-1が東京リージョンを表し、a,c,dがそれぞれのデータセンターになります。bも存在しますが、説明は割愛します。先ほどの3つが使用できると考えてください。
- public subnet => インターネットと接続できる。
- private subnet => インターネットと接続できない。
- RDS => マネージド型データベースサービス（MySQLやPostgreSQL）
見ての通り、EC2インスタンスが二つあります。先ほど心臓と例えましたが、人間と違い、Webサービスは複数の心臓を持つことができます。ちなみに世にあるサービス（AWSを使用した）でEC2インスタンス一個で運用しているサービスはありません。理由としては、サーバーにアクセスが集中し、万が一ダウンしてしまった場合に、EC2インスタンスが一個しかなければ、そのWebサービスは完全にストップしてしまうからです。
だから、EC2インスタンスは複数用意しなければならないのです。ちなみにこのような対策をとることを冗長化といいます。
また、EC2インスタンスが複数あれば、先ほど説明したELBを使って、負荷を分散することもできます。

S3の役割

S3とは

高機能なストレージサービスになります。例えるならば、ドラえもんの四次元ポケットみたいなものです。S3にも色々機能はありますが、今回は、メリットに注目したいと思います。次項の具体例で詳しく触れていきます。

具体例:S3を活用した画像投稿機能付きアプリケーション

今回はrailsで画像投稿機能を実装したアプリケーションをEC2インスタンスに立ち上げたと仮定し、構成は下記のようにしました。
ちなみに画像の保存先はgem "fog-aws" を利用し、S3に保存できるように設定しているとします。

構成

メリット

Webサイトホスティング機能
これが最も便利な機能と言っても過言ではありません。この機能では、静的ファイルを「CloudFront」（説明は割愛します）経由で公開することができます。静的ファイルとは、画像や動画、また画像とHTMLだけで作られているファイル等を指します。上の構成図（緑枠線内）を見てわかる通り、CloudFront経由であれば、EC2にアクセスする必要がなく、EC2の負担がかかりません。
前述したようにEC2インスタンスが止まれば、サービスへの影響は甚大です。その意味でもこの機能はWebサービスを支える重要な機能と言えます。
容量が無制限
EC2のストレージであるEBSはあらかじめ容量が定められていますが、S3は容量が無制限です。
可用性、耐久性
障害やエラー等に対して強い。また最低3つのAvailability Zoneで自動で保存されているため、どこか一つのAvailability Zoneに障害があっても、使い続けることができる。

他にもたくさんありますが、とりあえずこの辺で。
ここまででも、十分にS3を使った方がいい理由やメリットがわかったと思います！
では、S3を使わないWebサービスの場合を見ていきましょう。

具体例:S3を活用しない画像投稿機能付きアプリケーション

今回はデメリットだけに注目したいので、あえてインフラ構成も最低限のもので揃えました。
未経験からエンジニア転職を目指して、ポートフォリオを作り、AWSでデプロイする場合や個人開発の場合であれば、インフラ構成はこれでも足りると思います。
想定しているアプリケーションは上記同様で、違いは、下記の通りです。
- 冗長化措置が取られていない
- S3を使用していない

構成

デメリット

デメリットは色々ありますが、今回はEBSの確保容量を超えた場合の挙動について注目したいと思います。

LinuxOSに影響が出る

OSに影響が出ることで最も怖いのは、ログが出力されなくなることです。ログが出力されなければ、どんなに優秀なエンジニアであっても解決には時間がかかります。なぜなら、そのサービスに関連する全てのフォルダ、ファイル等の全てに目を通さなければならないからです。エラーコードがあれば、それを手がかりに解決を測れますが、なければ、完全手探り状態でエラー解決しなければなりません。サービスが停止して、その後普及までに時間が掛かれば、お客さんは離れてしまいます。

状況によっては、Nginxが停止する

影響はEC2インスタンス以外にも及ぶということです。

仮に冗長化されていてもEBSは複数のEC2インスタンスで共有できない

EC2インスタンスがダウンした場合に、一緒にEBSも使えなくなってしまいます。
最近、EBSも複数のEC2インスタンスで共有できる機能がリリースされましたが、元々、共有を前提としたサービスではないので、不安が残ります。

=> ちなみにEC2インスタンスでは、EBS以外にもEFSというストレージ機能があります。この機能であれば、複数のEC2インスタンスで共有可能、容量も自動拡張してくれます。
しかし、それでもS3を指定するのは、EC2への負担を軽減してくれるからです。

結論

EC2インスタンスに頼った設計では、確保容量を超えた場合、ログが出力されなくなる等の致命的なリスクを抱えている。

ログが出力されないことは、Webサービスとして致命的です。そのリスクを抱えてまで、EC2インスタンスに頼った設計をする必要はないと考えます。

まとめ

S3を使えば、EC2インスタンスへの負担を減らし、安全なサービス運用につながる

AWSを使ってポートフォリオをデプロイしたことを機に勉強を始めましたが、本当によかったと思います。
**せっかくインフラエンジニアの方が、安全にサービスを運用できるインフラを整えてくれても、アプリケーション自体がインフラを考慮したコード設計になっていなければ、インフラエンジニアの努力は水の泡となります。そういった意味でもバックエンドエンジニアがインフラ関連の基礎知識を持っていることは重要だと感じました。**今後も勉強を継続したいと思います。

疑問を解決してくれたサービス、参考書籍

私は現在、くろかわこうへいさんが主催する**「AWS CloudTech」**にてAWSについて勉強しています。
AWSの基本的な部分については、全て網羅されていますし、何より説明が丁寧でわかりやすいです。

初心者にはおすすめできるサービスです。質問もしやすい環境です！

そして本記事執筆に伴い、同サービス内において、私の質問に対して丁寧に説明をしていただいた、**公式メンターのルビコン（＠RubiconLink）さん！**本当にありがとうございました！今後ともよろしくお願いいたします。

私がAWSの勉強を始めるにあたって、参考になった書籍もリンク貼っておきます。ネット関連の知識がなくても、読みやすかったです。本記事でも参考にしました。