1日1%成長する ~Amazon EC2スポットインスタンス ~

AWSの学習メモ

Amazon EC2スポットインスタンス 

スポットフリート
  ワークロードの選択
    - Load balancing: 近しいサイズのインスタンスタイプから選択していく
    - Flexible workloads: サイズの異なるインスタンスタイプから選択していく

  最低限の仕様指定
    - vCPU、メモリ or インスタンスタイプ指定がある

  ターゲット容量指定
    - 台数 or vCPU
    - ターゲット容量維持も可能

  起動確認
    - フリートの強度が「強度が十分」であることを確認
      - 複数のインスタンスタイプを指定しておくと強度が上がる
    - フリート全体の削減額を確認する
    - 問題なければ作成

EC2 Auto Scaling Group
  EC2フリーと統合した新しいEC2 Auto Scalingの機能を使うには「起動テンプレート」を用いる
    - 「購入オプションとインスタンスを組み合わせる」を選択
      - オートスケールを詳細設定したい場合にこれを使う
    - 起動テンプレート選択

  台数
    - 全体数：グループサイズ
    - オプションの「オンデマンドベース」でオンデマンドの台数指定
    - 「ベースを超えるオンデマンド割合」に従って分配
      - グループサイズ: 12 -> 全体として
      - オプションのオンデマンドベース: 2 -> 最低2台はオンデマンド
      - ベースを超えるオンデマンド割合: 30:70 -> 12 - 2 = 10を3:7で分ける
        - オンデマンド:2台 + 3台
        - スポット: 7台

ユースケース
  AWS Batch
    - ECSを選択するがそこをAutoScalingするEC2を選択可能
    - スポットインスタンスを選択できる

  ECSクラスターで使ってみる
    - 中断時の考慮が必要

使いこなす
  4+1の原則
    1. ステートレス：状態をもたせない
    2. 再開可能なワークロード：安全な再開
    3. 疎結合：周辺影響の極小化
    4. 分散：複数AZと複数インスタンスタイプの活用
    5. 「上限価格」にはオンデマンドインスタンス価格を指定

1日1%成長する ~Amazon EC2スポットインスタンス ~

AWSの学習メモ

Amazon EC2スポットインスタンス 

EC2購入オプションをどう組み合わせる？
  - 新規のワークロード、あるいはステートフルなワークロードには？
    - オンデマンドインスタンス
  - 中断に強く、スケールするワークロードには？
    - スポットインスタンス
  - 一定の負荷が見込めるワークロードには？
    - リザーブドインスタンス

スポットインスタンスの特徴
  - 低コスト
    - 最大9割引
    - 中断に強い
      - ビッグデータ
      - コンテナ
      - HPC/グリッド
      - レンダリング
  - 容易は起動
    - 一度のリクエストで1000台以上を起動可能
  - 柔軟な選択
    - 複数のインスタンスタイプを指定可能

アンチパターン
  - 高可用性を求められるミッションクリティカルなワークロード
    - データベース（オンライントランザクション）
  - チェックポイントを設けにくいステートフルなワークロード
    - マルチプレイヤーのゲームステージ

空きキャパシティとスポット価格
  - 使われていないインスタンスがスポットプールに入る
    - リージョン、AZ、インスタンスタイプ毎に独立している
  - 価格は需要と供給で決まる
    - リクエスト時に上限価格を指定する
      - デフォルトはオンデマンド価格になる

スポットインスタンスの中断
  - 2分前までに通知される
  - 受信
    - インスタンスメタデータ
    - CloudWatch Events
  - EC2のキャパシティ要件（オンデマンドインスタンスの需要増加など）
    - 空きキャパシティとして戻す必要が出てくるため中断
  - 上限価格を上回った場合に中断

種類
  - スポットインスタンス
    - リクエスト：台数
    - リクエストタイプ：インスタンス
    - 永続性：ont-time(sync)、persistent(sync)
    - 容量変更：出来ない
  - スポットフリート
    - リクエスト：台数、vCPU数
    - リクエストタイプ：フリート（様々なインスタンスタイプ郡）
    - 永続性：request(async)、maintain(async)
    - 容量変更：出来る
  - EC2フリート
    - リクエスト：台数、vCPU数
    - リクエストタイプ：フリート（様々なインスタンスタイプ郡）
    - 永続性：instant(sync)、request(async)、maintain(async)
    - 容量変更：出来る

1日1%成長する ~Aws VPC~

AWSの学習メモ

Amazon VPC

クラウドで仮想ネットワークを構築（NFV）

