AWSサービス全体の概要

1-6 ストレージサービス

S3: Simple Storage Service

• オブジェクトストレージ

  • 富士通 - オブジェクトストレージとは

  • データをオブジェクト単位で管理する

    • cf. ファイルストレージではディレクトリ構造で管理
  • IDとメタデータによって管理
  • データサイズやデータ数の保存制限がないため、大容量データの保存に適する

• 高耐久性

  • デフォルトで同一リージョン内の3箇所のAZに自動複製
  • eleven nine

• 大容量ストレージ

  • 容量制限実質なし

    • 1ファイルあたりのサイズ制限はあり
  • 従量課金

• バージョニング機能

  • オブジェクト単位にバージョンIDで管理
  • 標準では同名オブジェクト上書き(世代管理しない)

• 静的Webサイトホスティング

  • サーバ不要
  • Route 53のDNSフェイルオーバーと組み合わせて、Sorryページとしてもよく使われる

• 暗号化

  • SSE(Server-Side Encryption)

  • AES-256暗号化対応

    • AWSで鍵管理

      • S3のデフォルトキー
      • KMS: Key Management Serviceで管理されている鍵

    • ユーザーで鍵管理

      • ユーザーの任意の鍵
  • AWSで鍵管理する場合は、暗号化鍵と暗号化されたオブジェクトとのマッピングは透過的

• アクセス制御

  • IAMポリシー

    • Read, Get, Put等の認可

  • バケットポリシー

    • JSONで記述
    • IAMユーザーだけでなく、IPアドレス等での制御も可能

  • ACL: Access Control List

    • AWSアカウントレベルのアクセス制御

    • パブリックアクセス

      • 不特定多数のユーザーへファイル公開可能

• ストレージクラス

  • 公式ドキュメント
  • 公式ドキュメント/RRS
  • IA: Infrequent Access
  • RRS: Reduced Redundancy Storage

• 柔軟なライフサイクルポリシー

  • 設定した期間が経過したらなにかする

  • 例

    • Glacierにアーカイブ
    • 削除
• 署名付きURL
• ログ保管

• マルチパートアップロード

  • 大容量のオブジェクトのアップロード時に
  • 分割アップロードし、S3側で再構成

• クロスリージョンレプリケーション

  • S3は分類上グローバルサービス
  • S3に保存したデータはデフォルトで同一リージョン内の3箇所のAZに複製される

  • これを複数リージョンに複製するようにする

    • 別AWSアカウントも指定可能

EBS: Elastic Block Storage

• ブロックストレージ

  • ブロック単位でデータを分割保管するやつ

• EC2インスタンスにアタッチするやつ

  • 単一インスタンスに
  • cf. EFS(後述)
• 複数のストレージタイプ

• 高可用性

  • AZ内冗長性

• スナップショットによるバックアップ

  • スナップショットはS3に自動保管
  • 初回はフルバックアップ
  • 以降は増分

  • 完了を待たなくて良い

    • 開始時点のスナップショットが保管される
    • cf. オンプレ環境での「スナップショット」は完了待ちがある

その他のストレージサービス

• インスンタンスストア(エフェメラルディスク)

  • インスタンスのホストコンピュータの領域を使用

    • 高パフォーマンス
    • 揮発性

• EFS: Elastic File System

  • 共有ストレージサービス
  • 複数のEC2インスタンスにアタッチできる
  • オンプレサーバーからも利用できる

• SGW: Storage Gateway

  • S3に標準プロトコルでアクセス

    • NFS: Network File Sytem
    • SMB: Server Message Block
    • iSCSI: Internet Small Computer System Interface
  • オンプレサーバーにS3をマウントして利用できるようになる

  • タイプ

    • キャッシュ型ボリュームゲートウェイ

      • データをS3格納
      • 高アクセス頻度データはローカルキャッシュ
      • iSCSI使用

    • 保管型ボリュームゲートウェイ

      • データをスナップショットとしてS3に格納
      • iSCSI使用

    • テープゲートウェイ

      • 物理テープ装置の代替としてデータをS3 Glacierに格納
      • iSCSI使用

    • ファイルゲートウェイ

      • データをS3に直接オブジェクトとして格納
      • NFS使用

• AWS Import/Export

  • ユーザ <— 物理ディスク —> AWS内ストレージ
  • deprecated

• AWS Import/Export Snowball

  • PB単位の大容量データをAWS内ストレージに転送
  • AWSが専用の筐体を用意・住所に発送

1-7 データベースサービス

AWSのデータベースの特徴

