Go to Qiita Advent Calendar 2024 Top
LoginSignup
5
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@3062_in_zamud(3062._zamud)

[AWS]各サービス概要

Posted at

#VPC(Amazon Virtual Private Cloud)
利用者ごとにプライベートなネットワークをAWS内に作成出来る。
ネットワーク空間は可能な限り大きなサイズ(/16)で作成する。

  • サブネット

    • インターネットと通じているパブリックサブネットと、外との繋がりが無いプライベートサブネットに分けられ、同一の役割を持ったサブネットを、複数のAZに作るのが推奨されている。

  • ルートテーブル

    • VPC内部の通信や、インターネット・オンプレミス(※1)ネットワーク基盤など外部への通信を実装する。
    • サブネットに1つずつ設定する。

  • セキュリティグループ

    • インスタンス単位の通信制御をするもので、インバウンド(外部からVPCへ)、アウトバウンド(VPCから外部へ)の両方からの制御が可能。

  • ネットワークACL(アクセスコントロールリスト)

    • サブネットごとの通信制御をする。

  • ゲートウェイ

    • VPCの内外部との通信をやり取りする出入り口のこと。主にインターネットゲートウェイ、仮想プライベートゲートウェイ、NATゲートウェイがある。
    • インターネットゲートウェイは、VPCとインターネットを接続するもので、各VPCに1つだけアタッチする。
    • 仮想プライベートゲートウェイは、VPNやDirect Connectに接続するもので、各VPCに1つだけアタッチできる。(複数のVPN(※2)やDirect Connect(※3)に接続可能)
    • NATゲートウェイは、ネットワークアドレス変換機能を有して、プライベートIPをNATゲートウェイが持つグローバルIPに変換し、外部と通信します。これを用いてプライベートサブネットがインターネットと通信出来るようになります。

  • VPCエンドポイント

    • ゲートウェイを経由せずに、VPCと他のAWSのサービスとをプライベートに接続できるAWSのサービスです。

  • ピアリング

    • 2つのVPC間でプライベートな接続をすること。同一のアカウントだけでなく、別のAWSアカウントを跨って通信もできます。

  • VPCフローログ

    • VPC内の通信を解析して、送信元・送信先アドレスとポート、プロトコル番号(※4)、データ量と許可/拒否の区別を記録します。

#CloudFront
HTMLファイルやCSS、画像、動画といった静的コンテンツをキャッシュし、オリジンサーバーの代わりに配信するCDNサービス。
サーバーの負荷を下げながら安定したサービス提供が出来る。

  • 元となるコンテンツを保持するバックエンドサーバー(オリジンサーバー)が必要。

  • ELBやEC2、そしてS3の静的ホスティング(※5)を利用することが出来る。

  • オンプレミスのサーバーも指定可能。

  • URLのパスに応じてことなるオリジンサーバーを指定出来る。

  • ディストリビューション

    • カーネルと呼ばれる中核部分だけでなく、その他に必要な諸々のソフトも含めたLinuxで、ダウンロードやストリーミングというのがある。
    • ダウンロードディストリビューションは、HTTPやHTTPSを使ってHTMLやCSS、画像などのデータを配信する際に利用する。
    • ストリーミングディストリビューションは、RTMP(※6)を使って、動画のストリーミング配信をする際に利用する。

  • キャッシュルール

    • 頻繁にアップデートされる静的コンテンツはキャッシュ期間を短くし、あまりされないものは長くする。
    • 動的サイトのURLパスは、キャッシュ無効化することでCloudFrontをネットワーク経路としてだけ利用することも可能。

#Route53
ドメイン管理と権威DNS機能を持つAWSサービス。

  • ドメイン管理

    • 新規ドメインの取得や更新の手続きが可能。(自動更新機能もあり)

  • 権威DNS

    • ドメイン名とIPアドレスの変換情報を保持しているDNSのことで、変換情報を保持していないキャッシュDNSと区別するときに使う。

  • ホストゾーン

    • レコード情報の管理単位のこと。通常はドメイン名。

  • レコード情報

    • Aレコード、MXレコード、CNAMEレコード、Aliasレコードがある。

  • トラフィックルーティング

    • 名前解決の問い合わせに対してどのように応答するかを決める7種類のルーティングポリシーがある。
    • シンプルルーティングポリシーとは、標準的な1対1のルーティングポリシーです。
    • フェイルオーバールーティングポリシーとは、アクティブ/スタンバイ方式(※7)で、アクティブ側のシステムへのヘルスチェック(※8)が失敗したときにスタンバイ側のシステムへルーティングするポリシーです。
    • 位置情報ルーティングポリシーとは、ユーザーの位置情報に基づいてトラフィック(※9)をルーティングするポリシーです。
    • 地理的近接性ルーティングポリシーとは、リソースの場所に基づいてトラフィックをルーティングして、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する際に使用するポリシーです。
    • レイテンシールーティングポリシーとは、複数箇所にサーバーが分散されて配置されている場合に、遅延が最も少ないサーバーにリクエストをルーティングするポリシーです。
    • 複数値回答ルーティングポリシーとは、1つのレコードに複数のIPアドレスを登録し、ランダムに返却されたIPアドレスに接続する。ヘルスチェックがNGの場合は返却されない。
    • 加重ルーティングポリシーとは、指定した比率で複数のリソースに、トラフィックをルーティングするポリシーです。

  • DNSフェイルオーバー

    • Route53が持つフォールトトレラントアーキテクチャ(※10)です。

EC2(Amazon Elastic Compute Cloud)

仮想サーバーを提供するコンピューティングサービスです。インスタンスという単位で管理され、簡単にサーバー調達が可能。これを使うことでコスト削減や時間短縮といったメリットがある。

  • EC2における性能の考え方

    • 「m4.large」や「p2.8xlarge」などといったインスタンスタイプといった形でスペックを選択する。
    • 先頭のアルファベットはインスタンスファミリーを表し、「m」はバランス型で、「c」はコンピューティング最適化で、「r」はメモリ最適化、「t」は汎用といった感じです。
    • インスタンスファミリーの後ろの数字は世代を表し、大きいほど最新です。
    • 「.~」の部分はインスタンスサイズを表し、大きいほどスペックが高くなる。

  • 費用の考え方

    • 起動していたインスタンスタイプの時間単価×使用時間×起動インスタンス数で費用が計算出来る。
    • インスタンスには、起動中(Running)、停止中(Stopped)、削除済み(Terminated)の3つの状態があり、停止中や削除したインスタンスは課金対象にはなりません。

  • スポットインスタンスとリザーブドインスタンス

    • スポットインスタンスとは、AWSが余らせているEC2リソースを入札形式で安く利用する方式です。ただし、リクエストが増えて余剰なリソースが無くなった場合はインスタンスが自動中断されるので、一時的にインスタンスを利用したいときなどに使う。
    • リザーブドインスタンス(RI)とは、長期間の利用を約束することで割引されるオプションのこと。システムが安定した時などに検討する。

ELB(Elastic Load Balancing)