VPC
    - AWS上にプライベートネットワーク空間を構築
        - 任意のIPアドレスレンジが利用可能
    - 論理的なネットワーク分離が可能
        - 逆にネットワーク同士をつなげることも可能
    - ネットワーク環境のコントロールが可能
        - ルートテーブルや各種ゲートウェイ、各種コンポーネント
    - 複数のコネクティビティオプションが選択可能
        - インターネット経由
        - VPC/専用回線

全体
    - 全体のネットワーク空間をVPCで定義
    - 実際に稼働するネットワークをサブネットという
    - InternetGatewayをVPCにアタッチするとインターネットにアクセス可能

    - インターネットに接続しないプライベートサブネットも可能
    - VPNや専用線を使ってオフィスやデータセンターとつなぐ

アドレスレンジ
    - 172.31.0.0/16など
        - RFC1918レンジ
        - /16（65534アドレス）
VPC CIDRブロック
    /16で設定した場合

    - /18：サブネット4つ、IP数：16379
    - /20：サブネット16、IP数：4091
    - /22：サブネット64、IP数：1019
    - /24：サブネット256、IP数：251 <- 推奨
    - /26：サブネット1024、IP数：59
    - /28：サブネット16384、IP数：11
        ※VPCあたりのサブネット作成上限はデフォルトで200個まで

AZは1つ以上のIDCで構成されている
サブネットで/24の際の予約ホストアドレス
    .0：ネットワークアドレス
    .1：VPCルータ
    .2：Amazonが提供するDNSサービス
    .3：AWSで予約
    .255：ブロードキャストアドレス

セキュリティグループ = ステートフルFirewall
  - EC2インスタンスもしくはRDSインスタンスで設定
  - サーバレベルで行う

Network ACLs = ステートレスFirewall
  - サブネット単位で関連づけ
  - デフォルトは全ての送信元IPを許可

Route 53 Resolver for Hybrid Clouds
  今まではオンプレからVPC-Provided DNS（VPCで設定したCIDRアドレス）へ
  アクセス不可制限があった
    => オンプレからDirectConnect/VPNによるVPC Provided DNSへ直接アクセス可能な、
        DNSエンドポイントを提供

Amazon Time Sync Service
  VPC内で稼働する全てのインスタンスからNTPで利用できる高精度NTP
  169.254.169.123で可能
  leap smearingによる「うるう秒」対策済み
  全てのリージョンで指定可能

Direct Connect Gateway
  同一アカウントに所属する
    複数リージョンの複数のロケーションから複数リージョンの複数のVPCに接続可能

  DirectConnectから世界の全リージョンのVPCに接続することが出来る。
  1つのDirectConnectの仮想インターフェイスから複数のVPCに接続することが出来る
  複数のDirectConnectの仮想インターフェイスをDirectConnectGatewayに接続する事が出来る

  冗長化
    - VPNとDirectConnectを同じVGWに接続することが可能
    - VPNを優先したい場合は/24だったら/25にするとVPNが優先される
      - ロンゲストマッチ

Transit VPC
  - CloudFormationのテンプレートとして提供

Transit Gateway （Transit VPCを使う必要がない）
  - 1000以上のVPCとオンプレミス間の相互接続を簡単になる

VPC Endpoint
  VPC EndpointはグローバルIPを持つAWSのサービスに対して
  VPC内部から直接アクセスするための出口になる。

  - Gateway型
    - 無料、ユーザ側で意識する必要ない
  - PrivateLink型
    - 有料、マルチAZ設計

VPCピアリング
  - 2つのVPC間でトラフィックのルーティングが可能
  - 同一、異なるアカウントで可能
  - リージョンを跨ぐことが可能

VPCシェアリング
  - アカウントをまたいだVPCシェアリングによりVPC数を削減可能
  - AWS Organizationsは必須
  - デフォルトVPC、サブネット、セキュリティグループはシェアできない

運用
  - VPC Flow Log
    - ネットワークトラフィックをキャプチャ
  - GuardDuty
    - 悪意のあるスキャン
    - インスタンスへの脅威
    - アカウントへの脅威
    - VPC Flow Log、DNS Logs、CloudTrailをデータソースとして可視化する

1日1%成長する ~Aws EBS~

AWSの学習メモ

Amazon EBS

EBSの監視
    - 標準メトリクス
        - Volume Read/Write Bytes
        - Volume Read/Write Ops
        - VolumeConsumedReadWrite
        - Ops
    - 容量メトリクス
        - ディスクの使用量、空き容量
    - バーストクレジットのメトリクス
        - BurstBalance

    io1は1分間、gp2、st1、sc1は5分毎