• マネージド

  • 本来行いたいことに多くの時間を充てることができる

    • テーブルやカラムの設計等

RDS: Relational Database Service

• DBエンジン

  • Amazon Aurora
  • PostgreSQL
  • MySQL
  • MariaDB
  • Oracle Database
  • Microsoft SQL Server

• Amazon Aurora

  • PostgreSQL, MySQL互換

  • これらより高性能

    • 3倍、5倍のスループット

  • 冗長構成

    • 3箇所のAZにデータ格納
    • 1AZにつき2箇所のディスクに書き込み
    • ダウンタイムほぼなし

• パッチ適用の管理負荷軽減

  • パッチ自動適用

    • 曜日や時間帯指定

  • マルチAZ使用時の流れ

    1. スレーブのメンテ
    2. スレーブをマスターに昇格
    3. 元マスターのメンテ

• バックアップと復元

  • バックアップ

    • データベースインスタンスのスナップショット

      • 標準で1日1回
      • S3
      • 任意のタイミングで手動でも実施可能
      • 保存期間指定可能
      • 最大で35日分保存可能

    • トランザクションログの保存

      • 5分に1回
      • S3

  • 復元方法

    • 通常の復元

      • スナップショットから

    • ポイントインタイムリカバリ

      • スナップショット+トランザクションログから

  • 復元時は新しいインスタンスを建てる

    • ので、アプリケーション側に修正必要

      • 新しいエンドポイントを指すように

• マルチAZ

  • Aurora以外のエンジンでは明示的に指定

    • cf. Auroraではもともと3AZ x 2ディスクの冗長構成
  • 複数のAZをまたいでRDSクラスタ構築

  • 高耐久性・高可用性

    • 障害時、フェイルオーバーが働く
    • cf. シングルAZではバックアップからの復元が必要

• リードレプリカ

  • 読み込みスループットを高めるためのもの
  • マスターと同じものを複製し、読み取り専用として構築

  • 利用可能エンジン

    • Aurora
    • PostgreSQL
    • MySQL
    • MariaDB

• SSL接続

  • 公式

  • コマンド

    • MySQL, MariaDB

      • mysql ... --ssl-ca=[full path]rds-combined-ca-bundle.pem --ssl-verify-server-cert

    • PostgreSQL

      • $ psql ... sslrootcert=rds-ca-2015-root.pem sslmode=verify-full"

DynamoDB

• NoSQL

• キーバリュー型

  • 半構造データもバリューとして格納可能

    • JSON
    • XML
    • LOG

• マルチAZ

  • 自動的に3AZに保存

• 結果整合性モデル(Eventual Consistency)

  • データ読み取りのタイミングによっては書き込んだデータが反映されない

    • 3箇所のAZに分散・保存される際、時間差がある
    • 2つのAZに正常に書き込み完了した時点で、「正常に書き込み完了した」と判断し、成功の旨をレスポンスする
    • この状態で、残り1つのAZからデータを読み取るとinconsistencyがおこる
    • 時間が経てば正しく反映される(結果的には整合性が保証される)
  • それでは困る場合は「Consistent Read」オプションを利用する

Redshift

• データウェアハウス

• PB単位の大量データの集計・分析

  • BIツールなどからの

• PostgreSQL8.0.2準拠

  • 列指向なので大きな違いもある

• 世界観

  • クラスター

    • ノードの集まり

      • リーダーノード

        • 処理を受ける

      • コンピュータノード

        • 実処理

• スナップショット

  • タイプ

    • 自動

      • トリガーは下記いずれか:

        • 8時間ごと
        • 5GBの更新ごと
      • 保存期間がすぎると自動削除
    • 手動

  • 格納先

    • 標準: クラスターが配置されているリージョン

    • クロスリージョンスナップショット

      • 別リージョンにもコピー

ElastiCache

• インメモリDB

  • 高スループット
  • 低レイテンシ

• RDSのキャッシュ等として利用される

  • EC2 -> ElastiCache -> RDS

1-8 データ通知・連携処理サービス

• アプリケーションで自ら実装せずにデータ通知・連携

データ通知・連携処理サービスの概要