ロードバランサーのマネージドサービスであるELBは、スケールアウト時の負荷分散を担う。

  • ELBの種類

    • CLB,ALB,NLBといった3タイプある。
    • CLBとALBは同じアプリケーションレイヤー(※11)での負荷分散を行うが、新しいALBを使用するのが一般的です。
    • NLBは、HTTP(S)以外のTCPプロトコルの負荷分散を行う。

  • Auto Scaling

    • システムの利用状況に応じて自動的にELBに紐付くインスタンスの台数を増減させる機能。
    • 最小・最大のインスタンス数を設定することで自動的なスケールアウト/イン(※12)を実現します。

  • ELBとAuto Scalingを利用する際の設計ポイント

    • サーバーをステートレス(※13)にして、状態を保持しない設計にする。
    • AZをまたがってインスタンスを配置する。

ECS(Amazon Elastic Container Service)

Docker環境を提供するサービスです。
EC2インスタンス上で実行されるコンテナをTaskと呼び、EC2インスタンスのことをClusterと呼びます。Cluster上で動作するTaskの定義はTask Definitionで行う。

-例-


{
   "containerDefinitions": [ 
      { 
         "command": [
            "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
         ],
         "entryPoint": [
            "sh",
            "-c"
         ],
         "essential": true,
         "image": "httpd:2.4",
         "logConfiguration": { 
            "logDriver": "awslogs",
            "options": { 
               "awslogs-group" : "/ecs/fargate-task-definition",
               "awslogs-region": "us-east-1",
               "awslogs-stream-prefix": "ecs"
            }
         },
         "name": "sample-fargate-app",
         "portMappings": [ 
            { 
               "containerPort": 80,
               "hostPort": 80,
               "protocol": "tcp"
            }
         ]
      }
   ],
   "cpu": "256",
   "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
   "family": "fargate-task-definition",
   "memory": "512",
   "networkMode": "awsvpc",
   "requiresCompatibilities": [ 
       "FARGATE" 
    ]
}

  • 同じTaskを複数用意した場合はServiceを用いる。

    • TaskごとにIAMロールを割り当てられる。

  • その他のコンテナサービス

    • AWS Fargate,EKS,ECRといったものがある。

Lambda

サーバーをプロビジョニング(※14)しなくてもプログラムを実行できるサービス。
利用すると、ソースコードの実行環境一式提供されるため、ソースコードさえ用意すればすぐにプログラム実行できます。
サーバーを持たないため、インフラ管理の大部分をクラウド側に任せられる。Lambda関数といった単位で実行プログラムとその実行トリガーとなるイベントを事前に定義する。

  • 課金体制
    • リクエストの数と処理時間で決まる。

CloudWatch

運用監視を支援するマネージドサービスです。定期的にAWSリソースの状態を取得し、問題がある場合は運用者に通知します。また、問題が発生した後の処理も設定することが可能です。

  • CloudWatch
    • 各AWSリソースの状態を定期的に取得することをメトリクスという。AWS側が予め定義しているものを標準メトリクスと呼び、利用者が定義した独自のものをカスタムメトリクスと呼びます。

-例-
・Webサーバー用のEC2インスタンスのCPU利用率が80％を超えるとき
・定期実行するLambda関数が一定期間に3回以上エラー発生したとき

  • CloudWatch Logs

    • アプリケーションログやApacheログなどをモニタリングするサービス。
    • 独自のエージェントをインストールする必要がある。

  • CloudWatch Events

    • 独自のトリガー(イベントソース)と何かしらの後続アクション(ターゲット)との組み合わせを定義するサービス。
    • イベントソースには、期間(時間)ベースのトリガー定義のスケジュールと、AWSリソースの状態変化のトリガー定義するイベントの2種類があります。
    • ターゲットには、既存のAWSリソースに対するアクションを定義する。

CloudTrail

AWSに関する操作ログを自動的に取得するサービス。
「誰が」「いつ」「どのような操作をしたか」といった監査ログを記録しておくことが重要。

  • 取得できるログの種類

    • 管理イベント(マネジメントコンソールへのログイン、EC2やS3バケットの作成など)
    • データイベント(S3バケット上のデータ操作、Lambda関数の実行など)
    • 管理イベントはデフォルトで取得しているが、データイベントは設定しないと取得しない。

  • CloudWatch Logsとの連携

    • ユーザーが不正な操作をしたことを自動検知したいときには連携する。
    • 事前に不正な操作(ログメッセージや文字列)を登録しておき、ユーザーがそれに該当する行動をしたときに検知することができる。

AWSのストレージサービスについて

主なサービスは以下の5つです。

  • Amazon EBS　　　　　　・・・①
  • Amazon EFS　　　　　　・・・②
  • Amazon S3　　　　　　 ・・・③
  • Amazon Glacier　　　 　・・・③
  • AWS Storage Gateway

これらは3つのタイプに分類される。

①ブロックストレージ
データを物理的なディスクにブロック単位で管理するストレージ。
データベースや仮想サーバーのイメージ保存領域のように、頻繁に更新されたり高速なアクセスが必要とされる用途で使われる。

②ファイルストレージ
①上にファイルシステムを構成し、データをファイル単位で管理するストレージ。
複数のクライアントからネットワーク経由でファイルにアクセスするといったデータ共有や、過去データをまとめて保存するといった用途で使われる。

③オブジェクトストレージ
ファイルに任意のメタデータを追加してオブジェクトとして管理するストレージです。
更新頻度の少ないデータや大容量のマルチメディアコンテンツ(※15)を保存する用途で使われます。

EBS(Elastic Block Store)

