はじめに
どーも、のぶこふです。
この記事はGFAMアドベントカレンダー2021の4日目の記事です。
4日目にして、すでに破綻しそうな感じがぷんぷんしてます。
Qiitaから、アドベントカレンダーのリマインドメールも届きました。ありがとうございます。
ということで、今日も元気に書いていきます。
今回は、みんなお馴染み。
「AWSと言ったらコレ!」
と言っても過言ではないEC2関連をまとめていきます。
今回のサービス一覧
Service名とか | 概要 |
---|---|
EC2 1 | IaaSの代表格 |
EC2 Auto Scaling | リソースの増減するよ |
前回の内容を鑑みて、内容を絞りました。
でも、EC2も奥が深く、本気でやろうとすると、これだけで1ヶ月は埋められると思います。
まずは、表面だけでも理解しよう、ということで、ライトに記述していきます。
EC2
- EC2:Amazon Elastic Compute Cloud
- お馴染みのコンピューティングウェブサービスです
- 逆に正式名称だと、「あれ、そんなサービスあったっけ?」と思いますね
- コンピューティングウェブサービスって何よ?となると思いますが、いわゆるサーバです
- プロセッサ、ストレージ、ネットワーキング、オペレーティングシステム、購入モデルを選択出来ます
- 具体例として・・・
- OS:Windows、Linux系(Amazon Linux、RHEL、MacOS、Ubuntu…)
- プロセッサ:インテル、AMD、Arm ベース
- 具体例として・・・
インスタンスタイプ
-
先の通り、EC2ではプロセッサの選択が行えます。その際、話に出てくるのが、インスタンスタイプです2
- インスタンスタイプは
[ファミリー][世代][追加機能].[サイズ]
で構成されています
- インスタンスタイプは
-
ファミリー
- メモリ・I/O・CPUクロック、価格・・・等、特徴に合わせたファミリーが提供されていて、処理するワークロードに合わせて、選択が可能です
- 時たま、「最適なファミリーを選べ」みたいな話もあったりするので、ざっくりと覚えておくと良いと思います
- どんどん増えていくので、その時々の最新を調べるのが吉
-
世代
- 数字が大きい方が新しく、コスパが良いので、基本は最新世代(数字が最も大きいの)を選ぶのが推奨されています
-
追加機能
- 内蔵ストレージ(インスタンスストア)を持っていたり、AMDのCPUだったり等
-
サイズ
- CPU、メモリ、EBS・NWの帯域幅によってサイズが分類されています
- アプリが必要とするリソースに合わせて選択・変更します
- CPU、メモリ、EBS・NWの帯域幅によってサイズが分類されています
ストレージ
InstanceStore | EBS | |
---|---|---|
概要 | インスタンス用のブロックレベルの一時ストレージ | EC2向けのスケーラブルなストレージ |
種類 | ブロックストレージ | ブロックストレージ |
揮発性(停止、休止、終了で消失) | 永続性 | |
特定のインスタンスタイプでのみ使用可能 | 全タイプで使用可能 | |
HDD/SSD | インスタンスタイプ(ファミリー)によって異なる | 選択可能 |
EC2 Auto Scaling
- Auto Scalingと一口に言っても、実は分類されている5 6
- Auto Scaling Groupと呼ばれるEC2インスタンスの集合体を作る
- 最小/最大インスタンス数を定義すると、それより小さく/大きくなる事は無い
- 希望するインスタンス数を定義すると、その台数になるように調整される
希望するインスタンス数?
- サイズ維持
- 障害などで停止した際、差分を検知して追加してくれる
- 手動スケーリング
- 希望する数を手動で変更し、台数を変更させる
- 自動スケーリング
- 様々な条件に応じて、希望する数を動的に変更し、台数を変更させる
スケール動作時に「インスタンスの分散」を重要視する
- 複数のAZにまたがってグループを作成している時、各AZ間で均一にインスタンスを配置しようとする
- インスタンス数が最も少ないAZに新規起動する
設定方法
- 概要が掴めたところで、早速、使ってみたいと思います。
- かくいう私も、初めて設定するので、ドキドキしながら設定してみます。
- AMIの設定については、独自AMIを使うでも良いですし、各自の状況に合わせて変更してください。
起動設定を作成する
-
EC2コンソールを開く
-
リージョンを確認する(指定したリージョンに紐づく)
-
情報を入力して、「起動設定の作成」を選択します
項目名 | 設定値 |
---|---|
名前 | my-launh-conf |
AMI | ami-0218d08a1f9dac831(Amazon Linux 2 AMI (HVM) - Kernel 5.10, SSD Volume Type ) |
インスタンスタイプ | t2.micro |
追加設定 | デフォルトのまま |
ストレージ | デフォルトのまま |
セキュリティグループ | デフォルトのまま(新規作成、全IPからのSSH許可) |
キーペア | 既存のキーペアの選択 |
AutoScalingグループを作成する
-
EC2コンソールを開く
-
リージョンを確認する
-
Auto Scaling > Auto Scaling Group を選択し、「Auto Scaling グループの作成」を選択する
-
情報を入力して、「AutoScalingグループを作成する」を選択する
- 複数ページに分かれているので、途中は「次へ」を選択する
項目名 | 設定値 |
---|---|
名前 | my-auto-group |
起動設定 | my-launh-conf(先程作成した起動設定を選択) |
ネットワーク(AZとサブネット) | デフォルトで用意されているap-northeast-1a〜1d を選択 |
ロードバランシング | デフォルトのまま(ロードバランサがありません) |
ヘルスチェック | デフォルトのまま |
その他の設定 | デフォルトのまま |
グループサイズ(希望する容量) | 2 |
グループサイズ(最小キャパシティ) | 1 |
グループサイズ(最大キャパシティ) | 3 |
スケーリングポリシー | デフォルトのまま(なし) |
インスタンスのスケールイン保護 | デフォルトのまま |
通知を追加 | なし |
タグを追加 | Key:Name, Value:AutoScaling, 新しいインスタンスにタグ付けをする:チェック |
挙動確認
あれ?じゃあ、どうやってインスタンスを終了させたら良いの?
- スケーリングポリシーが設定してあるのであれば、「有効化/無効化」を変更することができます9
- ※今回は設定していないです
- ポリシーを設定していない場合は、Auto Scaling Groupを削除する必要があるみたいです
- Auto Scaling Groupを削除すると、紐付いていたEC2インスタンスも削除されます
- 「ゴミを残しておかない」という観点からも、起動設定も削除しても良さそうです
おわりに
- ようやく「やってみた」感を出せるようになってきました。
- ドキュメントをまとめるだけではなかなか理解し難いところもあるので、実際にサービスを触ってみて、理解して行こうと思います。
- 今回のアドベントカレンダーの裏テーマは「知らないサービスを触ってみる」なので!
「AutoScalingも触ったこと無いのかー(ぶぶっ」と、思われても仕方なし。
愚直に、一つずつでも、触ってみるしかないぞー。そんな精神で、やっていこうと思います。
今回はここまでです。
ありがとうございました。