• 通知処理

  • SES: Simple Email Service

    • メール

  • SNS: Simple Notification Service

    • メッセージ通知
    • Pub/Sub

    • 構成要素

      • トピック

        • 通知を受信するためのアクセスポイント

      • サブスクライバ

        • HTTP/HTTPS

        • AWSのさまざまなサービスへの通知・連携

          • CloudWatch
          • SQS
          • Lambda

      • パブリッシュ

        • トピックに対して配信

  • SQS: Simple Queue Service

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

    • 非同期かつ並列な分散処理

      • 処理負荷の大きなバッチとか

  • Data Pipeline

    • データのETL: Extract/ Transform / Load

    • 機能

      • スケジュール
      • ワークフロー定義
      • イベント通知
      • オンプレ環境との連携

  • Kinesis

    • ストリーミング処理

    • シリーズ

      • Kinesis Data Streams
      • Kinesis Data Firehose
      • Kinesis Data Analysis

1-9 構成管理サービス

構成管理

• プロビジョニング

  • ITリソースを状況に応じて動的に利用したり割り当てたり

    • サーバー
    • N/W
    • DB
    • ストレージ

• デプロイ

  • サーバーにファイルやアセットを配置して利用できるようにする

CloudFormation

• AWSのすべてのインフラストラクチャリソースを自動でプロビジョニング

• テンプレート

  • IaC: Infrastructure as Code

    • JSONまたはYAML

• スタック

  • プロビジョニングされるリソースの集合

Elastic Beanstalk

• プロビジョニング+デプロイ

• 対応アプリケーション

  • Java
  • .NET
  • PHP
  • Node.js
  • Python
  • Ruby
  • Go
• Dockerにも対応

• 対応サーバー

  • Apache HTTP Server
  • Nginx

  • Passenger

    • RoR動かすやつ
  • Microsoft IIS: Internet Information Services

その他のサービス

• OpsWorks

  • デプロイ・プロビジョニング自動化

  • 構成管理ツール利用可能

    • Chef
    • Puppet

• CodeDeploy

  • デプロイ自動化

1-10 運用管理サービス

CloudWatchの概要

• リソースの情報の収集・監視・可視化

• EC2のメトリクス

  • 標準メトリクス

    • CPUUtilization
    • DiskReadOps
    • DiskReadBytes
    • NetworkIn

  • 標準メトリクスにないやつ

    • メモリ使用率
    • ディスク使用率

  • カスタムメトリクス

    • CloudWatchエージェントをインスタンスにインストール
    • 自前でスクリプト書いてエージェントからカスタムメトリクス送りつける
• CloudWatchの監視間隔と保存期間

• CloudWatchアラーム

  • CloudWatchでの監視項目がある一定の値になった場合にアラームとアクション起動
  • 基本モニタリングなら5分間異常だとALARMになり5分間正常だとOKに

• CloudWatch Events

  • イベント駆動型監視

  • トリガー

    • リソースの状態変化

      • EC2インスタンスの状態 pending->running とか
      • Auto Scalingの起動成功/失敗とか
    • スケジュール

  • アクション

    • Lambda
    • SNS
    • Kinesis
    • SQS

  • 用例

    1. スポットインスタンスが強制停止されたら(トリガー)
    2. Lambdaを起動して(アクション)
    3. 新しいスポットインスタンスを起動する

その他の運用管理サービス

• CloudWatch Logs

  • さまざまなAWSログを統合的に収集

    • VPCフローログ
    • CloudTrail
    • など

• VPCフローログ

  • VPC内のネットワークインタフェース間で行き来する通信の内容をキャプチャ
  • やはり監視・監査に

• CloudTrail

  • AWSアカウントで利用されたAPIコールをログとして記録

  • セキュリティ監視・監査に

    • 不審なアクセスや操作
    • 意図せぬ設定変更
  • AWS Configとの違い
  • 「何やったか」

• AWS Config

  • リソースの構成変更の追跡
  • CloudTrailとの違い
  • 「どうだったか」

• AWS Systems Manager

  • なんかよくわからないので公式引用

AWS Systems Manager を使用することで、複数の AWS のサービスの運用データを一元化し、AWS リソース全体のタスクを自動化できます。
アプリケーション、アプリケーションスタックのさまざまなレイヤー、本番環境と開発環境といったリソースの論理グループを作成できます。
Systems Manager では、リソースグループを選択し、その最新の API アクティビティ、リソース設定の変更、関連する通知、運用アラート、ソフトウェアインベントリ、パッチコンプライアンス状況を表示できます。
運用ニーズに応じて、各リソースグループに対してアクションを実行することもできます。
Systems Manager により、AWS リソースを一元的に表示および管理でき、運用を完全に可視化して制御できます。

• AWS Trusted Advisor

  • ベストプラクティスに基づいて改善事項を推奨する

  • 例の5つの柱っぽいやつ

    • コスト最適化
    • セキュリティ
    • 耐障害性
    • パフォーマンス
    • サービスの制限