EC2のOS領域として利用したり、追加ボリュームとして複数のEBSをEC2にアタッチすることが可能。
指定したリージョン以外のEC2インスタンスにはアタッチできないので、スナップショットを利用してボリュームを作成しアタッチする。

  • ボリュームタイプ

    • 汎用SSD(gp2)とは、最も一般的でSSD(※16)をベースとしたボリュームタイプです。1001IOPSから最大10000IOPS/ボリュームまで容量に応じたベースライン性能があり、一時的なIOPS(※17)の上昇に対応できるよバースト機能もあります。
    • プロビジョンドIOPS SSD(io1）とは、最も高性能なSSDをベースとしたボリュームタイプです。501IOPS/GBから最大64000IOPS/ボリュームまで容量に応じたベースライン性能があります。
    • スループット最適化HDD(st１)とは、HDDをベースとしたスループット(※18)重視のボリュームタイプです。ログデータに対する処理やバッチ処理のインプット用ファイルなど、大容量ファイルを高速に読み取るようなユースケースに適している。
    • Cold HDD(sc１)とは、最も低コストのボリュームタイプです。データをシーケンシャル(※19)にアクセスするようなユースケースや、アーカイブ領域の用途に適している。

  • EBSの拡張と変更

    • 必要に応じて何度でも拡張可能だが、縮小はできません。
    • プロビジョニンドIOPS対応で指定したIOPS値については、増減どちらも可能。
    • 変更作業を行なった場合、同一のEBSボリュームへの変更作業は6時間以上開ける必要がある。
    • 現行世代以外のEC2インスタンスタイプで使用中のEBSボリュームに対する変更作業では、インスタンスの停止やEBSのでタッチが必要になる。

  • 可用性・耐久性

    • 内部的にAZ内の複数の物理ディスクに複製が行われており、AWS内で物理的な故障が発生した場合でも利用者が意識することはほぼない。

  • セキュリティ

    • 暗号化オプションを有効にすると、ボリュームだけでなく、スナップショットも暗号化される。

EFS(Elastic File System)

容量無制限で複数のEC2インスタンスから同時にアクセス可能なファイルストレージサービスです。
システムに最適なモードを選択する必要がある。

  • 構成要素

    • ファイルシステム、マウントターゲット、セキュリティグループで構成されており、ファイルが作成されると自動的に3箇所以上のAZに保存される分散ファイルシステムを構成します。
    • ファイルシステムにアクセスするために、AZごとにサブネットを指定してマウントターゲットを作成する。マウントターゲットにはセキュリティグループを指定でき、EC2からEFSへの通信要件を定義して不要なアクセスを制限できる。

  • EFSのパフォーマンスモード

    • 汎用パフォーマンスモードが一般的なので、ほとんどの場合はこちらを使用する。
    • ただし、大量のアクセスがある場合は最大I/Oパフォーマンスモードを選択する。
    • どちらを使えば良いかの判断は、CloudWatchのPercentlOLimitを参考にする。80%以上の場合は最大の方を利用する。

  • EFSのスループットモード

    • バーストスループットモードとは、EFSに保存されているデータ容量に応じてベースラインとなるスループットは設定されている。一時的なスループットの上昇に耐えられるモードです。
    • プロビジョニングスループットモードとは、上記のモードで設定されているベースラインスループットを大幅に上回るスループットが必要な場合や、一時的なバースト時にバーストスループットで定められている最大スループットよりも高性能が必要な場合に、任意のスループット値を指定することができるモードです。
    • どちらのモードを選択するかの判断は、CloudWatchのBurstCreditBalanceを参考にする。クレジットバランスを使い切ってしまったり、常に減少傾向である場合はプロビジョニングスループットモードを選択する。

S3(Simple Storage Service)

非常に優れた耐久性を持つ、容量無制限のオブジェクトストレージサービスです。
ディレクトリ構造を持たないフラットな構成であり、メタデータ(※20)を付与できる。
主なユースケースは以下の通りです。

・データのバックアップ
・ビッグデータ解析用などのデータレイク
・ETLの中間ファイル保存
・Auto Scaling構成されたEC2インスタンスやコンテナからのログ転送先
・静的コンテンツのホスティング
・簡易的なKey-Value型のデータベース

  • S3の構成要素

    • バケット(オブジェクトを保存するための領域)
    • オブジェクト(S3に格納されるデータそのもの)
    • メタデータ(オブジェクトを管理するための情報)

  • 耐久性と整合性

    • S3に保存されたデータは、複数のAZ、さらにはAZ内の複数の物理的ストレージに複製されるため高い耐久性が維持出来る。
    • 結果整合性方式を採用しており、データ保存後に複製が完全に終了するまでの間にデータ参照すると保存前の状態になる可能性があるので注意する。

  • ストレージクラス

    • STANDARDは、デフォルトのストレージクラスです。
    • STANDARD-IAは、格納コストが安価なストレージクラスです。高速なアクセスが必要だけどアクセスが低頻度の場合はこちらを利用する。
    • ONEZONE-IAは、単一のAZ内のみでデータを複製するストレージクラスです。AZで障害が発生した場合はデータ消失される。
    • INTELLIGENT-TIERINGは、参照頻度の工程を明確に決めることができないデータを扱う場合に有効なストレージクラスです。30日以上参照されなかったデータは、STANDARD-IAに移動される。
    • GLACIERは、ほとんど参照されないアーカイブ目的のデータを保存するストレージクラスです。
STANDARD STANDARD-IA ONEZONE-IA INTELLIGENT-TIERING GLACIER
可用性 99.999999999% 99.999999999% 99.999999999% 99.999999999% 99.999999999%
耐久性 99.99% 99.9% 99.5% 99.9% 99.99%

  • ライフサイクル管理

    • 移行アクションとは、データの利用頻度に応じて、ストレージクラスを変更するアクションで、その時に応じた最適なストレージクラスへ移行してくれる。
    • 有効期限アクションとは、指定した期限を超えたオブジェクトをS3から削除するアクションです。

  • バージョニング機能

    • 1つのオブジェクトに対して複数のバージョンを管理することが出来ます。バケット単位で有効か無効を指定できます。

  • Webサイトホスティング機能

    • 静的コンテンツに限り、Webサイトとしてホスティングする環境を作成できる。動的なコンテンツは使用できません。
    • Webサイトホスティングを設定すると自動的にドメインが作成される。そのサイトに独自ドメインでアクセスしたい場合はRoute53などのDNSにCNAME情報を設定します。この時、バケット名とドメイン名は一致させる。

  • アクセス管理

バケットポリシー ACL IAM
AWSアカウント単位の制御 ○ ○ ×
IAMユーザー単位の制御 △ × ○
S3バケット単位の制御 ○ ○ ○
S3オブジェクト単位の制御 ○ ○ ○
IPアドレス・ドメイン単位の制御 ○ × ○

  • 署名付きURL

    • アクセスを許可したいオブジェクトに対して期限を指定してURLを発行する機能。
    • URLを知っていれば誰でもアクセスできるので注意する。

  • データ暗号化

    • サーバー側での暗号化では、データがストレージに書き込まれるときに暗号化され、読み出す時に復号化されます。
    • クライアント側では、AWS SDKを用いてS3に送信する前に暗号化され、メタデータからどのキーで復号化するのか判別されたときに復号化される。

Glacier

S3同様にイレブンナインの耐久性を持ちながら、容量当たりの費用を抑えたストレージサービスです。
オンプレミス環境での磁気テープのように長期間保存し、アクセス頻度が低く取り出しにある程度時間がかかっても大丈夫なデータを保存するユースケースに適している。

  • 構成要素

    • ボールト(アーカイブを保存する領域、S3のバケットに相当)
    • アーカイブ(格納されるデータ自身、S3のオブジェクトに相当)
    • インベントリ(各ボールドに保存されているアーカイブ情報を収集する。)
    • ジョブ(アーカイブやインベントリに検索をかけたり、データをダウンロードといった要求に対しての処理を実行し、処理状況を管理する。)

  • データの取り出しオプション

    • アーカイブしたデータを閲覧するには、データの取り出しリクエストを出します。高速・標準・バルクといったリクエストオプションがあるので最適なものを選ぶ。

  • Glacier Select

    • アーカイブデータに対してSQLを実行して、条件に合ったデータを抽出する機能。

  • データ暗号化

    • 保存されるデータは標準で暗号化される。
    • 独自の暗号化方式を取りたい場合は、Glacierに保存する前にデータを暗号化する。

Storage Gateway

オンプレミスにあるデータをクラウドへ連携するための受け口を提供するサービス。
それぞれ、参照頻度の高いものや低いものに分類してS3などに保存していく。

  • タイプ
    • ファイルゲートウェイは、S3をクライアントサーバーからNFSマウント(※21)して、あたかもファイルシステムのように扱うことができるタイプのゲートウェイ。
    • ボリュームゲートウェイは、データをS3に保存し、S3の保存領域全体を１つのボリュームとして管理する。
    • テープゲートウェイは、テープデバイス(※22)の代替としてS3やGlacierにデータをバックアップするタイプのゲートウェイです。
ゲートウェイタイプ Storage Gatewayの配置先 S3での保存単位 S3への保存タイミング プライマリデータの保存場所 ファイルキャッシュ クライアントインターフェイス S3 APIからのアクセス
ファイル オンプレミス、EC2 ファイル 非同期ほぼリアルタイム S3 あり NFS v3,v4.1 可
キャッシュ型 オンプレミス、EC2 ボリューム 非同期スナップショット S3 あり iSCSI 不可
保管型 オンプレミス ボリューム 非同期スナップショット ローカルディスク あり iSCSI 不可
テープ オンプレミス、EC2 仮想テープ 非同期バックアップ ローカルディスク なし iSCSI 不可
  • セキュリティ
    • CHAP認証とは、クライアントからStorage GatewayにiSCSI(※23)で接続する際に設定することができる。なりすましや通信の盗聴の防止が可能。
    • データ暗号化は、AWS KMSを使って行う。S3に保存されるタイミングで暗号化される。
    • 通信の暗号化はオンプレミス環境からStorage Gateway経由でS3データを転送する際にはHTTPSが使用されるため暗号化される。

RDS(Relational Database Service)

AWSが提供するマネージドRDBサービスです。MySQLやPostgreSQL、Oracleなどのオンプレミスでも使い慣れたデータベースエンジンを選択できる。
さらに、Auroraというクラウドのメリットを最大限に活かしたアーキテクチャのRDSも提供されている。

  • RDSで使えるストレージタイプ

    • データ保存ストレージにはEBSを利用する。その中でも、「汎用SSD」「プロビジョニングIOPS SSD」「マグネティック」が利用可能だが、基本的にはSSDを使用する。
    • 拡張中は若干のパフォーマンス劣化が見られるため、利用頻度が低い時間帯に実施する。

  • RDSの特徴

    • 1つのリージョン内に2つのAZにDBインスタンスをそれぞれ配置し、障害発生時やメンテナンス時のダウンタイムを短くして高可用性を実現するためにマルチAZ構成が推奨されている。これにより、書き込み速度が遅くなったり、フェイルオーバー(※24)に60〜120m秒かかってしまうデメリットもあることを知っておく。
    • 通常のRDSとは別に参照専用のDBインスタンスを作成するサービスであるリードレプリカが、MySQL、Aurora、MariaDB、PostgreSQLで利用可能。これによって、マスターDBの負荷を抑えたり、読み込みが多いアプリケーションにおいてDBリソースのスケールアウトを容易に実現可能。マスターとリードレプリカは非同期レプリケーション方式である。

  • バックアップ/リストア

    • バックアップウィンドウと保存期間を指定することで1日に1回自動バックアップを取得してくれる。バックアップの保存期間は最大35日である。
    • 任意のタイミングでRDBのバックアップを取得することができる。1リージョンあたり100個までの手動スナップショットしか取得できないので注意する。
    • RDSにデータをリストアする場合は、自動バックアップ及び手動スナップショットから新規のRDSを作成できる。
    • ポイントインタイムリカバリーという、直近5分前から最大35日前までの任意のタイミングの状態のRDSを新規に作成出来るサービスがある。戻すことが出来る最大日数は自動バックアップの取得期間に準ずるので自動バックアップを有効かしておく。

  • セキュリティ

    • ネットワークセキュリティとは、インターネットに接続出来ないAWSのVPCネットワーク内で利用可能なサービスです。EC2同様、セキュリティグループによる通信要件の制限が可能。
    • RDSの暗号化オプションを有効にすることで、データが保存されるストレージやスナップショットだけでなく、ログなどのRDSに関連する全てのデータが暗号化された状態で保持されます。

  • Amazon Aurora

    • DBインスタンスを作成すると同時にDBクラスタが作成される。このDBクラスタは、1つ以上のDBインスタンスと、各DBインスタンスから参照するデータストレージで構成される。クラスタボリュームは単一リージョン内の3つのAZにそれぞれ2つのデータコピーで構成され、各ストレージ間のデータは自動的に同期される。
    • 他のRDSと異なりマルチAZ構成オプションは無い。しかし、Auroraクラスタ内に参照専用のレプリカインスタンスが作成可能。
    • Auroraでは作成されるエンドポイントが3種類あり、プライマリインスタンスに接続するためのクラスタエンドポイントと、レプリカインスタンスに接続するための読み取りエンドポイントと、Auroraクラスタを構成するDBインスタンスに接続するためのインスタンスエンドポイントがある。

Redshift

AWSが提供するデータウェアハウス(※25)向けのデータベースサービスです。大量のデータから意思決定に役立つ情報を見つけ出すために必要な環境を素早く安価に準備できる。

  • Redshiftの構成

    • 複数ノードによる分散並列実行(※26)が大きな特徴です。この複数ノードのまとまりをRedshiftクラスタと呼び、1つのリーダーノードと複数のコンピュートノードから構成されている。
    • コンピュートノードはノードスライスという最小の単位で構成されています。

  • Redshiftの特徴

    • 列指向型データベースなので、大容量のデータに対して集計処理を実行する場合に優れたパフォーマンスを発揮する。
    • 9種類の圧縮エンコード(※27)方式に対応しており、ディスクI/O(※28)をさらに軽減することができる。
    • ブロック単位でデータが格納されており、データの最小と最大値をメモリに保存する仕組みがあります。これをゾーンマップと言います。
    • 1回の集計処理を複数のノードに分散して実行する仕組みのMPPと、ノードとディスクセットで拡張する仕組みのシェアードナッシングによって柔軟な拡張性を実現している。
    • Redshift Spectrumは、S3に置かれたデータを外部テーブルとして定義できるようにし、Redshift内にデータを取り組むことなくクエリの実行可能にする拡張サービスがある。

DynamoDB

AWSが提供するマネージドNoSQLデータベースサービスです。テーブルやインデックスを作成する際に、読み取り・書き込みに必要なスループットを指定してリソースを確保することで、安定した性能を担保する仕組みになっている。

・高い信頼性と拡張性を必要とするシステム
・スループットが増減するようなピーク帯のあるシステム
・大量のデータを蓄積して高速な検索が可能なシステム
・広告やゲームなどのユーザー行動履歴を管理するシステム
・Webアプリケーションの永続的セッションデータベース

  • DynamoDBの特徴

    • 単一障害点を持たない構成となっているおり、自動的に3つのAZに保存される仕組みになっているので非常に可用性が高いサービスです。

  • スループットキャパシティ

    • RCUとは読み取りのスループットキャパシティを指定する指標で、WCUとは書き込みのスループットキャパシティを指定する指標です。
    • スループットキャパシティの変更は増加させるのに制限はないが、減少については1日9回までの制限がある。

  • データパーティショニング

    • データをパーティションという単位で分散保存する。データの増加や指定したスループットのサイズによって最適化された状態を保つようにパーティションを拡張します。この生業は自動的に行われる。

  • プライマリーキーとインデックス

    • プライマリーキーは、データ項目を一意に特定するための属性で、「パーティションキー」単独のものと、「パーティションキー＋ソートキー」の組み合わせで構成されるものの2種類がある。
    • インデックスとしても利用され、データ検索の高速化に役立ちますが、プライマリーキーだけでは高速な検索要件を満たすことが出来ない場合はセカンダリインデックスを作成する。プライマリーキーはテーブルで指定したパーティションキーと同じで、別の属性をソートキーとして作成するインデックスのことをローカルセカンダリインデックスと、プライマリーキーとは異なる属性を使って作成するグローバルセカンダリインデックスがあります。

  • 期限切れデータの自動メンテナンス(Time to Live、TTL)

    • DynamoDB内の各項目には有効期間を設定でき、期間が過ぎたデータは自動削除される。最大48時間以内に削除されます。

  • DynamoDB Streams

    • DynamoDBに対して行われた直近24時間の追加・更新・削除の変更履歴を保持する機能。

  • DynamoDB Accelerator(DAX)

    • DynamoDBの前段にキャッシュクラスタを構成する覚醒サービスです。これを利用すると、毎秒数百万もの読み取り処理でもマイクロ秒単位での応答を実現します。

ElastiCache

AWSが提供するインメモリ型データベースサービスです。高頻度で参照するデータや検索に時間がかかるデータセットをメモリ上に保持することでシステムのパフォーマンス向上に寄与します。
KVS型インメモリデータベースのデファクトスタンダード(※29)として利用されているエンジンであるMemcachedと、KVSインメモリデータベースであり、より多くのデータ型が扱えてキャッシュ用途だけでなくメッセージブローカーやキューを構成する要素としても利用できるRedisの2つのエンジンをサポートしている。

  • Memcached版の特徴

    • 最大20のElastiCacheインスタンスで構成されている。クラスタ内に保存されるデータは各インスタンスに分散されます。
    • スケールアウト/イン/アップ/ダウンの4つのスケーリングから必要に応じてリソースを調整できます。

  • Redis版の特徴

    • クラスタモード無効の場合、キャッシュデータはすべて1つのElastiCacheインスタンスに保存される。
    • クラスタモード有効の場合、最大15のシャードにデータを分割して保存する構成が可能。

IAM(Identity and Access Management)

IAMポリシー、ユーザー、グループ、ロールといった機能を用いて、権限を付与してセキュリティ向上できるAWSのサービスです。
最低限の権限を付与することが重要です。以下の手順を基本として権限を付与していけば良い。

①AWSサービスやリソースに対する捜査権限をIAMポリシーとして定義する。
②IAMポリシーをIAMユーザーやIAMグループにアタッチする。
③IAMユーザーあるいはIAMグループに属するIAMユーザーがマネジメントコンソールにログインすると、付与された権限の操作を行うことができる。

  • IAMポリシー

    • Action(どのサービスの)、Resource(どういう機能や範囲を)、Effect(許可/拒否)といったルールに基づいて権限付与の設定を行う。
    • 対象ごとに作成・付与するポリシーで、複数のユーザー・グループに同種の権限を付与することに向いていないポリシーをインラインポリシーと呼びます。
    • 1つのポリシーを複数のユーザーやグループに適用出来るポリシーを管理ポリシーと言います。AWS側が用意していて、管理者権限やサービスごとのポリシーがあるAWS管理ポリシーと、ユーザー自身が管理して、最大5世代前までバージョン管理出来るカスタマー管理ポリシーの2種類があります。

  • IAMユーザー

    • ユーザーIDとパスワードで認証する方法と、アクセスキーとシークレットアクセスキーで認証する方法があります。

  • IAMグループ

    • 　同じ権限を持ったユーザーの集まり。複数のユーザーに同一の権限を与えることができる。
    • 　一定の権限をまとめておき、ユーザーに必要なグループに割り当てる。

  • IAMロール

    • 一時的にAWSリソースへのアクセス権限を付与する場合に使う。
    • AWSリソースへの権限付与や、クロスアカウントアクセス(複数のAWSアカウント間のリソースを1つのIAMユーザーで操作)、IDフェデレーション(社内のADサーバーに登録されているアカウントを使用してAWSリソースにアクセス)、WebIDフェデレーション(Googleなどのアカウントを使用してAWSリソースへアクセス)などで利用すると良い。

#KMS(AWS Key Management Service)とAWS CloudHSM

暗号化鍵の作成と管理のためのサービスです。
通常使うのは圧倒的にKMSが多いが、秒間100を超える暗号化リクエストがある場合などはCloudHSMを使う。
2つの主な違いは以下の表を参照。

CloudHSM KMS
専用性 VPCないの専用ハードウェアデバイス AWSが管理するマルチテナント
可用性 ユーザーが管理 AWS側が高可用性・耐久性を設計
信頼の起点 ユーザーが管理 AWSが管理
暗号化機能 共通鍵及び公開鍵 共通鍵
コスト ほぼ固定費 従量課金

  • KMSの機能

    • 主な機能は鍵管理機能とデータ暗号化機能があります。
    • データ暗号化機能は、Encrypt(データを暗号化)とDecrypt(データを復号化)、GenerateDataKey(ユーザーがデータの暗号化をするためのカスタマーデータキーを作成する)といったAPIがあります。

  • KMSのマスターキーとデータキー

    • マスターキーは、Customer Master Key(CMK)と呼び、データキーは、Customer Data Key(CDK)と呼ばれています。
    • CMKがデータキーを暗号化するもので、CDKがデータを暗号化するものです。
    • データキーでデータを暗号化して、そのデータキーをマスターキーで暗号化する手法を、エンべローブ暗号化と言います。

  • クライアントサイド暗号化とサーバーサイド暗号化

    • クライアントサイド暗号化は、ユーザー側の処理で暗号化する方式です。
    • サーバーサイド暗号化は、AWS側の処理で暗号化する方式です。基本的にはこちらを用いる。

AWS Certificate Manager

サーバーの信頼性を確認するためにサーバ証明書というものが利用されます。
その際に利用されるプロトコルがSSL(Secure Sockets Layer)/TLS(Transport Layer Security)で、SSL証明書と呼ばれることが多いです。
現在は、TLSが主流でSSLは脆弱性があり非推奨とされています。

  • 証明書の役割のと種類

    • 経路間の通信の安全性の確保と、通信している誰かの証明を実現することが出来ます。
    • SSL証明書は、認証局(CA)という機関により発行されている。
    • 証明方法は、自己証明書(自分で認証局を立てて証明書を発行する)と、ドメイン認証(ドメインの所有のみを認証)と、組織認証(組織情報の審査を経てから認証する)と、拡張認証(組織認証より厳格な審査で認証する)の4つがあります。

  • ACM(AWS Certificate Manager)

    • AWS自身が認証局となってDV(拡張認証)証明書を発行するサービスのこと。
    • 初期設定時には、ドメインの所有の確認が必要です。

  • 連携可能なサービス

    • Elastic Load Balancing のうち、ALBのみ。
    • Amazon CloudFront
    • AWS Elastic Beanstalk
    • Amazon API Gateway

CodeCommit

ソースコード管理のためのGitリポジトリサービスを提供するマネージドサービスです。
IAMユーザーを用いて権限管理を行います。
HTTPS方式でアクセスする場合は、コンソール上で下記コマンドを利用し、ローカル環境にあるIAMのクレデンシャル情報を用いてGitに接続する。


$ git config --global credential.helper '!aws --region ap-northeast-1 --profile CodeCommitUser codecommit credential-helper $@'

$ git config --global credential.UseHttpPath true

SSH方式でアクセスする場合は、ターミナル上で秘密鍵と公開鍵を作成し、公開鍵をマネジメントコンソールでIAMユーザーに紐づけることでGitリポジトリに接続する。

  • AWSサービスとの連携
    • Gitリポジトリで何らかのイベントが発生した際に、それをトリガーにSNSトピックを呼び出せる。
    • SNSトピック経由でほかのAWSサービスと連携できます。

CodeBuild

その名の通りソースコードのコンパイル/ビルド環境を提供するマネージドサービスです。
CodeBuild上でユニットテストを実行することが出来て継続的な品質の担保にも貢献する。
ビルド環境のランタイムとしては、JavaやPHP、Python、Rubyなどを標準サポートしているほか、Dockerイメージも利用可能です。
ビルド対象のソースコード取得元は、外部プロバイダーのGitHubなども利用できます。

  • ビルドの定義
    • ビルド環境上で何をするかは、buildspec.ymlに定義する。
buildspec.yml

version: 0.2

phases:
  build:
    commands:
      - echo Build started on `data`
      - mvn test
  post_build:
    commands:
      - echo Build completed on `data`
      - mvn package
  artifacts:
    files:
      - target/my-app-1.0-SNAPSHOT.jar
      - appspec.yml
    discard-paths: yes
  • 料金
    • ビルドにかかった時間単位の従量課金となります。
    • アプリケーションの成長に伴い、ビルド負荷が高まってきたタイミングで、環境のスペックを上げることも可能です。

CodeDeploy

ビルド済みのモジュールのサーバーへのデプロイを自動化するサービスです。

  • デプロイ先を選択可能
    • EC2やLambda、オンプレミスサーバーに対してモジュールをデプロイできる。
    • デプロイ時にどのモジュールをどこに配置するかといった設定はappspec.ymlに定義する。
appspec.yml

version: 0.0
os: linux
files:
  - source: index.php
    destination: /var/www/html/
  - source: img
    destination: /var/www/html/img/
hooks:
  BeforeInstall:
    - location: script/clean.sh
      runas: root
  • デプロイ方式を選択可能
デプロイ方式 具体的な動き
AllAtOnce 関連するサーバー全てに同時のデプロイを行う。リリース時間が短いが、システム全体でダウンタイムが発生する。
HalfAtTime 関連するサーバーの半分のリソースに対してデプロイを行う。半分のリソースでもこう負荷にならない設計が必要。
OneAtTime 関連するサーバーを1つずつデプロイする。負荷は少ないが時間がかかる。
  • デプロイ対象のサーバーが増減する場合
    • AutoScalingグループをデプロイ対象として選択出来るため、この問題に簡単に対処できます。

CodePipeline

ソースコードのプッシュ、ビルド、デプロイといったサイクルを自動化されたパイプラインを作成することができます。

Elastic Beanstalk

定番のインフラ構成を自動構築するサービスです。アーキテクチャのパターンは限られていますが、適切な環境を素早く用意出来て、予め用意されたサンプルアプリケーションを最初からデプロイすることも可能です。

・Webサーバー構成(ELB+AutoScaling+EC2)
・Batchワーカー構成(SQS+AutoScaling+EC2)

構築できる構成は大きく分けて上記2つです。
それぞれ低コストの構成か、高可用性の構成かを選択出来ます。

  • 利用方法

    • マネジメントコンソールから利用することが出来る。
    • AWS Toolkit for Eclipseという、Eclipseから利用できるツールも提供されています。
    • AWS CLIや、Elastic Beanstalk専用のEB CLIというクライアントツールも提供されています。

  • アプリケーションデプロイのサポート

    • デプロイ方式は、デプロイにかかる時間や、システム停止時間をどれだけ許容できるかと言った方針から選ぶことになる。
デプロイの進め方 メリット デメリット
All at Onceデプロイ 全ての「既存の」インスタンスを一気にデプロイする。 デプロイ時間が短い。 システムが全停止する可能あり。デプロイ失敗時はやり直しなので、時間がかかる。
Rollingデプロイ 「既存の」インスタンスの一部をELBから切り離しデプロイする。 システム全停止の危険性がない。デプロイ失敗時も影響が少ない。 他と比べて比較的時間がかかる。
Rolling with additional batchデプロイ インスタンスを新規作成しデプロイする。 システム全停止の危険性がなくなる。縮退構成になる期間がない。デプロイ失敗時のリスクが少ない。 新しくインスタンスを作成する分、かなり時間がかかってしまう。
immutableデプロイ インスタンスを新規に一つ作成してデプロイする。 これまでのデプロイ方式の中で最も切り戻ししやすく、リスクが小さい。 全てのインスタンスを新規作成するのでデプロイに時間がかかる。
ebコマンドによるURL Swapデプロイ ebコマンドを利用してCNAMEを切り替えるブルーグリーンデプロイメント 旧環境が残っているので間違いがあれば戻せる。 環境を全て作り直すためとても時間がかかる。
ebコマンドによるRoute53レイヤーでの切替デプロイ ebコマンドを利用して、Route53の設定を変更するブルーグリーンデプロイメント URL Swapデプロイと同じ。 URL Swapデプロイと同じ。

OpsWorks

Chefを利用した構成管理サービスです。レシピと呼ばれるファイルにサーバーの構成を定義して、ミドルウェアのインストールや設定を自動化するツールです。

-例-
Apacheのインストール、サーバー起動時の自動プロセス立ち上げ設定、httpdプロセスの立ち上げ。


package "httpd" do
  action :install
end

service "httpd" do
  action [ :enable, :start ]
end

  • OpsWorksスタック

    • スタックとは、OpsWorksのトップエンティティ。スタック単位の構成情報をJSON形式で保持する。
    • レイヤーとは、インスタンスの特性ごとにレイヤーを用意する。

  • OpsWorks for Chef Automate

    • Chefを統合的に利用するための機能。レシピが適用される各インスタンスをクライアントと呼び、それらとは別にクライアントを管理するマスターサーバーが存在するアーキテクチャを採用している。

CloudFormation

AWSリソースを自動構築するためのサービスです。
利用する際は以下の流れで行います。

1.CloudFormationテンプレートを作成する。
2.テンプレートを適用する。
3.CloudFormationスタックが作成され、それに紐づく形でAWSリソースが自動構築される。

  • CloudFormationのスタック

    • CloudFormationで構築されたAWSリソースはスタックという集合にまとめられる。テンプレートを修正し、スタックを指定して再度適用することで、スタック上のAWSリソースの設定を変更したリソースを削除したりできます。
    • 同一システム内でテンプレートを分割することで、複数のスタックにリソースを分けることもできます。

  • CloudFormationテンプレート

    • テンプレートはJSON形式化YAML形式で記述しますが、基本的にはYAMLで良いでしょう。

  • Resourcesセクション

    • Resourcesセクションとは、構築するAWSリソースの設計を書きます。各リソースには論理IDをつける必要があります。公式ドキュメントを見ながら1つずつ定義していきましょう。

Resources:
  cfnVpc:  # 論理ID
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: '192.168.0.0./16'
      Tags:
        - Key: 'Name'
          Value: 'cfn-vpc'
  • Parametersセクション
    • Parametersセクションとは、実行時に値を選択する項目を定義するセクションです。

Parameters:
  InsranceType:
    Type: String
    Default: t2.micro
    AllowedValues:
      - t2.micro
      - t2.small
      - t2.medium
    Description: Select EC2 instance type.
  cfnEC2Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      InstanceType: !Ref InstanceType  # Parametersセクションの値をRef関数で取得
  以下省略
  • Mappingsセクション
    • 変数をMap形式で定義できます。実行環境によって変わる値を定義するのに用いることが多いです。
    • この変数を使う際は、FindInMap関数を用いて参照する。

Mappings:
  RegionMap:
    us-east-1:
      hvm: 'ami-a4c7edb2'
    ap-northeast-1:
      hvm: 'ami-3bd3c45c'

以下のように参照します。


  cfnEC2Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      ImageId: !FindInMap [ RegionMap, !Ref 'AWS::Region', hvm ]
  • 組み込み関数
    • !Ref関数とは、AWSリソースの値や設定されたパラメータの値を取得する関数です。
    • FindInMap関数は、Mappingセクションで定義したMap型の変数を取得する際に使います。

Mappings:
  MappingName:
    Key1:
      Name1: Value11
    Key2:
      Name1: Value21  # この値を取得したいとすると、、
      Name2: Value22

以下の記述で取得可能です。


!FindInMap [ MappingName, Key2, Name1 ]

EMR(Elastic MapReduce)

分散処理フレームワークで、分散処理基盤と分散処理アプリケーション基盤の2つの機能で構成されている。

  • EMRのアーキテクチャ

    • マスターノード、コアノード、タスクノードの3種類のノードで構成される。
    • マスターノードは、コア・タスクノードにジョブを振り分けます。1台のみ存在し、フェイルオーバーできません。
    • コアノードとタスクノードは、どちらもジョブを実行します。コアノードはデータを保存する領域であるHDFS(Hadoop Distributed File System)をもち、タスクノードは持っていません。

  • 分散処理基盤としてのEMR

    • 分散処理に必要なEC2の調達・廃棄などのリソース調整機能と、S3を分散処理に扱いやすいストレージとして扱う機能がある。
    • リソースの調整機能としては、伸縮自在性とコストが重要になる。
    • コストの観点では、EMRには分析費用を小さくする機能があります。

  • EMRとコスト

    • EMRを使う際は、まず分散処理できるようにアプリケーションを適合させ、その上でスポットインスタンスを利用できるようにするのが良い。
    • 分散処理を早く低コストで実行するために、オートスケールとスポットインスタンスの組み合わせが最適なケースになることが多い。

ETL(Elastic Transform Load)ツール

データソースからのデータの抽出・変換・投入の役割を果たします。AWSのETL関連サービスで特に重要なのがKinesisです。

  • Kinesis

    • AWSが提供するストリーミング処理プラットフォームです。
    • センサーやログなどのデータをリアルタイム/準リアルタイムで処理するData　StreamsとData Firehose、動画を処理するVideo Streams、収集したデータを可視化・分析するData Analyticsという4つの機能がある。

  • Data Pipeline

    • データ処理やデータ移動を支援するサービスです。これでパイプラインを設定すると、オンプレミスやAWS情の特定の場所に定期的にアクセスし、必要に応じてデータを変換し、S3、RDS、DynamoDBなどのAWSの各種サービスに転送します。
    • 例外処理の設計・実装の手羽が少なくインフラ運用の負荷も少ない。

回復性の高いアーキテクチャ

以下の5つの構成要素で構成されています。

  • 復旧手順のテスト

    • クラウドの場合は、仮想的にネットワーク機器などを専有できるので、障害の発生をシュミレーションしやすく、復旧手順のテストも容易になる。

  • 障害からの自動復旧

    • 閾値を設定し、負荷状況などが超過した場合にトリガーを設定することが出来る。それによりリソースの追加や、問題の発生したリソースの自動的な交換の設定が可能。
    • 閾値の検知には、CloudWatchを利用する。
    • 自動復旧は、ELBなどのロードバランサー配下のインスタンス群とAutoScalingを組み合わせて、定期的にヘルスチェックを行い、動的にインスタンスの増減などを行う。
    • DBの場合は、マルチAZ構成を取ることが基本です。マスター障害時に自動的にスタンバイがマスターに昇格して復旧する。

  • スケーラブルなシステム

    • スケーラブルなシステムを検討する際は、水平方向の拡張(スケールアウト)が可能な仕組みを考える。
    • この構成にするには、増減するサーバーに状態を持たせない(ステートレス)にすることが大事です。具体的には、Webサーバーの場合はセッションを外部のサービスに出します。AWSの場合は、ElastiCacheを利用する。
    • もう一つ、個々のリソースのサイズをできるだけ小さくすることが大事です。サイズが大きいと負荷がかかっていない錠での無駄が大きくなるからです。

  • キャパシティ推測が不要であること

    • 水平方向に追加(スケールアウト)できるリソースは何か、あるいは垂直方向に拡張(スケールアップ)しないといけないリソースは何かを正しく知ることが重要です。
    • Webサーバーやアプリケーションサーバーはスケールアウトが容易です。
    • ただし、DBサーバーはスケールアウトが難しく、スケールアップすることが多いです。DBサーバーの一般的なスケーリングとしては、参照系と更新系に分離し、参照けにはリードレプリカを利用しスケールアウト可能とし、更新系はスケールアップして処理性能をアップさせる。

  • 変更管理の自動化

    • 構成管理の自動管理には、CloudFormationやAWI、OpsWorksなどが利用されます。

パフォーマンスに優れたアーキテクチャ

パフォーマンスに優れたアーキテクチャの第一歩は、適切なリソースを選択することです。
コンピューティングやストレージ、データベース、ネットワークが主なリソースです。

  • コンピューティングリソース

    • インスタンス(EC2、Elastic Beanstalk)、コンテナ(ECS)、関数(Lambda)の選択肢があります。
    • 原則的にアプリケーションの可搬性を高めたいときや、アプリケーションのOSとの依存度を下げたいといった場合はコンテナを選ぶケースが多い。

  • ストレージリソース

    • インスタンスに紐付いたブロックストレージであるかを考える時はEBSが基本となります。
    • リソースをオブジェクト単位で扱える場合はS3が最適になります。
    • どのようにS3を使えるかを考えることが重要。

  • データベースリソース

    • データベースの選択については、RDBMSかNoSQLかの選択ができます。
    • RDBMSは汎用的で使いやすいです。RDSとAuroraの選択肢があり、AuroraはRDSの上位互換サービスです。
    • NoSQLは、ドキュメント指向、列指向、KVSなど様々なタイプがあります。大容量データ処理の場合は、列思考のRedshift、KVSの場合はインメモリデータベースでもあるElastiCacheを考える。それ以外の汎用的な使い方ができるのは、DynamoDBです。

  • ネットワークリソース

    • EC2インスタンスには、インスタンスごとにネットワーク帯域の限界が定められている。帯域を上げるにはインスタンスタイプを変更する必要があります。
    • インスタンスからEBSへのアクセスはネットワーク経由となる。
    • EC2ではEBS最適化というオプションが設けられている。EBS専用のネットワークを用意するオプションのことです。

  • リソースの確認とモニタリング

    • モニタリングにはClouWatch、自動対処にはSQSやLambdaを利用する。

  • トレードオフの判断

    • トレードオフの判断とは、どこで処理をするかの決定です。具体的にはキャッシュの活用です。
    • キャッシュの使い方は、データベースのキャッシュ(ElastiCache)と、コンテンツ(CloudFront)のキャッシュがあります。

セキュアなアプリケーションおよびアーキテクチャ

AWSにおけるセキュリティには、AWS利用に関するセキュリティと、構築システムのセキュリティの2つの観点があります。

  • AWS利用に関するセキュリティ

    • AWSのアクセスにはIAMを利用します。
    • まず利用者ごとのIAMユーザー作成が必要です。AWSルートアカウントは通常の運用には使用しません。パスワードポリシーの設定や多要素認証を設定します。操作の追跡にはCloudTrailを利用し、設定履歴の確認にはAWS　Configを利用する。
    • 最小権限の原則に則り、IAMユーザーやIAMロールには必要な操作権限を最小限に付与することが重要です。

  • 構築システムのセキュリティ

    • 1つはレイヤーごとの防御です。ネットワークレイヤーの保護ではVPCが前提となり、セキュリティグループやネットワークACLをどのように活用するかがポイントです。あるいは、S3などのAWSリソースにインターネットを経由しないでアクセスするためのVPCエンドポイント/プライベートリンクをどのように利用するか重要。
    • もう1つはデータの保護です。バックアップ(S3のライフサイクル機能)やバージョニング(S3)、暗号化(EBSやS3の暗号化機能、KMS)があります。

コスト最適化アーキテクチャ

  • 需給の一致

    • あらかじめ大量のリソースを用意しないことが大切です。
    • CloudWatchでリソースの状況のメトリクスを計測し、EC2であればAutoScalingでリソースの調整を行うのが基本です。

  • インスタンス購入方法によるコスト削減

    • 通常使うインスタンスは、オンデマンドインスタンスと呼び、これを定価とします。
    • １年間もしくは３年間の利用を約束することで、３〜７割程度の割引を受けられるのが、リザーブドインスタンスと言います。常時使用することを前提とした価格体系となっています。
    • 時間でのAWSの余剰リソースを入札制で買うのがスポットインスタンスといい、最大９割ほどの割引を受けられることもあります。入札額を上回った場合は強制的に使用を中断されるので注意する。

  • アーカイブストレージの活用

    • 利用頻度の低いものはS3のライフサイクル機能を使ってGlacierにアーカイブするのが定番のコスト削減策です。

  • 通信量

    • 通信量の最適化をするには、CloudFrontを利用するのが良いです。通常の転送量に比べてコストを抑えることができます。
    • 転送地域によって価格が高くなる可能性があるので注意する。

  • コストの把握

    • CloudWatchとSNSの組み合わせを使うことによって、月内にあらかじめ定めた以上の金額に達した場合、メールなどで通知を受けることが可能です。

オペレーションエクセレンスを備えたアーキテクチャ

  • コードによるオペレーション

    • 運用の負荷軽減・品質のために運用の自動化を支援することをInfrastructure as Codeと呼ばれ、繰り返される手順を自動化することができる。
    • 構成を管理するのはCloudFormationを筆頭に、EC2に管理サービスとデプロイツールを付けたElastic Beanstalkや、アプリケーションのライフサイクルを支援するCode系サービスなど、様々なものがあります。

  • 障害時の対応

    • まず、障害の検知方法はSNSとCloudWatchとの組み合わせを利用し、対応方法としては、EC2のAutoScalingによる復旧があります。
    • また、RDSのマルチAZ構成も対応方法にあります。

  • 変更の品質保証

    • ロールバックしやすいリリース方法として、ブルーグリーンデプロイメントがあります。これは、稼働中のシステム(ブルー)に対して、リリース後のシステム(グリーン)を別に用意し、切り替えることでリリースする方式です。
    • ユーザーごとの分割リリースとして、ローリングデプロイメントやカナリアデプロイメントがあります。ローリングデプロイメントは、リソース中の一部のリソースを、カナリアデプロイメントは、最小のリソースセットを切り替える方式です。

##単語解説一覧

※1 オンプレミス
自社の中で情報システムを保有し、自社内の設備によって運用すること。

※2 VPN(Virtual Private Network)
離れた場所の間を仮想的な専用線でつないで安全なデータ通信を実現する仕組み。

※3 Direct Connect
AWS Direct Connectロケーションにユーザーの内部ネットワークを接続するためのサービスです。(通信媒体としてイーサーネット光ファイバーケーブルを利用)。

※4 プロトコル番号
上位層のプロトコルを識別するための番号であり、IPヘッダに 8 ビット情報であります。

※5 静的ホスティング
静的なWebサイトをホスティングすること。

※6 RTMP
Real-Time Messaging Protocolの略。
Adobe社の「Flash」で利用できるプロトコル（通信規約）の一つで、動画や音声のストリーミング配信・再生を行うためのもの。

※7 アクティブ/スタンバイ方式
同じシステムを複数用意して耐障害性を高めたシステムで、いくつか（2系統の場合は片方）を待機状態にして、障害時に切り替えて処理を引き継ぐ方式。

※8 ヘルスチェック
正常に稼働しているかを外部の別の機器などから監視あるいは検査すること。

※9 トラフィック
インターネットやLANなどのコンピューターなどの通信回線において、一定時間内にネットワーク上で転送されるデータ量のこと。

※10 フォールトトレラントアーキテクチャ
システムに異常が発生した場合でも、被害を最小限度に収める仕組みのこと。

※11 アプリケーションレイヤー
通信プロトコル（通信手順/通信規約）の機能や役割を階層構造で整理したモデルを構成する層の一つで、具体的なシステムやサービスに必要な機能を実装するための層。

※12 スケールアウト/イン
スケールアウトとは、システムを構成する仮想マシン（サーバー）の台数を増やすことをいいます。反対に、仮想マシンの台数を減らすことはスケールインという。

※13 ステートレス
システムが現在の状態を表すデータなどを保持せず、入力の内容によってのみ出力が決定される方式。同じ入力に対する出力は常に同じになる。

※14 プロビジョニング
必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくこと。

※15 マルチメディアコンテンツ
動画・音声・静止画・文章などを組み合わせたマルチメディアタイトルを作成するための素材の総称。

※16 SSD(ソリッドステートドライブ)
メモリーチップを媒体にした記録、読み出しを行う装置。

※17 IOPS(Input/Output Per Second、アイオプス)
ハードディスクやSSDなどのストレージ（外部記憶装置）の性能指標の一つで、ある条件の元で1秒間に読み込み・書き込みできる回数のこと。

※18 スループット
機器や通信路などの性能を表す特性の一つで、単位時間あたりに処理できる量のこと。

※19 シーケンシャル
対象が複数ある場合に、並んでいる順番に処理することや、連続して立て続けに処理すること。

※20 メタデータ
主となるデータの説明書きが書いてあるデータのこと。

※21 NFSマウント
LinuxなどUNIX系のOSで利用されるファイル共有システムである。NFSでは、データの実体はNFSサーバと呼ばれるファイルサーバに存在する。NFSクライアントは、NFSサーバの公開されたディレクトリをネットワーク越しにマウントする。この機能を使うと、複数のホストから同じファイルを共有することができる。

※22 テープデバイス
テープ ドライブのことであり、テープ ドライブの巻き戻し形式および圧縮機能の各ペアのこと。

※23 iSCSI(アイスカジー)
コンピュータ本体とストレージ（外部記憶装置）の通信に用いられるSCSIコマンドを、IPネットワーク経由で送受信する通信規約（プロトコル）。

※24 フェイルオーバー
稼働中のシステムで問題が生じてシステムやサーバーが停止してしまった際に、自動的に待機システムに切り替える仕組みのこと。

※25 データウェアハウス
各種データを時系列に保存するデータベースの利用形態の一つ。

※26 分散並列実行
認知科学における人間をコンピューターのような記号処理系とみなす指導原理の下、遅くて不正確なハードウェアである「脳」を持つ人間が無意識下で行っているとされる情報処理方式のこと。

※27 エンコード
映像・文字・音声などのある形式のデータを一定の規則に従って、圧縮や暗号化を含む目的に応じた別の形式のデータに変換することを表す単語。

※28 ディスクI/O
ハードディスクなどの外部記憶装置（ストレージ）に対するデータの読み書き操作のこと。

※29 デファクトスタンダード
「事実上の標準」を指す用語である。

5
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?