メモ
仕事で前回のITパスポート資格に続き、スキルアップと今のPJで活かすためにAWSの資格を取得することにしたのでその勉強用の備忘録です。
まずは「クラウドプラクティショナー（AWS Certified Cloud Practitioner(CLF-C01)）」から。
いつも何か勉強するときは基本的に書きながら覚えるのでここでアウトプットします。
有益な情報かどうかは不明(笑)
スポンサーリンク
EC2
EC2の概要
EC2はAmazon Elastic Compute Cloudの略。
Elasticは「弾力性のある」「伸縮自在な」という意味。
EC2では、仮想サーバーがサービスとして提供されるが、
需要の変化に応じて性能も台数も伸縮自在に柔軟に使うことができる。この特徴はサービスを理解する上でも重要。
EC2の特徴
EC2には次のような特徴がある。
・必要なときに必要なだけの量を使用
・使用した分だけコストが発生
・変更可能なインスタンスタイプから性能を選択
・数分でサーバーを調達して起動できる
・世界中のリージョンから起動場所を選択
・AMIからいくつでもサーバーを起動できる
・セキュリティグループでトラフィックを制御できる
・オペレーティングシステムを管理者権限で操作できる
・ユースケースに応じた料金オプション
必要なときに必要なだけの量を使用
EC2では必要な時に必要なだけのインスタンスを稼働させることができる。
1インスタンスは仮想サーバー1台。
必要でない時は、稼働しているインスタンスを減らすことができる。
これにより使われていないリソースの余剰が減る。
適切に設定していれば、需要の変化に応じて必要なインスタンスを起動させることができるので、
予測できていない範囲にも対応できる。
EC2を使うことにより、これまでのように予測できない範囲まで推測する必要がなくなる。
事前に予測できないものを予測しようとするよりも、状態を観測しながら柔軟に対応することができる。
★使う時にだけEC2インスタンスを起動することができる
★必要なEC2インスタンスの数を事前に予測する必要はない
使用した分だけコストが発生
EC2の料金は次の3種類から構成されている。
1.EC2稼働に対しての料金
2.データ転送料金
3.ストレージ料金
・EC2に対しての料金
OS、リージョン、インスタンスタイプによって料金が異なる。
この料金は1時間単位で課金される。(Amazon Linux、Ubuntuでは秒単位(最短1分)の課金)
EC2インスタンスが起動中の時間が課金対象となり、停止中には課金が停止している。
・データ転送料金
リージョンの外にデータを転送した場合に、データ転送料金が発生する。
データ転送料金はリージョンによって異なる。
インターネットへ転送した場合と他リージョンへ転送した場合でも料金が異なる。
インターネット→EC2へのデータ転送受診(イン)には課金されない。
アプリケーションに対してインとなる通信位は転送料金は発生せず、アウトとなる通信に転送料金が発生する。
また、同じリージョン内の他のEC2へデータを転送した時は、AZが異なる場合、転送料金が発生する。
・ストレージ課金
厳密にはEC2の料金ではなく、EBS(Amazon Elastic Block Store)の料金。
EBSに対しての課金は、1GBあたりのプロビジョニングした料金。
プロビジョニングとは、ボリュームのサイズとして確保した容量。
稼働しているインスタンス分のみ課金が発生するため、コスト効率よくインスタンスを使うことができる。
EC2を使うことによって、これまでは固定費として考えられていたインフラストラクチャの費用を、
必要に応じた変動費として考えることができるようになる。
★使った分にだけ料金が発生する
★時間単位、秒単位で課金される
★アウト送信に転送料金が発生する
変更可能なインスタンスタイプから性能を選択
EC2では、様々なインスタンスタイプという性能の組み合わせから選択することができる。
最初に決めたものを使い続けるのではなく、使い始めてから他のインスタンスタイプに変更することができる。
インスタンス対応は運用開始後でも、インスタンスを停止することで変更できる。
インスタンスタイプはファミリー、世代、サイズから表記される
t2.micro
・ファミリー：インスタンスを何に使用するか、用途によって選択する。
ファミリーごとに適した構成のハードウェアが使用される。
例：T(汎用、検証)、M(汎用)、C(コンピューティング)、X/R(メモリ最適化)、P/F/G(高速コンピューティング)、H/I/D(ストレージ最適化)
・世代：バージョン。新しいバージョンを使用することで、
コンピュータ効率が良くなるなど、改善や機能改善がなされる。
インスタンスタイプがいつでも変更可能ということは、
時間の経過に伴って発展していく技術をいつでも利用することができるということ。
・サイズ：性能のレベルを表す。サイズを変更することにより、
vCPU、メモリ、ネットワーク、ストレージの性能、使用できるストレージなどが決まる。
まずファミリーを選択肢、その後サイズを選択、
そして状態に応じてサイズを変更しながら調整していくというアプローチが一般的。
・インスタンスタイプの選び方
インスタンスタイプによってインスタンスの稼働時間の課金単価は変わる。
性能が低い方がコストとして低くなる傾向がある。
だからと言って、低いコストのインスタンスを利用することが最適なコスト最適化ではない。
必要としているコンピューティング処理が最も早く完了する
インスタンスタイプを選択することがベストプラクティス。
EC2は一時的なコンピューティングリソースとして使い捨てすることができる。
処理が終わったところでインスタンスを捨ててしまえば、それ以上課金は発生しない。
処理に長い時間をかけてその分の課金を発生させるよりも、
処理を迅速に終わらせた方が、トータルコストが下がる可能性がある。
コストだけではなく、処理を早く完了することは、遅いことよりも多大なるメリットをもたらす。
ただし、当然のことながら、過剰なスペックを持つインスタンスタイプを選択する必要はない。
最適なインスタンスタイプを選択する最も確実な方法は、計画や机上の計算による予測ではない。
モニタリングしながら適切なインスタンスタイプを選択し、そしてまたモニタリングすることが重要。
★インスタンスタイプは運用を開始した後に柔軟に性能を変更できる
★運用を開始する前の、誤った性能予測の計算をする必要がなくなる
数分でサーバーを調達して起動できる
EC2インスタンスを手動で起動する場合に必要なステップをいかに示す。
1.リージョンを選択する
2.AMIを選択する
3.インスタンスタイプを選択する
4.起動するネットワークを選択する
5.ストレージを選択する
ものの数分で起動することができる。いちどに複数台を自動で起動することも可能。
これらのステップをあらかじめ設定しておくことで、調達・起動を自動化することもできる。
従来の、発注してからハードウェアが納品されるまでに数週間かかっていたプロセスに比べると、
サーバーの調達時間を飛躍的に短縮することができる。
リソースの調達が早いと、そのリソースを使用したサービスを顧客に提供するスピードも早くなる。
企業は顧客からのフィードバックを早く得ることができるようになり、経営の俊敏性が向上する。
★数分でEC2を起動できることは、経営の俊敏性が増すことに直結する
世界中のリージョンから起動場所を選択
EC2を起動する場所を世界中のリージョンから選択できる。
どこのリージョンで起動しても時間の差はない。
グローバル化を考えた時、数分で世界中にインスタンスをデプロイできるということは、非常に大きなメリット。
★数分でEC2を世界中にデプロイできる
AMIからいくつでも同じサーバーを起動できる
EC2インスタンスはAMI(Amazon Machine Image)から起動する。
1つのAMIからいくつでもインスタンスを起動することができる。
AMIのおかげで、同じ構成を持ったEC2インスタンスを複数起動することができる。
AMIはEC2インスタンスのテンプレートであり、OS、アプリケーション、データなど様々な情報をEC2に提供する。
AMIは大きく分けて4種類ある。
1.クイックスタートAMI
AWSがあらかじめ用意しているAMI。
OSとモジュールがインストール済みで用意されている。
Deep Leaning向けのクイックスタートAMIをある。
最初に始めるときに、要件に合致しているAMIがある場合はクイックスタートから選択する。
2.マイAMI
ユーザーが作成するAMI。AMIの作成は非常に簡単。
起動中のEC2を選択してイメージを作成するだけ。
例えばクイックスタートから起動したEC2インスタンスに独自のアプリケーションをデプロイして、AMIを作成する。
そのAMIから新しいインスタンスを起動することで、
同じアプリケーション構成を持ったインスタンスを複数起動することができる。
稼働中のアプリケーションサーバーのバックアップとしてAMIを定期的に作成することもできる。
マイAMIは他のアカウントと共有することも、公開することも可能。
3.AWS Marketplace
ソフトウェアやミドルウェアがすでにインストールされている構成済みのAMI。
パートナーベンダーが提供している。
使用予定のソフトウェアがAWS Marketplaceにある場合は、
それを使うことが最も早くシステムを構築する方法。
ソフトウェアは提供ベンダーによってテスト済みの状態で提供される。
ソフトウェアによっては、ライセンス料金が、EC2の従量課金に加算されるものもある。
運用を開始したからといって、そのソフトウェアを1年間など長いスパンで使い続けなければならないのではなく、
必要に応じて他のソフトウェアを選択していくことも容易になる。
ハードウェアだけでなく、ソフトウェアの利用についても柔軟に対応していくことができる。
1-Click Launch(1-Click起動)オプションを使用することで、推奨オプションを使用してすばやく起動できる。
4.コミュニティ AMI
一般公開されているAMI。クイックスタート、マイAMI、AMS Marketplaceに適したAMIがない場合は
コミュニティAMIから選択する。
たとえばWindowsのJapaneseエディションなどもコミュニティAMIから選択できる。
★AMIから同じ構成のEC2インスタンスを何台でも起動できる
★AWS Marketplaceから簡単にソフトウェア構成済みのEC2インスタンスを起動できる
セキュリティグループでトラフィックを制御できる
EC2インスタンスへのトラフィックは、セキュリティグループで制御できる。
1つのセキュリティグループを複数のインスタンスに設定することができる。
★EC2インスタンスへのトラフィックはセキュリティグループのインバウンド(受信)で制御する
オペレーティングシステムを管理者権限で操作できる
起動したEC2では、キーペアを使用してログインすることで、OSを管理者権限で操作できる。
・キーペア：ユーザー名とパスワードのセットでログインするよりも安全な方法として、
EC2ではキーペアを使った認証方式がデフォルトで採用されている。
キーペアでは、公開鍵と秘密鍵の2つの鍵ファイルをペアにして認証を行う。
ユーザーは、ユーザー名と秘密鍵ファイルを使ってログインする。
秘密鍵ファイルが漏れてしまわない限りは、不正アクセスのリスクからインスタンスを保護することができる。
ユーザーはまずAWSでキーペアを作成する。
公開鍵はAWSに保管され、秘密鍵は作成したタイミングでダウンロードされる。
ユーザーはこの秘密鍵を、OSの管理者だけがアクセスできる場所で管理する。
そうすることで、不正アクセスのリスクからインスタンスを保護することができる。
EC2インスタンスを作成する際にキーペアを選択する。
AWSに補完されている公開鍵がEC2インスタンスにコピーされる。
OSの管理者はあらかじめダウンロードしている秘密鍵とユーザー名で
EC2インスタンスにログインすることできる。(EC2インスタンス起動時にキーペアを作成することもできる)
・Amazon Linux、Ubuntuへのログイン：SSHコマンドかSSHクライアント(TeratermやPutty)を使用して、
ターミナルからログインする。
コマンド例：$ ssh -i .ssh/MyKey.pem ec2-user@51.52.53.54
Amazon Linuxではec2-user、Ubuntuではubuntuというユーザーが、
キーペアを使うユーザーとして初期設定されている。
ec2-userとubuntuは、sudoコマンドを使うことでroot権限で各コマンドが実行できるユーザー。
・Windowsへのログイン：起動したEC2インスタンスを選択して、
[アクション]-[Windowsパスワードの取得]を選択する。
秘密鍵を読み込むことでAdministratorのパスワードを取得できる。
OSの管理ユーザーはAdminisuratorのパスワードを使用して
リモートデスクトップ(Remote Desktop Protocol RDP)でWindowsにログインする。
AWS Systems Managerのパッチマネージャーを使用することにより、
SSHやRDPで接続しなくてもセキュリティパッチを適用できる。
★OSの管理者はキーペアで安全にログインできる。
ユースケースに応じた料金オプション
EC2インスタンスの使用料金にはいくつかの料金オプションが用意されている。
この料金オプションをユースケースに応じて使い分けることで、
ユーザーはコスト効率よくEC2を使用することができる。
・オンデマンドインスタンス
・リザーブドインスタンス
・スポットインスタンス
・Dedicated Hosts
・ハードウェア専用インスタンス(Dedicated INstance)
・Sarvings Plans
・オンデマンドインスタンス：料金オプションを使わずにEC2インスタンスを使わずにEC2インスタンスを起動すると、
オンデマンドインスタンスの単価が適用される。
いわば定価料金。秒単位、時間単位の課金により、必要な時に必要なインスタンスを起動できる。
運用を開始してすぐのタイミングなど、インスタンスタイプの変更が必要な場合はオンデマンドインスタンスを使用する。
その後、柔軟に性能を変更する、もしくは必要なくなったときに削除することができる。
・リザーブドインスタンス：たとえば24時間365日(またはその75%以上)稼働し続けることが決まっているインスタンスの場合、リザーブドインスタンスが最適な選択肢。
1年または3年の使用期間を事前設定することで、割引を受けることのできる料金オプション。
リザーブドインスタンスには、1年または3年という期間の選択と、
支払い方法(全額前払い、一部前払い、前払いなし)の選択がある。
3年・全額前払いが最も割引率が高い選択肢。
75%の使用率(558時間以上)を上回れば、
確実にリザーブドインスタンスの方がトータルコストが低くなることがわかる。
リザーブドインスタンスにはコンバーティブルという、期間中に属性を変更できるタイプもある。
コンバーティブルに変更することで割引率は少し低くなる。
最も割引率の高いリザーブドインスタンスは、3年間、前払い、スタンダード(コンバーティブルではない)タイプ。
・スポットインスタンス：EC2では顧客がインスタンスを使いたい時に必要な量を提供できるように、
未使用のEC2キャパシティがある。
この未使用のキャパシティ量によって変動するスポット料金がある。
未使用キャパシティが多ければ多いほどスポット料金は下がり、
未使用キャパシティが少なればスポット料金は上がる。
いわば市場取引のように変動する。
このスポットインスタンスに対して支払っても良い金額を
リクエストとして設定することで利用できるのが、スポットインスタンス。
指定したスポット料金よりも下回ったら起動し、上回ったら終了する。
スポットインスタンスは、処理途中で終了しても問題がないユースケースに向いている。
処理途中で終了しても問題がないインスタンスにするためには、
インスタンスでは状態や情報を持たない、ステートレスな設計にすることが前提。
厳密なリアルタイム性を伴わないバッチ処理などを、低コストで実現したい場合などに適している。
検証やテストで使用する場合もある。
一定の時間、確実にインスタンスを起動しておく必要がある場合は、
オンデマンドインスタンスかリザーブドインスタンスの使用を検討する。
・Dedicated Hosts：Dedicated Hostsは、EC2が起動するホストを専有するオプション。
セキュリティ/ガバナンス要件、ソケット、コア、VMソフトウェア単位でもライセンス要件を満たせる。
他の料金オプションとの最大の違いは、インスタンスではなく、ホストに対しての従量課金だという点。
・ハードウェア専有インスタンス：アカウント専用のハードウェアでEC2を実行する。
Dedicated Hostsとは違いインスタンス単位で料金が発生する。
専有追加料金が必要。
・Savings Plans：1年または3年でより柔軟にコストを節約できる。
EC2インスタンス用のSavings Plansのみならず、
AWS Fargate、AWS Lambdaを使用する場合にも適用されるCompute Sarvings Planもある。
★ユースケースに応じて料金オプションを使い分けることでコスト効率が向上する。
EC2インスタンスの起動
マネジメントコンソールにサインインして、サービスからEC2を選択。
リージョンは東京になっており、起動中のインスタンス、サービスの状況やイベントが表示されている。
[インスタンスの作成]ボタンからインスタンスの起動を始める。
まずはAMIを選択。クイックスタート、マイAMI、AWS Marketplace、コミュニティAMIから選択できる。
次にインスタンスタイプを選択。
vCPU、メモリ、選択できるストレージ、ストレージの最適化有無、ネットワーク性能がインスタンスタイプごとに異なる。
次にネットワークの設定などを行う。
[インスタンス数]に数字を入力すると、現在設定中の構成を持ったインスタンスを複数台同時に起動することができる。
[スポットインスタンスのリクエスト]を有効にすると、起動するインスタンスをスポットインスタンスで起動することができる。
[最高価格]フィールドに入力したリクエスト料金[現在の価格]が下回った時にスポットインスタンスが起動する。
続いて、使用するストレージボリュームの設定。
次はタグの設定。タグには、EC2インスタンスをユーザーやプログラムから見分けやすくするためのキーと値を設定できる。「Name」というキーの値はマネジメントコンソールのインスタンス一覧にも表示される。
続いてセキュリティグループの設定。
例ではポート番号22番のSSHのみを許可。
これによってEC2インスタンスへの他のポート番号でのアクセスは拒否される。
また、送信元として「マイIP」を選択することで
マネジメントコンソールを操作している端末のグルーバルIPアドレスが設定される。
本番環境では、SSHにはOSの管理者が送信元として使用するIPアドレスを設定する。
確認画面の内容に問題がなければ[作成]ボタンを選択する。
つづいて キーペアの選択画面が表示される。
既存のキーペアを選択するか、新たなキーペアを作成することができる。
例では新たなキーペアを作成して秘密鍵をダウンロードする。
インスタンスが作成され、runnning(起動中)の状態になる。
作成してダウンロードした秘密鍵を使ってSSHにログインする。
Amazon Linuxにはキーペアを使うことのできる「ec2-user」というユーザーが初期設定されている。
MacやLinuxクライアントからSSHコマンドでログインする場合はパーミッションを変更する必要がある。
WindowsでTeratermを使用する場合はそのまま使用できる。
WIndowsでPuttyを使用する場合はPEMファイルをPPKファイルに変換する必要がある。
EC2インスタンス起動のコマンド
$ sudo chmod 600 MyKey.pem
$ ssh -i MyKey.pem ec2-user@パブリックIPアドレス
他に、AWS Systems Managerセッションマネージャーを使って、マネジメントコンソールから接続することもできる。
★数クリック、数分でEC2インスタンスを起動できる
ELB
ELBの概要
例えば、EC2にWebアプリケーションをデプロイして、外部からのアクセスができる状態にする。
1つのAZ(AZa)にしかEC2を構築していない場合、
AZaが使えなくなった場合やEC2に何らかの障害が発生した場合、
EC2にデプロイしているWEBアプリケーションはユーザーからのリクエストを受け付けられなくなる。
これでは、システムがいつ停止してもおかしくない状態。
EC2を複数のAZに配置して、
ユーザーからの単一アクセスを受け付けるようにするためのサービスがElastic Load Balancing、略してELB。
ELBを使用することで、同じ構成を持った2つのEC2インスタンスを別々のAZに配置することができる。
そして、ELBはその2つのEC2インスタンスにユーザーからのリクエストトラフィックを分散する。
このようなマルチアベイラビリティゾーン構成にすることで、
EC2の障害だけではなく、AZ単位で障害が発生した場合でも、システムを継続することができる。
これで高可用性、耐障害性を向上することができる。
★EC2インスタンスの可用性を高めるためにELBを使用することができる
ELBの特徴
ELBの主な特徴
・ロードバランサータイプ
・ヘルスチェック
・インターネット向け/内部向け
・高可用性のマネージドサービス
・クロスゾーン負荷分散
・ロードバランサータイプ：ロードバランサーには3つのタイプがある。
Application Load Balancer...HTTPまたはHTTPSのリクエストを負荷分散する用途で選択する。
ターゲットとするインスタンスやコンテナを複数設定し、
リクエストパスや送信元のホストによってルーティングする機能や、SSL証明書を設定する機能、
リダイレクトする機能、ターゲットのインスタンスに対してセッションを維持する機能など、
Webアプリケーションに対して高度な機能が提供される。
Network Load Balancer...HTTP、HTTPS以外のTCPプロトコルを使用する場合に選択する。
Appliciation Load Balancerにはない主な機能としては、
静的なIPアドレスを使用できる点。1秒あたり数百万のリクエストを処理することができる。
Classic Load Balancer...以前のタイプのロードバランサー。
以前はALBとNLBはなかった。ELBを使うということは、CLBを使うということだった。
以前の構成との互換性のために、このタイプは残されている。
これから構築する新しい環境では、ALBかNLBを選択すれば問題ない。
★HPPT/HTTPSではALBを使い、それ以外のTCPではNLBを使う。
・ヘルスチェック：ELBは、ターゲットとしているインスタンスが正常かどうかのヘルスチェックを行い、
正常なインスタンスのみにリクエストを送るように動作する。
そうすることでユーザーが異常なインスタンスにアクセスしてしまうことを防いでいる。
ヘルスチェックは、対象として指定されたパス(index.htmlなど)への簡単な接続試行、
またはインスタンスに対してのpingで確認する。
★ELBには、正常なインスタンスのみにトラフィックを送るためのヘルスチェック機能がある。
・インターネット向け/内部向け...ELBはインターネット向けに作ることも、内部向けに作ることもできる。
作成する時にどちら向けかを選択する。
ELBを作成すると、設定したELBの名前を含んだDNS名が付与される。
このDNS名にパブリックIPアドレスが紐づくか、
プライベートIPアドレスが紐づくかの選択によって設定効果が変わる。
インターネット向けのELBのDNSにはパブリックIPアドレスが付与される。
外部からインターネット経由でアクセスできる。
内部向けのELBのDNSにはプライベートIPアドレスが付与される。
外部からのアクセスは受け付けずに内部でのアクセスを許可する。
ELBに対してのトラフィックはEC2同様に、セキュリティグループで制御することができる。
★ELBはインターネット向けにも内部向けにも対応している
★インターネット向けだけではなく内部にもELBを挟むことによって、システムの可用性をさらに高めることができる。
・高可用性のマネージドサービス...ELBを使うことでEC2の高可用性を実現できる。
では、ELB自体が単一障害点とはなり得ないか。
ELB自体が高い可用性を持つマネージドサービスのため、複数設定しておく必要はない。
例えば、複数のAZに配置するようにELBを設定しているとする。
このとき、内部的にはELBのノードと呼ばれるインスタンスが複数起動して、
ユーザーからのリクエストを受け付けて負荷分散している。
ELBを通過するトラフィックが増えれば自動的・水平的にこのELBのノードも増えてリクエストに対応する。
よって、ELBは単一障害点にはならない。
★ELB自体が高可用性のマネージドサービスなので単一障害点とはならない。
・クロスゾーン負荷分散...ALBで常に有効、NLBで有効/無効が選択できる機能に、
クロスゾーン負荷分散というものがある。
名前の通り、AZを越えて負荷分散するかどうかの設定。
有効にしていると、すべてのターゲットインスタンスに対してリクエストが送信される。
これによりリクエストの分散が均等となり、ターゲットインスタンスのリソースが無駄なく使える。
例えば2つのAZにALBを配置する。
この時、実態としてのALBのノードは各AZに配置される。
ALBのノードが存在するAZだけではなく、他のAZのターゲットインスタンスにも負荷分散ができている。
これにより全ターゲットインスタンスで負荷を均等にすることができる。
★複数のAZに負荷分散を実行できるのでリソースの負荷が均等になる
スポンサーリンク
Auto Scaling
Auto Scalingの概要
Auto Scalingを使用すると、どの時点でEC2インスタンスがいくつ必要かを予測する必要がなくなる。
必要なEC2インスタンス数が、状況や時間によって変化するシステムは珍しくない。
業務アプリケーションでは、業務時間内の利用が多く、業務時間外の利用が減るか、もしくは利用がなくなる。
コンシューマー向けのサービスでは、昼間の利用が多く、夜間の利用が減る傾向がある。
また、コンシューマー向けのサービスの場合、提供者の推測を超えた利用量が発生する場合もある。
このようなオーバーキャパシティの場合、
気づいたタイミングでインスタンスを慌てて用意しても間に合わないことがある。
その逆に、予想に反してあまり使われない場合もある。
使われていないインスタンスを起動し続けることは、無駄なコストを発生させていることになる。
Auto Scalingによって、必要なタイミングで必要なインスタンス数を柔軟に用意することができる。
需要に応じて必要なインスタンスだけが起動しているということは、
EC2インスタンスを最も効率よく使うということ。
例えばEC2インスタンスのCPU使用率が高騰することによる障害が発生しそうだとしても、
そうなる前に新しいEC2インスタンスを自動追加することができ、
CPU使用率の高騰を抑えられるので、ユーザーは意識することなく使い続けることができる。
Auto Scalingにより耐障害性、可用性も高くなる。
★Auto ScalingによってEC2インスタンスを必要な時に自動で増減できる
★Auto Scalingのメリットは、高可用性、耐障害性、コスト効率化
垂直スケーリングと水平スケーリング
Auto Scalingのように数の増減でスケーリングすることを水平スケーリングという。
また、インスタンスそのものの性能を変更してスケーリングすることを垂直スケーリングという。
垂直スケーリングではインスタンスのサイズを変更することによって、
スケールアップ/スケールダウンを行う。
垂直スケーリングの場合、システムの設計変更が発生する。
影響がないかの検証も事前に必要で、変更時にはサーバー単位での停止も発生する。
上限はインスタンスタイプの最大サイズに限定される。
水平スケーリングでは、インスタンス数を変更することによって、スケールアウト/スケールインを行う。
水平スケーリングをすることを前提としてシステムを設計するため、設計変更ではない。
変更時にシステム全体に対しての影響はない。システム停止もない。上限は理論的には無限。
水平スケーリングの方がスケールしやすいと言える。
Auto Scalingでは水平スケーリングを自動化する。
AWSには「スケーラビリティを確保する」というベストプラクティスがある。
Auto Scaling機能を使うことでこのベストプラクティスが簡単に実現できる。
★垂直スケーリングよりも水平スケーリングの方がスケーラビリティを確保しやすい
Auto Scalingの設定
Auto Scalingを実現するためには3つの要素を設定する。「何を」「どこで」「いつ」の設定。
・何を...起動設定...どのようなEC2インスタンスを起動するか
・どこで...Auto Scalingグループ...どこでEC2インスタンスを起動するか
・いつ...Auto Scalingポリシー...いつのタイミングで起動/終了するか
起動設定(何を)
起動設定では以下を設定する。
・AMI
・インスタンスタイプ
・IAMロール
・ユーザーデータ
・ストレージ
・セキュリティグループ
・キーペア
EC2インスタンスを起動するために設定した内容とほぼ同じ。
どのようなEC2インスタンスを起動するのかをあらかじめ設定しておくのが起動設定。
起動設定の他に起動テンプレートを使用することもできる。
起動テンプレートを使うことで、バージョニング機能やオンデマンド、スポットインスタンスを組み合わせるなどの
柔軟な購入オプションが利用できるようになる。
Auto Scalingグループ(どこで)
Auto Scalingグループでは以下を設定する。
・起動設定名
・AZ(サブネット)
・ELBのターゲットグループ
・最小/最大/希望するインスタンス数
・通知
・タグ
AZとVPCのサブネットを選択する。
複数のAZを選択することで、一方のAZが仮に地域災害などで使えなくなったとしてもシステムは継続することができる。Auto Scalingグループではインスタンスの最小数、最大数、そして今起動したい希望数を設定することができる。
Auto Scalingポリシー(いつ)
Auto Scalingには3つのタイプがある。
・ターゲットポリシー：Auto ScalingグループのEC2インスタンス平均CPU使用数などを決めておくことで、
AWSが自動的に最小数と最大数の間でEC2インスタンスを調整する。最も簡単な設定方法。
・シンプルポリシー：CloudWatchのアラームに基づいて、Auto Scalingアクションを実行する。
「その後待機」はクールダウンと呼ばれる機能で、Auto Scalingアクションが連続で発生し、
インスタンスが頻繁に起動/終了されることを防ぐ。
・ステップポリシー：複数段階でのインスタンスの追加、削除を設定できる。
ウォームアップは、インスタンス頻繁に追加されることを防ぐが、
クールダウンと違うところは、必要な数に満たさなければ追加される点。
さらに、Auto Scalingアクションはポリシーだけではなく、時間を指定したスケジュールも実行できる。
スケジュールを設定できる情報は、最小数、最大数、希望数。
★Auto Scalingでは、起動設定(何を)、Auto Scalingグループ(どこで)、スケーリングポリシー(いつ)を設定する。
アプリケーションデプロイの自動化
Auto Scalingの起動設定によって、スケーリングポリシーかスケジュールによってEC2インスタンスが起動する。
必要無くなればスケールインし、インスタンスは削除される。
EC2インスタンスは削除されるので、EC2インスタンスに情報や状態を持たせない設計が必要。
このようなEC2インスタンスの構成をステートレスという。
いつ起動しても、AMIを基に同じ構成のEC2インスタンスが起動するので、再現性が非常に高い。
起動しているアプリケーションのバージョンアップやプログラムの改修が発生した場合、
AMIの再構成、起動設定の再作成、Auto Scalingグループの設定変更が必要。
もし複数リージョンで同じ設定をしている場合は、各リージョンでも同じ作業が必要。
昨今ではソフトウェアのアップグレードのサイクルも非常に早く、定期的、不定期的に発生する。
これを解決する手段の1つとして、ブートストラップという設計パターンがある。
Auto Scalingによって、AMIを基に起動したインスタンスの起動時にコマンドスクリプトを実行して、
例えばソースコードを最新にする。
EC2には初回起動時に自動実行してデプロイを自動化するユーザーデータという機能がある。
もそもユーザーデータの処理の中でインスタンス固有の情報が必要な場合はメタデータを利用することもできる。
ユーザーデータ：例えばEC2インスタンスをAmazon LinuxのAMIを使って起動する。
このインスタンスはWebアプリケーションを起動するインスタンスにするよう、SSHでログインしてデプロイ作業を行う。
ここで必要なデプロイ作業は2つある。
1.最新バージョンのプログラムをダウンロードする
2.EC2インスタンスのパブリックIPアドレスを取得して設定ファイルに書き込む。
このような作業をEC2インスタンスの初回起動時に自動実行するのがユーザーデータ。
Linuxではシェルスクリプトが、Windowsではコマンド、またはPowerShellスクリプトが利用できる。
メタデータ：ユーザーデータのサンプル処理ではパブリックIPアドレスを取得するために特定のURLにアクセスしていた。
このURLにアクセスして取得できる情報がメタデータ。
EC2インスタンスにSSHログインしてコマンドを実行する時、取得できる情報が表示される。
パブリックIPアドレスやインスタンスIDなど、
EC2インスタンスが起動しないと生成されない情報を起動直後に取得することができる。
★EC2のユーザーデータを使うことでコマンドを自動実行し、デプロイ処理を自動化することができる。
★EC2の情報(IPアドレスやインスタンスID)はメタデータから取得できる。
ELBとAuto Scalingを使用したスケーラブルなWebアプリケーション
ELBのALBとAmazon CloudWatchのアラーム、
それにAuto Scalingを使ったスケーラブルなWebアプリケーションを構築する。
ALBの作成
今回構築する環境では、複数のEC2インスタンスで同じWebアプリケーションを起動する。
Webアプリケーションの入り口としてALBを作成する。
マネジメントコンソールでEC2を選択して、EC2ダッシュボード左ペインからロードバランサーを選択。
最後に[ロードバランサーの作成]をクリック。
ロードバランサーの種類はALBを選択。
[ロードバランサーの選択]では、まずロードバランサーの名前を入力。
ここで入力するロードバランサーの名前が、ロードバランサーのDNS名にも反映される。
スキームはデフォルトのインターネット向けで、リスナーもデフォルトのHTTPに設定。
AZは2つのAZに配置するよう設定。VPCは一旦デフォルト。
これでAZが地理的な災害などで万が一使えなくなったとしても、
今回構築しているアプリケーションは継続して提供することができる。
[セキュリティ設定の構成]では、SSL証明書の設定を行う。今回は検証のため、この設定は行わない。
次に[セキュリティグループの設定]。今回はあらかじめ作っておいたセキュリティグループを選択。
リスナーで設定しているポートにアクセスができればよいため、新規に作成しても大丈夫。
続いて[ルーティングの設定]。ここではターゲットとなる対象とヘルスチェックを設定する。
今回、ターゲットグループは新たに作成。
ターゲットグループに対するプロトコルはHTTPにしている。
ヘルスチェックのパスはデフォルトのままで、検証をスムーズに進めるために感覚を10秒に変更した。
[ターゲットの登録]では、ターゲットグループにEC2インスタンスを登録することができる。
今回はターゲットをAuto Scalingグループとするため、ここでは何も設定しない。
設定の確認画面で何も問題なければそのまま作成。無事ALBが作成される。
起動設定の作成
Auto Scalingでは、どのようなインスタンスを起動させるかを設定する。
EC2ダッシュボードでは、左ペインから起動設定を選択し、[起動設定の作成]をクリックする。
AMIを選択する。AMIはEC2インスタンスのテンプレート。今回はAmazon Linux 2 を選択。
インスタンスタイプを選択。今回起動するWebアプリケーションは、静的なHTMLを1ページ表示するだけ。t2.nanoでも十分だが、無料利用枠の期間内であればt2.microを選択。
起動設定の名前を入力。Auto Scalingアクションで起動されたEC2インスタンスで、Webアプリケーションを自動デプロイするために、ユーザーデータを設定しておく。
コマンドではApacheをインストール・起動して、index.htmlにEC2インスタンスが起動しているAZ、インスタンスID、パブリックIPアドレスを書き込んでいる。ブラウザからアクセスするとAZ、インスタンスID、パブリックIPアドレスが表示される。AZ、インスタンスID、パブリックIPアドレスはメタデータから取得している。
つぎにストレージを設定する。デフォルトの8Gのままとした。
セキュリティグループを設定する。ALBから80番ポートでアクセスできるように設定された、既存のセキュリティグループを選択した。
設定内容を確認して作成する。次にキーペアを選択する。ここで新たなキーペアを作成しても構わない。
無事作成完了。[この起動設定を使用してAuto Scalingグループを作成する]ボタンをクリックして、引き続きAuto Scalingグループを作成する。
Auto Scalingグループを作成
EC2インスタンスをどこで起動するかの設定となるAuto Scalingグループを作成する。
Auto Scalingグループ作成手順の中で、スケーリングポリシーも設定する。
Auto Scalingグループの名前を入力する。
開始時のインスタンス数を指定できるため、2インスタンスとした。さらにネットワークの設定。
あらかじめ設定されているVPCがあったためそれを選択。
とりあえず試すだけであれば、デフォルトのVPCとデフォルトのサブネットでも実行できる。
ただし、ALBと同じVPCにする必要がある。
画面下の[高度な設定]でALBのターゲットグループを指定。
これでALBのターゲットとしてAuto Scalingグループ内のEC2インスタンスが登録される。
ヘルスチェックのタイプは「EC2」にする。
EC2のステータスが正常かどうかでヘルスチェックを行う。
ヘルスチェックを「ELB」とすれば、ELBのヘルスチェックが失敗したときに、
Auto ScalingからEC2インスタンスをデタッチさせて終了させることもできる。今回は「EC2」としておく。
Auto Scalingポリシーを作成する。
最小数を「2」、最大数を「10」に変更。今回はステップポリシーを使用。
まずスケールアウトのためのアラーム設定。
Auto ScalingのEC2インスタンス平均CPU使用率60%以上を閾値として、アラームを設定。
この設定はAuto Scalingグループの一連の設定の中で行うが、アラームはCloudWatchに作成される。
スケールアウトするアクションでは、2段階の追加アクションを設定した。
Auto ScalingのEC2インスタンス平均CPU使用率60%から80%の中で1インスタンスの追加、
80%で2インスタンスの追加とした。
次はスケールインするためのアラームを設定。
Auto ScalingのEC2インスタンス平均CPU使用率40%以下を閾値とした。
スケールインするアクションでも、2段階の削除アクションを設定。
Auto ScalingのEC2インスタンス平均CPU使用率20%から40%の間で1インスタンスの削除、
20%以下で2インスタンスの削除とした。
Auto Scalingアクション実行時に通知することが可能。今回は設定せずに次に進む。
Auto Scalingグループそのものと、Auto Scalingによって起動したインスタンスにタグをつけることができる。
EC2ダッシュボードで見分けがつきやすいように、「Name」キーに「DemoASG」と設定した。
設定を確認して作成する。無事作成できたら一連の設定は完了。
動作確認
EC2インスタンスの一覧を見ると、
DemoASGのタグがついたEC2インスタンスが2つのAZで1つずつ起動していることが確認できる。
ELBのターゲットグループを見ると、2つのインスタンスが「healthy」ステータスになっていることが確認できる。
Auto Scalingグループを見ると、インスタンス数が「2」になっている。
そして、ターゲットグループ同様に2つのインスタンスが「Healthy」ヘルスステータスになっていることが確認できる。
ELBのDNS名をコピーして、ブラウザのURLにアクセスしてみる。
すると、EC2インスタンスにアクセスでき、AZ、インスタンスIP、パブリックIPアドレスが表示される。
ブラウザ画面を更新するともう1つのインスタンスにリクエストが送信されて、
AZ、インスタンスID、パブリックIPアドレスが変わったことが確認できる。
つまり、負荷分散もちゃんとされている。
CloudWatchのアラームも確認。2つのアラームが作成されている。
CPU使用率40%以下のアラームが「アラーム」の状態。
現在EC2インスタンスは最小台数の2つのため、削除アクションは実行されない。
そこで負荷をかけてみる。
Auto Scalingで起動している2つのEC2インスタンスそれぞれにSSHでログインし、次のコマンドで負荷をかけた。
yes > /dev/null
CloudWatchのメトリクスを見てみると、CPU使用率が上がっている。
CloudWatchのアラームを見ると、CPU使用率60%以上のアラームが「アラーム」状態になった。
Auto Scalingグループを見ると、希望するインスタンス数とインスタンス数が「3」になっている。
実際に起動しているインスタンスも3になっている。
このままにしていたところ、平均CPU使用率が80%を超えた。
さらに2インスタンス追加のオートスケールアクションが実行されて、EC2インスタンスは5になった。
負荷をかけているプロセスはLinuxのtopコマンドで判別できる。このプロセスをkillコマンドで停止する。
すると平均CPU使用率が下がる。
スケールインアクションによりEC2インスタンスが削除されたことを確認できる。
★ELB、CloudWatch、Auto Scalingの3つのサービスで、自動的でスケーラブルなアプリケーションを構築できる。
Lambda
AWS Lambdaは、ソースコードさえ用意すれば、そのプログラムを実行することができるサービス。
プログラムを実行するための環境構築を行う必要も管理する必要もない。
開発者はサーバーの管理やメンテナンスから解放され、プログラム開発に注力することができる。
Lambdaの特徴
Lambdaの特徴としてはいかが挙げられる。
・サーバーの構築が不要
・サーバーの管理が不要
・一般的な言語のサポート
・並行処理/スケーリング
・柔軟なリソース設定
・ミリ秒単位の無駄のない課金
・他のAWSサービスとの連携
サーバーの構築が不要
Lambdaでプログラムを実行するのは非常に簡単。
実行したいプログラムのランタイムを選択してソースコードをアップロードすれば、もう実行できる。
これまでのように、OSの用意、実行するためのミドルウェアのインストール、環境設定など、
本来注力する必要のない作業を行わなくてよくなる。
Lambdaをマネジメントコンソールから作成する場合、
名前を決め、ランタイムを選択し、権限をIAMロールから選択したら、あとはソースコードをアップロードするだけ。
★サーバー構築や環境の準備をすることなく、すぐに開発を始められる
サーバーの管理が不要
Lambdaを使用すれば、以下のようなサーバーの管理が不要。
より良いプログラムコードを開発することに集中できる。
・OSの更新
・セキュリティパッチの適用
・ディスク容量の追加
・OS、ミドルウェアのメンテナンス
・冗長化、障害の復旧
・スケーラビリティの確保
・障害を考慮した設計
・実行エラー時のリトライ
・ジョブが特定時間に集中することへの考慮
★サーバーの運用から解放され、開発に注力できる
一般的な言語のサポート
Lambdaを使うために、特定の言語を改めて勉強する必要はない。以下の言語でコードを実行することができる。
・C#
・PowerShell
・Go
・Java
・Node.js
・Python
・Ruby
これらの言語の中に使えるものがあれば、そのコードを書くだけでLambdaを使える。
2015年にLambdaが発表されたときにはJavaとNode.jsのみのサポートだったが、現在はこれほどまでに増えている。
この言語のサポートの推移から考えると、対象言語はこれからも増えていくことが予想される。
★Lambdaを使うために新しい言語の勉強は不要。使い慣れた言語ですぐに始められる
並行処理/スケーリング
Lambdaは、リクエストやトリガーからの実行指示がないときは実行されない。
従来のサーバーのようにリクエストを待っている間に稼働し続けておく必要がない。
リクエストやトリガーによってコードが実行される、もし2つのリクエストが同時に発生した場合は、
2つのLambda関数が同時に実行される。
リクエストの数が増えれば、実行されるLambda関数の数も増えていく。
Auto Scalingの設定をしなくても、Lambdaでは、自動的にスケーラビリティが確保されているということ。
初期設定では、アカウント全体で同時実行数1000という制限はある。
これ以上の実行数が必要な場合は、同時実行数の制限引き上げをリクエストすることができる。
また、関数ごとに同時実行数の上限を決めておくこともできる。
★リクエストに応じて水平的にスケーリングして、並行で関数が実行される
★Auto Scalingを設定する必要がない
柔軟なリソース設定
Lambdaを設定する性能はメモリ。
設定できる範囲は128MBから3008MBの間で、64MB刻みで設定できる。
CPU性能はメモリに比例して割り当てられる。メモリの設定が課金に影響する。
タイムアウト時間は最長で15分で設定することができる。
Lambdaで実行できる処理は15分までということになる。
この15分が制限となり問題となるのであれば、もしかすると15分で終わらない処理そのものに問題がある可能性もある。
★メモリを割り当てることで他のリソースの性能も割り当てられる。
ミリ秒単位の無駄のない課金
月間合計が400,000GB-秒となるまでは無料。
また、リクエスト数に対しても課金されるが、これも月間100万リクエストまでは無料。
実行結果を確認しながら、最も早く当該処理が終わるメモリを割り当てることが、最もパフォーマンス効率の良い設定。
★実行されている時間に対してミリ秒単位の無題のない課金がなされる
★実行されていない待機時間には課金されない
他のAWSサービスとの連携
Lambdaは、たとえば以下のようなイベントをトリガーとして実行される。
・特定の時間になったとき(CloudWatch Events)
・S3にデータがアップロードされたとき
・DynamoDBに新しいアイテムが書き込まれたとき
・Auto Scalingアクションが実行されたとき
・Webページでボタンが押されたとき
・Kinesisにレコードが追加されたとき(Kinesisではリアルタイムなデータストリーミングを処理する)
・「Alexa、〇〇について教えて」と言ったとき
様々なAWSサービスがトリガーとして用意されているので、
それらを組み合わせることで簡単にAWSのサービスとサービスとを繋げることができる。
Lambdaでは、使用できる言語のSDKが、ランタイムを選択することにより実行環境に用意される。
SDKを使用すると、AWSサービスの操作を数行のコードで自動化できる。
LambdaでSDKに対応するコードを書けば、
AWSサービスのイベントをトリガーにして他のAWSサービスの処理を行うことが簡単にできる。
Lambdaのモニタリングでは、CloudWatchのメトリクスやLogs、X-Ray(マイクロサービスのエラーなどの検出サービス)
で行う。
Lambdaを使用することで、
サーバーレスアーキテクチャ(サーバーの準備・管理を必要としない設計)を構築することができる。
ソースコードはAWS CodeCommitなどのリポジトリでバージョン管理できる。
★AWSサービスの処理を簡単に自動化できる
★AWSサービスからのトリガーを使用することで、イベントからLambdaを実行できる
スポンサーリンク
その他のコンピューティングサービス
その他のコンピューティングサービスは以下のものが挙げられる。
ECS：「Amazon Elastic Container Seivice」の略。コンテナ管理を行うマネージドサービス
Lightsail：Amazon Lightsailは、AWSが提供する仮想プライベートサーバー
Batch：AWS Batchは、フルマネージド型のバッチ処理実行環境サービス
まとめ
EC2
・必要なときに必要なだけのEC2インスタンスを使用できる
・必要なEC2インスタンスの数を予測する必要はない
・運用を開始した後に柔軟に性能を変更できる
・必要なEC2インスタンスの性能を予測する必要はない
・使った分だけ時間単位/秒単位の料金が発生する
・アウト通信に転送料金が発生する
・数分でEC2を世界中に起動できる
・AMIから同じ構成のEC2インスタンスを何台でも起動できる
・EC2インスタンスへのトラフィックはセキュリティグループのインバウンド(受信)で制御する
・OSの管理者はキーペアで安全にログインし、root権限、Administer権限を持つ
・ユースケースに応じて料金オプションを使い分けることでコスト効率が向上する
ELB
・EC2インスタンスの可用性を高めるためにELBを使用することができる
・HTTP/HTTPSではALBを使い、それ以外のTCPではNLBを使う
・ELBには、正常なインスタンスのみにトラフィックを送るためのヘルスチェック機能がある
・ELBはインターネット向けにも内部向けにも対応している
・インターネット向けだけではなく内部にもELBを挟むことによって、システムの可用性を高めることができる
・ELB自体が高可用性のマネージドサービスなので、単一障害点とはならない
・複数のAZに負荷分散を実行できるのでリソースの負荷が均等になる
Auto Scaling
・Auto ScalingによってEC2インスタンスを必要なときに自動で増減できる
・Auto Scalingのメリットは、高可用性、耐障害性、コスト効率化
・垂直スケーリングよりも水平スケーリングの方がスケーラビリティを確保しやすい
・Auto Scalingでは起動設定(何を)、Auto Scalingグループ(どこで)、スケーリングポリシー(いつ)を設定する
・EC2のユーザーデータを使うことでコマンドを自動実行しデプロイ処理を自動化することができる
・EC2の情報(IPアドレスやインスタンスID)はメタデータから取得できる
・ELB、CloudWatch、Auto Scalingの3つのサービスで、自動的でスケーラブルなアプリケーションを構築できる
Lambda
・サーバー構築や環境の準備をすることなく、すぐに開発を始められる
・サーバーの運用から解放され、開発に注力できる
・Lambdaを使うために新しい言語の勉強は不要。すぐに始められる
・メモリを割り当てることで他のリソースの性能も割り当てられる
・リクエストに応じて水平的にスケーリングして並行で関数が実行される
・Auto Scalingを設定する必要がない
・実行されている時間に対してミリ秒単位の無駄のない課金がなされる
・実行されていない待機時間には課金されない
・AWSサービスの処理を簡単に自動化できる
・AWSサービスからのトリガーを使用することで、イベントからLambdaを実行できる
