🔥

AWSでサーバーを構築してみる~インスタンス詳細設定③~

2021/01/22に公開

AWS

初心者

idea

はじめに

くーばねてすをやっつけるためにこれまでにLinuxさんと密に仲良くさせていただいたが、新たなステージに上がるためについにAWSさんに会いに行くことにした。AWSさんと仲良くなることでLinuxさんのファイルシステムだけでなく、インターネットの仕組みの理解につながると思い勉強する。今回はその第1歩としてAWSを使ってWordPressでブログシステムを構築しようと思う。

概要

■インスタンスの詳細の設定③
をまとめた！

■インスタンスの詳細の設定③

インスタンスの詳細の設定画面を開いたら詳細設定をする。

ここの画面で設定できるのはこれ↓
ノーマルの設定では、
インスタンス数
購入のオプション
ネットワーク
サブネット
自動割り当てパブリック IP
配置グループ
キャパシティーの予約
ドメイン結合ディレクトリ
IAM ロール
CPU オプション
シャットダウン動作
停止 - 休止動作

↓今回はここから(^_-)-☆

終了保護の有効化
モニタリング
テナンシー
Elastic Inference
クレジット仕様
ファイルシステム

高度な詳細では、
Enclave
アクセス可能なメタデータ
メタデータのバージョン
メタデータトークンレスポンスのホップ制限
ユーザーデータ

が設定できる！詳細設定のよくわからない項目をまとめてみた。

■終了保護の有効化

インスタンスを誤って終了しないように保護することができます。有効になると、終了保護を無効にしない限り、API や AWS Management Console を使用してこのインスタンスを終了できなくなります。

API や AWS Management Console でインスタンスを間違って終了(削除)を選択しても終了(削除)されないようにするっていう設定ね！OK。
今回はテストなのでいらない！(^_-)-☆

■モニタリング

Amazon CloudWatch を通じて、メトリクスをモニタリング、収集、分析します。デフォルトは、5 分間隔でデータを利用できる無料の基本モニタリングです。1 分間隔でデータを利用できる詳細モニタリングを有効にすることができます。

Amazon CloudWatch使うか？ってことらしい('_')
Amazon CloudWatchとは？

仕組み
CloudWatch は、AWS とオンプレミスで実行される AWS のリソース、アプリケーション、およびサービスを統括的に把握することができるように、ログ、メトリクス、およびイベントという形式でモニタリングデータと運用データを収集し、それらを自動化されたダッシュボードを使って可視化します。メトリクスとログは、リソースの健全性とパフォーマンスをより良く理解するために関連付けることができます。ユーザーが指定するメトリック値のしきい値に基づいたアラーム、または機械学習アルゴリズムに基づいて異常なメトリック動作を監視するアラームを作成することも可能です。迅速に措置を講じるには、アラームがトリガーされた場合に通知を受け、Auto Scaling などを自動的に開始する自動化されたアクションをセットアップできるため、平均解決時間の短縮に役立ちます。また、メトリクス、ログ、およびトレースを詳しく調べて分析し、アプリケーションパフォーマンスを向上させる方法をより良く理解することも可能です。

つまり、
Amazon CloudWatchを使うことにより...
■Amazon CloudWatch では、AWS のリソース、アプリケーション、サービス等全体のデータからデータを収集して、そのままの形ではなくて、計算や分析を加えてわかりやすいデータ（数値）に変換(メトリクス化して)システム全体の状態を一目でわかりやすいようにして、問題をすばやく解決することができるようになる。
■CloudWatch を使用することにより、AWS のリソースとアプリケーションのモニタリングが簡単になる。
■Amazon CloudWatch では、事前に定義されたしきい値、またはメトリクス内の異常動作を識別するアルゴリズム(計算方式)などに基づいてアラームを設定し、それに対応したアクションを設定することができる。
■パフォーマンスとリソース使用率を最適化するために、これまでの運用履歴が参照できる。Amazon CloudWatchでは最大 15 か月のメトリクスのストレージ保持できる。

見張っててくれてなんかあったらすぐに対応してくれるんだね！(^_-)-☆アルソックみたい！
デフォルトでは、基本的な所だけ　5 分間隔でデータを無料モニタリングしてくれる。

今回はテストなのでいらない！(^_-)-☆

■テナンシー

