はじめに
「AWS Cloud Practitioner について勉強してわからないことをまとめた ~モジュール１~」の続きです。
僕自身が学んでいて不明だった箇所を纏めておきました。
ぜひともこれから学ぶ方への参考になればとおもいます。
参考：AWS Cloud Practitioner Essentials(Japanese)
Amazon Elastic Compute Cloud (Amazon EC2)
サイズ変更可能で安全なコンピュティングキャパシティーを Amazon EC2 インスタンスとしてクラウド内で提供する。
従来のオンプレミスのリソース
- ハードウェアを購入するために先行投資する。
- サーバーが届くのを待つ。
- サーバーを物理データセンターに設置する。
- ウェブサイトの公開に必要な設定を行う。
Amazon EC2 インスタンスを利用した場合
- Amazon EC2 インスタンスは数分以内にプロビジョニング、作成できる。
プロビジョニング
必要に応じてネットワークやコンピュータの設備などのリソースを提供できるよう予測し、準備しておくこと。供給や設備などの意味を表すプロビジョン(provison)という単語がもととなって派生した言葉。
- ワークロードの実行が終了したら、使用を停止できる。
- 料金は、インスタンスの実行時に使用したコンピューティング時間に対してのみ支払い。停止時や終了時に料金は発生しない。
- 必要なサーバー容量に対してのみ支払うことでコストを節約できる。
Amazon EC2 インスタンスタイプ
ワークロードやアプリケーション固有のニーズを考慮。
コンピューティング、メモリ、ストレージの機能要件も含まれる。
汎用インスタンス
コンピューティング、メモリ、ネットワークのリソースをバランスよく提供する。
以下のようなさまざまなワークロードに使用できる。
- アプリケーションサーバー
- ゲームサーバー
- エンタープライズアプリケーションのバックエンドサーバー
- 小規模および中規模のデータベース
コンピューティング最適化インスタンス
高パフォーマンスプロセッサの恩恵を受けることができるアプリケーションに最適。
高性能のウェブサーバー、計算負荷の高いアプリケーションサーバー、専用のゲームサーバーに最適。
1つのグループで多くのトランザクションを処理する必要があるバッチ処理ワークロードに使用することもできる。
メモリ最適化インスタンス
メモリ内にロードした大規模なデータセットを処理するワークロードに対して、高速なパフォーマンスを実現するように設計されている。
メモリは一時的なストレージ領域です。中央演算装置 (CPU) がアクションを完了するために必要なすべてのデータと命令を保持します。コンピュータプログラムやアプリケーションは、ストレージからメモリにロードされた後に実行可能となります。このプリロードプロセスによって、CPU からコンピュータプログラムへの直接アクセスが可能になります。
プリロード
先取り、先読み、などの意味をもつ。
この先必要になるデータなどを予め読み込んでおき、読み込みにかかる時間を短縮する仕組みのこと
高速コンピューティングインスタンス
ハードウェアアクセラレーターやコプロセッサーを使用して、一部の機能を CPU で実行中のソフトウェアよりも効率的に実行します。こうした機能には、浮動小数点数計算、グラフィックス処理、データパターン照合などがあります。
コンピューティングにおいて、ハードウェアアクセラレーターは、データ処理を高速化できるコンポーネントです。高速コンピューティングインスタンスは、グラフィックアプリケーション、ゲームストリーミング、アプリケーションストリーミングなどのワークロードに最適です。
ハードウェアアクセラレーター
なんらかの機能を通常の汎用プロセッサ (CPU) 上で動作するソフトウェア（コンピュータ・プログラム）による実装で処理したのではレイテンシやスループットが遅い、消費電力が大きい、などといった問題があるような場合に、ハードウェア実装による支援で実行速度などを加速（アクセラレーション）し、システム全体の性能や効率を向上させる技術である。
引用： wikipedia
ストレージ最適化インスタンス
ローカルストレージの大規模なデータセットに対する高速シーケンシャル読み取りおよび、書き込みのアクセスを必要とするワークロード用に設計されている。
Amazon EC2 の料金
Amazon EC2では使用したコンピューティング時間に対してのみ料金が発生する。
オンデマンド
中断できない不規則で短期的なワークロードに最適。
初期費用や最低料金は発生しない。
ユーザーがインスタンスを停止するまで、インスタンスは継続的に実行される。
ユースケースの例には、
アプリケーションの開発とテスト、使用パターンが予測不可能なアプリケーションの実行などがあります。ワークロードを１年以上実行し続ける場合、オンデマンドインスタンスは推奨されません。そのようなワークロードにはリザーブドインスタンスを使用することで大幅にコストを削減できるため。
Amazon EC2 Savings Plans
一定のコンピューティング使用量を１年または３年の期間で契約することにより、コンピューティング料金を削減できる。期間をコミットすることにより、オンデマンドの料金に比べて料金を７２％節約できる。
リザーブドインスタンス
オンデマンドインスタンスの利用に適用される割引。
スタンダードリザーブドインスタントとコンバーティブルリザーブドインスタンスは１年または３年の契約で購入でき、スケジュールされたリザーブドインスタンスは１年契約で購入できる、３年のオプションの場合、コストを大幅に削減できる。
スポットインスタンス
開始時刻と終了時刻が定まっていないワークロードや、中断可能なワークロードに最適。
スポットインスタンスでは、未使用のAmazon EC2コンピューティングキャパシティーを使用することにより、オンデマンドの料金と比較してコストを最大９０％削減できます。
Dedicated Hosts
お客様専用の、Amazon EC2インスタンスキャパシティーを備えた物理サーバーです。
ソケット単位、コア単位、またはVM単位の既存のソフトウェア・ライセンスを使用して、ライセンス要件を満たすことができる。
もっとも高価なオプション。
Amazon EC2 のスケーリング
スケーラビリティ
変化する需要に応じて自動的にスケールアウトまたはスケールインするアーキテクチャを設計できる。そのため、実際に使用したリソースに対してのみ料金が発生する。お客様のニーズを満たすためのコンピューティングキャパシティーの不足そ心配する必要はない。
Amazon EC2 Auto Scaling
Amazon EC2 Auto Scaling を使用すると、アプリケーションの需要の変化に応じて EC2インスタンスを自動的に作成または削除することができる。
必要に応じてEC2インスタンスを自動的にスケールインおよびスケールアウトすることにより、アプリケーションの可用性を更に高めることができる。
Amazon EC2 Auto Scalingには、動的スケーリングと予測スケーリングの２つのスケーリング方法が用意されている。
- 動的スケーリングは変化する需要に対応する
- 予測スケーリングは予測された需要に基づいて、適切な数のEC2インスタンスを自動的に用意する。
Elastic Load Balancing を使用してトラフィックを転送する
アプリケーションへのトラフィックを、EC2インスタンスなどのリソースへ自動的に分散するAWSのサービス。
::: note
トラフィック
通信の分野におけるトラフィックとは、インターネットやLANなどのコンピュータなどの通信回線において、一定時間内にネットワーク上で転送されるデータ量のことを意味する
:::
メッセージングとキューイング
モノリシックアプリケーションとマイクロサービス
アプリケーションは複数のコンポーネントで構成されている。
コンポーネントはアプリケーションが継続的に実行するために、相互に通信してデータを送信し、リクエストを処理する。
コンポーネント同士が密結合になったアプリケーションがあるとします。
これらのコンポーネントには、データベース、サーバー、ユーザーインターフェイス、ビジネスロジックなどがある。このようなアーキテクチャはモノリシックアプリケーションと呼ばれる。
モノリシックアプリケーションは１つのコンポーネントで障害が発生すると、ほかのコンポーネントでも障害が発生し、場合によってはアプリケーション全体で障害が発生する。
マイクロサービスのアプローチを利用することで１つのコンポーネントで障害が発生してもアプリケーションの可用性を維持することができる。
マイクロサービスのアプローチでは、アプリケーションのコンポーネントが疎結合される。
１つのコンポーネントで障害が発生しても、コンポーネントは相互に通信する関係のため、他のコンポーネントは引き続き機能する。
AWS でアプリケーションを設計する場合、さまざまな機能を実行するサービスやコンポーネントを使用して、マイクロサービスのアプローチを取ることができます。Amazon Simple Notification Service (Amazon SNS) と Amazon Simple Queue Service (Amazon SQS) の 2 つのサービスによって、アプリケーションの疎結合化が容易に実現できる。
Amazon Simple Notification Service(Amazon SNS)
Pub/Subサービス。パブリッシャーはAmazon SNS トピックを使用して、サブスクライバーにメッセージを発行できる。
Amazon SNSの場合、サブスクライバーとなるのはウェブサーバー、Eメールアドレス、AWS Lambda関数など。
Amazon Simple Queue Service(Amazon SQS)
メッセージキューイングサービス
ソフトウェアコンポーネント間でメッセージを送信、保存、受信できる。メッセージが失われることはない。Amazon SQS ではアプリケーションからキューにメッセージを送信する。ユーザーはまたはサービスは、キューからメッセージを受信して処理した後、キューからメッセージを削除する。
キュー（queue）
データ構造の一つ（データを格納する入れ物）で、入ってきたデータを順番に格納して、先に格納したデータから順に取り出す。
先入れ先出しのデータ構造。
その他のコンピューティングサービス
サーバーレスコンピューティング
「サーバーレス」とは、コードはサーバー上で実行されますが、サーバーのプロビジョニングや管理を行う必要なありません。
サーバーレスコンピューティングのもう１つの利点がサーバーレスアプリケーションが自動的にスケールされるという柔軟性。
サーバーレスコンピューティング向けのAWSサービスは AWS Lambda。
AWS Lambda
サーバーのプロビジョニングや管理を行うことなく、コードを実行できるサービス。
AWS Lambdaは使用したコンピューティング時間に対してのみ料金が発生する。
課金されるのはコードが実行されているときのみ。ほぼすべての種類のアプリケーションやバックエンドサービスのコードをを管理作業を行うことなく実行できる。
AWSでは、コンテナ化されたアプリケーションを構築して実行することもできる。
コンテナ
アプリケーションのコードや依存関係を１つのオブジェクトにパッケージ化する技術。
セキュリティ、信頼性、スケーラビリティに関する必須要件があるプロセスやワークフローに使用することができる。
Amazon Elastic Container Service(Amazon ECS)
スケーラビリティとパフォーマンスに優れたコンテナ管理システム。
このシステムを使用することでコンテナ化されたアプリケーションをAWSで実行及びスケールできる。
Amazon ECSではDockerコンテナをサポートしている。
Amazon Elastic Kubernetes Service(Amazon EKS)
AWSでKubernetesを実行できるフルマネージドサービス。
フルマネージドサービス
マネージドサービスで提供している内容に加えて、より細やかな監視、障害対応または運用代行サービスを提供しているサービスのこと。
本来であればオプションとして別に請求されるようなセキュリティ監視や24時間365日の障害対応もサービスに含まれている。
Kubernetes
コンテナ化されたアプリケーションを大規模にデプロイして管理できるオープンソースソフトウェア。
ボランティアによる大規模なコミュニティによって管理されており、AWSはKubernetesコミュニティと積極的に連携している。
AWS Fargate
コンテナ向けのサーバーレスコンピューティングエンジン。
Amazon ECSとAmazon EKSの両方を利用できる。
サーバーのプロビジョニングや管理を行う必要はありません。
サーバーインフラストラクチャはAWS Fargateによって管理される。
料金は、コンテナの実行に必要なリソースに対してのみ発生する。
注意
自己学習のために割愛している部分があるので
公式も合わせてご確認ください。
AWS Cloud Practitioner Essentials(Japanese)