NVMeSSD
    - NitroベースインスタンスではNVMeブロックデバイスとしてEBSボリュームを認識
    - OSのNVMeドライバを利用してPCIバスをスキャンして、アタッチされたEBSを検出
    - 旧世代のインスタンスやハイパーバイザーからの移行
        - 旧世代ハイパーバイザーからNitroハイパーバイザーへ変更の際にはNVMeドライバが必要
        - OS自体がNVMeデバイスに対応していること
        - OSのアップグレードが難しいなど、条件を満たすことができないc4/m4/r4などの旧世代を利用することも検討

    - OSからNVMeデバイスに送信されるI/O操作のタイムアウト値を最大へ
    - EC2の起動毎にデバイス名が変わるため、fstab等ではUUIDを指定（もしくはLABELでも可能）

Elastic Volume
    - EBSボリュームをEC2インスタンスにアタッチ中でもサイズやIOPSを変更可能
        - gp2 -> io1
        - gp2 -> st1やsc1への変更は500GB以下でないことを確認
        - サイズ縮小はできない
    - io1はサイズとiopsの両方が変更可能
    - API、CLI、マネージメントコンソールから操作可能

    注意
        - EBSの容量拡張後はOS側のファイルシステムの拡張を実施
        - IOPSの設定は徐々に反映される
        - 1度変更すると6時間は変更不可（つまり6時間は変更できない）
        - 変更後のボリュームに応じて金額が変わる

バックアップ
    - 定期的にsnapshotを作成する
    - データ整合性を保つため、静止点を設けてやる
    - 保存期間や世代数は無制限
    - フルバックアップと増分バックアップ
        ※フルバックと増分1バックアップを両方消すと戻せなくなる
    - リージョン間でコピー可能
    - cloudwatch eventsで可能

バックアップ方法
    - CLI/SDK/マネージドコンソール
    - Systems Manager/CloudWatch Events
        - windowsとlinux混合の場合に利用
        - VSSと連携して一貫性のあるSnapshotを作成可能
    - Amazon Data Lifecycle Manager(DLM)
        - タグ付けしたEBSを定期的にSnapshot
    - AWS Backup
        - EBSだけでなく、EFS、RDS、DynamoDB、StorageGatewayをサポート（東京リージョンは未サポート）
暗号化
    - ボリュームされると以下が暗号化される
        - ボリューム内のデータ、インスタンス間の移動されるデータ、Snapshotが暗号化される
    - OSから透過的に使えるためOSを乗っ取れれると意味がない
    - 暗号化/復号化はハードウェア機能なのでパフォーマンス影響は小さい
    - 暗号化されたSnapshotを復元すると暗号化されたボリュームが作成される

暗号化キー
    - AES256
    - Data keyは暗号化する各ボリューム毎に一意のキーを生成し、暗号化されたデータと共にボリューム上に保存
    - Data Keyの生成
        - AWS Management Service(KMS)
        - カスタマーマスターキー（CMK）及びカスタマー管理（CMK）

暗号化
    - EBSボリューム作成後はSnapshot経由で暗号化を有効にできる
    - 暗号化の解除を行う場合は新規ボリュームを作成してOS側でデータコピーを行う
    - 暗号化の解除は新規ボリュームを作成してOS側でデータコピーを行う
        - linux:rsyncやwindows:robocopy

1日1%成長する ~Amazon EBS~

AWSの学習メモ

Amazon EBS

ブロックストレージ
    - EC2インスタンス・ストレージ
        - ホストコンピュータの領域で一時的なもの（落とすと消える）
    - EBS
        - SSD-backed Volume
            - gp2, io1
        - HDD-backed Volume
            - st1, sc1
EBSユースケース
    - gp2
        - 負荷が読めないシステム
        - 小規模DB
        - 開発環境など
    - io1
        - RDB
        - NoSQL
        - 他に持続的なIOPSパフォーマンスが必要な場合
    - st1
        - ビックデータ、分析
        - Hadoop、Splunk
        - DWH
    - sc1
        - ログデータ
        - アーカイブ
        - 低頻度アクセスの大量データ