ご利用の目的にあわせて、完全専有の物理サーバーでインスタンスを実行することもできます。ホストテナンシーを利用すると専有ホスト (https://aws.amazon.com/ec2/dedicated-hosts/) でインスタンスが作成され、専有テナントを利用するとハードウェア専有インスタンス (https://aws.amazon.com/dedicated-instances/) としてインスタンスを作成します。インスタンスは、ホストのテナンシーとしても、専有 VPC 内でも作成できます。

「テナンシー」とはテナント属性のこと。共有か専有か選択することができる。
インスタンスを立てるAWSのハードウェアを他のユーザと共有するか、自分だけで専有するか選択できる。デフォルトでは共有になっている。
共有だと発生する料金は自分のAWSアカウントが所有するインスタンスの分だけとなる。
専有だとAWSのハードウェアの利用料(利用していないところも含め)全てを払う。
セキュリティ面を考慮し、他のアカウントと同居したくない、オンプレで使用していたライセンスを持ち込みたい時などに使うそうだ。
共有か？専有か？このインスタンスを自分の専有インスタンスで起動するか？が選択できる。

今回はテストなのでいらない！(^_-)-☆(共有)

■Elastic Inference

伸縮性のある推論？('_')

Elastic Inference は、すべての EC2 インスタンスタイプで、深層学習による推論におけるコスト効率に優れたハードウェアアクセラレーションを提供します。コストはスタンドアロンの GPU インスタンスのほんの一部です。

機械学習の推論を効率化をしてくれるサービスらしい('_')ハードウェアアクセラレーションってのはCPUの負荷を減らして処理してくれるやつらしい。

「Amazon Elastic Inference」を利用すれば、ユーザーはGPUアクセラレーションをEC2インスタンスに追加して、推論を高速化し、コストを最大75％節約することができる。通常、推論中のGPUの平均使用率は10～30％であるとAmazon Web Services（AWS）の最高経営責任者（CEO）のAndy Jassy氏は述べた。
　クラウド上の機械学習を採用する企業が増える中、AWSは推論を改善する新しい機能とツールを発表した。Amazon Elastic Inferenceを発表し、「AWS Inferentia」と呼ばれる新しいプロセッサを披露した。
　Jassy氏はラスベガスで開催中の「re:Invent」カンファレンスで、「コストの大部分、おそらくその約90％は推論に関するものだ」と述べた。

今回はテストなのでそんなに難しいものを作るわけではないのでいらない！(^_-)-☆

■クレジット仕様

クレジット仕様で無制限を選択すると、いつでも必要な分だけ、アプリケーションがベースラインを超えてバースト可能になります。インスタンスの平均 CPU 使用率がベースライン以下の場合は、すべての使用量が時間別インスタンス料金内で自動的にカバーされます。それ以外の場合、ベースラインを上回る使用量はすべて請求されます。アカウントレベルのクレジット仕様のデフォルトは設定で設定します

CPUクレジット
「CPU クレジット」。この言葉を聞いたことはございますでしょうか。例えば、Amazon EC2でT系インスタンスを使用しようとした場合、他のインスタンスタイプとは違い、ベースラインと呼ばれるあらかじめ決められたCPU使用率が定義されています。その上で、ベースラインを超えたCPU使用率が使用できる状況をバースト機能と呼びます。そのバースト機能を使用している時に使われるのが、CPUクレジットです。
略
「CPUクレジット残高」が0になると、後述するCPUクレジットの消費タイプにより、ベースライン以下の性能しか出なくなるか、追加の課金が発生します。

決められた使用率以上を使いたい時に追加の課金が発生するけど使うか？ってことらしい(>_<)

初期状態でデフォルト有効になっているインスタンスもあるようなので、意図せず有効化して高額請求が発生しないように、ちゃんと設定を確認するといいかも。
CPUクレジット残高！そんなやつがいたのか。。。

CPUクレジットが枯渇すると動作が不安定になるらしい。

■ファイルシステム

インスタンスにマウントする Amazon EFS ファイルシステムを指定します。インスタンスとファイルシステム間のトラフィックを有効にするには、ファイルシステムに、インスタンスから NFS ポートで TCP プロトコルのインバウンドアクセスを許可するセキュリティグループが必要です。また、インスタンスには、NFS ポートのマウントターゲットへのアウトバウンドアクセスを許可するセキュリティグループが必要です

WebサイトやWebシステムを構築する場合など、共有ストレージが必要になる場合があります。
WordPressを使ったオンプレミスのWebサイトの運用を例に挙げると、サーバー1台で運用している間は特に問題になりませんが、スケーリングや高可用性のためにサーバー複数台での運用に切り替えようとした場合、アップロードした画像やプラグインなどのファイルをサーバー間で共有することが求められます。

どうらやサーバー間で共有できるファイル機能付きストレージみたい('_')
ファイル機能付きストレージ使うか？ってことらしい。

Amazon S3やAmazon EBSとの違い
Amazon EFSは「ファイルストレージ」というタイプのストレージサービスであり、LinuxなどのOSでマウント可能なファイルシステムを提供します。
Amazon EFSとは異なり、Amazon Simple Storage Service (S3)は「オブジェクトストレージ」というタイプのストレージサービスであり、データを「オブジェクト」と呼ばれる単位で読み書きするためのHTTPSなどでアクセス可能なエンドポイントを提供します。
また、Amazon Elastic Block Store (EBS)は「ブロックストレージ」というタイプのストレージサービスであり、Amazon Elastic Compute Cloud (EC2)のインスタンス(仮想マシン)にアタッチするためのボリュームを提供します。
このように利用するサービスによって異なるタイプのストレージが提供されるため、目的に応じて適切なタイプのストレージサービスを使い分ける必要があります。

Amazon EC2インスタンスからAmazon EFSをマウントするにはマウントターゲットをインスタンスと同じサブネット内に作成し、そこを通じて他のインスタンスもAmazon EFSへアクセスするといった流れになる。

今回は便利そうだけど、お金かかるしインスタンス一個しか作成しないのでいらない！(^_-)-☆

まとめ

長いので続く！
Amazon CloudWatchはアルソック！