AWS勉強 振り返りまとめ (2)

AWS ソリューションアーキテクト アソシエイト受験に向けて取り組んできた勉強において、
振り返っておくと良さそうな部分をまとめてみました (その2)
同じように AWS の勉強をしている方の参考になれば嬉しいです

前はこれ AWS勉強 振り返りまとめ (1)

Load Balancing 系

• 静的/動的なスケーリング
  • 静的 : desired-capacity が固定
  • 動的 : desired-capacity が可変 = Auto Scaling (それはそう)
• ステップスケーリングポリシー
  • CloudWatch から取得できるメトリクスの値に応じて増やす台数を調整できる。
  • e.g. cpu 使用率 60% => 1台, ~ 70% => 2, ~ 80% => 3
• ELBのターゲットグループを設定すれば、ELB構成を利用してELBのヘルスチェックによりAutoScalingを実行することができる。
  • ELB の実態がなくても、Auto Scaling の機能は使える。
• ASG の Termination Policy のデフォルト設定は、OldestLaunchConfiguration からClosestToNextInstanceHour の順番に適用される。
  • OldestLaunchConfiguration : 使用されている Launch Template の古い順
  • ClosestToNextInstanceHour : 追加課金が発生するタイミングが早い順
• RDS はインスタンスタイプの縮小はできるが、ストレージサイズの縮小はできない (拡張のみ)。

ElactiCache

• タイプ別特徴

  タイプ	スレッド	スナップショット機能	データの永続化	ユースケース
  Redis	シングルスレッド	あり	可能	複雑なデータの処理や分析処理、機械学習など
  Memcached	マルチスレッド	なし	不可能	シンプルなデータのオーケストレーション(管理の自動化)

Cloudfront

• リクエストヘッダーに Accept-Encoding:gzip が指定されており、オリジンサーバ (S3 など) が gzip に対応していない場合、Cloudfront のエッジロケーションにて gzip 圧縮を行い配信が可能。

SQS

• Pull / P2P なメッセージングサービス。
• ユースケース
  • 大量リクエストのバッファリング
  • ワークキューとしてアプリケーション間の依存関係を弱める。
    • プロデューサー(メッセージを送る側)とコンシューマ(受け取る側)が双方の稼働状況(メンテナスなど)の影響を受けにくい。
  • リクエストのオフロード
    • 軽い処理をプロデューサーが応答し、重い処理はキューに積んでコンシューマーに対応させる。
  • ターゲットのファンアウト(一括送信)
    • SNS と組み合わせることで、1つのメッセージ送信で並列化が可能になる。
    • SNS を使用しない場合は、プロデューサー側で並列化の制御をする必要がある。
• 単発のメッセージではなく、関連する複数のメッセージを処理する場合は Kinesis を使う。
  • e.g. 映像データ, 1台のデバイスから発生するログの解析

SNS

• Push / Pub-Sub なメッセージングサービス
  • Pub-Sub : Publisher(発行者) と Subscriber(購読者) との間に Topic (所有者) がある。
• ロール
  • Topic Owner : Topic を作成
  • Subscriber : 購読する Topic を選択
  • Publisher : Topic へ向けて Message を送信
• SNS のエンドポイントとして Lambda を指定することで、他のAWSリソースを Subscriber のように扱うことができる。
• 配信の順序
  • 基本的には Topic に対して発行された順序で、Publisher からの Message を配信するようになっているが、ネットワーク上の問題により、結果的に Subscriber 側に Message の順番が入れ替わって届く可能性もある。
  • 対して SQS はキューのタイプを FIFO キューにすることで、発行と配信の順序付けを行うことができる。

Lambda

• Lambda の課金は 100 ミリ秒単位の実行時間から換算される。
• 実行に関わるパーミッション
  • Execution : LambdaがS3やDynamoDBなどのAWSリソースから実行できる許可設定を行う。
  • Invocation : Lamdba を外部リソースから実行できる許可設定を行う。
• ポーリングベースのイベントソース
  • ストリームベース : DynamoDB, Kinesis Data Stream
  • 非ストリームベース : S3
• ユースケース
  • モバイル・API関連
    • Webアプリのモバイルバックエンド
    • データ配信APIとしてリアルタイムに情報を配信
  • データ加工・連携処理
    • S3へのデータアップロードをトリガーにデータ処理
    • イベント駆動の業務処理連携 w/SQS
    • 短時間処理の並列実行
    • アプリケーションのフロー管理
  • データイベント処理
    • ストリームデータの連続処理
    • チャットボット
    • IoTバックエンド
    • データ変更トリガー
      • DynamoDB (DyamoDBストリーム有効) => Lambda => RDS
  • バックエンドデータ処理
    • ログデータ収集処理
    • 機械学習などデータパイプライン
    • データレイクからのデータ加工
    • スケジュール・ジョブ
• API Gateway は最大数十万個のAPI同時呼び出し/受付が可能である。

CloudFormation

• テキストファイルのテンプレートを用いることで、ほぼ全ての AWS リソースをスタックと呼ばれる単位でプロビジョニングできるサービス。
• 他プロビジョニングサービスとの比較 (導入コストの昇順, CloudFormation が最も難しい)
  • Beanstalk
    • とりあえずデプロイだけサクッとしたい人向け (自動で運用サポート)
    • WEBアプリケーションやワーカー環境などの構築によく用いられる。
  • OpsWorks
    • アプリケーション志向のAWSリソース(EC2, Elastic IP, ...)に限定される。

セキュリティ/運用

• CodePipeline は他の Code シリーズのサービス以外にも、ECSなどにも利用可能である。

• KMS で使われるキー

• CMK (カスタマーマスターキー) : 暗号化の実行の際に最初に作成されるキーで、暗号化キーを暗号化する。

• 暗号化キー (カスタマーデータキー) : 実際のデータを暗号化する。

• 検出制御系サービスとその対象

  サービス	対象
  CloudTrail	AWSユーザーの行動ログ
  CloudWatch	AWSリソースのメトリクス
  AWS Guard Duty	AWS 上で悪意のある操作や不正な動作
  AWS Shield	DDoS に対する保護
  IAM Access Analyzer	外部と共有されているリソース/データへの意図しないアクセス
  Amazon Inspector	セキュリティ評価の実施

• 運用系サービスとその管理対象

  サービス	対象
  AWS Config	リソースの変更/構成(Stream, History, Snapshot から成る)
  AWS Service Catalog	AWSでの使用が承認された IT サービスのカタログ
  AWS Artifact	コンプライアンス関連(Artifact Reports, Artifact Agreements から成る)
  AWS System Manager	運用タスクの自動化

その他

• Snowball
  • セキュリティに考慮して設計されたデバイスを使用するペタバイト規模のデータ転送ソリューション(デバイス)で、AWS クラウド内外に大容量データを転送することが可能になる。
  • 1台当たり 50 or 80 TB のストレージがあり、42 or 72 TB が使用可能である。
  • ストレージ/スペックの最適化が行われた Snowball Edge Storage / Compute Optimzied も存在する。 ストレージ容量は 100 TB (83 TB が使用可能)。