gp2
    - デフォルトボリューム
    - 最小100IOPS（33.33GB以下）から最大16,000IOPS（5,334GB以上）
    - 1000GIBまでは3000IOPSまでバースト
    - スループットは1IOPS = 256KB/s
        - 128MB/s(170GBまで)
        - 最大250MB/s（170GBから334GB）
        - 250MB/s（334GB）
    - バーストバケットモデル
        - 5,400,000I/Oクレジットまで蓄積可能
        - バケットにクレジットが残っていればIOPSを3000まで引き上げてくれる
        - 枯渇するとベースラインパフォーマンス分
        - 3IOPS/GB以下でクレジット残高増加

    I/Oクレジットの監視で常にバーストするのであればSSD増加やio1への移行を検討

io1
    - 最小100IOPSからNitroベースインスタンスに対して最大64,000IOPS、
    　他のインスタンスに対して最大32,000IOPSを提供
    - スループットは32,000IOPSで500MB/s、64,000IOPS/1000MB/sを提供

st1
    - シーケンシャルアクセス時に高い性能を発揮
        - ビックデータ向き
    - 500GB~16TBまで1GB単位で指定可能
    - 最大500IOPS、1MBのIOサイズで読み取りと書き込みが処理
    - スループット
        - 1TBあたり40MB/sがベースラインパフォーマンス
        　1TBあたり250MB/sまで性能を引き上げるバーストが利用可能
        　スループットの上限値は500MB/sとなる
sc1
    - ログやバックアップのアーカイブ先
    - 500GB〜16TBまで1GB単位で指定可能
    - 最大250IOPS、IMBのI/Oサイズで読み取りと書き込みが可能
    - スループット
        - 1TBあたり12MB/sがベースラインパフォーマンス
        　容量1TBあたり12MB/sがベースラインパフォーマンス
        　スループットの上限値は250MB/sとなる

st1/sc1のバーストはスループット

gp2とio1のIOPSカウント
    256KBまでの連続したアクセスを1IOPSとカウント
        - 32KBの連続するアクセス8回は、I/O命令を1回発行
        - 32KBのランダムなアクセス8回は、I/O命令を8回発行
    256KBを超える場合は複数回の256KBブロックアクセスを行ったとしてカウントされる
        - 32KBアクセスの1回はI/Oを1回発行
        - 512KBアクセスの1回はI/Oを2回発行

EC2インスタンス側のスループットを改善
    - 最新ではないインスタンスタイプの場合はEBS最適化(EBS-Optimized)を有効
    - インスタンスタイプを大きいものへ変更する

EBS側のI/O処理性能を改善
    - EBSボリューム側の実績IOPSを確認する
        - CloudWatchのVolume Read/Write Opsの合計値
        - OSでEBSボリュームへのI/O命令回数を確認（iostatやperfmon）
    - 上限に達成していればボリュームの変更を検討
        - タイプを変更（HDD -> gp2、gp2 -> io1）
        - スペックの変更（gp2：容量を増加、io1：IOPS値を増加）

1日1%成長する ~Amazon EBS~

AWSの学習メモ

Amazon EBS

EBS
    - EC2インスタンスにアタッチして使用するブロックれベルのストレージサービス
    - OSやアプリケーション、データ置き場などに使える
    - SnapshotでS3へバックアップ可能
        - 任意のAZへ復元可能
    - 99.999%の可用性

    注意
    - 他のAZのEBSはアタッチできない
    - 1つのEC2は複数のEBSにアタッチ可能
    - 1つのEBSに対して複数のEC2でアタッチできない

    AZ内で複数のHWにレプリケートされているのでRaidによる冗長化は基本的に不要
    実体はネットワーク・ストレージだが使用時は意識しなくてもよい。
        ※実体がネットワーク・ストレージなので帯域とかは意識する必要有り
    セキュリティグループの通信制御の対象外

EBSの最適化
    - EC2から外部への通信とネットワーク通信が分けて管理されている
        - 最適化無しだと1つの経路になる
        - EBSとの専用帯域として56.25MB〜1750/MBまで大きいインスタンスほど帯域増加
    - 最適化インスタンス
        - c3/m3/r3/t2などの次世代以上のもの

1日1%成長する ~Amazon CloudWatch~

AWSの学習メモ

Amazon CloudWatch

CloudWatch Alarmsの設定
    - M out of N(N個中M個)のアラーム
    - 評価期間：アラームの状態を決定するまでに要する値
    - Datapoint to Alarm：アラームがALARM状態に遷移するために超過する必要がある評価期間内のデータポイントの数
        - 短時間で変化が大きいメトリクスで誤報を抑制

