AWS Cloud Practitioner Essential まとめ

AWS Cloud Practitiner Essential 殴りがき

クラウドコンピューティング

• メリット
  • 他の人と1台のOSのリソースをシェアすることによって、必要コストを下げて提供することができる
  • 使いたい時にすぐに使える
  • 使わなくなったらすぐに削除できるため、オーバーコストが発生しない

EC2

• EC2とは

  • サーバーをクラウドとして提供する
    • つまり、物理サーバーを保有することなく、自分のサービスを提供できる

• メリット

  • 使いたい時にすぐに使える(設定を選択するだけ)
  • 用事が済めば、使用を停止することで、それ以上の料金が掛からなくなる(使っていた時間に対してのみの支払いとなる)
  • コストを節約できる。
    • (物理サーバー)は、保有コストがかかる上、使用する前に大きく投資することとなるため、実際の使用量を越したコストが必要となる
    • EC2は使いたい時だけ。

• EC2の仕組み

  1. 作成
     • 基本設定を含むテンプレートの選択
       • 基本設定　= OS,アプリケーション、インスタンスタイプ(スペック)
     • ネットワークの設定 = 通信制御・セキュリティ設定
  2. 接続
     • プログラム・アプリケーションから直接接続(SDKやAPIかな?)
     • EC2インスタンスにログインしてアクセス
  3. 使用
     • 普通のPCと同じように使いたいように使える
       • 使いたいソフトウェアのインストール
       • ストレージの追加
       • ファイルのコピーや整理 など。。　

• EC2インスタンスタイプ

  • CPU,メモリ、ストレージ、ネットワーク の性能の組み合わせ
    • 作業負荷(=ワークロード)やアプリケーション固有のニーズを考慮して選択する
  • インスタンスファミリー
    • 汎用
      • コンピューティング、メモリ、ネットワークそれぞれのリソースが同じくらい必要な時に使う
      • それぞれどのリソース領域でも最適化を必要としないため
      • ウェブサーバー・アプリケーションサーバー・コードリポジトリとして使われる。
      • 多様なワークロードに適したバランス型
    • コンピューティング最適化
      • ゲームサーバー(※　ゲームをプレイする側ではなく提供する側)・ハイパフォーマンスコンピューティング(HPC)・化学モデリングなどに使われる -　コンピューティング負荷(CPU負荷)の高いタスク -　バッチ処理
    • メモリ最適化
      • 大量のメモリを必要とするワークロードに向いている
      • メモリはCPUがアクションするために必要な全てのデータと全ての命令を持っている。
      • アプリケーションは、ストレージからメモリにロードされたのちに実行可能となる。
      • メモリ内にロードした大規模なデータを処理するのに向いている
      • メモリ負荷の高いタスク
      • 高パフォーマンスデータベースに最適
        • DBのデータはアプリから読み込まれるために使われる。つまり、メモリから読み込まれる。
    • 高速コンピューティング
      • グラフィック処理・データパターンマッチング・浮動小数点の計算・ハードウェアアクセラレータ等
      • 高パフォーマンスプロセッサの提供
    • ストレージ最適化
      • ローカルに保存されたデータをハイパフォーマンスで処理する
      • IOPS(input/output operation per second) =　1秒間に実行できる入出力操作の回数はストレージ最適化に依存する。
      • 分散ファイルシステム・データウェアハウジングアプリケーション　、オンライントランザクション処理などに向いている
      • デーファウェアハウジングアプリケーションに最適
      • データウェアハウスとは、データを業務で使用するだけではなく、その開発者チームの知識として、意思決定などに役立てるようにして使われること。データは基本的にストレージにあるものなので、ストレージにあるデータをうまく使う(データウェアハウスを使いこなす)にはストレージ最適化が適切

EC2 料金体制

1. オンデマンド = 起動時間単位の支払い契約となる。
   • 一年以上継続して実行し続ける場合は向いていない。⇨　リザーブどインスタンスなどを使うことでコスト削減できる

2. Savings Plans = 1時間あたりの使用量を契約することで固定料金として支払うことができる。

   • 一時間あたりの使用量上限が指定されている？
   • 1年 or 3年の期間で契約することでコスト削減できる。
   • 契約した使用量を超えなければ(一時間単位など)、割引が適用された料金で使用できる
   • 契約した使用量を超えた場合、超えた分だけオンデマンド料金で支払う
   • 契約期間を超えて実行することはできない？

3. リザーブド インスタンス = 使用量が一定 or 予想可能な際に適している。

   • 全額前払い。一部前払い。前払いなし
   • オンデマンドインスタンスの割引体系。
   • 1年 or 3年の契約。
   • 契約期間が終了しても、EC2インスタンスは停止されず実行できる。
   • 契約期間終了後も使用する場合、オンデマンド料金で支払う.
     • (インスタンスを削除 or 新しいリザーブドインスタンスを購入 をしない限りオンデマンド料金が継続される)

4. スポット インスタンス = 予備として確保されているEC2を利用できる。

   • AWSがEC2要領を必要とした場合、すぐに(2分前)に連絡がくる。
   • 実行するワークが中断可能でないと使えない
   • リクエストを行い、HOSTのキャパがない場合はリクエスト失敗。　⇨　EC2を利用できない。
   • リクエストを行い、HOSTのキャパがある場合はリクエスト成功。

