今一度基礎からアウトプットしていこう。AWSサービス【サーバ関連】編


## サーバ関連

### Elastic Compute Cloud (EC2)
![EC2 イメージ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/6d727cf4-d476-65a1-3bf6-f2d584b91bae.png)

- **AWS上でレンタルできる仮想サーバの一つ**で、短時間で構築可能です。  
  EC2インスタンスの作成方法は、GUI、CUI、プログラム、APIなど多岐にわたります。同一リージョンに複数インスタンスを作成することで可用性が向上します。  
  **カテゴリ：IaaS**

#### 仮想サーバとは？
- **一つのサーバ上で複数のOSを動かし運用する仕組み**です。  
  ハードウェアリソース（ストレージ・CPU等）の分割配分を行い、効率的に運用します。  
  **キーワードは「分割・配分」**

#### 具体的に何ができるのか？
- EC2を利用することで、以下のメリットがあります。  
  - **コスト削減**：導入コスト、物理スペース、運用管理費の削減。  
  - **AWSサービスとの連携**が可能。  

#### 実例
- **任天堂のマリオラン**  
  [公式事例リンク](https://aws.amazon.com/jp/solutions/case-studies/nintendo-dena/)  
  エンタープライズ級のシステムはマネージドサービスではなくインフラ管理も自社で行う傾向になる。

#### 料金形態
1. **オンデマンドインスタンス**  
   - 利用時間に応じて課金されます。短時間利用におすすめです。  

2. **リザーブドインスタンス**  
   - 長期間契約（1年や3年）により割引が適用されます。長期稼働におすすめです。  

3. **Saving Plan**  
   - EC2以外のサービス（Lambda、Fargateなど）と併合して使用する場合、全体で割引が適用されます。  

4. **スポットインスタンス**  
   - 未使用リソースを低コストで利用できます。ただし、サーバが途中で停止するリスクがあります。  

#### 関連サービス
- **AMI（Amazon Machine Image）**  
  - インスタンス起動に必要な情報がまとまったテンプレート。OS、アプリ、起動許可などがパッケージ化されています。  

---

### Lambda
![Arch_AWS-Lambda_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/519e45b6-8972-6273-c08a-ae5c4ae1919e.png)

- クラウド上にプログラムを定義し、インターネットを通じて実行できるサービス。
イベントドリブンな**サーバーレスコンピューティングサービス**。実行時間が短く、データの変更やイベントによってトリガーされるアプリケーションに最適。Lamdaの実行には、他のサービスが処理のきっかけとなる呼び出しを送る必要がある。
**カテゴリ：FaaS**

#### サーバレスとは？
- 実際にアプリを稼働するためのサーバが存在するものの、その存在を意識しなくて良いこと。サーバにOS等のセットアップをする手間が省ける。サーバの障害対応等もクラウド提供者側が行う。


#### 具体的に何ができるのか？
- 上記のサーバレスの利点によって、大幅な開発スピードの向上が見込める。運用コストの削減。AWSサービスの恩恵を受けることもできる。

#### 実例
- **スクエアエニックスのドラゴンクエストX**
 [公式事例](https://aws.amazon.com/jp/solutions/case-studies/square-enix/)
 ゲーム内イベントの一時的負荷増加に備えた利用方法

---
### Elastic Beanstalk
![Arch_AWS-Elastic-Beanstalk_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/cbd9d62a-3754-0c4a-2cf9-6d38969ede06.png)


- アプリケーションサーバを簡単に構築・デプロイ・運用するための支援サービス。
インフラの詳細を隠蔽しつつアプリケーション運用を支援する。他サービスと比べ、早くて簡単。Java,Node.js,Go,Docker等一般に使われているプラットフォームがサポートされている。
**カテゴリ：PaaS**


#### 実例 
- **株式会社RettyのWebサービス構築**
[公式事例](https://aws.amazon.com/jp/solutions/case-studies/retty/)
デプロイ作業の簡易化、負荷対策の自動化という観点から選出されている

#### 他同種サービス
- OpsWork、CloudFormation
この差異については別記事でまとめる。

---

### Lightsail
![Arch_Amazon-Lightsail_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/17c803b8-1a8d-191c-6d3e-31ac4a86e49c.png)

- AWSの提供するVPN(Virtual Private Server)サービス。コンピューティング、ストレージ、データ転送等,Webサービスに必要な機能をパッケージ化している。AWS初心者向け。トレードオフの関係性で、柔軟性は少ない。

#### 実例
- 特になし。初心者向けのため、触ってみるとよいかも。

#### 料金について
- パッケージごとに月額固定料金。ただしインスタンスは停止していても課金される。

---

### Outposts
![Arch_AWS-Outposts-family_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/be99fdab-323a-899b-fa9f-d731aa149cba.png) ![Arch_AWS-Outposts-servers_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/4aa11b2d-6c90-972a-bc77-e32afcb9abbf.png) ![Arch_AWS-Outposts-rack_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/3155b54f-e2b0-0e4d-aebd-5fa6e821b0e7.png)

- AWSをオンプレミスのように利用できるハードウェアサービス。AWSクラウドと超低レイテンシで接続できる。自社のデータセンターに置くオンプレミス端末もAWS側の資産である。AWSデータセンターで発生する遅延に対処可能。

#### ハイブリッド型との違い
- オンプレミスとクラウドを併用することでハイブリッド型と呼称する。従来はオンプレミスは自社資産であったが、このOutPostsでのオンプレミス端末はAWS資産になる。
#### 事例
- 軍事利用
[興味深い記事](https://note.com/mickmack/n/n220ce15d86d5)
軍事関連情報においては低レイテンシが求められるため、このようなサービスが大々的に勧められている。日本ではこのようにマーケティングされていない。

---

### Auto Scaling
![Arch_Amazon-EC2-Auto-Scaling_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/4ec1ef4b-b883-be14-0500-055cb4249ae1.png)

- サーバの負荷が増大したときに自動的に性能や台数を引き上げて処理の遅延が怒らないようにすること。EC2インスタンスや他リソースを自動スケーリングする。どの程度高まったら拡張するかという「**しきい値**」を管理者が設定する。

#### 実例
- **株式会社StudyPlus**
[公式事例](https://aws.amazon.com/jp/solutions/case-studies/studyplus/)
規則正しい時間にのみ負荷のかかるサービスに対してのコスト減目的。

---

### Batch
![Arch_AWS-Batch_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/cb4541b3-94c2-afbe-a1c9-00dd59ab4127.png)

- フルマネージドなバッチサービス。ジョブを実行するためのインフラをユーザ側で準備する必要がない。AWSと連携することで大量のバッチ処理に対応することが容易になる。バッチ処理によって結果的に必要になってしまうリソースを、**EC2などで予め用意する必要がない**。Batchそのものに料金はかからない。

#### バッチ処理とは
- 連続したプログラム（ジョブ）を一切の手動介入なしにコンピュータで実行すること。リアルタイム処理ではなく、**事前に予定していた処理を自動的に実行**させること。**スケジュール**や**特定の条件**に従って自動実行される。一括した大量の処理を投入する場合に処理を分散化できる。

#### どういうときに使う？
- 大規模データ処理・・・気象データシミュレーション、金融データのリスク解析
- 高パフォーマンスコンピューティング・・・DNA配列解析、工学シミュレーション
その他機械学習、ETL処理等
→大量のリソースが必要な処理において、インフラを意識せずに効率的に実行できるサービス。**データに対しての処理が主**なので、S3は必須に近いが、他サービスは必須ではない。

#### 実例
- **スパコンなどの利用事例**
[公式事例スライド](https://speakerdeck.com/daisukemiyamoto/shi-li-karaxue-buaws-batch-x-supotutoinsutansuniyoruda-gui-mo-batutichu-li?slide=32)
---

### ECS(Elastic Container Service)
![Arch_Amazon-ECS-Anywhere_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/bc0510dc-be29-4343-c038-0b4f56f7963e.png)

- AWSが提供するフルマネージドコンテナオーケストレーションサービス。あくまで**コンテナの管理を担うツール**であり、コンテナの実行環境ではない。
　
#### コンテナとは
- 仮想サーバと比較して考えると、仮想サーバではOSを仮想サーバごとに分割していた。それにより片方のリソースが使用されない無駄が生じていた。これに対しコンテナはサーバ内の分割をアプリ、ミドルウェアのみにして、OSを切り離した。**仮想サーバに比べて、OSのリソースを余すことなく使えるようになったのが、コンテナ技術**である。コンテナの起動に応じて、柔軟にリソースの増減をすることが出来る。
　
#### コンテナの用意
- EC2内に**Docker**をインストールする。Dcoker内にアプリケーションを用意。これでコンテナの用意完了
　
#### EC2とコンテナの掘り下げ
- コンテナは**ホストOS**のリソースをもとに処理をしている。この**ホストOS**が、EC2インスタンス内のOSということになる。仮想サーバ内にコンテナが作られる。EC2インスタンス内部でコンテナを利用する場合は、ECSサービスを使うことで**コンテナオーケストレーション**が可能。

#### AutoScailingとの併用
- **AutoScailingはEC2インスタンスのスケーリング**。**ECSはコンテナのスケーリング**を行う。コンテナ数を増やしてもリソース不足の場合、EC2インスタンスをAutoScailingによって追加する。という処理も可能である。

#### kubernetesとの違い
- kubernetesも同じくコンテナオーケストレーションサービスである。状況によって使い分ける必要あり。**ECSの方が簡単**。**kubernetesの方がカスタム性充実**のトレードオフ関係。kubernetes専用のEKSというサービスもある。
　
#### 実例
- 金融スタートアップのWebサービス
[公式ページ](https://speakerdeck.com/stajima/container-fest-summer-fintech)
EKSに比べて簡単でキャッチアップが早い。

---

### Amazon EKS
![Arch_Amazon-EKS-Anywhere_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/8311cde3-f264-3d8e-49f6-3593028a5784.png)

- Kunernetesをクラウド上で扱えるマネージドサービス。ECSはAWS独自のオーケストレーションツールだったのに対して、Kubernetesを利用しているのが違い。
コンテナのスケーリングを行う。Kubernetes上にデータベースを作ることも可能。
ECSに比べて大規模なワークロード向け

#### 実例
- フロムソフトウェアのエルデンリング
[公式事例](https://aws.amazon.com/jp/solutions/case-studies/fromsoftware/)
デプロイ時のライブラリ、ミドルウェアの環境差異の解消

---
### Fargate
![Arch_AWS-Fargate_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/522fee06-d1e6-37d6-84ae-fbd780b9b712.png)

- AWS上でコンテナを**サーバレス**で運用できるマネージドサービス。サーバ運用で必要なOS管理が不要。**データプレーン**（コンテナ実行環境）としてECSやEKSと組み合わせる。
　
- タスク・・・Fargate上で実行できるようにコンテナ情報を定義したもの。
　
#### 実例
- Vanguard
[公式事例](https://aws.amazon.com/jp/solutions/case-studies/vanguard-ecs-fargate-case-study/)
セキュリティ、メンテナンスの観点からサーバレスマネージドサービスを選定。

---
### Elastic Container Registry(ECR)
![Arch_Amazon-Elastic-Container-Registry_64.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332976/c1797163-278d-e565-3c08-910067df1bf0.png)

- AWSでコンテナソフトウェアイメージを保存・デプロイ・共有できるサービス。フルマネージドサービスで、インフラのインストールなしにプッシュすることが可能。ECSかEKSに統合されている。
**コンテナイメージの格納サービス**

---
### まとめ
ケーススタディを覚えるのが一番理解度が増す方法だと分かった。
次回はセキュリティ編。