CloudWatch Alarmsのアクション
    - SNS
        - SNSトピックを追加してアラームの状態が変わったときにトピック発行
        - 以下、例
            - CloudWatch MetricsにEC2からメトリクスを送付
            - 指定したしきい値を超えた時にSNSのアクションを実行
            - SNSをトリガーにAWS Lambdaを実行
            - GetMetricWidgetImage APIのグラフを取得する
            - 取得したグラフの画像ファイルを添付したEmailを送信/運用システムに連携
    - EC2
        - EC2インスタンスを自動的に停止、終了、再起動または復旧アラームを作成
        - StatusCheckFailed_SystemアラームがトリガーとしたAutoRecovery
    - EC2 Auto Scaling
        - AutoScalingのEC2インスタンス台数を増減するアラームを作成
        - 負荷に応じてリソース調整

クラウドならではの監視
    Billingアラーム設定が可能
        ※アラームの設定はVirginiaリージョンから可能

CloudWatch Logs
    - AWSサービス及び顧客システムのログを監視、保存、アクセスを提供
    - エージェント経由でログメッセージをCloudWatchエンドポイントに転送
    - ログデータの保存期間を設定可能（1日〜永久保存）
    - Amazon S3へのログのエクスポートが可能

階層
    - ログイベント
        - 1つのログエントリ
        - アクティビティのレコード
    - ログストリーム
        - 複数のログイベントで構成
        - モニタリングしているリソースのタイムスタンプ順でイベントを表す
    - ロググループ
        - 複数のログストリームで構成

CloudWatch Logsのメトリクスフィルタ
    - ログデータから特定の文字列のフィルタリングが可能

CloudWatch Logsサブスクリプションフィルタ
    - 集めたログをフィルタパターンに応じてリアルタイムにKinesis Data Streams/Firehose/Lambdaへ転送
    - 1つのロググループにつき、1つのサブスクリプションフィルタが可能
    - サブスクリプションフィルタはCLIからのみ設定可能

CloudWatch Logs Insights
    - 専用のクエリ言語といくつかのシンプルで強力なコマンドを提供
    - サンプルクエリ、クエリの自動補完、ログフィードの検出
        - サンプルクエリ例：VPCフローログ向けに「送信元と送信先のIPアドレス別の平均、最小、最大バイト転送」など
    - 2018/11/5以降にCloudWatchLogsに送信されたログデータを検索可能
        - ログタイプに応じログフィールドも異なる
            - VPCフローログやRoute53ログ、Lambdaログなど
    - fields：指定したフィールドをログイベントから取得
    - filter：クエリの結果を1つ以上の条件でフィルタリング
    - stats：ログフィールドの値に基づいて集約統計を計算
    - sort：取得したログイベントをソート
    - limit：クエリから返されるログイベントの数を制限
    - parse：ログフィールドからデータを抽出
    Visualization
        - 集約関数「stat()」、グルーピングに期間切り上げで「bin()」を使用する必要有り
        - 時間軸に沿ってトレンドやパターンを特定、分析

CloudWatch Dashboards
    - CloudWatchコンソールでカスタマイズ可能
    - 異なるリージョンのリソースでも1つのダッシュボードでモニタリング可能
    - 自動更新間隔（10s、1m、2m、5m、15m）
    - 表示可能な5つのウィジェット
        - 折れ線グラフ
        - スタックエリア
        - 数値
        - テキスト
            - マークダウン形式で表示可能
            - ボタンとしてウェブリンクを指定
        - クエリ結果
            - Logs Insightsから結果を表示

    APIとCLI有り
    AWSが推奨するベストプラクティスに基づいたダッシュボード
        「Automated dashboard」

    CloudWatch Alarmsと統合可能

CloudWatch Events
    - AWS上のリソースを変更する示すシステムイベントのストリームを提供
    - システムイベントをトリガーとして、ターゲットがイベントの処理
        - JSON形式のイベントを条件にあってるかどうかチェックして処理

    イベントバス
        「他のAWSアカウントとイベントを送受信するようなAWSアカウントを設定」

        1. 受信側アカウントでイベント受信を許可するAWSアカウント番号/Organizationを指定
        2. 送信側アカウントで受信したイベントをイベントソースにするルールを作成
        3. 受信側アカウントで受信したイベントをイベントソースとするルールを作成

Amazon CloudWatch EventsでのAWS Healthイベントのモニタリング
    - AWS Healthイベントのステータスの変化を検出し、アクションするツールをGitHubで公開

Private Linkの対応（Metrics/Events/Logs）
    - オンプレもしくはプライベートサブネット環境におけるCloudWatch利用

料金
    - APIの料金
    - メトリクスの数（カスタムメトリクス含む）1つずつかかる
    - event（100万あたり）