5. Dedicated Hosts = 自分のEC2インスタンスのために物理ホストを占領する。

   • Dedicated Hosts　以外では、一台の物理Hostsを仮想的に分割して、いろいろな人が使うEC2を確保する
   • EC2で一番高い料金体制。

EC2 Auto Scaling

※ Auto Scaling自体は無料。ただし、実行インスタンスがスケーリングされるため、その数に応じてEC2料金が変わる。

• スケールアップ
  • インスタンスの能力を強化する。
• スケールアウト
  • ニーズに合わせて台数を増やすこと
• スケールイン
  • ニーズに合わせて台数を減らすこと

2つの方法

• 動的スケーリング
  • 変化する需要に対応。後手で対応する。
• 予測スケーリング
  • 予測された需要に基づいて対応。 先手で対応する。

※　どちらも同時に使える

スケーリングの設定

• 最小キャパシティー
  • スケールインによって減らせる最小の数(設定できる最小は1)
  • Auto Scaling適用後すぐに作成されるインスタンスの数
• 必要キャパシティー
  • 通常はこの数で運用されることを想定してる？
  • スケールイン・スケールアウトされていない状態の設定数
  • 何も設定していない時は最小キャパシティーと同じ数になる
• 最大キャパシティー
  • スケールアウトによって増やせる最大の数

ELB (Elastic Load Balancing)

リクエストを受け付け、リクエストを処理するインスタンスにルーティングする。
ELBはリージョンごとに稼働する。

1. ELBが一貫してリクエストを受け取る
2. それぞれのインスタンスに割り振る
3. ELBはEC2インスタンスがスケールアウト(auto scaling)された際、新しく作られたインスタンスから通知を受け取る
4. 作成されたインスタンスにリクエストを割り振れるようになる
5. スケールアップされた際は、インスタンスが終了するまでにリクエストを送らなくなる。
   1. ただし、EC2は既に送られてきたリクエストを処理し終わるまでは終了しない。
6. インスタンスのurlは一つ。ELBがリクエストを仲介することになるため、リクエストを送る側は、インスタンスの数を気にすることはない。

メッセージングとキューイング

メッセージング(=　キューイング) とは、サービス間でデータをやり取りする際、一方のサービスが機能不能となっても、その間のリクエストが失われないように、バッファ(メッセージキューと呼ばれる)を間に挟み、そこでデータを一時的に保存しておくこと。
配列のキューと同じイメージ。送信側のサービスは、送信先のサービスの状態に依存せず、各サービスの状態に依存することなくリクエストができる。

SQSとSNSの使うことで、各サービスを疎結合することが可能。
サービス間(A2A) or サービスtoユーザーでメッセージを送ることができる

Amazon SQS(Simple Queue Service)

二つのサービス間に設置する。いくらでもメッセージ(リクエスト)の送信、保存、受信ができる。
※　メッセージを喪失することはない。 = 処理されるまでデータは保存される。

• メッセージを送信する
• メッセージを保存する
• メッセージを受信する
• ソフトウェアコンポーネント間
• 任意のボリューム

Amazon SNS(Simple Notification Service)

SQSの各機能 + サービスへ通知を送信する or エンドユーザへの通知が可能。
pubsubモデル。

サーバーレス

EC2は、新しいソフトウェアパッケージがリリースされるたびに、それを適用することが必要。
サーバーを管理しながら使わないといけない。

そこで、サーバーレスを使う。
サーバーレスとは、基盤・サーバー管理を意識しない。プロビジョニング・スケーリング(Auto Scaling)、高可用性の確保(マイクロサービス, メッセージングキュー)などを設計しないで使える。
サーバーレスでは、サーバーの維持を考慮することなく、サービス開発に集中できる

AWS Lambda

1. 開発したコードをLamdaにアップロードして、Lamda関数として使用する。
2. トリガーを用意して、トリガーが呼び出されるまではLambda関数は待機してる
3. トリガーが呼び出されると、開発したコードがLambda環境上で実行される
4. ただし、1つのリクエストに対しての処理 = コードの実行時間が15分未満である必要がある。
   1. ディープラーニングは不適切。
   2. Webサービスのバックエンドは適切。
5. 支払いはコンピューティングに使用した時間に対してのみ発生する

コンテナオーケストレーションツール

• Dockerコンテナの構築・運用などの自動化ツール
• コンテナとは、アプリケーションの実行に必要な構成・設定(実行バージョンなど)をパッケージ化している
• コンテナが構築されるホストはEC2インスタンス

ECS

• 各コンテナの実行・停止などをする
  • コンテナ内には、複数のアプリケーションがある。アプリのバージョンはコンテナによって維持されている。
  • clusterと呼ばれる、コンテナの名前？(実行アプリケーションの集合体)があり、それを実行・停止する
  • 複数のEC2をまとめて実行できる。
    • クラスター設定をして、クラスターを起動すると、複数のEC2インスタンスが生成されるイメージ
  • EC2はアプリケーション1つずつ。
  • 自分達でEC2の管理をしないといけない。

EKS

• よくわからん。詳細は今度。
• 自分達でEC2の管理をしないといけない。

AWS Fargate

• ECS,EKS用のサーバーレスコンピューティングプラットフォーム。
• ECS,EKS実行時には、EC2インスタンスが生成され、自分でサーバーの管理をしないといけないが、基盤・サーバー管理を意識したくない場合は　AWS Fargateを使う。
• ECS,EKSのコンテナのインスタンスにEC2を使いたくない場合に使う。